Git is a distributed Version Control System(VCS), founded in 2005 by Linus Torvalds. Version Control System is the system used to track the changes in the files of our project. Git is a distributed VCS as more than one developer can make their contributions to a project without being on the same network from anywhere in the world, this is also the main reason that makes git stand out from other VCS as they need the developers to be on the same network. Git allows us to check which member in our team made a change and when, and if in any case, the change turns out to be not so well the team can then revert back to the previous versions at any point in time, and that is an important feature if you are working on your projects and one line just spoils all the fun.

Git works well with both local and remote repositories. The Local repository refers to the repository/directory we have on our local machine, while the remote repositories refer to our project repository hosted on the internet. There is various remote repository software like GitHub, Bitbucket, etc., which help us to host our local repository on the internet by a simple push command. For working with local repositories you need not have an internet connection but while working with remote repositories you need the internet to host your repository on the internet with the “push” command.

How does Git track our code?

The way Git keeps track of your code is that it takes snapshots of your code.

Now you might think about how and when are these snapshots taken and who takes them? — The answer to this is that whenever you make changes to the code in your project snapshots are taken only when you decide that you want to commit these changes. This snapshot is then taken when you run the “git commit” command. There is a scenario to it, that whenever you want to commit your changes you’ll first need to add them to the staging area using the “git add” command. We’ll see working on it later in our blog.

This snapshot can then be revisited as discussed earlier at any point as discussed earlier.

Starting up Git on your Local Machine

Once you have installed git on your device from here, we can move ahead to start initializing git to your machine. Go to your project folder on the local machine, right-click in the folder and select “open with git bash”.

The next steps that follow are to set up your configuration information, and this can be done using the “git config” command. In the git bash terminal after the init command type “git config --global user.name ‘YOUR_NAME’”, followed by “git config --global user.email ‘YOUR_EMAIL’”. And with these steps, you are done with setting up Git on your local machine.

Working with GitHub

Let's now talk a bit about GitHub. To work on Github and host your repositories you need to create an account. After signing up you can create a repository on the GitHub website which is easy.

Cloning your repository on the local machine

Once you have created a repository on GitHub you’ll want to clone it on your local machine so that you can make changes to it and push them to your remote repository. For cloning a repository open the repository and copy the link from there.

Once you have copied the link open git bash or any other terminal at your preferred location and type the following command- “git clone LINK_COPIED”.

The folder will then be cloned on your local machine. Once the remote repository is cloned on your device a “.git” folder is created which is hidden but it's where all of your changes and commits are recorded so would not want to trouble this folder.

Adding Changes to your repository

Once done with cloning you can now go ahead and make some changes in your local repository. After making the changes you can now add the changes to the staging area using the “git add” command followed by the file name you made changes in. If you have made changes in multiple files or added multiple files you can simply run the “git add .” command rather than specifying the name of any file, this will simply put all of your files in the staging area. To now check which of your files/folders are in the staging area you can run the “git status” command to get the details about the same.

The files that are mentioned in green color while the files in red are yet to be staged for further commit. Now to commit the files or to take snapshots of them we need to run the “git commit” command. The commit is followed by a message for which we use the “-m” flag to specify a message that tells why the changes were made.

In the above example, the first ‘-m’ is used to specify the title for our commit message while the second ‘-m’ flag is for the description of our commit message.

Sending our Changes to the Remote Repository

Remember that after committing your files your remote repository remains unaffected by any changes you have made to your files while committing. The changes will only be reflected on your local repository, to make them reflect on the remote repository you now need to push the files to the remote repository.

To push the changes to your remote repository hosted on GitHub you can run the “git push origin BRANCH_NAME” command. The BRANCH_NAME can be replaced by the branch you are working on by default the branch name would be main/master until you have created a new branch.

That’s it you can now check that your changes are successfully reflected on your remote repository too.

In a case when you have not created a remote repository on GitHub, rather you have started with a local repository you’ll first need to create the new repository for the same on GitHub then, copy the link for the repository and run the command “git remote add origin COPIED_LINK”. After running this step you can now push your repository using the -u flag to GitHub anytime.

Branching in Git

In the push command mentioned before we encountered something called Branch name. Now, what are these Braches?

