Basic Git & GitHub for DevOps Engineers

What is Git?

Git is a version control system (VCS) that allows developers to manage and keep track of changes made to their source code files over time. It was developed by Linus Torvalds in 2005 to help manage the development of the Linux kernel.
One of the main benefits of Git is its distributed architecture, which means that developers can work on their own local copy of a repository, and then merge their changes with the master repository when they are ready. This allows for greater collaboration and flexibility in development workflows.

What is GitHub?

GitHub is a web-based platform that is used for version control and collaborative software development. It is a code hosting platform that allows developers to store their code repositories in a central location, making it easy to collaborate with other developers on the same project.
In addition to version control, GitHub offers features such as issue tracking, project management, and code review, which make it a powerful tool for software development teams. It also allows developers to showcase their work by creating public repositories that can be viewed and cloned by anyone on the internet.

What are Version Control & Types?

Version control is a system that records changes to a file or a set of files over time, allowing you to keep track of modifications, compare different versions, and revert to an earlier state if needed.
Version control systems (VCS) typically store a complete history of changes to a project, including who made the changes, when they were made, and what was changed. This makes it easy to collaborate on a project with multiple people, as each person can work on their version of the files and then merge their changes with the changes made by others.
There are two main types of version control:

Centralized Version Control Systems (CVCS): In this type of version control, all code changes are stored in a central repository. Users check out the latest version of the code from the repository, make changes locally, and then commit their changes back to the central repository. Examples of CVCS include Subversion (SVN) and Concurrent Versions System (CVS).
Distributed Version Control Systems (DVCS): In this type of version control, each user has a local repository that contains a complete copy of the code and its entire history. Users can commit changes to their local repository and then push their changes to a central repository, which can then be pulled by other users. Examples of DVCS include Git and Mercurial.

Why do we use distributed version control over centralized version control?

Offline Work: One of the most significant advantages of DVCS is the ability to work offline. DVCS allows developers to work on their local copies of the repository without needing a connection to the central server. Developers can commit changes to their local repository and then push those changes to the central server when they regain internet connectivity.
Branching and Merging: DVCS makes branching and merging much easier than CVCS. Each developer can have their own local branch, which they can work on and merge with the main branch when they're ready. This allows for the parallel development of different features and the ability to experiment without interfering with the main codebase.
Flexibility: DVCS gives developers more flexibility to work in different ways. With CVCS, developers must follow a strict workflow and rely on a central server to manage changes. With DVCS, developers can work in a way that best suits their needs and collaborate with others when necessary.
Better Collaboration: DVCS encourages better collaboration among team members. With CVCS, developers need to lock files before editing them, which can cause delays and conflicts. With DVCS, multiple developers can work on the same file simultaneously, and the system will merge changes automatically.
Security: With DVCS, every developer has a complete copy of the repository, which makes it easier to recover from data loss. In contrast, with CVCS, a central server is the single point of failure, and if it goes down, developers can lose access to their codebase.

Installation of Git

To install git in your local system we can get the git from:

Git Download
To install on Debian/Ubuntu system

For the latest stable version for your release of Debian/Ubuntu
```
  sudo apt-get install git
```
For Ubuntu, this PPA provides the latest stable upstream Git version
```
  add-apt-repository ppa:git-core/ppa# apt update; apt install git
```
To check the version of git
```
  git --version
```

For configuring Username & Email

  git config --global user.name <name>

  git config --global user.email <Email_id>

For checking configuration details
```
  git config --list
```
For getting the git log
```
  git log
```

Git Staging Area

Configuring Git in the local system

Creating a new repository on GitHub
Initialized the folder into git using the command
```
 git init
```
Clone the repository into your local machine
```
 git clone <github_repo_url>
```

Adding a file into the directory to check the status, and adding the file using git

 # Checking the status
 git status

 #Untracking from working dir to Stagging area, we add file into git
 git add <file_name>

Committing the file, so that it moved from Stagging to Git Repository
```
 git commit -m <"Comment">
 # Here m stands for message
```
To show remote origin URL
```
 git remote -v
```
** If no branch or URL is present in the directory, we can add a remote URL using git remote.
```
  git remote add origin <complete/url/path>
```
We can push the code into the main branch using the authentication username & password
```
 git push -u origin main
```
Or else we can do a code push by creating an "Access token" in GitHub

** Path will be: Setting / Developer Settings / Personal access token / Token(Classic)

** Make sure to copy the token & kept it in a safe place.

To push code we can use this token as access to GitHub
```
 git remote set-url origin https://<Personal_access_token>@github.com/<complete/repo/path>

 # <Personal_access_token> paste the access token that was generated before

 git push -u origin main
```
Finally, you can see the code changes in GitHub.