A Better Git Flow

The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at &lt;day job&gt;.<p>Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts.<p>But you can very easily do this just by rebasing instead of resetting and re-committing.<p>In particular, `git commit --fixup &lt;ref&gt;` and `git commit --squash &lt;ref&gt;` are <i>extremely</i> useful for this during the &quot;WIP&quot; stage as well as when handling PR comments, and these are things that I only learned about in the last 6 months. I would recommend doing a google search on &quot;fixup commits&quot; to learn more about them. I enjoyed this article: <a href="https:&#x2F;&#x2F;www.mikulskibartosz.name&#x2F;git-fixup-explained&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.mikulskibartosz.name&#x2F;git-fixup-explained&#x2F;</a><p>Yes, rebasing is scary if you&#x27;re new to git, but it does everything in this article in a way that&#x27;s much cleaner and once you learn how to use it effectively you&#x27;ll feel like you have super powers. It&#x27;s worth taking the time to learn.

What a waste of time and effort. Squash when merging to master and be done with it. Every PR&#x2F;commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I&#x27;m doing something else. Those will be two separate PR&#x27;s. The second problem shouldn&#x27;t exist IMO.

Most folks are complaining about `git reset` being more dangerous and to just use `rebase -i` instead. To each their own... I&#x27;m one of those weirdos who also uses the `git reset` in their workflow. I prefer it to `rebase -i` because it doesn&#x27;t mess with my working tree a bunch while it&#x27;s happening, plus I like to construct brand new logical commits, in order, in the manner described by the article.<p>But this part set off alarm bells:<p>&gt; Once you’ve finished making your changes, it’s time to prepare your work for some “git clean up.” To do this, we’ll run the following command:<p>&gt; git reset origin&#x2F;main<p>Be very careful here! If you&#x27;ve run `git fetch origin` since you&#x27;ve started your work, you may be resetting to a commit that&#x27;s <i>newer</i> than what you based your work on, and thus you&#x27;ll wind up creating a commit which effectively reverts anything that&#x27;s happened on `main` since then.<p>The more technically correct command would be:<p>&gt; git reset $(git merge-base origin&#x2F;main HEAD)<p>Since that resets to the commit you started your branch from.

