🏠 / Gitlab / Issues Workflow
Gitlab Issues Workflow
This guide takes you step-by-step through our Gitlab workflow from issue to completion. We start by creating an issue on Gitlab, and then creating a development branch for the issue on Git. All development for that issue happens on that issue branch. Eventually once the issue concerns have been committed and pushed, we walk through the steps of initiating and accepting a merge request, which is the final step of the workflow.
Create an issue
- Go to Gitlab project and click Issues from the header navigation
- Check to see if issue already exists (check both open and closed issues)
- If an issue already exists and is open
- Leave any comment that might contribute to the issue's conversation
- If an issue already exists and is closed
- Re-open ticket and leave a comment explaining why there is work to be done with the issue
- If an issue does not already exist
- Click the New Issue button
- Give your issue a brief but meaningful title in the Subject field - e.g.
Restrict droppable area for draggable items
- Assign at least one label - e.g.
bug
- If the Label text input doesn't have autocomplete functionality with pre-built labels, then you need to generate labels for the project (a one-time process). Go to the Issues section, click the Labels tab, and then click the Generate link.
- Fill out the Details field and any other fields that you want to set (Assign to, Milestone).
- Click Submit new issue
- If an issue already exists and is open
Create development branch
Generic Git Workflow
- Checkout master branch
- Pull changes from origin/master
- Create a new issue/development branch from master following these naming conventions...
- Should start with a (single) main label for the Gitlab Issue, followed by a slash - e.g.
bug/
- Should be a lowercased, dash-separated and a potentially shorter version of the Gitlab Issue Subject - e.g.
bug/restrict-droppable-for-draggables
- Should start with a (single) main label for the Gitlab Issue, followed by a slash - e.g.
- Checkout the new issue/development branch
- Create remote branch by pushing to origin using the same branch name.
- Begin development
PhpStorm Workflow
There are several ways to access the Git commands in PhpStorm. These instructions make use of the Navigation Bar at the top of the PhpStorm window and the Status Bar at the very bottom of the PhpStorm window. Make sure they are visible by enabling the View > Navigation Bar and View > Status Bar menu items.
- Make sure you are on the master branch
- The right-side of the Status Bar at the bottom, you should see Git: {BRANCH NAME}
- If the {BRANCH NAME} is not master then click the branch name to open the branches popup menu. From the Local Branches section, choose master -> origin/master > checkout.
- Pull changes from Gitlab (origin). Click the Update Project button (has an icon that says "VCS" with a blue downward arrow below it) located on the right side of the upper Navigation Bar.
- Click the Git: {BRANCH NAME} menu towards the right-hand side of the Status Bar to reveal the Git Branches popup menu
- Choose New Branch to create your issue/development branch and follow these naming conventions...
- Should start with a (single) main label for the Gitlab Issue, followed by a slash - e.g.
bug/
- Should be a lowercased, dash-separated and a potentially shorter version of the Gitlab Issue Subject - e.g.
bug/restrict-droppable-for-draggables
- Should start with a (single) main label for the Gitlab Issue, followed by a slash - e.g.
- PhpStorm creates the branch and checks it out so you are now in your new branch. You should now see your newly created branch name as the selected branch in the Status Bar. If you don't, check it out.
- Create a remote branch on Gitlab (origin) by opening the Terminal via the Tools > Open Terminal... menu item, and then entering this command:
git push origin {ISSUE BRANCH NAME}
where{ISSUE BRANCH NAME}
is the name of the issue branch that you just created - e.g.git push origin bug/restrict-droppable-for-draggables
Develop, Commit, Push
Generic Workflow
- Whenever development for this issue occurs, make sure you have the branch that was created for this issue checked out
- All commits should reference the issue. Do this by placing a
#{ISSUE ID}
somewhere in the commit message - e.g.#4: Add start() event listener that kills overlay
.- You can also close a ticket via the commit message by starting your commit message with:
Fixes #{ISSUE ID}
orCloses #{ISSUE ID}
- e.g.Fixes #4: Add start() event listener that kills overlay
- NOTE: You will not see these commit messages in the Issue comments until your branch has been merged into the master.
- You can also close a ticket via the commit message by starting your commit message with:
- Push the branch to Gitlab (origin) using the same name for the remote branch as the local branch that was created for the issue.
- Repeat until issue is resolved.
PhpStorm Workflow
- Whenever development for this issue occurs, make sure you have the branch that was created for this issue checked out
- The right-side of the Status Bar at the bottom, you should see Git: {ISSUE BRANCH NAME}
- If the {ISSUE BRANCH NAME} isn't the correct branch created for the issue, then click the branch name to open the branches popup menu. From the Local Branches section, choose correct branch and select checkout.
- Commit changes to your local repo by clicking the Commit Changes button (has an icon that says "VCS" with a green upward arrow below it) located on the right side of the upper Navigation Bar. All commits should reference the issue. Do this by placing a
#{ISSUE ID}
somewhere in the commit message - e.g.#4: Add start() event listener that kills overlay
.- You can also close a ticket via the commit message by starting your commit message with:
Fixes #{ISSUE ID}
orCloses #{ISSUE ID}
- e.g.Fixes #4: Add start() event listener that kills overlay
. - NOTE: You will not see these commit messages in the Issue comments until your branch has been merged into the master.
- You can also close a ticket via the commit message by starting your commit message with:
- After filling out your commit message, you can choose to Commit and Push, or just Commit. Just note that a Push is required either then or later on to have your commits show up on Gitlab.
- When you do push, within the Git Push popup window you'll notice towards the bottom that it will push to the origin and use the same branch as your issues branch. Click the Push button to push your commits to Gitlab (origin).
- Repeat until resolved.
Create Merge Request
- Go to Gitlab project and click Merge Requests from the header navigation
- Click the New Merge Request button
- On the left-hand side choose the branch associated with the issue. On the right-hand side choose the
master
branch - If someone else is responsible for accepting the merge request, then it might be helpful to assign the merge request to them and use the Description to communicate any extra information to them.
- Click Submit merge request button
Handling the Merge Request (Project Admin)
- Go to Gitlab project and click Merge Requests from the header navigation
- Select the merge request that you are interested in
- Verify the code
- For simple requests, you can view the Diff tab below the Commits list
- For more involved merges, pull the branch down to your local repo and verify it works as expected.
- If there are issues, add a comment to the Discussion tab below the Commits list. It could help to reference any people that might need to know about the reject by using the
@{USERNAME}
pattern in the comment - e.g.@mmclin
- Once everything looks good, enable the Remove source-branch checkbox if the issue is complete and the branch is no longer needed, and then click the Accept Merge Request button.