Aliases
git config --global alias.<name of command shortcut you want> "<enter chain of commands here>"
We all know about git add . and git commit -m "" but did you know you can shorthand it to: git commit -am "". This is pretty good but we can simplify it even further by creating an alias to it. Aliases are basically just shortcuts. Personally, I've changed my add and commit command to just git ac "<my commit msg>"; the ac is the name of the command I want. In order to create this specific command I have, you will write the following:
git config --global alias.ac "add -A commit"
and if you want to remove your alias, it is as simple as:
git config --global --unset alias.<your_alias>
git log (but prettier)
Git log essentially shows us the commit history of a repo and sometimes, it can be a bit overwhelming if you have a lot of complexity in it. The following command is to show the commit history and display it in a way where it is a lot easier to see:
git log --graph --oneline --decorate
BEFORE:
AFTER:
(To exit out of the git log, press "q")(I condensed this into an alias to git lgod). In my current personal project, you can see that I've only used one branch to work on and merge it to my main branch very easily whilst having all the commit messages and it's commit ID. This can come very handy if you don't use something like git kraken.
GIT KRAKEN:
Stash
Have you ever had borderline ready code to be pushed to the remote repo but have some doubts and want to work on something else? Maybe you want to store it and pull someone's code for a PR review. You can and it is as easy as git stash. This will safely store your work and if you want to retrieve it, you can use git stash pop. Let's say that you really want to use this feature, you can; using the following code will stash your code and give it a name so you can reference it later:
git stash save <name of stash>
and to see how many stashes you have, use the following command:
git stash list
and it will return something like this:
stash@{0}: On main: <yourStashName>
stash@{1}: On branch1: <yourOtherStashName>
To retrieve the stash you want, use this:
git stash apply <corresponding index found in curly braces of git stash>
Bisect
Have you ever had a bug in your code but you don't know which commit has it initially introduced? Did you solve or try to solve it by tediously going through every single commit, one by one, hoping to see where the bug was introduced? This can genuinely happen from personal projects to big company codebases and both can come with extreme stress to try to resolve. Introducing, git bisect. This command works like binary search. Binary search is a lot better than linear search. It essentially saves you half the time searching for a bad commit using the following command:
git bisect start
and to end the process, write the following command:
git bisect reset
While you are bisecting, you need to specify the last commit that was good and bad. This will look like the following code respectively if you already wrote git bisect start:
git bisect good <commit ID>
git bisect bad <commit ID>
If you do not add a commit ID, it will start from the latest commit so if you do not include an ID on both, the binary wouldn't work. To really make sure you understand bisect, I'll give you an example:
0 --> 1 --> 2 --> 3 --> 4 --> 5* --> 6 --> 7 --> current(8)
The asterisk is the bad commit you have. To begin the bisect, write:
git bisect start
git bisect good 0
git bisect bad
(If you do not add any commit ID, it'll default to the most recent commit). Let's write the worst-case scenario if you have no idea where the good or bad commit is. The search will start at the commit ID 4. If the bug does not exist (which it doesn't because it is in commit ID 5), we write git bisect good. This will eliminate all the commits on the left side because the bug does not exist there and now we are dealing with 5, 6, 7 and 8. Let's say it cuts at 7. Is the bug in commit ID 7? Yes it is, we write git bisect bad and we eliminate 7 and 8. Now we are dealing with 5 and 6. You should sort of understand how it is working now but let's say it goes to 6. The bug is still there so we write git bisect bad and now there is only one commit and that commit is the origin of the bug. The total number of operations was 3 and we said we have no idea where the bug is so, this was the absolute worst case possible. This is definitely better than searching linearly, 9 operations. If we doubled the amount of commits to 18, we would only have one more operation in comparison to if we were searching linearly which is why binary search is amazing.
Top comments (0)