Confirmed users
514
edits
Labs/Jetpack/FlightDeck/Code Workflow/Management Commands: Difference between revisions
Labs/Jetpack/FlightDeck/Code Workflow/Management Commands (view source)
Revision as of 14:31, 22 July 2010
, 22 July 2010→bug-#-
m (→release-) |
m (→bug-#-) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{draft}} | |||
This article is inspired by [http://nvie.com/git-model A successful Git branching model]. | This article is inspired by [http://nvie.com/git-model A successful Git branching model]. | ||
| Line 27: | Line 28: | ||
#May branch from: '''master''' | #May branch from: '''master''' | ||
#Must merge back to: '''master''' | #Must merge back to: '''master''' | ||
#Branch naming convention: '''bug-1234-name_of_the_bug''' where 1234 is the number of the bug in bugzilla | |||
Branch naming convention: bug-1234-name_of_the_bug where 1234 is the number of the bug in bugzilla | |||
These branches are used to develop new features for the upcoming or a distant future release. This branch exists for the time of development of this topic only. It's goal is to be merged back into '''master''' | These branches are used to develop new features for the upcoming or a distant future release. This branch exists for the time of development of this topic only. It's goal is to be merged back into '''master''' | ||
| Line 66: | Line 66: | ||
git tag -a 1.0a3 | git tag -a 1.0a3 | ||
Push the changes to main repository | Push the changes to main repository | ||
git push main production | git push main production --tags | ||
To keep the changes made in the release branch, we need to merge those back into master | To keep the changes made in the release branch, we need to merge those back into master | ||
git checkout master | git checkout master | ||
git merge --no-ff release-1.0a3 | git merge --no-ff release-1.0a3 | ||
git push main master | |||
If this would lead to a conflict resolve it and commit. Release branch is not needed anymore, delete it | If this would lead to a conflict resolve it and commit. Release branch is not needed anymore, delete it | ||
git branch -d release-1.0a3 | git branch -d release-1.0a3 | ||
| Line 97: | Line 98: | ||
git tag -a 1.0a3.1 | git tag -a 1.0a3.1 | ||
git push main release-1.0a3 --tags | git push main release-1.0a3 --tags | ||
== hotfix-#- == | |||
#May branch off from: '''production''' | |||
#Must branch back into: '''support''' or '''production''' | |||
#May branch back into: '''release''' and '''master''' | |||
#Branch naming convention: '''hotfix-1234-name_of_the_hotfix''' where 1234 is the bug number in bugzilla | |||
Hotfix branches are very much like bug-#- branches, albeit unplanned. They are meant to prepare a production or support release. They arise from the necessity to act upon an undesired state of live production version. Hotfix branch may be branched off from the correspondind tag on the production branch that marks the production version. | |||
Hotfix has to merge back into production (if it's relative to the current production version) or (else) into support- branch. | |||
If the hotfix is sensible in the current development it may be merged to release or master branch. | |||
=== ''workflow'' === | |||
Merge the remote hotfix branch production (or support) | |||
git remote add -t hotfix-1234-name_of_the_hotfix john-1234-name_of_the_hotfix git@github.com:john/FlightDeck.git -f | |||
git checkout production | |||
git merge --no-ff john-1234-name_of_the_hotfix | |||
git tag -a 1.0a3.1 | |||
git push main production --tags | |||
Delete local branch after usage | |||
git branch -d john-1234-name_of_the_hotfix | |||