功能分支的好git過程

Question

我們一直在團隊中反覆討論各個開發人員使用功能分支，重新定義等的最佳流程。以下是我們提出的（來自一些郵件列表），但似乎有點複雜&有很多步驟。還有其他的SO問題與一些似乎相似和簡單的答案例子。

這是一個很好的工作流程嗎？如何簡化（如果有的話）或改變？

git checkout develop # all developer work is off of this branch 
git pull --rebase # make sure local develop is up-to-date 
git checkout -b my-nifty-feature-559876 # create your feature branch; I like to put Pivotal story ID in it for convenience; not required 

# do your work, make sure all tests still pass, etc. COMMIT FREQUENTLY 
git commit -m "First part of my nifty feature working; now on to the back-end." 

# fetch latest remote develop and rebase your local feature branch on this. 
git fetch 
git rebase origin/develop 
# Local feature branch now has latest origin/develop code as base 

# repeat above 3 frequently as you're working 

# when you're done, pull and rebase one last time, make sure tests pass, then final commit with Pivotal comment 
git commit -m "It works! [Fixes #559876]" # commit when done. Include comment like that for Pivotal integration 
git fetch 
git rebase origin/develop 

# Local feature branch now has latest origin/develop code as base 

git checkout develop # switch back to develop 
git pull 
git merge my-nifty-feature-559876 # This should be a simple FF merge 
git push origin develop # send to github 
git branch -d my-nifty-feature-559876 # you can get rid of your feature branch 

Answer 1

這幾乎是的 git的工作流程。幾乎每個其他的VCS都一樣。

git rebase origin/develop與git merge origin/develop是一個味道的問題，但兩者基本上是相同的最終結果。 Rebase提供了更清晰的歷史記錄，但合併意味着您可以始終回滾到昨天的位置。

同樣，有時我更喜歡做--squash的最終合併，以保持主分支歷史更清潔。

一個小提示，我認爲是非可選的，但：rebase之前備份。如果你使用rebase來重寫歷史記錄，那麼就有可能毀掉所有的東西然後不能回滾的危險。

git branch my-nifty-feature-559876-BACKUP 
git rebase origin/develop 

# verify everything rebased ok 
git branch -D my-nifty-feature-559876-BACKUP 

創建一個新的分支意味着你有一個分支前的特徵分支的副本。如果rebase嚴重錯誤，您可以使用reset回滾。