如何推/拉 Git rebase

How to push/pull Git rebase

提问by Wernight

I'd like to use git rebaseso as to cleanly merge a feature in the master branch (in less commits or at least at the top of the change log). Note that I'm the only one working on the repository.

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

After reading Git workflow and rebase vs merge questions, I found git rebasewould be pretty nice and like Micah I'd like to git pushrebased changes simply because I'm working on them from different places(ex: my notebook, my home, another PC somewhere...)

在阅读了Git 工作流程和 rebase vs merge questions 之后，我发现git rebase会非常好，就像 Micah 我想重新git push调整更改只是因为我从不同的地方（例如：我的笔记本、我的家、某处的另一台 PC）处理它们。 ..)

So here are two solutions (to the bi-directional ugly merge):

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

1. Using git push -fto push, and then pulling on other machine, but how to cleanly get the latest version on other machines?
2. Using merge to merge master changes to the feature branch, git push/pull, and once mature, do a single rebase (in one or more commits cleanly)

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

(2) would be like below:

(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

Which solution do you think would work? I haven't tried either of them so far (mostly by fear of making my log more messy).

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

采纳答案by Greg Bacon

Remember that git rebasereplays changes and creates new commits. By rebasing and forcing pushes all over the place, you're going against the grain of the tool. Note how the "Recovering from an upstream rebase"section of the git rebasedocumentation begins (with added emphasis):

请记住，git rebase重播更改并创建新的提交。通过在整个地方重新定位和强制推动，您将与工具的纹理背道而驰。请注意文档的“从上游变基恢复”部分是如何git rebase开始的（特别强调）：

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream's point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.

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

Even though you're the sole developer, you'll still be others (from the perspective of one repo) when working in other clones. As you've seen, this workflow is a hassle.

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

Let your changes cook in branches. When a branch is ready for primetime, thenrebase, merge it into master, and delete its topic branch. Your life will be easiest if you keep branches' lifetimes short and their scopes narrow.

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

回答by krosenvold

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

我总是确保我从我离开的任何机器上提交和推送 (-f) 一切。

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)

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