GIT Development Workflow

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Added info for what to do when a wrong commit message was added)
(5 intermediate revisions not shown)
Line 1: Line 1:
-
== General Workflow ==  
+
== Recommended settings ==
 +
Recommended settings in your ''.gitconfig'' file:
 +
 
 +
Entire Firebug repository should use Unix line endings.
 +
 
 +
* Windows:
 +
<syntaxHighlight lang="bash">
 +
  git config --global core.autocrlf true
 +
  git config --global core.safecrlf false
 +
</syntaxHighlight>
 +
 
 +
* Linux:
 +
<syntaxHighlight lang="bash">
 +
  git config --global core.autocrlf input
 +
  git config --global core.safecrlf false
 +
</syntaxHighlight>
 +
 
 +
It's also useful to have the following aliases defined in your ''.gitconfig''
 +
 
 +
<syntaxHighlight lang="ini">
 +
[alias]
 +
  co = checkout
 +
  ci = commit
 +
  st = status
 +
  br = branch
 +
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
 +
</syntaxHighlight>
 +
 
 +
== General workflow ==  
# Anything in the <code>master</code> branch is deployable
# Anything in the <code>master</code> branch is deployable
-
# To implement a new features or bug fix, create a new feature branch off of <code>master</code>
+
# To implement a new feature or bug fix create a new feature branch out of <code>master</code>
# Commit all your changes to the branch and push on the server
# Commit all your changes to the branch and push on the server
-
# When you need feedback/review/help open a pull request
+
# When you need feedback/review/help, open a pull request
# After testing your branch by running Firebug test suite on it, merge it into <code>master</code>
# After testing your branch by running Firebug test suite on it, merge it into <code>master</code>
# When doing a release create a tag/branch off of <code>master</code>
# When doing a release create a tag/branch off of <code>master</code>
-
 
+
=== <code>master</code> branch ===
-
=== 1. Master Branch ===
+
* The <code>master</code> branch should be stable.
-
* The master branch should be stable.
+
* It should be always safe to make a release from it.
* 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.
+
* 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 <code>master</code> branch.
* You should feel guilty if you break the <code>master</code> branch.
 +
=== Wrong commit messages for fixes ===
 +
If you accidentally added the wrong commit message to a patch for an issue:
-
=== 2. Create Feature Branch ===
+
# Revert your changes using <code>git revert</code>. Add the following message to the revert commit: <code>"Backed out <commit hash> for wrong bug number/commit message"</code>
-
When you work on a new feature (or fixing a bug), create a new ''feature'' branch.
+
# Reland your patch with the correct commit message.
-
First clone Firebug repo:
+
Doing so avoids confusion when looking at blames/lists of commit messages.
-
<pre>
+
 
 +
== Working on a feature ==
 +
=== 1. 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:
 +
<syntaxHighlight lang="bash">
$ git clone git@github.com:firebug/firebug.git
$ git clone git@github.com:firebug/firebug.git
-
</pre>
+
</syntaxHighlight>
Create a new <code>myfeature</code> branch:
Create a new <code>myfeature</code> branch:
-
<pre>
+
<syntaxHighlight lang="bash">
$ cd firebug
$ cd firebug
$ git checkout -b myfeature master
$ git checkout -b myfeature master
-
</pre>
+
</syntaxHighlight>
-
 
