Hacker News Reader

This is the workflow we've adopted at my company. There are 2 types of commits, you either want to release some new feature or bit of work and do it atomically, or you want to develop the feature, fix typos and throw it between machines without a care.

Is it ever going to help anyone to `git blame` a line of a file and see a commit message like "Whoops, fixed a typo!"? No. But you can't avoid those types of commits.

What you can do is prevent those commits from going into the released history of the product. We develop all new features in feature branches (made _very_ easy with the commandline tool we built for it) and only after code review and acceptance testing do we squash merge it to master.

This lets us put together all of the commits, typo commits, WIP commits and whatever else into a combined commit that contains all of the changes that make up that feature. We even enforce a special syntax on the commit so when you look back in the history, you can trace it back to the code review and to the actual ticket that requested the work.

This means we keep all of our dirty backup commits until release time when we throw them all away in favor of the squashed commit. It makes git blame on any line of any file a sexy experience that provides accountability and an easy way to figure out why the code is the way it is.

Our commandline tool automates a lot of this for us. It's biggest benefit is the tie in with github (and this week bitbucket) to create pull requests and the "deliver" command that handles squash merging and providing the structure for the final commit.

It's all open source and available here: http://github.com/reenhanced/gitreflow/

We prevent force pushes to the remote, so if you need to rebase commits that are on the remote already, you'd have to delete the branch from the remote and re-push, and that closes the PR, which confuses reviewers and causes spurious notifications.

Do you merge master into feature branches between the time the feature branch is first pushed to the remote and when they are reviewed and ready to merge? Can your command line tool handle creating a squashed commit when master has been merged into the feature branch a few times?

Yes, master is merged into the feature branches before going upstream. We consider it to be the responsibility of the feature branch owner to make sure their code will work with master.

Because we don't care about the commits on the feature branches, we prefer doing a regular merge, not a rebase of the feature branch, so that there's no need for force pushing at any point. We consider a force push of any kind to be unnecessarily dangerous.

The tool will handle the merge up for you, but if there are conflicts you'll have to resolve them before you can release the feature.

In your flow, how would you update a pull request branch to fix a typo? Make extra commits and normal push?

and how would you update a pull request branch to contain the latest master? Merge back and forth?

From the looks of it, this tool is made for the force-push flow, which doesn't suit you. See https://github.com/reenhanced/gitreflow/issues/52

Squash merging is only of the feature branch to master. If your feature branch makes it through code review and acceptance and you still need to update the typo, then you make the commit to master directly.

It would be great if we could be perfect, but sometimes small commits to master do have to happen. All we do is make sure we subject every feature to code review and acceptance before it gets to master. If it slips through, then it's technically a new change request in our eyes

git diff?

Interestingly, I have two different version control systems for doing these two different species of commit. The published kind, I do in my regular team version control system, complete with commit comments that explain the meaning of the complete thought that is being committed. The other kind (bookmarking my state before messing around with things I may want to cleanly revert) I do using the version control that is built into IntelliJ IDEA. It is completely orthogonal to the one used by my team.

Other IDEs should offer this feature... it turns out to be quite useful in practice.

Xcode offers this feature:

http://tewha.net/2012/01/ive-changed-my-mind-about-xcode-sna...

Netbeans also has a local history recording feature which is integrated pretty well alongside the git/vcs features (just hit history on any file and see a log of all your local changes intermingled with the committed versions).

I think most IDEs nowadays have a local history. The Eclipse one let you compare between revisions like if it were a local git repo, which is useful sometimes.

I really like this approach, you can take it one step further. Set up an automatic independent (aka private) commit after every successful compile.

IntelliJ, when you combine the internal version control and the undo log, manages it so that effectively there is a commit after each piece of typing -- without any need to save or even compile. That turns out to be a nice way of working.

You could easily do this entirely in git. Create a microfeature branch, work in it, and when you've got something you want to commit as a feature, squash and merge onto the feature branch.

> You can really have two "species" of commits:

That's what Mercurial phases are:

http://mercurial.selenic.com/wiki/Phases

"Knowing the benefits of this approach, I don't understand why anyone would want to reject it."

It's always difficult to have these kinds of conversations in the abstract, but for me it's a slightly cumbersome distraction (unless you don't write commit messages). But if it works for you, you should certainly keep doing it. I tend to divide stuff into small chunks so never work on something for long without something that can be committed.

Most usually I still do write commit messages, and that's actually an important additional value of this workflow for me. That said, the commit message is again often a quick and raw: usually a quick in-progress summary of the most important work in the commit, but not perfected at all - just quick something, can have errors, ignores all Commit Message Guidelines like length or whatever. One benefit is, as well noted in other post in the thread, that it will remind me "what the hell was I thinking doing that" when I look at it tomorrow. Second one, obviously, is to help distinguish those commits when doing any sculpting/molding later (i.e. "git rebase -i" & "git cherry-pick" & "git merge --squash").

But that, as I said, is most usually. Sometimes, as you considered, I do write just "WIP" or "dump of current state". The second one, mostly when I already don't remember WTF was I doing here... (i.e. when I forgot to commit month ago and left some stuff on the table). The first one... I'm not sure now. But I know I sometimes do; with some guilt too; but usually the need for having that particular stuff committed is stronger than the guilt...

So, still can't really understand why anyone would want to reject it :) but that said, thanks a lot for expressing your approach. As much as it still puzzles me :)

Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?

Yeah, Mercurial phases handles this:

http://mercurial.selenic.com/wiki/Phases

Why would this be advantageous?

If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something?

In addition, git has a staging area (git add), which I use to stage intermediate steps of work.

It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.

> If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something?

It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.

As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).

You can do that with autosquash https://coderwall.com/p/hh-4ea

Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.

No, but this explains a nice trick to use it without remembering the commit message http://technosorcery.net/blog/2012/08/05/updated-git-rebase-...

With that you can do:

    git fixup HEAD~2

It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.

If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.

What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?

You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.

I would like to commit on every keystroke + a mechanism to hierarchically group commits.

this is what I use a "$YOURNAME$-dev" branch for. all my hacks / etc go there and only "proper" work gets merged upstream.