Pull, Fetch, Commit, Push, Merge, Rebase – have these terms have managed to make their way into your everyday lives yet? When Linus Torvalds created his very first version of Git, he described it as “the stupid content tracker”. Fast-forward to today, this free open-source software is now the most popular version control system.

What is Git? 

Don’t you wish you could turn back time sometimes, so you could have made a better decision or done things differently? Well, in the world of technology and coding, you can. Git is an open-source distributed version control system that saves versions of your precious code every time you make any changes/additions to it. So whenever you need to rollback, you just pick the working version and voila! Git also allows disruption-free working within teams as developers work on their individual local copies concurrently. Every change by every team member is tracked, thus maintaining transparency in an organized flow. So what is GitHub then? GitHub is a repository hosting service for Git that also has plenty of features to optimize your version control system. 

Git Workflow



Every organization has a different Git workflow. The most successful Git workflow is the one that gives your team enough space for productivity while maximizing the effectiveness of their outputs. It should be scalable with your team’s size and should minimize the number of conflicts that can arise. The Centralized Git workflow is the base upon which other Git workflows are built, like the Feature branching workflow, the forking workflow, the Gitflow workflow, etc. A workflow should be planned to enhance and complement your organization’s culture. To each Team, their own Git Workflow. 

Why use Git?

 

1. The distributed architecture 

Unlike Centralized version control systems that force developers to access the single central repository to be able to “checkout” and commit changes to the individual files, Git follows a distributed approach. In the distributed architecture, every developer has their own local copies of the entire central repository, allowing them to work offline, access complete revision history and easy branching and merging.

2. Powerful performance

Branching, merging, committing, etc. are really easy and fast with Git workflow because of its intelligent deep knowledge algorithms that understand the access patterns to the T.

3. It is Secure

Git stores all file content including relationships between versions and directories, cryptographically using a SHA1 as its hashtag algorithm. Any accidental or malicious code change is completely traceable.

4. Open-source

Being open-source, Git is free, enjoys good community support, continuously scrutinized for quality and is backed-up with loads of documentation and tutorials for learners.

5. Faster releases

Git’s distributed development and easy branching and creating of new features encourages developers to make more frequent changes in an agile workflow

 

 

Best practices for Git

• New project? New repository

It just makes good organizational sense to create a new repo for every new project you want to start working on. Once done, push it to GitHub.

•  New feature? Branch out

Now that you have created a new project, how about creating some new Git features? Git Branching lets you create and manage an organized workflow within your repo. Team members can be assigned various Git branches allowing them to work concurrently but in an isolated manner. Always give a meaningful to your git branch so others know what exactly you are working on. 

• Start your day by staying current

Always “rebase” or get the latest, the most current version of your project (master) before you start working on the features you created/ assigned to you. You don’t want to make changes on outdated files.

• Have periodic check-points

Don’t save your commits for a big change. “Commit” small changes frequently so the code is easier to comprehend for you and your team members. Reverting back and tracking is also easier when the changes are small and frequent. 

• Stash your work

Often, you might come across situations where you are working on one Git branch but you have suddenly remembered that you need work on another branch but don’t want to “commit” those half-done changes. Or you might simply want a clean working copy. “git stash” to the rescue. Stashing lets you save your unfinished changes on a stack where you can get back to anytime!

• Squashing them commits

Having lesser commits in your history makes it easier to monitor and track where you went wrong. If you want to keep a clean commit history, this one’s for you. Squash and merge all your commits into one when the pull request is merged.

• Commit messages

Always provide clear and understandable information in your commit message. Start by writing a short summary of your changes, leave a blank line and then follow it up with a detailed description of the change. You don’t want your commit history to end up looking like this :/ 

https://xkcd.com/1296/">https://xkcd.com/1296/</a></strong&gt;" data-entity-type="file" data-entity-uuid="982f7fb6-2ae8-4600-9a24-b018a85a5a28" src="/sites/default/files/inline-images/git-commit-messages.png" class="align-center">

 

• Don’t change history

Once you have committed your changes the repository, do not go back and change history. Although Git allows you to do that and rewrite pubic history, it is never a good practice to do so. Both for you and your team.

• Apply a Git patch

At times when you don’t have write access to the repository but you still want to fix a bug – apply a Git patch. Always remember to clone the master repository and then create a branch for the new feature. When you have your .patch file ready, always preview it and do a dry run to check for errors. Git apply the patch (git apply -R path/file.patch) once done. DO NOT forget to test and check for 

• Don’t leave Pull requests out for too long

An open “pull” request can create conflicts sooner or later. Don’t leave them unattended for more than 2 days. Always review the code and if it is ok to deploy, merge the pull request. This will not only fasten the shipping process but also avoid code conflicts.

• Better organizing with project management tools

If you have been using project management tools like Redmine, it is a good practice to use it in conjunction with Git to be able to manage multiple team members and their tasks better. Creating your Git branches with the Redmine task as the name is one of the best Git best practices as it allows for better transparency and organizing. 

 

• GitLab CI/CD

Using a Continuous Integration/ Continuous Deployment tool like this one allows you to test and check for bugs and errors and ensures compatibility with code standards. These jobs are performed after the code is pushed to the staging server.