Difference between revisions of "Development workflow - webdev"
Line 2: | Line 2: | ||
= Overview Diagram = | = Overview Diagram = | ||
− | [[File:Git_Workflow_- | + | [[File:Git_Workflow_-_WormBase2.png]] |
[https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram] | [https://docs.google.com/drawings/d/1j-a-8a_hTIqCiMCRLUcemGqEe_c8LXOZKuioHlE9oX4/edit?usp=sharing Editable version of the diagram] |
Revision as of 21:57, 6 March 2013
This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management.
Overview Diagram
Editable version of the diagram
Branch Strategy
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.
Main branches
Inside the WormBase/website
repository, there are three main branches: master
, dev
and production
.
master
: current, stable code. All new changes brought into master have been tested on staging.wormbase.org and approved by either the curator requesting the change, or the development lead.
dev
: any features/changes ready for testing should be pushed to thedev
branch. This code gets pushed nightly to staging.wormbase.org.
production
: the code currently in production. Branched off ofmaster
at each release.
Supporting branches
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into dev
or the fix is completed.
Feature branches
Any new major features should branch off dev
. Once the feature is ready for testing, it can be merged back into dev
.
Starting a feature
Create a branch from dev
for your work on this feature/issue/bug
git checkout -b myFeature dev
Finishing a feature (ready for testing)
When you're ready to incorporate your feature and have it tested on staging.wormbase.org, you can push your feature branch back to dev
For a smaller feature:
git checkout dev git merge --squash myFeature git commit -v
You can use --squash
to remove any checkpoint commits you may have added to your branch during development, ie. you may have committed debug statements, or broken changes you have since removed.
If your feature is larger and would benefit from having the work broken down into several commits, you can rebase instead:
git checkout myFeature git rebase --interactive dev
This will open your editor with a list of commits. Each line has the operation to perform (pick
or squash
), the SHA1 for the commit, and the commit message. By default, each commit has the pick
operation:
pick 8af9b68 Update search pick c180b1b bug fix pick 36afac4 work on field titles
Changing the operation to squash
will squash that commit.
pick 8af9b68 Update search squash c180b1b bug fix pick 36afac4 work on field titles
Moving a feature to master
(pass testing)
Once all features currently on the dev
branch have been tested on staging and approved by either the requesting curator or the development lead, dev
can be merged onto the master
.
git checkout master git merge dev
Hotfixes
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into production
and dev
Begining a fix
git checkout -b hotfix-issXXX production
Fix the bug and commit the fix in one or more commits. Reference the github issue:
git commit -m "Severe production bug * search redirecting to home page * fix #XXX"
Closing the fix
The fix needs to be merged back to both production
and dev
git checkout dev git merge hotfix-issXXX
git checkout production git merge hotfix-issXXX
Release Management
When production is ready to updated for release WSXXX:
git checkout production git merge master git tag -a WSXXX