Question

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

在阅读Git workflow and rebase vs merge questions之后，我发现git rebase会非常好，就像弥迦一样，我希望git push重新定义更改只是因为我正在从不同的方面处理它们地方（例如：我的笔记本，我的家，另一台PC ......）

所以这里有两个解决方案（对于双向难看的合并）：

使用git push -f推送，然后拉动其他计算机，但如何在其他计算机上干净利落地获取最新版本？
使用merge将主更改合并到功能分支，git push / pull，并且一旦成熟，执行单个rebase（在一个或多个提交中干净利落）

（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文档的"Recovering from an upstream rebase"部分是如何开始的（更加强调）：

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

即使您是唯一的开发人员，在其他克隆中工作时，您仍然会成为其他人（从一个回购的角度来看）。如您所见，这个工作流程很麻烦。

让你的变化在分支中烹饪。当分支准备好进入黄金时段时，然后 rebase，将其合并到master中，并删除其主题分支。如果你让分支的生命周期缩短，范围缩小，你的生活将会变得最简单。

如何推/拉Git rebase

2 个答案: