Say you have made one commit, changing two files. In the mean time on master there had been 5 additional commits. To make this easily mergeable you can 'pretend' you applied those two changes after the 5 new commits.
When non of those files where changed in the other 5 commits this will go fine. When there where changes made, there is a conflict and you need to merge you commit that's applied again, with the new commits.
Your rewriting history in such a way that the commits are not ordered strictly in time, but when they where about to be merged.
If you do this before ever merge you get a flat history that is easy to follow.
You can also do some other fancy stuff while rebasing, like changing the commit message, merge multiple commits to one, or skip a commit.
These things will bother make it easier to review a pr, because it's much clearer what you changed compared to a pr with a lot of merges in it, and will keep master cleaner.
I mostly use IntelliJ to rebase, it makes resolving conflict very easy.
Thank you @gklijs
for the detailed reply. So when you "pretend" you applied those two changes after the 5 new commits, does it actually do it, or is it only a dry-run? I guess I will need to test this out for myself to really understand how it works..but your explanation helped, I'll come back to this for reference :)
Be sure to push your branch to your fork before you start rebasing. In that case you can always restore the branch in case something goes wrong. After the rebase, make sure all the tests run, and your code (those two changes) are still there. If it's all good you can force pushgit push -f your local branch to your fork.
If you do it like that there no risk losing something. You shouldn't work with multiple people on the same remote branch, because then there is a risk of losing stuff. Ideally features are small enough to be done by one person. In case you do need to work together on the same branch, and still like to rebase, each person should work in it's own forked branch, and can rebase on the other fork when needed.
Say you have made one commit, changing two files. In the mean time on master there had been 5 additional commits. To make this easily mergeable you can 'pretend' you applied those two changes after the 5 new commits.
When non of those files where changed in the other 5 commits this will go fine. When there where changes made, there is a conflict and you need to merge you commit that's applied again, with the new commits.
Your rewriting history in such a way that the commits are not ordered strictly in time, but when they where about to be merged.
If you do this before ever merge you get a flat history that is easy to follow.
You can also do some other fancy stuff while rebasing, like changing the commit message, merge multiple commits to one, or skip a commit.
These things will bother make it easier to review a pr, because it's much clearer what you changed compared to a pr with a lot of merges in it, and will keep master cleaner.
I mostly use IntelliJ to rebase, it makes resolving conflict very easy.
Thank you @gklijs for the detailed reply. So when you "pretend" you applied those two changes after the 5 new commits, does it actually do it, or is it only a dry-run? I guess I will need to test this out for myself to really understand how it works..but your explanation helped, I'll come back to this for reference :)
Be sure to push your branch to your fork before you start rebasing. In that case you can always restore the branch in case something goes wrong. After the rebase, make sure all the tests run, and your code (those two changes) are still there. If it's all good you can force push
git push -fyour local branch to your fork.If you do it like that there no risk losing something. You shouldn't work with multiple people on the same remote branch, because then there is a risk of losing stuff. Ideally features are small enough to be done by one person. In case you do need to work together on the same branch, and still like to rebase, each person should work in it's own forked branch, and can rebase on the other fork when needed.
Thank you for the tips! Much appreciated!