问一个多分支间同步代码的常用策略

[laoyur]

前提
我是git渣，只会常用操作，而且只用GUI工具（SmartGit），理由是省得背命令（记性不好）、操作傻瓜、不容易误操作，自带冲突编辑界面。团队里另一个小伙伴一直跟我安利命令行，我始终无法适应。

问题描述
一个项目做到七七八八，比如游戏项目，就会被安排接一大堆的sdk，特别是Android，真特么的烦屌了，接sdk不是仅仅仍一坨文件完事，不仅要接相应的代码，有些奇葩sdk还得定制UI之类。
于是一个sdk就搞一个分支出来，到这里还算相安无事。
接下来问题来了：
1. master分支其实一直有更新，改改弄弄又是烦的一比，我都是用Cherry-Pick把多个commit给搞到其他分支。
2. 有时候master分支的某个commit中，只有部分需要被apply到sdk分支，所以还得手工修改。
3. 有时候头脑发昏，直接在某个sdk分支中修改了bug之类，需要将这次修改应用到master和其他sdk分支，此时咋办？
4. 时间一长，master新增的commit变多后，我都搞不清哪些sdk分支Cherry-Pick到哪了，哪些遗漏了哪些是重复的，log也看的稀里糊涂的。所以每次从master往sdk分支拖代码时都小心翼翼谨慎又谨慎。

问题
我总觉得现在的做法有相当多的问题，请神人给一个主流、稳妥又易懂的方案，谢谢！

[ryanking8215]

我来安利git-flow

[ryanking8215]

http://nvie.com/posts/a-successful-git-branching-model/

[laoyur]

@ryanking8215 这货看过，不过没仔细看，感觉看不太懂……是不是说我必须认认真真把它学会了，才能真正解决我的问题，除此以外别无他法？

[kongruxi]

如果约定好 master 是发布分支，那就意味 master 是稳定代码，可以合并到任何开发分支
那最简单的方式就是直接将最新的 master 分支合并到你当前的分支，而不必做 cherry-pick
基于 master 来 rebase 是更好方案，但前提是你本地代码还没有 push 到远程库

[Tiande]

感觉你的 master 和 sdk 的关系更像是 平行，而不是 主从。

"某个sdk分支中修改了bug之类，需要将这次修改应用到master和其他sdk分支"
个人觉得逻辑上应：先将 bug/update 提交到 master，其他分支 再从 master 取。

[lilydjwg]

你看看不用 cherry-pick 这种会改变提交 ID 的方式、只用 merge 之类的能满足你的需求不？

[laoyur]

@dtdnqsb “先将 bug/update 提交到 master，其他分支 再从 master 取。”——是的，的确应该这样，可是实际开发过程中往往会不记得切换到master来改bug

[laoyur]

@lilydjwg 谢谢回复。merge是不是只能逐个commit merge？master上新增commit多了后感觉很繁琐

[laoyur]

谢谢，我消化下

[w88975]

master只做主版本的合并,并且不允许任何人为的修改.

每个功能,或者每个sdk,都单独一个分支,采用pull requst的方式来合并代码,1是方便review,2是功能点分离,安全性很高.也不容易搞混.

[yangmls]

cherry pick 会改变 hash 信息，久而久之你的 sdk 和 master 会像两棵树一样分裂开来，而不是一棵树上的两条分支。

嫌 commit messages 累赘的，应该使用 rebase ，或者使用 git merge --squash，但要注意，进行 git merge --squash 之后，应该删掉 sdk，重新从 master 分支里 checkout 出新的 sdk 分支，这是为了不让分支岔得越来越开，以至于下次合并，需要解决很多很多的冲突问题。

[lilydjwg]

@laoyur 可以写个脚本来解决。
提交的时候能够看到会提交到哪个分支的。如果发现不对及时退出，切换分支再提交。（当然命令行上的操作是这样子，GUI 不清楚。）

[lilydjwg]

@laoyur 对了，merge 操作是合并连续的提交的。你多看看 git book 吧。

[xylophone21]

我觉得你需要一只会设计的git。

[jdlau]

有bug先新建分支解决了，然后rebase到master，其它分支再rebase master。

[laoyur]

感谢各位，还是应该把Git好好理解透彻再说
SmartGit自带Git-Flow功能，也要好好研究下

[Agromania]

我无法适应GUI工具，菜单太复杂，操作太多

命令行一敲，全部搞定

常用命令就那么两个

[ZackYang]

GitFlow +1

[pluson]

能不能扑下心思，学习后，再来问问题。记性不好，懒。告诉你也也记不住，也不想去尝试，有卵用？

[ryanking8215]

@laoyur 其实git-flow的概念还是蛮简单的:
git flow会有以下分支概念:
master
develop
feature
release
hotfix


master是主分支，就是程序当前stable版本分支
develop是开发分支
feature分支是特性分支，由develop branch而来（git flow feature start xxx），结束后（git flow feature finish）合并进develop
release是发布分支，develop到一定程度需要发布版本了，那么通过git flow release start xxx， 生成一个发布分支，在分支上修改版本号啥的，或者按照生产环境再测试一下，然后git flow release finish xxx, 它会将修改合并进develop和master，并生成tag.
hotfix没怎么用过，避免错误就不说了。

多人协作的话，一般在远程版本库保留master和develop分支即可，每个开发者在本地可以创建feature分支进行开发，然后push进develop，到时由主管项目人员进行release步骤即可。

我就是这么用的，挺简单方便的，希望对你有帮助