# Git
:::spoiler {state="open"} **🧷 Table of Content**
[toc]
:::

<br/>

 **Git** is a powerful distributed version control system that has become the industry standard for managing and tracking changes in codebases. It allows multiple developers to work collaboratively on projects, ensuring that every change is tracked, reversible, and can be seamlessly merged with the work of others.

By mastering Git, developers can efficiently manage source code, track history, and collaborate with teams of any size. Understanding the fundamental concepts of version control, branch management, and remote repository interactions will significantly enhance your software development workflow.

<br/>

## **[Git Overview](#git-overview)**
- **Version Control**
- It is a system that records changes to a file or set of files over time so that you can recall specific versions later. It is essential for managing the development of projects where multiple versions of code and files need to be maintained, tracked, and collaborated on.
- **Tracking Changes:** Every modification in the codebase is logged with details such as who made the change, what was changed, and when it was done.
- **Collaboration:** Version control systems allow multiple developers to work on the same project simultaneously without interfering with each other’s work.
- **Backup and Restore:** Version control ensures that all versions of the project are stored and can be restored to any previous state if needed.
- **Branching and Merging:** Developers can create branches to work on new features or bug fixes in isolation and later merge these changes back into the main project.
- **Distributed Systems**
- A distributed version control system (DVCS) allows all developers to have a complete copy of the project’s history locally, enabling offline work and reducing dependency on a single central server. Git is a distributed system, meaning every clone of a repository is a full-fledged repository with complete history and full version-tracking capabilities.
- **Local Repositories:** In a DVCS like Git, developers can commit changes locally and sync with remote repositories only when necessary.
- **Collaboration:** Collaboration is easier in a distributed system as developers can share changes directly between repositories without needing to go through a central server.
- **Flexibility:** A distributed system is more resilient to failure; if the central server crashes, any local repository can be used to restore the system.
- **Git vs. Other Version Control Systems**
- We should also understand how Git compares to others like Subversion (SVN) and Mercurial.
- **Git vs. SVN**:
- **Distribution**: Git is distributed, while SVN is centralized. This makes Git more robust and flexible in terms of offline work and collaboration.
- **Branching**: Git’s branching model is lightweight and encourages branching and merging, while SVN’s branches are heavier and often harder to manage.
- **Speed**: Git is generally faster, especially for large projects, because most operations are performed locally.
- **Git vs. Mercurial**:
- **Simplicity vs. Flexibility**: Mercurial is known for being simpler and more user-friendly, which can make it easier for new users to learn. Git, on the other hand, offers more flexibility and power, which might be preferred for more complex workflows.
- **Popularity**: Git has a larger community and more tools and services built around it (e.g., GitHub, GitLab), making it the more popular choice in the industry.
- **Performance**: Both Git and Mercurial perform well, but Git has an edge in handling large codebases with a complex history.

<br/>

## [Git Basis](#git-basis)
### Structures
1. **Git Bash**
- A command-line shell, making it easier to interact with _**repositories**_ through standard command-line tools.
- Interacting by typing commands to perform miscellaneous operations.
2. **Working Directory** _**(Working Tree)**_
- The location where you actively work on your project, containing all your files and directories.
- Any changes made here are untracked until you add them to the _**Index**_.
3. **Index**
- Also known as the "_**Staging Area**_," it temporarily stores files and changes that are about to be committed.
- It is _mutable_, allowing multiple updates until you're ready to commit to the repository.

:::spoiler Look into Git Index

- **Alternative Names**
- Cache
- Staging Area
- Staged files
- Directory cache
- Current directory cache
> e.g. `git diff --cached` equal to `git diff --staged`

- **File Status**
- untracked 🡆 Files not yet added to the repository.
- unmodified 🡆 Files identical to the last commit (HEAD).
- modified 🡆 Files that have been changed since the last commit.
- staged 🡆 Files added to the staging area, ready for the next commit.

<br/>

