5 Best practices of using GIT, that every software developer should know — in 5 minutes
Tags: productivity, git, github, githunt
Published: 2020-02-08 22:42:19

5 Best practices of the GIT Version Control System (VCS)…

## Table Of Contents
  1: Best Practices(#chapter-1)
  2: Bonus - Pro Tips!(#chapter-2)

### Best Practices <a name="chapter-1"></a>

#### 1: The Branch Names best practices<a name="chapter-1"></a>
One of the most important aspects of GIT is to wisely choose branch names. We make branches on a day-to-day basis and hence, it becomes a very important and good practice to follow branch name conventions.

It not only provides visibility to all the other team members but also makes our life easy to maintain and debug the changes at a later point in time.

Attaching below is a handy and self-explanatory template:

![GIT branch names best practices](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/02222.png)

Most of the time we end up messing with our main master branches, a good way to deal is to either make a new master branch with some identifier (stage ex: prod) or directly identifier `stable` can be used also.

> Usually some people/teams preferred the same conventions but with a prefix of the Developer's name. Ex: `burhanuddin/topic-API-rate-limiter` which is also fine.

#### 2: Commit Messages best practices

Below are the reasons why commit messages are important:
    * Clear and concise description or summary of what is done in the commit, or the issue/ticket closed by the commit & leaves a good impression to other developers!
    * Visibility & clarity amongst the team members and Debugging!
    * If you have any security vulnerabilities in your repository (repo) that GIT reports like **We found potential security vulnerabilities in your dependencies** and if you have followed the GIT commit messages conventions below then GITHUB will automatically fix that for you by fixing that build-commit directly as per backward compatibility if it's possible.

Attaching the template, commit message format:

    COMMIT MESSAGE MASTER FORMAT: <TYPE>(<SCOPE>): <SUBJECT>

##### SUBJECT:
The subject contains a succinct description of the change:
    * Use the imperative, present tense: 
        “change” not “changed” nor “changes”
    * Don’t capitalize the first letter
    * No dot/period (.) at the end

##### SCOPE:
 Mainly file_name/s, for a bunch of files, use functionality name

##### TYPE: 
  Please see the sub-template attach below for that (divided into 4  segments):
![Commit messages TYPEs](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/07.png)

Yes, there are tools like [commitizen](https://github.com/commitizen/cz-cli), etc. that are just all of the above. But, I don’t like that for simple reasons:
    * It asks so many details before allowing us to commit
    * Restrict us to make it our habit to do it on our own — which I prefer generally!

#### 3: Squash, Rebase & then Merge for linear commit history on the stable branch

This is something again based on the practices which various DEV teams follow. Some teams follow and want to maintain merge commit while others prefer to have a linear commit history on the `master` OR `main` branch.

The best of both worlds is to Squash the *related* commit on the feature branch and then go for rebasing followed by a merge. This will have a linear commit history while the related commit will be squashed (like a merge commit)

The downside of the above approach is that you may need to avoid squashing if multiple developers working on the same branch as this approach require `force` push. A turnaround of this is to use `--force-with-lease` while pushing on to the feature branch after squashing.

```
git checkout -b topic-something # HEAD off from stable
git rebase -i HEAD~5 # Squash 5 commit made on the feature
git push origin --force-with-lease topic-something
git pull origin --rebase stable-branch # If fetched already
git push origin topic-something # Pushing merge conflicts fix

git checkout stable-brach 
git merge topic-something # W/o --no-ff avoiding merge commit, thus maintaining linear commit history
git push
```

Below is the useful command to check the commit history in the form of decorating graph, you can alias the below command using `~/.gitconfig` details on this to be followed.

    $ git log --all --graph --decorate --oneline --abbrev-commit


![git-merge with — no-ff v/s without — no-ff](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/03.png)

#### 4: Use --reset-index instead of --cached

We at times run into a problem where `.gitignore` simply doesn’t listen or work. This happens for already tracked files by GIT. Eventually, end up using — cached flag, but it is having 2 disadvantages:
    * --cached flag sets that particular file flag as deleted in staging, end up having one extra unnecessary commit.
    * And after the commit, if you pull that code, into the production repo, it will delete that file (say config file), and hence eventually mess up the entire production code.

A simple solution is to update that particular file index to listen to `.gitignore`

    $ git update-index --assume-unchanged <file-names*>

#### 5: Use GIT config for aliases, push/pull  settings and across different workspaces

GIT config can be highly useful for the following reasons:
    5.1: For adding **author info for each commit globally and locally for different workspace across the same system**:

![GIT author info using config](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/04.png)
    5.2: For adding the GIT default **merge-tool** and **diff-tool** very handy! Helps in resolving the merge-conflicts from the terminal itself:
![GIT mergetool + difftool settings](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/042.png)
    5.3: Make **aliases** for your favorite GIT commands, for example, is used for mainly below command:
![GIT aliases using config](https://raw.githubusercontent.com/burhanuddinbhopalwala/blogs/master/blog3/05.png)

There are other more useful features of GIT like setting the `core.editor` or settings `file-options` etc. for which GIT config can be used.

### Bonus — Pro Tip! <a name="chapter-2"></a>

Recently (2019) Github announces **GitHub Actions** that enables SDLC or CI workflows directly from GitHub only. GitHub Actions are available with GitHub Free, GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub One.

It is a plus, as compared to using 3P CI services like Travis CI, Circle CI, CodeShip, etc. because it eases the maintenance to maintain the Workflow from GitHub only. Attaching below is a sample YAML file to set up the GitHub Actions into your repo:

{% gist https://gist.github.com/burhanuddinbhopalwala/0b3189504b3280c842a196ecf11c0ce2 %}

*Thanks for reading. I hope you will find this blog helpful. Please stay tuned for more such upcoming blogs on cutting-edge Software Development Engineering, Big Data, Machine Learning & Deep Learning. And lastly, always remember to breathe :)*

## Playlist:
   * ***Big Data & Cloud Engineering***:
     - Medium-Towards Data Science Publication — 4 Easy steps to setting up an ETL Data pipeline from scratch {% medium https://towardsdatascience.com/4-easy-steps-to-setting-up-an-etl-data-pipeline-from-scratch-a6e67c40b6e1 %}
     - Medium-Towards Data Science Publication — Amazon S3 Data Lake | Storing & Analyzing the Streaming Data on the go | A Serverless Approach {% medium https://towardsdatascience.com/amazon-s3-data-lake-storing-analyzing-the-streaming-data-on-the-go-a-serverless-approach-48b68a9433ff %}
     - Serverless Database migration and replication in nearly no downtime {% medium https://medium.com/analytics-vidhya/moving-an-on-premise-production-database-to-a-managed-cloud-serverless-database-in-nearly-no-d1fb3f47cfd3 %}