Git工作流指南(二)

二、功能分支工作流

下面的示例演示了如何把Pull Requests作為Code Review的方式,但注意Pull Requests可以用于很多其它的目的。

小紅開始開發(fā)一個新功能

在開始開發(fā)功能前,小紅需要一個獨立的分支。使用下面的命令新建一個分支:

git checkout -b marys-feature master

這個命令檢出一個基于master名為marys-feature的分支,Git-b選項表示如果分支還不存在則新建分支。這個新分支上,小紅按老套路編輯、暫存和提交修改,按需要提交以實現(xiàn)功能:

git status
git add <some-file>
git commit

小紅要去吃個午飯

早上小紅為新功能添加一些提交。去吃午飯前,push功能分支到中央倉庫是很好的做法,這樣可以方便地備份,如果和其它開發(fā)協(xié)作,也讓他們可以看到小紅的提交。

git push -u origin marys-feature

這條命令push marys-feature分支到中央倉庫(origin),-u選項設(shè)置本地分支去跟蹤遠(yuǎn)程對應(yīng)的分支。設(shè)置好跟蹤的分支后,小紅就可以使用 git push命令省去指定推送分支的參數(shù)。

小紅完成功能開發(fā)

小紅吃完午飯回來,完成整個功能的開發(fā)。在合并到master之前,她發(fā)起一個Pull Request讓團(tuán)隊的其它人知道功能已經(jīng)完成。但首先,她要確認(rèn)中央倉庫中已經(jīng)有她最近的提交:

git push

然后,在她的GitGUI客戶端中發(fā)起Pull Request,請求合并marys-feature到master,團(tuán)隊成員會自動收到通知。Pull Request很酷的是可以在相關(guān)的提交旁邊顯示評注,所以你可以對某個變更集提問。

小黑收到Pull Request

小黑收到了Pull Request后會查看marys-feature的修改。決定在合并到正式項目前是否要做些修改,且通過Pull Request和小紅來回地討論。

小紅再做修改

要再做修改,小紅用和功能第一個迭代完全一樣的過程。編輯、暫存、提交并push更新到中央倉庫。小紅這些活動都會顯示在Pull Request上,小黑可以斷續(xù)做評注。
如果小黑有需要,也可以把marys-feature分支拉到本地,自己來修改,他加的提交也會一樣顯示在Pull Request上。

小紅發(fā)布她的功能

一旦小黑可以的接受Pull Request,就可以合并功能到穩(wěn)定項目代碼中(可以由小黑或是小紅來做這個操作):

git checkout master
git pull
git pull origin marys-feature
git push

無論誰來做合并,首先要檢出master分支并確認(rèn)是它是最新的。然后執(zhí)行git pull origin marys-feature合并marys-feature分支到和已經(jīng)和遠(yuǎn)程一致的本地master分支。你可以使用簡單git merge marys-feature命令,但前面的命令可以保證總是最新的新功能分支。最后更新的master分支要重新push回到origin。

這個過程常常會生成一個合并提交。有些開發(fā)者喜歡有合并提交,因為它像一個新功能和原來代碼基線的連通符。但如果你偏愛線性的提交歷史,可以在執(zhí)行合并時rebase新功能到master分支的頂部,這樣生成一個快進(jìn)(fast-forward)的合并。一些GUI客戶端可以只要點一下『接受』按鈕執(zhí)行好上面的命令來自動化Pull Request接受過程。如果你的不能這樣,至少在功能合并到master分支后能自動關(guān)閉Pull Request

與此同時,小明在做和小紅一樣的事

當(dāng)小紅和小黑在marys-feature上工作并討論她的Pull Request的時候,小明在自己的功能分支上做完全一樣的事。

通過隔離功能到獨立的分支上,每個人都可以自主的工作,當(dāng)然必要的時候在開發(fā)者之間分享變更還是比較繁瑣的。

到了這里,但愿你發(fā)現(xiàn)了功能分支可以很直接地在集中式工作流的僅有的master分支上完成多功能的開發(fā)。另外,功能分支還使用了Pull Request,使得可以在你的版本控制GUI客戶端中討論某個提交。

功能分支工作流是開發(fā)項目異常靈活的方式。問題是,有時候太靈活了。對于大型團(tuán)隊,常常需要給不同分支分配一個更具體的角色。Gitflow工作流是管理功能開發(fā)、發(fā)布準(zhǔn)備和維護(hù)的常用模式。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 多種多樣的工作流使得在項目中實施Git時變得難以選擇。這份教程提供了一個出發(fā)點,調(diào)查企業(yè)團(tuán)隊最常見的Git工作流。...
    JSErik閱讀 4,609評論 2 8
  • Paste_Image.png]](http://blog.jobbole.com/76861/) Forking...
    yohn閱讀 484評論 0 0
  • 鬼谷的月色撩人,鬼谷的女子更撩人。顧輕塵一直都知道。 是夜,顧輕塵記不清這是他在鬼谷的第幾個年頭,自從在墨脫失去了...
    李宛宸679閱讀 737評論 59 32
  • 某一個電影這樣說過“同志間對上眼的信號只有三秒”但是機(jī)緣巧合,兩個電影中的主角們就在那么兩三天的時間,遇到了他們這...
    白大截閱讀 433評論 0 1
  • 一只金色的小瓢蟲 被風(fēng)吹送著 落在敞開的車窗邊 在我準(zhǔn)備開啟 一段隨心而行的旅程時 它匆匆加入進(jìn)來 一切都因這可愛...
    水仙書生閱讀 472評論 2 3

友情鏈接更多精彩內(nèi)容