> Huh? Do you mean it isn't being done on a topic (aka feature) branch? Master branch is still a branch.
Yes, I thought that was obvious from the context, but I admit I could have worded it better.
> Many people, including myself, aren't going to create a new topic branch for drive-by commits, such as fixing a typo.
Agreed, me neither, but this scenario is still no excuse for the advocated "Always use pull --rebase" - I would fix this by:
# See typo
# Immediately `git pull` to make sure it hasn't already been fixed
# Fix typo
# Commit, push
The likelihood that somebody will have pushed another commit in the time it took to do the above is so small that it's just not worth doing a precautionary --rebase. In the event that it did happen, I would use either rebase or a soft reset to tidy up the history before pushing.
> Many people prefer a cleaner, more linear history from rebasing.
IME this causes more problems than it solves: The history looks beautiful and linear, but it's a lie. The biggest problem with it is that the timestamps go out of chronological order on an apparently-linear history.
When you have a situation of "This bug started happening at 4pm" and you look at a linear branch that has commits for 5pm, 4pm, 3pm, 2pm, 1pm.. you'd be forgiven for not looking further, and so would miss that there was a SECOND commit at 4pm just before the 1pm one, courtesy of a rebase. If you'd kept history "true" by not rebasing, you'd see that there were two branches and therefore you'd investigate both for commits at the right time. This can lose you significant amounts of time when you're trying to track down a bug.
> If you've pushed your topic branch to a remote git repo then anyone else with commit access can make changes
That still falls into the trap of "minimal branches" - git is good at branching, do it often! If you've pushed a topic branch and are collaborating on it, your work should be on a feature branch of the topic branch. One feature, one branch. Not using git's awesome branch&fork power the way it should be used is what causes 99% of the problems people think they need rebasing for.
Branch early, branch often.
We have a multitude of git repos at $work and we all collaborate on new features. I haven't reached for rebase in months - it's an over-used tool that IMHO most people would be better off without. It gets too much use as a crutch that stops people from working out they're doing something wrong.
I agree with the mantras "Branch early, branch often" and "One feature, one branch" and follow them myself. And like you imply, the majority of git operations are cheap, so stuff like branching can (and should) be done more often.
> If you've pushed a topic branch and are collaborating on it, your work should be on a feature branch of the topic branch.
A feature branch of the topic branch seems like overkill in most cases. It seems odd to be writing a feature on top of an unfinished feature. Or if it's not a separate feature being added but the work is on the same feature, then creating a new feature branch of the topic branch breaks the branch per feature rule.
All this being said, people should follow the git workflow and guidelines set in place for their team. Don't use git differently than your teammates do, it'll cause issues eventually. If it's a solo project then go wild.
Yes, I thought that was obvious from the context, but I admit I could have worded it better.
> Many people, including myself, aren't going to create a new topic branch for drive-by commits, such as fixing a typo.
Agreed, me neither, but this scenario is still no excuse for the advocated "Always use pull --rebase" - I would fix this by:
# See typo
# Immediately `git pull` to make sure it hasn't already been fixed
# Fix typo
# Commit, push
The likelihood that somebody will have pushed another commit in the time it took to do the above is so small that it's just not worth doing a precautionary --rebase. In the event that it did happen, I would use either rebase or a soft reset to tidy up the history before pushing.
> Many people prefer a cleaner, more linear history from rebasing.
IME this causes more problems than it solves: The history looks beautiful and linear, but it's a lie. The biggest problem with it is that the timestamps go out of chronological order on an apparently-linear history.
When you have a situation of "This bug started happening at 4pm" and you look at a linear branch that has commits for 5pm, 4pm, 3pm, 2pm, 1pm.. you'd be forgiven for not looking further, and so would miss that there was a SECOND commit at 4pm just before the 1pm one, courtesy of a rebase. If you'd kept history "true" by not rebasing, you'd see that there were two branches and therefore you'd investigate both for commits at the right time. This can lose you significant amounts of time when you're trying to track down a bug.
> If you've pushed your topic branch to a remote git repo then anyone else with commit access can make changes
That still falls into the trap of "minimal branches" - git is good at branching, do it often! If you've pushed a topic branch and are collaborating on it, your work should be on a feature branch of the topic branch. One feature, one branch. Not using git's awesome branch&fork power the way it should be used is what causes 99% of the problems people think they need rebasing for.
Branch early, branch often.
We have a multitude of git repos at $work and we all collaborate on new features. I haven't reached for rebase in months - it's an over-used tool that IMHO most people would be better off without. It gets too much use as a crutch that stops people from working out they're doing something wrong.