Recently, I have been managing a team of engineers working on multiple projects, not just a single project, bruh. Naturally, this comes with limitations, from communication overhead to code pushes across different repos. You already know how time expensive it can be managing people, making sure code reviews happen, and ensuring everything goes the right way.
case study
We use Git for version control, and keeping everyone on the same page is crucial. But here is the thing: the most common GUI for Git, GitHub, can sometimes be painfully slow. Waiting for pull requests to load, or spending forever navigating through branches, feels like watching the senate sign a bill.
So all this problem must have a solution? you think right
When linux torvalds was creating git, he did not create a GUI for it and also did not create pull requests here is torvalds talking about how hard it is for adding pull request to git because github is requesting email, so if you follow the thread you see linux doing what he does best, so that brings me to the first guy I have been running away from right github. Thanks to the God that github have their cli that manages there newly added version controls tools. So that makes me the guy that goes back to his “ex” right, how do we go on from this.
I have always been a fan of anything commmand line but no one talks about learning new macros every day or using and never forgetting a certian new commands, that limitation there takes me back a little, but looking at it we can use alias to get the job done because no one is stuffing gh pr create --base --head --title or gh pr create -B -H -T, even tho I just wrote it down off the flow, all this part follow up commands makes it hard to remember. Sure, maybe that’s a skill issue (damnnnn 💀), but still it’s annoying. That is where aliases save the day.
fetch origin
Getting your locale environment upto date with the latest version on the remote is very important and it follow what we are doing this time, running git fetch origin get all the latest commit history all round the individual branch on the repository, so let say we have like 5 branch we get all the latests across all commits but if you dont need all to be updated but a certain branch what we do is that we go in further by adding the branch name to that git fetch origin <branch name>, it fetch the required branch latest commit change, making an alias for this and naming it <gfo> is the most perfect way to remember it but this is easy to remember and not that complex, if i need to attach a branch name to it, we add alias gfo="git fetch origin $1" this to your configuration file (.zshrc for me because i use zsh). if my branch name is dude, source your configuration file and run your gfo dude for fetch all the latest commit on branch dude, understand that the code change are not pulled to your locale but instead it only fetch the commit history of that commit. Here is an example response when you run gfo 2bf8ed8b..389d3a7a Staging -> origin/Staging which is showing the later commit history(practically the latest commit on your locale) to the current commit history(practically the latest commit on the remote).
Upon making sure my locale is upto date with the remote, I want to check my colleague’s commit history and go through the changes but first we need the commit hash, no one goes around with it but our initial commmand give us the commit hash and we pick the second one which is 389d3a7a, i use the git log --oneline --decorate --graph <commit hash> not because of the aesthetics but just it shows the stretch through out the branch and all other part involved on the particular branch, making an alias will not be bad for this or maybe skill issue again alias <what you like>"git log --oneline --decorate --graph $1". upon confirming all is right, we still want to check the changes on the each commit message made, this is where git diff <commit hash> comes through and no i didnot add any alias to this because I can remember it anytime. so instead i dry brain run it and go through my diffs, although i dont like the diff provided by git but i am still researching on the most efficiently tired engineer interface in viewing my diffs if you know any mail me, found one here updates.
pr management
When all is right and you are done with your thorough code review, we want to create a pull request, so in my company we have a direct naming convention for creating your branch. It is not important I create the pull request tho, if it have been created by the engineer working on it right, then we go through another pathway for code review right. So first i check for all the pull request opened on the repository, so this is where the github cli comes in, as it was talked about in my introduction right. You can use gh pr list for that right, it shows all the pull request opened on the repository and a id is attached to it by the right side, we will be using this id in navigating other posssible way for the code reviews.
gh pr list response
Showing 1 of 1 open pull request in **********/*****
ID TITLE BRANCH CREATED AT
#93 Feature feature about 1 month ago
So i am going to be talking minimally on the ones I use, but there are more commands in the cli documentation you can use. But here i get to use the merge, comment, review, diff and view commands, and they are very handy as long it take me from spending time trying to reload screens all the time. The gh pr view <pr number> gives me the well detailed all of all
gh pr view response
fix: dashboard stats ************/****#116
Merged • Dudeiebot wants to merge 2 commits into feature from dude • about 2 days ago
+33 -1 • No checks
• feat: add avatar_url and is_active to customer profile
• feat: best performing kitchen
- View this pull request on GitHub: https://github.com/**********/****/pull/116
The diff shows the file changes also, the comment adds the comment to the pull requests and then when all is done upon reviewing it all, then i can merge it with gh pr merge <pr number>. But let say you want to be the one to create the pull request, the cli commmand is pretty long, I talked about it in the introduction part gh pr create --base --head --title or gh pr create -H -F -T, yeah skill issue i know, but have you tried creating pr across 6 projects with over 12 developers working on it.
Remember along the line I talked about my branch naming convention in my company, what I have to do is find the constant that does not change in all this instance, which is the branch naming convention. This makes creating an alias with their naming convention the easiest in this aspect, so for instance my company name is polarok and my name is dude so let say my company uses the naming convention polarok-dev-dude, so now my lead engineer knows my branch name and it does not even change when i am working on multiple project for the company right, my lead engineer can create this alias alias gc-dude="gh pr create --base staging --head polarok-dev-dude --title $1", so now as the lead engineer i know to always create dude pr with gc-dude "Fix: payment bug". This works for all your team member as long there is a naming convention you follow -> if you dont know their name use their nickname -> if you dont know that then you cant be saved.
edge case
- a team member having the same name
- too many aliases -> looks like spaghetti
- you low-key hate your company and don’t care to optimize
update regarding the best way to view my diffs
so i have known about lazygit since long but i was lazy setting it up and lazy learning all the commands used, funny thing i tried it out and it seems like the best thing ever. so my process is like this, i run my git fetch origin, then checkout the branch git checkout origin <branch-name>, and finally with lazygit. We are good to go and see our individual diffs across all file changes. Thanks - this is an update