What kind of Git workflow suits our case?

Question

We have currently just master branch. Our current workflow involves implementing the features locally, committing to the repository and updating the test server, letting the client know about it and if he approves the changes we also update the production.

The thing is that now we use SVN and we update manually the specific folders and files that we have changed because otherwise we might get unwanted changes to production. With Git as our near-future repo that we use for one project already, what kind of Git workflow/branching would suit our need? The Git workflow needs to work well for this scenario:

1. Do your work locally.
2. Update test server and let client know.
3. If client approved the changes, update the production as well.

Ideally we would want it to be possible to update the production to a specific tag all files and folders at once. It's possible that test and production have several different changes from many developers and some of them need to be moved to production some not.

Initially I thought of having 3 branches master for production stable releases, test for the test server (to be merged to from dev) and dev where we code. I'm not sure if this fits well.

Answer 1

(each commit is represented by a circle). (dotted lines: extra merges required)

Prologue

• This thing is written fast, and definitely have mistakes but should give a good overview of the approach.

Overview

We have a use-case very similar to yours, and this is the most optimized solution that we've found until now.

You will need 3 different branches:

1. master (this is your main branch, all the -- useful -- code that developers write comes here at last)
2. production

3. pre-release -> this is a temporary branch. it's there between the time that you are demoing something to the client and the time that that thing goes to the production server.

   • take note that production and pre-release are eventually both an older version of master branch, i.e. master excluding some of its the latest changes. So any changes that are directly made to pre-release(based on client request) should be merged to master. also any changes in the production branch (critical bug fixes) should be merged to master branch as well as the pre-release branch if it's active. This is the most important thing to consider, otherwise you'll end up in a mess very similar to having more than one code base in one git repository.

For routine tasks:

The developer Foo would:

git pull 
git checkout -b new_feature

and then writes her code and commits often to the new_feature branch. Once she's done:

git pull << to get the latest changes on master (in the picture you see Foo's branch is 2 commits behind master's ~HEAD)
git rebase -i master << -i to be interactive, so she can pull out some of the local changes she's made e.g. local changes config files or customized loggers for her own benefit, etc.
git merge --no-ff master << merge the changes with master
git push << push to the repository

Test server:

Once you're good enough for testing/demoing to client, you can create a temporary branch:

git pull
git checkout master
git checkout -b pre-release

You may need to have some custom configs for your test machine so you can have a branch (test_server_local_changes) and serve it to the user. when you have new pre-release branch then do: git pull and git rebase -i pre-release

At this stage if a client asks for changes, a developer should branch out from pre-release and, after making changes merges, merges his branch with both master and pre-release.

Production server:

Once your client approves the changes:

git pull and git checkout production and git rebase pre-release

You may want to serve production branch. Or if you have custom changes specific to your production server, it's better to have a separate branch for it (production_local_changes) with a couple of extra changes and always rebase it on production branch.

Critical Bug fixes:

Suppose someone will find a critical bug in your production server, then Bob will create a branch from production branch, fix the bug, commit it and then merge his branch with production server and then pull and rebase the prodction_local_changes. But then, the change will not be present in the master, so he will also need to merge with master as well, also with pre-release if it's active and rebase test_server_local_changes.

Notes

• In my opinion in git (unlike SVN as I remember those ugly days of using it) users should branch whenever necessary and commit as often as it makes sense.

• Each user can and should have his local branch having all his own configurations and merge it or do cherry-pick first thing when they branch off from any of 3 main branches. They can always rebase -i and remove their own local changes before they merge back to any of those 3 branches. Same goes for production and pre-release branchs, there should be a branch off them for all the configurations that are local to each.

• I love gitolite and I think it's a good tool to use on top of git to manage permissions, have a kind of a central repo and make using git easier.

Answer 2

It looks like, that you do not need 3 branches, but more like at least 2 repositories. Each developer hes its own at least local repository and everybody has access for pulling and this is "dev branch". Then there are testers that has to know which commits to test, and testing team is responsible to maintain official repository with working commits. (Total number of repositories = number of members + 2)

Having single repository and 3 branches (master,test, dev) is not that good idea, because your product will eventually evolve and you will get new features (use branches for that), versions (branches and tags) and different people will contribute to source code (more branches).

Answer 3

In my opinion, you wouldn't necessarily need branches for each server - this can create (depending on your ignores and some other factors) some issues when cascading changes up and down. Instead, your various servers can just have a branch checked out and changes pulled to it. The server having a complete copy of the repository is very, very useful.

Our ecosystem initially included branches for every server, production, staging, and development - syncing changes between the branches sometimes created merge issues that were very frustrating. We currently have all of the servers with the production branch checked out, and we've saved ourselves quite a few headaches. We check everything there before actually pulling on the production server - you can also switch branches if needed to test more drastic coding changes. There's a lot of flexibility there.

My suggestion would be to evaluate your workflow and see if you can leverage hooks to automate the process of updating your test/staging servers. We do this wonderfully with gitolite. Otherwise, your workflow is easily achieved, and you can put some polish on the concept to automate it further.