You can consider branches in git similar to those in trees. The branches are used to divide the workflow, in Git. In our example before we were on something called a master/main branch. This branch represents the default workflow of our project until we create a new branch.

When we create a new branch at first the code within our new branch and the master branch remains the same but as we start to update the code within any of our branches then, in that case, the code residing within the other branch won’t change as there is no mechanism for an independent branch to know what changes have occurred in other branches. Now how is that useful?

Many a time you’ll be working to develop a new feature for your project and in that case, you might not want to disturb your original workflow(i.e the master branch) rather you’ll want to work on a separate area where if any major error occurs your original workflow will remain unaffected of it.

Creating a New Branch

To create a new branch in Git we use the “git checkout -b BRANCH_NAME” command. Once we have created a new branch we will automatically be switched to that branch and will be working on it. To check the branches you have and which branch you’re currently on run the “git branch” command.

In the above example, the feature branch is newly created and is prefixed with a ‘*’ that represents that it is our current branch. Now if due to any case you want to switch back to your main branch you can run the “git checkout BRANCH_NAME” command(Notice that in this there is no -b flag which was used when we created a new branch)

Now once you have made certain changes in your new branch you are ready to commit then and these steps are similar to those we discussed above for the main branch. It’s noteworthy that even after making changes in your new branch your changes won’t be reflected in the main branch of any other branch as discussed earlier for that you’ll need to merge your branches and there are 2 ways of doing so: 1.) Using the “git merge BRACH-TO-MERGE” 2.) By creating a Pull request.

Let’s first do that using the merge command. But before merging the branches if you want to check what changes you’ve made in your files you can use the “git diff” command.

Once you’re sure of your changes you can now merge them into the main branch using “git merge BRANCH-NAME”.

Pull Requests

The other and the most commonly used way to merge your branches is via creating a pull request or a PR. What is a PR?

A Pull Request is a request to have your code pulled into some other branch. In this case, we are making a Pull Request from our feature branch to our main branch. To make a PR to our main branch we first need to push the changes made in our new branch to GitHub using the command “git push”, but this time we use the -u flag with it.

Now you can go to your repository and you’ll notice a banner telling you to create a pull request using which you can create a PR.

On the next screen, you’ll need to leave a message on why do you want to merge the branches and what features you have added.

Once you have created a PR you can now merge your branches using the merge option in the next screen(This will work only if you are the owner of the repository).

Now in the practical case, while merging a file some merge conflicts might arise which needs to be resolved before you can merge your files. This will not be discussed here but later on in some other blog.

If you used the Pull Request method to merge your branches you’ll now need to pull the files from the remote repository to your main branch to visualize the changes on your main branch.

Once you are done with the new branch you can manually delete it using the git branch command followed by the ‘-d’ flag and the name of the branch to be deleted.

Undo changes in Git

As a human being is a statue of mistakes, it might happen that you staged or committed a file accidentally on Git. But worry not git has got you covered with its commands.

Undoing a file from git add

Let’s say you’ve made some changes in your files and you in some hurry add those to the staging area and now you wanna remove them from the staging area. You can do that using the “git reset” command followed by the file you want to remove from the staging area or you can run only the “git reset” to remove all files from the staging area.

Undoing a Commit

Now let’s assume that you’ve gone a step further with your mistake and even committed the file well in this case you can again use the “git reset” command but in this case, it will be followed by “HEAD~1”, this tells git to make head pointer of our workflow to move 1 step back of the recent commit we made. This means the head will now point to the commit that we made before our accidental commit.

In Git we can also go through the changes we committed until now using the git log command.

The keys marked/underlined with blue ink can further be used to revert back to any commit you want. This is why a good commit message is considered useful as using those you can figure out which features in your projects you want to undo. To reset using the keys you can use the “git reset KEY” command.

Forking in Git

I GitHub you have access to make changes to your repositories that you created under your username, but what if you want to contribute to some other repository. Well in that case you can fork that repository, which in simple terms will create a copy of that repository under your username.

You can then create branches, do some changes, commit them, and finally send a Pull Request for your changes to be accepted, and if you made some positive changes on the project your code might even be merged into the original repository.