Oh shit, git: Getting myself out of bad situations

Re:Oh shit, git: Getting myself out of bad situations by swalsh on Monday December 18, 2017 @01:05PM (#15953701)

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.

[ Parent | on HN ]

Re:Oh shit, git: Getting myself out of bad situations by lmm on Monday December 18, 2017 @03:40PM (#15955297)

> 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.

[ Parent | on HN ]

Re:Oh shit, git: Getting myself out of bad situations by Yokohiii on Monday December 18, 2017 @01:34PM (#15953996)

That sounds quite chaotic and impossible to keep stable. I wonder who was responsible to find problems and fix the master after messing up?

[ Parent | on HN ]

Re:Oh shit, git: Getting myself out of bad situations by swalsh on Tuesday December 19, 2017 @10:21AM (#15960776)

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.

[ Parent | on HN ]

Re:Oh shit, git: Getting myself out of bad situations by drdrey on Monday December 18, 2017 @05:37PM (#15956135)

git revert is exactly the tool for the situation you are describing

[ Parent | on HN ]

Re:Oh shit, git: Getting myself out of bad situations by swalsh on Tuesday December 19, 2017 @10:23AM (#15960786)

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.

[ Parent | on HN ]