3 ms·

Um.. No.. if you use rebase regularly, you're doing something very wrong. In this case, the problem is that development isn't being done on a branch. One of th

Um.. No.. if you use rebase regularly, you're doing something very wrong. In this case, the problem is that development isn't being done on a branch. One of the most important features of Git is how easy it is to fork & merge - there's no excuse for doing your work on master. Work on a branch, merge your branch into master when it's finished. History is completely accurate, you only get one merge commit. Don't mess up history just to work around bad workflow. Fix the problem at its source.

eloisant 13y ago
Indeed when you do work on a feature branch, you shouldn't rebase. But when you're working on master, or a branch that's also remote, then you have to rebase. If you don't then you get completely meaningless merge commits. If 3 people merge when they just want to push a commit it then you're history becomes a tangled unusable mess.
- justin_vanw 13y ago
  Maybe you are history becomes a tangled unusable mess, but it works for me just fine.
- Cthulhu_ 13y ago
  Then those three should've worked on their own feature branch. In fact, one could consider a local copy of master (or, commits made on master on one user's machine) as a feature branch, all named 'master'. Another thing, a developer doesn't need to obsessively pull every couple of minutes. If they're fixing a bug and deciding against using a branch for that (seeing that it could be just one commit), they only pull twice; once before they start working, and again when they're done and want to push to master. If there's more than one person fixing the same bug simultaneously, then it's yet another process bug.
reledi 13y ago
> In this case, the problem is that development isn't being done on a branch. Huh? Do you mean it isn't being done on a topic (aka feature) branch? Master branch is still a branch. > there's no excuse for doing your work on master. Many people, including myself, aren't going to create a new topic branch for drive-by commits, such as fixing a typo. > Work on a branch, merge your branch into master when it's finished. ... Don't mess up history just to work around bad workflow. You're technically rewriting history, but it's not like you're rewriting history that's been pushed (which is typically a big no-no). Many people prefer a cleaner, more linear history from rebasing. And if you're implying that using topic branches somehow fixes the "problem" of having to rebase, that's not true. If you've pushed your topic branch to a remote git repo then anyone else with commit access can make changes or you can even make changes on the remote repo if the web interface allows it (like how GitHub does).
- oneandoneis2 13y ago
  > 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.
  - reledi 13y ago
    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.

eloisant 13y ago

Indeed when you do work on a feature branch, you shouldn't rebase. But when you're working on master, or a branch that's also remote, then you have to rebase. If you don't then you get completely meaningless merge commits. If 3 people merge when they just want to push a commit it then you're history becomes a tangled unusable mess.

justin_vanw 13y ago
Maybe you are history becomes a tangled unusable mess, but it works for me just fine.
Cthulhu_ 13y ago
Then those three should've worked on their own feature branch. In fact, one could consider a local copy of master (or, commits made on master on one user's machine) as a feature branch, all named 'master'. Another thing, a developer doesn't need to obsessively pull every couple of minutes. If they're fixing a bug and deciding against using a branch for that (seeing that it could be just one commit), they only pull twice; once before they start working, and again when they're done and want to push to master. If there's more than one person fixing the same bug simultaneously, then it's yet another process bug.

reledi 13y ago

> In this case, the problem is that development isn't being done on a branch. Huh? Do you mean it isn't being done on a topic (aka feature) branch? Master branch is still a branch. > there's no excuse for doing your work on master. Many people, including myself, aren't going to create a new topic branch for drive-by commits, such as fixing a typo. > Work on a branch, merge your branch into master when it's finished. ... Don't mess up history just to work around bad workflow. You're technically rewriting history, but it's not like you're rewriting history that's been pushed (which is typically a big no-no). Many people prefer a cleaner, more linear history from rebasing. And if you're implying that using topic branches somehow fixes the "problem" of having to rebase, that's not true. If you've pushed your topic branch to a remote git repo then anyone else with commit access can make changes or you can even make changes on the remote repo if the web interface allows it (like how GitHub does).

oneandoneis2 13y ago
> 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.
- reledi 13y ago
  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.