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

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