我们的开发环境包含dev，demo和master分支。我们使用JIRA来跟踪问题，每次我们开始问题时，我们都会分支dev，进行必要的更改，最后推出分支。
为了进行测试，我们首先将分支（对应于JIRA问题的名称）合并到dev，测试它，然后合并到demo，测试它，然后合并到{{1 }}
我们遇到的问题是这些问题似乎是相互依赖的。我最好用一个例子解释一下：
假设我们拥有典型的环境master，dev和demo。有三个问题，master，TEST-1和TEST-2。问题按照创建顺序完成，分支TEST-3，分支，然后提交和推送分支。然后我将分支合并到dev，然后再次分支出来进行下一个问题。
当需要将这三个分支推出时，我们会有意想不到的结果。为了将这些合并到dev，我登录服务器的命令行并首先运行命令：
master这将允许我看到新的分支。假设我们只想推送git fetch origin
的更改。我们运行命令：
TEST-3而不是只看到第三个分支的变化被合并，所有的变化似乎都被拉了。所以后来，当我们最终在第一和第二个问题中合并时，它给我们提供了“已经是最新的”消息。
这不是我们想要的，因为这种行为，我们无法退出各个分支。
我有什么问题吗？我们怎样才能以这样一种方式做到这一点，即允许我们为每个问题创建分支，并将它们一次合并为一个，如果需要，可以将这些变更拉出来。
答案 0 :(得分：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
如果您已经在基于错误起点的分支上工作，则可以使用git rebase --onto将您想要的提交移回dev：
# 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