In recent times, i’ve found some very useful git commands in our daily workflows. In general, developers will be familiar with simple git workflows such as git initialization, commit messages and push to existing master repos. The next step for git workflows itself might be extend to creating a new branch, merging a branch, resolving conflicts or pulling from a repo that is available on the remote.
Coupling rebase whenever pulling another branch
git itself is very intuitive and there will be some insanely useful git commands to make it easier for us to collaborate with fellow developers (although, I’m not sure whether this git command has been frequently or become standar in their company that used by other people or not hahaha).
For first useful git command, instead using git pull origin <branch>, i think we should using git pull --rebase origin <branch>. Why? Sometimes we have an upstream that rebased a branch we’re depending on. This can be a big problem that causing messy conflicts for us if we’re gonna to pulling that branch. Simply said, if you’re pulling a branch without rebase, you just merges and creates a merge commit from remote branch into your local branch (and this probably occured a messy conflict because the most recent commits just placed after the merge), hence, if you’re pulling a branch with rebase the chances of you getting a conflict will be small, because the most recent commits will be placed on the remote master (or remote HEAD). Using rebase itself in this case also pretty useful because the visible commit message is not like the Merge branch ‘develop’ of gitlab.com:… but the commit message become commit message that appears is the last committed.
Modified a commit message after pushing
Have we ever thought about changing the commit message after pushing the local repo? If you think your commit message is incorrect or something is wrong or just a “typo”, you can change the commit message by using the git command --amend -m "new commit message". I find this git command very useful because based on my experience for a while, many fellow engineers in my office often have many typos in their commit messages. As for concern, you can only use this git command if you haven’t pushed it to the remote branch, and if you want to change the commit message that is already on the remote branch then you need to use a force command after ammending the message.
Using —force-with-lease instead —force only
In this case, git push --force will be useful and can be used in cases like the one above. However, we should use the git push --force-with-lease command instead of just using --force. The most realistic difference is that when we use --force alone, we will overwrites a remote branch with your local branch. By using --force-with-lease is a safer option that will not overwrite any work on the remote branch if more commits were added to the remote branch (by another engineer what you have). It is also ensures you do not overwrite someone elses work by force pushing.
RERERE is love RERERE is life
Yeah, this is probably the most underappreciated git command and i’m pretty sure that the git command for this one is very rarely used. git rerere itself is an acronym for reuse recorded resolution, where this functions to automatically correct a recurring conflict. The scenario is like this, you have already fixed the conflict on your local branch, and you have pushed to the remote branch, then there is a conflict similar to the conflict that you just corrected earlier, and of course it’s very suck. This is where git rerere comes in, this git feature takes a something like keys of every conflict as it happens, and pairs it with a matching value of fingerprint when the problematic commit gets finalized. Later on, if a conflit matches the first key, rerere will automagically use the matching fix for you. Based on my experience using this command, this feature can be done when we activate the rerere with the command git config --global rerere.enabled true, then when a conflict occurs (either when you do pushing, pulling or merge a branch), a message appears like Recorded preimage for ..., if this message appears then we don’t need to resolve the conflict because the conflict has been confirmed by us before and has been saved based on the keys and values earlier. We can commit directly with git commit --no-edit which later the commit will be recorded and we can safely push again.
Safer option whenever undoing the changes
For the last one, if you feel that the commit you pushed is wrong, you can use a variety of methods and i think one of the most appropriate is to use the git reset --soft. When using git reset --soft HEAD~1 you only will remove the last commit from the current branch, but the file changes will stay in your working tree. Also the changes will stay on your index, so following with a git commit message will create a commit with the exact same changes as the commit you reset before. Eventually, we can also using git revert which in functionality is also similar to git reset, with the difference is that when we use git revert and after that we do a commit message, the commit message will create a new commit message (different from git reset which remains the same as the previous commit message). You can use these two git commands depending on the your situation, do you want to change the previous commit message or stay exact the same.