The article starts by stating a rather obvious problem: if you revert a commit, you might break something because any commit following the reverted one could build on what was added in the reverted commit.<p>Then the article describes a very elaborate way of… not addressing the problem?<p>Reset-Cleanup is a decent idea and helps keep a tidy repo which is a good goal. But the revert reason seems contrived.<p>The problem is going to be later code (from other pull requests) being dependent on the code in my pull request.<p>If my pull request is reverted then any later change can break. If my PR consists of 5 well separated commits or 3 messsy ones doesn’t matter in that scenario.<p>If someone against all odds wants to revert one individual commit from a merged branch but <i>not</i> revert the whole PR by reverting the merge commit then not only can the feature in the PR stop working (if the feature&#x2F;bug fix in the PR didn’t need that commit to work then why was it there in the first place!?), any later code can break just as it can when PR is reverted as a whole.<p>This is why I recommend squashing for almost all cases. For really complex features with dozens of commits you can always do a rebase + FF (but in that case all commits should build + pass tests, which is an unrealistic goal in all code bases where a build + test takes hours).

I wrote a similar suggestion in 2011: <a href="https:&#x2F;&#x2F;sandofsky.com&#x2F;workflow&#x2F;git-workflow&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sandofsky.com&#x2F;workflow&#x2F;git-workflow&#x2F;</a><p>As far as I could tell, this was the recommended workflow from the earliest users of git. Look at the Linux kernel&#x27;s public history.<p>When git gained widespread adoption, it was sold as &quot;Subversion, but with cheap branching.&quot; People don&#x27;t realize that this power requires discipline, otherwise you end up with complicated history that makes change management a nightmare.<p>In code review systems like Gerrit, you have to approve every single commit, and you can also enforce rules like &quot;fast-forward merges only.&quot; It sure makes Github&#x27;s pull-request model feel like an anti pattern.

This to me seems more like a logical separation than anything technical.<p>I use GitHub and always squash commits before merging a PR. This keeps the commit log clean and also has the side effect that you have the PR number in the merge commit.<p>Having said that I also suggest keeping PRs small. If you are going to reformat a code base, make that a separate commit. Updating a library, separate commit. Adding a library you need for a new feature: create a PR for the library update, base your implementation off that branch and rebase against main when the first PR is merged.

My two cents: I just always squash commits when merging to master&#x2F;main. That way the main branch has clean commit messages and it&#x27;s easy to revert later. I think cherry-picking commits after the fact can also be very time-consuming, especially if you do a lot of refactoring or &quot;clean as you go&quot; as I like to call it. However, I could see it being worth it for open-source.

Why do we keep trying to make git &quot;smart&quot;er than it needs to be? Whenever I hear someone complain about git it&#x27;s 9&#x2F;10 times because of ignorance, and it&#x27;s a simple mistake to solve. No amount of tooling or smartening (as this author seemed to be described) is a valid alternative to training and understanding. The consequences of that is that a smarter tool used by dumb people means those people are held back, and made unproductive by the tool in question.

I think this makes a lot of sense. I usually use git in a completely different way when developing than I do when I&#x27;m pushing up code for others into a shared branch.<p>When developing my priority is to easily get back to a last known working state. This allows me to try out risky changes, and throw them all away if it doesn&#x27;t work out.<p>When pushing my changes for PR, those working states I saved before may not be the best logically. I usually re-write my commits to break it into more logical chunks, that are easy to revert and easier for other teammates to digest.

I use lazygit[0] to essentially do the same thing. (or even vim-fugitive[1])<p>Previously I avoided creating messy commits simply because it was &quot;tedious&quot; to reorganize commits. And making overly atomic commits and typing out git commands more frequently didn&#x27;t appeal to me either.<p>Once I got used to the above tools, life got so much easier. Lazygit makes it super easy to amend, reword, and even re-position commits in a TUI environment. Real life-changer for me. I can stage hunks super easily too, though that&#x27;s even easier in neovim.<p>The only issue I face is my C-j&#x2F;C-k keys are already bound to tmux, but are needed by lazygit to reposition commits.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit</a> [1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;tpope&#x2F;vim-fugitive" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tpope&#x2F;vim-fugitive</a>

&gt; do the work first, clean up the commits later<p>I&#x27;m not sure this gives the right impression. Yes rename&#x2F;squash&#x2F;interactive rebase if necessary to tidy, however I still believe you should strive to create clear, separate commits as you go.<p>If you have to regularly make major changes to history before review, I could be a sign that your process&#x2F;approach is disorganised.

I hate to see git guides where they tell the user to make commits that are literally the description of the diff rather than the <i>why</i> of the change.<p>&quot;Added new styles to navigation&quot;<p>No duh, that&#x27;s what the diff shows, but that doesn&#x27;t tell us why you made the change, and that&#x27;s the part we&#x27;re going to struggle to remember in 6 months.

This doesn&#x27;t really have anything to do with the Git Flow model which is all about having multiple long-lived development branches.<p>As far as the proposal goes, this is a much better way to do it than trying to preserve every mistake you made along the way. I&#x27;d prefer to see either this or just the one squashed commit. I&#x27;d just argue that maybe if its important to break it up into multiple commits that you might consider that it should also be separate PRs. If it is necessarily so interlinked that you can&#x27;t produce separate passing PRs then I probably need to wrap my brain around the whole thing at once as well.<p>Usually my objection is that multiple different concerns need to be done totally separately. I can&#x27;t think of the last time I really wanted just separate commits and not entirely different PRs.

It makes sense sometime, but not always. Group commits by files.<p>For example,<p>Most of one core change is in multiple files, it will be very bad to commit by files group

Why commit at all if you&#x27;re going to reset? Sounds like the intermediate commits are just used as a backup method. The real trickery is mentioned in the last part, if commits don&#x27;t break up tidily along file boundaries you&#x27;ll have to commit hunks somehow and then go back and test whether the code works.<p>Either way, in the end it&#x27;s up to developer discipline to make clean commits, git doesn&#x27;t really help all that much although in my (long) source control history before git I never thought of committing hunks.

This article undermines itself the second it moves from “here’s the problem” to “here’s the solution:”<p>&gt; Be mindful of not leaving your codebase in a broken state during this step<p>You’re still relying on very fallible human intervention here. Even worse, often times when grouping commits post-facto you’ve forgotten some of the context of what depends on what.<p>Ostensibly the approach presented could be better than other strategies in this regard, but that’s now how the article presents itself and it loses credibility for that.

I highly recommend tig because it lets you easily stage each line&#x2F;change separately. Together with interactive rebase and fixup commits, it becomes super easy to group changes where they belong. For fixup commits with tig (in main view go to the commit to fixup and press &#x27;=&#x27;), my .gitconfig has:<p><pre><code> [tig &quot;bind&quot;] main = = !git commit --fixup=%(commit)</code></pre>

I feel that these &quot;workflow suggestions&quot; are all nice and dandy, but have nothing to do with the real world. The real world looks like this: Create a new branch, make changes, commit, make a PR, commit some more (all without proper commit messages of course), make more fixup commits, and when it gets merged it gets all squashed into one big commit, rebased on master and ff-merged.<p>This is what the project I was just hired to work on looks like. Result is a linear history, with multi-thousand-line changes in a commit with message &quot;Implement fixes&quot; and a list of &quot;fix bug&quot;, &quot;fix more&quot;, &quot;format&quot;, &quot;change implementation&quot; in the long-form commit message.<p>People out there do not even know how to work properly with git, I think it is way too much for them when we start telling them how to &quot;workflow&quot; with git. It is sad, but that&#x27;s what I see.

uhh...git rebase -i anyone?

Yes git rebase -i is better as others pointed out.<p>Example from the start ... revert.<p>Don&#x27;t revert stuff, fix stuff forward (make new commits with new changes) you won&#x27;t introduce bugs in silly way.

The use of `git reset` is a little silly and is playing with fire for no absolutely no benefit.<p>If you want to follow the pattern described here, create a new branch and do `git checkout the_feature_branch -- $filename` and pull the changes from the branch you did the work in into the new branch, making commits as described in the article. You can even do `git diff --numstat $feature_branch $new_branch` to see what has changed.

I&#x27;m surprised no one has mentioned trunk based development yet. Never going back to git flow at a medium&#x2F;large org again. Merge hell is a nightmare and releases more so.<p>&gt; When the feature is complete, make a pull request.<p>gotta love 100 file commits that take a day to review.

I hate Perforce (most because of bugs) BUT the in progress CL workflow is better than this.<p>Git should introduce stages and allow you to have any number of stages. Git should also have some porcelain around stashing all but one stage and restoring all etc etc.

Or you can just use staging to bunch up your changes until you are ready for a logical commit....<p>the problem with your approach is that sometimes, changes are logically grouped but cross file.

I always thought this was how git commits were meant to work? Isn&#x27;t this just GitHub flow with sensible commit grouping?

And if you have PR comments&#x2F;commits you do this everytime? Just squash