读完这篇文章后，rebase 将更改从主分支收集到我的功能分支是有意义的： Git workflow and rebase vs merge questions
clone the remote repo
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature
如果功能分支位于我的机器本地并且我可以随意重写历史记录，这将非常有用。
但是，如果我在功能分支上与其他人合作怎么办。既然我们的功能分支保存在远程存储库中，我们如何从主分支获取最新更改到我们的功能分支？
所以我们合并？还是有另一种巧妙的 GIT 方法来做到这一点？
提前致谢！
您的情况有解决方案，无需切换到完全不同的工作流程。
正如您已经发现的那样，关于从主分支获取修复到功能分支，最好的办法是挑选那些特定的提交。但我更喜欢为修补程序设置主题分支，而不是在主线中修复，这样我就可以将这些修补程序正确地合并到它们阻止的每个功能中。
为了尽可能保持功能开发历史的简洁和线性，所有协作者都必须使用它git pull --rebase来获取更新，这样就不会出现无意义的合并提交。
如果您仍想在当前主要开发分支上重新设置协作功能分支（用于持续集成测试或其他目的）或以任何其他方式重写其历史记录，您可以在功能完成/完成后，就在合并到之前执行此操作主分支，但你应该在一个新的单独的本地/私有分支中进行。
以下是如何在 master 的新分支中重新创建您的主题更改（跳过樱桃选择）：
$ git checkout -b feature_final feature # jump to a new branch for grooming
$ git rebase [-i] master # rebase topic changes onto master
从那里你决定如何处理重新定位的分支 - 向上游推送 QA 或直接合并到 master（如果你想在历史中明确表示，可以使用 --no-ff ）。
如果你一个人工作，rebase 什么都不做。您没有向 master 提交任何新内容。
您的合并将是一个快进合并，您可以通过根本不检查它来做到这一点
git push . HEAD:master
无论您是否与某人一起工作，将 master 中的工作合并到您的功能分支中都是一种不好的做法。它被称为反向合并。它不好的原因是你现在没有一个原子的工作。master 的历史现在与你的特性纠缠在一起，使得使用这个特性，比如 rebase，在很多情况下是不可能的。
您需要考虑您的分支策略以及您想要实现的目标。这是我的：
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
可以看到每个分支都是从同一个地方开始的。您有一个单独的集成分支和发布候选分支来混合和匹配您想要的功能，同时不污染它们。
至于与同事合作开发一个功能，这取决于一个功能有多大（您工作的粒度）。如果它很大，您可以将上述过程应用于功能本身并改为按任务分支。
如果它是一个小功能，您可以在该分支上合并或变基 - 这并不重要。在这一点上，它归结为团队对什么感到满意。