Hacker News Reader

Comment by brown9-2 | Hacker News Reader

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?

View on HN

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.

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.

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. :)

Reply on news.ycombinator.com