Git Branching

Git branching is a powerful feature that allows developers to diverge from the main line of development and work on isolated changes. 🌳

In Git, a branch is essentially a lightweight movable pointer to a commit. When you create a branch, you are creating a new line of development, allowing you to make changes without affecting the main codebase. 🚀

Branching is particularly useful for collaborative projects and managing different features or bug fixes simultaneously. Developers can work on their features independently, and once they are ready, the changes can be merged back into the main branch. 🤝

Git Revert and Reset

Git Revert 🔄

• Purpose: Revert changes by creating a new commit that undoes a previous commit.

• Usage: git revert [commit_hash]

• Effect: Doesn't remove commits but adds new ones to negate the changes introduced by the specified commit.

Git Reset 🔄

• Purpose: Reset the current branch to a specific commit, effectively discarding changes.

• Usage:

  • Soft Reset: git reset --soft [commit_hash]

  • Mixed Reset (default): git reset [commit_hash]

  • Hard Reset: git reset --hard [commit_hash]

• Effect:

  • Soft Reset: Moves HEAD and the branch pointer to the specified commit, keeping changes staged.

  • Mixed Reset (default): Same as soft reset but also unstages changes.

  • Hard Reset: Discards changes, both in the working directory and staging area.

When to use:

• Revert: When you want to undo changes while preserving the commit history, suitable for shared branches.

• Reset: When you want to completely discard changes and rewrite history, use with caution, especially on shared branches.

Both git revert and git reset serve different purposes, and the choice depends on whether you want to preserve the commit history or rewrite it. 📚✨

Git Rebase and Merge

Git Merge 🤝

• Purpose: Combine changes from different branches, integrating them into the current branch.

• Usage: git merge [branch_name]

• Effect: Creates a new commit that has two parent commits, incorporating changes from the specified branch.

Git Rebase 🔄

• Purpose: Combine changes from one branch to another by moving or combining commits.

• Usage: git rebase [branch_name]

• Effect: Rewrites commit history by placing the changes on top of the specified branch, creating a linear history.

When to use:

• Merge: When you want to maintain a clear and separate history for different features or bug fixes.

• Rebase: When you want a clean, linear history, useful for feature branches before merging into the main branch.

Considerations:

• Merge: Preserves the original commit history but introduces merge commits, which can clutter the history.

• Rebase: Provides a cleaner history but should be used with caution on shared branches, as it rewrites commit history.

Both git merge and git rebase have their advantages and use cases, and the choice depends on the project's workflow and preferences. 🚀💡

Task 1:

Add a text file called version01.txt inside the Devops/Git/ with “This is first feature of our application” written inside. This should be in a branch coming from master, [hint try git checkout -b dev], swithch to dev branch ( Make sure your commit message will reflect as "Added new feature"). [Hint use your knowledge of creating branches and Git commit command]

• version01.txt should reflect at local repo first followed by Remote repo for review. [Hint use your knowledge of Git push and git pull commands here]

Add new commit in dev branch after adding below mentioned content in Devops/Git/version01.txt: While writing the file make sure you write these lines

• 1st line>> This is the bug fix in development branch

• Commit this with message “ Added feature2 in development branch”

• 2nd line>> This is gadbad code

• Commit this with message “ Added feature3 in development branch

• 3rd line>> This feature will gadbad everything from now.

• Commit with message “ Added feature4 in development branch

Restore the file to a previous version where the content should be “This is the bug fix in development branch” [Hint use git revert or reset according to your knowledge]

Solution :

Certainly! Here's a step-by-step guide to achieve the described scenario:

Step 1: Create and Switch to Dev Branch

# Create and switch to the dev branch
git checkout -b dev

Step 2: Add version01.txt

# Create version01.txt with the specified content
echo "This is the first feature of our application" > Devops/Git/version01.txt

# Add the file to the staging area
git add Devops/Git/version01.txt

# Commit with the message "Added new feature"
git commit -m "Added new feature"

Step 3: Push to Remote Repository

# Push the changes to the remote repository
git push -u origin dev

Step 4: Add New Commits to Dev Branch

# Open version01.txt and add the specified content
echo "This is the bug fix in development branch" >> Devops/Git/version01.txt
git add Devops/Git/version01.txt
git commit -m "Added feature2 in development branch"

echo "This is gadbad code" >> Devops/Git/version01.txt
git add Devops/Git/version01.txt
git commit -m "Added feature3 in development branch"

echo "This feature will gadbad everything from now." >> Devops/Git/version01.txt
git add Devops/Git/version01.txt
git commit -m "Added feature4 in development branch"

Step 5: Restore the File to a Previous Version

Option 1: Using Git Revert

# Revert the last commit, effectively restoring the file to a previous version
git revert HEAD

Option 2: Using Git Reset (Use with caution, as it rewrites history)

# Reset to the commit before the last one
git reset --hard HEAD~1

Important Notes:

• Always be cautious when using git reset --hard as it can rewrite history, which may lead to data loss.

• If the branch is already pushed to the remote repository, force push (git push -f) might be necessary after a reset to update the remote branch. However, be careful with force pushing on shared branches to avoid conflicts.

Task 2:

• Demonstrate the concept of branches with 2 or more branches with screenshot.

• add some changes to dev branch and merge that branch in master

• as a practice try git rebase too, see what difference you get.

Solution :

Let's go through the process step by step:

Step 1: Create a New Project and Initialize Git

# Create a new project
mkdir MyProject
cd MyProject

# Initialize Git
git init

Step 2: Create Two Branches and Switch to dev

# Create and switch to dev branch
git checkout -b dev

# Make some changes in dev branch (e.g., create or modify files)
echo "This is a dev branch change" > dev_changes.txt
git add dev_changes.txt
git commit -m "Add changes in dev branch"

# Switch back to master
git checkout master

# Create and switch to another branch (e.g., feature branch)
git checkout -b feature_branch

# Make some changes in the feature branch
echo "This is a feature branch change" > feature_changes.txt
git add feature_changes.txt
git commit -m "Add changes in feature branch"

Step 3: Merge dev Branch into master

# Switch back to master
git checkout master

# Merge dev into master
git merge dev

Step 4: Rebase feature_branch onto master

# Switch to feature_branch
git checkout feature_branch

# Rebase feature_branch onto master
git rebase master

Step 5: Observations

• After the merge, if you run git log, you will see a new commit representing the merge on the master branch. This is a merge commit.

• After the rebase, if you run git log, you will notice that the commit history is linear. The changes from feature_branch are "replayed" on top of the latest master commit. There is no separate merge commit.

Note:

While I can't show you screenshots, you can run these commands in your terminal to observe the changes. Open the project directory in a file explorer to visually confirm the changes in the created files. If you encounter any issues or have further questions, feel free to ask!

HAPPY LEARNING !!!