GIT Development Workflow
From FirebugWiki
| Line 9: | Line 9: | ||
| - | === Master Branch === | + | === 1. Master Branch === |
* The master 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. | ||
| Line 16: | Line 16: | ||
| - | === Feature | + | === 2. Create Feature Branch === |
| - | When you work on a new feature or fixing a bug, create a new ''feature'' branch. | + | When you work on a new feature (or fixing a bug), create a new ''feature'' branch. |
First clone Firebug repo: | First clone Firebug repo: | ||
| Line 30: | Line 30: | ||
</pre> | </pre> | ||
| - | Commit all changes into your feature branch | + | |
| + | === 3. Commit to Feature Branch === | ||
| + | Commit all your changes into your feature branch and publish all the the public server (github.com) | ||
| + | |||
| + | Commit to <code>myfeature</code> branch. | ||
<pre> | <pre> | ||
$ git add <modified-file> | $ git add <modified-file> | ||
| Line 36: | Line 40: | ||
</pre> | </pre> | ||
| - | Push to public server | + | Push to public server into <code>myfeature</code> branch: |
<pre> | <pre> | ||
$ git push -u origin myfeature | $ git push -u origin myfeature | ||
| + | </pre> | ||
| + | |||
| + | |||
| + | === 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 merge and solve any possible conflicts. | ||
| + | |||
| + | Switch into <code>myfeature</code> branch: | ||
| + | <pre> | ||
| + | $ git checkout myfeature | ||
| + | </pre> | ||
| + | |||
| + | 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 merge. | ||
| + | <pre> | ||
| + | $ git fetch | ||
| + | $ git rebase master | ||
| + | </pre> | ||
| + | |||
| + | Solve any possible conflicts and run Firebug test suite then merge to master. | ||
| + | <pre> | ||
| + | $ git checkout master | ||
| + | $ git merge --no-ff myfeature | ||
| + | </pre> | ||
| + | |||
| + | Don't forget to remove your feature branch after successful merge. It's not needed anymore. | ||
| + | <pre> | ||
| + | $ git branch -d myfeature | ||
| + | </pre> | ||
| + | |||
| + | Push to public server: | ||
| + | <pre> | ||
| + | $ git push -u origin master | ||
</pre> | </pre> | ||
Revision as of 12:05, 8 March 2012
Contents |
General Workflow
- Anything in the
masterbranch is deployable - To implement a new features or bug fix, create a new feature branch off of
master - Commit all your changes to the branch and push on the server
- When you need feedback/review/help open a pull request
- After testing your branch by running Firebug test suite on it, merge it into
master - When doing a release create a 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
masterbranch.
2. Create Feature Branch
When you work on a new feature (or fixing a bug), create a new feature branch.
First clone 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 Feature Branch
Commit all your changes into your feature branch and publish all the 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 merge 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 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 successful merge. It's not needed anymore.
$ git branch -d myfeature
Push to public server:
$ git push -u origin master
