A. COMMON GIT COMMANDS

Here are some common Git commands used in daily version control tasks:

1. Basic Git Commands

git init: Initializes a new Git repository in the current directory.
```
git init
```
git clone: Clones an existing repository from a remote server.
```
git clone https://github.com/user/repo.git
```
git status Shows the current status of your working directory and staging area.
```
git status
```
git add: Stages changes (files or directories) for the next commit.
```
git add file.txt
git add .  # Stage all changes
```
git restore
Remove from the staging area without discarding the changes.
```
git restore --staged <file>
```
Restore a file to its last committed state:
```
git restore <file>
```
This will discard any changes made to since the last commit.

It can be used to:
- Unstage files that have been added to the staging area.
- Discard changes in a specific file or directory that haven't been committed yet.
It is often used instead of git checkout for modifying or undoing changes to files.
git commit: Records the staged changes in the repository with a message.
```
git commit -m "Commit message"
```
git push: Pushes the local commits to the remote repository.
```
git push origin branch-name
```
git pull: Fetches and integrates changes from the remote repository to the local branch.
```
git pull origin branch-name
```

2. Branching and Merging

git branch: Lists, creates, or deletes branches.

git branch        # List all branches
git branch new-branch  # Create a new branch
git branch -d old-branch  # Delete a branch

git checkout: Switches to a different branch or commit.

git checkout branch-name
git checkout -b new-branch  # Create and switch to a new branch

git merge: Merges a branch into the current branch.
```
git checkout main
git merge feature-branch
```

3. Remote Repositories

git remote: Manages the remote repository connections.

git remote -v  # List remote connections
git remote add origin https://github.com/user/repo.git  # Add a new remote

git fetch: Downloads changes from the remote repository but does not integrate them.
```
git fetch origin
```

4. Viewing History

git log: Displays the commit history.

git log        # Show commit history
git log --oneline  # Condensed history view
git log --graph --oneline --decorate  # Graphical commit history

git diff: Shows changes between commits, branches, or the working directory.

git diff                 # Changes not staged
git diff --staged        # Changes staged for commit
git diff branch1 branch2  # Compare two branches

5. Undoing Changes

