Git merge 导致回归

Question

你能帮我解开这个谜吗？几个月来我们一直遇到一个问题，有时我们的 git 存储库中的更改似乎“消失”或回归。我终于发现它正在发生。

我们的工作流程是从 master 创建一个功能分支并开始工作。当我们准备好 merge 我们的工作时，我们首先将 master merge 到功能分支上，并修复任何冲突或集成问题。

在这个特定的 merge 过程中，git 决定选择一个 block 的功能分支版本，而它应该从 master 中选择 block 。没有 merge 冲突，git 只是认为这是正确的做法，但却是错误的。为什么？那么我们能做些什么来防止这种事情发生呢？

Answer 1

为什么要将 master merge 到 feature 中？您的功能分支应该是代表您的更改的一组独立的提交。一旦您将 master merge 到功能中，您就“污染”了您的提交。

如果您需要在分支功能后将更改提交给 master，则应该使用 rebase 。将 rebase (在这个意义上)视为现在再次创建您的分支，并使用您已经在该功能分支上所做的提交。

关于您的更改消失的推测原因是文件的主版本比功能分支提交更新。当您将 master merge 到 feature 中时，不会发生 merge 冲突，因此 git auto 会为了方便而 merge 分支。

尝试重新创建您上面提到的场景，但将功能 merge 到主版本中，看看会发生什么。

编辑:

how would we handle a hotfix that needs to happen in the middle of the integration of the feature with master?

在集成之前，可以从最新的远程主服务器创建一个修补程序作为新分支。请记住，您只是在本地存储库上进行集成，因此此处的任何更改都不是公开的......还没有。

git checkout -b hotfix origin/master
# do changes
git commit -am "Made hotfix"
git checkout master
git merge hotfix

# hotfix complete!
git push origin master 

how do we keep long running feature branches up to date?

这是 rebase 面包和黄油!如果您的功能是孤立的，您可能不必进行 rebase 。也就是说，您应该尝试使您的功能尽可能简洁，因此重新调整这些功能分支的基础是一个好主意。这也意味着您正在“整合”!

git checkout master
git checkout -b long_feature master
# commit
# commit
# commit

# now to rebase!
# get latest changes from others
git fetch origin 
# update your local master branch to reference the latest from origin/master
git branch -f master origin/master
# do the rebase!
git rebase master

# repeat this cycle as often and as many times as necessary until your feature is complete

当您 rebase 时，您可能必须解决冲突。无论如何，这是你在某个阶段必须做的事情，如果你随心所欲地这样做，你可能会遇到不太复杂的冲突需要解决，因为它们是渐进的而不是“大爆炸”。