以前大多個是一個的使用 Git, 到 Github 上提交的場景, 對多人開發合並項目經驗不多,
現在遇到的是在 Github 上存在主分支, 本地需要修改多個功能和 bug 等等,
我是按以前實習回來的同學提示, 在多個分支開發不同的功能, 然後合並提交..
合並和提交的順序不是確定的, 因此不能簡單直接用 merge 每次一個個疊加.
有時我用 rebase, 但有發現 commit 順序不是時間順序, 到線上被 merge 以後也不是非常清晰
於是我想問一下麵對這樣的場景, 用怎樣的方式管理會更合適?
有在 Google, 但一些細節不清晰.. 比如 commit 顯示順序.. 還有再次被 merge 後的細節..
git支援很多工作流程，我們採用的一般是這樣，遠端建立一個主分支，本地每人創建功能分支，日常工作流程如下：
去自己的工作分支
$ git checkout work工作
....提交工作分支的修改
$ git commit -a回到主分支
$ git checkout master取得遠端最新的修改，此時不會產生衝突
$ git pull回到工作分支
$ git checkout work用rebase合併主幹的修改，如果有衝突在此時解決
$ git rebase master回到主分支
$ git checkout master合併工作分支的修改，此時不會產生衝突。
$ git merge work提交到遠端主幹
$ git push這樣做的好處是，遠端主幹上的歷史永遠是線性的。每個人在本地分支解決衝突，不會在主幹上產生衝突。
上面那位仁兄的回答很好，我這裡再補充一個資料，給樓主作為參考。這是阮兄寫的，[git分支管理策略](http://www.ruanyifeng.com/blog/2012/0...)。
可以在一條分支上一起開發，你有變更的時候，在提交前，使用
這樣將本地的修改全部緩存在一個堆疊中了，然後把別人的修改同步過來
下一步是將自己的變更恢復到最新的節點上
然後再使用git commit提交，這樣就會讓一個分支的版本按順序繼續發展，而不是像織毛衣一樣，你可以看一下我們使用這種方法前後的對比圖
之前：
之後
