What is Git?

Git is an open-source tool that developers install locally. It is a version control system that allows developers to track changes in their code. It was created by Linus Torvalds in 2005 and maintained by Linux.

Git*: Git is a* software*,* command-line tool, installed locally*on the system,first released in2005and maintained by*linux*.*

What is GitHub?

GitHub is a platform or a cloud-based service that allows us to host our Git repositories. Just like Git, it is a distributed version control system that allows you to store data, track it, and collaborate on software projects.GitHub was launched in 2008 and maintained by Microsoft.

GitHub*: GitHub is a* service,graphical user interface*,* hosted*on theweb, launchedin*2008*. and maintained by* Microsoft*.*

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

Version control is a system that tracks changes to a file or set of files over time so that you can recall specific versions later. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.

There are two main types of version control systems: centralized version control systems and distributed version control systems.

1. A centralized version control system (CVCS) uses a central server to store all the versions of a project’s files. Developers “check out” files from the central server, make changes, and then “check-in” the updated files. Examples of CVCS include Subversion and Perforce.

2. A distributed version control system (DVCS) allows developers to “clone” an entire repository, including the entire version history of the project. This means that they have a complete local copy of the repository, including all branches and past versions. Developers can work independently and then later merge their changes back into the main repository. Examples of DVCS include GitHub, Mercurial, and Darcs.

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

1. Better collaboration: In a DVCS, every developer has a full copy of the repository, including the entire history of all changes. This makes it easier for developers to work together, as they don’t have to constantly communicate with a central server to commit their changes or to see the changes made by others.

2. Improved speed: Because developers have a local copy of the repository, they can commit their changes and perform other version control actions faster, as they don’t have to communicate with a central server.

3. Greater flexibility: With a DVCS, developers can work offline and commit their changes later when they do have an internet connection. They can also choose to share their changes with only a subset of the team, rather than pushing all of their changes to a central server.

4. Enhanced security: In a DVCS, the repository history is stored on multiple servers and computers, which makes it more resistant to data loss. If the central server in a CVCS goes down or the repository becomes corrupted, it can be difficult to recover the lost data.

Overall, the decentralized nature of a DVCS allows for greater collaboration, flexibility, and security, making it a popular choice for many teams.

What is the difference Between Main Branch and Master Branch?

There is no particular difference between the two. Main or Master is the default branch when you create a repository. In GitHub when you create a branch by default it’s set to main but you also can change it to master. Mainly GitHub changed the name from master to main as it sounds like a master-slave concept. Easy to remember as Git > Local > Master & GitHub > GUI > Main.

Explain the difference between Git and GitHub.

Git is a version control system that allows developers to track changes in their code. GitHub is a cloud-based hosting service that allows developers to manage Git repositories.

What is the difference between local & remote repositories?

The main difference is that a local repository is accessible only on your local machine, while a remote repository can be accessed by multiple users and can be used for collaboration.

In Git, a local repository is a copy of the repository that is stored on your local machine (You can access & perform actions using Git Bash installed on your local machine), while a remote repository is a copy of the repository that is stored on a remote server, such as GitHub or GitLab.

GIT Hands-on

Set your user name and email address, which will be associated with your commits.

Here you have to put the Username and password of your GitHub account

git config --global user.name "username"
git config --global user.email "username@gmail.com"

git config --global --edit    // using nano editor set username and email

Verify your configuration info

git config --list

How to connect local to remote?

Create a Repository on GitHub

1. Click on the new repository option

2. Now give a name of your repository as per your choice and a description.

3. Choose the Visibility to public /private as per your requirement.

4. Before hitting the create button you can include a README file

5. Click on the Create button and a new repository will be created.’

Access Repository from Local Machine

1. To initialize a local repo in the machine create a folder and go to that folder (say /GIT_REPO). Open the Git bash terminal and write the command git init. Here .git hidden folder will be created.

git init #make GIT_REPO folder as git repository

2. Create/Add the files to your new local repository. This stages them for the first commit.

touch file1 #create a file 
git add file1 && git commit -m "added new file" #perform git add & commit

3. Add the URL for the remote repository where your local repository will be pushed.

git remote add origin <URL_OF_GitHub_REPO.git>

4. Enter your username and Personal access token to push your codes to the central repo (GitHub)

git pull           # always pull before push
git branch -M main
git branch

git push origin main     #  here you can use master or main

