So you think my post is spam or something? It’s a genuine question.
I know some steps would be faster if Gitlab was setup for trunk based development or had some tooling around the branch management which the github client has. I was curious what the Gitlab community had to offer.
FYI, I have restored the flagged topic after reviewing the linked article. Asking questions about Git and all related topics to GitLab is welcome and encouraged in our community
Sharing a few suggestions to reduce the steps and make the workflow more efficient. I have adopted and learned these tips since using Git in 2009.
(and 2.) Use a shell integration for Git that shows the current state (clean, modifications, etc.) and the checked-out branch.
There are many solutions for different terminals out there (Bash, ZSH, etc.). As an example, I recently switched my ZSH Theme to Powerlevel10k which shows the state after git add (modified in yellow) and branch name test. New ZSH theme on macOS: Powerlevel10k
Newer Git versions support git switch <branchname> which might be faster to type.
Suggest running git fetch first to see if there were any remote changes that would be pulled. When I am confident, run git pull.
Newer Git versions support automatically rebase when pulling. You can also specify that using git pull --rebase.
Branch name should be descriptive but if too long, it can be helpful to add the issue ID into its name instead, so that other team members can look it up with quick search, etc.
Good commits require practice.
I have adopted present tense, describing the action. Some folks use https://www.conventionalcommits.org/ which needs practice and team documentation and workflows.
Seems that commits need to be linked with [Jira tag] in your workflow to show up in Jira, can you elaborate a bit more why this is needed? Trying to understand the purpose.
I’ve google searched for jira tag git commit gitlab, and found something that is called “smart commits” which are available via GitLab integration as well. Jira integrations | GitLab
Depending on your OS, a quicksearch extension (Spotlight, Raycast on macOS) might be available that allows to find the Jira tag without leaving the scope.
Another consideration would be to create the Merge Request, and only link it to the Jira issue, and not the raw Git commits. Issue readers do not need to see the changes that are stored in MRs and its code review discussions.
By default, git push would ask you to setup the remote tracking branch with git push -u origin <branchname> or shorter with a virtual head pointer git push -u origin head. Modern Git versions will ask you once to enable the remote tracking automatically. Can be configured in a global .gitconfig like this
The URL to open a browser window/tab is still a good choice. In the future, you will be able to use the GitLab CLI that was adopted from the glab community project, blog post was published earlier today.
One way to control the description of MRs is to use merge request templates, you can also define a default.md that always gets loaded. That’s a helpful workflow to ensure that all tasks are checked, and required information is filled in (and removes potentially unwanted Git Commit message strings).
Before approving a merge request, a suggested workflow is to have another team member review it. You can use either the UI menu to assign reviewers, or by using a quick action. Type r as keyboard shortcut, and type /assign_reviewer @<type name here> to quickly request a review. Approvers can use /approve then, and /merge. A complete workflow is described in this blog post:
The aforementioned /merge quick action also supports the workflow of “merge when the pipeline succeeds” setting which is enabled by default for new projects. Merge when pipeline succeeds | GitLab
Tip: You can create a shell alias for the same, and pass in push options that do the same. No more wait times for manual merges after the CI completed successfully. It is one of the tips described in this blog post:
The MR setting to delete the branch after being merged is enabled on the remote GitLab server too.
On the local client, you can use some CLI magic to delete all branches whose remote tracking branch was deleted. It is linked the blog post above, copying my shell alias on macOS ZSH here too:
# Delete all remote tracking Git branches where the upstream branch has been deleted
alias git_prune="git fetch --prune && git branch -vv | grep 'origin/.*: gone]' | awk '{print \$1}' | xargs git branch -d"
