we did a little bit of branch fuckery

Use the guitar controller to branch, commit, and merge to the beat of Through The Fire And Flames and try to get a conflict-free repo.

Instead of git history, you get a git fairy tale. Practically, the merge conflicts and their resolutions get spread across one or more commits on the branch that was rebased, and the history makes it look like all the work was done after the upstream commit(s) that there was a conflict with. This can be much tidier, but also loses the context of changes. E.g. you can no longer see that something is done differently to everywhere else that does the same thing not because it needs to do it differently, but because it copied and pasted something from ten lines above and the thing ten lines above received a bug fix on another branch which the feature branch was rebased onto. Based on my experience working on large projects that used both approaches, I'd rather scroll past extra commits and squiggly branch lines than try to reconstruct what someone was thinking when they made a mistake without access to the original commit they made the mistake in. If I had to allow history-rewriting operations in git, the one I'd pick would be rewriting the history of Earth so that when history rewriting operations were implemented in git, they defaulted to adding some metadata to the rewritten commits making the operations reversible so I could decide I wanted the real history back.

It's basically like you check out the destination branch and cherry pick your changes on top of it.

I don't know if there is a functional difference between a merge and a rebase assuming your git history is reasonable, but rebasing makes the history so much easier to follow. Every commit only has a single ancestor, commits are generally better structured because devs where I work tend to squash and rebase.