Reputation: 15861
I wonder how git rebase helps reverting changes. I cannot understand why rebase is easier than merging for reverting changes.
Reverting a change I mean, reverting a previous version of master.
At this point I want to revert to Master v4
for example.
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:
a
from masterb
from mastera
b
a
into master with merge [tag-a]b
into master with merge [tag-b]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
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
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
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