0% found this document useful (0 votes)
4 views10 pages

About Git

Git is a distributed version control system that enables developers to track and manage changes to source code, allowing collaboration without overwriting each other's work. It provides features like version tracking, branching, and merging, making it essential for modern software development. Git was developed by Linus Torvalds in 2005 to manage the Linux kernel's development, and it has become an industry standard for version control.

Uploaded by

Kavitha Reddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views10 pages

About Git

Git is a distributed version control system that enables developers to track and manage changes to source code, allowing collaboration without overwriting each other's work. It provides features like version tracking, branching, and merging, making it essential for modern software development. Git was developed by Linus Torvalds in 2005 to manage the Linux kernel's development, and it has become an industry standard for version control.

Uploaded by

Kavitha Reddy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

GIT

What is Git :

 Git is developers tool enabling developers track and manage changes


to source code over time. It allows multiple people to work on the same
project without overwriting each other’s work. Git keeps a history of
every change, so you can review, undo, or merge changes as needed.
 Git is an open-source distributed version control system (DVCS)

Why is Git called a Version Control System?

A Version Control System (VCS) is a tool that records changes to files


over time so that you can recall specific versions later. Git is called a VCS
because it:

 Keeps track of every change to your code.

 Allows you to revert back to previous versions.

 Helps you collaborate by managing changes from multiple


contributors.

 Manages branches to work on different features or fixes without


affecting the main codebase.

Types of Version Control Systems

There are mainly two types of VCS:


1. Centralized Version Control System (CVCS):
o Has a single central server that stores all the versioned files.
o Developers check out files from this central place.
o Examples:
 Subversion (SVN)
 CVS (Concurrent Versions System)
2. Distributed Version Control System (DVCS):
o Every developer has a complete copy of the entire repository
including history.
o You can work offline and later sync changes.
o Examples:
 Git
 Mercurial
 Bazaar
Why Use Git?

Git offers numerous benefits to developers and development teams:

1. Version Control: Git helps in tracking changes, allowing you to go


back to previous states if something goes wrong.

2. Collaboration: It enables multiple developers to work on a project


simultaneously without interfering with each other’s work.

3. Backup: Your entire project history is saved in a Git repository,


providing a backup of all versions.

4. Branching and Merging: Git’s branching model allows you to


experiment with new features or bug fixes independently from the
main project.

5. Open Source Projects: Most open source projects use Git for version
control. Learning Git allows you to contribute to these projects.

6. Industry Standard: Git is widely used in the software industry,


making it an essential skill for developers.

Who developed Git and why?

Git was developed by Linus Torvalds in 2005 to help manage the


development of the Linux kernel. It was created because the previous
version control system, BitKeeper, was no longer freely available, and the
Linux community needed a fast, reliable, and distributed system to handle
their large codebase and many contributors.

Fundamental Git commands

1. git init (initialize a repository)


 Initializes a new Git repository in your current directory.
 # git init
2. git clone (copy a remote repository)
 Copies an existing remote repository to your local machine.
 # git clone <repository_url>
3. git add (stage changes)
 Adds changes (new files, modifications) to the staging area,
preparing them to be committed.
 # git add <file_name> -> add specific file
 # git add . -> add all changes in current directory
4. git commit (save changes)
 Records the staged changes in the repository with a descriptive
message.
 # git commit -m "Commit message describing the changes"
5. git status (check current changes)
 Shows the status of changes in your working directory and staging
area.
 # git status
6. git log (shows commit history)
 Displays the history of commits in the repository.
 # git log
7. git push (upload changes to remote)
 Uploads your local commits to a remote repository.
 # git push origin <branch_name>
8. git pull (fetch and merge remote changes)
 Fetches and merges changes from the remote repository to your
local branch.
 # git pull
9. git branch (manage branches)
 Lists branches or creates a new branch.
 # git branch -> list all branches
 # git branch <branch_name> -> create a new branc
10. git checkout (switch branches)
 Switches to a different branch or restores files.
 # git checkout <branch_name> -> switch branches
 # git checkout <file_name> -> discard changes in a file
11. git merge (combine branches)
 Merges another branch into the current branch.
 # git merge <branch_name>

12. git remote


 Manages remote repository connections.
 # git remote -v -> list remote repositories
 # git remote add <name> <url> -> add new remote
 # git remote remove <name>
 # git remote rename <oldname> <newname>

Working with Git

The Git workflow involves the following steps:


1. Initializing a Repository: When you initialize a folder with Git, it
becomes a repository. Git logs all changes made to a hidden folder
within that repository.

2. Staging Changes: Git marks modified files as “staged.” Staging


prepares changes for a snapshot you want to keep.

3. Committing Changes: Once staged changes are satisfactory, commit


them. Git maintains a complete record of each commit.

4. Create and switch branches: Use "git branch" to create a new


branch, and "git checkout" to switch to a different branch.

5. Merge branches: Use "git merge" to merge changes from one branch
into another. This combines the commits from both branches into a
single branch.

