我总是在执行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

我将按照开发和功能分支回答，

如果您在功能分支上，需要使用develop进行更新，请使用以下命令：

git checkout develop
git pull
git checkout feature/xyz
git merge develop

现在，您的feature/xyz已通过开发分支更新，您可以将更改推送到远程feature/xz。

这里已经有很多好答案了。我只是在添加我所做的步骤。

git fetch -p
git checkout master
git rebase origin/master
git checkout test
git rebase master

解释

gitfetch-p将检索自上次获取以来所做的任何更改，-p将修剪您的分支，删除所有过时的分支。

git checkout master签出master分支

gitrebaseorigin/master更新master分支。在这里做一次拉动会得到同样的结果。

gitcheckout测试签出您所做更改的分支

gitrebasemaster使用master上的更改更新测试分支。这将合并所有更改的文件，如果在任何提交上存在冲突，则必须解决它们，然后执行git rebase--continue或git rebase--abort

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

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

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

git push origin master

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

这是一个非常实用的问题，但上面的所有答案都不实用。

Like

git checkout master
git pull origin master
git merge test
git push origin master

这种方法有两个问题：

这是不安全的，因为我们不知道测试分支和主分支之间是否存在冲突。它会将所有测试提交“压缩”到master上的一个合并提交中；也就是说，在主分支上，我们看不到测试分支的所有更改日志。

因此，当我们怀疑会发生冲突时，我们可以执行以下git操作：

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

在提交之前测试合并，通过--no ff避免快速提交，

如果遇到冲突，我们可以运行gitstatus来检查冲突的详细信息并尝试解决

git status

一旦我们解决了冲突，或者如果没有冲突，我们就承诺并推动它们

git commit -m 'merge test branch'
git push

但这种方式将丢失记录在测试分支中的更改历史，并且会使主分支很难让其他开发人员了解项目的历史。

因此，最好的方法是我们必须使用rebase而不是merge（假设此时我们已经解决了分支冲突）。

以下是一个简单的示例，有关高级操作，请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

是的，当你完成了上层时，所有测试分支的提交都将被移动到Master分支的头上。重新定基的主要好处是可以获得线性的、更清晰的项目历史。

唯一需要避免的是：永远不要在公共分支上使用rebase，就像master分支一样。

切勿执行以下操作：

git checkout master
git rebase -i test

的详细信息https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

附录：

如果您不确定重新定基操作，请参阅：https://git-scm.com/book/en/v2/Git-Branching-Rebasing

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

开发时的通常方法是

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就在您身边。

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