在承诺保持历史清洁之前，是否有必要将更改从 master 变基到分支
Is it neccessary to rebase changes from master into branch before committing to keep history clean
我有一个关于在使用 git 变基时保持 git-历史记录干净的问题。
我遇到了以下问题：
我有以下历史，由项目的其他人制作：
m0 - m1 - m2 - m3
\- b1 - b2
现在我想将更改变基到母版中，所以我学到的是，你使用
git 变基大师
git结帐大师
git合并分支
一切顺利。主人现在有了分支的变化，反之亦然。
所以我推了大师，太棒了。我想推送分支，发现遥控器设置了禁止非快进推送的标志。
在我犯了一些其他问题和错误之后，我通过删除分支并创建一个新分支来解决问题，其中包含来自 master 的提交。
现在我的问题是：...当想要使用 rebase 时，正确的做法是什么...任何分支的每个用户是否总是需要做
git stash
git fetch
git rebase origin/master
git stash pop
在提交之前，保持git-历史干净，这样前面描述的问题就不会发生了？
在我看来，这对 git 项目中的其他用户（也许是初学者）来说有点难以承受。一旦一个人忘记在分支内提交更改之前对 origin/master 进行变基，整个 git-历史将不再干净，对吗？
那么正确的做法是什么？如何在项目中正确使用rebase？
因为我看到的是，一旦来自 master 的更改在提交之前没有重新定位到分支中，它总是会发生，历史看起来像这样：
m0 - m1 - m2 - m3 - b1 - b2
\- m1 - m2 - m3 - b1 - b2 //<-----PUSH-Problems, since history changed!
谁能澄清我对git rebase 的误解？如果有的话？
因为根据我的理解，一旦有多个人在一个项目上工作，就立即使用 git rebase 是一个坏主意。
如果问题不够清楚：我要的是
的一些有代表性的例子
- 解决远程禁止非快进推送时描述的问题
- 当超过 3 或 4 个人在一个项目和一个分支上工作时使用分支和变基的典型方法
编辑：也许我应该澄清一下我们需要使用远程分支，因为多人在一个 feature/one 分支上工作
经过更多研究后我注意到，我似乎误解了 rebase 的用法。
简而言之，Rebase 用于将您的本地更改添加到 public 分支（或主分支）而不创建不相关的合并提交。它不是一个工具，应该完全取代合并。
本文介绍了使用 rebase 的典型工作流程：
https://www.randyfay.com/node/91
总之，您（显然）永远不想直接在 base-branch 上工作。当向项目添加内容时，例如向工具的功能添加内容（public 分支 featureX），您创建自己的本地分支（针对所述功能的错误修复，或添加功能，这是功能的一部分) 并提交给这个分支。
然后当你完成后，你将基础分支变基（而不是合并）到你的本地分支，创建一个日志，它只是将你的提交添加到基础分支的后面。
然后，当将基础分支与本地分支合并时，它只是将头部快进到本地分支的末尾，并且你有一个包含所有提交的漂亮行。
所以rebase只能用于本地分支！而不是 public 分支机构，多个人在其中工作。因为那会导致我在问题中描述的问题。建议说使用 "git push --force" 或类似的建议只应在非常依赖情况的问题中使用，但不在这里！
我有一个关于在使用 git 变基时保持 git-历史记录干净的问题。
我遇到了以下问题： 我有以下历史，由项目的其他人制作：
m0 - m1 - m2 - m3
\- b1 - b2
现在我想将更改变基到母版中，所以我学到的是，你使用 git 变基大师 git结帐大师 git合并分支
一切顺利。主人现在有了分支的变化，反之亦然。 所以我推了大师，太棒了。我想推送分支，发现遥控器设置了禁止非快进推送的标志。 在我犯了一些其他问题和错误之后，我通过删除分支并创建一个新分支来解决问题，其中包含来自 master 的提交。
现在我的问题是：...当想要使用 rebase 时，正确的做法是什么...任何分支的每个用户是否总是需要做
git stash
git fetch
git rebase origin/master
git stash pop
在提交之前，保持git-历史干净，这样前面描述的问题就不会发生了？ 在我看来，这对 git 项目中的其他用户（也许是初学者）来说有点难以承受。一旦一个人忘记在分支内提交更改之前对 origin/master 进行变基，整个 git-历史将不再干净，对吗？ 那么正确的做法是什么？如何在项目中正确使用rebase？
因为我看到的是，一旦来自 master 的更改在提交之前没有重新定位到分支中，它总是会发生，历史看起来像这样：
m0 - m1 - m2 - m3 - b1 - b2
\- m1 - m2 - m3 - b1 - b2 //<-----PUSH-Problems, since history changed!
谁能澄清我对git rebase 的误解？如果有的话？ 因为根据我的理解，一旦有多个人在一个项目上工作，就立即使用 git rebase 是一个坏主意。
如果问题不够清楚：我要的是
的一些有代表性的例子- 解决远程禁止非快进推送时描述的问题
- 当超过 3 或 4 个人在一个项目和一个分支上工作时使用分支和变基的典型方法
编辑：也许我应该澄清一下我们需要使用远程分支，因为多人在一个 feature/one 分支上工作
经过更多研究后我注意到，我似乎误解了 rebase 的用法。 简而言之，Rebase 用于将您的本地更改添加到 public 分支（或主分支）而不创建不相关的合并提交。它不是一个工具，应该完全取代合并。 本文介绍了使用 rebase 的典型工作流程： https://www.randyfay.com/node/91 总之，您（显然）永远不想直接在 base-branch 上工作。当向项目添加内容时，例如向工具的功能添加内容（public 分支 featureX），您创建自己的本地分支（针对所述功能的错误修复，或添加功能，这是功能的一部分) 并提交给这个分支。 然后当你完成后，你将基础分支变基（而不是合并）到你的本地分支，创建一个日志，它只是将你的提交添加到基础分支的后面。 然后，当将基础分支与本地分支合并时，它只是将头部快进到本地分支的末尾，并且你有一个包含所有提交的漂亮行。
所以rebase只能用于本地分支！而不是 public 分支机构，多个人在其中工作。因为那会导致我在问题中描述的问题。建议说使用 "git push --force" 或类似的建议只应在非常依赖情况的问题中使用，但不在这里！