Best workflow with Git & Github

Question

I'm looking for some advice on how to properly structure the workflow for my team with Git & GitHub.

We are recent svn converts and it's kind of confusing how we should best set up our day-to-day workflow.

Here is a little background: I'm comfortable with command line and my team is pretty new to it but can follow use commands. We all are working on the same project with 3 environments (development, staging, and production). We are a mix of developers & designers so some use the git GUI and some the CLI.

Our setup in svn went something like this:

• We had a branch for development, staging and production.
• When people were confident with code they would commit and then merge it into the staging.
• The server would update itself and on a release day (weekly) we would do a diff and push the changes to the production server.

Now I set up those branches and got the process with the server running but its the actual workflow that is confusing the hell out of me.

It seems like overkill that every time someone makes a change on a file they would create a new branch, commit, merge, and delete that branch. From what I have read they would be able to do it on a specific commit (using the hash), do I have that right? Is this an acceptable way to go about things with Git?

Any advice would be greatly appreciated.

Answer 1

The ideas to keep in mind when working with a DVCS are:

• distribution: even if you have one central GitHub, the developper are not limited to publish (push) only to that GitHub repo. They can fork the repo and publish in their own version (while fetching from the official central GitHub repo -- called "upstream").
  The advantage is they can rewrite history (reset, rebase --onto, rebase -i, ...) as many times as they want, in the end, they will make a pull request, allowing an integrator to manage their changes.

• one of publication: in your own local repo, you can setup as many branches as you want (not one for every file modification, of course, but one for any new task or set of tasks you need to develop).
  But you can also set public branches that will be pushed ("published") to your remote repo.
  See this question on Git workflow, and also JC Hamano's articles on remote branches:
  o Fun with remote branches (1)
  o Fun with remote branches (2)
  The phrase "When people were confident with code they would commit and then merge it into the staging" should not apply with a DVCS: commit early, commit often, but push ("publish") only when you want.

Answer 2

Great post on GitHub Workflow by one GitHub creators Scott Chacon and author of mentioned Pro Git book :P

Answer 3

Depending on your workflow, you can have a few 'important' branches on your central repository (ie. on github) which people can clone locally. These would correspond to 'stable', 'beta', 'development' etc. A nice article on a possible set of branches is this.

Once that's done, you can let people use their own strategy. I prefer to keep topic branches for major projects and have one called 'quick-fixes' for quick things I need to do. If you have a team working on a major project which they want to keep on a separate branch cut off from the main repo, you can let them do it without any intervention. If people prefer having lots of tiny branches to try things out etc, they can do that too.

As for automatically testing and integrating into production from staging, you can either configure the git hooks to do that or have a system running that will do it for you at regular intervals and report issues.

Answer 4

You can copy your workflow from svn verbatim. Git can do everything svn can (but it can do more than that!). But your workflow could be improved in spite of CVS used.

If you want to keep number of branches minimal (which in case you're new to git would in fact simplify things) in the workflow you have described I'd suggest to have (instead of one development branch) three per-developer branches: devel-john, devel-mary, etc:

devel-john >--\
               \
devel-mary >------> staging ---> production
               /
devel-peter >-/

This is convenient: all development changes would be pushed to central repository (which is often a good thing even for git) without conflicts and merged anytime by anyone who's willing/obliged to do the merging (for example into the staging branch).

Answer 5

There are also some project workflows described in the ProGit book that show the Git commands developers will use to follow daily.

There is a well regarded Git branching model described at http://nvie.com/git-model