4 Git Best Practices & curated list of life-saving articles

4 Git Best Practices & curated list of life-saving articles

Habits every developer should adopt

ยท

3 min read

Hi folks. In this post I want to share some tips and suggestions on common best practices for the method of work, that are not always explicitly stated/taught.
When we transition to a new environment, there's a certain learning curve involved before we get on with our work smoothly. I struggled with my modus operandi and after tripping on many pitfalls, I think these tips might be of help:

  1. Don't branch when you start working. Branch when need to push.
    I've had situations where I faced merge conflicts due to early branching. You don't know how long its gonna take for you to fix that defect or complete that story. By the time you are ready to push the changes to remote repository, there might be significant changes in many files. And may be even on the one that you're working on. This is typically the case when many teams are working on a repository. Hence, always create a branch to push your code when you are actually ready to push.

  2. Pull every morning. Keep the code base up to date
    Branching off of the previous comment, keeping the code base up to date is ofcourse very essential, but the frequency is what matters. I had this question when I started in my new role "how often should I pull?"
    The answer is every morning. Don't worry you won't lose your work. And if you're unable to, because of un-committed changes, then stash your things are apply them after you've pulled. This way, you can lift-off from where you ended yesterday.

  3. Always sign/author your commits, if you don't.
    Although some organizations have some guidelines regarding this, but that might not always be the case. Even though the organization has a way to keep track of who's changed what, it's always advisable to author your commits. I prefer ending the commit message with:

    Reviewed by: Reviewer Name <email@addre.ss>
    Signed-off-by: Your Name <your@email.id>
    
  4. Squash all your commits into one once you're done.
    This is something you must be aware of already. Squash all your commits before merging. This way all the code changes for a fix/feature are consolidated into one, and the whole thing is much clearly maintained and tracked.

These are the few things I learned the hard way. I hope you adopt these habits soon if you don't already.
Before signing-off, below are some guides and articles in Bonus section, that I find very useful & you might too.

ย ย And even though cats may rule this world one day, you are reading Code with P. ๐Ÿ‘‹๐Ÿˆ

BONUS - Resources

ย