【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
从master创建了一个新分支，我们称之为test 。
有几个开发人员要么致力于master要么创建其他分支，然后合并成master 。
假设test工作需要花费几天的时间，并且您希望通过master内的提交来不断更新test 。
我会做git pull origin master从test 。
问题1：这是正确的方法吗？ 其他开发人员可以像我一样轻松地处理相同的文件。
我的test工作已经完成，我准备将其合并回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：这两种方法中哪一种是正确的？ 有什么区别？
所有这一切的目的是使我的test分支随时master发生的事情，然后我可以将它们合并回master以期使时间轴尽可能保持线性。
#1楼
这是一个非常实际的问题，但是以上所有答案都不实际。
喜欢
git checkout master
git pull origin master
git merge test
git push origin master
这种方法有两个问题 ：
这是不安全的，因为我们不知道测试分支和主分支之间是否存在任何冲突。
它将“压缩”所有测试提交到主控上的一个合并提交中。 也就是说，在主分支上，我们看不到测试分支的所有更改日志。
因此，当我们怀疑会有一些冲突时，我们可以执行以下git操作：
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
commit前测试merge ，避免使用--no-ff快速提交，
如果遇到冲突，我们可以运行git status来检查有关冲突的详细信息并尝试解决
git status
一旦解决了冲突，或者如果没有冲突，我们就会commit并push它们
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
是的，完成鞋面后，所有Test分支的提交都将移至Master分支的头部。 变基的主要好处是，您可以获得线性且清晰得多的项目历史记录。
您唯一需要避免的是：永远不要在公共分支（如master分支）上使用rebase 。
切勿执行以下操作 ：
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
#2楼
git checkout master
git pull origin master
# Merge branch test into master
git merge test
合并后，如果文件已更改，则合并时将出现“解决冲突”错误
因此，您首先需要解决所有冲突，然后再次提交所有更改，然后再按
git push origin master
谁在测试分支中做过更改，这样做会更好，因为他知道自己做了什么更改。
#3楼
这是我在团队工作中使用的工作流程。 该场景如您所描述。 首先，当我完成test工作时，我以master为基础进行基础工作，以提取我在test分支工作期间添加到master中的所有内容。
git pull -r upstream master
自从您分支test分支并应用它们以来，这会将更改拉到master上，然后应用所做的更改来“在master的当前状态之上”进行测试。 如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。 如果有，您将必须手动修复它们并提交。 完成此操作后，最好切换到master分支并合并test ，不会出现任何问题。
#4楼
我首先要使要合并的分支尽可能干净。 运行测试，确保状态为所需状态。 通过git squash清理新提交。
除了KingCrunches答案 ，我建议使用
git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master
您可能在另一个分支中进行了多次提交，而这些提交仅应在master分支中进行了一次提交。 为了使提交历史记录尽可能整洁，您可能希望将所有来自test分支的提交压缩为master分支中的一个提交（另请参见： Git：压扁还是不压扁？ ）。 然后，您也可以将提交消息重写为非常具有表现力的内容。 无需深入了解代码即可轻松阅读和理解的内容。
编辑：您可能对
因此，在GitHub上，我最终对功能分支mybranch执行了以下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
#5楼
我会使用rebase方法。 主要是因为它在语义上完美地反映了您的情况，即。 您想要做的是刷新当前分支的状态，并“假装”它好像是基于最新分支。
因此，即使不签出master ，我也会：
git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here
当然，仅从原点获取不会刷新master的本地状态（因为它不执行合并），但这完全可以满足我们的目的-为了节省时间，我们希望避免切换。
来源：oschina
链接：https://my.oschina.net/stackoom/blog/3149142