‭ Distributed Version Control System (DVCS) is a type of version control system that allows‬

A
‭multiple contributors to work on a project concurrently, without necessarily being connected to a‬
‭central server. In a DVCS, each user has a complete copy of the entire repository, including its‬
‭full history, on their local machine.‬

-‭ **Decentralized Architecture**: Each user's local repository is a full and independent copy of‬
‭the project, containing the entire history of changes.‬

-‭ **Offline Capabilities**: Users can work offline since they have a complete local copy of the‬
‭repository, enabling asynchronous collaboration from anywhere.‬

-‭ **Enhanced Collaboration**: DVCS allows seamless sharing of changes between team‬

‭members through cloning, fetching, pushing, and pulling changes between repositories.‬

-‭ **Branching and Merging**: DVCS excels in branching and merging workflows, enabling users‬
‭to create branches, work independently, and merge changes efficiently.‬

-‭ **Redundancy and Backup**: Every user having a full copy of the repository ensures‬
‭redundancy and backup. If a central server fails, users can continue working with their local‬
‭copies, preserving the repository's history.‬
‭Ex: Git, Bazaar, and Mercurial.‬

‭ entralized Version Control System (CVCS) is a type of version control system where there is a‬
C
‭single central repository that stores the entire history of the project and manages all changes‬
‭made by contributors.‬

-‭ **Centralized Repository**: CVCS has a single central repository storing all project files and‬
‭version history.‬

-‭ **Dependency on Central Server**: Users need to be connected to the central server for‬
‭version control operations, leading to potential bottlenecks and single points of failure.‬

-‭ **Limited Offline Capabilities**: All version control operations rely on the central server, limiting‬
‭offline work and requiring synchronization once reconnected.‬

-‭ **Collaboration and Access Control**: CVCS provides access control mechanisms for‬
‭managing user permissions and facilitates collaboration through centralized management of‬
‭files and version history.‬

-‭ **Branching and Merging**: CVCS supports branching and merging but may have limitations‬
‭compared to distributed version control systems, with branches managed within the central‬
‭repository context.‬
‭Ex : subversion and concurrent version.‬
‭MERGE CONFLICT :‬

I‭t is an event that occurs when git is unable to automatically solve the conflict due to conflicting‬
‭files or differences in code between two commits and requires human intervention to resolve this‬
‭issue.‬
‭1. **Conflict Occurs**: Git notifies you when merging if it finds conflicting changes in the same‬
‭part of a file between branches.‬

‭ . **Open Files**: Use a text editor to open the conflicted files. Git marks the conflicting sections‬
2
‭with special markers.‬

‭ . **Resolve Conflict**: Edit the conflicting sections to keep the changes you want, remove the‬
3
‭conflict markers.‬

‭4. **Save Changes**: Save the files after resolving the conflict.‬

‭5. **Stage Changes**: Use `git add` to stage the resolved files.‬

‭ . **Complete Merge**: Use `git merge --continue` or `git commit` to complete the merge‬
6
‭process.‬

‭7.‬‭verify and Push Changes: After resolving the conflict and completing the merge, verify‬
t‭ hat everything is as expected and push the changes to the remote repository if‬
‭necessary.‬

‭ it show commit_hash : show the information abt that commit ID‬

g
‭git show : info abt last commit‬
‭1. **Repository**:‬
‭- A repository, or repo, in Git is a collection of files and version history for a project. It‬
‭contains all the files, directories, and metadata related to the project, as well as the‬
‭entire history of changes made to those files over time.‬

‭2. **Commit**:‬
‭- A commit in Git represents a snapshot of the project at a specific point in time. It‬
‭includes changes to one or more files, along with a commit message describing the‬
‭changes. Commits are the building blocks of the version history in Git.‬

‭3. **SCM**:‬
‭- SCM stands for Source Control Management, which is the process of managing‬
‭changes to source code over time. Git is an example of a distributed SCM system,‬
‭allowing multiple contributors to work on a project concurrently while keeping track of‬
‭changes made to the codebase.‬

‭4. **Working Directory**:‬

‭- The working directory, also known as the working tree, is the directory on your local‬
‭machine where you are currently working on files in a Git repository. It contains the‬
‭actual files and directories of the project, including any changes you've made since the‬
‭last commit.‬

‭5. **Checkout**:‬
‭- Checkout is the process of switching between different branches or commits in a Git‬
‭repository. When you check out a branch or commit, Git updates the files in your‬
‭working directory to reflect the state of the code at that specific point in time.‬

‭6. **Branching**:‬
‭- Branching in Git allows you to diverge from the main line of development and work on‬
‭new features or bug fixes in isolation from the main branch. Each branch represents an‬
‭independent line of development, and changes made in one branch do not affect other‬
‭branches until they are merged together.‬

‭7. **Staging Area**:‬

‭- The staging area, also known as the index, is an intermediate area in Git where‬
‭changes to files are prepared (staged) before being committed to the repository. It‬
‭allows you to selectively choose which changes to include in the next commit.‬

‭8. **SHA**:‬
 -‭ SHA, or Secure Hash Algorithm, is a cryptographic hash function used by Git to‬
