LUNA Git Flow

Describes development related processes in LUNA Project

登録は簡単!. 無料です
または 登録 あなたのEメールアドレスで登録
LUNA Git Flow により Mind Map: LUNA Git Flow

1. Features

1.1. One Feature - One Task - One Branch

1.1.1. Exceptions Very related issues Mutually dependent issues 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 More than one dev working on a feature Early testing is involved

1.5. Flow Sequence

1.5.1. Begin work Move the Jira issue to [In Dev] Create a branch

1.5.2. When you have something ready, push it and create a Merge Request Name the MR: [COLLABEM-999] Adds some feature Add a comment to the JIRA ticket with a link to the MR Set Milestone from Fix Version field in JIRA Jira ticket might contain more detailed version, f.x. [3.18 hotfix], In this case use only [3.18] Mark Merge Request with [WIP] Resolve [WIP] status just before clicking Merge button This approach is TBD: it is new for our team. Add label [Development]

1.5.3. When the coding is done Approve it with Kyiv Team Rebase the feature branch on development branch with squashing commits Remove [Development] label Add [Kyiv Review] label and assign to one of Kyiv key developers Move the Jira issue to [Code Review] Announce in dev chat for review If MR needs additional works, reviewer adds comments; Go to [Development] stage Otherwise each reviewer adds Thumb-Up Propagate for Lex and Russ approval Reassign the MR to Lex or Russ Remove [Kyiv Review] label Add [Final Approve] label Ask Lex or Russ to review the MR in Messenger Chat or somehow else If MR needs additional works, reviewer adds comments; Go to [Development] stage Otherwise Lex or Russ adds Thumb-Up Finalize All discussions must be resolved Add [Ready] label If the feature is targeted for the current milestone Otherwise, if the feature is targeted for the next milestone and the current release has not beed branched off 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 $ git checkout -b feature/COLLABEM-999_magic_button development To rename a misnamed branch Current local branch: $ git branch -m feature/COLLABEM-999_magic_button # delete old origin misnamed branch and push a new one $ git push origin :my-branch feature/COLLABEM-999_magic_button # 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 # 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 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 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 Another (preferable) approach is to use visual and/or scripted tools like WebStorm or GitFlow for Visual Studio Avoid errors during picking/squashing commits Visual and automated conflict resolving This flow also ends with $ git push -f

4.3.3. Merged back to development Merge request should have at least 2 thumb-up, at least one of them - from key developers Merge can be done by a key developer the feature developer once there is enough thumb-ups As a very exception the branch can be merged by a Repository Master without any GitLab Merge Request (TBD) $ 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 Check [Delete source branch] checkbox in gitlab Merge Request 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: Hotfix is branched from a release 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

5.3. What the JIRA Issue status for a feature targeted to the next release, thus not merged?

6. DoD

6.1. [TODO]