GIT and Version Control - A beginners guide
- Amit Dhanik

- Sep 3, 2022
- 7 min read
Updated: Sep 26, 2022
What is Version control?
A version control, in simple terms, is used to manage source code(which creates our software). Version control, as the name suggests, means controlling the version. While writing source code for software, there are going to be continuous improvements and bug fixes in our software, hence we will be having multiple versions of our software. Multiple version of software means we will have multiple versions of our source code as well. Version Control helps us with the managing of different versions of our source code.
Why is it important?
Suppose, you work for a large organization, where multiple teams are working on the same project. Generally these days, all the teams are following the AGILE Methodology. The team member work in smaller sprints, writing a piece of code, testing it, deploying it, and delivering it to the customer. This is carried out again and again until the application is fully developed. While working in sprints, always a small piece of the application is developed. These smaller snippets of codes are deployed in regular succession with feedback. Let's say the first piece of code we wrote was V1. This piece of code, in the next sprint, is again modified with some extra features, and bug fixes from the previous version and hence we have a newer version V2. Following the same, we have V3, V4, V5, V6, and V7. To keep track of all the modifications and changes done from beginning to end, we have version control. Now suppose the latest version of our application V7 fails and crashes on the customer end. What should we do? We will roll back to the previous version. If we hadn't had version control, it would have led to a big downtime. Hence the need for version control.
With version control, everyone is able to have access to the latest version of code, and any modifications in the code can easily be tracked.
GIT
GIT is a distributed version control system. It is used to locally track all the changes that have been made to the source code of the software in your project/folder and also help with push and pull changes from remote repositories like GitHub.

cc: Great Learning
GitHub, Bitbucket, and GitLab - These are a few of the services that allow you to host your project on a remote repo and have additional features to help in SDLC and CI/CD. Eg - Managing, Sharing, wiki, Bug Tracking, and CI/CD all these services are provided by Gitlab/GitHub.
Lifecycle of code within GIT
Working directory - This is the directory where the user stores all of his codes.
Initialization - Initializing a local directory means that the directory is now considered a local repository, which can be pushed to the cloud. Here GIT keeps track of all the files that are staged and unstaged.
Staging Area- Changes made to the coding file compared to the previous version are marked by GIT in the staging area. Here only GIT looks for all the changes that have been made.
Local storage - Once the work on the code is done, and the files are staged, it's time to commit the files. We save the files when do commit to our code.
GitHub(GITDirectory) - After the file has been committed, the last step is to push it to GitHub. Now the code is pushed from local storage to cloud storage.

cc: Great Learning
Let's put into practice what we have learned above !!
Open your GIT Bash terminal. We will be creating a project directory in which we will be working. Command used is mkdir project.
Note - If you have not downloaded GIT, just type GIT download for windows or Mac-OS, and you will be ready to go!!

Before we move further ahead, give your username and email on the initial install to GIT.
The commands used are -
git config --global user.name "Your Name" - sets up the name of the user
git config --global user.email "yourname@somemail.eu" - sets up the mail of the user git config --list - lists all the git configurations

Next, we will initialize our directory. This is informing GIT to keep track of all the files that are created in this folder.
Command - git init

Let's create a file and see how git keeps track of files. We can see the status of the file using git status. Git status tells us whether files are staged or not in our local repository. For now, first.py is unstaged as shown in dark red color. No commits yet as well.

To stage the file, we have two commands - git add . The dot stages all the files in the current folder(project).
But if you only want to stage a specific file, I am going to use git add <file-name>

If we do git status now, we can see that our file is staged(in green color).
COMMIT
To commit the changes that have been made to our first.py file, we will make use of the git commit -m " This is a commit for python file" command. This will commit our file to our local repository.


If we do git status now, we can see nothing new to commit now on our local repository.

PUSH
Now we have to push this to our GitHub. Log in to your GitHub account and create a new Repository.


Copy the URL of your GitHub repository.

To push an existing local repository from the command line to GitHub, the command used is -
git remote add origin https://github.com/Adhanik/pythonfirst.gitWe will add this repo(https://github.com/Adhanik/pythonfirst.git) as an origin location. After this has been added successfully, we can push it using git push origin master
Note - git push for the first time will need authorization. Put in the password of your GitHub account and allow permission.

If you now login into your GitHub account, and check your repo, you can see the same file that was there in your local repository, it has been uploaded to GitHub successfully.

If you make any other changes to your code and do a commit, you can see it in the commit history on GitHub. Below is eg of how I made some changes to my python file, and then did the commit.

If I now see my GitHub repo, I can see that now we have 2 commits.

GIT PULL
GIT Pull command is used to Pull content from a remote repository to a local repository.

cc: Simplilearn
GIT PULL is a combination of two commands - GIT Fetch and GIT Merge.
GIT Fetch is used to download contents from a remote repository to the local repo.
The GIT Merge command combines multiple sequences of commits into a single branch.
We will pull an existing repository on a new folder(initialized with GIT), make some changes to it, and then add the files to the staging area, commit, and push them back to a new repository that we will create.
What happens if you do a GIT PULL before commit?
from stack overflow -
The command git pull is effectively an alias for git fetch and git merge. Whoever was instructing you probably did a poor job, because git pull right before you commit will indeed wipe out all your work. What they should have told you to do instead was commit, then git pull, or if you don't want a merge history use git pull --rebase instead. After that, you can git push.
All your uncommitted work will be overwritten by a merge initiated by git pull.
Should you Pull before a Push?
If you are working for an organization, where your teammates along with you have been pushing to the remote repository, it is always advised to do a git pull before Push. Doing so will ensure that your local copy is in sync with the remote repository. If you push before syncing up, you could end up with multiple heads or merge conflicts when you push.
Reminder - Make sure every time before you start working on a new commit you git pull to get any commits anyone else has been working on.
GIT Lifecycle

cc - GeeksforGeeks
GIT Clone
This is used to copy an existing repo onto your local host machine. Git Clone copies the entire git repo.

GIT Checkout
This is used to select a specific version of branches created by Git branch.

Learnings (This is in progress)
Note - If you have multiple files and you make use of the command git add . , all the files get staged and ready to commit. Now you cannot commit any single file out of these. If you have to make a commit, say to one file or two files out of five, only add those two files to the staging area. Don't add all files to the staging area, as commit will then commit all of the files. You don't have an option to specify files while committing. Below is an example where I had five versions of a file, and though I only wanted two, I added all five to the staging area. Then I had to commit all of them. Hence add only those files to the staging area which you want to commit.

If I log in to my GitHub account, I can see all the files.

UNDO
Now if you want to undo these changes, we have to start all over again. Below you can see how to unstage and start all over again.
If you accidentally commit the wrong files, use - git reset --soft HEAD~1
You can unstage all the files and start over again using the command - git reset

Now we have our one file staged. We can commit it and push it to our GitHub repo. But if I do push now, I get the following error.

If I delete this file from GitHub and commit changes, and then again try to do a push.

I deleted the guessV1.py also. You can check the situation by gitk --all

We add both the files, stage them, commit and then push. We get the same error again.

Now, in end, I have deleted my whole repository from GitHub. One thing, I missed was that I did not initialize this directory with git init. I will commit all the files again after creating a new Repo.
So, this was the beginner's guide to getting started with GIT and why you need to understand Version control. I hope this helps you with the fundamentals of getting started with GIT. Hope you enjoyed reading it!!
Read this article for Good Practices on GIT
Till then, Keep learning. Maybe we will have another blog on Advance concepts on GIT.
Stay tuned!!






Comments