4 ms·

I would strongly recommend avoiding a rebase-based strategy. When developers at my company run into git issues, they are almost always the result of a bad or co

I would strongly recommend avoiding a rebase-based strategy. When developers at my company run into git issues, they are almost always the result of a bad or confusing rebase. My team's process is simple and easy for anyone to follow: all feature work is done on feature branches. Branches should be kept small and atomic. When they've passed code review, squash and merge into Master. If you need to pull changes from master, always merge into your feature branch, never rebase.

joatmon-snoo 10y ago
I would disagree with the strongly recommend here, because rebasing makes it so much easier to track down bugs and isolate breaking changes. Of course, this does require someone to be more proficient with Git beyond the simple add, commit, fetch, push model, which has its own drawbacks. Also, at least in Git, squash is just one use case of interactive rebase, so I'm not quite sure what you're arguing against...
- hitsurume 10y ago
  Can you go more in depth with this process on how rebasing things makes it easier to track down bugs / breaking changes? Usually you can track down which feature branch is the one that cause a regression in your code base, and you can also look at specific commits to find out where problems happen. I can't tell how a rebasing flow would make this any easier?
burntsushi 10y ago
How do you squash commits without rebasing?
- bryanh 10y ago
  git checkout master git merge --squash some-feature-branch
radicalbyte 10y ago
It sounds like you've had people rebasing some public commit which has then been branched from. That's asking for trouble. Rebasing is wonderful, it makes Git a joy to use. But you have to understand the process and, most importantly, train your team so that they also understand it. As I've said, I've had great experiences working like this; but it took a lot of effort and support of my senior developers to get the team up to speed.

joatmon-snoo 10y ago

I would disagree with the strongly recommend here, because rebasing makes it so much easier to track down bugs and isolate breaking changes. Of course, this does require someone to be more proficient with Git beyond the simple add, commit, fetch, push model, which has its own drawbacks. Also, at least in Git, squash is just one use case of interactive rebase, so I'm not quite sure what you're arguing against...

hitsurume 10y ago
Can you go more in depth with this process on how rebasing things makes it easier to track down bugs / breaking changes? Usually you can track down which feature branch is the one that cause a regression in your code base, and you can also look at specific commits to find out where problems happen. I can't tell how a rebasing flow would make this any easier?

burntsushi 10y ago

How do you squash commits without rebasing?

bryanh 10y ago
git checkout master git merge --squash some-feature-branch

radicalbyte 10y ago

It sounds like you've had people rebasing some public commit which has then been branched from. That's asking for trouble. Rebasing is wonderful, it makes Git a joy to use. But you have to understand the process and, most importantly, train your team so that they also understand it. As I've said, I've had great experiences working like this; but it took a lot of effort and support of my senior developers to get the team up to speed.