Git & GitHub Basic to Adv for DevOps Engineers

Introduction

In the world of DevOps, Git and GitHub are essential tools that help developers work together and manage their code.

What is Git?🌿🐱

Definition: Git is a distributed version control system that helps developers track changes in their code, collaborate with others, and manage software development efficiently.

Key Aspects of Git:

Version Control: Tracks code changes effectively.
Branching: Isolates different feature developments.
Collaboration: Enables smooth teamwork and contributions.
Remote repositories facilitate easy code sharing and backups.
Pull Requests: Allow code review before merging.

Fundamental Concepts in Git:

Commits: Snapshots of code changes.
Repositories: Collection of code and history.
Working Directory: Where developers make changes.
Staging Area: Prepares changes for commits.
Push and Pull: Sending and fetching changes.
Merge and Conflict Resolution: Combining changes and handling conflicts.
Branches: Separate development paths for features.
Forks: Personal copies for independent development.

What is GitHub?

Definition: GitHub is a web-based hosting service that uses Git for version control. It provides a platform for developers to store, manage, and collaborate on code repositories.

Key Aspects:

Code Hosting: Store code online.
Collaboration: Work together on projects.
Community and Open Source: Global developer community.
Issue Tracking: Manage project issues.
CI/CD Integration: Automate testing and deployment.

What is Version Control? How many types of version controls we have?

Version control is a system that helps you manage changes to your files and code over time. It keeps track of different versions of your work, allowing you to go back to previous states, collaborate with others, and avoid conflicts. It's like having a time machine for your project, so you can undo mistakes and track progress.

There are mainly two types of version control:

Centralized Version Control (CVC): In CVC, there is a central server that stores all the project files and their versions. When team members want to work on the project, they check out a copy from the central server, make changes, and then commit those changes back to the server. Examples of CVC systems include Apache Subversion (SVN) and Perforce.
Distributed Version Control (DVC): DVC, on the other hand, doesn't rely on a central server. Each team member has a complete copy of the entire project, including its history. They can work independently and synchronize their changes directly with each other. Examples of DVC systems include Git and Mercurial.

CVCS vs DVCS

Sr. No.	Key	Centralized Version Control	Distributed Version Control
1	Working	In CVS, a client need to get local copy of source from server, do the changes and commit those changes to centeral source on server.	In DVS, each client can have a local branch as well and have a complete history on it. Client need to push the changes to branch which will then be pushed to server repository.
2	Learning Curve	CVS systems are easy to learn and set up.	DVS systems are difficult for beginners. Multiple commands needs to be remembered.
3	Branches	Working on branches in difficult in CVS. Developer often faces merge conflicts.	Working on branches in easier in DVS. Developer faces lesser conflicts.
4	Offline Access	CVS system do not provide offline access.	DVD systems are workable offline as a client copies the entire repository on their local machine.
5	Speed	CVS is slower as every command need to communicate with server.	DVS is faster as mostly user deals with local copy without hitting server everytime.
6	Backup	If CVS Server is down, developers cannot work.	If DVS server is down, developer can work using their local copies.

Setting Up Your Local Repository:

Install Git on your computer.
Click here for download git in your system
Configure your name and email in Git.
- username: git config --global user.name "Your Name"
- Email: git config --global user.email "your.email@example.com"
Open the terminal or command prompt.
Navigate to the directory where you want to create your repository.
Initialize a new Git repository using git init.
Add your files to the staging area with git add.
Make your first commit using git commit.
Create a remote repository on GitHub (optional).
Link your local repository to the remote one using git remote add origin.
Push your code to the remote repository with git push origin.

Your local repository is now set up and ready to track changes and collaborate with others using Git.

Git Commands

git init: Initializes a new Git repository in the current directory.
git add <file_name>: Stages (adds) a file to be included in the next commit. Use git add . to stage all changes.
git status: Shows the current status of your working directory, including modified files and staged changes.
git log: Displays the commit history, showing the commit IDs, authors, dates, and commit messages.
git diff: Compare changes between files, showing line-by-line differences between versions.
git commit -m "Commit message": Creates a new commit with the changes that you have staged. The commit message should briefly describe the changes made.
git branch: Lists all branches in the repository. Use git branch <branch_name> to create a new branch.
git checkout <branch_name>: Switches to a different branch.
git merge <branch_name>: Merges changes from a different branch into the current branch.
git clone <repository_url>: Clones (downloads) a remote repository to your local machine.
git pull: Fetches and merges changes from the remote repository into your local branch.
git push: Pushes your local commits to the remote repository.
git stash: Temporarily saves changes for later use without committing.
git cherry-pick: Applies a specific commit from one branch to another.