git push -f origin main   # forcefully push

Using a Personal access token make a origin and push code on GitHub

git remote -v           # show present url of github push/fetch
git remote set-url --add origin https://<token_id><githun_url>
git remote -v          # show new git hub url for push

git remote set-url --delete origin <old_url>// delete the old url
git remote -v
git push origin main   #push your code on github

make git token URL and push code on GitHub

git push https://<token_id><githun_url>

Git merge

git init
echo "this is line 1 of file1" > file1
git add file1 
git commit -m "file1-v1"
git checkout -b feature1
echo "this is line1 of feature1" > feature1
git add feature1 
git commit -m "fea1-v1"
git log
git checkout master
ls                   // feature1 file not show in master branch
git merge feature1   // feature1 file merge in master branch

git branch -d feature1  // delete branch

difference between git merge and git rebase?

git merge: creates a new merge commit that combines the changes from both branches.

• Preserves the history in chronological order

• Protects branches

git rebase: creates a new set of commits applied on top of the target branch.

• Converts complex history into a single format

• Simplifies DevOps work by reducing multiple comments to a single comment.

Git create/resolve conflict

git init
echo "file1 is updated 1st time" > file1 
git commit -am "v1"
git branch 
git checkout -b feature1 
echo "file1 is updated 2nd times" > file1 
git commit -am "v2"
git checkout master 
git merge feature1

we’ve set up a merge conflict. Both branches have changes on the same line in the same file but with different content.

vim file1 
 <<<<<<< HEAD
file1 is updated 1st time    // version of the current branch (master)
=======
file1 is updated 2nd times     // version from the feature1 branch
>>>>>>> feature1

The content between <<<<<<< HEAD and ======= is the version of the current branch (master), and the content between ======= and >>>>>>> is the version from the feature1 branch.

Resolve the conflict: Decide which version to keep, or merge the changes manually. For instance, you can edit the file

vim file1
file1 is updated 1st and 2nd times both
git commit -am "v3"
git status

Git Revert & Reset

Git Revert: it is used to create a new commit that undo the changes made in a previous commit. This is different from, which erases commits from the commit history. git revert is considered a safer option for undoing changes because it doesn't alter the existing commit history; instead, it adds a new commit that undoes the changes.

cat file  // in this file 4 line and commit but we delete last line
line 1         ---> v1 (commit)
line 2         ---> v2 (commit)
line 3         ---> v3 (commit)
line error     ---> v4 (commit)

v1 -- v2-- v3-- v4(HEAD)     // commit 

git revert <commit_id(v4)>

git log --oneline
v1 -- v2-- v3 -- v4 -- v5(HEAD)  Revert "v4"   // commit

cat file 

line 1
line 2
line 3

Remember that git revert is useful for undoing changes in a collaborative environment where you want to preserve the commit history and avoid rewriting the Git history.

Git Reset: Remove Commit History

git reset command is used to reset the current HEAD to a specified state. It's used to undo changes, unstage files, or move the branch pointer to a different commit. There are three primary options for the git reset command: --soft, --mixed (default), and--hard.

1. --soft: keeps the changes made in the commit but moves them to the staging area. It does not modify the working directory. This is useful if you want to recommit the changes with some modifications. git reset --soft <commit>

git reset --soft <commit>  // commit_id -> delete and file -->stages area

// if we want to file in local repo. then --> commit this file
// if we want changes in the working directory
git restore --staged <file>  // unstage area 
git restore <file>   // unchanged the file (add code is previous)

2. --mixed (default): It resets the HEAD to the specified commit and unstages the changes. The changes, however, are kept in the working directory. This allows you to make further modifications and choose whether to commit or discard them. git reset --mixed <commit>

git reset --mixed <commit>  //commit_id -> delete and file -->unstages area

// if we want to file in  local repo. then --> add and commit this file
// if we want changes in the working directory
git restore --staged <file>  // unstage file 
git restore <file>

3. --hard: It resets the HEAD to the specified commit and discards the changes in the working directory, and stages area. git reset --hard <commit>

git reset --hard <commit>   // commit_id -> delete and file -> changed

Git stash:-

git has an area called the stash where you can temporarily store a snapshot of your changes without committing them to the repository. It's separate from the working directory, the staging area, or the repository.

This functionality is useful when you've made changes to a branch that you aren't ready to commit, but you need to switch to another branch.