GIT Development Workflow

From FirebugWiki

Revision as of 21:05, 14 October 2012

General workflow

1. Anything in the master branch is deployable
2. To implement a new feature or bug fix create a new feature branch out of master
3. Commit all your changes to the branch and push on the server
4. When you need feedback/review/help, open a pull request
5. After testing your branch by running Firebug test suite on it, merge it into master
6. When doing a release create a tag/branch off of master

1. master branch

• The master branch should be stable.
• It should be always safe to make a release from it.
• If you push changes into master, they must be tested by Firebug automated test suite and all tests must pass.
• You should feel guilty if you break the master branch.

2. Create a feature branch

When you work on a new feature (or fix a bug), create a new feature branch named after the feature or the issue number it represents.

First clone the Firebug repo:

$ git clone git@github.com:firebug/firebug.git

Create a new myfeature branch:

$ cd firebug
$ git checkout -b myfeature master

3. Commit to the feature branch

Commit all your changes into your feature branch and publish all to the public server (github.com).

Commit to myfeature branch.

$ git add <modified-file>
$ git commit -m "This is my new feature"

Push to public server into myfeature branch:

$ git push -u origin myfeature

4. Open a pull request

If you need somebody from the team to review your code, open a pull request.

5. Merge to master

After you are done with your changes you can merge your branch back to master. Since master could have changed in the meantime you should update your branch before merging and solve any possible conflicts.

Switch into myfeature branch:

$ git checkout myfeature

Get changes from master. Using rebase here will cause git to pull off the branch commits, update the branch to master, then re-apply the commits. Conflicts are easier to fix in this direction than with a merge.

$ git fetch
$ git rebase master

Solve any possible conflicts and run Firebug test suite then merge to master.

$ git checkout master
$ git merge --no-ff myfeature

Don't forget to remove your feature branch after a successful merge. It's not needed anymore.

$ git branch -d myfeature

Push to public server:

$ git push -u origin master

Delete myfeature branch on the origin remote:

$ git push origin :myfeature

6. Create a release branch/tag

When doing a minor (alpha or beta) release, create a tag at the appropriate revision that bumps up the version number. In the case of a major (final) release create a branch (e.g. firebug1.11).

Create minor version tag:

$ ./bump-version.sh 1.10.0a5
$ git commit -a -m "[firebug-1.11.0a5]"
$ git tag 1.11.0a5
$ git push --tags

Create major version branch:

$ git checkout branch firebug-1.11.0a5

Push to public server:

$ git push -u origin master

TODO: process for hot fixes in existing release branches

Recommended settings

Recommended settings in your .gitconfig file:

Entire Firebug repository should use Unix line endings.

• Windows:

   git config --global core.autocrlf true
   git config --global core.safecrlf false

• Linux:

   git config --global core.autocrlf input
   git config --global core.safecrlf false

It's also useful to have the following aliases defined in your .gitconfig

[alias]
  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short