Git

Introduction to Git

• Git provides a flexible environment to work collaboratively and securely

• Has a Version Control System (VCS) to allow multiple users:

  • to modify the same file,

  • to record and track changes,

  • to revert to earlier versions

  • to compare multiple versions of a file

  • to manage conflicts and merge files

• Allows users to create and manage remote repositories (repos)

• Facilitates branching and merging of files with the main repo

• Allows each user to have a copy of the file locally thus keeping the file in the server secure

Limitations fo Existing VCS and What is Git

• Limitations of Existing VCS

  • Existing VCS have a centralized architecture

  • Changes cannot be done offline

    • User retrieves the file, makes changes, and commits

    • Next user can only pull the data when online

  • All changes are made in the central server

    • Connecting to the central server is necessary to make edits

    • Leaves no room for error

• What is Git?

  • A VCS-distributed revision control system aimed at:

    • speed

    • data integrity

    • security

Git Configuration Levels

• Three levels of configuration

  • System level: --system

    • applicable to all users who use the system where git is installed

    • command: git config --system

    • saves to: /etc/gitconfig

  • Global level: --global

    • applicable to user settings for all repos

    • command: git config --global

    • saves to: ~/.gitconfig

  • Local level: --local

    • applicable to the current repo only

    • command: git config --local or git config

    • saves to: .git/config

The following settings need to be configured for all commits:

• user.name

• user.email

Creating a Git Repository

Steps to Create a Git Repository

1. Create an empty directory and change directory into created directory mkdir <directory-name> && cd <directory-name>

2. Convert the directory into repository git init

3. ALT: git init <directory-name> combines steps 1 & 2

4. Run git status git status

Git Workflow

Git maintains three snapshots of a file maintained in separate directories:

1. Working Directory

   • refers to the directory where git was initialized by git init command

   • when a file is entered/created in this directory, it is untracked

   • Staging Area

     • area where files are moved to when tracked

     • command: git add

2. .git/index file

   • storage of staged files

3. Local Repository

   • file moved to this area when it is committed

   • command: git commit

Managing and Viewing Changes

To modify a file in git --> Update --> Add --> Commit

To view the changes in a file:

• command: git log

  • lists all the commands enacted on the file in reverse chronological order by:

    • Commit ID

    • Author

    • Date

    • Commit Message

Tracking File Changes

Ability to identify changes between the different versions of the same file, spread across various repos

command: git diff

• view the changes of a modified file in it's working directory and it's staged state

command: git diff --staged

• view the changes of the staged file and it's last commit of the same file

Once in the local repo, the latest commit of a file is pointed to by a pointer called HEAD

• each of the previous commits are also pointed to by a pointer called HEADX where X is an incremented number beginning with 1

Reverting to Earlier Commits

Steps to Revert to Earlier Commits in Git

1. List details of the commit associated with a file command: git log

2. Stage the file command: git checkout <version-code> or git checkout HEAD~1 <filename>

3. Share the command to unstage the file command: git status

4. Remove the file from the staging area and bring it back to the working directory command: git reset

Deleting Files in Git

Deleting Files from Staging Area and Working Directory

• Delete the file from staging area and working directory command: git rm <filename>

  • To verify file has been removed from the staging area command: git ls-files --stage

• Delete a file only from the staging area command: git rm --cached <filename>

Ignoring File in Git

How to ignore Files in Git

• Add the file to a .gitignore file

  • stores file name

  • stores file pattern

• The file name and file pattern can be overridden using the -f flag

Renaming Files in Git

Steps to Rename Files in Git

1. command: git mv <filename> <new-filename>

2. command: git add .

3. command: git commit -m "renamed <filename> => <new-filename>"

4. command: git status

Introduction to GitHub

Creating a Repository in GitHub

There are two protocols you can use to create a repo

1. HTTPS

2. SSH

Pulling Commits from GitHub

• to push changes from local (main) to remote (origin) command: git push origin main

Sometimes, files on origin (remote) may change without having come from main (local) so, you will need to pull from origin to main.

• command: git pull origin main

Managing Multiple Commits in Git

Scenario: same file has been changed in the local and remote repos

How does Git manage these changes?

• when you attempt to push your change from the local, Git identifies the file on the remote has changed as well

• Git will reject the push action and suggest you do a pull changes from remote

• once the changes are pulled, the remote commit comes to the local and git will merge those changes in with the local changes

• this forces an additional commit at the local which then can be pushed to the remote later

Merging File Changes in Git

What are these file changes?

Scenario: User A wants to modify a particular line of a file in the local repo, User B wants to modify the same line of the same file in the remote repo

• User A attempts to pull the change, git shows a conflict and suggests to resolve the conflict manually

• To resolve conflicts manually command: git merge

Branching in Git

Branching is very important in Git. It helps:

1. reducing errors

2. protecting the content in the main repo

Branches are separate workspaces created when you need to:

• experiment or test something without impacting the main code base

• manage releases

• create hotfixes to the production branches

Merging Branches in Git

Fast Forward and Recursive Merge

Git employs a merge algorithm based on the context it has to merge to

Fast Forward Merge—Employed when you merge into a branch, the latest commit of which is your parent

• When one branch has been created from a parent branch (in this case the main) and no more commits have been done to the parent branch

• Git moves the main label to the latest commit brought from the branch

• Used when a Hotfix is needed over the production code base to fix bugs

Recursive Merge—Employed when dealing with multiple merge bases

• When one branch has been created from a parent branch (in this case the main) and there have been more commits done to the parent branch since the creation of child branch

• Git creates another commit on the parent branch and brings all the changes into this additional commit

Resolving Merge Conflicts in Git

Scenario:

What causes conflicts?

Two users change the same line in a file. One user wants to delete the line while the other just wants to modify the line. Git does not have any idea how to merge these changes together, so it shows the conflict in the file.

How does Git resolve these conflicts?

Normally, if Git can resolve them it will do so automatically. However, in this scenario, it has no clue so it flags the file and requests a manual resolve.

Stashing in Git

Rebasing in Git

Cloning in Git