在看 git 合并策略的文章时注意到了一个案例，dev 分支上加入了一个 A 文件，然后合并给了 main 分支。dev 分支继续向前开发。此时 main 分支发现新加入的 A 文件有 bug，于是紧急 fix，撤掉了合并，并生成一个新的 commit 。。此时 dev 在向前推进了一个 commit，然后此时 dev 再次合并到 main，合并后发现 main 内部“丢失”了 A 文件。
那篇文章解释这个现象是“三向合并”导致的，因为，因为 main 撤销合并时，实际对 A 文件做了删除，而 dev 分支直到第二次合并时对 A 没有任何改变，所以这个"对 A 改变"的行为在版本上说是最新的，于是合并后，A 就被删除了。
这个问题让我产生的疑问是：
*.按这个理解，最好不要在 main 分支上直接做任何改动？
*.但是如果我要 hotfix 的时候，该怎么操作呢？难道 hotfix 的改动需要通知到 dev 去？也就是 hotfix 合并到 dev，那如果人多一点，同时有十几个个 dev 分支在开发，一个 hotfix 就要发十几次次合并？
*.而且，像上面这文里提到的，hotfix 需要删除文件，把 hotfix 合并到 dev，肯定会导致 dev 的文件也被删掉，这是不是有点不妥？
那篇文章解释这个现象是“三向合并”导致的，因为，因为 main 撤销合并时，实际对 A 文件做了删除，而 dev 分支直到第二次合并时对 A 没有任何改变，所以这个"对 A 改变"的行为在版本上说是最新的，于是合并后，A 就被删除了。
这个问题让我产生的疑问是：
*.按这个理解，最好不要在 main 分支上直接做任何改动？
*.但是如果我要 hotfix 的时候，该怎么操作呢？难道 hotfix 的改动需要通知到 dev 去？也就是 hotfix 合并到 dev，那如果人多一点，同时有十几个个 dev 分支在开发，一个 hotfix 就要发十几次次合并？
*.而且，像上面这文里提到的，hotfix 需要删除文件，把 hotfix 合并到 dev，肯定会导致 dev 的文件也被删掉，这是不是有点不妥？
3
Select Language