6. Push and pull changes: Use "git push" to upload your local commits
to a remote repository, and "git pull" to fetch and integrate remote
changes into your local repository.

What is Branching in Git:

 A branch in Git is essentially a pointer to a snapshot of your changes.


We usually creating branch to work on new fixes or bugs without
affecting the main branch of code.
 changes in one branch don’t affect others until you explicitly merge
them.
 We use branches to:
 Isolate work: Work on new features or fixes without disrupting the
stable code.
 Collaboration: Multiple people can work on different branches
simultaneously.
 Experiment safely: Try risky changes without affecting the main
code.
 Organize development: Keep production-ready code (e.g., main
or master branch) clean.
 Primary branch is Master branch /main branch usually production-
ready branch
 Feature branch is nothing but copy of main branch to wok on

Commands :

1. git branch <branch-name>


creates a new branch in repo
2. git checkout <branch-name>
switch to a branch
3. git checkout -b <branch-name> or git switch -c <branch-
name>
creates a new branch and switches to branch immediately
4. git branch -d <branch-name>
deletes the branch Once merged and no longer needed
5. git branch -D <branch-name>
deletes the branch forcefully without merged

What is Merging in Git:

 Merging is the process of taking the changes from one branch and
integrating them into another branch. It’s how you combine the work
done separately in different branches back into a single branch.
 For example, if you’ve been working on a feature branch and want to
bring those changes into the main branch, you merge the feature
branch into main.
 When you merge, Git looks at the history of both branches and tries to
automatically combine changes.
 If the changes were made in different parts of the files , Git
merges them smoothly.
 If the same part of the code was changed differently in both
branches, Git will raise a merge conflict, which you need to
resolve manually.
 Workflow:
 Switch to branch you want to merge into
# Git checkout master
 Run the merge command, specifying the branch you want to
merge from
# git merge mybranch2
 Fix the merge conflits if arises
 Stage the clean and fixed file
#git add .
 Commit the merge to complete
# git commit
 Git will either Complete the merge automatically if there are no
conflicts, or Pause and ask you to resolve conflicts.

Commands :

 Git merge <branch-name>


 It merges the changes from the specified branch (<branch-
name>) into your current branch.
 be on the branch that you want to bring changes into before
running this command.
What are Merge Conflicts :

Merge conflicts happen when Git tries to combine two branches, but finds
that the same parts of the same files have been changed differently in each
branch. Since Git can’t automatically decide which change to keep, it asks
you to manually fix the conflict.

Why do conflicts happen?

Because two branches modified the same line(s) of code or close parts in
different ways.

How does Git show conflicts?

In the conflicted file, Git adds special markers to highlight the conflicting
sections, like this:

When you encounter merge conflicts in Git, your code editor or Git tools
often give you options to resolve the conflict by choosing:

 Accept Current Change (also called Accept Ours) — When you


want to keep your existing code and ignore the incoming conflicting
change.
 Accept Incoming Change (also called Accept Theirs) — When you
want to overwrite your code with the changes from the other branch.
 Accept Both Changes — When both changes are useful and you
want to keep them both (maybe they add different functionality or
info).

conflict markers :

refers to <<<<<<<, =======, >>>>>>


When Git can’t automatically merge changes, it inserts special markers
directly into the conflicting file to highlight the differences.
 <<<<<<< HEAD
This marks the start of the section that contains your current
branch’s version of the code (called HEAD).
 =======
This is the separator between your branch’s version and the incoming
branch’s version.
 >>>>>>> branch-name
This marks the end of the conflicting section, showing the branch
name you are merging from (called the incoming branch).

Remote Repositories PUSH ,PULL


1. git push
Pushes your current local branch to the remote branch it is tracking.
2. git push origin <branch-name>
Pushes a specified local branch to the remote origin.
3. git pull
Fetches changes from the remote branch your current local branch is
tracking and merges them into your current branch.
4. git pull origin master
Fetches and merges master branch from origin into your current
branch.
Reference :
 Unstaged Changes you made but haven’t
changes: prepared yet
 Staged Changes you have added to the
changes: staging area
 Commit: Snapshot of staged changes saved to repo
 You stage changes by running : git add .
 If you don’t run git add, those changes stay unstaged and won’t be
part of your next commit.
What is a Pull Request?
 A Pull Request is a way to propose changes you've made in your
branch to be merged into another branch, usually in a remote
repository
 The pull request compares the source branch changes against the
target branch.
The pull request lets others:
 Review your changes
 Discuss the code with comments
 Suggest improvements or request changes
Workflow:
 you create a branch (e.g., feature-x) and make your changes
locally.
 You push your branch to the remote repository (e.g.,
origin/feature-x).
 On the hosting platform you open a pull request from your branch
(feature-x) into a target branch (usually main or master).
 The source branch is the branch where your changes live — the
branch you made your new commits on. It’s the branch you want to
merge from.
 The target branch is the branch where you want your changes
to be merged into.
 Once approved, your changes are merged into the target branch.

You might also like