git revert: Reverts a specific commit by creating a new commit that undoes it.
```
git revert commit-sha
```
git reset: (Use this with care, potentially cause losing recent updated) Resets the staging area or moves the branch pointer.
```
git reset file.txt        # Unstage a file
git reset --hard HEAD^    # Revert to the previous commit
```
Can be used with different options: (--mixed is default if we don't mention an option)
- --soft: Moves the HEAD pointer but keeps the changes in the staging area.
- --mixed (default): Moves the HEAD pointer and unstages the changes.
- --hard: Moves the HEAD pointer and discards all changes in the working directory.
- ^: Means number of commits we want to rollback if it was ^^^ we will rollback 3 prior commits.

6. Stashing Changes

git stash: Temporarily saves changes that are not ready to be committed.

git stash          # Stash current changes
git stash pop      # Apply the stashed changes and remove them from the stash
git stash list     # List all stashed changes

7. Tagging

git tag: Creates tags to mark specific commits, typically used for releases.

git tag v1.0         # Create a lightweight tag
git tag -a v1.0 -m "Version 1.0"  # Annotated tag
git push origin v1.0 # Push tag to remote

8. Collaboration

git rebase: Re-applies commits on top of another base tip, useful for linearizing commit history.
```
git checkout feature-branch
git rebase main
```
git cherry-pick: Applies a specific commit from one branch to another.
```
git cherry-pick commit-sha
```

These commands are foundational for working with Git in both solo and collaborative projects.

B. CONFLICTS

Resolving a Git Merge Conflict

Identify the conflict: After attempting a merge, Git will notify you of conflicts.
```
git status
```
This will list the files with conflicts.
Open the conflicted files: Look for conflict markers (<<<<<<<, =======,>>>>>>>) in the files.

<<<<<<< indicates the start of your changes.
======= separates your changes from the incoming changes.
>>>>>>> indicates the end of the incoming changes.

Resolve the conflict: Edit the file to combine changes or choose one version over the other. Remove the conflict markers after deciding.
Stage the resolved files:
```
 git add <file>
```
Continue the merge:
```
 git commit
```
If the merge was interrupted, you might need to use:
```
git merge --continue
```
Verify the merge: Ensure that the merge was successful and no further conflicts exist.
```
git status
```
Push the changes (if needed):
```
git push origin branch-name
```
Now the merge conflict should be resolved, and the merged changes are committed.

Resolving a GitHub Pull Request Conflict

Navigate to the Pull Request: Go to the repository on GitHub, and find the pull request (PR) with conflicts.
Check Conflict Details: GitHub will show a message indicating that the branch has conflicts. Click on the Resolve conflicts button to see the conflicting files.
Resolve Conflicts in the GitHub Editor: For each conflicting file, edit the content to resolve the differences directly in the GitHub web editor. Remove the conflict markers (<<<<<<<, =======, >>>>>>>) and ensure the code is correct.
Mark as Resolved: Once you have resolved the conflicts for all files, click Mark as resolved.
Commit the Changes: Click the Commit merge button to create a merge commit that resolves the conflicts.
Merge the Pull Request: After conflicts are resolved and committed, you can proceed to Merge the pull request into the target branch.

Now the pull request conflict is resolved, and changes are merged.

C. GIT FLOW OVERVIEW

Git Flow is a branching strategy for managing feature development, releases, and hotfixes in a structured and scalable way. It helps teams manage parallel development, collaborate efficiently, and handle releases and bug fixes smoothly. Here's a brief overview of the common Git Flow:

1. Main Branches

main (or master): The production-ready branch that contains the stable, deployed code. All releases are tagged here.
develop: The main development branch where the latest code for the next release is integrated. Features and fixes are merged into develop.

2. Supporting Branches

Git Flow uses additional branches for feature development, bug fixes, and releases. Each branch has a specific role:

Feature Branches (feature/):
- Used to develop new features or changes.
- Created from develop and merged back into develop once complete.
- Example: feature/new-login
Release Branches (release/):
- Used to prepare a new release.
- Created from develop when it’s feature-complete, allowing for final testing, bug fixes, and versioning before merging into main.
- Example: release/v1.0
Hotfix Branches (hotfix/):
- Used to fix critical bugs in production.
- Created from main and merged back into both main and develop to ensure the fix is applied to both branches.
- Example: hotfix/fix-payment-bug

3. Git Flow Workflow

Feature Development: Developers create a feature branch (feature/) from develop to work on new features. After completion, the feature is merged back into develop.
Releasing: Once develop is stable and ready for release, a release/ branch is created for final testing and adjustments. Once ready, it's merged into main (for production) and develop (to keep it updated).
Hotfixes: If a critical bug is found in production, a hotfix/ branch is created from main, fixed, and then merged into both main and develop to keep both updated.

4. Version Tags

After merging a release/ or hotfix/ into main, you tag the commit with a version number (e.g., v1.0) to mark the release.

Summary of Key Git Flow Commands

Start a feature:
```
git checkout -b feature/xyz develop
```

Finish a feature:

git checkout develop && git merge feature/xyz

Start a release:
```
git checkout -b release/v1.0 develop
```

Finish a release:

git checkout main && git merge release/v1.0

Start a hotfix:
```
git checkout -b hotfix/fix-bug main
```

Finish a hotfix:

git checkout main && git merge hotfix/fix-bug

Git Flow is ideal for teams that require a structured process for managing releases, features, and hotfixes, particularly in projects with regular production releases.

D. COMMON GIT FAQ

What is Git HEAD?

HEAD is a pointer that refers to the current commit or branch you are working on.
Typically, it points to the latest commit in your current branch.
When you make a new commit, HEAD moves forward to point to that new commit.
If you switch branches with git checkout, HEAD moves to point to the tip of the new branch.
In a "detached HEAD" state, HEAD points directly to a specific commit instead of a branch, which means you're not on any branch.

     git checkout branch-name  # HEAD points to the latest commit on 'branch-name'
     git checkout <commit-sha>  # Detached HEAD points directly to a specific commit

Difference between `git stash` and `git add`?

git stash:
- Temporarily saves changes in the working directory that are not yet ready to be committed.
- Allows you to switch branches or work on something else without losing the current work.
- Changes are moved to a stash stack and can be reapplied later with git stash pop or git stash apply.
- Does not affect the staging area (index).
```
git stash          # Stashes the current changes
git stash pop      # Applies and removes the most recent stash
```
git add:

Moves changes from the working directory to the staging area (index), preparing them to be committed.
Only staged changes will be included in the next git commit.
Does not save changes temporarily; it prepares them for a commit to the repository.

Summary:

Use git stash to temporarily save uncommitted changes without committing.
Use git add to stage changes that you intend to commit.

Differences between `git revert`, `git reset`, and `git checkout` ?

git revert:
- Creates a new commit that undoes the changes of a specific previous commit.
- Keeps the commit history intact, making it useful for reverting changes in a collaborative environment.
- Does not alter the commit history—just adds a new commit that negates the specified commit.
- Safe for use when changes have already been pushed to a shared repository.
git reset:
- Moves the branch pointer backward to a specific commit, potentially changing the working directory and staging area.
- Can modify the commit history (especially with --hard), making it suitable for local-only changes that you haven't shared yet.
- Different options like --soft, --mixed, and --hard control how much is reset.
- Can be risky to use on public branches, as it changes the commit history.
git checkout:
- Primarily used to switch between branches or to view the state of files at a particular commit.
- Does not alter commit history; it only changes the working directory or the branch you are working on.
- Can be used to create and switch to a new branch or to temporarily view old commits.
- In newer Git versions, git switch is recommended for switching branches, while git restore is used for restoring files.