Photo by veeterzy on Unsplash
Bet on git
Any company that does development work should be using some form of version control. Git takes the cake as the industry standard. It is one of the most influential tools ever created and is one of the reasons open source has been so successful.
Looking at this visualization from 2004 to 2019, we can see Git's dominance over other version control systems.
I will share some tips to improve productivity and collaboration with team mates.
Use an alias library
Some git commands can be verbose. Things get worse if the files in your project have long names or files are deeply nested. The same goes for branch names.
My tool of choice to solve this is scm-breeze.
It's killer feature is mapping list outputs to numbers when you type in commands such as gs (git status) or gb (git branch). Now instead of git checkout some-long-branch-name-for-some-reason, you could instead run gb, look for the number that is mapped to your branch (lets say 3 for this example), and then run gco 3.
Example of a git branch command
Example of a gb command
There are a ton of other commands pre defined, just type git_aliases in your terminal after installing to see them.
Stage changes granularly
While working on a feature, you might be modifying various parts of your code to experiment. What do you do when you finish a piece of logic but only want to commit a small chunk of code? You might have made changes in other parts of the same file. Newbie me might have copied the changes I want to commit, reset the branch, and paste the changes back.
git add -p (or --patch) gives an interactive cli interface to add chunks of changes to staging instead of all the changes within the file. (This is gap in scm_breeze btw ;) ) At each chunk, you will see a prompt, where you can choose to either add, ignore, or edit the chunk.
On top of the granular control over what changes you want to add, I find this way of committing easier to digest. Instead of seeing a screen full or green and red, you have a few isolated lines of changes to look at.
Merge unrelated changes from a big feature branch early
There are times when you will be working on a feature that may take several days or weeks. While working on big changes like this, its common to notice small optimizations or refactors you need to make to other parts of the code base to support the feature you're working on.
Instead of hogging all these changes on your branch, waiting until your feature branch is ready for a PR, make a new branch off the dev/master branch and cherry pick the commits with these small optimizations. Start a new PR. Since its small the PR should be easier to review and merge with the main development branch. Then merge / rebase those changes back into your feature branch.
This type of workflow will make everyone on your team happier. Since we introduced these optimizations sooner, the rest of your team will get to benefit from your changes while you continue working on the big feature.
When you are ready to start a PR for that feature you've been working on, your reviewers will see a smaller diff. They will only see changes that are more focused on the feature you worked. This should make the PR easier to read and approve.
Closing remarks
Git-fu is a must have skill to be a productive developer. I hope this post has inspired you improve your git workflow. Try some of these out and let me know how things go! If you have any questions I'd be glad to go deeper in to the tips I discussed.
Happy coding!
Latest comments (1)
Very helpful info! Thanks :D