Git Reflow

#1

Post by jaybosamiya » Thu, May 19, 2016, 4:30 PM UTC

Git Reflow
github.com

Re: Git Reflow

#2

Post by teen » Thu, May 19, 2016, 6:20 PM UTC

This seems super useful- it matches my team's workflow, I'll def suggest we try it. Squash merge ftw

Re: Git Reflow

#3

Post by juped » Thu, May 19, 2016, 6:23 PM UTC

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News.

Something is deeply wrong with the ecosystem when people want to do things like this!

Re: Git Reflow

#4

Post by DannyBee » Thu, May 19, 2016, 6:29 PM UTC

teen wrote: post #2

This seems super useful- it matches my team's workflow, I'll def suggest we try it. Squash merge ftw

I'm really curious about it. One of the purported reasons - "it makes git blame more useful", is pretty silly, unless you never have anyone fixing typos or reformatting code or whatever.

git blame is already an approximation (because git, and well, everything, does not record what you did for real, only the smallest set of binary delta instructions you must execute to produce file version 2 from file version 1).

So this is essentially is "this one git command sucks, so we are going to destroy all of history to make it's output slightly better in a few cases", instead of "hey, we are going to produce a version of blame that identifies the kind of info we care about"

Re: Git Reflow

#5

Post by 32bitkid » Thu, May 19, 2016, 6:34 PM UTC

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo.

When I think I'm done with a feature is exactly the time that metadata becomes relevant! Why would I want to lose it?

If anything, I wish ides would integrate git-blame more into my visualisation of a file

But there are so many people into it, that I feel I must be missing something obvious and it bothers me.

Re: Git Reflow

#6

Post by pcl » Thu, May 19, 2016, 6:41 PM UTC

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I'm with you. History is mostly useful after the fact to understand the details, not the big picture.

I wish git had a first-class model of a milestone-ish block of commits, so that the detailed commits and the feature milestones are disambiguated. I try to do this with merge points, but it doesn't seem to always work out, and since it's not native, it depends entirely on convention.

Re: Git Reflow

#7

Post by andrewchilds » Thu, May 19, 2016, 6:42 PM UTC

From the README:

    $ git reflow setup
    Please enter your GitHub username: nhance
    Please enter your GitHub password (we do NOT store this):

    Your GitHub account was successfully setup!

That implies that the username is actually stored somewhere. Is it stored locally or on some reenhanced.com server? The README should be very clear about what exactly gitreflow stores and where.

Re: Git Reflow

#8

Post by 0942v8653 » Thu, May 19, 2016, 6:45 PM UTC

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I agree, but here's their reasoning: https://github.com/reenhanced/gitreflow/issues/52

> When it really comes down to it, the only place we care about enforcing a particular style of commit is in the master branch. We don't care if you make a thousand commits to get there, the only thing we care about is the individual features that come in from each (small) pull request.

> And while the history is nice, the biggest advantage of using the squash merge is that over time, git blame becomes way more useful. You get to see for every line of code in your project, not only the person who changed it, but their commit in the full context of why that change was made, including an easy-to-reference link to the pull request and ideally (through the pull request description), a link to the ticket tracker. So we can tie any line of code all the way back to the ticket that caused it's creation.

> And over time, that's all we really care about in the history. Who made this change and why was it made. Squash merging allows us to do that while still giving all of our developers the individual freedom to develop in the way that suits them best. To try and enforce commit styles in branches owned by other devs is to me, micromanagement that will go against the best results.

Re: Git Reflow

#9

Post by throwanem » Thu, May 19, 2016, 6:48 PM UTC

juped wrote: post #3

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

Where is information lost? Delivered branches aren't deleted, so full history information is available - it just doesn't clutter trunk by merging in every commit.

Re: Git Reflow

#10

Post by sergiosgc » Thu, May 19, 2016, 6:48 PM UTC

pcl wrote: post #6

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I'm with you. History is mostly useful after the fact to understand the details, not the big picture. I wish git had a first-class model of a milestone-ish block of commits, so that the detailed commits and the feature milestones are disambiguated. I try to do this with merge points, but it doesn't seem to always work out, and since it's not native, it depends entirely on convention.

I get close to the milestone-ish commit by opening feature branches and then merging with no fast forward. All commits in the main branch are merges, and all of those are features. The feature incremental commits go in the branch.

It's ok, I'd just like to be able to apply this structure to stuff like bisect or blame.