git簡明實操模板

2021-10-12 10:12:33 字數 4421 閱讀 8584

已經merge到主分支的開發分支就不要再繼續用了,刪掉就行,如果繼續用那麼開發分支的新提交就只能通過cherry-pick指令向主分支提交**以最大限度的減少衝突,繼續使用merge就會出現大量的衝突,而且用繼續用這個開發分支是沒有任何意義的,因為開發分支裡的所有**改動都已經在主分支裡了,直接從主分支裡面再checkout -b乙個新分支就好了,為什麼還要繼續使用乙個本應該被刪掉的分支呢?

**版本管理的情景。

專案遠端倉庫中有兩個分支:

1】maseter分支作為發布分支,只接受要release到客戶手中的**,需要保證任何時候都能編譯通過

2】dev分支作為開發分支,接受所有開發過程中的**,需要保證任何時候都可以編譯通過

你自己在本地以dev分支為base進行開發,測試通過後merge進入master分支。在版本管理的時候你要面對的幾個主要問題:

1】保證自己的本地分支跟遠端分支同步

2】保證自己的commit跟分支整潔

3】合併**時候盡量少的衝突

4】自己的**合併進遠端倉庫後不會引起問題

下面從倉庫的建立開始,逐步進行介紹:

1】建立倉庫

git clone 遠端倉庫位址
2】切換到開發分支

git checkout dev

git pull # git pull 是定期的操作,需要時長進行,這是減少衝突的保證

3】以開發分支為base,建立自己的開發分支

git checkout -b mydev
4】在自己的開發分支中進行開發,提交自己的commit

git add -u

git commit -m "commit1"

git add -u

git commit -m "commit2"

git add -u

git commit -m "commit3"

git add -u

git commit -m "commit4"

5】現在碰到乙個場景,你的當前task還沒有開發完,但是你的**已經有一段時間沒有同遠端dev分支進行同步了,這讓你很忐忑,你可以通過如下操作進行同步

git checkout dev       # 切換到本地的dev分支

git pull # dev 分支同遠端dev分支進行同步

git checkout mydev # 切換回自己的分支

git rebase dev # 讓自己的mydev分支同遠端的dev分支進行同步,並保證自己的commit1、commit2、commit3、commit4處於所有commit記錄中的最新位置,這個過程中可能會出現衝突,需要及時解決,如果過這個同步過程進行的比較頻繁(如每隔一兩天進行一次)及時的話,很少會出現衝突,就算有衝突也是很小的衝突很容易解決

6】在mydev分支上繼續開發

git add -u

git commit -m "commit5"

git add -u

git commit -m "commit6"

git add -u

git commit -m "commit7"

git add -u

git commit -m "commit8"

補充6】如果在開發過程中,你使用多台機器(跨平台開發時候)同時維護mydev分支,也就是說你本台機器上開發的**需要在開發過程中與其他機器共享(不是與同事共享,是這個分支就你自己在用,但是在多台機器上用),你需要保持遠端的mydev分支跟你本地的mydev分支時時保持同步

git checkout dev    #切換到主分支

git pull # 獲取主分支最新**

git checkout mydev # 切回自己的開發分支

git pull # 先把其他機器上提交的**同步下來

git rebase dev # 基於最新的dev**rebase 自己的開發分支

git push --force-with-lease --set-upstream # 將自己的開發分支mydev同步到遠端的開發分支mydev,當缺少後面的命令字尾時候會有衝突報錯,只是別人也在使用這個mydev分支的話,會給其他的同事產生非常不好的影響;設定遠端的跟蹤分支,缺少該字尾,則本地分支與遠端分支沒有跟蹤關係

git commit --amend # 向前乙個commit中追加改動

乙個人同時使用多台機器時候工作通常是序列的,完全可以一台機器上推完**再去另一台機器上pull之後再工作,但是多個人共用乙個分支點的時候工作往往是並行的,把遠端的mydev分支強制改了就相當於把其他同事的開發base給改了,他要pull你強制推到遠端的**就會失敗,所以多個人共用乙個開發分支的時候一定不要使用rebase,或者在開發過程中都不要再改動mydev的base,等最後再開發分支都做完了統一由乙個同事做rebase的工作,做完rebase之後強制推到遠端倉庫與遠端的主dev分支合併。

7】經過這8個commit你已經完成了task的開發,完成了各種測試,需要將**提交到遠端dev分支中

git checkout dev

git pull

git checkout mydev

git rebase dev # 將本地**與遠端**進行最後的同步

git rebase -i # 將本地的8個commit進行合併,以簡潔自己的版本管理,具體細節網上有很充足的教程

git push origin mydev:mydev # 將本地的mydev分支推送到遠端倉庫的mydev新分支

# 需要注意的是上面雖然將本地的分支推到了遠端倉庫,但是此時的遠端倉庫mydev分支跟本地的mydev分支之間並沒有跟蹤關係,要建立他們之間的跟蹤關係還需要 git --set-upstream origin mydev:mydev 指令操作

8】在遠端倉庫中建立merge request將**合併進dev分支就可以了。

9】你提交的**進入了遠端的dev倉庫之後,經過別人pull測試合格了,可以release了,後面你開始準備將你的開發**合併進入release分支

10】切換到本地的master分支pick對應的**

git log --author="你的賬號名字"     # 檢視你自己的提交記錄,獲取commitid

git checkout master

git pull

git cherry-pick commitid # 前面你已經將commitid進行了合併,而且將commitid移到了最新的位置,所以你這裡的這一步就會少很多麻煩,如果出現衝突解決衝突,不過前面你如果嚴格按照這個流程進行開發,這裡理論上不會出現衝突

11】本地master分支**測試通過,提交到遠端自己的新分支

git push origin master:master-自定義遠端新分支字尾
12】遠端倉庫中提交merge request 或者是cherry-pick請求,將自己分支中的**合併到master分支中

13】其他人獲取了你在master上的**,聯調測試通過,等待**release

補充場景:

在6或者4的過程中,你又接收了新的task,這個task可以在你commit3的基礎上繼續進行,分兩種情況:

1】新的task你可以非常快的完成,基本上不會影響你現在的工作進度

git stash         # 將現在工作現場進行保護

git checkout commit3id -b mydevnew # 以commit3id為base建立乙個新的開發分支

# 完成開發工作,提交**

git checkout mydev # 回到原來的開發分支

git stash pop # 恢復原來的工作現場,繼續原來的開發工作

2】新的task是個長期的任務,且優先順序比較高,需要停下手頭的task,首先完成新的task

git add -u

git commit -m "儲存工作現場"

git checkout commit3id -b mydevnew # 建立新的開發分支

# 完成新task的開發工作,提交**,流程如上面所本文所講

git checkout mydev # 切換回原來的開發分支,繼續原task的開發

總結乙個流程圖

git版本控制系統實操

sudo apt get install git git config global user.name zhangshouguo git config global user.email zhangshoug 163.com 顯示中文目錄檔名 git config global core.quot...

git 分布式版本控制軟體 實操

git 分布式版本控制 為什麼要做版本控制?要保留之前所有的版本,以便回滾和修改。進入要管理的資料夾 右鍵 git bash here 初始化 git init 管理目錄下的檔案狀態 git status 管理指定檔案 git add 檔案的名字 index.html git add 當前所有的檔案...

mysql分割槽實操

分成2步 2.將原表資料插入新錶 insert into 目標表 select from 表 create table met shopv2 order copy1 id int 11 not null auto increment,orderid varchar 20 character set ...