Mandatory stages in Git

We have already seen how to setup Git in the previous post. So next, we move on to our current project directory in terminal and initiate the Git, which in simple word means that we are starting to track the current project files. After moving on the working project directory, the following needs to be done:

Initiating Git

git init

This adds up the hidden .git directory in the project folder, that would be used to track all the changes in the current project directory. This is done only once for a particular project. Until this, the project files were, what we call, untracked. The list of untracked files can be checked out by typing the following:

git status

Tracking new and modified files

To start tracking a single modified file, type the following in the terminal window as:

git add filename

To track all the files in the project directory at a single instance, particularly when starting with a new project, type the following:

git add .

So now we can say that all the new as well as the modified files are being tracked and are staged. The files are now queued to be further committed. Note that, for every further modification that is done to the individual file, the change has to be staged again using git add before committing.

Viewing Your Staged and Unstaged Changes

After the git add, the staged files are ready to be committed. We can check for the changes as:

//to list out the untracked and modified files
git status

//to check the difference between the modified files and staged files
git diff

//to check what staged changes are going to be committed
git diff --cached

Committing the changes

Committing the change simply records the snapshot of what has been staged previously. To commit the code, all you need to do is:

git commit -am "your custom text"

This records all the changes in the form of the snapshot and even the further modifications are detected using these snapshots.

Adding shortname for the remote repository

This step is also needed only once for a particular project. What we do here is add an alias or simply assign a shortname to the current project Git repository URL. For example:

git remote add sn [email protected]:example-project.git

That means that from now on, we can push, pull, fetch or do anything using just ‘sn‘ in place of the complete Git repository URL. To get further details on git remote, just type the following:

git remote -v

This lists out all the shortnames assigned to the project Git Repo URL .

Pushing the committed code to Git Repository

Pushing the committed code to the remote Git repository is the final step in the process. By default, master branch is already present whenever a new project Git repository is created. So all we got to do is:

git push [shortname] master

For instance:

git push sn master

So, for all the subsequent changes, make sure to add, commit and push. Note that the shortname has to be added only once for a particular project. In the upcoming post, we will be discussing about Forking involving git checkout, git clone, git fetch, git merge and many more, considering that there are several people involved in a single project, who make their contribution and push back the changes to the respective branches.