4 ms·

rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous depl

by swalsh 9y ago

rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.

madeofpalk 9y ago
driving can be dangerous, but so productive. I think it's important to each new adults how to properly use it.
Nullabillity 9y ago
You already have git-revert, for reverting commits without rewriting history.
- swalsh 9y ago
  You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. When reverting code is easy, and the company has good logging to identify problems, you can deploy more often. It's a good thing. But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. One commit, as little dependencies as possible. Rebase is the right tool to use for this. The goal is a tidy linear history.
  - Yokohiii 9y ago
    That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?
    - swalsh 9y ago
      It was actually quite clean, and the environment was extremely stable. The trick is, every commit was "self-contained". Reverting it would go to another previous stable version. Creating a self-contained commit can be done many ways, and rebase is one common tool used to do it. Another is the use of git merge with --squash and a cherry-pick.
  - drdrey 9y ago
    git revert is exactly the tool for the situation you are describing
    - swalsh 9y ago
      Sorry again, you're not understanding my point. Git revert is of course used... but i'm not worried about the mechanics of the revert itself. I'm worried about each revert being a "self-contained" piece. That the project was stable after the revert. That's the bit that was important. A Linear history of commits is the important bit. Not how to do a revert.
  - lmm 9y ago
    > But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. How are these concepts related to each other? Merges don't make reverting any harder.
- sirmarksalot 9y ago
  Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you. After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch. In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.
  - lmm 9y ago
    Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.
    - falsedan 9y ago
      It’s a lot of paperwork to avoid a perfectly safe and normal git command.
      - sirmarksalot 9y ago
        To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.
        falsedan 9y ago
        That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!
falcolas 9y ago
Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly. And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especially in the context of re-writing the history of previously shared commits. Yes, it is capable of cleaning up and reducing the number of commits you have to read through when looking at history, but that's such a rare event that optimizing for it (especially by normalizing dangerous commands like `git push -f`) seems, well, premature.
- Sir_Cmpwn 9y ago
  Rebase is mostly useful for cleaning up local commits or feature branches. You can rebase without force pushing master.
- Yokohiii 9y ago
  Completely agree. Rebase is practically only safe on single developer feature branches which haven't been merged or completely isolated repos that produces patches only. Keeping track of all requirements in the former is hard, especially if the dev doesn't know git pitfalls. No one should default to rebase in a day to day workflow, but it is quite common.

by swalsh 9y ago

madeofpalk 9y ago

driving can be dangerous, but so productive. I think it's important to each new adults how to properly use it.

Nullabillity 9y ago

You already have git-revert, for reverting commits without rewriting history.

swalsh 9y ago
You're misunderstanding the purpose i'm describing. Imagine 100 commits a day, maybe more. (I worked at a company that averaged 500 or more commits a day to the master branch. There were 1000 developers working in a monorepo). Some code is out in production, and suddenly we realize a specific commit is causing a problem. The idea here is to revert the commit as soon as you can, and then spend your time fixing it. When reverting code is easy, and the company has good logging to identify problems, you can deploy more often. It's a good thing. But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. One commit, as little dependencies as possible. Rebase is the right tool to use for this. The goal is a tidy linear history.
- Yokohiii 9y ago
  That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?
  - swalsh 9y ago
    It was actually quite clean, and the environment was extremely stable. The trick is, every commit was "self-contained". Reverting it would go to another previous stable version. Creating a self-contained commit can be done many ways, and rebase is one common tool used to do it. Another is the use of git merge with --squash and a cherry-pick.
- drdrey 9y ago
  git revert is exactly the tool for the situation you are describing
  - swalsh 9y ago
    Sorry again, you're not understanding my point. Git revert is of course used... but i'm not worried about the mechanics of the revert itself. I'm worried about each revert being a "self-contained" piece. That the project was stable after the revert. That's the bit that was important. A Linear history of commits is the important bit. Not how to do a revert.
- lmm 9y ago
  > But to enable this "revert-first" culture, you have to design your commits to basically be super easy to revert. That means no merges in the master branch, you want to keep your revision history as clean as possible. How are these concepts related to each other? Merges don't make reverting any harder.
sirmarksalot 9y ago
Git revert has undesired side effects for merges. If you have a merge-only workflow (GitFlow, for example), and your pull request breaks something, a revert commit will not help you. After a revert, all the commits that were merged, are still merged, but then they're deleted. The next time you pull, git will delete the changes in your working branch. In a merge workflow, you have to either fail forward (fix the problem, rather than backing out the merge), or reset/rebase the shared branch, and email repair instructions to everyone on the team.
- lmm 9y ago
  Create a feature branch, revert the revert, and then fix the problem. It sounds a little weird but it works fine.
  - falsedan 9y ago
    It’s a lot of paperwork to avoid a perfectly safe and normal git command.
    - sirmarksalot 9y ago
      To be fair, rebasing a shared branch really isn't all that safe. You can potentially make life hard for a lot of people.
      - falsedan 9y ago
        That’s not fair. That’s fear, uncertainty, doubt. Those people pulling that shared branch will see a big honking warning message, which can easily be resolved if you communicate what’s happening and why you rebased the upstream. When you say, it’s not safe, it sounds like you could lose work or someone could be hurt, when it’s more likely that the removed ancestors could be merged back in by someone not using ‘git pull —rebase’, or other devs being put out by having to resolve some conflicts. It’s not great, but it’s a far cry from unsafe or DANGEROUS! MUST AVOID! PUBLIC SHAMING!

falcolas 9y ago

Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly. And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especially in the context of re-writing the history of previously shared commits. Yes, it is capable of cleaning up and reducing the number of commits you have to read through when looking at history, but that's such a rare event that optimizing for it (especially by normalizing dangerous commands like `git push -f`) seems, well, premature.

Sir_Cmpwn 9y ago
Rebase is mostly useful for cleaning up local commits or feature branches. You can rebase without force pushing master.
Yokohiii 9y ago
Completely agree. Rebase is practically only safe on single developer feature branches which haven't been merged or completely isolated repos that produces patches only. Keeping track of all requirements in the former is hard, especially if the dev doesn't know git pitfalls. No one should default to rebase in a day to day workflow, but it is quite common.