这是一个创建于 347 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景:
隔壁部门老项目,有 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 347 天前
用以下指令可以看到所有的不同之处，或者交换分支名
git diff dev..test >> diff merge 里有 commit 号，被 merge 过的 commit 不会被再次 merge |
 |
2
Rache1 347 天前  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 347 天前
肯定是按照第二种来呀。2 楼已经说了原因了。而且分支管理，正常来说，没有删除主分支的习惯。
我们的版本管理是： 比如当前版本是：1.1.0 ，那么每个人都要切到自己临时分支，如：name-1.1.0 。然后在上面做修改，改完后，合并到 1.1.0 。在 1.1.0 测试完成发布后，就封版了。下次就是 1.3.0 了。 |
 |
5
Felldeadbird 347 天前
其实你 2 个方案合并，他们肯定会有一次冲突产生的。 解决了冲突，两个分支其实就是同一个内容（后续按照规范执行的话）。
然后为什么怕丢代码，文件之类问题呢？两个差异大的分支合并肯定会保冲突的，只要解决冲突的人没合并错，就不会丢代码，丢文件。 我用了 10 年 git ，没出现过这个问题。 |
 |
7
wonderl17 347 天前
1 这么搞不就是一个人写代码么，多人协作肯定要用 2 啊
|
 |
8
28Sv0ngQfIE7Yloe 347 天前
|
 |
9
Charrlles 347 天前 via iPhone
用 cherry-pick 吧，或者用一个公共的 dev 分支，每个人再从 dev 分支切 dev1 dev2 ，然后定期 rebase 到最新的 dev
|
 |
10
paceewang1 347 天前
|
|
11
Rache1 346 天前
|
|
12
CrazyMonkeyV 346 天前
@Morii 万一临时有 BUG 或者需求更改，就 1.2.0 上搞。没问题了再搞会主分支、
|
|
13
CrazyMonkeyV 346 天前
@Morii 万一临时有 BUG 或者需求更改，就 1.2.0 上搞。没问题了再合并回主分支。
|
Select Language