Hacker News Reader

Comment by KirinDave | Hacker News Reader

Git flow is a great tool as a starter to teach people what a reasonable git workflow is. Once you understand got better, you may find it a bit constraining.

Personally, I don't see why you shouldn't work out of master and make release tags. The develop branch seems like an extra step that is unnecessary. But I suppose if your team is quite large it makes sense.

EDIT: Please not I am not suggesting that you not do feature branching. That is an awesome and compelling feature of git. I just don't see the need for a second branch just for developing in general in. That's what master has traditionally been for.

And yes, you can branch and redo tags at any time. If you don't know this, you probably don't understand git's underlying model very well. Time to read up: http://www.google.com/search?q=explanation+of+git+internals

View on HN

If you develop directly in master, then how can you go back and fix a severe bug in the version of the code that is in your production site without having to revert all the in-progress development changes or risk introducing them into the bugfix? I believe this is the intent of not working in master.

If you tag each release, does git allow you to checkout by that tag and then start making commits to it / make a new branch from it? I could be wrong but I thought tags in git were basically just read-only and informational - can you start work from them?

I develop in master sometimes, but only check in small edits that are pushed immediately.

If my edits grow to the point that I need to write tests or push to staging, I just checkout a feature branch before committing.

If you are using git-flow, this should probably be done in a hotfix branch, so that when you are done, finishing your hotfix merges directly to master and develop. Without a hotfix you would have to manually merge master back into develop.

It sounds like git-flow removes some hassle, can anyone answer the question about adding git-flow to an existing repo?

Running `git flow init` in an existing repository will ask you which branches you want to use as master- and development branches. So, yes. :)

Yes, you can create a new branch from any tag (or indeed any commit).

Going a bit further, when you create a branch, what you're specifying is a starting point for that branch which will be a commit. The commit may be referenced via a tag, as the head of a branch (when you give the branch name or the head of the current one by default), or by the commit itself.

It's not hard (not claiming it's sensible, but still). Do gitk --all, walk back to the tag, right click and create a new branch. This is even possible if there was no tag (just a recognizable revision), or if you want to create a tag retroactively.

There's a psuedo-branch in master, which is "everything since the latest commit that has been pushed out". (This is my own terminology, so don't go Googling for it.) This is the branch that becomes "real" once pushed to the public, and that's when you can no longer rewrite the history without hurting things.

If you are disciplined, it's ok to build on master, but once you realize you need a branch (3 or 4 commits in), it's really easy to deal with. You branch from master, re-checkout master, and git reset --hard back to the public psuedobranch. And it is as if you had a branch all along.

I play the same game with git svn sometimes, except the psuedobranch is the "stuff that has not yet been committed to SVN" and it's a lot more clear where the cutoff is. I won't pretend this is perfect, but it does work.

(The problem I have with branching off for absolutely everything is that I find it easy to end up with too many branches to remember what's what. Granted, I'm the team lead and I may be more prone to that than a team member with more defined tasks.)

There's no need for any custom terminology: Your master branch isn't a pseudo-branch. It's just another branch that happens to live in your local repository and shares the same name as the remote repository's branch that it tracks.

its actually very easy.

You develop on master. if you need s 'stabilisation' phase, when you only do bugfixes you can do that on a release branch. Or if you usually deploy the latest you can just tag the version that you deploy. If you want to just fix something from the currently deployed version you can create a 'hotfix' branch out of the tagged release version, do the fix, deploy, merge the hotfix branch into master and delete it:

    git branch hotfix v1.2.3
    git co hotfix
    # do the fix
    git tag v1.2.4
    # deploy
    git co master
    git merge hotfix
    git branch -d hotfix

Is there a reason to delete the branch? I don't think I've ever tried to delete a branch in subversion. I imagine it's possible, and can be reversed if necessary, but goes against my thinking of the repository as a canonical log of all development.

Since branches are supposed to be mutated all the time, and don't keep any history about where they were earlier, it's quite reasonable to delete branches.

Commits are what's fixed. Branches are basically just mutable pointers to commits.

No relevant information is lost. You're basically only deleting the reference, which is only a name. As long as you don't explicitly destroy the commits (eg. with a squashing merge or a rebase) the branch will still exist in the repository structure. The commits won't be GCd because they're merged to another branch which has an explicit reference (master).

You can at any time go back to it as long as you know the SHA-1 identifier for the head commit you want. Because of this, there's little reason to keep temporary refs cluttering the ref namespace.

If you really want to keep references to everything, a "git attic" tool exists which allows you to move branch refs out from the main ref namespace into a normally invisible (ie. doesn't show up in git branch etc.) namespace.

Master exists as a pristine releasable code base. Develop is the main branch for working on things, and branching usually happens from there. Having master and develop lets you keep developing on your project while having a frozen deployable branch master in this case.

My question is, why is this (develop/master) better than master/release branches? Or master/qa/production? Or do you view that as just an arbitrary choice of names (since there's nothing special about the master branch in git)?

I would prefer not calling any branch master when using a specific scheme like this. It's confusing. Master of what? The master development branch? The master release branch? Better to name each branch specifically.

what is your equivalent of:

git checkout -b hotfix master

The master/develop model gives you a pointer to the latest release for free. The pointer is called master.

Without the 'extra' develop branch, you have to remember or lookup the name of the latest release if you want to make a hotfix, or keep an extra tag for it, in which case the two models are the same.

Reply on news.ycombinator.com