Intro to Git
Source Control
Source control solves a simple problem: how do you and your colleagues keep track of changes in your codebase?
By, sending each other updated code
By, notifying each other when code changes
So, when the size of your project increases, you may encounter certain issues :
If there are multiple projects running simultaneously on the same codebase, then tracking the changes gets complicated.
If multiple developers are working on the same files at the same time, then we need a tool to coordinate those changes.
Source control tool is a system that helps in managing such complexities.
Before Git, there were certain tools like Concurrent Versions System and SubVersioN, which had a centralized architecture.
Following a centralized structure can increase the size of the source control database, and might mess up the history, making your checkouts complicated and painful.
From a user perspective, code is in 2 stages
Local changes mean the changes that I am making
Committed essentially means "pushed to the server"
By using Git, anyone can work on the Linux kernel across the globe.
Branches
“Branching” is the core concept of Source Control.
A Branch is a set of changes made on a repository from a specific point in time.
GitHub
Most people use GitHub as a reference or upstream repository, it can also be used as a secondary or downstream repository for a workflow. It completely depends on the developer of the repo.
Let me give you an example here, you have a stream of water, if you are downstream, you receive whatever floats along the water, similarly changes made upstream, you get it automatically. In order for you to push the changes from the downstream repo to the upstream repo you you have to “push” those changes manually to the upstream.
Distributed Source Control
It is a bit complicated to understand git because of its distributed nature unlike the traditional version control systems
In a distributed source control, instead of communicating with one central source code (server).
Git operates as a set of separate repos that can pull and push changes to each other if the “owner” of the repo agrees.
This is why “pull request” exists. When you make a pull request, you are asking the owner of the other repo to take the change that you’ve made in your repos and apply it to his.
GUI Vs CLI
It is better to understand the Command line rather than the GUI. They differ and can mislead you about what is going on under the hood.
Say for example when someone asks you to work with bitbucket or any other GUI it becomes confusing. So it is better to begin by understanding the core git and then start learning GUI
Git vs other Version Control Systems
History can be changeable in your own copy of the repo.
Branching is cheap it’s very slow to branch a repository (O(n) n-number of files).In Git, it’s an O(1).
O(1) notation means that branching takes the same amount of time, regardless of the size of the repository.
Advantages would be making the branching much easier.
Branch deletion is also a common and cheap operation.
In contrast to other source control tools, changes are made across the whole project but not per file.