‭generate unique identifiers for commits, files, and other objects in a Git repository. The‬
‭SHA hash, also called the commit hash or object ID, uniquely identifies each commit in‬
‭the repository and is used for referencing commits in Git commands and operations.‬

‭●‬ U ‭ se‬‭git push -u origin main‬‭the first time you push‬‭commits from a local‬
‭branch to a remote repository to set up tracking.‬
‭●‬ ‭Use‬‭ git push <repo_name> <branch_name>‬‭to push commits‬‭to a specific‬
‭branch on a specific remote repository without setting up tracking.‬

‭ emote Repository :‬
R
‭It serves as a centralized storage location for your project's codebase and allows‬
‭collaboration among multiple developers by providing a centralized location to push and‬
‭pull changes.‬
‭GitHub,GitLab‬

‭ ommon Commands:‬
C
‭git remote add <name> <url>: Adds a new remote repository with the specified name‬
‭and URL.‬

‭ it remote -v: Lists all remote repositories associated with the current repository along‬
g
‭with their URLs.‬

‭ it push <remote_name> <branch_name>: Pushes local commits to the specified branch‬

g
‭of the remote repository.‬

‭ it pull <remote_name> <branch_name>: Fetches changes from the remote repository‬

g
‭and merges them into the current branch.‬

‭ it fetch <remote_name>: Fetches changes from the remote repository without merging‬
g
‭them into the local branch.‬

‭ it remote show <remote_name>: Displays information about the specified remote‬

g
‭repository, including fetch and push URLs‬
‭.gitignore file :‬
‭-‬ ‭The .gitignore file is used in Git to specify intentionally untracked files that Git should‬
‭ignore.‬
‭-‬ ‭These files are typically generated as a result of the build process, editor configurations,‬
‭or other temporary files that do not need to be tracked by version control.‬
‭-‬ ‭The .gitignore file helps to keep the repository clean and prevents unnecessary files from‬
‭being included in commits.‬

‭Different parameters of the .gitignore file include:‬

‭ ile Patterns: You can specify file patterns to ignore specific files or directories. These‬
F
‭patterns can include wildcards to match multiple files or directories.‬

‭For example:‬

‭*.log ignores all files with the .log extension.‬

‭ uild/ ignores the entire build directory.‬
b
‭temp/*.tmp ignores all .tmp files in the temp directory.‬

‭ egation: You can use ! to negate patterns and include files that would otherwise be‬
N
‭ignored.‬
‭For example:‬

‭!important.log includes the important.log file even though *.log is ignored.‬

‭ Ignore doc/notes.txt‬
#
‭doc/notes.txt‬

‭ Exclude doc/server/arch.txt‬
#
‭!doc/server/arch.txt‬
‭REBASING :‬

‭ ebasing in Git is the process of moving or reapplying a series of commits from one‬
R
‭branch onto another branch's tip. Instead of merging the changes, rebasing effectively‬
‭rewrites the commit history of the branch being rebased.‬

‭1. **Git Rebase**:‬

‭- `git rebase` moves or reapplies commits from one branch onto another branch's tip.‬
‭- It creates a linear history without merge commits by rewriting the commit history of the‬
‭branch being rebased.‬
‭- It's useful for maintaining a clean and linear history, especially in collaborative projects where‬
‭feature branches are frequently merged into a main branch.‬
‭- Use `git rebase` when you want to incorporate changes from one branch onto another while‬
‭keeping a linear history.‬

‭2. **Git Merge**:‬

‭- `git merge` creates a new merge commit that combines the changes from one branch into‬
‭another.‬
‭- It preserves the entire history of both branches, including their individual commit timelines.‬
‭- It explicitly shows when and where branches were merged, making it clear how different‬
‭lines of development came together.‬
‭- Use `git merge` when you want to merge changes from one branch into another and‬
‭preserve the original commit history of both branches.‬

‭ tashing in Git is a feature that allows you to temporarily shelve changes in your working‬
S
‭directory so that you can work on something else without committing those changes to your‬
‭repository. It's useful when you need to switch to a different branch or work on a different task‬
‭without committing your current changes.‬

‭Common commands used for stashing are:‬

‭1. **git stash**:‬

‭- This command saves your current modifications to the stash, which is a temporary storage‬
‭area. It reverts the changes in your working directory to the last commit state.‬

‭2. **git stash list**:‬

‭- This command lists all stashed changes in your repository. It shows the index and‬
‭description of each stash entry.‬
‭3. **git stash apply**:‬
‭- This command applies the most recent stash entry to your working directory, reapplying the‬
‭changes you stashed. It does not remove the stash entry from the stash list.‬

‭4. **git stash pop**:‬

‭- This command applies the most recent stash entry to your working directory and removes it‬
‭from the stash list. It's equivalent to running `git stash apply` followed by `git stash drop`.‬

‭5. **git stash drop**:‬

‭- This command removes the most recent stash entry from the stash list. It's useful when you‬
‭no longer need the stashed changes and want to clean up the stash list.‬

‭6. **git stash clear**:‬

‭- This command removes all stash entries from the stash list. It's useful when you want to‬
‭clear the stash list completely.‬