什么时候需要git-rebase？ [英] When would one need git-rebase?

问题描述

每次我阅读git-rebase文档，我都会迷失方向。这感觉对我来说就像是一种低级操作（阅读：黑魔法）。

引用文档：

假设以下历史记录存在
且当前分支为topic：

  A --- B --- C话题
 / 
 D --- E --- F --- G master 
   
 
 $ p 
 
 
 
 
 
 
 
 
 
 
 
 
 $ p $  git rebase master 
 git rebase master topic 
  

会是：

 
 A' -  B' -  C'topic 
 / 
 D --- E --- F --- G master 
 

问题是：为什么有人想要做这样的事情呢？

首先，它似乎重写历史，好像分支从不同的角度开始;基本上提交历史将是一堆谎言。另外一点，它不安全。我尝试过一次，发生了很多冲突，并且一切都失败了。我不记得我是如何解决这个问题的，但是如果我没有记错的话，那是在一个临时测试分支或类似的东西上。

另外一个问题： strong>我是否因为不知道如何利用 git-rebase ？ $ b而缺少一些非常酷的/节省时间的功能

编辑：

相关问题：撤销git rebase

解决方案

首先，git中没有不安全的操作。 rebase有一个中止操作，并且所有的操作都会将它放到reflog中，所以你可以撤消任何操作。事实上，情况恰恰相反。

它允许您在任何时候随心所欲地提交内容，而无需进行良好构建在制作一个的路上。您可以通过压缩您一路提交的所有步骤来完成您发布的修订。

我使用rebase全部时间（通常通过我在配置阶段之后通常配置为重新绑定的拉）。不要把它看成是重写历史 - 把它想象成提供一种工具让你在发布之前清理你的草稿。

在一年现在，对于项目中的任何人来说，知道你真正开始使用 E 而不是修订 G


不必要的递归合并掩盖了历史中更重要的部分。

Everytime I read the git-rebase documentation, I get lost. It feels to me like a kind of a low-level operation (read: dark magic).

Quoting the docs:

Assume the following history exists and the current branch is "topic":

       A---B---C topic
      /
 D---E---F---G master 

From this point, the result of either of the following commands:

git rebase master 
git rebase master topic 

would be:

               A'--B'--C' topic
              /
 D---E---F---G master

The question is: Why would anyone want to do such a thing?

For one thing, it seems to "re-write" history, as if the branch started at a different point; essentially the commit history will be "a bunch of lies".

Another point, it doesn't feel safe. I tried it once, got a ton of conflicts, and all hell broke loose. I don't remember exactly how I resolved that hell, but if I recall correctly, it was on a temporary test branch or something like that.

The other question: Am I missing some really cool/time-saving set of features by not knowing how to utilize git-rebase?

EDIT:

Related question: Undoing a git rebase

解决方案

First, there are no unsafe operations in git. rebase has an abort operation, and all operations make it to the reflog, so you can undo anything. It is, in fact, quite the opposite.

It allows you to feel free to commit any time you want without having to have a "good" build while you're on the path to making one. The revisions you publish can be clean by squashing all of the steps you took along the way into a single commit.

I use rebase all the time (quite often via pull which I generally have configured to rebase after the fetch phase). Don't think of it as rewriting history -- think of it as providing a tool for you to clean up your rough draft before you publish it.

In a year from now, will it be important to anyone in your project to know that you really started this feature against revision E and not revision G?

Unnecessary recursive merges obscure the more important parts of history.

这篇关于什么时候需要git-rebase？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！