Although rebase is not a complicated concept itself, many people have trouble understanding it.
I believe this is mostly because people new to git...
For further actions, you may consider blocking this person and/or reporting abuse
Bob can actually do this to fix it:
git checkout -b feature-bob- creates a new branch from the existing feature branch for Bob, with his changesgit checkout feature- go back to the original branchgit fetch origin- fetch changes from remote after the rebasegit reset --hard origin/feature- resets Bob's currentfeaturebranch to be identical with remote'sgit checkout feature-bob- go back to Bob's branchgit rebase feature- include your changes into his branchBob now keeps working on his feature branch and just rebases on top of yours. That way you can work on the same feature, but still do your own rebase.
From the Bob's local
featurebranch, he can accomplish all this with just:git pull --rebase origin featureI use
pull --rebaseall the time when I don't want a merge commit every time I pull down from the public branch. Simply replays my local commits on top of the remote head.Yeah I was going to mention this in the fetch flow.
It actually makes collaborating with rebase completely acceptable as long as you never merge which I think may work at times too.
Hello Dalibor,
This solution would fit the "no nice way for him to fix this situation" category in my opinion :)
Rebase is a nice trick, but not a real workflow:
Just pull and merge, it's ok. Don't lie to git's history.
Saying that rebase is not a real workflow is relative. It will depend on what level you are rebasing things. Although it might not be the best option when you do not put your work in separate branches and instead commit everything to the default branch, I can say that rebasing makes your git history much cleaner. So a good approach in my opinion is when you work in separate branches and use rebase on those to clean history a little bit and then after that you merge to the default branch, which should give you merge commits, which believe me can be really helpful.
Git push --force-with-lease
That is a slightly safer push, wish the command was shorter.
Using git to communicate, I believe requires rebase.
Git is a Communication tool
Jesse Phillips
It depends on how you work. If your branch is only being worked on by you and/or your team, just communicate before you git push -f it, so everyone will be up to date afterwards. If that doesn't work for you, merge and silently cry about your ugly git history.
Hello Roger,
I wouldn't call rebase a "trick". It's a git command like any other.
Whether you'll use it depends on your(team's) workflow.
If the two commits of the feature branch have conflicts with the new one in
master, I'll have to resolve conflicts twice, which is even worse if there are more. This is what I normally do:This is what I do when working in a feature branch + PR workflow, what do you think?
Hy David,
Yes, this happens because during rebase git re-applies the commits (from feature branch in this case), so if you have conflicts on some commit, you must resolve them before git can try to re-apply the next commit. And if you have conflicts on every commit than you'll have to do it fore every of those commits.
Your workflow helps you avoid that "multiple" conflict resolution but you lose you commits granularity since they all get squashed into a single commit.
Only one thing - checkout interactive rebase, it's a cool feature and could help you combine a message for your squashed commits.
Exactly, but I actually prefer to have a single commit for a feature, while I like to have the whole commit history of my branch while I'm working on it, so yeah, interactive rebase is a good choice for that :)
I need to evaluate more cases, but if each commit conflicts, you don't eliminate any merge conflict by squashing. You'll just get one big collection of conflicts to deal with.
I'll have to admit that I rarely use rebase. I don't mind the "messier" git history, as as far as I am concerned it is a true history.
On top of that, I am of the "commit early, commit often" mindset and hand in hand with that is "push your branch to origin often IN CASE OF FIRE".
And since I instilled this in my team as well, our branches are pushed up public often, which is exactly the scenario one should not be rebasing from.
So it works out for us just fine.
Vim has the true history which is actually really helpful during initial changes. But I don't commit my vim history to git, I have a different goal when I commit.
Git is a Communication tool
Jesse Phillips
Thanks for explaining rebasing! :D
Where we're going, we don't need old commit ids.
But seriously, you combined one of my favorite movies with my favorite git command. Nailed it!
Really well explained!
I don't suggest using rebase because if that red node on master removes some dependencies and functions that you actually need in those purple nodes, your commits won't build.
That is fair I suggest using commit --fixup to get the solution to the right commit. You still need to make a solution on merge.