Introduction of GIT

Introduction Of GIT

Full course for free : https://www.udemy.com/introduction-of-git/?couponCode=GITFORFREE

If free Coupon expired,take course at just 10$:
https://www.udemy.com/introduction-of-git/?couponCode=GITAT10

Start with all basics of GIT,Understand what are nodes and what are commits.
Understand why dvcs was required.

Start with Git basic commands like git add, git commit, git log etc.



Understand working of Git Checkout

How to ignore changes and skip it from staging area:

How to see changes of a particular commit with the help of Git Show:

Full course for free : https://www.udemy.com/introduction-of-git/?couponCode=GITFORFREE

If free Coupon expired,take course at just 10$:
https://www.udemy.com/introduction-of-git/?couponCode=GITAT10

Version Control System

Suppose two or more developers are working simultaneously on a shared file, keeping track of changes and not over riding each other’s changes is a difficult task always. Version control systems are there to help you to work easily in a team and maintain history of changes also easily.

There was a time when no VCS even existed. Developers mutually decided to work on different files so that changes might not be lost by other’s save. Here developers were habituated to take regular backup also manually.

Then they started locking a file they were working on, once lock is released on a particular file other developer can access it and put lock on that file to access. In order to work on a particular file which locked by other developer, One has to wait for other to release the lock.

Then CVCS came into market and allowed users to work simultaneously on files. Centralized version control system used a central server that kept changes trace and all new code. In case of CVCS, you have to merge before commit. For example there is a shared file. Two developers working on same file so both have copied the file into local system at the starting of day. Now, one developer has done changes and put on server. Then other developer has also done changes and tries to commit. But he will be blocked. Because original file was modified by other. So other developer need to take the file again and merge changes with new file and put the merged file back to server.

Then innovation came that is “commit before merge”. In the late 90s DVCS came into market. Distributed version control system has lots of advantages. Developer can code even after they are disconnected from central server. Simply Write some code and commit. Here, Branches creation also easy. Directed Acyclic Graph would be really helpful to understand DVCS.

Directed Acyclic Graph:

This is not very new, you might have already studied.

It’s a graph which have nodes and edges (Lines).And we need to use directed graph that means edges are directed (they are having arrows for direction).Look at below image. Its a directed acyclic graph with 3 node and 2 edges connecting to nodes. Node 3 is child of node 2 and node 2 is child of node 1.If you want to add one more arrow from node 3 to node 1 that is also fine. But as its directed graph, you can not go in reverse direction. From node 3 to node 2 is possible same way node 3 to node 1 also possible but node 2 to node 3 not possible because of direction.

Now, here is how DVCS relates to Directed acyclic graph:

·        All commits can be considered as nodes.

·        Each and every node will have detail about parent node.

·        Apart from parent node details, All Nodes will have details of Changes made in a particular commit. So it means what changes in code you did in this particular commit that was not there in last commit that details will be traced.

·        All nodes will be identified uniquely with a Hash value. Hash values are calculated According to the details of Parent node and changes in this commit. It generally uses SHA-1 Algorithm.

·        So if you make even a single change and commit, it’s going to create a new node and new hash value. In diagram we have simple numbers like 1 2 3 but in real time hash values are longer.

Workflow for DVCS

Now, for better understanding lets discuss few workflows.

Imagine there is a server which is having 3 commits (nodes).

You are a developer and you want to want in this project. So you take all existing work from server to your local system. That is also known as cloning. So now your local system will also have same 3 commits and same existing code.

Now you stared your work and at the end of day you finished with some amazing code. So you save and commit the code. As soon as you commit it will create a new node, which is node 4.it will be child of node 3 and will have details of what changes you have done.

Server is still having 3 nodes only. So when you push your changes to server it will check for nodes which are not already there. That is node 4 which can be easily identified with unique hash value. So changes along with details of node 4 will be pushed and server and your system will be synchronized properly.

It was pretty good scenario where you easily merged your code with existing code on server. Suppose that’s note the case. Some other developer also working with you.

At the staring you both cloned from server your system, his system and server all will have same 3 nodes.

Now he has done some changes, committed changes and pushed to server.He left office and you are still working :(

After some time, you have also completed your work and committed

In this scenario when you try to push changes to server, you will have difficulty. Your last commit node 4 is child of node 3. While on server last node is 5.so 4 cannot be pushed after 5 because it maintains parent node details also.

So solution is that you need to merge your code with new node 5 and then only you can push the changes. So first you need to fetch new changes on your system.

Now your system is having two end nodes, so it will be confusing for server when you create build. Whether to build according to node 4 or node 5.We need changes of both so we need to merge.

When you merge, it will create a new node that is node 6 which will have 4 and 5 as parent node.

If changes in 4 and 5 are not in conflict, merge would happen automatically  but if there are conflict in changes, you need to decide how to merge.

So once you have merged, you need to push changes to server. So after that server will have changes of both developers and any work will not be lost.

In case of CVCS,we would do changes on exiting node only that is node 4 , but in the case of DVCS, we will create a new node that is node 6.So that and changes are not lost and will be kept in history for future reference.

After Version control system and workflows let’s talk about GIT

GIT is an Open source version control System. This keeps track of changes done in code.

With the help of GIT you can easily and very efficiently collaborate with team and don’t mess up the code. GIT keeps track of changes only.

Take one photograph of your code, after some take another photograph and compares both. Suppose your code is having 100 lines of code at a time, And after some there few more lines  are added and now there are 125 lines of code. It will not store your code but it will keep trace of change only. That is 25 new lines added. But remember it’s not backup system its version control system.

There is a word in GIT Terminology: Repository. It’s the place where you store your code. For example your project folder in your system or it can be repository on GitHub.

In your repository any type of code file can be there, Say foo.java. Now, whenever you create a new file in repository by default it will not be traced. You need to add to Staging area in order to trace changes. So all your files that you want to trace, will be added to staging area then only changes will be noticed. When you do a commit, only changes (update or new file) that are present in staging are they will be commited,other changes will not be commited.Once a file is traced, It can have two states : modified and unmodified. If you have done any change since last commit, it means file is modified. Otherwise it’s not modified. In summary, all files in repository will have three state: untracked, tracked and not modified, tracked and modified. When you commit, only modified traced changes will be committed.