如何推/拉 Git rebase

Question

我想使用 git rebase 来干净地合并 master 分支中的功能（减少提交或至少在更改日志的顶部）。请注意，我是唯一一个在存储库上工作的人。

阅读 Git 工作流程和 rebase 与合并问题后，我发现 git rebase 会非常好，就像 Micah 一样，我想 git Push 重新调整更改的基础，只是因为我正在从不同的地方处理它们（例如：我的笔记本，我的家，某处的另一台电脑...）

所以这里有两个解决方案（双向丑陋的合并）：

1. 使用 git push -f 推送，然后在其他机器上拉取，但是如何在其他机器上干净地获取最新版本呢？
2. 使用 merge 将主更改合并到功能分支，git 推/拉，一旦成熟，就进行一次变基（干净地在一个或多个提交中）

（2）如下所示：

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

您认为哪种解决方案可行？到目前为止我还没有尝试过其中任何一个（主要是担心让我的日志更加混乱）。

Answer 1

我总是确保我从我离开的任何机器上提交并推送（-f）所有内容。

当我到达其他机器时：

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

这很有效，因为我知道不同计算机上的另一个“我”在我离开之前一致地提交和推送（因此我到达的机器上没有未推送的更改）

Answer 2

请记住，git rebase 会重播更改并创建新的提交。通过在各处重新设置基础并强制推动，您将违背工具的原则。请注意“从上游变基恢复”git rebase 文档的 > 部分开始（特别强调）：

重新定位（或任何其他形式的重写）其他人基于工作的分支是一个坏主意：它下游的任何人都被迫手动修复其历史记录。本节从下游的角度解释如何进行修复。 然而，真正的解决办法是首先避免对上游进行变基。

即使您是唯一的开发人员，在工作时您仍然是其他人（从一个存储库的角度来看）在其他克隆中。正如您所看到的，这个工作流程很麻烦。

让你的改变在分支中进行。当一个分支准备好进入黄金时段时，然后变基，将其合并到 master 中，并删除其主题分支。如果你缩短分支的生命周期并缩小它们的范围，你的生活将会变得最轻松。