Day 10 - Advanced Git Concepts & Commands

Let's begin with some advance concepts and commands of Git.
For the basics concepts and commands of git and GitHub, please refer Day 9 - Git and GitHub (hashnode.dev) this blog.

Branching

Each repository has a default branch i.e., main or master branch.

You can create your separate branch using the below command. So, that the stable branch or other branches in the repository doesn't get affected and other's work as well.

git checkout -b <branch_name> -> To create new branch and switch to that.
git checkout <branchname> -> To switch to the existing branch.
git branch -a -> To see the list of branches in the repository.

NOTE: You don't have to clone the repository again for making branches. You can simply run the above commands in your cloned repository.

You can create a new branch using GitHub also. Below snapshot is for your reference:

Click on "View all branches"

Click on "New branch"

Give your branch name and then create new branch.

You can do the steps which has been covered previously for adding new changes to the file, committing it and to pushing it to remote repository in your new branch.

Merging your branch to stable branch

For merging your branch changes to stable branch, you need to create a "pull request".

Pull Request is basically for getting your changes reviewed from the reviewers and getting approval before merging it to the stable branch. While creating pull request you can see the changes whatever has been done to that branch(your branch).

After getting reviewed and approval from the reviewers then "merge" button will get enable and you can merge the changes to the stable branch.

You can see the below snapshot on how you can create pull request.

So, in the above snapshot you can see while raising a pull request, you need to add title, description, you can add reviewers for reviewing your code and after filling all the details, you can simply create a pull request.

And once, your code is reviewed and gets approved from reviewer you can merge it to the stable branch or for whatever branch you have raised it for merging.

You can also merge your changes using the git merge command. Git merge can develop a new commit that can integrate the changes from two branches. This new commit has two parent commits, one from each branch.

git merge <yourbranchname>

First, you have to go to the branch where you want to merge your changes. In this case we want our "Test_branch" changes to merge it to "main" branch.

So , you can see our head is now pointing to "main" branch after merging the changes.

Merge Conflicts

Merge conflicts occur when competing changes are made to the same line of a file, or when one person edits a file and another person deletes the same file.

You can see line2 is edited via git and via GitHub and contents of both are different. Now we will push our changes to GitHub via git.

While pushing our local changes to GitHub, we got an error saying "Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing hint: to the same ref."

Here, it is given to do git pull . "git pull" is basically used to fetch and download content from a remote repository and immediately update the local repository to match that content.

You can see the error Merge conflict in the file. Fix conflicts and them commit the result.

Now to fix the conflict, you have to edit your file, if you want to keep both the changes you can keep them or you can remove one change or if you want to remove both you can do that as well and save the file as per your requirement.

Now, you can see the changes has been pushed to your remote repository.

REVERT

Revert our changes to the commit wherever we want to revert it. Creates a new commit on whatever we have reverted back and maintains the version history.

git revert <commit_id>

You can refer to the below screenshots on how we can revert the changes.

A text editor will get open after running the command which will show you which commit is going to revert back.

You can see here the new commit has been created with message "Revert Added a new line"

You can see all the commit history in GitHub also using history as shown in the bellow snapshot.

RESET

Git reset is similar to Git checkout as it allows you to move the HEAD to any previous commit in your history. Unlike checkout however, Git reset will effectively uncommit all the changes between your starting state and the specified commit.

In order to understand Git reset, you must first understand another core Git concept, which is the internal states that Git uses to manage your work. You might sometimes see these three states called “the three trees”.

The three states are:

Working Directory: The working directory is sometimes referred to as your Work In Progress, or WIP. The working directory is simply referring to your files that have been saved, but not staged or committed yet. You can think of your working directory as your sandbox to test any changes before you stage, commit, or share them.
Index: The index is the “staging area” in your Git workflow. Inside every .git folder, there is a special file called index. This is the file that tracks the files that are staged when you perform a Git add.
Commit History: This is likely the area where you already have the clearest understanding. Your commit history is the chain of commits, or snapshots of the project, that you’ve made over time.
While most commonly, we simply move forward in time by adding new commits to our history, having a clear chain of commits makes it possible to change where HEAD points without any issue. It’s important to understand that resetting to a particular commit means that you’re changing your current working directory and potentially the indexes that were previously committed.

Below is the command for reset:

git reset <commit_id>

There are basically 3 types of reset:

git reset soft: This option moves HEAD back to the specified commit, undoes all the changes made between where HEAD was pointing and the specified commit, and saves all the changes in the index. In other words, Git re-adds the changes as staged, ready to be committed again.
```
 git reset --soft <commit_id>
```
Git reset soft is a very safe way to move back to a prior point in your Git history and preserve all changes. Since the changes are preserved, this is one way to rewrite your history, applying all the changes across multiple commits into one commit while providing a path for making additional changes at the same time.
git reset hard: Git reset hard is to use it to discard all the changes in the working directory and in the index.
```
 git reset --hard <commit_id>
```
git reset mixed: Git reset with the --mixed option will undo all the changes between HEAD and the specified commit, but will preserve your changes in the Working Directory, as unstaged changes.
```
 git reset --mixed <commit_id>
```

Conclusion

In Conclusion, We have seen about:

Branches
Merging strategy
git merge
Merge Conflicts
git revert
git reset

👆The information presented above is based on my interpretation. Suggestions are always welcome.😊

~Smriti Sharma✌