Advance Git & GitHub [Day 10 Task] Part 1

Git Branching

The diagram above visualizes a repository with two isolated lines of development. By developing them as branches, it's not only possible to work on both of them in parallel, but it also keeps the main Master (default branch) free from error.

Each task has one separate branch.
After done with the code, Merge other Branches with the Master.
This concept is useful for parallel development means at times many persons can work on their branch and that won't reflect on the main branch.
you can create any number of branches.
Changes are personal to that particular branch.
The default branch is Master.
Files created in Workspace will be visible in any of the branch workspaces until you commit. Once you commit, then that file belongs to that particular branch.
When creating a new branch, data from the existing Branch is copied to the new branch (only one time when the branch is created).

Git Revert and Reset

The git revert command can be considered an 'undo' type command, however, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.

Reverting should be used when you want to apply the inverse of a commit from your project history.

How Revert Works

The git revert command is used for undoing changes to a repository's commit history. Other 'undo' commands like, git checkout and git reset move the HEAD and branch ref pointers to a specified commit. Git Revert also takes a specified commit, however, git revert does not move ref pointers to this commit. A revert operation will take the specified commit, inverse the changes from that commit, and create a new "revert commit". The ref pointers are then updated to point at the new revert commit making it the tip of the branch.

Syntax: git revert <commit-id> [Commit id that you want to revert]

Git Reset

The git reset command enables you to undo or "reset" code changes that you previously made. when You create or modify code files with a text editor directly in your Git working directory. You then use the git add command to move your changes to Git's staging area (or index). Finally, you can run git commit to commit these changes to the repo. These three steps correspond with the following three Git concepts:

The working directory (or working tree)
The staging area (or staging index)
The object repository (or object database)

Executing git reset provides a way to reset changes that were made in any of these three locations. You can think of this as a way to "move backward" in your Git flow (or Git history) if you need to undo changes in Git from any of these three locations. Essentially, Git will reset the tip of your current branch to a prior commit, and handle any uncommitted changes as you see fit.

The main result of using the git reset command is to repoint the branch label of your currently checked-out branch to a different (usually a previous) commit. You can think of this as resetting the tip of your current branch to a previous state.

But if you already pushed a set of changes to your remote repository such as on GitHub or BitBucket, you probably want to use the git revert command instead of reset.

The basic syntax for git reset is as follows:

Git reset offers three main modes (or options) that determine how it behaves. They are --mixed, --soft, and --hard. Here's a brief description of each mode:

git reset --mixed: The default option for git reset. Updates the current branch tip to the specified commit and unstaged any changes by moving them from the staging area back to the working tree.

git reset --soft: Known as a soft reset, this updates the current branch tip to the specified commit and makes no other changes.

git reset --hard: Known as a hard reset, this updates the current branch tip to the specified commit, unstaged any changes, and also deletes any changes from the working directory.

When the [commit] parameter is omitted, it defaults to the commit pointed to by Git HEAD. This is equivalent to running the command "git reset HEAD".

Since Git HEAD always points to the currently checked-out commit, the current branch tip is not repointed or changed in this case. When git reset is run without specifying a commit, it is typically to undo changes in Git's staging area or working directory (or both), without resetting the branch to a different commit. Note that each branch head points to the tip of that branch, i.e. the most recent commit on that branch.

When do we use Merging?

Suppose a situation arises where you are working on a feature in your branch while your friend is working on the other, and both of you need to merge changes into the main repo. In this condition, you will need to go with either the Git rebase or git merge features, which one is better:

Git Merge

The easiest option to merge the branches is using the git merge command. Git merge safeguards the histories of both repositories.

command:

git checkout feature

git merge main or master

Creates a new “feature commit”, safeguarding the history of both branches and giving it a structure like this:

Advantage

Merge command is a non-destructive command. In this command, the existing branches are not changed in any way and thus it covers all the demerits of Git Rebase.

Disadvantage

Besides being easy, there are many demerits also git merge. Consider a condition where you have to work regularly on the main branch and have a very active main branch, in such conditions the commit history will become messy, thus resulting in a painful experience for the developers to understand the log or the commit history.

Git Rebase

The alternative to git merge is the git rebase option. In this, we rebase the entire feature branch to merge it with the main branch.

Command:

git rebase main or master

Git rebases the feature branch and merges it with the main branch. In simple words, it moves the entire feature branch to the tip of the main branch .

Advantage

The major benefit of using git rebase is it provides a cleaner merge history. It works linearly, removing the unnecessary merge commits, unlike git merge. It makes it easier to move along the log history and understand the changes.

Disadvantage

The biggest pitfall with git rebase is it you can’t see when the upstream changes were made, and they were incorporated into the feature branch. If many developers are working on this and you rebase it, then Git might consider that the upstream changes that were made are different than what they were previously working on.

Some Tasks :

Task 1

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], switch to the dev branch ( Make sure your commit message will reflect as "Added new feature"). [Hint uses your knowledge of creating branches and Git commits command.

Now check-out to the dev branch, as it is created from a master branch so everything will get copied for the first time. Then add and commit as per the task.

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

Now push it to the GitHub Repo followed by the username and PATh.

Here is the file in GitHub Repo

3. Add a new commit in dev branch after adding the 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 the development branch
Commit this with the message “ Added feature2 in development branch”
2nd line>> This is gadbad code
Commit this with the message “ Added feature3 in the development branch
3rd line>> This feature will gadbad everything from now.
Commit with the message “ Added feature4 in the development branch

Added the content in the file by the command vim version01.txt and committed them. So this all is the commit id --

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

Here used the git revert command to bring back the previous version and it created the new commit id.

Task 2

1. Demonstrate the concept of branches with 2 or more branches with a screenshot

Added two more branches called prod and test from the dev branch.

2. add some changes to the dev branch and merge that branch into master

Created a file called task.txt in the dev branch then added and committed there. Then check-out to other branch and merge the dev branch here by the command git merge dev.

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

Add a file file1.txt and add some content there. then check out to the master branch and try to rebase.

As per the output try to check the master branch in the .git folder.

Check the git log command :

In summary, git merge maintains a clear history of branching and merging, while git rebase creates a linear history by moving commits onto a new base. The choice between them depends on the project's development workflow, collaboration needs, and the desired commit history aesthetics.