Section 1: Introduction

What is Git?

Git is a form of distributed VCS for tracking changes to any set of files, using simple text formats and content-tracking. Git was founded by Linus Torvalds in 2005, and as of now, it's the most used version control system in the world. It has its most prevalent use in software development to manage source code, although it can be applied to track changes in any set of files.

Key features of Git include the following: distributed architecture, whereby every user gets a comprehensive copy of not only the repository but its history; and branching and merging-where you can create a separate branch for new features or experiments from the mainline code with ease. Later, you might merge this into the main branch after review and testing. Commit History: Git allows tracking changes made to the codebase, with record of who made it and when. This is quite useful for tracking and reverting back in case the need arises.

"Git" and "git"

The term Git-with a capital "G"-generally refers to the software tool itself, the system that developers use to manage their code and track changes.

Where the term git, lowercased, would usually refer to the command-line interface or CLI commands that would be used to interact with the Git system. Examples of common git commands would include git init, git clone, and git commit.

This may seem like a subtle difference, but it is useful in both documentation and conversation sometimes to make the distinction between the tool as a concept-what you're doing (Git)-and the specific commands or interactions with that tool (git).

Different Git Interfaces

Though Git initially had been developed as a command-line utility, today there are plenty of ways to interact with Git. Here they are:

Command-Line Interface (CLI):
- Pros: Serves full control over the functionality of Git, lightweight, able to be used almost in every development environment.
- Cons: Has a steeper learning curve, especially for those just starting out.
Graphical User Interfaces (GUIs):

Examples: GitHub Desktop, GitKraken, Sourcetree, and TortoiseGit.
- Pros: Easy to use, good visualization of branches, commits, and merges. Thus, easier for beginners.
- Cons: Lack some of the more advanced capabilities of the CLI.

IDE Plugins:
- Examples: VS Code's Git Integration, IntelliJ IDEA, Eclipse's EGit.

Pros: Subtly merges Git into the workflow of development, allowing developers to work with Git directly from their coding environment.
- Cons: Usually less feature-rich compared to a standalone client for Git.

Web Interfaces:
- Examples: GitHub, GitLab, Bitbucket.
- Pros: Makes collaboration, code review, and project management pretty easy with features like pull requests, issues, and wikis.

Cons: Hosted repositories, mainly, and may not always expose all the features of Git directly.

Git vs. GitHub vs. GitLab

Although Git, GitHub, and GitLab are names one often hears in conjunction with each other, they are actually used for different purposes:

Git:
- What it is: A version control system that monitors your file changes and allows you to create collaborative projects. It is software you install on your computer.
Purpose: Manage local and remote repositories, track changes, branch and merge code, maintain project history.
- Example Use: Git is used by developers for maintaining the source code of a project.
GitHub:
- What it is: A web-based hosting platform for Git repositories that provides additional features related to issue tracking, code review, and project collaboration.
Purpose: Simplifies the collaboration on Git repositories, especially for open-source projects. Besides that, it hosts CI/CD pipelines, project management, and more.
- Example Use: A team of developers can work on a project hosted on GitHub, create pull requests to review the code and bugs in the code.
GitLab: What it is: GitLab is similar to GitHub; it also offers a web-based user interface for the hosted Git repositories. As an extended version, it provides many more built-in features about DevOps such as CI/CD, project management, and monitoring. It enables the developer to look after the entire DevOps lifecycle in one platform starting from planning to deployment and monitoring. Example Use: It can be used for private repository management, setting up testing and deployment pipelines automatically, and project management tasks within a company.

Key Differences Between GitHub and GitLab: CI/CD Integration: By default, GitLab has already integrated highly customizable CI/CD pipelines, while GitHub's proper CI/CD will require integrating third-party tools like GitHub Actions.

Self-Hosting: GitLab has a cloud-hosted and a self-hosted version, while GitHub is mostly cloud-based. However, GitHub Enterprise allows for limited self-hosting.
Project Management: Both offer project management, but GitLab's tools are more deeply integrated into its Continuous Integration/Continuous Deployment Pipelines.

In a nutshell, Git is the underlying technology allowing for version control, while GitHub and GitLab provide features that expand on collaboration, project management, and DevOps; this forms the software layer above Git.

Section 2: Git Quick Dive and Authentication

Installing Git on Linux

Installing Git on a Linux system is straightforward. Here's how to do it on the most common distributions:

Debian/Ubuntu:
```
 sudo apt update
 sudo apt install git
```
Fedora:
```
 sudo dnf install git
```
CentOS/RHEL:
```
 sudo yum install git
```
Arch Linux:
```
 sudo pacman -S git
```

Once installed, verify the installation by running:

git --version

This should display the installed version of Git.

Installing Git on Windows

Installing Git on Windows involves downloading the Git installer and following the setup instructions:

Download the Git installer from the official Git website: Git for Windows.
Run the installer. During installation, you can choose:
- Git Bash: A command-line interface for Git with Unix-style commands.
- Git GUI: A graphical user interface for Git.
- Path environment: Option to use Git from the command prompt or third-party software.
Follow the setup steps, selecting options like the default editor, and adjusting your PATH environment if needed.
After installation, open Git Bash and verify the installation with:
```
 git --version
```

Choosing Our Default Git Editor

When configuring Git for the first time, you’ll need to choose a text editor for Git to use when opening files (e.g., commit messages):

Set the default editor during Git installation (on Windows) or afterward with:
```
 git config --global core.editor "editor_name"
```
Replace editor_name with your preferred editor (e.g., vim, nano, code for VSCode).

To verify or change the default editor:

 git config --global --get core.editor

 git config --global core.editor "new_editor"

Creating Our GitHub Account

Creating a GitHub account is simple:

Visit GitHub and click on "Sign up".
Fill in the required details: username, email, and password.
Follow the instructions sent to your email to verify the account.
Once verified, you can start creating repositories, contributing to projects, and more.

Cloning Our GitHub Repository

Cloning a GitHub repository allows you to copy the repository to your local machine:

Copy the repository URL from GitHub (HTTPS or SSH).
Open a terminal (Git Bash on Windows) and run:
```
 git clone <repository_url>
```
Replace <repository_url> with the actual URL.
This will create a directory with the repository's content on your machine.

git add & git commit

These commands are fundamental to managing changes in Git:

git add: Adds changes in the working directory to the staging area, preparing them for a commit.
```
 git add <file_name>
 git add .
```
git add . stages all changed files.
git commit: Records the staged changes in the repository’s history. This requires a commit message describing the changes.
```
 git commit -m "Your commit message"
```
This command creates a new snapshot of the project's history.

git status

This command shows the current status of the working directory and staging area, including:

Modified files
Staged files ready for commit
Untracked files
Any files with merge conflicts

Usage:

git status

.gitignore

The .gitignore file tells Git which files or directories to ignore, meaning they won’t be tracked or committed:

Create a .gitignore file in the root directory of your project.
Add file patterns for files you want to ignore, such as:
```
 *.log
 node_modules/
 *.tmp
```

To apply the .gitignore rules, use:

 git rm -r --cached .
 git add .
 git commit -m "Update .gitignore"

git push and git pull

These commands sync your local repository with a remote repository:

git push: Uploads local commits to the remote repository.
```
 git push origin <branch_name>
```
Replace <branch_name> with your branch name, usually main or master.
git pull: Downloads changes from the remote repository and merges them into your local branch.
```
 git pull origin <branch_name>
```
This command integrates remote changes into your local branch.

git log

git log shows the commit history of the current branch, including commit hashes, authors, dates, and messages.

Usage:

git log

To see a more concise version of the log:

git log --oneline

This shows one commit per line.

Push Local Repository to GitHub

To push an existing local repository to GitHub:

Create a new repository on GitHub without initializing it with a README, license, or .gitignore.
Add the remote repository URL to your local repository:
```
 git remote add origin <repository_url>
```
Push your local commits to the remote repository:
```
 git push -u origin main
```

Branches

Branches are used to work on different features or fixes separately:

Creating a new branch:

 git checkout -b <branch_name>

 git branch <branch_name>

Switching between branches:
```
 git checkout <branch_name>
```
Merging branches: Merge changes from one branch into another (usually into main):
```
 git checkout main
 git merge <branch_name>
```
Deleting a branch: Once merged, you can delete a branch:
```
 git branch -d <branch_name>
```

Authentication Overview

Git offers various methods to authenticate when interacting with remote repositories, such as using HTTPS, SSH keys, or credentials stored in a keychain or credential manager. These methods ensure secure access to your repositories, whether on GitHub, GitLab, or other platforms.

Authentication: Windows Credential Manager

Windows Credential Manager can store your Git credentials so you don’t need to enter them every time:

Set up Git to use the credential manager:

 git config --global credential.helper wincred

The next time you clone a repository, Git will ask for your username and password and store them securely.

Authentication: macOS Keychain

macOS users can store Git credentials in the macOS Keychain:

Install the credential helper (if not already installed):
```
 git credential-osxkeychain
```

Configure Git to use the keychain:

 git config --global credential.helper osxkeychain

Git will now store your credentials in the macOS Keychain.

Authentication: SSH Instead of HTTPS

Using SSH keys for authentication is more secure and convenient than using HTTPS:

Generate an SSH key:

 ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Add the SSH key to the SSH agent:

 eval "$(ssh-agent -s)"
 ssh-add ~/.ssh/id_rsa

Add the SSH key to your GitHub account:
- Copy the SSH key:
```
  cat ~/.ssh/id_rsa.pub
```
- Add it to your GitHub account under Settings > SSH and GPG keys.

Set the remote repository to use SSH:

 git remote set-url origin git@github.com:username/repository.git

Authentication: Changing Local Repo to SSH

If your local repository is currently using HTTPS, you can change it to SSH:

Verify the current remote URL:
```
 git remote -v
```

Change to SSH:

 git remote set-url origin git@github.com:username/repository.git

Verify the change:
```
 git remote -v
```

IDE & Editors: Overview

Integrated Development Environments (IDEs) and text editors offer tools and plugins to make working with Git easier. Some popular ones include:

Emacs
Git Gui
GitHub Desktop
IntelliJ
TortoiseGit
VsCode GitLens

IDE & Editors: Emacs

Emacs is a customizable text editor that can be configured to work with Git.

Install Magit:
- Magit is an Emacs package that provides an interface for Git.

    bashCopy codeM-x package-install RET magit RET

Using Magit:
- Inside Emacs, type M-x magit-status to open the Magit interface.

IDE & Editors: Git Gui

Git Gui is a graphical interface for Git that is included with Git installations.

Launch Git Gui:
- Open your terminal and type:
```
  bashCopy codegit gui
```
Features:
- Git Gui allows you to perform commits, create branches, and push changes through a user-friendly interface.

IDE & Editors: GitHub Desktop

GitHub Desktop is a GUI client for Git that integrates with GitHub, simplifying version control operations.

Download and Install:
- Get GitHub Desktop from https://desktop.github.com/.
Sign in to GitHub:
- After installation, sign in to your GitHub account.
Clone Repositories:
- Use the interface to clone repositories, manage branches, and commit changes.

IDE & Editors: IntelliJ

IntelliJ IDEA, a popular IDE, has built-in Git support, making it easy to manage Git repositories.

