Explore topic-wise InterviewSolutions in .

• git STASH pop command throws away the specified stash (topmost stash by default) after APPLYING it.
• git stash apply command LEAVES the stash in the stash list for future reuse. In CASE we wanted to remove it from the list, we can use the git stash drop command.

• This command ANNOTATES each line within the given file with information from the commit which introduced that change. This command can also OPTIONALLY annotate from a given REVISION.
• Syntax: git annotate [<OPTIONS>] <file> [<revision>]
• You can get to learn more about this command from the official git documentation here.

Detached HEAD indicates that the currently checked-out repository is not a LOCAL branch. This can be caused by the following scenarios:

• When a branch is a read-only branch and we try to create a COMMIT to that branch, then the commits can be termed as “free-floating” commits not connected to any branch. They would be in a detached state.
• When we checkout a tag or a specific commit and then we try to perform a new commit, then again the commits would not be connected to any branch. When we now try to checkout a branch, these new commits would be automatically PLACED at the top.
  
  In order to ensure that detached state doesn't happen, =instead of checking out commit/tag, we can create a branch emanating from that commit and then we can SWITCH to that newly created branch by USING the command: git checkout -b <<new_branch_name>>. This ensures that a new branch is checkout out and not a commit/tag thereby ensuring that a detached state wouldn't happen.

• In order to make git work, it uses a set of configurations that are pre-defined by default by means of configuration files (or config files). We can change the default behavior of git by just modifying these files which are basically text files. In order to do this, it is important to understand how git identifies these files. It does so by following the below steps:
  
  - Firstly, git searches for the config values in the system-wide gitconfig file stored in &LT;<installation_path>>/etc/gitconfig file that has settings defined and applied to EVERY user of the system and all their repos.
       - In case you WANT git to search from this particular file and read/write on it, we can pass the option --system to git config command.
  
  - Next, git searches for the ~/.gitconfig file or ~/.config/git/config that has the scope specific to the user.
     - Git can be made to read/ write from this file specifically bypassing --global to the git config command.
  
  - Lastly, git searches for the config values in the git directory of the local repository that we are currently working on.
     - These config values are specific to that particular repository alone and can be accessed by passing --local to the git config command.This is the default config file that gets accessed and modified upon in case we do not SPECIFY any levels.

A commit object consists of the following COMPONENTS:

• A set of FILES that represents the state of a PROJECT at a given point in time.
• Reference to parent commit objects.
• A 40 character STRING TERMED as SHA-1 name uniquely identifies the commit object.

This command tracks every single change made in the repository references (that can be branches or tags) and also maintains the branches/tags log HISTORY that was either created locally or CHECKED out. Reference logs such as the commit snapshot of when the branch was created or CLONED, checked-out, renamed, or any commits made on the branch are maintained by Git and listed by the ‘REFLOG’ command.

• This recovery of the branch is only possible when the branch was either created locally or checked-out from a remote repository in your LOCAL repository for Git to store its reference history logs.
• This command should be executed in the repository that had the lost branch.

We can RECOVER this by CHECKING out the latest commit of this BRANCH in the REFLOG and then checking it out as a NEW branch.

Squashing MULTIPLE commits to a single one overwrites the HISTORY which is why it is recommended to be done using full caution. This step can be done by RUNNING the command: GIT REBASE -i HEAD~{{N}} where {{N}} represents the number of commits needed to be squashed.

• git diff works in a SIMILAR FASHION to git status with the only difference of showing the differences between commits and also between the working directory and index.

• GitHub provides a variety of services like forking, USER management, etc along with providing a CENTRAL repository for collaborative work.

• “PUSH REQUEST” is termed so because it is done when the target repository requests US to push our changes to it.
• “Pull request” is named as such DUE to the fact that the repo requests the target repository to GRAB (or pull) the changes from it.

• git stash apply command is used for bringing the works back to the working DIRECTORY from the stack where the CHANGES were stashed using git stash command.
• This helps the developers to resume their work where they had LAST LEFT their work before SWITCHING to other branches.

git REMOTE command creates an entry in  git CONFIG that specifies a NAME for a particular URL. Whereas git clone creates a new git repository by copying an EXISTING one located at the URL.

• To DELETE a branch we can simply use the command git branch –d [head].
• To delete a branch locally, we can simply run the command: git branch -d <local_branch_name>
• To delete a branch remotely, run the command: git PUSH origin --delete <remote_branch_name>
• Deleting a BRANCHING scenario occurs for multiple REASONS. One such REASON is to get rid of the feature branches once it has been merged into the development branch.

Git stash can be used in CASES where we need to SWITCH in between branches and at the same time not wanting to lose edits in the current branch. RUNNING the git stash COMMAND basically pushes the current working directory state and index to the stack for future USE and thereby providing a clean working directory for other tasks.

• Have GIT installed in your system. 
• Then in order to CREATE a git repository, create a folder for the PROJECT and then run git init. 
• Doing this will create a .git FILE in the project folder which indicates that the repository has been created.

With the help of git, developers have GAINED many advantages in terms of performing the development process faster and in a more efficient manner. Some of the main features of git which has made it easier to work are:

• Branching Capabilities:
  
  - Due to its sophisticated branching capabilities, developers can easily work on multiple branches for the different features of the project.
  - It also has an easier merge option along with an efficient work-flow feature diagram for tracking it.
   
• DISTRIBUTED manner of development:
  
  - Git is a distributed system and due to this nature, it became easier to trace and locate data if it's lost from the main server.
  - In this system, the developer gets a repository file that is PRESENT on the server. Along with this file, a copy of this is also stored in the developer’s system which is called a local repository.
  - Due to this, the scalability of the project gets drastically improved.
   
• Pull requests feature:
  
  - This feature HELPS in easier interaction AMONGST the developers of a team to coordinate merge-operations.
  - It keeps a proper track of the changes done by developers to the code.
   
• Effective release cycle:
  
  - Due to the presence of a wide variety of features, git helps to increase the speed of the release cycle and helps to improve the project workflow in an efficient manner.