Tobias is trying to convert/rebase me to the git church of rebase:
rebasing topic onto master
A---B---C topic
/
D---E---A'---F master
results in
B'---C' topic
/
D---E---A'---F master
which then allows you to merge topic into master and get a nice linear gitgraph. (With the caveat that if you have a remote topic, you need to force push after a rebase because you’ve edited the git history of topic, and the further caveat that if 2 people are working on topic at the same time, you don’t do this without communication)
I asked about the situation where I had merged from master into topic at some point:
https://stackoverflow.com/a/4784082
By default, a rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch.
Rebase is essentially an easier way to reset your git history and re-commit all your changes.
It’s nice for branches that have either A) very few commits, or B) only changes entirely unrelated to commits on the main branch. If you have a lot of commits and a lot of potential conflicts, a merge would be better. With the border between the two depending on how pedantic and patient you are.
Outside of not rebasing, one thing I am doing that’s ugly: merging master into topic, checking everything is ok, then merging topic into master. You end up with monster merges that show all the changes from master that weren’t in topic at the time of merge.
Solution is when it’s time to merge, you create a branch from master, merge into that from topic, if all is well you can merge your new branch back into master.