Version Control Tool Window:
- Open the Version Control tool window to view and manage your Git repositories.
Git Integration:
- IntelliJ supports all standard Git operations, such as commit, push, pull, branch management, and more.

IDE & Editors: TortoiseGit

TortoiseGit is a Windows Shell Interface to Git, providing a simple and easy way to interact with Git repositories directly from Windows Explorer.

Download and Install:
- Get TortoiseGit from https://tortoisegit.org/.
Right-Click Git Commands:
- TortoiseGit adds Git commands to your right-click menu in Windows Explorer, allowing you to perform Git operations with ease.

IDE & Editors: VsCode GitLens

GitLens is a popular extension for Visual Studio Code that enhances Git capabilities within the editor.

Install GitLens:
- In VSCode, go to the Extensions view and search for "GitLens". Install the extension.
Features:
- GitLens provides inline Git blame information, history exploration, and more, directly within VSCode.

Git with Synchronization and Backups

Synchronization and backups are essential for maintaining the integrity and availability of your Git repositories.

Automated Backups:
- Use tools like GitLab, Bitbucket, or GitHub to host remote repositories, which act as backups for your local repositories.
Syncing Repositories:
- Ensure your local and remote repositories are in sync using git push and git pull commands.
Local Backups:
- Regularly back up your .git directory to an external storage device or cloud storage to safeguard your repository's history.
Disaster Recovery:
- In case of data loss, you can restore your project by cloning the remote repository or using a local backup.

This section covers the essentials of using Git, setting up authentication, and integrating with various IDEs and editors to streamline your version control process.

Section 3: Git Advanced Deep Dive

Git Commits: Deep Dive

Git commits are snapshots of your project at a specific point in time. Each commit is uniquely identified by a SHA-1 hash, which is a 40-character string. A commit in Git stores:

Commit metadata: Information about the commit, including the author, date, and commit message.
Tree object: A reference to the tree object that represents the state of the project’s files at the time of the commit.
Parent commits: Reference(s) to the previous commit(s), forming a chain of commits (commit history).

Git Commits: Internals

Internally, a Git commit is structured as a series of objects:

Blob Object: Stores the contents of individual files.
Tree Object: Represents a directory, storing references to blob objects (files) and other tree objects (subdirectories).
Commit Object: Points to a tree object and has metadata like the commit message, author, and parent commit(s).

These objects are stored in the .git/objects directory, and Git uses the tree and commit objects to track changes over time.

Git Commits: Move and Delete

Moving Files:
```
 git mv <source> <destination>
```
This command moves a file from the source path to the destination path and stages the change for commit.
Deleting Files:
```
 git rm <file_name>
```
This removes the file from the working directory and stages the deletion for commit.

Staging Changes Manually: You can move or delete files using standard filesystem commands and then stage them:

 mv <source> <destination>
 git add <destination>
 git rm <file_name>
 git commit -m "Moved and deleted files"

Git Commits Undo: `git reset` and `git restore`

git reset: This command alters the state of your branch by moving the HEAD pointer to a different commit, effectively "undoing" commits.
- Soft reset: Keeps changes in the working directory and staging area.
```
  git reset --soft <commit>
```
- Mixed reset (default): Keeps changes in the working directory but un-stages them.
```
  git reset --mixed <commit>
```
- Hard reset: Discards all changes, both in the working directory and staging area.
```
  git reset --hard <commit>
```
git restore: This command is used to restore files in the working directory to a previous state without altering commit history.
- Restore a file to the last commit:
```
  git restore <file_name>
```
- Unstage a file:
```
  git restore --staged <file_name>
```

Git Commits Undo: `git show` and `git diff`

git show: This command shows the details of a commit, including the changes made.
- Show details of the latest commit:
```
  git show
```
- Show details of a specific commit:
```
  git show <commit_hash>
```
git diff: Compares changes between commits, branches, or the working directory and the staging area.
- Compare working directory and staging area:
```
  git diff
```
- Compare staging area and the last commit:
```
  git diff --staged
```
- Compare two commits:
```
  git diff <commit1> <commit2>
```

Git Commits Undo: `git revert`

git revert is used to create a new commit that undoes the changes made by a previous commit without altering the commit history.

Revert a specific commit:
```
  git revert <commit_hash>
```
This creates a new commit that reverses the changes made by the specified commit.

Git Commits Undo: Changing Commit Message

You can change the commit message of the most recent commit or an older one:

Changing the most recent commit message:
```
 git commit --amend -m "New commit message"
```
This updates the commit message for the most recent commit.
Changing an older commit message: Use interactive rebase:
```
 git rebase -i HEAD~n
```
Replace n with the number of commits to go back. Mark the commit(s) you want to edit with reword and provide the new message.

Branches

Creating a New Branch:
```
 git branch <branch_name>
```
This creates a new branch without switching to it.

Switching Branches:

 git checkout <branch_name>

 git switch <branch_name>

Switch to an existing branch.

Creating and Switching to a New Branch:

 git checkout -b <branch_name>

 git switch -c <branch_name>

Listing Branches:
```
 git branch
```
Shows all local branches, with the current branch highlighted.
Deleting Branches:
- Delete a local branch:
```
  git branch -d <branch_name>
```
- Force delete (if the branch is not fully merged):
```
  git branch -D <branch_name>
```
Renaming a Branch:
- Rename the current branch:
```
  git branch -m <new_name>
```

Merging

Fast-forward Merge: This type of merge occurs when there are no new commits on the destination branch since it branched from the source branch. Git simply moves the branch pointer forward.
```
 git merge <branch_name>
```
Three-way Merge: This type of merge occurs when both branches have new commits. Git uses a common ancestor commit to create a new merge commit that combines changes.
```
 git merge <branch_name>
```
Squash Merge: Combines all commits from the source branch into a single commit on the target branch.
```
 git merge --squash <branch_name>
```
Merge Conflicts: Occur when Git cannot automatically resolve differences between branches. Conflicts need to be resolved manually before completing the merge.

Git Stash-Area (Stashing)

Git stash temporarily shelves changes in your working directory, allowing you to switch branches or perform other tasks without committing the changes.

Stashing Changes:
```
 git stash
```
This stashes all changes (tracked and untracked files) in a stash stack.
Applying Stashed Changes:
- Apply and remove the stash:
```
  git stash pop
```
- Apply without removing the stash:
```
  git stash apply
```
Listing Stashes:
```
 git stash list
```
Dropping a Stash:
```
 git stash drop <stash@{n}>
```
Replace <stash@{n}> with the stash reference.
Stashing Untracked Files:
```
 git stash -u
```

Remote Repositories

Adding a Remote Repository:
```
 git remote add <remote_name> <url>
```
Listing Remote Repositories:
```
 git remote -v
```
Fetching Changes from Remote:
```
 git fetch <remote_name>
```
This downloads changes from the remote without merging them.
Pulling Changes from Remote:
```
 git pull <remote_name> <branch_name>
```
This fetches changes and merges them into your current branch.
Pushing Changes to Remote:
```
 git push <remote_name> <branch_name>
```
Removing a Remote:
```
 git remote remove <remote_name>
```

Merge Conflict (VS Code)

Using VS Code to Resolve Conflicts:
- When a merge conflict occurs, VS Code highlights the conflicting areas in the editor.
- You can choose between "Accept Current Change," "Accept Incoming Change," "Accept Both Changes," or manually edit the conflict.
- After resolving, stage the file and commit.
Viewing Merge Conflicts:
- Open the Git panel in VS Code to see a list of conflicting files.
- Click on a file to view and resolve the conflicts.

Merge Conflict (Merge Tools: MELD)

Setting Up MELD as a Merge Tool:

 git config --global merge.tool meld
 git config --global mergetool.meld.path /path/to/meld

Using MELD to Resolve Conflicts:
- Start the merge tool with:
```
  git mergetool
```
- MELD opens with three panes: the left and right show the conflicting changes, and the middle shows the merge result.
- Manually resolve the conflicts and save the file.
Completing the Merge:
- After resolving conflicts with MELD, stage the changes and commit them.

Merge Conflict: Content Merge Conflict and Internals

Content Merge Conflict:
- Occurs when two branches modify the same part of a file differently, leading to a conflict that Git cannot automatically resolve.
- Requires manual intervention to merge the changes.
Internals:
- During a conflict, Git creates conflict markers in the file:
```
  <<<<<<< HEAD
  // Changes from the current branch
  =======
  // Changes from the merging branch
  >>>>>>> branch_name
```
- Resolve by choosing which changes to keep or by merging them manually.

Rebasing

What is Rebasing?
- Rebasing re-applies commits from one branch onto another, creating a linear history.
Basic Rebase:
```
 git rebase <branch_name>
```
This re-applies the current branch's commits on top of <branch_name>.
Interactive Rebase:
```
 git rebase -i <commit_hash>
```
Allows you to edit, squash, or reorder commits.
Abort a Rebase:
```
 git rebase --abort
```
Continue a Rebase:
```
 git rebase --continue
```
Used after resolving conflicts during a rebase.
Rebase vs. Merge:
- Merge: Creates a merge commit, preserving branch history.
- Rebase: Rewrites commit history, creating a linear sequence of commits.

Referencing Commits

Commit Hashes:
- Each commit is referenced by a SHA-1 hash (e.g., e1e1d3f).
Branches and HEAD:
- HEAD points to the current commit.
- Branches are pointers to specific commits (e.g., master, feature-branch).
Tags:
- Tags are references to specific commits, often used for marking release points.
Relative References:
- HEAD~1 refers to the commit before HEAD.
- HEAD^ refers to the first parent of HEAD (useful in merge commits with multiple parents).
Reflog:
- Tracks changes to the HEAD pointer, allowing recovery from "lost" commits.

    git reflog

This section covers the advanced aspects of working with Git, including deep dives into commits, branches, merges, rebasing, tagging, and handling conflicts. Let me know if you need further details or examples for any specific part!

Section 4: Information Analysis in Git-Repository

Search Commits

1. git log

Purpose:
git log is one of the most frequently used commands in Git, allowing you to explore the commit history of your repository. This command displays a detailed list of all the commits in the repository's history, starting from the most recent to the oldest.
Basic Usage:
```
  git log
```
- This command shows the commit history with details such as the commit hash, author name, date, and commit message.
Options and Examples:
- View commit history for a specific file:
```
  git log <file_path>
```
  This option shows only the commits that have affected the specified file.
- Limit the number of commits shown:
```
  git log -n <number>
```
  This shows the most recent <number> commits.
- One-line summary of each commit:
```
  git log --oneline
```
  Each commit is displayed in a single line, showing the commit hash and the commit message.
- Show differences introduced in each commit:
```
  git log -p
```
  This adds the differences between the commits (a patch) to the log.
- Filter commits by author:
```
  git log --author=<author_name>
```
  Displays only the commits made by the specified author.
Advanced Use Cases:
- Graphical representation of the commit history:
```
  git log --graph --oneline --all --decorate
```
  This creates a visually structured view of the commit history, showing branches, merges, and tags.

2. git reflog

Purpose:
git reflog is a powerful Git command used to track every change made in the repository's reference (ref) logs. Unlike git log, which shows the commit history, git reflog keeps a history of all the changes to the tip of branches, such as checkouts, commits, rebases, merges, and resets.
Basic Usage:
```
  git reflog
```
- This command displays a list of all changes made to the current branch, including those not yet reflected in the git log.
Options and Examples:
- View reflog for a specific branch:
```
  git reflog <branch_name>
```
  This displays the reflog for a specified branch.
