小白提问： Git 在实际多人合作中是如何使用的？

[AerithLoveMe]

请问一下 Git 在实际工作中是如何使用的？是由一个人创立仓库建立基本模块，然后组员 clone 下来分别完成么？还是其他的方式？求告知，谢谢！

[jadehare]

操作分支，有一个主分支，其他人从这个主分支切分支，改完后再和回到主分支

[shuax]

git flow 了解一下

[TuringGunner]

有一个 master 分支，其他人 fork 一个自己的，开发，往 master 提

[itskingname]

有几个基本原则：
1. master 分支不能直接修改代码。他里面的代码变动只能通过 merge 引入
2. 要增加新功能或者修改 bug 时。先把本地的 master 分支更新到最新。然后基于它创建一个开发分支 dev
3. 在开发分支 dev 修改代码。
4. 先把 dev 分支的代码 commit 。但不要 push
5. 切换回 master 分支，git pull 更新到最新
6. 切换到 dev 分支，把 master 分支 merge 到 dev 分支。如果有冲突，就解决冲突，然后继续 commit 。如果没有冲突，进入第 7 步。
7. 切换到 master 分支，把 dev 分支 merge 进来。第 7，8 步的时间间隔一定要短。正常情况下，这一步一定会成功。
8. 提交 master 分支到远程的 master 分支。完成。

如果团队有持续集成的流程。那么第 8 补是提交到持续集成专用的分支，CI 系统会自动发起 code review 给相关的人。他们审查完毕通过以后，CI 系统自动把代码合并进入真正的远程 master 分支。然后自动部署上线。

[AerithLoveMe]

@itskingname 大概了解了 谢谢

[zxCoder]

如果第 7 步的时候，master 分支又被人改了，是不是就得重新进行 5-7 步了

[volvo007]

因为自己是野路子出家，所以还真不清楚，谢谢 #4 的老哥

所以关键就是自己的修改先 commit，别急着 push ； master 再 pull 一次同步并解决和 dev 冲突之后，再把 dev merge 到本地的 master 再提交。了解了

如果这个时候，不巧远程的 master 真的被人修改了，那看起来再从 5. 开始做一次就行了

[zxCoder]

@itskingname
如果第 7 步的时候，master 分支又被人改了，是不是就得重新进行 5-7 步了

[dilu]

#4 的方法是 checkout 一个新分支 干完了 merge 到 master 其实也可以通过平台的 merge request 合并到 master 上

这种瀑布流的开发其实还有一个办法是，本地 dev 开发完了 rebase 一下 origin/master 然后 push 如果跟别人协同，git pull 的时候可以加上--rebase 这样出来的线非常清晰明了

还有一种敏捷开发的方式，多人同时在 dev 开发，定时从 dev 合并到 test 分支，测试完成后合并到 master，再定期打 tag 或者发布 release 分支

[itskingname]

@zxCoder 是的，所以第 6，7 步的间隔时间要短。