Re: About "git rebase"

[Christof Thalhofer <chrisml@xxxxxxxxxxx>]

Am 11.09.24 um 14:31 schrieb Benoît Minisini:

> I have just read an article about "git rebase". This command can be 
> useful to synchronize a local branch to the master when you are doing a 
> long development, or if you want to avoid too many non-informative merge 
> commits.
>
> But it is a powerful command as it can copy any piece of the commit tree 
> on another place, hiding the original, and so you can break your 
> repository if you are not careful enough...

git rebase packs the own commits (which were not pushed) aside, then 
fetches the new commits from the repository and after that puts the own 
commits on top of it.

If something breaks, the local git repo is in a special state "rebasing" 
(if I remember correctly) which you can rewind with

git rebase --abort

I often see that if do 'git pull' (which equals to 'git fetch;git 
merge') conflicts I can abort it with

git merge --abort

and then try to do a 'git rebase'. And this usually solves the merge 
problem.

So I find 'git rebase' often to be more robust than 'git merge' when I 
fetch changes from a public repo into my own.

But: 'git rebase' changes the order of the commits and must therefore 
never be used on a public shared repository because when others pull 
from this public repo (changed with rebase), the order of commits of 
their own copies will no longer match that of the public one and that 
causes a lot of trouble.

Alles Gute

Christof Thalhofer

--
[x] nail here for new monitor