16

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

在阅读了 Git 工作流和变基与合并问题之后，我发现git rebase这会非常好，就像 Micah 一样，我想重新git push基基更改只是因为我正在从不同的地方处理它们（例如：我的笔记本、我的家、某处的另一台 PC。 ..)

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

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

(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

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

4

2 回答 2

13

I always make sure I commit and push (-f) everything from any machine I leave.

When I arrive at some other machine:

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

This works well because I know the other "me" at different computers consistently commits and pushes before I leave (And therefore there are no unpushed changes on the machine I arrive at)

于 2010-02-08T06:56:06.597 回答
11

请记住，git rebase重放更改并创建新提交。通过在所有地方重新设置和强制推送，你违背了工具的本质。请注意文档的“从上游变基中恢复”部分是如何git rebase开始的（特别强调）：

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

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

让您的更改在分支中烹饪。当一个分支准备好进入黄金时段时，然后变基，将其合并到 master 中，并删除其主题分支。如果你保持分支的生命周期很短并且它们的范围很窄，你的生活将是最轻松的。

于 2010-02-08T05:01:19.543 回答