Beginner's Guide to Using Version Control Systems
Table of contents
- Version Control system
- What is Version?
- What is Git?
- Difference Between Git and GitHub -
- Git Commands
- 1.) Initialising Git →
- 2.) Checking the status of the files →
- 3.) Adding a file in the staging Area →
- 4.) Creating a Version Or adding file in Repository Area →
- 5.) To look your commit or log history you can do something like →
- 6.) What if you want to revert back a file from stagging Area back to Working Area →
- 7.) We can also have a look on the difference between the two commits →
- 8.) Connecting Your local git repository to your Github repository →
- 9.) Uploading changes from the local repository to the github repository →
- 10.) Downloading the latest changes made to the repository by the contributors →
- Recommended Practice to do →
- Merge Conflicts →
Version Control system
What is Version?
So when we release any application we release it with minimal application
uses for our users and later keep on updating it with new features. Once we are complete with building one complete ‘milestone’. Now a Milestone is when we add few features to the existing application fix the bugs and a new stable application with a change or added features is a milestone. This milestone is then released in the form of versions.
Applications being updated on long terms can have many versions actually a whole set of version history.
And we can come up with situations where the new updated version is not much stable and want to revert back to the older stable version. That’s when our Version control System comes into picture.
Its not over here, now one application is not build by any one person its the collaborative effort of whole bunch of people working and building few features and contributing in the project. Its not like I build one page of the project and other page is build by my fellow mate and we just share that information over mails to test the things this is not done.
That’s why we have a bunch of tool that help us to do Version control and provides us an environment where we can have a collaborative coding contributions.
What is Git?
The simple definition of git can be a Version Control System with whose help you can manage different version’s of a piece of code.
You can understand it like you and your friend working on a project and makes a new feature for your project even though a simple one still its the new version of the project on the small scale and git helps to manage it efficiently on a very high scale.
Git is a free and open source application. One best part of git is its not a programming language so need not to worry of learning a new language more and less its like a tool.
Example → We all have worked with power points where we create ppts its too a tool where we just want to know the steps to add a slide.
In a similar way git is merely a tool where you just need to learn how to use it rather going inside of creating and thinking of logic how is it doing it.
Difference Between Git and GitHub -
So Git is a Version Control System and just like Git we have other VSC like Mercurial. Whereas Github is absolutely different then Git. Github is a Online tool for collaboration for Open soucre or Close source contributions. Github itself doesn’t do version control for you if you don’t have a .git file(Internally github uses git). Github just harness the power of git or similar VSC. Its an online platform where we have our code being published on the internet which manages our codes version just like VSC and instead of sharing the code on a private network we have made it on internet where people can come and have collaborative contribution its like a GUI interface.
Github have some additional feature like -
Github not only helps in managing the VSC rather provides few extra functionalities like.
We can raise an issue if there is any issue regarding some piece of code.
We can have a feature request for merging our feature in the production branch.
Gitbub is free.
Somw similar platforms like Github are Gitlab, Bitbucket.
Git Config →
If you have installed the git you can test it.
Open the terminal it can be gitBash Terminal or a window’s PowerShell Terminal or even imacTerminal and run these commands to check you have successfully installed it or not.
This will show the version of git in your system
git --version
Now Once you have installed the git you need to configure to enable using git and to attach it with your github.
Read this github offical docs for setting up the github confi → Gitbub setup offical docs linkOnce you are done you can run this command
git --config list
`
- to check your email and credential whether they have been setuped properly or not.
`
Git Commands
1.) Initialising Git →
When you run this command intialiases git and creates a .git folder.
Its a hidden folder. Created in the same repository.
Powers your repository to be managed by git.
If you re-run this command will re-intialise .git.
Now let’s say you don’t want to manage any versions all you have to do is delete the .git folder and it will loose all the tracks.
git init
2.) Checking the status of the files →
git status
`
- Helps in tracking the files whether they are in the stagged area or working area.
`
There are Three areas where our file changes can reside.
Working Area
Stagged Area
Repository Area
So any file change we do might lie in one of these areas.
Working Area →
Currently if we create a file or do any changes which is not been tracked by git is in the working area. Tracking means git doesn’t know that whether these changes will or will not go into the next version as not being tracked right not.
A file in working area is considered to be not in the staging area. When we do git status and see a bunch of untracked file then these untracked files are said to be in Working Area. You manually need to tell to git that which files you want to start tracking that will go into the new versions. As there could be log files or even some temporary files you need not to track those. So git itself doesn’t tracks file you need to tell it.
Staging Area →
All the files inside the Staged Area or Staging area are going to be the part of the next version that we will create. This staging area is the place where git knows what changes will be done from the last version to the next version. Tracks the file changes between the two commits.
3.) Adding a file in the staging Area →
This add command will add the file from the working area to the stagging area.
The file being added in the staging area means it will get tracked by git and will be added to the newer version.
git add <file-name>
- This command will just revert back the file being added to staging area to the working area.
git rm --cached <file-name>
- This command will help you add multiple files together into the stagging area -
git add <file1> <file2> <file3> ...
`
- All these files will get added to the stagging area.
`
- We can too add all the files to the stagging area in go with this command
git add .
- A good practice is considered to add the files in the stagging area one by one so that you have an idea that none of the un-useful file is being tracked by git.
Repository Area →
This area actually contains the details of all your previous registered version. And the files in this area, git already manages them and knows their version history.
4.) Creating a Version Or adding file in Repository Area →
One commit is like one new version.
Inside the git versions are maintained by the commit.
Commit is particular version of the project. It captures the snapshot of the project’s stagged changes and creates a version out of it.
git commit
`
- You register the staging area files to get commit through this command. And create a new version out of it.
- Once you enter it will show a terminal based text editor(actually its a vim editor).
- And expects you to enter a message before commiting the changes.
`
- We can add -m flag to just add a message there and then only avoiding the opening of vim/nano text editor.
git commit -m "<Your Commit message>"
5.) To look your commit or log history you can do something like →
So as we mentioned that every commit is a new version, therefore you will see a unique hash for each commit in the log history.
Because of this unique hash only we will be able to revert back to a version.
If you want to exit out of the git log prompt you can simple press ‘q’.
git log
`
- Will show you the whole commit history, By whom what time a commit was made.
`
- We have something like -
git restore <file-name>
which restores the mentioned file in original stage as it was stagged and all the new changes made to the file (the modified changes will be removed from it) will revert back.
This can be useful, if we write some dirty piece of code and now no more want it. Instead of deleting every changes line by line, we can restore it or you can say restore the last committed clean version of file.
6.) What if you want to revert back a file from stagging Area back to Working Area →
This command will help us revert back the file changes from the stagging area back to the Working Area where it will again be at modified stage and now you can do git restore to complete move back to the older clean version.
This command only works in stagging Area once you have made a commit and then try to have a git restore it doesn’t do anything as everything is clean and there nothing to move back as we have already made the changes to go to a new version.
git restore --stagged <file-name>
Difference between the git rm and git restore →
Git rm only works when you have nothing in the staged Area all the changes are already been committed.
But if we still want to make a git rm command then we can make a forceful remove with a -f flag.
If we want to move the whole file back to the untracked state, then we do git rm, otherwise if we just want the changes to be moved in working area or staging area then we do git restore.
git rm --cached <file-name>
7.) We can also have a look on the difference between the two commits →
- GIves the diff of all files changes between two commits
git diff <hash-id-second-commit> <hash-id-first-commit>
8.) Connecting Your local git repository to your Github repository →
Right now the git repository which we have is inside our local system and to make it availabe on the internet we just need to connect it with our github repository.
Helps us to add a new remote connection to our repository.
And we can do this with a simple command -
git remote add origin <Url-of-github-repo>
`
- This will just link our local repo to the github repo.
- Here instead of origin we can write anything its just a name of the remote connection most of the users use origin
`
- We can just see the remotes of our repository with a command -
git remote
`
- Will list all the remote connection.
`
Remote Connection → It hepls you to link two git repositories for uploading and downloading the changes from each other.
We can too delete a remote connection for the repository from the command -
git remote rm <name-of-remote-connection>
- This command will help you rename your remote connection
git remote rename <old-name> <new-name>
- Name of the remote connection is always used for establishing the connection of the repository.
9.) Uploading changes from the local repository to the github repository →
This command will just push or uplaod your commits on to the github repository.
Master is the branch.
git push origin master
10.) Downloading the latest changes made to the repository by the contributors →
This command will pull or download the newer commits and changes made in the repository to our local git repository.
From the mentioned branch to your repo.
git pull <remote-name> <branch-name>
Recommended Practice to do →
It is recommended to add the files and push a commit in this sequence making a pull request before doing a push request.
Make changes
git add <file>
git commit
git pull origin master
git push origin master
Merge Conflicts →
Merge conflicts are very common scenario that can occur while pushing a commit.
Merge conflict can occur if multiple people try to make contribution to the same file they can come up with a situation where they try to modify at same line.
Then one of them have to resolve these conflicts manually. Either by accepting his changes or the other person’s changes or even accepting both of changes.
Subscribe to my newsletter
Read articles from Aman Pratap Singh directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Aman Pratap Singh
Aman Pratap Singh
Welcome to my blog! I'm passionate about web development and have developed a strong foundation in backend technologies. My journey in tech has equipped me with the skills to handle both front-end and back-end tasks, making me a proficient full-stack developer. Currently, I'm on the lookout for exciting opportunities in full-stack development where I can apply my skills and grow further in this dynamic field. Join me as I share insights, tutorials, and experiences from my ongoing adventure in web development. LinkedIn - https://www.linkedin.com/in/aman-pratap-singh12/ Instagram - https://www.instagram.com/aman.1.2_/ Github - https://github.com/aman1-2 Twitter - https://x.com/Amanps_12