- Limit the number of entries shown:
```
  git reflog -n <number>
```
  Limits the output to the specified number of entries.
- Restore a previous state using reflog:
```
  git reset --hard <reflog_entry>
```
  If you made a mistake, you can use the reflog entry to reset your repository to a previous state.
Why It's Important:
git reflog is particularly useful when you need to recover from mistakes. For example, if you accidentally reset a branch or performed a hard reset, git reflog allows you to find the commit you lost and recover it.

3. git tag

Purpose:
git tag is used to create a reference (tag) that points to a specific point in the Git repository's history. Typically, tags are used to mark release points (e.g., v1.0, v2.0) in your project's history.
Basic Usage:
```
  git tag <tag_name>
```
- This command creates a simple tag at the current commit.
Types of Tags:
- Annotated Tags:
```
  git tag -a <tag_name> -m "Tag message"
```
  Annotated tags store extra information such as the tagger's name, email, and date. They are generally recommended for public releases.
- Lightweight Tags:
```
  git tag <tag_name>
```
  Lightweight tags are just pointers to a specific commit and do not store any additional information.
Options and Examples:
- View all tags in the repository:
```
  git tag
```
  This lists all the tags created in the repository.
- View details of a specific tag:
```
  git show <tag_name>
```
  Displays the details of a specific tag, including the commit it points to and any annotated information.
- Tagging a specific commit:
```
  git tag <tag_name> <commit_hash>
```
  You can tag any commit, not just the current one.
Use Cases:
- Tags are most commonly used for marking release points, such as v1.0 or v2.1.3. This makes it easier to refer to specific versions of your codebase.

4. git shortlog

Purpose:
git shortlog is a convenient tool to summarize the commit history by grouping commits by author. It’s especially useful for generating reports and summaries of who contributed what to a project.
Basic Usage:
```
  git shortlog
```
- This command provides a summary of commits grouped by author, showing the commit count and a list of commit messages for each author.
Options and Examples:
- Group by committers instead of authors:
```
  git shortlog --committer
```
  This groups the summary by committer rather than by author.
- Show number of commits per author:
```
  git shortlog -sn
```
  This option shows the number of commits made by each author in a simplified format.
- Restrict output to a specific branch or range of commits:
```
  git shortlog <branch_name> --since="last month"
```
  This command restricts the summary to a specific branch or time frame.
Use Cases:
- Contribution analysis: git shortlog is an excellent tool for project maintainers to analyze contribution levels. For instance, it can help in writing release notes, identifying key contributors, and understanding the distribution of work in a project.

Search Files

1. git show

Purpose:
git show is a versatile command used to view various types of objects in Git, most commonly to view the details of a specific commit. It can display the commit details, including the author, date, commit message, and the changes introduced in that commit.
Basic Usage:
```
  git show <commit_hash>
```
- This shows the details of a specific commit, including the changes made to files.
Options and Examples:
- View a specific file's changes in a commit:
```
  git show <commit_hash>:<file_path>
```
  Displays the content of a specific file as it was in the specified commit.
- View changes made in a specific tag:
```
  git show <tag_name>
```
  Shows the details and changes associated with a specific tag.
- View previous versions of a file:
```
  git show HEAD~1:<file_path>
```
  This shows the version of the file from one commit ago.
Use Cases:
- git show is often used to inspect individual commits or specific changes within commits, providing a detailed view of the project's history.

2. git diff

Purpose:
git diff is an essential tool for viewing the differences between various states of the repository, such as between commits, branches, or the working directory and the last commit. It helps you see what has changed before committing those changes.
Basic Usage:
```
  git diff
```
- Shows changes between the working directory and the index (staged files).
Options and Examples:
- Compare changes between the working directory and the last commit:
```
  git diff HEAD
```
  Shows changes between the working directory and the last commit.
- Compare changes between two specific commits:
```
  git diff <commit_hash1> <commit_hash2>
```
  Shows changes between two specific commits.
- Compare changes between two branches:
```
  git diff <branch1> <branch2>
```
  This displays the differences between two branches.
- Ignore whitespace differences:
```
  git diff --ignore-space-at-eol
```
  Ignores whitespace at the end of lines when showing differences.
Use Cases:
- Reviewing changes: git diff is crucial for code review before committing changes. It allows you to see exactly what has been added, removed, or modified, making it easier to spot errors or unnecessary changes.

3. git grep

Purpose:
git grep is a powerful search tool that allows you to search through the contents of files in your Git repository for a specific pattern. It's particularly useful for locating specific pieces of code, text, or patterns across multiple files in your project.
Basic Usage:
```
  git grep "pattern"
```
- Searches for the specified "pattern" in all files in

the repository.

Options and Examples:
- Search in a specific branch:
```
  git grep "pattern" <branch_name>
```
  Searches for the pattern within the specified branch.
- Search in a specific commit:
```
  git grep "pattern" <commit_hash>
```
  This command searches for the pattern within the specified commit.
- Count the number of matches:
```
  git grep -c "pattern"
```
  Shows the count of matches per file.
- Show line numbers of matches:
```
  git grep -n "pattern"
```
  Displays the line numbers where the pattern is found.
Use Cases:
- Code navigation: git grep is incredibly useful for quickly locating specific functions, variables, or text within a large codebase, saving time and effort during development or debugging.

4. git blame

Purpose:
git blame is used to determine the origin of each line in a file. It shows which commit, and thus which author, last modified each line of a file. This is particularly useful for identifying when and why a specific change was made.
Basic Usage:
```
  git blame <file_path>
```
- This shows the commit hash, author, and timestamp for each line in the file.
Options and Examples:
- View blame for a specific commit:
```
  git blame <commit_hash> <file_path>
```
  Shows the blame for a file as it was in the specified commit.
- Ignore certain revisions (e.g., bulk reformatting):
```
  git blame --ignore-revs-file <file_path> <file_name>
```
  This allows you to ignore specific revisions that might have changed many lines without altering the actual code (like reformatting).
- Show the commit message along with the blame:
```
  git blame -C -L 1,10 <file_name>
```
  This command also includes the commit message for the blamed lines.
Use Cases:
- Tracking code ownership: git blame is essential for understanding the history behind specific lines of code, identifying who introduced a bug, or understanding the rationale behind a change.

Search Errors

1. git bisect

Purpose:
git bisect is a tool used to identify the specific commit that introduced a bug. It performs a binary search through your commit history to quickly isolate the commit that caused the issue, making it an invaluable tool for debugging.
Basic Usage:
```
  git bisect start
  git bisect bad
  git bisect good <commit_hash>
```
- These commands start the bisect process, marking the current commit as "bad" (i.e., it contains the bug), and a known good commit where the bug was not present.
Workflow:
- Mark a known good commit:
```
  git bisect good <commit_hash>
```
  This marks the last known good commit in your repository.
- Mark the current commit as bad:
```
  git bisect bad
```
  This marks the current commit as containing the bug.
- Continue the bisecting process: Git will check out a commit in the middle of the range. Test it, and if it’s bad, run git bisect bad; if it’s good, run git bisect good. This process continues until Git isolates the specific commit that introduced the bug.
- End the bisect process:
```
  git bisect reset
```
  This command ends the bisecting process and returns your repository to its original state.
Use Cases:
- Debugging: git bisect is extremely effective for pinpointing the exact commit where a bug was introduced, especially in large projects with extensive commit histories.

Visualization and Statistics

1. git shortlog

Purpose:
As mentioned earlier, git shortlog is used to summarize the commit history by author, providing a quick overview of contributions to the repository. It is also useful in generating release notes and contributor statistics.
Basic Usage:
```
  git shortlog
```
- Summarizes the commit history by author.
Use Cases:
- Generating release notes: The grouped commit messages can be used to create detailed release notes, highlighting the contributions of each developer.

2. gitstats

Purpose:
gitstats is a third-party tool that generates detailed statistics and visualizations for a Git repository. It provides insights into the repository's history, including commit frequency, activity per author, and more.
Installation:
- Python:
  gitstats is written in Python, so it requires Python to be installed on your machine. You can install it using pip:
```
  pip install gitstats
```
Basic Usage:
```
  gitstats <repository_path> <output_directory>
```
- This command generates a detailed HTML report with various statistics and visualizations for the repository.
Examples of Statistics Provided:
- Commits per day/week/month: Shows the frequency of commits over time.
- Commits per author: Provides a breakdown of contributions by each author.
- Lines of code: Tracks how the size of the codebase has changed over time.
- File statistics: Shows which files are most frequently modified.
Use Cases:
- Project analysis: gitstats is a powerful tool for project maintainers and managers to analyze the development process, identify bottlenecks, and understand contributor dynamics.

3. gitk

Purpose:
gitk is a graphical history viewer for Git repositories. It provides a visual representation of the commit history, making it easier to understand the project's development over time, including branch merges and the flow of commits.
Basic Usage:
```
  gitk
```
- Opens the gitk GUI to explore the repository's commit history.
Key Features:
- Commit graph visualization: Shows a graphical representation of branches and merges.
- Commit details: Clicking on a commit shows detailed information, including changes made, files affected, and the commit message.
- Filtering and searching: Allows filtering commits by message, author, or file changes.
Use Cases:
- Visualizing complex histories: gitk is particularly useful for visualizing complex histories involving multiple branches and merges, making it easier to track down issues or understand the flow of development.

4. GitKraken and Git Flow Chart

Purpose:
GitKraken is a popular third-party Git client that provides an intuitive GUI for managing Git repositories. It is particularly well-suited for teams and complex workflows, offering advanced features like Git Flow support, which is a branching model designed to facilitate the development process.
GitKraken Features:
- Graphical commit history: Provides a clear, interactive view of the repository's history, with support for drag-and-drop reordering of commits.
- Branch management: Simplifies the process of creating, merging, and deleting branches.
- Git Flow support: Integrates Git Flow, a workflow model that defines specific branches for different stages of development (e.g., feature, release, hotfix).
- Issue tracking integration: Connects with popular issue trackers like Jira, GitHub Issues, and GitLab to link commits to issues.
Use Cases:
- Team collaboration: GitKraken is an excellent tool for teams, providing features that make collaboration smoother and more efficient.
- Managing complex workflows: The Git Flow integration helps teams follow best practices in managing their development process, making it easier to coordinate feature development, releases, and hotfixes.
- Visualization: GitKraken’s visual tools help in understanding and managing complex histories, similar to gitk but with more advanced features and integrations.

Section 5: GitHub

Pull Requests

Purpose:
A pull request (PR) is a feature that allows developers to inform others about changes they've pushed to a GitHub repository. It’s a request to merge changes from one branch into another (typically from a feature branch into the main branch). Pull requests are the central point for discussing proposed changes, reviewing code, and tracking the status of a contribution.
Basic Workflow:
1. A developer creates a new branch and makes some changes.
2. They push their changes to the repository.
3. They open a pull request, describing the changes they’ve made.
4. Reviewers can comment on the changes, request modifications, and approve the PR.
5. Once approved, the PR is merged into the main branch.

