Holy mao, using rebase for merge and wasting time to refix the same conflicts, and teaching other devs to do the same, that's a no go for me.
If you have to write 2 pages on a simple task maybe something is wrong, git merge is for merges, rebase and push force is for playing with fire and rescue the lost kittens :))
It's common sense if you reached - - force you screwed something.
Well, rebase is a nice tool to use, specially if you haven't pushed your branch.
About conflicts, in the rare cases where they would be recurrent, git rerere can help a lot.
Personally, I think rebase is an exceptionally useful tool however it's potential for misuse is great.
From my point of view, rebase should only be used on stuff that hasn't been pushed to a [shared] remote. There is a useful article here - daolf.com/posts/git-series-part-2/ - about that.
Consider the case where multiple developers are working on a single feature. The feature is in branch feature/j207, which was taken from branch develop. Potentially each developer could have their own branch off feature/j207, do some work, then do merges etc, but they might actually just all work directly from feature/j207, which is where rebase comes in. Let's just consider two developers for the moment, Bob and Jim.
1) Bob and Jim both clone the repo and checkout -b feature/j207
2) Bob makes a change and commits locally
3) Jim makes a change and commits locally
4) Jim makes a second change and commits locally
5) Bob makes a second change and commits locally
6) Bob pushes to the remote branch
7) Jim makes a third change and commits locally
8) Jim tries to push to the remote branch, but it's rejected due to Bob's changes having gone in
At this point Jim has two main options:
1) merge from the remote, e.g. use git pull, auto-merge, sort out conflicts across multiple commits, commit and push
2) rebase from the remote, e.g. use git pull --rebase, sort out conflicts on a commit-by-commit basis with git rebase --continue then, once complete, push
My preference is for that latter.
First of all, you avoid a merge commit that says (assuming your developers are what would appear typical in my experience) "Merge branch feature/j207 on blah into feature/j207". How useful is is it to know that you merged from a branch into another branch, in some unknown place, with the same name?
Secondly, you make the history of the branch linear, rather than having multiple branches, with the same name, being displayed on the graphical representation. As other people have mentioned, doing it this way also makes git bisect work better (I believe) when trying to track down bugs that may have been introduced during this process.
In this way you're only rewriting your local history that affects no one, other than yourself.
What's not so acceptable is rebasing feature/j207 from the current state of develop then pushing it. There's no reason why this should NEVER be done, but it's got to be done carefully, and not while multiple people are working on feature/j207.
So, in summary, there are circumstances where rebase is appropriate, and others where you need to think carefully about it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Holy mao, using rebase for merge and wasting time to refix the same conflicts, and teaching other devs to do the same, that's a no go for me.
If you have to write 2 pages on a simple task maybe something is wrong, git merge is for merges, rebase and push force is for playing with fire and rescue the lost kittens :))
It's common sense if you reached - - force you screwed something.
Well, rebase is a nice tool to use, specially if you haven't pushed your branch.
About conflicts, in the rare cases where they would be recurrent, git rerere can help a lot.
Personally, I think rebase is an exceptionally useful tool however it's potential for misuse is great.
From my point of view, rebase should only be used on stuff that hasn't been pushed to a [shared] remote. There is a useful article here - daolf.com/posts/git-series-part-2/ - about that.
Consider the case where multiple developers are working on a single feature. The feature is in branch feature/j207, which was taken from branch develop. Potentially each developer could have their own branch off feature/j207, do some work, then do merges etc, but they might actually just all work directly from feature/j207, which is where rebase comes in. Let's just consider two developers for the moment, Bob and Jim.
1) Bob and Jim both clone the repo and checkout -b feature/j207
2) Bob makes a change and commits locally
3) Jim makes a change and commits locally
4) Jim makes a second change and commits locally
5) Bob makes a second change and commits locally
6) Bob pushes to the remote branch
7) Jim makes a third change and commits locally
8) Jim tries to push to the remote branch, but it's rejected due to Bob's changes having gone in
At this point Jim has two main options:
1) merge from the remote, e.g. use git pull, auto-merge, sort out conflicts across multiple commits, commit and push
2) rebase from the remote, e.g. use git pull --rebase, sort out conflicts on a commit-by-commit basis with git rebase --continue then, once complete, push
My preference is for that latter.
First of all, you avoid a merge commit that says (assuming your developers are what would appear typical in my experience) "Merge branch feature/j207 on blah into feature/j207". How useful is is it to know that you merged from a branch into another branch, in some unknown place, with the same name?
Secondly, you make the history of the branch linear, rather than having multiple branches, with the same name, being displayed on the graphical representation. As other people have mentioned, doing it this way also makes git bisect work better (I believe) when trying to track down bugs that may have been introduced during this process.
In this way you're only rewriting your local history that affects no one, other than yourself.
What's not so acceptable is rebasing feature/j207 from the current state of develop then pushing it. There's no reason why this should NEVER be done, but it's got to be done carefully, and not while multiple people are working on feature/j207.
So, in summary, there are circumstances where rebase is appropriate, and others where you need to think carefully about it.