git操作工作流

2022-11-24 19:06:44 字數 3044 閱讀 7530

本文旨在為一些git新手講解git工作流上的操作,使大家更清晰的認識到git相關的操作,不再為因為不會git操作,連**都不敢合。

git是一個版本管理工具,同樣常見的還有svn。就概念上來說,git是分散式的,svn是集中式的,兩者有很大的思想上的差別。

在介紹操作命令時,首先講解一個概念:本地分支與遠端分支。

用來做生產(origin-master)、測試環境(origin-develop)的分支,很多情況下由開發組長進行控制,做自動化構建(如 jenkins)拉取的遠端**。一般來說,每次的遠端**推送,都代表實際的一個開發/測試環境版本。

與遠端分支無關的本地電腦快取區**。你可以從任何一個遠端分支拉取**作為自己的本地分支,如 origin-master上拉取到本地的** master。這樣可以做版本**的bug修復。本地分支的**,對於**管理者(開發組長-管理遠端分支**)來說,

只要你沒有將本地**推送到遠端,他就看不到你的**的。

commit 提交本地**(本地**做了更改之後,如果此時需要進行分支切換或者推拉遠端**,都需要首先提交本地**,這樣才不會報錯。)

checkout 切換/檢出分支 (這個是修復線上版本特定問題的神技,可以從特定某個分支版本節點上檢出**,或者切換本地不同分支**)

pull 拉取**(每次在推送**之前 需要先拉取一下相對應的遠端分支,這樣可以將其他人提交的**先拉到本地,如果遠端有與自己本地將要提交的**有同一地方的更改,就會有衝突,這時候需要進行解決衝突)

解決衝突時,需要對比自己的**與遠端拉取下來的**,非衝突部分,別人的與自己的都要保留,如果是衝突的地方,需要與相應的開發人員進行溝通,進行衝突解決。解決完成後,需要再進行**提交,或者是標記衝突解決

push 推送**(需要選擇對應的遠端分支進行推送,一般在不進行版本更新時,需要將**推送到自創的遠端分支上,再由開發組長,將**合併到相應的遠端分支)

**:所有人都會從一個遠端分支(由專案負責人決定)拉取(checkout)**,如master。每個人拉取完**後,會在本地進行業務/bug開發。每個人開發的模組或許都不一樣。只要在沒有向master進行push(一般master的push功能會被開發組長限制,

正常可能會push到develop等開發測試分支。)遠端master的**就一直不會改變。

簡而言之所謂的分散式協作就是,git遠端分支是一箇中心,大家都從遠端拉取**,在各自的本地進行開發,開發完畢之後,再統一推到遠端master,這樣就完成了多發協作開發。

圖中的commit是一個提交**的操作,這個提交是提交到本地快取,這樣本地也就有了比如master這個本地版本,當然,你也就可以任意建立本地分支,只要你自己能明白自己在哪個分支,在做什麼。

這裡引出一個問題,如果說大家開發的有相同的模組,如小黃與小吳同時在修改上傳的頁面。此時,如果小黃先推送了**,小吳後推送了**。那麼master上修改的頁面是不是就存在兩個人**,這樣master的**就可能會被報錯(所謂的衝突)

那麼如何解決這種問題呢?

所以,大家必須養成一個好習慣。本地**在進行commit提交後,需要先對遠端分支進行一個拉取遠端分支的操作 push。這樣,如果多個人修改了同一個檔案有衝突,可以先在自己本地發現衝突並且聯絡相對應的開發人員進行溝通解決衝突。

再講**提交進行推送。這樣可以避免遠端分支受到汙染。

工作流圖

解析:一般來說 稍微正規點的環境管理會有 測試環境,準生產環境,開發環境。其中準生產環境用來作為與master(生產環境)保持同步,進而保護生產環境**。對於測試來說,準生產環境通過之後,才能允許上線(master)

如果小黃需要將自己本地開發環境的**推送到測試環境讓測試人員進行測試,就需要進行 commit pull push操作將本地**的提交到開發/測試環境。然後通過自動化部署,如jenkins進行構建。

當前生產環境(master版本號為5的)有bug,需要小黃進行修復。那麼此時小黃就需要將自己本地的**進行commit儲存,然後從master(生產環境**)切出一個版本作為本地**,

然後推到一個新的遠端分支比如(fixed-修復失效)。

這裡其實有個問題,不同公司處理的方式也不同。

我們可以看到 **修復了,也推送到了遠端分支,但是此時我們的測試環境有現在正在開發的版本6**。如何將現在生產環境(版本5)修復的**推送到測試環境呢,如果直接推到 遠端測試環境/開發環境,那麼會因為

含有當前6版本的開發**導致環境裡的**不純潔,測試測的時候回含有版本6的**。一般常見的處理方式有以下幾種:

1:從遠端測試/開發環境,切出一個分支,推送到新的遠端(如 orgin-測試環境-備份),再將遠端的測試環境刪掉,此時將fixed-修復分支的**推送到測試環境,讓測試進行測試。通過之後再同樣的方式上到準生產(如果準生產也有版本6的**,如果沒有

版本6的**是不需要進行刪除準生產環境**的)。上線完成後,再將將現有的測試與準生產環境進行刪除從備份中取出。

2:如果公司是自動化構建,如jenkins,此時可以配置自動化構建拉取的遠端**為 fixed-修復,這樣就保證測試環境 直接拉取版本5的修復版本了。準生產環境一樣的道理,需要新建遠端分支,進行jenkins配置。

如果順利上線了,我們將**切回小黃的版本6開發**。此時我們需要注意的是,master**有了一個修復版本,版本號就變成了如5.5,那麼我們需要做一下**同步

**:首先我們需要將master** 直接拉到本地,如果有衝突,解決衝突,隨後一級一級往開發、測試、環境推送,最後上準生產,環境。這樣所有的版本**(黃色的圓點)**就是一樣的了。

操作工作表

目錄中階操作 高階操作 copy 表 我們可以對錶做 操作?無非是增刪改查,也就是方法 有哪些資訊可以獲取?也就是屬性 關於表的名字?我們知道我們可以對錶進行重新命名,那我們命名的那個名字算是表的名字嗎?可以算是,這個表可以叫某個名字,那個表也可以叫這個名字,並不唯一 但表還有一個其它的名字,那就是...

VBA 操作工作表

第一講 錄製巨集及for迴圈 for迴圈 sub shihsi dim i as integer for i 1 to 100 step 2 設定步長 range a i i next end sub 一些概念 方法 表示動作的操作叫做方法 屬性 表示固有的屬性,如有多少個單元格等,屬性不能單獨操作...

Git 工作流

git 工作流 在專案開發過程中使用 git 的方式 像 svn 一樣,集中式工作流以 倉庫作為專案所有修改的單點實體。所有 修改都提交到 master 這個分支上。這種方式與 svn 的主要區別就是開發人員有本地庫。git 很多特性並沒有用到。gitflow 工作流通過為功能開發 釋出準備和維護設...