从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
完成。
这里已经有很多好答案了。我只是在添加我所做的步骤。
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
这是一个非常实用的问题，但上面的所有答案都不实用。
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 squash清理新提交。
除了克朗彻国王的回答，我建议使用
git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master
您可能在另一个分支中进行了多次提交，而在主分支中应该只有一次提交。为了尽可能保持提交历史记录的干净，您可能希望将测试分支中的所有提交压缩到主分支中的一个提交中（另请参阅：Git：压缩还是不压缩？）。然后，您还可以将提交消息重写为非常有表达力的内容。易于阅读和理解的内容，无需深究代码。
编辑：你可能对
在git中，merge-squick和rebase之间有什么区别？合并与再贴现如何重新估价拉取请求
因此，在GitHub上，我最终为一个功能分支mybranch执行了以下操作：
从原点获取最新信息
$ git checkout master
$ git pull origin master
查找合并基哈希：
$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f
$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f
现在确保只有第一个是pick，其余的是s：
pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better
接下来选择一个非常好的提交消息并推送到GitHub。然后提出拉动请求。
合并拉取请求后，您可以在本地删除它：
$ git branch -d mybranch
和GitHub上
$ git push origin :mybranch