[](https://raw.githubusercontent.com/doggy8088/Learn-Git-in-30-days/master/zh-tw/figures/07/01.png)

<br/>

:::

4. **Object**
- The fundamental unit in Git, including Blobs, Trees, Commits and Tags.
- Objects are _immutable_; once written to the repository, they don't change.
- The object store is Git's object database, storing snapshots of all versions.

:::spoiler Look into Git Objects
### 1. Object Types

| **Git Object** | **Description** | **Hash Role** |
|-|-|-|
| **Blob** | Represents the content of a file. It is a binary large object without metadata like filenames. | Hashes the file content to ensure integrity and uniqueness. |
| **Tree** | Represents a directory, containing references to Blobs (files) and other Trees (subdirectories). | Hashes the directory structure and its contents, including references to Blobs and other Trees. |
| **Commit** | Represents a snapshot of the repository's state, including metadata like author, date, and commit message. | Hashes the snapshot of the repository, including metadata and references to other commits. |
| **Tag** | Labels a specific commit with a human-readable name, often used for marking releases or milestones. | Hashes the label pointing to a specific commit, along with additional tag information. |

- Each object is identified by a unique ++SHA1 hash++, known as its "absolute name."

- This hash ensures the integrity and uniqueness of each object.

- For commit objects, the absolute name is the commit hash, which allows us to retrieve the exact version of the repository at any point.

<br/>

### 2. **References (refs)**
Git uses symbolic names called "refs" as ++pointers to point to Objects++. Common `Commit` refs include:
- `HEAD`: Refers to the latest commit in the current branch.
- `refs/heads/<branch>`: Points to the latest commit in a specific branch.
- `refs/tags/<tag>`: Points to a specific commit labeled by a tag.
- `refs/remotes/<remote>/<branch>`: Points to the latest commit in a remote-tracked branch.
- `.git/refs/remotes/`: This directory stores references to the heads of branches in remote repositories. Each remote-tracked branch will have an entry here, for example, `.git/refs/remotes/origin/main`, which tracks the `main` branch from the `origin` remote.
- **Reference Paths Order**:
1. `.git/<ref>`: The general reference pointer in the Git repository.
2. `.git/refs/<ref>`: Stores references such as heads, tags, and remotes.
3. `.git/refs/tags/<tag>`: Points to a specific tag reference by name.
4. `.git/refs/heads/<branch>`: Points to a local branch reference by name.
5. `.git/refs/remotes/<remote>`: Tracks refs to branches in a remote repository.
6. `.git/refs/remotes/<remote>/HEAD`: Tracks the latest commit of the default branch in a remote repository.

- **Symref (Symbolic Reference)**
- A symref is a symbolic reference that points to another reference, often used to indicate the current branch or state of the repository.
- Rather than storing a direct hash value, symrefs point to other references (such as branch heads), which in turn resolve to the actual commit hashes.
:::spoiler **Common Symrefs**
| **Symref** | **Description** |
|-|-|
| `HEAD` | Points to the current branch's latest commit or a specific commit if in a detached HEAD state. |
| `ORIG_HEAD` | Stores the original `HEAD` reference before a potentially disruptive operation (e.g., a merge). |
| `FETCH_HEAD` | Refers to the branch that was fetched during the most recent `git fetch` operation |
| `MERGE_HEAD ` | Stores the commit that is being merged during an ongoing merge operation. |
| `CHERRY_PICK_HEAD` | Points to the commit being cherry-picked during an active cherry-pick operation. |
| `REBASE_HEAD` | Points to the commit being applied in a rebase process. |
:::

- **Custom References**

"Reference names" serve specific purposes, typically used in scenarios involving `local branches`, `remote branches`, and `tags`.

But we can create any number of ++custom reference names++ using `git update-ref` to establish **general references**.

- **`git show-ref`**: Lists all references and their corresponding commit hashes, useful for viewing the state of references.
- **`--heads`**: Shows references to local branches only.
- **`--tags`**: Shows references to tags only.
- **`--dereference`**: Follows symbolic references and shows the actual commits they point to.

- **`git update-ref`**: Used to create or update references in the repository, allowing you to set up custom references as needed.
- **`-d`**: Delete a specific reference.
- **`<ref>`**: The reference name to create or update (e.g., `refs/heads/my-branch`).
- **`<commit>`**: The commit hash or reference to set for the specified reference.
- **`<old-value>`**: The old value of the reference, used to prevent updates if it has changed.

- **`git symbolic-ref`**: Reads or updates symbolic references, which are references that point to other references (e.g., `HEAD` pointing to a branch).
- **`<ref>`**: The symbolic reference to read or update (e.g., `HEAD`).
- **`<new-ref>`**: The new reference to set (for updating symbolic references).
- **`--short`**: Outputs the short name of the reference.
:::

5. **Repository**
- Contains the complete history of version control, serving as the full record of your project.
- It includes the working directory, index, and object store combined.
- Can be a local or remote repository, used for collaborative developmen

> ==The operation of the Git repository is to write the changes in the working directory into Git objects by updating the Index.==

<br/>

### Basic Operations

:::success
_★ You can always use `git help [COMMAND]` to lookup for documentation._
:::

| Command | Operation | Description |
|-|-|-|
| `git init` | _Initializing a Repository_ | Creates a new, empty Git repository in the current directory. <br/> |
| `git clone` | _Cloning a Repository_ | Creates a copy of an existing repository from a remote server to your local machine with automatically built working directory. |
| `git status` | _Checking Status_ | Displays the state of the working directory and the staging area, showing any changes that are staged, unstaged, or untracked (use `-s` to see simplified info). |
| `git log` | _Viewing Commit History_ | Shows a list of the commit history for the current branch, displaying commit IDs, authors, dates, and messages. <br/> |
| `git add` | _Adding Files_ | Adds changes in the working directory to the staging area, preparing them for commit. |
| `git commit` | _Committing Changes_ | Saves the changes from the staging area to the local repository with a descriptive message. |
| `git checkout` | _Switching Branches or Restoring Files_ | Switches to a different branch or restores working directory files to a previous state. This command can be used to navigate between branches or revert changes in files. |
| `git reset` | _Resetting Changes_ | Undoes changes in the working directory or staging area, with different levels of impact (`--mixed`(default), `--soft`, `--hard`). |

1. **`git init`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `[NULL]` | Initializes a standard Git repository with a working directory. This is the default mode, where you can work on files directly and track changes locally before pushing them to a remote repository. |
| `--bare` | Initializes a bare repository with no working directory, typically used for shared repositories(remote) or centralized management: <br/> • A bare repository is commonly used as a central repository for collaboration, where multiple developers can push and pull changes. <br/> • It is not suitable for direct development work as it does not have a working directory. |
:::

<br/>

2. **`git clone`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `<REPOSITORY_URI>` | Specifies the URI of the repository you want to clone. This can be a remote repository on GitHub, Bitbucket, or another server. |

:::spoiler **URI**
- **U**niform **R**esource **I**dentifier
- A string used to uniquely identify a resource on the internet.
- It consists of a scheme (e.g., `http`, `https`), followed by a path, and sometimes additional components like query strings or fragments.
- Commonly used URIs include URLs (Uniform Resource Locators) that specify the location of a resource.:::

:::

<br/>

3. **`git log`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `--oneline` | Displays each commit on a single line with a shortened commit hash and message for a concise view of the history. |
| `-n <number>` | Limits the log output to a specific number of commits, helpful for reviewing a small portion of history. |
| `--abbrev-commit` | Displays a shortened version of the commit hash (abbreviated to a few characters) instead of the full hash in the log output. This is often combined with `--oneline` for concise logs. |
| `--pretty=<format>` | Formats the log output according to the specified format (e.g., `oneline`, `short`, `full`, `medium`). Allows customization of the commit log's appearance. |
| `--pretty=format:"<placeholders>"` | Customizes the log format using placeholders (e.g., `%h` for commit hash, `%an` for author name, `%s` for commit message). Enables a highly personalized view of the commit history. |

:::

<br/>

4. **`git add`**
:::spoiler **Note**
<br/>

- **Staging Area (≈Index):** The place where changes are prepared before committing them to the repository, allowing you to review and organize changes without making them part of the project's history just yet.
- **Example:** __`C:\User\...\git_demo [master +10 ~0 ~0 !]>`__ _`git add . <Enter>`_ <!-- 🡆 -->
- **`Added +10`**: Number of new files or lines added.
- **`Modified ~0`**: Number of modified files or lines.
- **`Deleted !0`**: Number of deleted files or lines.
> Git Bash may have __Red__ and __Green__ colors to represent the status of the _**Current**_ working directory, where red indicates unstaged changes, vise versa. And partital staged changes would make both colors appear at the same time.
:::

:::spoiler _**args**_

| Argument | Function |
|-|-|
| `.` | Adds all changes (modified, new, or deleted files) in the current directory and its subdirectories to the _**staging area**_. |
| `-u` | Adds only the changes to tracked files, ignoring untracked files. Useful when you want to stage ++modifications++ and ++deletions++ but not new files. |
| `<file>` | Adds a specific file to the staging area. You can use this to stage individual files rather than everything. |
| `<directory>` | Adds all changes within the specified directory to the staging area, including its files and subdirectories beneath it. |
| `<REGULAR_EXPRESSION>` | Adds files that match the provided regular expression. This allows for selective staging of files based on naming patterns or extensions (e.g., `*.js` for all JavaScript files). |
:::

<br/>

5. **`git commit`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `[NULL]` | Opens the default text editor to enter a commit message and then commits all staged changes to the local repository. Only the changes that have been added to the staging area will be included in the commit. |
| `-m <message>` | Allows you to specify a commit message directly from the command line without opening an editor. |
:::

<br/>

6. **`git checkout`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `-- <file>` | Restores a file to its state in the Index or the last commit, useful for discarding local changes to a file. |
| `<file_name>` | Restores a specific file in the working directory to the version in the specified commit or branch. This is useful for undoing changes to a file. Avoid `git reset --hard` that restores all files. |
| `<branch_name>` | Switches to the specified branch. If the branch does not exist, you can create and switch to a new branch by using `-b`. |
| `<branch_name>@{<n>}` | Checks out the state of the branch at a specific time, where `<n>` is the number of commits ago. For example, `HEAD@{1}` refers to the state of the branch just before the last change. |
| `-b <new_branch_name>` | Creates a new branch with the specified name and switches to it immediately. This is useful for starting new features or fixes. |
| `-d <old_branch_name>` | Deletes a branch. If the branch has unmerged changes, use `-D` to force deletion. Note: This will not delete the branch you are currently on. |
| `<commit_hash>` | Checks out a specific commit by its hash, effectively creating a "detached HEAD" state where the working directory reflects the state of the repository at that specific commit. |
:::

<br/>

## [Git File Management](#git-file-management)
Git tracks files in your repository, allowing you to manage their versions and changes.

### Common Operations
| Command | Operation | Description |
|-|-|-|
| `git rm` | _Removing Files_ | Removes files from the working directory and stages the removal for the next commit. If the file has already been staged or committed, it will also be removed from the repository's history. |
| `git mv` | _Renaming/Moving Files_ | Moves or renames files within the repository. This command stages the move/rename operation, which will be committed in the next commit. |
| `git restore` | _Restoring Files_ | Discards changes in the working directory and reverts to the last committed state. Useful for undoing changes to a file before committing. |
| `git clean` | _Removing Untracked Files_ | Removes untracked files and directories from the working directory. This is useful for cleaning up files that are not being tracked by Git and are not needed. |
| `git show` | _Showing Object Details_ | Displays information about a specific Git object (usually a commit), including commit message, changes, and metadata. Useful for inspecting individual commits and the changes they introduced. |
| `git diff` | _Comparing Changes_ | Shows the differences between files in the working directory and the index or between commits. Useful for reviewing changes before committing. |
| `git cat-file` | _Inspecting Git Objects_ | Displays the content or type of a Git object (commit, tag, tree, or blob) using its SHA1 hash. Useful for examining repository objects directly. |
| `git ls-files` | _Listing Files_ | Lists all files in the index (staged files) and optionally shows the status of files relative to the working directory. |

1. **`git rm`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `--cached` | Removes files from the staging area but keeps them in the working directory. This is useful if you want to stop tracking a file without deleting it locally. |
| `-f` | Forces the removal of files, even if they have changes or are not staged. |
| `<file>` | Specifies the file to remove from both the staging area and the working directory. |
| `<directory>` | Removes all files within the specified directory from both the staging area and the working directory. |
:::

<br/>

2. **`git mv`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `<oldname> <newname>` | Moves or renames the file `oldname` to `newname`. |
| `-f <oldname> <newname>` | Forces the move, even if it overwrites existing files. |
| `<oldpath> <newpath>` | Moves a file or directory from `oldpath` to `newpath`. |
:::

<br/>

3. **`git show`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `<commit>` | Shows the details of the specified commit, including the commit message, author, and file changes. |
| `--stat` | Displays the file change statistics (number of insertions and deletions) alongside the commit details. |
| `--name-only` | Lists only the file names that were changed in the specified commit. |
| `--name-status` | Shows the file names along with their statuses (added, modified, or deleted) in the specified commit. |
| `--pretty=<format>` | Formats the commit output in a specified format. Common options are `oneline`, `short`, `full`, `medium`. |
| `--abbrev-commit` | Displays only the abbreviated commit hash rather than the full 40-character hash. |
:::

<br/>

4. **`git diff`**
:::spoiler **Note**
- In the context of Git diff outputs, the `@@` symbols denote the start of a new chunk of changes.
- The numbers within the `@@` symbols provide information about which lines in the original and new files are affected by the changes.

| Symbol | Meaning | Description |
|--------|---------|-------------|
| `-<start-line>,<num-of-lines>` | Original File | Indicates the starting line and number of lines in the original file where changes occurred. `<start-line>` is the line number in the original file, and `<num-of-lines>` is the number of lines affected. |
| `+<start-line>,<num-of-lines>` | New File | Indicates the starting line and number of lines in the new file where changes occurred. `<start-line>` is the line number in the new file, and `<num-of-lines>` is the number of lines affected. |
| `@@` | Chunk Header | Marks the start of a chunk of changes. Shows the line ranges in both the original and new files affected by the changes. |
:::

:::spoiler _**args**_

| Argument | Function |
|-|-|
| `NULL` | Shows differences between the working directory and the index for all files. |
| `HEAD` | Shows differences between the working directory and the last commit. |
| `<file>` | Shows differences between the working directory and the index for the specified file. |
| `HEAD <file>` | Shows differences between the working directory and the last commit for the specified file. |
| `<branch>` | Compares the changes between the current branch and the specified branch. |
| `<commit>` | Shows differences between the working directory and a specific commit. |
| `<commit1> <commit2>` | Displays the differences between two commits, for example, `git diff HEAD^ HEAD` compares changes between the previous commit and the current commit. |
| `--staged` | Shows differences between the staged changes and the last commit. |
| `--cached` | Shows differences between the staged changes and the last commit (++same as `--staged`++), or between the index and a commit if a commit is specified. |
| `--cached <commit>` | Shows differences between the staged changes and the last commit, for example, can use `HEAD` as the reference. |
| `--name-only` | Lists the file names that have changed without showing the actual differences. |
:::

<br/>

5. **`git cat-file`**
:::spoiler _**args**_

| Argument | Function |
|-|-|
| `-t <object>` | Displays the type of the specified Git object (e.g., blob, tree, commit, or tag). |
| `-p <object>` | Pretty-prints the content of the specified Git object, showing the data in a readable format. |
| `-s <object>` | Displays the size of the specified Git object in bytes. |
| `-e <object>` | Checks if the specified Git object exists and returns no output if it does, or an error if it doesn't. |
| `--batch` | Reads object IDs from stdin and prints information about each object in bulk, useful for scripting. |
| `--batch-check` | Similar to `--batch` but only prints type and size information, without displaying content. |

> **Note:** Git object IDs are the result of a SHA-1 hash of the content, making them long. When referencing objects, you can use just the first few characters of the ID, as long as it's at least 4 characters. This means Git allows IDs between 4 and 40 characters.

> For example, a commit object might contain a reference to a tree object with an ID like `07c1321be49815d53eb2413f0ad5286010ebb6cc`. You can retrieve the tree's contents using `git cat-file -p <tree-id>`, as shown in the
:::

<br/>

:::spoiler 🖿 **Folder & File Types**
<br/>

| File Mode | Type | Description |
|-----------|------|-------------|
| `040000` | Directory | A directory in the repository. |
| `100644` | Regular File | A regular non-executable file. |
| `100664` | Regular File | A regular non-executable file that is group-writable. |
| `100755` | Regular Executable File | A regular executable file. |
| `120000` | Symbolic Link | A symbolic link. |
| `160000` | Gitlink | A submodule that links to another Git repository. |
:::

<br/>

## [Git Branch Management](#git-branch-management)
### **About Branching**
- **Branch:** A branch in Git represents an independent line of development. It allows you to work on different features or fixes simultaneously.
- **Working Branch:** The branch you are currently working on. Changes are made here before they are merged into other branches.
- **Main Branch:** Often referred to as `main` or `master`, it is the default branch where the codebase is stable.
- **Feature Branch:** Used to develop new features. These branches are usually merged back into the main branch once the feature is complete.
- **Release Branch:** Prepares for a release by allowing final adjustments and testing before merging into the main branch.
- **Hotfix Branch:** Used to quickly address critical issues in the production code. Once the fix is applied, it is merged into both the main branch and the development branches.

> **Visualizing Branches with Gitk**
> To visualize branches and history in a graphical interface, we can use `gitk`, which provides a simple way to view the commit history and branch structure on Git Bash.
>
> **Basic Command:**
> Open gitk in a new window, displaying all branches and commits.
> ```Bash []
> gitk --all &
> ```

<br/>

### **Branch Operation**
| Command | Operation | Description |
|-|-|-|
| `git branch <branch-name>` | Create Branch | Creates a new branch with the specified name. With `-d` argument can delete the branch. |
| `git checkout <branch-name>` | Switch Branch | Switches to the specified branch. <br/> With `-b` argument can create a new branch and switches to it. |
| `git switch <branch-name>` | Switch Branch | Alternative command to switch branches <br/> (Git 2.23+). |
| `git merge <branch-name>` | Merge Branches | Merges changes from the specified branch into the current branch. |
| `git merge --no-ff <branch-name>` | Merge with Commit | Merges with a merge commit, preserving the branch history. |
| `git merge --squash <branch-name>` | Squash Commits | Squashes all changes from the specified branch into a single commit. |

:::warning
**Warning:** Cannot delete the branch that you are currently on. Use `git branch -D <branch-name>` to force delete, but be cautious as it will remove the branch even if it has unmerged changes.
:::

:::spoiler **★ Detached HEAD**
<br/>

In Git, the `detached HEAD` state occurs when HEAD is ++pointing to a specific commit++ rather than a branch. This situation can arise in the following scenarios:

1. **Checking Out a Specific Commit**
- Using `git checkout <commit-hash>` to view or modify a specific commit will place you in a `detached HEAD` state.
2. **Checking Out a Tag or Older Branch**
- Using `git checkout <tag>` or `git checkout <branch>@{<n>}` will also result in a `detached HEAD` state as you are not on a named branch.
3. **Exploring Previous States**
- When switching to previous commits or restoring old states, HEAD may become detached from any branch.

**Implications:**
- In `detached HEAD` state, changes and commits are not associated with any branch.
- Commits made in this state ++can be lost++ if not explicitly saved or merged into a branch.
- To retain changes, create a new branch from the detached state using `git checkout -b <new-branch-name>`.

**Handling Detached HEAD:**
- **Create a New Branch:** If you want to keep your changes, create a new branch to save your work.
- **Return to a Branch:** Use `git checkout <branch-name>` to return to a named branch, and your HEAD will be reattached to that branch.
:::

<br/>

### **Rebasing**
| Command | Operation | Description |
|-|-|-|
| `git rebase <branch-name>` | Reapply Commits | Re-applies commits from the current branch on top of the specified branch. |
| `git rebase --interactive <branch-name>` | Interactive Rebase | Allows interactive rebasing to modify commits. |
| `git rebase --onto <new-base> <old-base> <branch>` | Rebase with New Base | Rebases a branch onto a new base. |

<br/>

### **Branching Workflows**
| Command | Operation | Description |
|-|-|-|
| `git flow feature start <feature-name>` | Start Feature | Starts a new feature branch in Gitflow. |
| `git flow release start <release-version>` | Start Release | Starts a new release branch in Gitflow. |
| `git flow hotfix start <hotfix-version>` | Start Hotfix | Starts a new hotfix branch in Gitflow. |
| `git push origin <branch-name>` | Push Branch | Pushes a branch to the remote repository. |
| `git clone <repository-URI>` | Fork and Clone | Fork the repo on GitHub, clone the fork, create branches, and submit pull requests. |
| `<Open a Pull Request> (GitHub web interface)` | Pull Request | Opens a pull request to merge changes into the main branch. |

<br/>

## [Git Remote Operations](#git-remote-operations)
- Adding Remote Repositories (`git remote add`)
- Pulling and Pushing (`git pull` & `git push`)
- Resolving Conflicts
- Managing Remote Branches

<br/>

5. [GitHub and Git](#github-and-git)
- Setting Up SSH Keys
- Creating and Managing Repositories
- Pull Request Workflow
- Integrating with GitHub Actions
6. [Advanced Git Operations](#advanced-git-operations)
- Interactive Staging (`git add -p`)
- Correcting Mistakes (`git reset` & `git revert`)
- Stashing Changes (`git stash`)
- Using Submodules
7. [Git and CI/CD](#git-and-cicd)
- Combining Git Flow with CI/CD
- Automated Testing and Deployment Workflows
- Setting Up CI/CD Pipelines in GitHub Actions
8. [Common Issues and Solutions](#common-issues-and-solutions)
- Rolling Back Versions
- Handling Rebase Conflicts
- Repairing Corrupted Repositories
9. [Resources and Further Learning](#resources-and-further-learning)
- Recommended Books
- Online Tutorials
- Communities and Discussion Forums

## Git and CI/CD
- **Combining Git Flow with CI/CD**: How to integrate Git Flow with CI/CD practices.
- **Automated Testing and Deployment Workflows**: Setting up automated workflows with GitHub Actions.
- **Setting Up CI/CD Pipelines in GitHub Actions**: Examples of YAML files for automating testing and deployment.

...

## Resources and Further Learning
- **Recommended Books**: A list of books to deepen your understanding of Git.
- **Online Tutorials**: Links to helpful online resources.
- **Communities and Discussion Forums**: Introduction to active Git and GitHub communities.

...