Git : Starting off

In this article, we are going to see about how to get going with git. For a more formal introduction of Git , Kindly check out my previous article.

We saw about why and how git came into existence. We also saw why we need a tool like Git. If you are still not quite sure, why people use ‘complicated‘ version control like git , for sure you will get that idea when you start using in your projects.

Installing Git

In order to use git, we must first install git.

I dont want to go in detail about this . So refer this link.

Creating a work environment

When using git, we must define the limits in which the particular instance of git must operate on. This ensures that git doesn’t have to look all over the computer for a single line change that you make in your software.

To use git in a repository / project , it must be initialized first. To do that, use git init in the folder containing the project code.

git init

What git init does is, it initializes it with the initial version of the project . So the state at which git init is entered is the first state of the project according to it . All previous states are not traceable with git.

Moving ahead

After successfully managing to create a initial repository , we may have to add contents to the project.

In Git , there are two stages for git ‘to record the changes’ you made in your project. We will quickly see why we need a 2 step process !

Staging for a commit :

Staging for a commit or also ‘adding‘ is the first process. In this step , we instruct git to track certain changes only.

It is a way of saying to git that ” hey these are all the changes i intended “.

Staging can be done by using a command called ‘git add’. Git add takes arguments. The arguments are the filenames of the files that are to be “staged” for a commit. To add all the changes in the entire folder architecture below the current folder, we can use git add . , where ‘.’ signifies ‘all’ .

git add files/core files/data

git add .

Commiting changes

This is the next step in committing changes in a git repository.

Committing changes is the equivalent of saying that ” Hey git ! Note the changes i recognized , add it with the previously known version,  as the next version “.

Only after a commit is made , the changes are actually registered in the git data structure. Simply adding a change is not enough because to git an unadded change is equivalent to an unconfirmed change. When we move forward , we will learn about rolling back changes and branching and stuff. All these can happen to or from a ‘recognized version‘ of your code. Unless or until a commit has been made to a code , it cannot be rolled back to that part.

Git assigns a commit ID ( actually 2 , a short one and a long one ) to every commit . Also git has the amazing feature of adding commit messages , which enables the users to specify what has changed in the commit . It is compulsory to specify commit messages , for each commit . Commit messages can be specified by using editors. By default if the command ‘git commit’ is specified , the files and changes staged for commits are taken for the commit and git asks for a message for this commit. Git commits can either be specified directly by using ‘git commit -m “<commit message>”‘. If no message is specified in the command, the default editor is opened.

Good Practices

Before progressing ahead , there are some good practices which will make usage of git actually useful .

1. Instead of including all the changed files at a stroke, only the related changes must be included ( ‘added‘ ) for a commit.

For example, let us consider , that we have added two different features. Instead of adding the entire directory , it should be taken care that files or changes related to the particular feature is only added . Commits must be specific to a particular feature , so that when we have to remove or add that particular feature, it can be easily done by using git commands like git cherry-pick or git checkout .

2. In case if a particular file has changes for both of the features, changes for a particular features can be isolated by using ‘git add -p‘.
Parts of a separate file change, is called a hunk. We can either choose to add a particular hunk or choose to ignore a particular hunk or even split a particular hunk into 2. Below is an example.

Screenshot from 2018-04-15 19-42-56

Screenshot from 2018-04-15 19-43-19

Screenshot from 2018-04-15 19-43-37

Screenshot from 2018-04-15 19-43-53

Screenshot from 2018-04-15 19-44-28Screenshot from 2018-04-15 19-44-13

3. Commit messages must be descriptive. Initially it may seem that commit messages are useless . But as the code becomes larger, it is difficult to read through all the changes to understand what feature has been included or removed.

4. It is often recommended to ignore binary files while committing using git. Changes in binary file can be too much for git to handle. So use the feature called .gitignore, which is used to ignore files that match a separate pattern.

 

Screenshot from 2018-04-15 20-18-04
Eventhough there is a file called idontwantthis.bin . git add . does not add that file since it matches a pattern in .gitignore

 

In the next article , we will see how to remove or change the last commit or staging operation. Thank you !

2 thoughts on “Git : Starting off”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s