从master创建一个新分支，我们称之为test。
有几个开发人员要么提交到master，要么创建其他分支，然后合并到master。
假设测试工作需要几天的时间，您希望通过master内部的提交不断更新测试。
我会从测试中提取原始主机。
问题1：这是正确的方法吗？其他开发人员可以像我一样轻松地处理相同的文件。
我的测试工作已经完成，我已经准备好将其合并回master。以下是我可以想到的两种方法：
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
我没有使用--rebase，因为根据我的理解，rebase将从master获取更改，并将我的更改叠加在上面，因此它可能会覆盖其他人所做的更改。
问题2：这两种方法中哪一种是正确的？有什么不同？
所有这一切的目标是让我的测试分支随着master中发生的事情而更新，然后我可以将它们合并到master中，希望尽可能保持时间线的线性。
旧线程，但我还没有找到我的方法。对于使用rebase并希望在master上合并（feature）分支的所有提交的人来说，这可能很有价值。如果途中发生冲突，您可以为每次提交解决冲突。您在过程中保持完全控制，可以随时中止。
获取Master和Branch的最新信息：
git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>
合并主节点顶部的分支：
git checkout <branch_name>
git rebase master
可选：如果您在回扣期间遇到冲突：
首先，解决文件中的冲突。然后：
git add .
git rebase --continue
您可以随时使用以下方法中止重新基准：
git rebase --abort
推送您的重新基础分支：
git push origin <branch_name>
如果之前已推送此分支，则需要使用强制推送来覆盖它：
git push origin -f <branch_name>
在执行此操作之前，请始终检查当前本地分支是否符合您的期望，因为强制推送会覆盖远程存储库中的旧分支。
现在您有两个选项：
A） 创建PR（例如在GitHub上）并通过UI将其合并B） 返回命令行并将分支合并到主节点
git checkout master
git merge --no-ff <branch_name>
git push origin master
完成。
正如标题所说的“最佳方式”，我认为考虑耐心合并策略。
发件人：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
