场景:
隔壁部门老项目,有 dev 和 test 分支.test 分支应该/也许/大概是基于 dev 创建的(时间太久了看不太清楚...) 由于一些历史原因,某段时间 dev 和 test 分支居然同时有代码提交. 现在想重新把 git 规范搞起来,严格按照 dev>test>master 这种方式.
两个方案:
1.dev 向 test 合并,再删掉 dev,然后基于 test 创建 dev 分支.后续按标准规范来.
2.dev 向 test 合并,然后 test 向 dev 合...后续按标准规范来.
我觉得 1 比较正常.但是最终不知道是怕代码丢了还是啥的,居然用的方案 2...
这种 A 和 B 互相 merge 的操作我也没见过..这是做了个啥???
1
ztxcccc 360 天前
用以下指令可以看到所有的不同之处,或者交换分支名
git diff dev..test >> diff merge 里有 commit 号,被 merge 过的 commit 不会被再次 merge |
2
Rache1 360 天前 1
> 这种 A 和 B 互相 merge 的操作我也没见过..这是做了个啥???
A:master ,B:feature-01 以这种为例的话,正常情况下 B 开发完成了,就合并到 A 。这是理想情况,但是实际情况会比较复杂,比如 A 新合并了 C 的内容。那么现在 A 就领先于 B 了,这时候如果 B 和 C 修改了同一部分内容。你在想把 B 合并到 A 的时候,就会有冲突了。 面对这种情况,就会出现 A 合并 B ,解决冲突,然后 B 再合并到 A 了。 简单的说,就是你的目的是要把功能合并到主干,但是主干又有新的代码,你可以把主干上最新的代码合并到你的功能分支上,这也就是最终会合并到主干上的效果。 |
3
CrazyMonkeyV 360 天前
肯定是按照第二种来呀。2 楼已经说了原因了。而且分支管理,正常来说,没有删除主分支的习惯。
我们的版本管理是: 比如当前版本是:1.1.0 ,那么每个人都要切到自己临时分支,如:name-1.1.0 。然后在上面做修改,改完后,合并到 1.1.0 。在 1.1.0 测试完成发布后,就封版了。下次就是 1.3.0 了。 |
5
Felldeadbird 360 天前
其实你 2 个方案合并,他们肯定会有一次冲突产生的。 解决了冲突,两个分支其实就是同一个内容(后续按照规范执行的话)。
然后为什么怕丢代码,文件之类问题呢?两个差异大的分支合并肯定会保冲突的,只要解决冲突的人没合并错,就不会丢代码,丢文件。 我用了 10 年 git ,没出现过这个问题。 |
7
wonderl17 360 天前
1 这么搞不就是一个人写代码么,多人协作肯定要用 2 啊
|
8
28Sv0ngQfIE7Yloe 360 天前
|
9
Charrlles 360 天前 via iPhone
用 cherry-pick 吧,或者用一个公共的 dev 分支,每个人再从 dev 分支切 dev1 dev2 ,然后定期 rebase 到最新的 dev
|
10
paceewang1 359 天前
|
11
Rache1 359 天前
|
12
CrazyMonkeyV 359 天前
@Morii 万一临时有 BUG 或者需求更改,就 1.2.0 上搞。没问题了再搞会主分支、
|
13
CrazyMonkeyV 359 天前
@Morii 万一临时有 BUG 或者需求更改,就 1.2.0 上搞。没问题了再合并回主分支。
|