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.
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.
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.
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 .
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.
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.
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.
In the next article , we will see how to remove or change the last commit or staging operation. Thank you !