1. Features
1.1. One Feature - One Task - One Branch
1.1.1. Exceptions
1.1.1.1. Very related issues
1.1.1.2. Mutually dependent issues
1.1.1.3. In this case naming as follows: feature/COLLABEM-123_COLLABEM-321_ui_changes
1.2. Should be short living
1.2.1. A branch with a life span longer than a week might deviate from development/master much.
1.2.2. Enormous cross-cutting changes in features branches usually not wanted.
1.2.3. If a feature requires more time, rebase on master regularly
1.3. Reverts should be simple
1.3.1. To avoid intertwining features, rebase on development before merge
1.3.2. Depending on whether the commit to revert is published, use a proper method
1.4. Feature assignee is responsible for the branch
1.4.1. Therefore she can arbitrarily rebase and change the branch history
1.4.2. Exceptions
1.4.2.1. More than one dev working on a feature
1.4.2.2. Early testing is involved
1.5. Flow Sequence
1.5.1. Begin work
1.5.1.1. Move the Jira issue to [In Dev]
1.5.1.2. Create a branch
1.5.2. When you have something ready, push it and create a Merge Request
1.5.2.1. Name the MR: [COLLABEM-999] Adds some feature
1.5.2.2. Add a comment to the JIRA ticket with a link to the MR
1.5.2.3. Set Milestone from Fix Version field in JIRA
1.5.2.3.1. Jira ticket might contain more detailed version, f.x. [3.18 hotfix], In this case use only [3.18]
1.5.2.4. Mark Merge Request with [WIP]
1.5.2.4.1. Resolve [WIP] status just before clicking Merge button
1.5.2.4.2. This approach is TBD: it is new for our team.
1.5.2.5. Add label [Development]
1.5.3. When the coding is done
1.5.3.1. Approve it with Kyiv Team
1.5.3.1.1. Rebase the feature branch on development branch with squashing commits
1.5.3.1.2. Remove [Development] label
1.5.3.1.3. Add [Kyiv Review] label and assign to one of Kyiv key developers
1.5.3.1.4. Move the Jira issue to [Code Review]
1.5.3.1.5. Announce in dev chat for review
1.5.3.1.6. If MR needs additional works, reviewer adds comments; Go to [Development] stage
1.5.3.1.7. Otherwise each reviewer adds Thumb-Up
1.5.3.2. Propagate for Lex and Russ approval
1.5.3.2.1. Reassign the MR to Lex or Russ
1.5.3.2.2. Remove [Kyiv Review] label
1.5.3.2.3. Add [Final Approve] label
1.5.3.2.4. Ask Lex or Russ to review the MR in Messenger Chat or somehow else
1.5.3.2.5. If MR needs additional works, reviewer adds comments; Go to [Development] stage
1.5.3.2.6. Otherwise Lex or Russ adds Thumb-Up
1.5.3.3. Finalize
1.5.3.3.1. All discussions must be resolved
1.5.3.3.2. Add [Ready] label
1.5.3.3.3. If the feature is targeted for the current milestone
1.5.3.3.4. Otherwise, if the feature is targeted for the next milestone and the current release has not beed branched off
1.5.3.3.5. Move the Jira issue to [In QA] ???
2. Releases
2.1. Each release is represented with a branch
2.1.1. Branch is created created from development when milestone is done
2.2. Release features can be merged to development once the previous release is branched off
2.2.1. Otherwise, ready Merge Releases are pending for merge
2.3. Hotfixes
2.3.1. The same workflow as with features
2.3.2. After hotfix is merged to release branch, the release branch is merged to master with --no-ff option and tagged
3. CI
3.1. [TODO]
4. Braches
4.1. master
4.2. development
4.3. feature/COLLABEM-999_magic_button
4.3.1. Branched from development
4.3.1.1. $ git checkout -b feature/COLLABEM-999_magic_button development
4.3.1.2. To rename a misnamed branch
4.3.1.2.1. Current local branch: $ git branch -m feature/COLLABEM-999_magic_button
4.3.1.2.2. # delete old origin misnamed branch and push a new one $ git push origin :my-branch feature/COLLABEM-999_magic_button
4.3.1.2.3. # set upstream for the local current branch git push origin -u feature/COLLABEM-999_magic_button
4.3.2. All commits are squashed and force-pushed to origin
4.3.2.1. # update dev branch: $ git checkout development $ git pull # rebase feature branch $ git checkout feature/COLLABEM-999_magic_button $ git rebase -i development $ git push -f
4.3.2.1.1. Interactive (-i) rebase will display an editor where you need to set an action on each commit: pick as is, reword to change commit message, skip or squash
4.3.2.1.2. If a conflict occurs, you need to handle it either manually or with a 3rd party tool. You can get the list of files in conflict using: $ git status
4.3.2.2. Another (preferable) approach is to use visual and/or scripted tools like WebStorm or GitFlow for Visual Studio
4.3.2.2.1. Avoid errors during picking/squashing commits
4.3.2.2.2. Visual and automated conflict resolving
4.3.2.2.3. This flow also ends with $ git push -f
4.3.3. Merged back to development
4.3.3.1. Merge request should have at least 2 thumb-up, at least one of them - from key developers
4.3.3.2. Merge can be done by
4.3.3.2.1. a key developer
4.3.3.2.2. the feature developer once there is enough thumb-ups
4.3.3.3. As a very exception the branch can be merged by a Repository Master without any GitLab Merge Request (TBD)
4.3.3.3.1. $ git checkout development $ git merge --no-ff feature/COLLABEM-999_magic_button $ git branch -d feature/COLLABEM-999_magic_button $ git push origin :feature/COLLABEM-999_magic_button $ git push origin development
4.3.4. Deleted on merge
4.3.4.1. Check [Delete source branch] checkbox in gitlab Merge Request
4.3.4.2. or delete the branch afterwards
4.4. release/3.123
4.5. hotfix/COLLABEM-888_we_are_doomed
4.5.1. The Hotfix Branch workflow is the same as the Feature Branch one. Exceptions:
4.5.1.1. Hotfix is branched from a release
4.5.1.2. Once done, the hotfix is merged back to the release AND to master WITH --no-ff option
5. Open issues
5.1. Elaborate how to descope published features
5.1.1. It does not seem to be an exceptional case
5.1.2. Revert commit and save it to a new feature branch
5.1.3. Save the commit, if needed, and drop it with rebase -i
5.2. Do we need a some kind of automation for the feature flow?
5.2.1. Branching
5.2.2. Relinking MR with the Jira issue
5.2.3. Labeling and issue status change on board