前提
我是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分支拖代码时都小心翼翼谨慎又谨慎。
问题
我总觉得现在的做法有相当多的问题,请神人给一个主流、稳妥又易懂的方案,谢谢!
1
ryanking8215 2015-07-24 11:28:51 +08:00
我来安利git-flow
|
2
ryanking8215 2015-07-24 11:29:21 +08:00
|
3
laoyur OP @ryanking8215 这货看过,不过没仔细看,感觉看不太懂……是不是说我必须认认真真把它学会了,才能真正解决我的问题,除此以外别无他法?
|
4
kongruxi 2015-07-24 11:37:34 +08:00
如果约定好 master 是发布分支,那就意味 master 是稳定代码,可以合并到任何开发分支
那最简单的方式就是直接将最新的 master 分支合并到你当前的分支,而不必做 cherry-pick 基于 master 来 rebase 是更好方案,但前提是你本地代码还没有 push 到远程库 |
5
Tiande 2015-07-24 11:42:26 +08:00
感觉你的 master 和 sdk 的关系更像是 平行,而不是 主从。
"某个sdk分支中修改了bug之类,需要将这次修改应用到master和其他sdk分支" 个人觉得逻辑上应:先将 bug/update 提交到 master,其他分支 再从 master 取。 |
6
lilydjwg 2015-07-24 11:43:42 +08:00
你看看不用 cherry-pick 这种会改变提交 ID 的方式、只用 merge 之类的能满足你的需求不?
|
7
laoyur OP @dtdnqsb “先将 bug/update 提交到 master,其他分支 再从 master 取。”——是的,的确应该这样,可是实际开发过程中往往会不记得切换到master来改bug
|
8
laoyur OP @lilydjwg 谢谢回复。merge是不是只能逐个commit merge?master上新增commit多了后感觉很繁琐
|
9
laoyur OP 谢谢,我消化下
|
10
w88975 2015-07-24 12:04:45 +08:00
master只做主版本的合并,并且不允许任何人为的修改.
每个功能,或者每个sdk,都单独一个分支,采用pull requst的方式来合并代码,1是方便review,2是功能点分离,安全性很高.也不容易搞混. |
11
yangmls 2015-07-24 12:26:56 +08:00 1
cherry pick 会改变 hash 信息,久而久之你的 sdk 和 master 会像两棵树一样分裂开来,而不是一棵树上的两条分支。
嫌 commit messages 累赘的,应该使用 rebase ,或者使用 git merge --squash,但要注意,进行 git merge --squash 之后,应该删掉 sdk,重新从 master 分支里 checkout 出新的 sdk 分支,这是为了不让分支岔得越来越开,以至于下次合并,需要解决很多很多的冲突问题。 |
12
lilydjwg 2015-07-24 13:31:46 +08:00
@laoyur 可以写个脚本来解决。
提交的时候能够看到会提交到哪个分支的。如果发现不对及时退出,切换分支再提交。(当然命令行上的操作是这样子,GUI 不清楚。) |
14
xylophone21 2015-07-24 14:00:25 +08:00
我觉得你需要一只会设计的git。
|
15
jdlau 2015-07-24 14:05:24 +08:00
有bug先新建分支解决了,然后rebase到master,其它分支再rebase master。
|
16
laoyur OP 感谢各位,还是应该把Git好好理解透彻再说
SmartGit自带Git-Flow功能,也要好好研究下 |
17
Agromania 2015-07-24 14:21:04 +08:00
我无法适应GUI工具,菜单太复杂,操作太多
命令行一敲,全部搞定 常用命令就那么两个 |
18
ZackYang 2015-07-24 14:39:13 +08:00
GitFlow +1
|
19
pluson 2015-07-24 15:23:29 +08:00
能不能扑下心思,学习后,再来问问题。记性不好,懒。告诉你也也记不住,也不想去尝试,有卵用?
|
20
ryanking8215 2015-07-24 16:01:26 +08:00 1
@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步骤即可。 我就是这么用的,挺简单方便的,希望对你有帮助 |
22
karloku 2015-07-25 20:37:49 +08:00
git flow流程确实好用, 不过真的想用舒服了还是需要你团队每个人都有review别人代码的能力, 这样才能顺畅. 不然的话可能还不如让一个开发人员开发完所有东西给你pr来得顺畅.
|
23
karloku 2015-07-25 20:41:43 +08:00 1
@ryanking8215 hotfix用来修复线上bug, 临时发现一个紧急问题需要快速修复放上线. 这时候就没法走feature->devel->release->master这个流程了.
hotfix直接基于现有master分支开出hotfix/xxxx的新分支, 当finish的时候会同时被merge到devel和master, 并且打上一个tag |
24
ablula 2015-12-16 15:25:44 +08:00
我也推荐 gitflow ,这里有篇文章讲的不错,中文的容易懂些: http://blog.csdn.net/sweetvvck/article/details/50245147
|
25
laoyur OP 感谢这么久还有人回复
其实现在回过头来看,我要问的不是 git-flow 能解决的……而是如何组织主帖中提到的安卓游戏纷繁复杂的项目结构。一份代码改改 UI ,改改部分代码,就变 N 个游戏,每个游戏要分 M 个渠道,全部要装在一个 git repo 中以方便维护,实在扛不住 最后,好吧, who cases ,老子已经脱坑安卓游戏了,古德拜尔,老子不玩了 |
26
tankxxl 2017-08-24 15:32:56 +08:00
是啊,我理解楼主的问题,一个项目多个变种,多个变种导致多个分支,多个分支是平等关系,那么问题来了。
1、在分支 1 写了几行代码,我现在想让所有其它分支都用上这几行代码。如何便捷的实现? |