CODEWITHSUNDEEP
gitmergerebasegit-revert
Totty.js
Totty.js

Reputation: 15861

Use git rebase because is easier to revert changes?

I wonder how git rebase helps reverting changes. I cannot understand why rebase is easier than merging for reverting changes.

Update 1:

Reverting a change I mean, reverting a previous version of master.

At this point I want to revert to Master v4 for example.

Update 2:

When I mean helps I don't mean that you revert using rebase or merge.

I will explain better what my colleague said:

For example you have this log:

He says that is more difficult to revert because the commits are not all grouped together. But to me makes no sense, if you revert one tag, let's say [tag-a], master doesn't have the changes from branch b. I also don't care about when the commits on branch b has been made, even if they are interlaced (in time) with the commits in branch a. Or I'm missing a really big point in how git works...

When I revert to [tag-a] I don't really care how many commits have been done in master, I just get what master was at the [tag-a], simple, independently by how many commits and when they have been made.

Thanks

Upvotes: 4

Views: 552

Answers (3)

Tonio
Tonio

Reputation: 1566

Actually, in that case, you probably want neither rebase nor merge. Depending on the use case, you want either git revert, or git reset.

Revert will allow you to create one or more commits that revert the changes introduced in one or more commits. Reset will essentially remove the commits from history.

In the case you described, you can either git revert the change introduced in v5, creating a new commit that reverses those changes, or you can git reset --hard to v4, which will remove the commit v5 from the history.

Both have advantages and disadvantages, and should be used in different cases for different reasons. For example, if the branch is public, and being worked on by multiple developers, you want to avoid git reset --hard, since that will mess up any commits other developers may have made based off v5. On the other hand, if you're working locally, and simply decided to abandon any work you had started on v5, then introducing a commit to reverse that change (with git revert) will only introduce noise into the branch's history.

You can read up more on git revert, and on git reset on git's web site.

Edit:

Hm, it seems I misunderstood your question... you're asking why it's easier to revert to an old state when you've been using rebase rather than merge to bring in feature branches.

If that's the case, then Dmitriy M's answer explains why: a branch which is rebased onto is linear, while one that is merged onto is more complex, so finding out which commit(s) to revert, or reset to, is simpler.

On the other hand, if what you're really trying to do is undo bringing in a branch into master, it's easier to figure out which commit to reset to if you've been merging rather than rebasing, especially if you use merge --no-ff, since you can simply look for the merge commit that brings in the branch (which should read something like "Merge branch XXX onto master"), and reset to its parent on the master side. For example, if you want to undo bring in the branch feature-a into master, and the merge commit, which reads "Merge feature-a into master" has a hash starting with 87db280, then you can just git reset 87db280^, or git reset 87db280~1.

Upvotes: 1

Dmitriy M
Dmitriy M

Reputation: 427

When rebasing - the tree is more straight without unnecessary "branches" (by branches I mean literaly branches on the structure of the commits tree, not "git branch") and it makes it easier to find a certain stage to revert to. When lots of people work with one repo merging it every time creates a veeeery complicated tree structure.

Upvotes: 3

Hui Chen
Hui Chen

Reputation: 131

Rebase will keep history of commits from both paths (shown as one set on top of the other set). Merge will lose the history of one of the two paths.

Upvotes: -3

Related Questions