6 Git tips for everyday use
Tags: Development, Software Development, Programming, Source Control, Git

I’ve recently noticed how many things I’ve learned with experience, I assume, to be common knowledge. Although, not everything that is obvious to me can be obvious to someone else. I hope you’ll find something for yourself.

Start fresh, merge fast, merge often

There are many branch strategies that you may use for managing your source code. Still, I know for sure that the longer the branch lives, the more chances it will cause you massive headache merging the changes.

Every time you start working on a new piece of code or fixing an existing one, make a branch specifically for it from the latest source code. As soon as you’re done, and change has been approved and merged, delete the branch. You might say, but hey, this next thing I need to build depends on this work, why wouldn’t I keep working on this branch?

I’ll answer, sure you can, but in this case, you need to make sure you keep rebasing the latest code in your working branch and help you God if somebody else is working on the same files.

The general best practice for Git is to commit fast and often. I will add that you also need to merge fast and often. Going in small increments allows you to avoid merge conflicts. It exposes your work to the team sooner so you can get feedback more quickly. In case the work you’re doing contains flaws, you would know about it before you’re too deep in the rabbit hole.

Make Amends

Did you make a commit and then notice a typo or a missing space right after? Instead of making a “fixed typo” commit, you can add it to your previous one. Just make a change, stage your file and then do `git commit — amend` this way it will add your fix to the last commit and will also allow you to change the name your previous commit.

Note: if you have already pushed your changes to remote and then made an amend, you will need to git push — force

Backup before doing wonky stuff

There are situations when your branch becomes all messy and full of merge conflicts, and you’re not sure if your next command is going to fix it or break it for good? Before proceeding, make a backup branch, just in case, to have your changes somewhere. If you override the history of your working branch by accident, then parts of your work might be gone!

Use aliases

Using aliases saved me ample of time typing “checkout” or “commit” every time. Setting aliases is as easy as that:

$> git config — global alias.co checkout

$> git config — global alias.br branch

$> git config — global alias.ci commit

$> git config — global alias.st status

For some more advanced aliases check this article

Use stash

Have you ever started working on something only to realize that you’re in the wrong branch? Or have you ever found yourself in a situation that you’ve changed something, and your program stopped working? Now you’re commenting out a piece of your code or reverting line one by one to find a problem? Maybe your project has some configuration file that you need to change every time you work on your code locally?

Look no further than git stash to solve all the above scenarios for you. This command will take all your uncommitted changes and save them to a safe space independent of any branch and revert all your uncommitted changes on the current branch.

If you started making changes in the wrong branch and realized that before committing a change, do a git stash, switch to the branch you need. Then hit a git stash pop, and all your changes reappear but on the correct branch now.

Once the stash is popped, it is not going to disappear. You actually may see all your stashes by using git stash show. That means that you can pop stash multiple times. So if you have that annoying config file that you have to change back and forth, you can simply stash and pop it as you need. You can do it via `git checkout stash@{0} — <filename>`

Also, useful when you do your work and suddenly completely unrelated unit test starts failing. Now you’re not sure if you broke it or it was broken before you’ve started. Stash your changes and rerun your tests to learn the truth.

GitLens extension for VS Code is super convenient for managing your stashes, just FYI.

Don’t delete your local repository

Not once I’ve seen people working on the local branch then pulling the latest code into local and being overwhelmed by the number of merge conflicts. In fact, they were so overwhelmed that deleting a local repository and downloading it again seemed like a valid option. What a surprise was for them to realize that all of their work was now gone.

In reality, deleting your local repository to fix a problem is never a viable option. So if you ever considering removing a local repository, do this thing first: Ask for help.

Do not hesitate to ask for help. It takes time to get used to Git. Being afraid of asking questions and appear not knowledgeable is not as bad as not asking questions and staying unknowledgeable.

Hit me up on Twitter to tell me what a bunch of nonsense I’ve written.