
Git Reflow - jaybosamiya
https://github.com/reenhanced/gitreflow
======
32bitkid
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.

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

As someone in favor of squashing, I can say that I don't want to see things
like "oops, reverting last commit" popup in my git history, especially if I'm
browsing history or bisecting a bug. That's noise - useless data. OTOH,
commits _should_ be the Minimum Necessary Change to accomplish a well-defined
goal. The code itself should _always_ be clear on what it is doing, otherwise
it's badly written. If it's "deep magic", then comment it in the code as such.

That being said, I do think that reasoning for _why_ a change was made, at
every level, should be in the commit message. I'm also not a fan of merge, but
prefer squash+rebase.

In all cases/workflows, it can be abused, and people writing bad code, bad
comments or bad commit messages will do so until you can make them care to do
it better. There's no silver bullet.

~~~
JimDabell
> As someone in favor of squashing, I can say that I don't want to see things
> like "oops, reverting last commit" popup in my git history

There's a middle ground between squashing and leaving a load of disorganised
crap in the history. Rebase before merging. It gives you a chance to clean up
the rubbish, but it doesn't force you to squash an entire feature's work into
a single commit. You can preserve the logical changes without letting the crap
into your history.

~~~
ghayes
I agree here. Be a good steward of your commits, and let `rebase -i` be your
tool for that. A bunch of "err, try this instead" should be washed away, but
it doesn't help to commit "Add Huge Feature" +10,000/-2,000 because "I should
squash my feature"

~~~
mikepurvis
If you're putting up 10k lines of code in a single review, you're doing it
wrong anyway. Why wouldn't you have multiple reviews that each add different
parts of a feature and link to the same ticket?

~~~
adrianratnapala
If I wanted to review 200 lines of changes, then I would still prefer to see
it as a series of patches, each maybe with 1-20 lines changed and each with a
clear purpose.

------
codenamev
As one of the maintainers of git-reflow, I understand the controversy over
squash-merges. Personally, on all the projects I've worked on with this
workflow, I have yet to find any drawbacks when needing to use git-blame;
although is not to say that there is no value in maintaining a full history
nor that it is our way or the highway. We like to keep all changes in context
of a feature.

We have worked in environments that promote rebasing of feature branches, and
while that may work well, it can lead to holes in the history of the review
process due to the need to force-push.

That said, we are nearing a stabilized core API and have plans to allow for
more flexibility in the process. If you are interested in following our ideas
behind this, feel free to follow the issue we have open:
[https://github.com/reenhanced/gitreflow/issues/53](https://github.com/reenhanced/gitreflow/issues/53)

------
juped
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!

~~~
jerf
"bisect". Bisect becomes useless if not every commit compiles (or local
equivalent). Bisect is a critical feature, even if I don't necessarily use it
often, because when I need it, I _need_ it.

As long as I can bisect, I don't much care about the details. But this is
definitely not compatible with three dozen commits mostly consisting of "oops
didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do
something about that.

The way some people talk, the only acceptable history is an asciinema [1]
recording of the development process with a microphone recording the
developer's mutterings as it goes. The question isn't about what information
you "lose" but about what you keep, because you _must_ discard the vast bulk
of it. We're arguing here about whether we chuck 99.97% or 99.99% of it.

[1]: [https://asciinema.org/](https://asciinema.org/)

~~~
_ikke_
Bisect also becomes useless because of large commits. Even if you find the
commit, the change it introduces can be so large you don't git much
improvement.

Git allows you to clean up your feature branches to prevent these kind of fix
commits.

Look at git.git. They don't require people to squash all their commits into a
single patch, but still every patch should be compilable.

~~~
jerf
"As long as I can bisect, I don't much care about the details."

If I can't bisect, I don't approve. So, by simple logic based on the premise
you supply, I also disapprove of large commits.

My point may not be what you expected prior to reading.

~~~
juped
Then your comment makes no sense in context, because you replied to my
complaint that people lose information by doing these giant squash merges and
having no nontrivial graph structure in their main project history.

~~~
jerf
There are positions other than the extremes. My position makes sense, yes, in
context too.

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

~~~
codenamev
From the README: "On your first install, you'll need to setup your Github
credentials. These are used only to get an oauth token that's stored in your
global git config. We use the Github credentials so we can create pull
requests from the command line."

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

~~~
DannyBee
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"

~~~
juped
>yfw you type `git blame --first-parent`

------
Dru89
I'm unhappy with the approval process being a simple search for "LGTM". I wish
GitHub pull requests had actual support for a review process, e.g.:

* open issues to address

* review state, such as "changes requested" or "approved" (along with users that are in each state).

We've been using Phabricator's[1] Differential tool for code reviews and it
feels superior to this process, but it would certainly be nice to have an all-
encompassing solution for this.

[1] [http://phabricator.org](http://phabricator.org)

~~~
deathanatos
An actual flag wouldn't be bad, but I know that I've sometimes given out
conditional approvals in a code review (i.e., "if you change this, then I
approve; if you don't agree, then we should talk"). The idea being to remove a
round-trip that would otherwise waste the reviewee's time. (This of course
implies a certain degree of trust that the reviewee makes the change as you
desire, but in practice I find this isn't a problem.)

------
tjbiddle
Created something in-house very similar for a job a few years ago; We could
accept a ticket, it would create a feature branch, update the ticket and
comment on it that it was being worked on, then when we submit, it would
update the ticket status - assign it to a reviewer, squash commits, create a
pull request and comment with the link.

This project seems to be done much cleaner though and in a more abstract and
reusable manner. Well done!

------
bsimpson
So...it's Gerrit's workflow for GitHub?

