Git: The common solutions.

#git

I have been using git for quite some time now. It seems quite easy to use at first but as one keeps using it, one may face certain difficulties. Thankfully, Git provides solution for relatively common scenarios.

Scenario #1 :

Suppose, I've created a project that has use private or secret tokens. Obviously, I would not let my private token end up in the version control. So, I'll have to make sure the file is not accidentally added to the version control.
Also, I may have some files or directories that I don't want to add to the version control( eg - node_modules/ ). But these will keep there as untracked files.

Solution - GitIgnore

In order to handle the above scenario, git provides gitignore. It is basically a file that you create in your git repository to ignore some files and/or directories while committing.
Inside the git repository, create a file named .gitignore and in that file, add all the file names which you don't want to add to the version control. Once you have committed this file, the file or directory names in .gitignore will be ignored by git.

A .gitignore may look something like this -

It will ignore npm-debug.log, config.js, and node_modules/ directory. If you want to ignore all .js files within your repository, then you may add *.js in your .gitignore file.

Scenario #2 :

The workflow with git is something like this -

Clone a repository to local machine using git clone.
Make the required changes.
Commit files.
Push the files to remote location using git push

Seems simple isn't it? Well, it is simple but if there all multiple files, it will take a lot of time to clone. Further, if it has a lot of commit history, then the time consumed in cloning increases. For Example- If a repository has >4K commits, every git clone will fetch all of the commit history.

Solution - Git Shallow Clone

Let us talk about the above example. The repository has >4K commits. I may not require all of this commit history. The cloning process will be faster if we only wanted the latest commits. Git provides a feature to only clone the required commit history. This is called Git Shallow Clone.

To use it, along with the git clone command pass a flag --depth and specify the depth of commit history you want. Here is an example -

Here, I'm trying to clone Linux kernel source tree. It has total of 704,972 commits.

So, a git clone will download 5608186 objects while with --depth 1 the size is reduced to 65237 objects.

Scenario #3 :

In order to work on a new feature, I've clone the repository. Now, my new changes may break the code. In other words, I'm not 100% sure that my changes will work perfectly. Suppose, while adding new feature, I received a call that another issue is critical and I need to fix it as soon as possible. So I fixed the issue and now I cannot push the code. Why? because the new feature is not fully functional. But the fix has to be deployed. What to do?

I can again clone the project and fix the critical bug. But, it I'll need to do all the work again.

Solution - Git branch

Git provides an independent line of development. We may think of them as a way to request a brand new working directory.

The commits in branches are isolated from other branches. This means if I've committed a change in one branch, it will not be visible in other branches. By default, we are on the master branch but we can make as many branches as we need.

git branch -> list all available branches

The output will be like this-

* master
branch_bug_fix

Currently I'm in master branch. In order to change branch I can use -
git checkout <BRANCH_NAME>

To create a new branch using current branch as source: git checkout -b <NEW_BRANCH_NAME>

To delete a branch use: git branch -d <BRANCH_NAME>

Scenario #4 :

So, I'm working on a feature and I need to change branch and work on something else. But wait! I haven't committed the code and git would not allow me to switch branches without committing. Also, the work is not complete so I cannot commit changes. The simplest solution is to commit changes with commit message like - feature x incomplete. It will work but it will add unnecessary commit history.

Solution - Git Stash

Git stash - Stash the changes in a dirty working directory away.

It stashes or saved changes temporarily so that user can work on something else, and then user can come back and re-apply them later on. It is very useful if there is a need to switch between different branches and switch the work mid-way through a code change.

In order to stash changes, use:

$git stash

We can reapply the changes using:

$git stash apply