Explore topic-wise InterviewSolutions in .

• git RESET --mixed command is used for undoing changes of the working directory and the git index.
• git merge --ABORT command is used for STOPPING the merge process and returning back to the state before the merging occurred.

• This can be a time-consuming process if we are not sure what to look at exactly. Fortunately, git provides a GREAT search facility that works on the principle of binary search as git-bisect command.
• The initial set up is as follows:

• Upon RUNNING the above commands, git checks out a revision that is labeled as halfway between “good” and “bad” versions. This step can be run again by marking the commit as “good” or “bad” and the process continues until the commit which has a BUG is found.

Both these COMMANDS ensure that changes from one branch are integrated into another branch but in very different ways. Git rebasing can be thought of as saying to use another branch as a new base for the work.

• Whenever in doubt, it is always preferred to use the git merge command.
  
  Following are some factors that tell when to use merge and rebase commands:
   
• In case our branch gets contributions from other developers outside the team as in open-source or public repositories, then rebase is not preferred.
  - This is because rebase DESTROYS the branch and it results in broken and inconsistent repositories unless the git pull --rebase command is used.
• Rebase is a very destructive operation. If not applied correctly, it results in loss of COMMITTED work which might result in breaking the consistency of other developer’s contribution to the repository.
• If the model of having branches per feature is followed, rebasing is not a good idea there because it keeps track of related commits done by the developers. But in case the team follows having branches per developer of the team, then the branch has no additional useful information to be conveyed. In this model, rebasing has no HARM and can be used.
• If there is any chance where there might be a necessity to revert a COMMIT to previous commits, then reverting a rebase would be almost impossible as the commit data would be destroyed. In such cases, the merge can be used.

• Sometimes we end up having certain files that are not needed in the GIT index when we are not being careful while using the git add command. Using the command git rm will remove the file from both the index and the local working tree which is not always desirable.
   
• Instead of using the git rm command we can use the git reset command for removing the file from the staged version and then ADDING that file to the .gitignore file to avoid repeating the same MISTAKE again.

This command is used to INTRODUCE certain commits from one branch ONTO ANOTHER branch within the repository. The most common use CASE is when we want to forward- or back-port commits from the MAINTENANCE branch to the development branch.

There can be cases where we want to revert from the pushed changes and go back to the previous version. To handle this, there are two possible approaches based on the situations:

• Approach 1: Fix the bad changes of the FILES and CREATE a new commit and push to the remote repository. This step is the SIMPLEST and most recommended approach to fix bad changes. You can use the command: git commit -m "<message>"
• Approach 2: New commit can be created that reverts changes done in the bad commit. It can be done USING git revert <NAME of bad commit>

• It is always advisable to CREATE an additional commit rather than amending the existing commit due to the following reasons:
  - Doing the AMEND operation destroys the previously saved state of that commit. If only the commit message gets changes or DESTROYED, it's acceptable but there might be CASES when the contents of the commits get amended. This results in the loss of important INFORMATION associated with the commit.
  - Over usage of git commit --amend can have severe repercussions as the small commit amend can continue to grow and gather unrelated changes over time.

• Conflicts occur whenever there are multiple people working on the same FILE across multiple branches. In such cases, git won't be able to resolve it automatically as it is not capable of deciding what changes has to get the precedence.
• Following are the steps are DONE in order to resolve git conflicts:
  1. Identify the FILES that have conflicts.
  2. Discuss with members who have worked on the file and ensure that the required changes are done in the file.
  3. Add these files to the STAGED SECTION by using the git add command.
  4. Commit these changes using the git commit command.
  5. Finally, push the changes to the branch using the git.

• git branch --merged HELPS to GET the LIST of the BRANCHES that have been merged into the CURRENT branch.
• Note: git branch --no-merged lists the branches that have not been merged to the current branch.