Git Best Practices

When you’re working as a software engineer, collaboration is a part of the job. In today’s world, coder collaboration has been made increasingly difficult by remote work, so finding the best DevOps tools is crucial.

Developed in 2005, Git is the most widely used modern control system used by countless developers around the world. Git is version-control software for working on group project collaboration. This devops tool is used for open source code management, and can be used to handle everything from small to large projects efficiently, track changes in the source code and enable multiple developers to work together on code development.

Think of Git in a similar category of Google Drive; just as this software makes it possible and very easy for multiple people to write, edit and add to a single file, Git is a computer program making it possible for multiple coders and project managers to collaborate and work on a single project simultaneously.

Before you get started, you should know that Git stores its data in a unique way; Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots.In this article, we’ll be walking you through some of the basics that you need to know to master Git, as well as some tried and tested best practices that can help you make your workflow a lot more seamless and efficient.

The Basics

There are many advantages to using Git to work on your project, but by far the main attraction of this DevOps tool is its branching functionalities. Before we get into the best practices you should make a part of your regular working routine, we want to take the time to explain some of the terminology you should familiarize yourself with:

1. Commit: stores the current contents of the index in a new Commit along with a log message from the user describing the changes. This command captures a snapshot of the project's currently staged changes
2. Branch: a pointer to a Commit. As you start making Commits, you're given a master branch that points to the last Commit you made so you can easily track the progression of your work
3. Master: the default name for the first branch
4. Merge: joining two or more Commit histories
5. Local Repository: where you keep your copy of a Git Repository on your workstation
6. Remote Repository:a secondary copy of a Git Repository where you push changes for collaboration or backup
7. Pull request: a term used to let others know about changes you've pushed to a Branch in a Repository
8. Merge request: a term used to let others know about changes you've pushed to a Branch in a Repository

Best Practices

Ok, so we gave you a rundown of some of the phrases you need to know to master Git, now let's move onto some best practices used by countries other experienced developers. Forts of all, do as much reading about Git as you can. Reading this article is a great start, but constantly keeping yourself up-to-date on what other coders are doing to make their working lives easier is a good best practice in itself.

Commits

First things first; get yourself into the habit of Committing early and often. You need to Commit in order for Girt to take a proper log of your data in a Repository. Failing to Commit If you fail and then making a mistake can lead to more work for you in the long run, so it’s vital that you get yourself into this habit from the start.. Additionally, having periodic checkpoints means that you can understand if something is broken, and pinpoint the exact action you took that caused it.

And if this happens, don’t panic; as long as you have Committed your work recently, it will not be lost for at least two weeks.

Now that we’ve discussed Committing early and often, let's discuss Atomic Commits. Basically, this means only Committing one small change at a time. The upside of an Atomic Commit is that the change is important enough to be recorded, but small enough to manage if something goes wrong. These smaller Commits are simply easier to track and change, so there is really no downside for you using this best practice that so many experienced developers swear by.

What not to do with Commits

A lot of the time, learning what not to do is just as important as mastering actionable best practices. When it comes to Commits on Git, it is advised that you never Commit dependencies or local configuration files.

It’s important to remember that the main function of Git is to store your source code, so Committing your dependencies or local configuration files can dramatically increase the size of the Repository and make your personal preferences public.

Lastly, when it comes to what not to do, this might sound obvious, but never Commit defective or broken code.This is why it is vital that you always test and review any changes before Committing. It’s also good to remember that you should always leave a clear and decisive Commit message for the rest of your team so they understand why you made a change, and you should never Commit a change that is unfinished for the sake of saving your work. There are other tips and tricks you can use to store unfinished work, like the git-stash command that will keep a record of your work and allow you pick back up where you left off without having to make things complicated.

Repositories

It’s always a smart idea to get together with your team to discuss how you want to set up your Git Repositories. The great thing about Git is that you can have as many Repos as needed, so it will really depend on the workflow of your time when deciding how to divide and conquer tasks. There’s no concrete best practice here; how many respostistors you set up will solely depend on the amount of tasks that need to be done in order to solidify a project. But the good news is that resopsitivies are unlimited. But know that defending your Repository setup well in advance of undertaking a project will only serve you in the long run. Gitenial.com has some great repository category breakdowns that can help guide you. You can check them out here, or we’ve added a couple of examples below

• A company or team-wide super-Repository for all projects.
• Repositories for files shared by multiple projects for easy re-use of code.
• Individual repositories for each project.
• Repositories for logical teams (internal, contractor, third-party), OR
• Repositories for logical segments of a project – per library or class, product or feature, etc.

Branches

The most important best practice when it comes to Branches on Git is using them to their full potential! Branches are by far, the most important and helpful feature on Git, so maximizing their uses can make your life a lot easier. There are different forms for Branches, like a larger, master Branch that you merge smaller Branches with as you work. Branches are essentially a new copy of your code's current state. A new git branch can be used for a number of reasons, including new feature roll outs and bug fixes. Branches allow you to manage the evolution of your task more easily, and help minimize the chance of mistakes being added to the overall Repository.

Branches can get out of hand easily, so removing old Branches will help keep your project on the right track and climate any confusion with team mates. Once a successful and tested Branch has been merged with a Master Branch, you no longer need to store that code on its own individual Branch. Keeping things organized will help both you and your team keep the project on track a lot easier.

Lastly, keeping your main or master Branch clean and bug free is a best practice you should not forget. Your main Branch is your vetted code that is ready to be pushed, so ensuring you do your due diligence and triple check all smaller Branches before merging is your best chance of success.

Wrapping up

Git is an amazing collaborative DevOps tool that can help you and your team get a project done in a timely manner and to a very high standard. With a few best practices, you can master the basics quickly and ensure that you are always using it to its maximum potential.