+
-
=== 3. Commit to Feature Branch ===
+
=== 2. Commit to the feature branch ===
-
Commit all your changes into your feature branch and publish all the the public server (github.com)
+
Commit all your changes into your feature branch and publish all to the public server ([http://github.com github.com]).
Commit to <code>myfeature</code> branch.
Commit to <code>myfeature</code> branch.
-
<pre>
+
<syntaxHighlight lang="bash">
$ git add <modified-file>
$ git add <modified-file>
$ git commit -m "This is my new feature"
$ git commit -m "This is my new feature"
-
</pre>
+
</syntaxHighlight>
Push to public server into <code>myfeature</code> branch:
Push to public server into <code>myfeature</code> branch:
-
<pre>
+
<syntaxHighlight lang="bash">
$ git push -u origin myfeature
$ git push -u origin myfeature
-
</pre>
+
</syntaxHighlight>
 +
=== 3. Open a pull request ===
 +
If you need somebody from the team to review your code, [http://help.github.com/send-pull-requests/ open a pull request].
-
=== 4. Open a Pull Request ===
+
=== 4. Merge to <code>master</code> ===
-
If you need somebody from the team to review your code [http://help.github.com/send-pull-requests/ open a pull request].
+
After you are done with your changes you can merge your branch back to <code>master</code>. Since <code>master</code> could have changed in the meantime you should update your branch before merging and solve any possible conflicts.
-
 
+
-
TODO: some screenshots from github.com explaining how to create 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 merge and solve any possible conflicts.
+
Switch into <code>myfeature</code> branch:
Switch into <code>myfeature</code> branch:
-
<pre>
+
<syntaxHighlight lang="bash">
$ git checkout myfeature
$ git checkout myfeature
-
</pre>
+
</syntaxHighlight>
-
Get changes from master. Using rebase here will cause git to pull off the branch commits,
+
Get changes from <code>master</code>. Using rebase here will cause git to pull off the branch commits, update the branch to <code>master</code>, then re-apply the commits. Conflicts are easier to fix in this direction than with a merge.
-
update the branch to master, then re-apply the commits. Conflicts are easier to fix in this direction
+
<syntaxHighlight lang="bash">
-
than with merge.
+
-
<pre>
+
$ git fetch
$ git fetch
$ git rebase master
$ git rebase master
-
</pre>
+
</syntaxHighlight>
Solve any possible conflicts and run Firebug test suite then merge to master.
Solve any possible conflicts and run Firebug test suite then merge to master.
-
<pre>
+
<syntaxHighlight lang="bash">
$ git checkout master
$ git checkout master
$ git merge --no-ff myfeature
$ git merge --no-ff myfeature
-
</pre>
+
</syntaxHighlight>
-
Don't forget to remove your feature branch after successful merge. It's not needed anymore.
+
Don't forget to remove your feature branch after a successful merge. It's not needed anymore.
-
<pre>
+
<syntaxHighlight lang="bash">
$ git branch -d myfeature
$ git branch -d myfeature
-
</pre>
+
</syntaxHighlight>
Push to public server:
Push to public server:
-
<pre>
+
<syntaxHighlight lang="bash">
$ git push -u origin master
$ git push -u origin master
-
</pre>
+
</syntaxHighlight>
 +
Delete <code>myfeature</code> branch on the <code>origin</code> remote:
 +
<syntaxHighlight lang="bash">
 +
$ git push origin :myfeature
 +
</syntaxHighlight>
-
=== 6. Create a Release Branch/Tag ===
+
== Create a release branch/tag ==
-
When doing a minor (alpha or beta) release create a tag at appropriate revision that bumps up the version number. In case of a major (final) release create a branch (e.g. <code>firebug1.10</code>)
+
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. <code>firebug1.11</code>).
Create minor version tag:
Create minor version tag:
-
<pre>
+
<syntaxHighlight lang="bash">
$ ./bump-version.sh 1.10.0a5
$ ./bump-version.sh 1.10.0a5
-
$ git commit -a -m "[firebug-1.10.0a5]"
+
$ git commit -a -m "[firebug-1.11.0a5]"
-
$ git tag 1.10.0a5
+
$ git tag 1.11.0a5
$ git push --tags
$ git push --tags
-
</pre>
+
</syntaxHighlight>
Create major version branch:
Create major version branch:
-
<pre>
+
<syntaxHighlight lang="bash">
-
$ git checkout branch firebug-1.10.0a5
+
$ git checkout branch firebug-1.11.0a5
-
</pre>
+
</syntaxHighlight>
Push to public server:
Push to public server:
-
<pre>
+
<syntaxHighlight lang="bash">
$ git push -u origin master
$ git push -u origin master
-
</pre>
+
</syntaxHighlight>
 +
== Hot fixes ==
 +
When there are issues that should be fixed in point releases you need to backport your patch to the branch for the previous release.
-
TODO: process for hot fixes in existing release branches
+
=== 1. Create an issue ===
 +
If there is no issue for the bug yet, create an issue for it, so it can be tracked. Mark the issue with the label <code class="label">port-&lt;previous Firebug version&gt;</code>, so e.g. <code class="label">port-1.11</code>.
-
== Recommended Settings ==  
+
=== 2. Fix the bug ===
-
Recommended settings in your ''.gitconfig'' file:
+
Make the necessary changes for the bug and commit your changes to the <code>master</code> branch. Mark the issue with the status <code class="label">Commit</code> and set yourself as owner as you normally do.
-
Entire Firebug repository should use Unix line endings.
+
=== 3. Port the bug ===
 +
To fix the bug for the next point release you need to port it to the other branch. To do so switch to the version branch, cherry-pick the patch to it and push your changes to the branch.
-
* Windows:
+
=== 4. Mark the issue as ported ===
-
<pre>
+
When you ported the patch don't forget to mark the issue as ported. To do so change the <code class="label">port-&lt;previous Firebug version&gt;</code> label to <code class="label">ported-&lt;previous Firebug version&gt;</code>.
-
  git config --global core.autocrlf true
+
-
  git config --global core.safecrlf false
+
-
</pre>
+
-
 
+
-
Linux:
+
-
<pre>
+
-
  git config --global core.autocrlf input
+
-
  git config --global core.safecrlf false
+
-
</pre>
+
-
 
+
-
It's also useful to have following aliases defined in your ''.gitconfig''
+
-
 
+
-
<pre>
+
-
[alias]
+
-
  co = checkout
+
-
  ci = commit
+
-
  st = status
+
-
  br = branch
+
-
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
+
-
</pre>
+

Revision as of 07:11, 18 February 2013

Contents

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

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

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.

Wrong commit messages for fixes

If you accidentally added the wrong commit message to a patch for an issue:

  1. Revert your changes using git revert. Add the following message to the revert commit: "Backed out <commit hash> for wrong bug number/commit message"
  2. Reland your patch with the correct commit message.

Doing so avoids confusion when looking at blames/lists of commit messages.

Working on a feature

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

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

3. Open a pull request

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

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

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

Hot fixes

When there are issues that should be fixed in point releases you need to backport your patch to the branch for the previous release.

1. Create an issue

If there is no issue for the bug yet, create an issue for it, so it can be tracked. Mark the issue with the label port-<previous Firebug version>, so e.g. port-1.11.

2. Fix the bug

Make the necessary changes for the bug and commit your changes to the master branch. Mark the issue with the status Commit and set yourself as owner as you normally do.

3. Port the bug

To fix the bug for the next point release you need to port it to the other branch. To do so switch to the version branch, cherry-pick the patch to it and push your changes to the branch.

4. Mark the issue as ported

When you ported the patch don't forget to mark the issue as ported. To do so change the port-<previous Firebug version> label to ported-<previous Firebug version>.

Personal tools