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 <i>feature</i> a line code was for. I want to know <i>why</i> 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.<p>When I think I'm done with a feature is exactly the time that metadata becomes relevant! Why would I want to lose it?<p>If anything, I wish ides would integrate git-blame more into my visualisation of a file<p>But there are so many people into it, that I feel I must be missing something obvious and it bothers me.
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.<p>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.<p>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: <a href="https://github.com/reenhanced/gitreflow/issues/53" rel="nofollow">https://github.com/reenhanced/gitreflow/issues/53</a>
Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News.<p>Something is deeply wrong with the ecosystem when people want to do things like this!
From the README:<p><pre><code> $ 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!
</code></pre>
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.
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.:<p>* open issues to address<p>* review state, such as "changes requested" or "approved" (along with users that are in each state).<p>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.<p>[1] <a href="http://phabricator.org" rel="nofollow">http://phabricator.org</a>
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.<p>This project seems to be done much cleaner though and in a more abstract and reusable manner. Well done!