7 ms·

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

lmm 2y ago
Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.
- saagarjha 2y ago
  Protect your main branch?
  - lmm 2y ago
    One of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.
    - saagarjha 2y ago
      Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?
      - lmm 2y ago
        I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.
        NewJazz 2y ago
        I'll often just do a git reset --hard origin/branch-name
        lmm 2y ago
        Right but that doesn't help if you've done your own work on top of their changes.
        iainmerrick 2y ago
        I think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.
        lmm 2y ago
        That's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.
        cnity 2y ago
        Just use: > git pull --rebase
        pjc50 2y ago
        git config --global pull.rebase=true
        lmm 2y ago
        Right but assuming I have a branch that's diverged from theirs I have to do a fiddly git rebase --onto and likely resolve the same conflicts again.
        cnity 2y ago
        This to me is a sign that some commits should be squashed, because it implies the same lines have changed multiple times in the commits that are ahead of the remote branch. It's worth doing the rebase interactively and squashing them up.
        xorcist 2y ago
        iainmerrick 2y ago
        Isn't "protect your main branch" still the answer to this? Your two feature branches would be unprotected so you can merge away if you like. When one of you wants to commit something to master, that's when you'd check for dodgy merges. Also, "git cherry-pick" is a good alternative to merging for this use case.
        lmm 2y ago
        > Isn't "protect your main branch" still the answer to this? No, the feature branches need to be protected or something, to enforce that they only rebase locally and don't rebase the parts that I've merged into my branch (and vice versa). > Also, "git cherry-pick" is a good alternative to merging for this use case. No it isn't, it means you get multiple unrelated commits for the same change, which causes conflicts and can be disastrous if a commit is deliberately reverted.
        otherjason 2y ago
        Protecting the main branch is definitely a good practice, but the other potential hazard is: - Having a developer on your team that rebases their own feature branch - Then tries to "git push", only for it to be rejected since a force push is required - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously Our team uses merges because they are safe from this kind of problem, although a rebase workflow would have cleaner history. I wish that "git push --force" would not push all branches by default, and just fail unless a (remote, branch) pair or --all is given.
        danaris 2y ago
        > - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously This is (part of) why, for most common operations, I use a Git GUI (SourceTree). Force pushing all branches can only be done by very explicitly selecting them all and initiating a force push; the default when pushing is to push only the currently active branch. It's also overall much clearer and more intuitive to use than the Git CLI. I use it when I have to—there are things that I can't do through SourceTree, and a few things that are complicated enough that I just want to be 100% sure I know exactly what's happening—but for 99% of the Git operations I do, it handles them perfectly and without any worry that I've mistyped something or forgotten to specify a branch.
- from-nibly 2y ago
  --force-with-lease And only on working branches. I do this every single day.
  - lmm 2y ago
    Not good enough, that can mean you rebase changes that someone else has based further work on (but hasn't pushed it yet, or has pushed it to a different branch).
    - from-nibly 2y ago
      Why are you having people base their work off your in progress work? Git is not the issue with what you are describing.
      - lmm 2y ago
        > Why are you having people base their work off your in progress work? To collaborate more closely and reduce (or get ahead of) conflicts. The whole point of using git at all is to be able to base your work off other people's in-progress work; if you're not interested in doing that then Subversion works better.
quectophoton 2y ago
I can give an example scenario. Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first): H(3) Implement feature B H(2) Implement feature A H(1) Initial commit Now you implement "shiny feature", so your history in your branch looks like this: H(5) Shiny feature, improvements. H(4) Shiny feature, initial implementation. H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You tested H(4) and H(5), and everything looks good. Then you `git pull --rebase`, and your history looks like this: H(10) Shiny feature, improvements. H(9) Shiny feature, initial implementation. H(8) Pulled commit C H(7) Pulled commit B H(6) Pulled commit A H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever). With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect. Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).
- citrin_ru 2y ago
  To avoid this you can squash H(9) and H(10) before pushing to a shared branch, this way only one tested commit will be added on top of existing commits.

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

lmm 2y ago

Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.

