Apparently it can, see here - at least this is the way I see it.
Before merge. The remote branch master
at origin
is on the left. Both branches are the same.
Now suppose both me and my friend have done some work, and my friend pushed his work first to the remote branch, and I have commited my work locally.
In this case I can't simply git push
, because that would cause commited by other
to be removed from the remote repo (I think I could do `git push -f for that, but again - that would overwrite my friend's commit).
The article suggests that git pull origin master
(which fetch
es the changes from the origin
repo's master
branch and merge
s it into my local master
branch) rewrites the history of commits in my local master
branch! How can it be? I thought a merge can only create a new merge commit, without altering the existing commits. But in this case, the commits order has changed - now the commited by other
comes first, then my local commit
.
So, knowing that pull is the same as fetch (which updates the remote-tracking branch origin/master
that is stored locally on my PC) followed by merging the updated origin/master
into the local branch master
, would it produce the same result in this case - would that merge alter the order of past commits in the local master
branch?
But in this case, the commits order has changed - now the commited by other comes first, then my local commit.
This is not true - your local commit and the "committed by other" are peers, or siblings. The new merge commit has them both as parents. Does that make sense? Your commit history is not changed in the least.
I cannot seem to access the site you posted, but the title in the url refers to merging and rebasing, and avoiding "rebase hell". Rebasing does indeed change your history; perhaps that is what the author was talking about.
Edit in response to comment: If you have A-B-C
locally and A-B-D
on the remote, after a fetch and merge your local will look like:
A--B--C--M
\--D-/
In other words, both C
and D
will have B
as a parent, and both C
and D
will be parents of M
. After you push, the remote branch will also look like this.
Now at first, you may think, "so my history does change, because B
used to have one child, and now it has two". But git does not store pointers to children, it only stores pointers to parents. And C
still has the single parent B
, so your history did not change. And since D
still has the single parent B
, the remote's history did not change either.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With