
Ask HN: Do you branch? - tehwebguy
Looking for some use cases from people that use git branches effectively.<p>Do you branch when you are building a new feature? Or only when you are making major changes? Or never? What about deployment, do you have a specific branch for Heroku or AWS?
======
angersock
At my current company, we use a lightly-modified GitFlow workflow:

[https://www.atlassian.com/git/workflows#!workflow-
gitflow](https://www.atlassian.com/git/workflows#!workflow-gitflow)

Previously, at my startup, we used long-running feature branches and merged to
mainline as seemed reasonable.

Branches are pretty much the only reason to use git--and a damned fine reason
they are.

~~~
tehwebguy
That link is awesome, I haven't locked down a comprehensive workflow yet and
this helps a lot.

~~~
angersock
No problem!

------
integraton
See "github flow": [http://scottchacon.com/2011/08/31/github-
flow.html](http://scottchacon.com/2011/08/31/github-flow.html)

------
RossM
Sole developer on my project, but I run something like this (looking forward
to see if it scales to multiple developers).

    
    
        - master (deployed/live version)
          - develop (next version)
            - feature/* (feature branch)
              - feature/*/* (optional sub-branches for big features)
            - fix/* (bugfix branch, may be off master if urgent)

------
clockwork_189
Yes. We use branches a lot at our startup. Typically our workflow goes as
follows:

1) git checkout master

2) git pull // to fetch latest version

3) git branch _issues /feature name_

4) git checkout _branch name_

//...do work on branch...//

5) git add .

6) git commit -m "Description of commits"

7) repeat 5) and 6) until feature/issue is fully implemented/fixed

8) git push origin _banch name_

9) git checkout master

10) git merge _branch name_ // only after the issue/feature is tested and
debugged

11) git push origin master

------
stevoo
We use mercurial. For anything that is not a small fix we branch it off. It is
extremely easy, and if that doesnt work you just kill that branch and you
don't worry about anything. If you are a team of 12 then branching is
definetely easier than having everyone constantly pushing into the live system

------
amykhar
At one company, we use the Development, Test, Beta and Master branches unless
we are working on a major, long-term feature. Then, we create a special branch
for that. At the other company, we use one branch for every FogBugz case. They
both work just fine.

------
smileysteve
Yes.

Master

QA/Staging that tracks master (but can be merged to first for staging
environment testing)

Feature/Release branch (once the project is stable, these are more granular)
get merged into QA/Staging first.

~~~
smileysteve
QA/Staging can also be used as a place where features that are functional, but
not complete can be tested.

------
fragmede
Yes? Branching (and the speed with which "git checkout -b" runs) is half the
point of git!

(Never going back to the bad old days of 'branching' in SVN.)

