Git Branching Model

Development happens on the master branch. Commit as often as you want, then push the changes to the repository, fetch it on the development server and test it. Once finished with development, switch to the sandbox branch in the local or development environment, merge the changes in from the master and push them. Update the staging site. hand over the project to the customer so that he can test and provide feedback, which needs to be implemented in the master branch. Repeat this step as often as necessary.

Once everything has been tested, merge the staging branch into production on the dev or staging environment and push the changes. It is important to do this step not on the production server because it could result in a merge conflict (e.g. when there were bugfix commits on the production branch, see below). Resolving them first and ensuring a fast-forward merge on the production server helps to keep the downtime as low as possible.

Below are detailed descriptions for the mentioned cases in the image.

Releasing a new project

Make sure you have the most recent code.

git checkout master

git pull

Create a new branch called staging

git checkout -b staging

Push branch and set upstream

git push -u origin staging

Now switch to the staging server and clone the project using the staging branch.

git clone --branch staging [email protected]:web-example-com/web.git

Then set up as usual. Replace staging with production for the production workflow.

Alternatively, if the server is already using git, you need to switch to the branch. As always, make sure there are no local chances. If there are, clean them up.

git status

Fetch the most recent code from the repository and checkout/switch to the production branch

git fetch

git checkout production #(Git 1.7 +)

git checkout -b production origin/production (older git versions)

New feature

Make sure you are on the master branch and have the most recent code.

git pull

git status

Develop, once finished:

git status

Look through your changes, make there aren't any obvious errors

git diff

Commit to master branch and push

git commit -a -m "Meaningful commit message, refs #123" (#issue number in chiliproject)

git push

Check out on development server, test. then merge into staging branch to prepare the customer handover. Make sure to switch back to the master branch locally immediately, to avoid accidental commits on the wrong branch.

git checkout staging

git merge master

git push

git checkout master

Then update using git pull.

Production bugfix

It is sometimes necessary to fix an urgent bug in the production code while you have a large amount of new changes in the master branch. This is the only case where working directly on the production branch is allowed. Make sure you have no pending changes # git status

Switch to production branch and make sure you have the most recent code.

git checkout production

git pull

Fix bug, then commit

git commit -a -m "Description, fixes #333"

git checkout master

Switch to production branch on staging/testing environment. If development has schema changes, a db restore might be necessary

git checkout production

git pull

Verify that bug is fixed, then git pull on production and merge changes into master branch.

git checkout master

git merge production

Alternatively, you can also pick a single commit from a production branch and add it to the current branch.

git cherry-pick 4aefb7a # git hash is visible in git log and is displayed after git commit.