How I learned I had been using git branches the wrong way for 2 years

I was at a meetup in Austin last summer and this guy looked over my shoulder while I was merging something. He asked why I was always merging master into my feature branch instead of rebasing, and I had no good answer. I literally thought merging was the only way to keep branches updated (you know, like a dummy). After he showed me rebase -i I felt like I had wasted so much time on messy commit histories. Has anyone else had that moment where a simple tip from a stranger just flipped your whole approach?

2 comments

2 Comments

grayw325d ago

Austin in July, that must have been a sweatbox. I gotta say though, I actually disagree with the rebase-everything crowd. I've been using git for 6 years and I still merge master into my feature branch on purpose. The rebase fanatics talk like a clean history is the only thing that matters, but I like knowing exactly where my branch started and what changes came from the main line while I was working. When a merge conflict happens halfway through a rebase and you're stuck fixing things out of order, that's when I really miss a simple merge commit. Plus if you work with a team, you're rewriting history that other people might have based work on. That's just asking for trouble. Don't you think the "right way" really depends on your team size and workflow?

harper_wells5d ago

Been there with the rebase conflicts popping up halfway through and you're stuck untangling history you didn't even make. That's the worst feeling. I switched to merging for exactly that reason, especially on bigger teams where three people might touch the same files. The clean history crowd never accounts for the mental overhead of fixing a rebase when you're just trying to get a bug fix out the door. Merging master in gives you a clear timestamp of when you synced up, and if something breaks you know exactly which set of changes caused it. Really does come down to team size and how much churn you deal with day to day.