Workflow Tips

Nick Wurzer

If you’re like me and this is your first exprience coding in the real world, it may take a while to get familiar with Git and GitLab. This may initially slow you down when working on tasks, so I aim to speed up the learning curve by showing some useful features of Git and GitLab. If you’re already familiar, then read on for a good review!

For an introduction to Git version control see Priya’s blog post.

GitLab

Although similar to GitHub, GitLab also provides tools for project management. I’d like to introduce the tools that I use most often. Because I use them so often I found it helpful to pin these pages in the sidebar. They are as follows:

Merge Requests: Merge requests (MRs) are important because they create an easy way for code to get reviewed before merging into another branch. When you start a merge request, others can ‘start a review’ or ‘comment now’. The main difference is that the person will only be notified once for a review, and once for every comment. If you have many comments for someone as you review their code, you should start a review.
Branches: Branches are useful because you can have a peek at someone’s code without them having to start a MR. If they have a specific question about one part of their code, but aren’t ready for a full review it could be helpful to just ask for the line number or commit to check, and then go to the branch to find it. Branches are also just a good way to get a quick overview of what people are currently working on, to see where the project is at overall.
Issue Boards: Issue Boards are really helpful for project management and can be a good way to communicate with the clients. Typically, the issue which a merge request is addressing should mention the issue by putting # before the issue number. Likewise an issue can mention a merge request by putting ! before the MR number. This way there is a connection between the issue, which describes desired functionality and the code which implements it. As you work on and complete issues, be sure to update the issue with progress or feedback, and give it the appropriate tag. This way when somebody goes to look at the issue board, they can get a broad overview of what work is still to do, what is being worked on and what is completed (and much more).
Commits: I also like to pin commits to the sidebar for ease of use. You can get to the commits by clicking on a branch then clicking the ‘history’ button, but this is easier. Sometimes you’re looking for a particular commit or maybe refreshing your memory in the morning before diving back into coding. You can change the branch by the drop down menu in the top left.

Git

I’d like to share some Git tips and commands that I have found save me a lot of typing, so hopefully they can for you too!

Tab autocompletion for Git: Tab autocompletion should save a lot of typing. Adding source /etc/bash_completion.d/git to your .bashrc file should enable tab autocompletion for Git.
git commit -am "<message>": Very often I’ll make some changes, then want to commit them all. I’ll enter git status to double check which files I’ve modified, and then if appropriate add all, and commit with a message with this command.
git commit --amend: This command is useful for editing the last commit message in case a mistake was made.
git rebase -i <branch_name>: Interactive rebase can be used to update commit messages, squash(combine) commits, or omit commits.
git checkout -: Checkout the previous branch you were on. Much faster than typing it out.
git checkout <origin branch name>: After creating a branch through GitLab this command creates and checks out a branch and sets its upstream branch to the origin branch with the same name. For some reason this workflow wasn’t clear to me when I first started. Previously, I would git checkout main and git pull, then git branch <branch name>, git checkout <branch name> and finally git pull --set-upstream <branch name>. Using this new command it is simply, git checkout main, git pull and then git checkout <branch name>.

[ Things in Git tend to make sense once you’ve done them 30,000 times. Or they still don’t. –Ed. ]

git reset ~<num_commits>: Reset Git to num_commits before the location of HEAD. This is great if you want to discard some recent changes if you made a mistake or if you wanted to experiment or demo example code before rewriting it.
git branch -D <branch_name>: Delete a branch. This command is useful if you created a branch with the wrong name or if you want to clean up your local repository.
git cherrypick <SHA>: Grab a specific commit from another branch and apply the changes to your current branch.