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>

-

+

=== 2. Commit to the feature branch ===

-

=== 3. Commit to Feature Branch ===

+

Commit all your changes into your feature branch and publish all to the public server ([http://github.com github.com]).

-

Commit all your changes into your feature branch and publish all the the public server (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 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.

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 -a 1.10.0a5

+

$ git tag 1.11.0a5

-

</pre>

+

$ git push --tags

+

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

+

+

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

+

+

=== 2. Fix the bug ===

+

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.

+

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

-

TODO: process for hot fixes in existing release branches

+

=== 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 <code class="label">port-&lt;previous Firebug version&gt;</code> label to <code class="label">ported-&lt;previous Firebug version&gt;</code>.

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