Example Workflow:

  # Step 1: Create a new branch
  git checkout -b new-feature

  # Step 2: Make some changes and commit them
  git add .
  git commit -m "Add new feature"

  # Step 3: Push the changes to GitHub
  git push origin new-feature

  # Step 4: On GitHub, create a pull request for review

Use Cases:
- Collaboration: Pull requests are essential for collaboration on large projects, as they allow multiple contributors to review code and discuss changes before merging them.
- Code Review: PRs enable thorough code reviews, where team members can suggest changes or improvements.

Organisations

GitHub provides a structure for organizing multiple repositories under one roof, which is particularly useful for businesses or open-source projects that involve many contributors and repositories. Organizations are an efficient way to manage permissions, teams, and projects.

a. Teams

Purpose:
Teams allow you to group users within an organization, making it easier to manage permissions across multiple repositories. For example, a team can be created for developers, designers, or operations, with each team having specific access rights to repositories.
Basic Workflow:
- Create a team: Organization owners can create teams from the organization settings page.
- Assign repositories: Once a team is created, repositories can be assigned to the team with specified permission levels (read, write, or admin).
- Add members: Team members can be added to the team.
Example:
1. Navigate to your organization’s page.
2. Go to Teams and click New Team.
3. Assign repositories and permissions to the team.
Use Cases:
- Permission management: Teams allow efficient permission management across many repositories, streamlining collaboration and access control.

b. Permission Levels

GitHub organizations have several permission levels to control access to repositories. These levels help ensure that users can only perform actions relevant to their role within the project.

Permission Levels:
1. Read: Users can view and clone the repository.
2. Write: Users can view, clone, and push changes to the repository.
3. Admin: Users can perform any action on the repository, including adding collaborators and deleting the repository.
4. Triage (optional): Users can manage issues and pull requests without having full write access.
5. Maintain (optional): Users can manage repository settings, but not delete the repository.
Example: Assign permissions through the repository settings by navigating to Settings > Manage Access > Invite teams or people > Select the permission level.

c. Protected Branches

Purpose:
Protected branches ensure that specific branches (like main or master) are safeguarded against direct modifications without the required approvals. This helps maintain code quality and stability by enforcing rules like requiring pull requests, approvals, or passing status checks before a branch can be merged or updated.
Rules You Can Enforce:
- Require pull request reviews before merging.
- Require status checks (like CI/CD tests) to pass before merging.
- Require signed commits.
- Restrict who can push to the branch.
Basic Workflow:
1. Go to the repository’s Settings > Branches.
2. Under Branch protection rules, click Add rule.
3. Set the rules for the branch (e.g., require pull request reviews, passing checks, etc.).
Use Cases:
- Prevent errors: Protected branches are essential for preventing accidental direct commits to critical branches like main.
- Enforce code reviews: They ensure that no code is merged without being reviewed.

d. Project Boards

Purpose:
GitHub Project Boards are used to track work at the project level. These boards allow teams to create and manage tasks as cards, similar to tools like Trello or Jira, and can help organize workflow, assign issues, and track progress in an agile way.
Types of Boards:
- Basic Kanban: Organize tasks into columns like "To do," "In progress," and "Done."
- Automated Projects: Automatically move tasks between columns based on issue or pull request status.
Basic Workflow:
1. Go to the Projects tab in a repository or organization.
2. Click Create a new project.
3. Add cards representing issues or pull requests, and move them through different columns to track progress.
Use Cases:
- Project management: Project boards help visualize and manage the tasks within a project, making it easier to track progress, assign tasks, and collaborate.

Forking

Purpose:
Forking a repository creates a copy of the original repository in your GitHub account. It allows you to freely experiment with changes without affecting the original project. You can later propose merging your changes back to the original repository via a pull request.
Basic Workflow:
1. Click the Fork button on a repository page.
2. This creates a copy of the repository in your account.
3. Make changes in your fork.
4. Submit a pull request to the original repository to propose merging your changes.

Example:

  # Clone the forked repository
  git clone https://github.com/<your_username>/<forked_repo>.git

  # Make changes and push them to your fork
  git add .
  git commit -m "Implement new feature"
  git push origin <branch_name>

  # Submit a pull request via GitHub’s web interface

Use Cases:
- Open-source contributions: Forking is commonly used in open-source development, where developers fork a project to propose changes without directly modifying the original repository.

Issues and Labels

Purpose:
Issues are a GitHub feature used to track tasks, enhancements, and bugs for a project. Labels are used to categorize issues for easier navigation and filtering. Issues and labels provide a structured way to manage and prioritize the work within a repository.
Basic Workflow for Creating an Issue:
1. Navigate to the repository’s Issues tab.
2. Click New Issue and describe the task, enhancement, or bug.
3. Optionally, assign labels, assignees, and projects to the issue.
Common Labels:
- bug: Something is not working.
- enhancement: Suggestion for a new feature.
- documentation: Related to improving or updating documentation.
Example:
1. Open the Issues tab and create a new issue.
2. Add a label like bug or enhancement.
3. Assign the issue to someone or a team for resolution.
Use Cases:
- Task tracking: Issues and labels help in tracking project progress, assigning tasks, and prioritizing work.

Markdown Syntax

Purpose:
Markdown is a lightweight markup language used for formatting text on GitHub. It’s used in README files, issues, pull requests, and GitHub Wiki pages. GitHub-flavored Markdown (GFM) extends the standard Markdown syntax with additional features like task lists, tables, and syntax highlighting.

Basic Syntax:

Headings:

  # Heading 1
  ## Heading 2
  ### Heading 3

Lists:

Unordered:
```
  - Item 1
  - Item 2
```
Ordered:
```
  1. First item
  2. Second item
```

Code blocks:
```
  ```bash
  git status
