Outline

I used GitLab so much during development of Mirori-HP. I am presenting the development flow that I have used. It maybe called issue-driven development.

 

Development flow

Like this.

  1. Create Milestone. Ex: v19.9.1 Release
  2. Development
    • Create Issue. "Add smt" "Fix bug" "How about such idea"
    • Create Branch and Merge request. Ex: midori-mate/a_function feature/a_function feature/#82_a_function
    • Make Commits. Ex: #82 Fix A function Fix A function (#82)
    • Request review. Set Assignee and comment him.
    • Modify and review again.
    • Merge.
  3. Repeat 2 cycle to develop.
  4. Close Milestone.

Milestone     : Issue         = 1 : n
Issue         : Merge request = 1 : n
Merge request : Commit        = 1 : n

Relationship between them is like above. In particular you should create Merge request with fine granularity, it means you should try to make smaller commits. It is okay even if one Merge request contains only few rows changes. It enables reviewers to review easier.

More information for each phase is below.

 

Create Milestone

Decide big goal, such as to release version bla bla until sometime. I name them like v19.9.1 Release.

 

Create Issue

Post something like "Add some function" "Fix some bug" and "How about". Each member is allowed to post easily.

  • Title, Description : As you want. You can prepare default template as well.
  • Assignee : Set someone who will face this Issue.
  • Milestone : Set Milestone you made above.
  • Labels : You can filter Issues by labels. Or ... it looks so colorful with labels.
  • Others : Never used.

 

Create Branch and Merge request

On Issue page, create Branch and Merge request as well at once. Name branches user/function_name, feature/function_name or feature/#issue_num_function_name.

 

Pull the branch and develop

Commit comment is like below.

  • #Issue_num comment ex: #82 Fix A function
  • Comment (#Issue_num) ex: Fix A function (#82)

Btw, don't involve your development processes but try to create simple commit history. Don't make commits like #82 Tried to fix A anyways #82 Oops as that didn't work, revert that. But you can make such commits because they are useful during the development. Before push, organize commits with git reset --mixed ***.

 

Request review

After push, edit related Merge request.

  • Title : Remove WIP:.
  • Description : Well as you want. If you write Closes #Issue_num GitLab closes the Issue automatically when the request is merged.
  • Assignee : Select reviewer, who is the one to merge as well.

Comment to assignee to request review.

 

Review and modification

Assignee reviews and comments.

If he requests you to modify something, you modify them, commit, push and comment again.

 

Merge

Assignee checks, merge the request and delete the branch.

 

Done

After all, close the Milestone.

 

Slack notification

Even with such flow, no one is aware of your works without notification. Set notification to Slack.

  1. Access Incoming WebHooks page of Slack.
  2. Add Configuration
  3. Choose a channel you want to notify.
  4. Get Webhook URL.
    • You can set icon and so forth on this page.
  5. Back to GitLab, Settings > Integrations > Slack notifications
  6. Write Webhook URL in Webhook form.