从Git合并分支

Question

我们的开发环境由dev,demo和master分支组成。我们使用JIRA来跟踪问题，每次我们开始讨论问题时，我们将分支dev，进行必要的更改，最后推出分支。

为了测试，我们首先将分支（对应于JIRA问题的名称）合并到dev中，测试它，然后合并到demo，测试它，然后合并到master。

我们遇到的问题是问题似乎在彼此建立。我可以用一个例子来最好地解释这一点：

比方说，我们有我们的典型环境，dev，demo和master。有三个问题，TEST-1,TEST-2和TEST-3。这些问题按其创建顺序完成，分支为dev，在分支上工作，然后提交并推送分支。然后我将分支合并到dev中，然后再次分支出下一个问题。

当需要推动这三个分支生存时，我们会产生意想不到的结果。为了合并这些为master，我登录到服务器的命令行1运行命令：

git fetch origin 

这将让我看到了新的分支机构。假设我们只想推动TEST-3的更改。我们运行命令：

git merge origin/TEST-3 

与仅看到第三个分支合并进来的更改相比，所有更改似乎都被拉了。所以后来，当我们最终在第一和第二期合并时，它给了我们“已经最新”的消息。

这不是我们想要的，就像这种行为一样，我们无法退出各个分支。

有什么我做错了吗？我们如何以这样一种方式来做到这一点，即允许我们为每个问题创建分支，并将它们合并成一个一个，并在需要时将这些更改拉出来。

Answer 1

正如您所描述的那样，您的工作流程应该按照您的要求工作。我可能会建议的唯一改进是使用git merge --no-ff origin/TEST-3来合并来自特定分支的工作，所以git总是在dev上创建一个合并提交，如果需要，可以稍后恢复，即使合并很简单。

您是否确定分支TEST-1,TEST-2和TEST-3是否正确创建了dev？例如，如果工作在TEST-2上的开发人员错误地创建了基于TEST-1的新分支，则合并TEST-2也会合并在分支点之前创建的所有提交TEST-1。 git checkout -b TEST-2将创建一个名为TEST-2 的分支，从当前已结算的分支开始，所以很容易意外地分支出您错误处理的最后一张票。使用类似git checkout -b TEST-3 origin/dev的内容来指定明确的起点可能会导致更少的问题。

同时，可以诊断你与git log像这样已经创造了历史：

# Show an ASCII art graph of all branch heads. Depending on the complexity 
# of your repository, this may or may not be too noisy to be useful. 
git log --oneline --decorate --graph --all 

# Graphing specific branches might be more readable: 
git log --oneline --decorate --graph dev origin/TEST-3 

# Show the commits that are reachable by TEST-3, but not by dev. 
# This tells you exactly what work you're about to merge in 
# If TEST-3 includes TEST-2 or TEST-1 by mistake, you'll see extra commits here. 
git log --oneline origin/TEST-3 ^dev 
# Or equivalently: 
git log --oneline dev..origin/TEST-3 

如果您已经有这是基于错误的起点分支的工作，你可以移动提交你想回到dev与git rebase --onto：

# I like to include the -i to see what commits I'm about to move before 
# the rebase actually happens. 
git rebase -i --onto dev TEST-3 TEST-2