```
Links:
```
  [GitHub](https://github.com)
```
Images:
```
  ![Alt text](image_url)
```

Tables:

  | Header 1 | Header 2 |
  | -------- | -------- |
  | Row1     | Data     |

Use Cases:
- Documentation: Markdown is widely used for creating README files, documenting code, and writing issues and pull requests.

GitHub Actions

Purpose:
GitHub Actions is a CI/CD tool that allows you to automate tasks like building, testing, and deploying your code. Workflows are defined using YAML configuration files and are triggered by events like pushing code, creating pull requests, or on a schedule.
Basic Workflow:
1. Create a .github/workflows/ directory in your repository.
2. Define workflows using YAML.

Example Workflow (Simple CI for a Node.js app):

  name: CI

  on: [push, pull_request]

  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
      - uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install
      - run: npm test

Use Cases:
- Automating CI/CD: GitHub Actions are used to automate testing, building, and deployment of applications, ensuring that your code passes all tests before being deployed.

GitHub Wiki

Purpose:
GitHub provides a built-in Wiki for each repository, which allows you to create and manage project documentation easily. Wikis are useful for writing long-form content like project guides, documentation, or contributor guidelines.
Basic Workflow:
1. Navigate to the Wiki tab in your repository.
2. Create and edit pages using Markdown.
Example:
1. Go to the Wiki tab and click Create the first page.
2. Write the documentation using Markdown syntax.
3. Save the page.
Use Cases:
- Project documentation: GitHub Wikis are a great way to maintain long-form documentation for a project in a centralized location.

GitHub Pages

Purpose:
GitHub Pages allows you to host static websites directly from a GitHub repository. It’s commonly used to host project documentation, portfolios, and personal blogs.
Basic Workflow:
1. Create a repository for your site.
2. Add HTML, CSS, or Markdown files.
3. In the repository settings, enable GitHub Pages.
Example:
1. Create a index.html or README.md file in the repository.
2. Go to Settings > Pages, and select the branch to serve from.
Use Cases:
- Project websites: GitHub Pages is used for hosting simple project sites, portfolios, or even personal blogs using static site generators like Jekyll.

GitHub Security with Dependent and CodeQL

GitHub provides security tools to help identify and prevent vulnerabilities in your code. Two key security features are Dependabot and CodeQL.

a. Dependabot:

Purpose:
Dependabot automatically checks for and alerts you of security vulnerabilities in your project’s dependencies. It can also create pull requests to update those dependencies to secure versions.
Basic Workflow:
1. Enable Dependabot in your repository.
2. When a vulnerability is found, Dependabot opens a pull request to update the affected dependency.
Example:
If your repository uses outdated dependencies, Dependabot might open a PR like:
```
  Bump lodash from 4.17.15 to 4.17.19
```

b. CodeQL:

Purpose:
CodeQL is a static analysis tool that scans your codebase for vulnerabilities. It can be integrated into your CI workflow to automatically detect security issues during code reviews.
Basic Workflow:
1. Add a CodeQL workflow to your GitHub Actions configuration.

Example CodeQL Workflow:

  name: "CodeQL"
  on: [push, pull_request]

  jobs:
    analyze:
      name: Analyze
      runs-on: ubuntu-latest
      strategy:
        matrix:
          language: [ 'javascript', 'python' ]
      steps:
      - uses: actions/checkout@v2
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v1
        with:
          languages: ${{ matrix.language }}
      - run: ./build
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v1

Use Cases:
- Vulnerability detection: Dependabot and CodeQL help maintain the security of your repository by detecting vulnerable dependencies and code patterns.

Section 6 : GitLab

GitLab is a comprehensive DevOps platform that offers various tools for managing source code, projects, and CI/CD pipelines. Below is a detailed explanation of each topic related to GitLab, which will help you understand its functionalities deeply.

Creating Projects (Repositories)

A project in GitLab is equivalent to a repository, similar to GitHub. It allows you to store and manage your source code, configuration files, and other resources necessary for development.

How to Create a Project in GitLab:
1. Navigate to your GitLab dashboard.
2. Click on the "New Project" button.
3. Choose between starting a blank project, importing from an external repository, or using a template.
4. Give your project a name, set the project visibility (private, internal, or public), and configure options like repository initialization with a README.
Types of Projects:
- Personal Projects: Linked to a user’s personal GitLab account.
- Group Projects: Created within a group and shared by multiple members for collaboration.
Key Features:
- Clone Options: GitLab provides SSH and HTTPS options to clone repositories.
- Branch Management: Create and manage branches to handle features, bug fixes, and code versions.
Use Cases:
- Collaborating on code development with multiple team members.
- Managing open-source projects.

Merge Requests

A Merge Request (MR) in GitLab is the process of integrating changes from one branch into another (often from a feature branch into the main branch).

Merge Request Workflow:
1. Create Branch: Start by creating a new branch for the changes you want to implement.
2. Commit Changes: Make commits to your branch.
3. Open Merge Request: Navigate to the Merge Request tab in GitLab and create a new MR, selecting the source and target branches.
4. Review and Approve: Code is reviewed by other team members. You can leave comments and request changes.
5. Merge: Once approved, the changes are merged into the target branch.
Features of Merge Requests:
- Discussion Threads: Collaborate on code changes with team members by leaving comments on specific lines of code.
- CI/CD Integration: MRs can trigger pipelines that automatically test changes before they are merged.
- Merge Options: GitLab offers options like squash merging and rebase merging to clean up commit history.
Use Cases:
- Code reviews and collaboration in large development teams.
- Integrating feature changes while maintaining code integrity via CI/CD.

Issues & Labels

GitLab’s Issues are a way to track tasks, bugs, and feature requests within a project. Labels help categorize and prioritize these issues.

How to Create an Issue:
1. Navigate to the “Issues” tab in a GitLab project.
2. Click on “New Issue” and fill out details like the title, description, and assign it to a milestone or team member.
Labels:
- Purpose: Labels help organize issues and MRs based on categories like bug, feature, high-priority, etc.
- Creating Labels: Go to the Labels section in a project and define custom labels with colors.
Key Features:
- Assignees: Assign issues to individuals responsible for their completion.
- Milestones: Group issues into milestones to track progress across a larger initiative or feature release.
- Linked Issues: Link related issues to show dependencies or track tasks in multiple issues.
Use Cases:
- Agile workflows to track work across sprints.
- Managing bugs and feature requests in a systematic way.

Project Member Permissions

GitLab has a comprehensive permission model to control who can access what in a project.

Permission Levels:
1. Guest: Limited to reading issues and accessing public repositories.
2. Reporter: Can create issues and view code but can’t make changes to it.
3. Developer: Can push code to branches, create merge requests, and manage CI/CD pipelines.
4. Maintainer: Can merge code, manage project settings, and approve merge requests.
5. Owner: Full control over the project, including transferring ownership and managing member permissions.
Key Features:
- Group and Project Permissions: Permissions can be set both at the project level and group level, allowing flexibility in managing team access.
- Protected Branches: Restrict certain branches to prevent developers from pushing directly to them.
Use Cases:
- Secure codebases by restricting write access to certain branches.
- Delegating different roles and responsibilities to team members based on their tasks.

Groups & Permissions

Groups in GitLab are collections of users that can own projects and manage permissions for those projects.

Creating Groups:
1. Navigate to Groups on the GitLab dashboard.
2. Click on New Group and provide a name.
3. Add members with different permission levels (Owner, Maintainer, Developer, etc.).
Subgroups:
- You can also create subgroups within a group to further organize your team and projects.
Permission Inheritance:
- Members of a group can inherit permissions across all projects within that group.
Use Cases:
- Grouping all related projects under one team to streamline collaboration.
- Assigning permissions for multiple projects at once using a group-level hierarchy.

Project Boards & Milestones

Project Boards in GitLab offer a visual way to manage tasks, using a Kanban-style approach. Milestones are used to track the progress of issues and merge requests within a defined period or for a specific goal.

Creating a Project Board:
1. Navigate to the Project Boards section within your project.
2. Create a new board and define columns such as “To Do,” “In Progress,” and “Done.”
Key Features:
- Drag and Drop: Move issues across columns to indicate progress.
- Issue Filters: Use labels and milestones to filter which issues appear on the board.
- Custom Columns: You can customize board columns to fit your project’s workflow.
Milestones:
- Creating Milestones: Navigate to the Milestones tab and define a new milestone with start and end dates.
- Linking Issues and MRs: You can assign issues and merge requests to milestones for tracking larger features or releases.
Use Cases:
- Agile sprint management with visual tracking of issue progress.
- Coordinating releases by grouping related issues and MRs under one milestone.

Wiki

GitLab offers an integrated Wiki for each project, allowing you to create and store documentation directly within the project.

How to Create a Wiki:
1. Navigate to the Wiki tab in your GitLab project.
2. Create a new page by providing a title and using Markdown to format the content.
Key Features:
- Markdown Support: GitLab wikis support Markdown for easy formatting of documentation.
- Versioning: Wikis maintain a history of changes, so you can revert to previous versions.
- Sidebar Navigation: Automatically generate a sidebar for easy navigation between pages.
Use Cases:
- Documenting project features, setup guides, and user instructions.
- Storing technical documentation for developers working on a project.

Snippets

GitLab Snippets allow users to share small pieces of code across projects or with the public. Snippets are useful for sharing code examples, configurations, or scripts.

Creating a Snippet:
1. Navigate to the Snippets section within GitLab.
2. Click on New Snippet and provide a title, description, and the code snippet.
3. Choose whether to make the snippet public, internal, or private.
Key Features:
- Public vs. Private Snippets: Public snippets can be shared with anyone, while private snippets are restricted to project members.
- Multiple File Snippets: GitLab allows the creation of multi-file snippets for sharing larger code samples.
Use Cases:
- Sharing code snippets for debugging, configuration files, or example scripts.
- Creating reusable code blocks for common tasks.

CI/CD Pipeline Basics

GitLab’s CI/CD pipelines automate the process of building, testing, and deploying code. Pipelines are defined in a .gitlab-ci.yml file.

Basic Pipeline Workflow:
1. Create .gitlab-ci.yml: Define jobs (steps) that your pipeline will execute. For example, you might have build, test, and deploy jobs.
2. Push Code: When code is pushed, the pipeline is triggered automatically.
3. View Pipeline Results: Check the pipeline status and logs to ensure everything is working.
Key Features:
- Jobs and Stages: Define multiple jobs (build, test, deploy) and organize them into stages.
- Runners: GitLab uses runners to execute jobs. These can be shared or specific to your project.
- Artifacts: You can configure jobs to save build artifacts (e.g., compiled code, test reports).
Example `.gitlab-ci.yml`:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling code..."
    - make build

test-job:
  stage: test
  script:
    - echo "Running tests..."
    - make test

deploy-job:
  stage: deploy
  script:
    - echo "Deploying application..."
    - make deploy

Use Cases:
- Automating code compilation and testing for every commit.
- Setting up a complete CI/CD pipeline to deploy code to production.

GitLab Pages

GitLab Pages allows you to host static websites directly from a GitLab repository. It’s commonly used for project documentation, personal websites, or project landing pages.

How GitLab Pages Work:
1. Create a GitLab Project: Your site is hosted from the repository in the public/ directory.
2. Configure .gitlab-ci.yml: Use GitLab’s CI/CD to build your static site and deploy it to GitLab Pages.
3. GitLab Pages Domain: By default, GitLab provides a domain like your-username.gitlab.io, but you can use custom domains.
Use Cases:
- Hosting documentation sites, blogs, or static project pages.

GitLab Markdown

GitLab supports Markdown, a lightweight markup language, to format text throughout the platform, including in issues, merge requests, wikis, and snippets.

Basic Markdown Syntax:
- Headers: # for H1, ## for H2, etc.
- Bold: **text**
- Italic: *text*
- Code Blocks: code
- Links: [link text](url)
Advanced Features:
- Task Lists: Use - [ ] to create task lists in issues and MRs.
- Tables: Create tables using | to separate columns and --- to define the header.
Use Cases:
- Formatting project documentation in wikis and issues.
- Creating readable and structured comments in code reviews.

Section 7: Azure DevOps & Bitbucket

Azure DevOps Overview:

Azure DevOps is a cloud-based service for source code management (SCM), work planning, build automation, and deployment. It integrates with Git and offers features for teams to collaborate on development, automate builds and testing, and deploy code.

Azure DevOps 01: Creating a Repository, Pull Requests, and Work Items

1. Creating a Repository in Azure DevOps

A repository in Azure DevOps (also called a "repo") is where all your source code is stored. Repositories in Azure DevOps are built on Git, which means you get all of Git’s features like branching, cloning, and commit history.

Steps to Create a Repository:
1. Open your Azure DevOps portal.
2. Select a project or create a new project.
3. Go to Repos > Files.
4. If no repository exists, click Initialize Repository.
5. Choose whether to add a README file, .gitignore, or license (optional).
6. Select Create.

Key Git Commands for Repo:

Clone a Repo:

  git clone https://dev.azure.com/{organization}/{project}/_git/{repo-name}

Commit and Push Code:

  git add .
  git commit -m "Initial commit"
  git push origin master

2. Pull Requests in Azure DevOps

A pull request (PR) is a request to merge code from one branch into another (often from a feature branch into main or master).

Steps to Create a Pull Request:
1. Push your branch to the repository.
2. Navigate to Repos > Pull Requests > New Pull Request.
3. Select the source branch and the target branch.
4. Add a title and description.
5. Assign reviewers and click Create.
Key Features of Pull Requests:
- Review Comments: Team members can review code and leave comments or suggest changes.
- CI Integration: You can set policies to automatically run builds/tests when a pull request is opened.
- Merge Strategies: Choose between strategies like rebase and merge or squash merge.

3. Work Items in Azure DevOps

Work items are tasks, bugs, features, or user stories that need to be tracked as part of your development process.

Types of Work Items:
- Task: A smaller, manageable piece of work.
- Bug: An issue in the code.
- User Story: A high-level requirement typically defined in agile projects.
- Epic: A large body of work that can be divided into user stories.
Steps to Create a Work Item:
1. Navigate to Boards > Work Items.
2. Click on New Work Item and select the appropriate type (e.g., Task, Bug, User Story).
3. Fill in details like title, description, assignee, priority, and tags.
4. Save and link the work item to commits, pull requests, or branches.
Work Item Linking: Azure DevOps allows linking work items to code changes, ensuring traceability between code and requirements.

Azure DevOps 02: Creating Project Boards

Project Boards in Azure DevOps are a visual tool for tracking work. They are part of the Boards section and provide a Kanban-style board to organize work items.

Steps to Create a Project Board:
1. Navigate to Boards > Boards from your Azure DevOps project.
2. Click on New Board to create a custom board, or use the default.
3. Set up columns such as To Do, In Progress, and Done.
Customizing Boards:
- Add Columns: You can add custom columns to fit your team’s workflow.
- Swimlanes: Organize work based on priority or type (e.g., bugs vs features).
- Rules and Automation: Use automation rules to automatically move work items between columns based on certain actions (e.g., moving to "Done" when a PR is merged).
Using Filters:
- You can filter work items based on tags, assignees, priority, or type to focus on specific tasks.
Work Item Cards:
- Cards on the board represent work items, and you can customize what fields are displayed on the cards (e.g., title, tags, priority).

Azure DevOps 03: Sprints & Wiki

1. Sprints in Azure DevOps

Sprints are time-boxed iterations in Scrum, where teams work to complete a set of work items. Azure DevOps supports sprint planning, execution, and review.

Setting up Sprints:
1. Go to Boards > Sprints.
2. Define sprint lengths and set sprint goals.
3. Assign work items (such as user stories or tasks) to sprints by dragging them from the backlog.
Sprint Planning Tools:
- Capacity Planning: Azure DevOps allows you to set team members’ capacities in hours or story points to ensure the sprint workload is manageable.
- Burndown Charts: Track progress throughout the sprint to ensure tasks are being completed on time.
Sprint Review:
- At the end of the sprint, review completed work, discuss any issues, and plan for the next sprint.

2. Wiki in Azure DevOps

The Wiki in Azure DevOps allows you to create and store documentation for your project directly within the platform.

Steps to Create a Wiki:
1. Navigate to Wiki from the project’s sidebar.
2. Click Create Wiki.
3. Start by creating a homepage for your wiki and use Markdown to format content.
Key Features of Wiki:
- Markdown Support: Format text with headings, lists, code blocks, tables, and links.
- Version Control: Wiki pages are version-controlled, so you can track changes and revert if needed.
- Link to Work Items: You can link to work items, pull requests, or other pages from within the Wiki.
Use Cases:
- Creating technical documentation, setup instructions, or project guidelines.
- Storing and managing internal knowledge for development teams.

Bitbucket Overview:

Bitbucket is another popular source code management tool, primarily designed for Git-based projects. It integrates with Jira and offers pipelines for CI/CD.

Bitbucket 01: Creating a Repository, Inviting Members, and Pull Requests

1. Creating a Repository in Bitbucket

A repository in Bitbucket is where you store your code and its version history. Bitbucket allows creating both Git and Mercurial repositories.

Steps to Create a Repository:
1. Open your Bitbucket dashboard.
2. Click Create Repository.
3. Choose a Project, provide a repository name, and select Git as the repository type.
4. Set the repository visibility (public or private) and click Create.

Key Git Commands for Repo:

Clone a Repo:

  git clone https://bitbucket.org/{username}/{repo-name}.git

Push Changes:

  git add .
  git commit -m "Initial commit"
  git push origin main

2. Inviting Members to Bitbucket Repository

Bitbucket allows you to collaborate by inviting members to repositories.

Steps to Invite Members:
1. Open the repository you want to share.
2. Navigate to Repository Settings > User and Group Access.
3. Enter the email or Bitbucket username of the user you want to invite.
4. Set their role (Admin, Write, or Read access) and send the invitation.

3. Pull Requests in Bitbucket

A pull request in Bitbucket is a way to review code before it is merged into the main branch.

Steps to Create a Pull Request:
1. Push your feature branch to the repository.
2. Navigate to Pull Requests > Create Pull Request.
3. Select the source and destination branches.
4. Add a title, description, and assign reviewers.
5. Click Create to submit the PR for review.
Key Features of Pull Requests in Bitbucket:
- In-line Code Comments: Reviewers can leave comments on specific lines of code for discussion.
- Merge Strategies: Choose from merge, squash, or rebase strategies when merging PRs.

Bitbucket 02: Permission & Pipelines

1. Permissions in Bitbucket

Bitbucket provides granular control over repository access through permission settings.

Permission Levels:
- Admin: Full control over the repository, including settings and user management.
- Write: Can push code and create pull requests but not manage repository settings.
- Read: Can clone and view the repository but cannot push changes.
Steps to Manage Permissions:
1. Go to Repository Settings > User and Group Access.
2. Add users or groups and set their permission levels.

2. Bitbucket Pipelines

Bitbucket Pipelines is a CI/CD service built into Bitbucket that allows you to automatically build, test, and deploy your code.

Key Features of Pipelines:
- Pipeline Configuration: Pipelines are configured using a .bitbucket-pipelines.yml file, which defines steps to execute in response to events like commits or pull requests.
- Pipeline Stages: Define multiple stages, such as build, test, and deploy, to automate your workflow.

Example .bitbucket-pipelines.yml:

  pipelines:
    default:
      - step:
          name: Build
          script:
            - echo "Building the project..."
            - npm install
            - npm run build
      - step:
          name: Test
          script:
            - echo "Running tests..."
            - npm test

Use Cases:
- Automating unit tests on every commit.
- Deploying code to production automatically after passing tests.

Section 8: Workflows

In software development, workflows dictate how teams manage their codebase, branches, and collaboration. A workflow in Git represents how developers interact with the repository and collaborate on projects using different strategies for version control.

Basic Instructions for Teams

When working in teams, version control practices become essential for maintaining a clean and efficient codebase. Teams use Git workflows to ensure that development is structured, that conflicts are minimized, and that features are delivered without breaking the project.

Key Practices for Teams:

Clear Branching Strategy:
- Decide on how branches are named and managed (e.g., main, dev, feature branches).
Consistent Commit Messages:
- Standardize commit messages for clarity and traceability. Use a format like:
```
  git commit -m "TYPE: Short description"
```
- Types could include fix, feature, refactor, docs, etc.
Code Reviews and Pull Requests:
- Every new feature or bug fix should be reviewed before merging into the main codebase via pull requests.
- This allows multiple team members to check for errors, offer suggestions, and maintain code quality.
Continuous Integration (CI):
- Set up CI pipelines that automatically test and build code when new changes are pushed. This reduces the chances of merging broken code into the main branch.
Conflict Resolution:
- Team members need to communicate regularly to avoid working on the same part of the code simultaneously, which could lead to merge conflicts.

Solo Development

Solo development often has simpler workflows since the developer is the only contributor. However, even solo developers should maintain a solid Git workflow to manage code versions, track changes, and avoid regressions.

Best Practices for Solo Development:

Use Feature Branches:
- Even when working alone, maintaining separate branches for features (feature/feature-name) helps in keeping the main branch stable.
- Example of creating a feature branch:
```
  git checkout -b feature/new-feature
```
Commit Often and with Purpose:
- Make small, frequent commits to keep the history clean and manageable.
- Each commit should have a clear focus (e.g., fix a bug, implement a specific feature).
Backup to Remote Repositories:
- Always push your work to a remote repository like GitHub or GitLab. This ensures you have a backup and that you can review the history of your changes.
```
  git push origin feature/new-feature
```
Use Tags for Release Points:
- Tags help in marking important points in your project, like releases or stable versions.
```
  git tag v1.0.0
  git push origin v1.0.0
```

Feature Branches

Feature branches allow developers to work on isolated features, bugs, or experiments without affecting the main branch. Once the work is complete, the branch is merged back into the main or development branch.

Why Use Feature Branches?

Isolation: You can work on one feature without affecting others.
Parallel Development: Multiple developers can work on different features simultaneously.
Easier Merging: When the feature is ready, it can be merged back into the main branch via a pull request, which can be reviewed by other team members.

Workflow with Feature Branches:

Create a Feature Branch:

 git checkout -b feature/new-login-system

Work on the Feature:

Add commits related to that feature:

  git add .
  git commit -m "Added new login system"

Push Feature Branch to Remote:

 git push origin feature/new-login-system

Open a Pull Request:
- Review and discuss changes with your team. Once approved, the feature is merged back into the main or development branch.

Delete the Branch (Optional):

 git branch -d feature/new-login-system

Gitflow - Long Running Branches

Gitflow is a popular Git workflow for large-scale projects. It emphasizes two long-running branches: main (or master) and develop, along with shorter-lived feature, release, and hotfix branches.

Gitflow Branches:

Main (or Master):
- This branch holds the production-ready code. Only stable and tested code is merged here.
- Tags are typically created here for version releases.
Develop:
- The develop branch serves as the integration branch for new features. When a feature branch is complete, it’s merged into develop.
Feature Branches:
- Short-lived branches created off develop to work on specific features.
Release Branches:
- When a feature is complete, and the product is ready for release, a release branch is created from develop.
- This branch allows for last-minute bug fixes and documentation before being merged into main and develop.
Hotfix Branches:
- These branches are created from main to address critical issues in production. Once fixed, the branch is merged back into both main and develop.

Example Gitflow Workflow:

Create a Feature Branch:

 git checkout -b feature/new-api develop

After Development, Merge to develop:

 git checkout develop
 git merge feature/new-api

Create a Release Branch:
```
 git checkout -b release/v1.0 develop
```

Merge Release Branch into main:

 git checkout main
 git merge release/v1.0

Create a Hotfix Branch:

 git checkout -b hotfix/fix-security-issue main

Merge Hotfix to Both main and develop:

 git checkout main
 git merge hotfix/fix-security-issue
 git checkout develop
 git merge hotfix/fix-security-issue

GitFlow Article

A Gitflow article typically outlines the importance and benefits of using the Gitflow branching model. These articles discuss how Gitflow offers a structured release process and allows for parallel development across feature and bug fix branches, ensuring that development can proceed while the main branch remains stable.

Trunk-Based Development

Trunk-based development is a Git workflow where developers collaborate on a single, long-lived branch (often called trunk or main). It emphasizes continuous integration and frequent, small commits to the trunk, with minimal use of long-lived branches.

Key Principles of Trunk-Based Development:

Small, Frequent Commits:
- Developers commit small, working pieces of code frequently, minimizing the risk of conflicts.
- Encourages using feature toggles or flags to hide incomplete features in the codebase.
Minimal Branching:
- Instead of using feature branches, changes are integrated directly into main.
- Short-lived feature branches are allowed, but they should be merged back into the trunk within a day or two.
Continuous Integration (CI):
- CI tools ensure that the trunk is always in a working state. If a build or test fails, it is the team’s priority to fix it immediately.
Automated Testing:
- Each commit triggers automated tests to ensure that no new bugs are introduced. This workflow promotes a "fail fast" approach to fixing issues.

Advantages of Trunk-Based Development:

Faster Delivery: Teams can deliver new features or fixes more quickly since there’s no need to wait for long-lived feature branches to be merged.
Fewer Merge Conflicts: Because changes are continuously integrated, conflicts are discovered early and resolved quickly.

Which Workflow to Use?

The choice of workflow depends on the team size, project complexity, and delivery schedule.

Gitflow:

Best suited for large teams and enterprise-level projects where formal release management is required.
Works well for projects with scheduled releases and separate environments (e.g., development, staging, production).

Trunk-Based Development:

Ideal for small teams or fast-paced projects where speed of delivery is crucial.
Works well in environments with continuous delivery or DevOps, where the goal is to release updates frequently.

Feature Branch Workflow:

Great for medium-sized teams working on multiple features in parallel.
Helps ensure that incomplete features don’t affect the stability of the main branch.

Section 9: Git Hooks, Commit Messages, Submodules, Subtrees, Git Aliases, and 2FA (Two Factor Authentication)

Git provides a wide array of features and utilities that can help streamline development processes and enforce certain workflows or practices. This section covers advanced Git concepts and tools like hooks, commit messages, submodules, subtrees, Git aliases, and two-factor authentication (2FA).

Hooks

Git hooks are scripts that Git executes before or after specific events, such as commits, merges, or pushes. These scripts allow you to automate tasks, enforce coding standards, or integrate additional tools in your Git workflow.

Types of Hooks:

Pre-commit: This hook runs before a commit is created. It is often used to check the quality of the code, run tests, or validate the code style.

Example Use Cases:
- Run linting tools (e.g., ESLint) to ensure code style consistency.
- Prevent commits with syntax errors or failing tests.

Example Bash Script for pre-commit:

    #!/bin/bash
    # Run tests before committing
    npm test
    if [ $? -ne 0 ]; then
      echo "Tests failed. Commit aborted."
      exit 1
    fi

Post-commit: This hook runs after a commit is created. It can be used to notify team members of changes, trigger a build pipeline, or update certain logs.

Example Use Cases:
- Send a notification to a messaging platform (e.g., Slack) after every commit.
- Automatically update documentation or version numbers.

Example Bash Script for post-commit:

    #!/bin/bash
    # Notify Slack after each commit
    curl -X POST -H 'Content-type: application/json' \
      --data '{"text":"New commit pushed to repository"}' \
      https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Commit-msg: This hook runs after the commit message is typed but before the commit is finalized. It is commonly used to validate the format of commit messages, ensuring they meet the project's guidelines.

Example Use Cases:
- Enforce a specific commit message format.
- Ensure commit messages include issue tracking numbers or ticket IDs.

Example Bash Script for commit-msg:

    #!/bin/bash
    # Ensure commit messages are at least 10 characters long
    if [ ${#1} -lt 10 ]; then
      echo "Commit message must be at least 10 characters long."
      exit 1
    fi

Pre-push: This hook runs before a git push command is executed. It's typically used to run tests, check for unresolved merge conflicts, or ensure that all commits are in line with the main branch.

Example Use Cases:
- Run integration tests to ensure no broken code is pushed to the remote repository.
- Prevent pushing to certain branches (e.g., the main branch) directly.

Example Bash Script for pre-push:

    #!/bin/bash
    # Ensure no direct pushes to main branch
    branch=$(git rev-parse --abbrev-ref HEAD)
    if [ "$branch" == "main" ]; then
      echo "Pushing to the main branch is not allowed."
      exit 1
    fi

Commit Messages

Commit messages are a crucial part of Git workflows as they provide context for the changes made to the codebase. Well-structured commit messages help developers understand the purpose of each change, track bugs, and maintain a clean Git history.

Best Practices for Commit Messages:

Use Imperative Mood: Write the message as if you're giving a command, such as "Add new feature" instead of "Added new feature."
Separate Subject and Body: The subject line should summarize the change in 50 characters or less, followed by a blank line and a detailed explanation in the body if necessary.
Reference Issues or Tickets: If the commit is related to a specific issue or ticket, mention it in the commit message (e.g., Fixes #123).

Example of a Good Commit Message:

Add support for OAuth authentication

This commit adds OAuth authentication to the login process. This will
allow users to log in using their social media accounts (e.g., Facebook,
Google) instead of creating a new account. The integration was tested
with Google OAuth and is working as expected.

Fixes #123

Enforcing Commit Message Guidelines:

You can use the commit-msg hook to enforce rules for commit messages, as shown earlier.

Submodules

Git submodules allow you to keep a Git repository as a subdirectory of another Git repository. This is useful when you have a project that depends on other projects and you want to keep their histories separate.

Use Cases:

Managing dependencies between multiple repositories.
Keeping track of external libraries within your project.

Example Workflow for Submodules:

Add a Submodule:

 git submodule add https://github.com/example/library.git external/library

Initialize Submodules:
```
 git submodule update --init
```
Updating Submodules:
```
 git submodule update --remote
```

Cloning a Repository with Submodules:

 git clone --recurse-submodules https://github.com/example/project.git

Submodules allow you to manage external dependencies as part of your Git project while keeping their changes separate from the main project history.

Subtrees

Git subtrees are an alternative to submodules that allow you to merge another repository into a subdirectory of your project, while keeping a copy of the other repository’s files and its commit history. Subtrees are more flexible than submodules, as they don’t require any special handling when cloning or managing repositories.

Advantages Over Submodules:

No need for special initialization.
Cloning a repository with subtrees is simpler because the external files are included directly in the project.

Example Workflow for Subtrees:

Add a Subtree:

 git subtree add --prefix=external/library https://github.com/example/library.git master --squash

Pull Updates from the Subtree:

 git subtree pull --prefix=external/library https://github.com/example/library.git master --squash

Push Updates to the Subtree:

 git subtree push --prefix=external/library https://github.com/example/library.git master

Subtrees allow you to merge external repositories into your project more seamlessly than submodules.

Git Aliases

Git aliases are shortcuts for Git commands, allowing you to create custom command names to reduce typing or simplify repetitive commands. Aliases are configured in Git's configuration file (.gitconfig).

Creating Git Aliases:

Open .gitconfig:
```
 git config --global --edit
```

Add Aliases: In the .gitconfig file, under the [alias] section, add your aliases.

 [alias]
   co = checkout
   br = branch
   cm = commit
   st = status
   lg = log --graph --oneline --all

Use the Aliases:

 git co master      # Equivalent to `git checkout master`
 git cm -m "Message" # Equivalent to `git commit -m "Message"`
 git lg             # Equivalent to a custom log command

Aliases can significantly speed up your Git workflow, especially when working with long or complex commands.

Two-Factor Authentication (2FA)

Two-Factor Authentication (2FA) adds an extra layer of security to your GitHub, GitLab, or Bitbucket account by requiring not only a password but also a one-time code generated by a device (usually a mobile phone app like Google Authenticator).

How 2FA Works:

Step 1: Enter your username and password to log in.
Step 2: Enter a second authentication factor, such as a one-time code generated by your phone.

Enabling 2FA on GitHub:

Go to Account Settings:
Navigate to Settings > Security > Two-factor authentication.
Choose Your Authentication Method:
- You can use an authenticator app like Google Authenticator or SMS.
Backup Codes:
- When setting up 2FA, GitHub will give you a set of backup codes. Store them in a safe place. These codes can be used if you lose access to your authenticator device.

Git Operations with 2FA:

When using HTTPS to push or pull from a remote repository, you will need to use a personal access token instead of your password once 2FA is enabled.
```
  git push https://github.com/username/repository.git
```
You will be prompted to enter your token as the password.

To generate a personal access token:
- Go to Settings > Developer settings > Personal access tokens on GitHub.
- Generate a new token with the appropriate permissions.

Section 10: Other Git Usages

This section delves into specialized uses of Git and integrates various tools and features to extend its functionality. From managing system files using etckeeper and dotfiles to utilizing Git Large File Storage (LFS) and enhancing Git workflows through Visual Studio Code (VS Code) extensions like GitLens, these topics represent advanced but practical applications of Git.

etckeeper & Git

etckeeper is a tool that integrates Git (or other version control systems) with the /etc directory on Linux systems. It allows for the tracking of configuration files under /etc, which can help system administrators manage and audit changes.

How etckeeper Works:

The /etc directory contains important system configuration files. Tracking changes to these files is crucial for maintaining system integrity.
etckeeper initializes a Git repository in /etc, enabling you to track changes to the files over time.
It automatically commits changes when system packages are installed, upgraded, or removed (using package managers like apt or yum).

Setting up etckeeper with Git:

Install etckeeper:
```
 sudo apt install etckeeper
```
Configure etckeeper: Edit the configuration file /etc/etckeeper/etckeeper.conf to ensure Git is selected as the version control system:
```
 VCS="git"
```

Initialize the Git repository:

 sudo etckeeper init
 sudo etckeeper commit "Initial commit"

Automatically commit changes: After installing or updating packages, etckeeper automatically runs git commit to save the changes made to /etc.

Manual commits: You can also manually commit changes as you would in any Git repository:

 cd /etc
 sudo git status
 sudo git commit -a -m "Manual commit of config changes"

Revert changes: To revert configuration files to an earlier version:
```
 sudo git checkout <commit_hash> -- path/to/file
```

Use Case: System administrators use etckeeper to keep track of changes in the /etc directory, allowing for easy rollbacks if misconfigurations occur, and enabling auditing of changes over time.

Dotfiles 01: Managing Linux Configuration Files with Git

Dotfiles are configuration files in Linux whose filenames begin with a dot (.), such as .bashrc, .vimrc, and .gitconfig. These files control how programs and environments behave.

Using Git to manage dotfiles ensures that you can easily transfer your configuration across systems, maintain version control, and track changes to your personal settings.

Setting up Dotfiles with Git:

Create a directory for your dotfiles:
```
 mkdir $HOME/dotfiles
```

Move your existing configuration files into the dotfiles directory:

 mv $HOME/.bashrc $HOME/dotfiles/
 mv $HOME/.vimrc $HOME/dotfiles/

Create symbolic links from the dotfiles directory back to the home directory:

 ln -s $HOME/dotfiles/.bashrc $HOME/.bashrc
 ln -s $HOME/dotfiles/.vimrc $HOME/.vimrc

Initialize a Git repository in the dotfiles directory:

 cd $HOME/dotfiles
 git init
 git add .
 git commit -m "Initial commit of dotfiles"

Push the dotfiles to a remote Git repository (e.g., GitHub):

 git remote add origin https://github.com/yourusername/dotfiles.git
 git push -u origin master

Benefits:

You can clone your dotfiles to any machine and instantly configure your environment.
Using Git allows you to track changes and experiment with new configurations safely.

Dotfiles 02: Importing Dotfiles Configurations

When you want to set up a new machine with your existing dotfiles, you can simply clone your dotfiles repository and restore the symbolic links.

Steps to Import Dotfiles:

Clone your dotfiles repository:

 git clone https://github.com/yourusername/dotfiles.git $HOME/dotfiles

Create symbolic links to the appropriate configuration files:

 ln -s $HOME/dotfiles/.bashrc $HOME/.bashrc
 ln -s $HOME/dotfiles/.vimrc $HOME/.vimrc

Reload your shell to apply changes:
```
 source $HOME/.bashrc
```

Now your new system will be configured with the same settings as your previous machine.

Git Large File Storage (LFS)

Git Large File Storage (LFS) is an extension for Git that allows you to version control large files (e.g., media, binary files) without bloating your repository. LFS replaces the actual large files in your Git repository with pointers to their locations in an external storage system, while keeping the full repository small and manageable.

How Git LFS Works:

Git LFS stores large files outside the regular Git repository.
When a file is added to the repository, a small text pointer file is stored instead of the actual large file.
The large files are stored on a remote server (e.g., GitHub LFS or a custom LFS server).

Setting up Git LFS:

Install Git LFS:
```
 git lfs install
```

Track specific file types with LFS:

 git lfs track "*.psd"  # Track all Photoshop files
 git lfs track "*.zip"  # Track all zip files

Add and commit files:

 git add file.psd
 git commit -m "Add large PSD file with LFS"

Push changes to a remote repository:
```
 git push origin master
```

Use Cases:

Storing large media files, videos, datasets, or binaries without slowing down your Git repository.
Suitable for game development, multimedia projects, and scientific research where large files are often involved.

Visual Studio Code: Git Integration

Visual Studio Code has built-in Git integration, making it easy to work with Git directly within the editor. This integration simplifies many Git operations such as staging, committing, branching, and merging.

Features of VS Code Git Integration:

Source Control View: Displays changes, staged files, and branch status.
Commits and Staging: Stage changes and commit directly from the editor.
Branching: Manage branches and switch between them within VS Code.
Diff View: Compare changes in a visual, side-by-side format.

Using Git in VS Code:

Initialize a Repository:
- Open VS Code, navigate to the Source Control pane, and click Initialize Repository.
- This creates a new Git repository in the current folder.
Stage and Commit Changes:
- In the Source Control pane, select the files to stage, add a commit message, and click Commit.
Push to a Remote Repository:
- In the Source Control pane, click Publish to GitHub to push the repository to GitHub.

Use Case: VS Code’s Git integration streamlines Git workflows, making it easier to manage code and collaborate without switching between the editor and the command line.

Visual Studio Code: GitLens Extension

GitLens is an extension for Visual Studio Code that enhances Git functionality by providing advanced features like blame annotations, commit details, and Git history insights.

Key Features of GitLens:

Blame Annotations: View who last modified a line of code and the commit message associated with it.
File History: See the commit history of a file, including detailed changes and commit messages.
Branch Comparison: Compare changes between branches and visualize differences.
Commit Graph: View a graphical representation of the Git commit history, making it easier to track changes over time.

Installing GitLens:

Open VS Code and go to Extensions.
Search for GitLens and click Install.

Using GitLens:

Line Blame: Hover over a line of code, and GitLens shows who last modified it and when.
File History: Right-click a file and select Open File History to see the list of commits affecting that file.
Visualize Git Graph: Open the GitLens pane to view the entire Git history as a graph.

Use Case: GitLens is ideal for developers who want deep insights into their Git history, including who made changes and the reasoning behind them, making collaboration and debugging much easier.

[Git Cheat Sheet : gitcheatsheet.tiiny.site]

Section 11: Additional Content

This section covers advanced topics related to Git usage on GitHub and GitLab, including security practices like signed commits, handling GitHub’s updated authentication requirements with HTTPS, and how to deploy a GitLab server on Oracle Cloud.

Signed Commits: GitHub

Signed commits are a way to prove the authenticity of the commits you push to a repository. By signing commits, you provide cryptographic proof that the changes come from you, preventing identity forgery or unauthorized changes to your repositories.

What are Signed Commits?

A signed commit uses a GPG key (GNU Privacy Guard) or SSH key to cryptographically verify the identity of the person making the commit.
GitHub shows a verified badge next to signed commits, which confirms that the commit is legitimate and not tampered with.

Why Use Signed Commits?

Security: Provides a layer of security, ensuring that changes come from a trusted source.
Trust: Establishes credibility in open-source and collaborative projects, making it harder for attackers to impersonate developers.
Compliance: Required for certain regulatory and security-conscious environments, especially for enterprise and large-scale projects.

Setting up Signed Commits with GPG Keys on GitHub:

Install GPG:

On Ubuntu/Debian:
```
  sudo apt-get install gnupg
```
On macOS (using Homebrew):
```
  brew install gnupg
```

Generate a GPG key:
```
 gpg --full-generate-key
```
Follow the prompts to generate a new GPG key. Select RSA encryption with at least 4096 bits for higher security. Set an expiration date if desired.
List your GPG keys and note the key ID:
```
 gpg --list-secret-keys --keyid-format LONG
```
The output will show the GPG key you just created. Note the Key ID (a 16-character string).

Tell Git to use your GPG key for signing:

 git config --global user.signingkey <your-key-id>

Add your GPG key to GitHub:
- Export your GPG key:
```
  gpg --armor --export <your-key-id>
```
- Copy the output and go to GitHub > Settings > SSH and GPG keys, then click New GPG Key. Paste your public key and save.
Sign commits automatically: To automatically sign every commit, run:
```
 git config --global commit.gpgSign true
```
Manually sign a commit: If you don’t want to sign every commit automatically:
```
 git commit -S -m "My signed commit message"
```
Verify the signature: GitHub shows a Verified badge next to signed commits, indicating the commit was signed with a valid key.

HTTPS Support Removed on GitHub 01: Use Personal Access Token Instead

GitHub recently removed the ability to authenticate over HTTPS using a username and password. Instead, users must use Personal Access Tokens (PATs) to authenticate Git operations over HTTPS.

What is a Personal Access Token (PAT)?

A Personal Access Token acts as a substitute for your password, providing scoped, time-limited authentication for Git operations over HTTPS.
Tokens are tied to your GitHub account and can be configured to limit access to specific resources or repositories.

Setting up a Personal Access Token on GitHub:

Generate a Personal Access Token:
- Go to GitHub > Settings > Developer settings > Personal Access Tokens.
- Click Generate new token and provide the following:
  - A name for the token.
  - Expiration date (optional but recommended).
  - Scopes: Select the permissions the token will have. For basic Git operations, you will need repo and workflow scopes.
Copy the token:
- Once generated, GitHub will show the token once. Copy it and store it securely. You won’t be able to retrieve it later.
Using the token in Git: When you perform Git operations over HTTPS, Git will prompt you for a password. Instead of your GitHub password, enter the token.

Example: Cloning a repository with a token:
```
 git clone https://<your-username>@github.com/<repository>.git
```
When prompted for a password, paste your token.
Cache your token: To avoid entering the token every time, you can cache your credentials:
```
 git config --global credential.helper cache
```

Note: Tokens should be treated like passwords and kept secure. You can revoke or regenerate tokens at any time from your GitHub settings.

HTTPS Support Removed on GitHub 02: Use SSH Key Instead

An alternative to using Personal Access Tokens for Git operations over HTTPS is to authenticate via SSH keys. SSH keys offer a secure, password-less way to interact with GitHub.

What is SSH Authentication?

SSH authentication uses a pair of cryptographic keys—one public and one private—to authenticate the connection between your local machine and GitHub.
Your public key is stored in GitHub, while the private key remains on your machine. GitHub uses the public key to verify the identity of the private key holder.

Setting up SSH Authentication for GitHub:

Generate an SSH key pair:
```
 ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
- -t rsa: Specifies RSA as the encryption algorithm.
- -b 4096: Sets the key size to 4096 bits for better security.
- -C "your_email@example.com": Adds a comment (usually your email) to identify the key.

You’ll be prompted to specify a location to save the key. You can press Enter to accept the default location (~/.ssh/id_rsa).

Add the SSH key to the SSH agent: Start the SSH agent and add your private key to it:
```
 eval "$(ssh-agent -s)"
 ssh-add ~/.ssh/id_rsa
```
Add your SSH public key to GitHub:
- Copy the contents of your public key:
```
  cat ~/.ssh/id_rsa.pub
```
- Go to GitHub > Settings > SSH and GPG keys, click New SSH Key, paste the public key, and give it a name.
Use SSH for Git operations: To clone a repository over SSH, use the following syntax:
```
 git clone git@github.com:<username>/<repository>.git
```
Test your SSH connection:
```
 ssh -T git@github.com
```
If successful, GitHub will respond with a welcome message.

Deploying GitLab on Oracle - Commands

Hi there :),

