Branch Naming: Use descriptive branch names to make it clear what the branch is for (e.g., feature-login, bugfix-issue123, release-v1.0).
Branch Lifecycle: Typically, you'll create a branch to work on a new feature or bug fix, merge it back into the main branch when done, and then delete it to keep your branch list clean.
Remote Branches: Working with remote branches involves using git fetch, git pull, and git push to synchronize changes between local and remote repositories.
Common Use Cases
-- List All Branches
-- Lists all local branches, highlighting the current branch with an asterisk (*)
git branch
-- Create a New Branch
-- Creates a new branch named new-branch from the current HEAD
git branch new-branch
-- Create a New Branch from a Specific Commit
-- Creates a new branch named new-branch starting from the specified commit SHA
git branch new-branch commit-sha
-- Delete a Branch
-- Deletes the specified branch. If the branch has unmerged changes, use the -D option to force delete.
git branch -d old-branch
-- Rename a Branch
-- Renames a branch from old-name to new-name
git branch -m old-name new-name
-- List All Remote Branches
-- Lists all branches from the remote repository
git branch -r
-- List Both Local and Remote Branches
-- Lists all branches, both local and remote
git branch -a
Example Workflow
-- 1. Check Current Branches
git branch
-- 2. Create a New Feature Branch
git branch feature-branch
-- 3. Switch to the New Branch
git checkout feature-branch
-- 4. Work on the Feature Branch and Commit Changes
git add .
git commit -m "Work on feature"
-- 5. Merge the Feature Branch into Main
git checkout main
git merge feature-branch
-- 6. Delete the Feature Branch After Merging
git branch -d feature-branch
Example Output
When running git branch
git checkout
Description
It is used for switching between branches, creating new branches, and checking out specific commits or files from your Git history. Although many of its functions have been replaced or supplemented by git switch and git restore, git checkout is still a fundamental Git command with versatile uses.
If we want to checkout remote branch i.e. create new branch and add remote origin reference to it, then create a new branch in remote (Gitlab etc) via UI and do git pull in local to get reference to remote branch. Then we will be able to run checkout remote branch and git push, pull etc will work.h
Using git switch and git restore: For switching branches and restoring files, Git introduced git switch and git restore to make commands more intuitive.
Switch branches: git switch branch-name
Create and switch to a new branch: git switch -c new-branch
Restore files: git restore path/to/file
Detached HEAD State: Checking out a specific commit (not a branch) puts us in a detached HEAD state. Any commits made in this state are not associated with any branch and can be lost if not handled properly. See the detached head workflow below.
Example Workflows
Workflow involving creation of new branch
-- Check Current Branch
git branch
-- Create and Switch to a New Feature Branch
git checkout -b new-feature-branch
-- Work on the Feature and Commit Changes
echo "New feature" > feature.txt
git add feature.txt
git commit -m "Add new feature"
-- Switch Back to Main Branch
git checkout main
-- Merge Feature Branch into Main
git merge feature-branch
-- Delete Feature Branch
git branch -d feature-branch
Workflow involving detached head and how to recover
-- Enter Detached HEAD State
-- Replace commit-sha with the SHA-1 hash of the commit we want to check out. This puts in a detached HEAD state.
git checkout commit-sha
-- Verify Detached HEAD State
-- We will see a message indicating that you are in a detached HEAD state
git status
-- Sample message -> HEAD detached at commit-sha
-- Work in Detached HEAD State
-- Make changes and commit them if needed. Remember, these commits are not on any branch yet.
echo "Changes in detached HEAD state" > file.txt
git add file.txt
git commit -m "Commit in detached HEAD state"
-- Create a New Branch from Detached HEAD State
-- If we want to keep the changes and not lose them, we should create a new branch from the detached HEAD state
-- This command creates a new branch named new-branch starting from the current commit and switches to it.
git checkout -b new-branch
-- Verify New Branch
-- With this we will see that we are now on the new-branch
git branch
-- Switch Back to Main Branch
-- If we decide not to keep the changes made in the detached HEAD state, we can simply switch back to an existing branch (e.g., main):
-- This will leave our detached HEAD state and switch back to the main branch
git checkout main
-- Verify Branch Switch
git status
Detached HEAD State: Be cautious when working in a detached HEAD state. If we make commits and do not create a new branch, these commits can be lost when we switch branches.
Example Output
When running git checkout branch-name
When creating and switching to a new branch with git checkout -b new-branch
git merge
Description
It is used to combine changes from different branches into a single branch. This is an essential feature for collaborative workflows, where multiple contributors work on different features or fixes in separate branches and then need to integrate these changes into a main branch.
Fast-forward Merges: These occur when the current branch has no new commits since the branch being merged was created, making it unnecessary to create a merge commit.
Three-way Merges: These occur when both branches have new commits since the last common ancestor, requiring Git to create a merge commit to combine the changes.
Merge Conflicts: Conflicts arise when changes in the two branches overlap. Git marks these conflicts in the files, and they must be resolved manually.
Usage
git merge [<options>] <branch>
<branch>: The branch that we want to merge into your current branch.
Options
--no-ff: Creates a merge commit even if the merge resolves as a fast-forward. This preserves the feature branch's history.
--ff-only: Ensures that the merge can only happen if it's a fast-forward merge. If not, the merge is aborted.
-squash: Combines all changes from the branch being merged into a single commit on the target branch.
-m <message>: Allows you to specify a commit message for the merge commit.
Fast-forward Merge: If the current branch has not diverged from the branch being merged, Git simply moves the current branch pointer forward.
Three-way Merge: If the branches have diverged, Git performs a three-way merge using the common ancestor of the two branches. This can result in merge conflicts that need to be resolved manually.
Common Use Cases
-- Merge a Feature Branch into Main
-- This merges feature-branch into the main branch
git checkout main
git merge feature-branch
-- Merge and Create a Merge Commit
-- This forces a merge commit, even if a fast-forward merge is possible. This is useful for preserving the history of feature branches.
git merge --no-ff feature-branch
-- Abort a Merge in Progress
-- This aborts the merge process and returns the branch to its pre-merge state.
git merge --abort
Example Workflow
-- Create a Feature Branch and Switch to It
git checkout -b feature-branch
-- Make Changes and Commit
echo "New feature" > feature.txt
git add feature.txt
git commit -m "Add new feature"
-- Switch Back to Main Branch
git checkout main
-- Merge the Feature Branch into Main
git merge feature-branch
Example Output
When running git merge feature-branch
If a merge commit is created (for a three-way merge)
Merge Conflicts
If there are conflicting changes in the branches being merged, Git will highlight these conflicts, and we'll need to resolve them manually. After resolving conflicts, we need to stage the changes and complete the merge with -
git add .
git commit
Resolve Git Merge Conflicts
Merge conflicts occur when changes from different branches interfere with each other and Git can't automatically combine them. Resolving merge conflicts involves identifying conflicting changes, deciding which changes to keep, and then completing the merge process.
Example Workflow to Resolve Merge Conflicts
----------- Prepare our Branches (main and feature)
-- Initialize a new Git repository
git init conflict-demo
cd conflict-demo
-- Create and switch to the main branch
git checkout -b main
-- Create a sample file and commit it
echo "Line 1" > example.txt
git add example.txt
git commit -m "Initial commit on main"
-- Create and switch to the feature branch
git checkout -b feature
-- Make changes to the file in the feature branch
echo "Line 2 from feature" >> example.txt
git add example.txt
git commit -m "Add Line 2 from feature"
-- Switch back to the main branch
git checkout main
-- Make conflicting changes to the file in the main branch
echo "Line 2 from main" >> example.txt
git add example.txt
git commit -m "Add Line 2 from main"
-----------
-- Merge the Feature Branch into Main
-- Attempt to merge the feature branch into the main branch, which will result in a conflict.
git merge feature
-- Git Identifies Conflicts
-- Git will detect conflicts and pause the merge process. We will see output like this
# Auto-merging example.txt
# CONFLICT (content): Merge conflict in example.txt
# Automatic merge failed; fix conflicts and then commit the result.
-- Check the Status
-- Verify the status to see which files are in conflict
git status
#On branch main
#You have unmerged paths.
# (fix conflicts and run "git commit")
# (use "git merge --abort" to abort the merge)
# Unmerged paths:
# (use "git add <file>..." to mark resolution)
# both modified: example.txt
-- Open and Resolve Conflicts
-- Open the conflicted file (example.txt) in a text editor. Git will mark the conflicts like this
# Line 1
# <<<<<<< HEAD
# Line 2 from main
# =======
# Line 2 from feature
# >>>>>>> feature
-- Resolve the conflict by deciding which lines to keep, modify, or combine. For example, we qcould resolve it to:
-- Save the file after resolving the conflict.
# Line 1
# Line 2 from main
# Line 2 from feature
-- Add the Resolved File
-- After resolving conflicts, mark the file as resolved by adding it to the staging area.
git add example.txt
-- Complete the Merge
-- Commit the resolved changes to complete the merge
git commit -m "Resolve merge conflict between main and feature"
-- Verify the Merge
-- Check the status and log to ensure the merge is completed successfully.
git status
git log --oneline --graph
Tips for Resolving Conflicts
Use a Merge Tool: Tools like kdiff3, meld, or IDE-integrated tools can help visualize and resolve conflicts.
Commit Often: Smaller, frequent commits make it easier to resolve conflicts.
Communicate: Coordinate with your team to avoid overlapping changes.
Test Thoroughly: After resolving conflicts, ensure that the project works as expected.
git switch
Description
It is used to switch branches or restore working tree files. It was introduced to provide a more intuitive and focused way to switch branches compared to git checkout, which can be confusing due to its multiple functionalities.
Switches to an Existing Branch: Changes the current working branch to another specified branch.
Creates and Switches to a New Branch: Creates a new branch and switches to it in one command.
Detached HEAD State: Using git switch --detach commit-sha puts you in a detached HEAD state, meaning you are not on a branch. Any commits made in this state are not associated with any branch and can be lost if not handled properly.
Switch vs. Checkout: While git switch focuses on changing branches, git checkout can also be used to check out files or commits. Git introduced git switch and git restore to make these operations more intuitive:
git switch for switching branches.
git restore for restoring files.
Common Use Cases
-- Switch to an Existing Branch
-- This switches the current working branch to branch-name.
-- This attempts to switch to branch-name even if there are uncommitted changes in the current branch.
-- If the switch cannot be completed due to conflicts, Git will inform and we must resolve these before switching.
git switch branch-name
-- Create and Switch to a New Branch
-- This creates a new branch named new-branch and switches to it.
git switch -c new-branch
Example Workflow
-- Check Current Branch
git branch
-- Create and Switch to a New Feature Branch
git switch -c feature-branch
-- Work on the Feature and Commit Changes
echo "New feature" > feature.txt
git add feature.txt
git commit -m "Add new feature"
-- Switch Back to Main Branch
git switch main
Example Output
When running git switch branch-name
When creating and switching to a new branch with git switch -c new-branch
git restore
Description
It is used to restore working tree files. It was introduced to provide a more focused way to undo changes and restore files compared to the multi-functional git checkout command.
Restores Files to Their Last Committed State: Discards changes in the working directory, reverting files to their state at the last commit.
Unstages Files: Moves files from the staging area back to the working directory.
Restores Files from a Specific Commit: Reverts files to their state at a specific commit.
Safety: git restore is a safer way to handle file restoration compared to git checkout, as it is more explicit in its intentions and helps avoid unintended switches between branches or commits.
Common Use Cases
-- Discard Local Changes in the Working Directory
-- Reverts the specified file to its state at the last commit.
git restore <file>
-- Unstage Changes
-- Removes the specified file from the staging area, keeping the changes in the working director
git restore --staged <file>
-- Restore a File from a Specific Commit
-- Restores the specified file to its state in the specified commit.
git restore --source=<commit> <file>
Example Workflow
-- Modify a File
echo "Some changes" > file.txt
-- Check the Status
git status
# On branch main
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git restore <file>..." to discard changes in working directory)
# modified: file.txt
-- Discard Changes in the Working Directory
-- This reverts file.txt to its state at the last commit
git restore file.txt
-- Stage the File and Then Unstage It:
git add file.txt
git restore --staged file.txt
-- Restore a File to a Specific Commit
git restore --source=commit-sha file.txt
Example Output
When running git restore file.txt, we might see no output if the command succeeds, and the file will be reverted to its last committed state. If there are errors, such as the file not being in the specified source, Git will inform you of the issue.
git rebase
Description
It is used to integrate changes from one branch into another. It is an alternative to merging, but instead of creating a new commit that combines the changes from the branches, rebasing moves or reapplies commits from one branch onto another. This results in a cleaner, linear project history.
Usage
git rebase [<options>] [<upstream>] [<branch>]
Options
-i or --interactive: Starts an interactive rebase session where you can edit, reorder, squash, or drop commits.
--continue: Continues the rebase process after conflicts have been resolved.
-skip: Skips the current commit and proceeds with the rebase
--abort: Aborts the rebase process and resets the branch to its state before the rebase started.
--onto <newbase>: Rebases the commits onto a new base.
git rebase -i main
git rebase --continue
git rebase --skip
git rebase --abort
git rebase --onto newbase oldbase feature-branch
What It Does
Moves Commits: Takes the commits from your current branch and applies them onto another branch.
Reapplies Commits: The commits are reapplied one by one on top of the new base commit.
Linear History: Rebasing is often used to maintain a linear project history, making it easier to follow and review.
Rewriting History: Rebase changes commit hashes, effectively rewriting history. This can cause issues if you rebase commits that have already been pushed to a shared repository.
Interactive Rebase: Interactive rebasing is powerful for cleaning up commits, such as combining multiple commits into a single commit or editing commit messages
Common Use Cases
-- Rebase Current Branch onto Another Branch
-- Moves the commits from feature-branch to the tip of main
git checkout feature-branch
git rebase main
-- Interactive Rebase
-- Allows to edit, squash, reorder, or drop commits during the rebase process
git rebase -i main
-- Continue a Rebase After Resolving Conflicts
-- After resolving conflicts during a rebase, this command continues the rebase process
git rebase --continue
-- Skip a Commit during a Rebase
-- Skips the current patch (commit) and proceeds with the rebase
git rebase --skip
-- Abort a Rebase in Progress
-- Stops the rebase process and resets the branch to its original state before the rebase started.
git rebase --abort
Example Workflow
-- Check Current Branch
git branch
-- Rebase Feature Branch onto Main
git checkout feature-branch
git rebase main
-- Resolve Any Conflicts:
-- If conflicts arise, Git will pause the rebase and mark the conflicts in the files.
-- We need to resolve these conflicts manually.
-- Continue the Rebase
git add .
git rebase --continue
-- If Another Conflict Arises
-- Repeat the conflict resolution steps and continue the rebase until it completes.
Example Output
When running git rebase main
If a conflict occurs, Git will provide instructions.
Rebase vs Merge
Feature
Git Rebase
Git Merge
Purpose
Reapply commits on top of another base branch
Combine the histories of two branches
History
Creates a linear, cleaner history
Creates a history with merge commits
Commit Hashes
Changes commit hashes (rewrites history)
Preserves commit hashes
Usage Scenario
Clean up feature branch before merging into main
Regularly integrating changes from one branch to another
Conflicts
Must be resolved during the rebase process
Must be resolved during the merge process
Branch State After
Current branch starts from the tip of the target branch
Current branch includes a merge commit
Merge Commits
No merge commits; commits are replayed individually
Creates a merge commit
Local/Remote
Best for local branch integration
Commonly used for both local and remote integration
Impact on History
Rewrites commit history
Adds to commit history
Interactive Option
Supports interactive rebase to edit, squash, reword commits
Does not support interactive merges
Conflicts Resolution
Conflicts need to be resolved as they appear and then continue
Conflicts resolved once during merge
Usage Command
git rebase target-branch
git merge target-branch
Typical Use Case
Clean up commit history before merging feature branches
Regular updates and integration of branches
Visual History
Linear and simplified
Branched with merge commits
git tag
Description
It is used to create, list, delete, and verify tags in Git. Tags are used to mark specific points in the repository’s history, typically used for marking release points (e.g., v1.0.0, v2.0.0).
Usage
---- Creating a Tag
-- Lightweight Tag: A lightweight tag is simply a pointer to a specific commit
git tag <tagname>
-- Annotated Tag: An annotated tag is stored as a full Git object and contains additional metadata such as the tagger name, email, date, and a message.
git tag -a <tagname> -m "Tag message"
---- Listing Tags
git tag
---- Viewing a Tag's Details
git show <tagname>
---- Deleting a Tag
git tag -d <tagname>
---- Pushing Tags to Remote
-- Push a single tag
git push origin <tagname>
-- Push all tags
git push origin --tags
---- Deleting a Remote Tag
-- Delete locally
git tag -d <tagname>
-- Delete from remote
git push origin :refs/tags/<tagname>
Example Workflow
---- Tagging a New Release
-- Create an annotated tag for the new release
git tag -a v1.2.0 -m "Release version 1.2.0 with new features"
-- Push the tag to the remote repository
git push origin v1.2.0
---- Listing and Verifying Tags
-- List all tags
git tag
-- View details of a specific tag
git show v1.2.0
---- Deleting a Tag
-- Delete a tag locally
git tag -d v1.1.0
-- Delete the same tag from the remote repository
git push origin :refs/tags/v1.1.0
