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

2015-07-24 11:22:06 +08:00
 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分支拖代码时都小心翼翼谨慎又谨慎。

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

5113 次点击
所在节点    git
26 条回复
ryanking8215
2015-07-24 11:28:51 +08:00
我来安利git-flow
ryanking8215
2015-07-24 11:29:21 +08:00
laoyur
2015-07-24 11:33:49 +08:00
@ryanking8215 这货看过,不过没仔细看,感觉看不太懂……是不是说我必须认认真真把它学会了,才能真正解决我的问题,除此以外别无他法?
kongruxi
2015-07-24 11:37:34 +08:00
如果约定好 master 是发布分支,那就意味 master 是稳定代码,可以合并到任何开发分支
那最简单的方式就是直接将最新的 master 分支合并到你当前的分支,而不必做 cherry-pick
基于 master 来 rebase 是更好方案,但前提是你本地代码还没有 push 到远程库
Tiande
2015-07-24 11:42:26 +08:00
感觉你的 master 和 sdk 的关系更像是 平行,而不是 主从。

"某个sdk分支中修改了bug之类,需要将这次修改应用到master和其他sdk分支"
个人觉得逻辑上应:先将 bug/update 提交到 master,其他分支 再从 master 取。
lilydjwg
2015-07-24 11:43:42 +08:00
你看看不用 cherry-pick 这种会改变提交 ID 的方式、只用 merge 之类的能满足你的需求不?
laoyur
2015-07-24 11:53:54 +08:00
@dtdnqsb “先将 bug/update 提交到 master,其他分支 再从 master 取。”——是的,的确应该这样,可是实际开发过程中往往会不记得切换到master来改bug
laoyur
2015-07-24 11:58:31 +08:00
@lilydjwg 谢谢回复。merge是不是只能逐个commit merge?master上新增commit多了后感觉很繁琐
laoyur
2015-07-24 12:00:12 +08:00
谢谢,我消化下
w88975
2015-07-24 12:04:45 +08:00
master只做主版本的合并,并且不允许任何人为的修改.

每个功能,或者每个sdk,都单独一个分支,采用pull requst的方式来合并代码,1是方便review,2是功能点分离,安全性很高.也不容易搞混.
yangmls
2015-07-24 12:26:56 +08:00
cherry pick 会改变 hash 信息,久而久之你的 sdk 和 master 会像两棵树一样分裂开来,而不是一棵树上的两条分支。

嫌 commit messages 累赘的,应该使用 rebase ,或者使用 git merge --squash,但要注意,进行 git merge --squash 之后,应该删掉 sdk,重新从 master 分支里 checkout 出新的 sdk 分支,这是为了不让分支岔得越来越开,以至于下次合并,需要解决很多很多的冲突问题。
lilydjwg
2015-07-24 13:31:46 +08:00
@laoyur 可以写个脚本来解决。
提交的时候能够看到会提交到哪个分支的。如果发现不对及时退出,切换分支再提交。(当然命令行上的操作是这样子,GUI 不清楚。)
lilydjwg
2015-07-24 13:34:35 +08:00
@laoyur 对了,merge 操作是合并连续的提交的。你多看看 git book 吧。
xylophone21
2015-07-24 14:00:25 +08:00
我觉得你需要一只会设计的git。
jdlau
2015-07-24 14:05:24 +08:00
有bug先新建分支解决了,然后rebase到master,其它分支再rebase master。
laoyur
2015-07-24 14:16:02 +08:00
感谢各位,还是应该把Git好好理解透彻再说
SmartGit自带Git-Flow功能,也要好好研究下
Agromania
2015-07-24 14:21:04 +08:00
我无法适应GUI工具,菜单太复杂,操作太多

命令行一敲,全部搞定

常用命令就那么两个
ZackYang
2015-07-24 14:39:13 +08:00
GitFlow +1
pluson
2015-07-24 15:23:29 +08:00
能不能扑下心思,学习后,再来问问题。记性不好,懒。告诉你也也记不住,也不想去尝试,有卵用?
ryanking8215
2015-07-24 16:01:26 +08:00
@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步骤即可。

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/207999

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX