Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Better Git Flow

render.com

Post reply on HN
Print view View original

31–40 of 115 posts

Re: A Better Git Flow

#31

Post by alkonaut »

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.

Then the article describes a very elaborate way of… not addressing the problem?

Reset-Cleanup is a decent idea and helps keep a tidy repo which is a good goal. But the revert reason seems contrived.

The problem is going to be later code (from other pull requests) being dependent on the code in my pull request.

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.

If someone against all odds wants to revert one individual commit from a merged branch but not revert the whole PR by reverting the merge commit then not only can the feature in the PR stop working (if the feature/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.

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

Re: A Better Git Flow

#32

Post by okl »

jcranmer wrote: post #29
dljsjr wrote: post #17

The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . 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. But you can very easily do this just by rebasing instead of resetting and re-commit…

The one thing I wish were easier would be breaking a single commit into two commits. Edit: to be clear, I know it's possible by using git reset... but I'd much rather have something like git add -i that interactively shifts changes from the commit itself and moves them into working directory-only changes.

Not much trouble if you're used to it.

    git rebase --interactive master
    In Vim: ciw e ESC :x
    git reset HEAD~
    // Make your commits
    git rebase --continue

Re: A Better Git Flow

#33

Post by geoffmanning »

ltbarcly3 wrote: post #13

The use of `git reset` is a little silly and is playing with fire for no absolutely no benefit. 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 h…

Trying to understand where the danger is with git reset. To avoid a very harmless and easily reversible command, you complicated the process with another branch. The fact you feel it is dangerous tells me that you don't have a strong understanding of how git works. It's always kind of funny to me to see how strong of an opinion devs get over how to use git when it's clear they don't really understand the toolset. It took a while to get all the devs at my last company to understand how simple it is to rebase/reset, and write some publish worthy commits, but once they all understood the value it adds, they all became converts and did the evangelism job for me the next time we hired a dev. I recommend reading Pro Git by Scott Chacon. Git is pretty dang amazing.

Re: A Better Git Flow

#34

Post by Supermancho »

_hao wrote: post #6

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

aka Premature process optimization.

Dont make work upfront, that is rarely important. When it is important, find the commit and split it up (as necessary) at that singular point (instead of across all PRs). You have now cut down how much time it takes to make PRs while retaining the same end result.

Re: A Better Git Flow

#35

Post by okl »

dljsjr wrote: post #30
jcranmer wrote: post #29

Earlier quoted context omitted.

The one thing I wish were easier would be breaking a single commit into two commits. Edit: to be clear, I know it's possible by using git reset... but I'd much rather have something like git add -i that interactively shifts changes from the commit itself and moves them into working directory-only changes.

1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.

> 4. use `git add -p`

I strongly recommend tig

Re: A Better Git Flow

#36

Post by sandgiant »

dljsjr wrote: post #17

The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . 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. But you can very easily do this just by rebasing instead of resetting and re-commit…

Rebase is great, but it's usefulness really depends on the commit history.

If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.

Re: A Better Git Flow

#37

Post by dljsjr »

okl wrote: post #35
dljsjr wrote: post #30

Earlier quoted context omitted.

1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.

> 4. use `git add -p` I strongly recommend tig

lazygit is also great.

VS Code also makes it easy to stage hunks in the editor if you like to stay in your editor; in the diff viewer from the Git view you can highlight the lines you want to stage and right click -> stage selected ranges.

I've never used tig. I'll look at it.

Re: A Better Git Flow

#38

Post by ninkendo »

Most folks are complaining about `git reset` being more dangerous and to just use `rebase -i` instead. To each their own... I'm one of those weirdos who also uses the `git reset` in their workflow. I prefer it to `rebase -i` because it doesn't mess with my working tree a bunch while it's happening, plus I like to construct brand new logical commits, in order, in the manner described by the article.

But this part set off alarm bells:

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

> git reset origin/main

Be very careful here! If you've run `git fetch origin` since you've started your work, you may be resetting to a commit that's newer than what you based your work on, and thus you'll wind up creating a commit which effectively reverts anything that's happened on `main` since then.

The more technically correct command would be:

> git reset $(git merge-base origin/main HEAD)

Since that resets to the commit you started your branch from.

Re: A Better Git Flow

#39

Post by danhab99 »

Why do we keep trying to make git "smart"er than it needs to be? Whenever I hear someone complain about git it's 9/10 times because of ignorance, and it'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.

Re: A Better Git Flow

#40

Post by travisd »

This article undermines itself the second it moves from “here’s the problem” to “here’s the solution:”

> Be mindful of not leaving your codebase in a broken state during this step

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.

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.

Post reply on HN