从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中，希望尽可能保持时间线的线性。
我将首先使要合并的分支尽可能干净。运行测试，确保状态符合您的要求。通过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
正如标题所说的“最佳方式”，我认为考虑耐心合并策略。
发件人：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
