Welcome to Tanuki Tuesday, where I look at the features offered by GitLab. This week I'm going to look at keyboard shortcuts, and how you can use them to speed up your personal process within GitLab.
There are a lot of places where you use keyboard shortcuts without even thinking about them. Ctrl+C for copy, Ctrl+V for paste, and Ctrl+S for saving are the ones most people will use. It's become ingrained in certain applications to use shortcuts to save the need to move from keyboard to mouse, select a menu, and then the select the option.
Learn keyboard shortcuts, and save time.
You can get a full list of shortcuts by pressing ? within GitLab, or from the ? icon and selecing Keyboard Shortcuts in the header. That will be the basis of most of this article.
Shortcuts for navigation
A lot of the shortcuts are used within specific projects. It allows navigation to various areas within a project using a g+(another key). The additional keys have been chosen for their ease of memory and to be intuitive; g+i to go to issues; g+f for files; g+m for merge requests.
I focus on those ones because they are the start of how I improved my productivity. It might seem trivial, but from entering gitlab.com and pressing enter in my address bar, I can get into my projects quickly, and work through the different sections of the projects I am working on.
By using the search function in the browser (Ctrl+f) to get to what I want on a given page, I can open a record and then use quick actions to perform a lot of the actions I do as part of my daily work.
Shortcuts in issues
Issues are where I most frequently use shortcuts. They allow me to get to the notes/comments section where I can provide additional information as needed, or ass the quick actions for setting labels and other meta informaiton as needed. When an issue loads, I can press r to go straight to the comments, add the content I need, and then use Ctrl+Enter to save the changes.
Other keyboard shortcuts
I don't currently use a lot of shortcuts within merge requests, other than the ones I also use in issues. Mainly for utilising quick actions to save me clicking round and searching for things in drop downs. Similarly, within jobs, epics and other areas, my use of keyboard shortcuts is limited.
Not everyone will use shortcuts everywhere. And for areas where you may not spend a lot of time, it might be counterproductive to learn and use keyboard shortcuts. Simply get the job done with the mouse, and get back to areas where you do spend your time.
Even in areas where you do spend a lot of time, you might not use all of the shortcuts. For me, within issues I know I can assign a milestone by pressing m, or change the assignee by pressing a. The chances are, however, I'm going to be performing multiple actions like that at the same time, so I work within the comments section. I focused on learning how to get there and using that area proficiently for my needs that I don't feel the need to use the individual shortcuts. You may not feel the need to learn them all, either.
Conclusion
Much like a lot of people were tricked into trying the Alt+F4 shortcut in school, you should only try using shortcuts when you won't be upset if you lose that section of work. When you do start with them it may be a little slower at first to get done what you need to. However, in time, you will be able to work more effectively when you don't need to more your hands away from the keyboard to reach for the mouse, move it, preform an action or two, and then move back to the keyboard.
Give some of the shortcuts a try, and see if you can improve your efficiency around GitLab. I'd love to know how you get on, so please let me know on Twitter.
Top comments (0)