Here are the commands that you will need in order to deploy your own GitLab Server in the next video. Please amend certain commands (they're marked) before executing them. You might wanna open this as a secondary browser tab or just copy & paste the content into an editor.

---------

To connect to your newly deployed VM via SSH:

ssh -i </path_to_your_private_key>/<private_key> ubuntu@<your_public_ip>

---------

sudo apt-get update

sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

sudo apt-get install -y postfix

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

sudo GITLAB_ROOT_PASSWORD="<strongpassword>" EXTERNAL_URL="http://gitlab.<yourdomain.com>" apt install gitlab-ee

sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT

sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT

sudo netfilter-persistent save

After all this your GitLab server should be accesible under http://gitlab.<yourdomain.com> but in order to access it under https we need to generate SSL certificates. GitLab offers you to do this automatically. The file you need to edit is /etc/gitlab/gitlab.rb

external_url "https://gitlab.example.com" # change the URL, make sure its https

letsencrypt['enable'] = true

letsencrypt['contact_emails'] = ['foo@email.com'] # optional for notifications

letsencrypt['auto_renew'] = true

letsencrypt['auto_renew_hour'] = "12"

letsencrypt['auto_renew_minute'] = "30"

letsencrypt['auto_renew_day_of_month'] = "*/7"

Once finished, save the file and execute sudo gitlab-ctl reconfigure after a few minutes you can visit your GitLab instance under HTTPS.

Deploying Your Own GitLab Server on Oracle Cloud

GitLab is an open-source DevOps lifecycle tool that provides Git repository management, continuous integration, and continuous delivery. You can host your own GitLab instance on cloud providers like Oracle Cloud to manage private repositories and projects.

Steps to Deploy a GitLab Server on Oracle Cloud:

Set Up an Oracle Cloud Virtual Machine (VM):
- Sign up for Oracle Cloud Infrastructure (OCI): Oracle Cloud offers free tiers, including VMs.
- Create a new VM instance:
  - Choose an Ubuntu or CentOS image (recommended for GitLab).
  - Configure CPU, RAM, and storage according to your needs.
  - Generate and provide an SSH key to access the VM later.
SSH into the VM: Once the VM is running, connect to it using SSH:
```
 ssh -i /path/to/private-key opc@<VM-IP-address>
```
Update the server: Before installing GitLab, update the system packages:
```
 sudo apt-get update
 sudo apt-get upgrade
```

Install GitLab:

Download the GitLab installation package from the GitLab official site:

  curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Install GitLab:

  sudo EXTERNAL_URL="http://<VM-IP-address>" apt-get install gitlab-ee

Replace <VM-IP-address> with your VM’s public IP.

Configure GitLab: After installation, configure GitLab:
```
 sudo gitlab-ctl reconfigure
```
Access GitLab in a Web Browser: Open a web browser and go to http://<VM-IP-address>. You should see the GitLab login page.
Set the root password: You’ll be prompted to set an admin (root) password for GitLab.
Optional: Secure GitLab with HTTPS: If you want to use HTTPS for GitLab, install SSL certificates (e.g., using Let’s Encrypt) and configure the GitLab instance to use them.

Practice Git with OhMyGit

Hi there,

some of you might have come across "Oh My Git!" already, but for those who haven't, it's a valuable tool to get more Git practice without having to bother around your own Repositories.
Oh My Git! is an interactive game that helps you practice and improve your Git skills through challenges. In the game, you use actual Git commands to solve problems in a simulated setting, which mirrors real-world scenarios. Each level is designed to help you get better at using Git for tasks like branching, merging, and rebasing. Oh My Git! is great for reinforcing what you've learned in this course and for building more confidence in handling Git commands. It's an effective tool for both reviewing basics and mastering more complex Git operations.

Command Palette

Section 1: Introduction

What is Git?

"Git" and "git"

Different Git Interfaces

Git vs. GitHub vs. GitLab

Section 2: Git Quick Dive and Authentication

Installing Git on Linux

Installing Git on Windows

Choosing Our Default Git Editor

Creating Our GitHub Account

Cloning Our GitHub Repository

git add & git commit

git status

.gitignore

git push and git pull

git log

Push Local Repository to GitHub

Branches

Authentication Overview

Authentication: Windows Credential Manager

Authentication: macOS Keychain

Authentication: SSH Instead of HTTPS

Authentication: Changing Local Repo to SSH

IDE & Editors: Overview

IDE & Editors: Emacs

IDE & Editors: Git Gui

IDE & Editors: GitHub Desktop

IDE & Editors: IntelliJ

IDE & Editors: TortoiseGit

IDE & Editors: VsCode GitLens

Git with Synchronization and Backups

Section 3: Git Advanced Deep Dive

Git Commits: Deep Dive

Git Commits: Internals

Git Commits: Move and Delete

Git Commits Undo: git reset and git restore

Git Commits Undo: git show and git diff

Git Commits Undo: git revert

Git Commits Undo: Changing Commit Message

Branches

Merging

Git Stash-Area (Stashing)

Remote Repositories

Merge Conflict (VS Code)

Merge Conflict (Merge Tools: MELD)

Merge Conflict: Content Merge Conflict and Internals

Rebasing

Tags

Referencing Commits

Section 4: Information Analysis in Git-Repository

Search Commits

Search Files

Search Errors

Visualization and Statistics

Section 5: GitHub

Pull Requests

Organisations

a. Teams

b. Permission Levels

c. Protected Branches

d. Project Boards

Forking

Issues and Labels

Markdown Syntax

GitHub Actions

GitHub Wiki

GitHub Pages

GitHub Security with Dependent and CodeQL

a. Dependabot:

b. CodeQL:

Section 6 : GitLab

Creating Projects (Repositories)

Merge Requests

Issues & Labels

Project Member Permissions

Groups & Permissions

Project Boards & Milestones

Wiki

Snippets

Git Commits Undo: `git reset` and `git restore`

Git Commits Undo: `git show` and `git diff`

Git Commits Undo: `git revert`