saagarjha 2y ago
Protect your main branch?
- lmm 2y ago
  One of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.
  - saagarjha 2y ago
    Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?
    - lmm 2y ago
      I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.
      - NewJazz 2y ago
        I'll often just do a git reset --hard origin/branch-name
        lmm 2y ago
        Right but that doesn't help if you've done your own work on top of their changes.
        iainmerrick 2y ago
        I think rebase is generally the correct approach here. If you've done your own work on top of their old changes, rebase your work on top of their new changes.
        lmm 2y ago
        That's possible but it requires a bunch of manual tracking and results in wasted/duplicate effort with people resolving the same conflicts multiple times.
        cnity 2y ago
        Just use: > git pull --rebase
        pjc50 2y ago
        git config --global pull.rebase=true
        lmm 2y ago
        Right but assuming I have a branch that's diverged from theirs I have to do a fiddly git rebase --onto and likely resolve the same conflicts again.
        cnity 2y ago
        This to me is a sign that some commits should be squashed, because it implies the same lines have changed multiple times in the commits that are ahead of the remote branch. It's worth doing the rebase interactively and squashing them up.
        xorcist 2y ago
      - iainmerrick 2y ago
        Isn't "protect your main branch" still the answer to this? Your two feature branches would be unprotected so you can merge away if you like. When one of you wants to commit something to master, that's when you'd check for dodgy merges. Also, "git cherry-pick" is a good alternative to merging for this use case.
        lmm 2y ago
        > Isn't "protect your main branch" still the answer to this? No, the feature branches need to be protected or something, to enforce that they only rebase locally and don't rebase the parts that I've merged into my branch (and vice versa). > Also, "git cherry-pick" is a good alternative to merging for this use case. No it isn't, it means you get multiple unrelated commits for the same change, which causes conflicts and can be disastrous if a commit is deliberately reverted.
        otherjason 2y ago
        Protecting the main branch is definitely a good practice, but the other potential hazard is: - Having a developer on your team that rebases their own feature branch - Then tries to "git push", only for it to be rejected since a force push is required - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously Our team uses merges because they are safe from this kind of problem, although a rebase workflow would have cleaner history. I wish that "git push --force" would not push all branches by default, and just fail unless a (remote, branch) pair or --all is given.
        danaris 2y ago
        > - Then performs a "git push --force", which will force-push all of their local branches, including feature branches from other developers that they may have checked out previously This is (part of) why, for most common operations, I use a Git GUI (SourceTree). Force pushing all branches can only be done by very explicitly selecting them all and initiating a force push; the default when pushing is to push only the currently active branch. It's also overall much clearer and more intuitive to use than the Git CLI. I use it when I have to—there are things that I can't do through SourceTree, and a few things that are complicated enough that I just want to be 100% sure I know exactly what's happening—but for 99% of the Git operations I do, it handles them perfectly and without any worry that I've mistyped something or forgotten to specify a branch.
from-nibly 2y ago
--force-with-lease And only on working branches. I do this every single day.
- lmm 2y ago
  Not good enough, that can mean you rebase changes that someone else has based further work on (but hasn't pushed it yet, or has pushed it to a different branch).
  - from-nibly 2y ago
    Why are you having people base their work off your in progress work? Git is not the issue with what you are describing.
    - lmm 2y ago
      > Why are you having people base their work off your in progress work? To collaborate more closely and reduce (or get ahead of) conflicts. The whole point of using git at all is to be able to base your work off other people's in-progress work; if you're not interested in doing that then Subversion works better.

quectophoton 2y ago

I can give an example scenario. Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first): H(3) Implement feature B H(2) Implement feature A H(1) Initial commit Now you implement "shiny feature", so your history in your branch looks like this: H(5) Shiny feature, improvements. H(4) Shiny feature, initial implementation. H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You tested H(4) and H(5), and everything looks good. Then you `git pull --rebase`, and your history looks like this: H(10) Shiny feature, improvements. H(9) Shiny feature, initial implementation. H(8) Pulled commit C H(7) Pulled commit B H(6) Pulled commit A H(3) Implement feature B H(2) Implement feature A H(1) Initial commit You test H(10) because it's the current state of your repo, looks good, and merge (or create PR, whatever). With the usual pull request flows, `H(9)` (i.e. anything between your new "base" and your most recent commit) usually stays untested, entirely ignored by the developers, and you would only ever find out if you ever need to bisect. Not usually a problem, unless you have a rule of "every commit should be verified/tested" and the untested commits have a change that doesn't prevent a build but still causes issues (e.g. something that's only visual, or a new config file was added to a "conf.d" directory and its presence changed some behavior, stuff like that).

citrin_ru 2y ago
To avoid this you can squash H(9) and H(10) before pushing to a shared branch, this way only one tested commit will be added on top of existing commits.