这是我在团队工作中使用的工作流。场景如您所述。首先，当我完成测试工作时，我与master重新建立了基础，以便在我进行测试分支的过程中提取添加到master的任何内容。

git pull-r上游主机

这将从您分叉测试分支开始将更改拉到master并应用它们，然后将您所做的更改应用到“在”当前master状态的顶部进行测试。如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。如果存在，则必须手动修复并提交。完成后，切换到主分支并合并测试将很好，不会出现任何问题。

git checkout master
git pull origin master
# Merge branch test into master
git merge test

合并后，如果文件发生了更改，则在合并时将出现“解决冲突”错误

因此，您需要首先解决所有冲突，然后再次提交所有更改，然后推送

git push origin master

这是更好的做法，谁在测试分支中做了更改，因为他知道自己做了什么更改。

我会使用rebase方法。主要是因为它在语义上完美地反映了您的情况，即您要做的是刷新当前分支的状态，并“假装”它是基于最新的。

所以，我甚至不需要检查master，我会：

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

当然，仅从原点获取不会刷新主机的本地状态（因为它不会执行合并），但这完全符合我们的目的-为了节省时间，我们希望避免切换。

重新基准和合并都不应覆盖任何人的更改（除非您在解决冲突时选择这样做）。

开发时的通常方法是

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

当你准备好合并回master时，

git checkout master
git log ..test # if you're curious
git merge test
git push

如果您担心在合并过程中出现问题，gitmerge--abort就在您身边。

使用推拉合并是愚蠢的。我也不确定你为什么要把测试推向原点。

我总是在执行git合并功能分支时遇到合并冲突。这似乎对我有用：

git checkout -b feature-branch

进行一系列代码更改。。。

git merge -s ours master 

git checkout master

git merge feature-branch

or

git checkout -b feature-branch

进行一系列代码更改。。。

git checkout master

git merge -X theirs feature-branch

正如标题所说的“最佳方式”，我认为考虑耐心合并策略。

发件人：https://git-scm.com/docs/merge-strategies

使用此选项，“merge recursive”会花费一点额外的时间来避免由于不重要的匹配行（例如，不同函数的大括号）而有时发生的错误合并。当要合并的分支出现严重分歧时，请使用此选项。另请参见gitdiff[1]——耐心。

用法：

git fetch
git merge -s recursive -X patience origin/master

Git别名

我总是为此使用别名，例如运行一次：

 git config --global alias.pmerge 'merge -s recursive -X patience'

现在你可以做到：

git fetch
git pmerge origin/master