GIT INTERVIEW QUESTIONS




1) What is Git fork? What is difference between fork, branch and clone?

  • A fork is a remote, server-side copy of a repository, distinct from the original. A fork isn't a Git concept really, it's more a political/social idea.

  • A clone is not a fork; a clone is a local copy of some remote repository. When you clone, you are actually copying the entire source repository, including all the history and branches.

  • A branch is a mechanism to handle the changes within a single repository in order to eventually merge them with the rest of code. A branch is something that is within a repository. Conceptually, it represents a thread of development.

2) What's the difference between a "pull request" and a "branch"?


A branch is just a separate version of the code.

A pull request is when someone take the repository, makes their own branch, does some changes, then tries to merge that branch in (put their changes in the other person's code repository).

3) What is the difference between "git pull" and "git fetch"?


In the simplest terms, git pull does a git fetch followed by a git merge.

  • When you use pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in. pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches, you may run into frequent conflicts.

  • When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge.

4) How to revert previous commit in git?


Say you have this, where C is your HEAD and (F) is the state of your files.


 (F)
A-B-C
 
 master
  • To nuke changes in the commit:

git reset --hard HEAD~1

Now B is the HEAD. Because you used --hard, your files are reset to their state at commit B.

  • To undo the commit but keep your changes:

git reset HEAD~1

Now we tell Git to move the HEAD pointer back one commit (B) and leave the files as they are and git status shows the changes you had checked into C.

  • To undo your commit but leave your files and your index

git reset --soft HEAD~1

When you do git status, you'll see that the same files are in the index as before.


5) What is "git cherry-pick"?


The command git cherry-pick is typically used to introduce particular commits from one branch within a repository onto a different branch. A common use is to forward- or back-port commits from a maintenance branch to a development branch.

This is in contrast with other ways such as merge and rebase which normally apply many commits onto another branch.

Consider:


git cherry-pick <commit-hash>

6) Explain the advantages of Forking Workflow


The Forking Workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own server-side repository. The Forking Workflow is most often seen in public open source projects.

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository that leads to a clean project history. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository.

When developers are ready to publish a local commit, they push the commit to their own public repository—not the official one. Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated.

7) Tell me the difference between HEAD, working tree and index, in Git?


The working tree/working directory/workspace is the directory tree of (source) files that you see and edit.

The index/staging area is a single, large, binary file in <baseOfRepo>/.git/index, which lists all files in the current branch, their sha1 checksums, time stamps and the file name - it is not another directory with a copy of files in it.

HEAD is a reference to the last commit in the currently checked-out branch.

8) Could you explain the Gitflow workflow?


Gitflow workflow employs two parallel long-running branches to record the history of the project, master and develop:

  • Master - is always ready to be released on LIVE, with everything fully tested and approved (production-ready).

  • Hotfix - Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop.

  • Develop - is the branch to which all feature branches are merged and where all tests are performed. Only when everything’s been thoroughly checked and fixed it can be merged to the master.

  • Feature - Each new feature should reside in its own branch, which can be pushed to the develop branch as their parent one.

9) When should I use "git stash"?


The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use, and then reverts them from your working copy.

Consider:


$ git status
On branch master
Changes to be committed:
new file: style.css
Changes not staged for commit:
modified: index.html
$ git stash
Saved working directory and index state WIP on master: 5002d47 our new homepage
HEAD is now at 5002d47 our new homepage
$ git status
On branch master
nothing to commit, working tree clean
The one place we could use stashing is if we discover we forgot something in our last commit and have already started working on the next one in the same branch:
# Assume the latest commit was already done
# start working on the next patch, and discovered I was missing something
 
# stash away the current mess I made
$ git stash save
 
# some changes in the working dir
 
# and now add them to the last commit:
$ git add -u
$ git commit --ammend
 
# back to work!
$ git stash pop

10) How to remove a file from git without removing it from your file system?

If you are not careful during a git add, you may end up adding files that you didn’t want to commit. However, git rm will remove it from both your staging area (index), as well as your file system (working tree), which may not be what you want.

Instead use git reset:


git reset filename # or
echo filename >> .gitingore # add it to .gitignore to avoid re-adding it
This means that git reset <paths> is the opposite of git add <paths>.

11) When do you use "git rebase" instead of "git merge"?


Both of these commands are designed to integrate changes from one branch into another branch - they just do it in very different ways.

Consider before merge/rebase:


A <- B <- C [master]
^
 \
 D <- E [branch]
after git merge master:
A <- B <- C
^ ^
 \ \
 D <- E <- F
after git rebase master:
A <- B <- C <- D <- E

With rebase you say to use another branch as the new base for your work.

When to use:

  1. If you have any doubt, use merge.

  2. The choice for rebase or merge based on what you want your history to look like.

More factors to consider:

  1. Is the branch you are getting changes from shared with other developers outside your team (e.g. open source, public)? If so, don't rebase. Rebase destroys the branch and those developers will have broken/inconsistent repositories unless they use git pull --rebase.

  2. How skilled is your development team? Rebase is a destructive operation. That means, if you do not apply it correctly, you could lose committed work and/or break the consistency of other developer's repositories.

  3. Does the branch itself represent useful information? Some teams use the branch-per-feature model where each branch represents a feature (or bugfix, or sub-feature, etc.) In this model the branch helps identify sets of related commits. In case of branch-per-developer model the branch itself doesn't convey any additional information (the commit already has the author). There would be no harm in rebasing.

  4. Might you want to revert the merge for any reason? Reverting (as in undoing) a rebase is considerably difficult and/or impossible (if the rebase had conflicts) compared to reverting a merge. If you think there is a chance you will want to revert then use merge.


12) What happens if the. git directory gets deleted?

If the. git/ directory gets deleted, then you will lose track of your project’s history. The repository will no longer be under version control.

13) Which command is used for writing a Commit Message in Git?

The command used for passing on a message to a git commit is git commit -m “commit message”. The flag m is used to pass a commit message.

14) What is the bare Git repository? How is it different from a standard/non-bare Git repository?

Repositories that are created through git init command are the standard/non-bare Git repositories.

In the top-level folder of such repository, you will find two things:

1. A .git subdirectory keeping all metadata and track of the history of your repo.

2. A working tree.

The repositories which are created using git init –bare command are known as bare Git repositories. They are mainly used for sharing. They do not contain any working tree. They keep the git revision history of your repository in the root folder rather than having it inside the .git subfolder.

It just contains bare repository data. This is how a bare Git repository is different from a standard Git repository. Also, a bare repository does not have a default remote origin repository as it serves as an origin repository for multiple remote users.

Since a bare repository does not contain any workspace, the git push and git pull commands do not work over a bare repo. You are not required to commit any changes to a bare repo.

15) What is a conflict in Git and how to resolve it?

Git has an automatic merging feature that handles the merge commits on its own, provided the code changes have occurred on different lines and in different files.

But, in case of competing for commits where there are changes in the same lines of code of a file or a file has been deleted in one branch but exists and modified in another, Git is unable to automatically resolve differences and thus raises merge conflict.

In such cases, it requires your help to decide which code to include and which code to discard in the final merge.

A merge conflict can occur during merging a branch, rebasing a branch, or cherry-picking a commit. Once a conflict is detected, Git highlights the conflicted area and asks you to resolve it. Once the conflict is resolved, you can proceed with the merge.

Follow the below steps to resolve a competing line change merge conflict:

1. Open Git Bash (Git command line).

2. Use cd <repository-name> command to go to the local Git repository which is having the merge conflict.

3. Use the git status command to produce the list of files affected by the merge conflict.

4. Open the text editor that you use and traverse to the file that has merge conflicts.

5. To see the start of the merge conflict in your file, look the document for the conflict marker <<<<<<<. At the point when you open the file, you'll observe the modifications from the HEAD or base branch after the line <<<<<<< HEAD. Then, you'll observe =======, which partitions your modifications are from the modifications in the other branch, trailed by >>>>>>> BRANCH-NAME.

6. Choose in the event that you need to keep just your branch's changes, just keep the other branch's changes, or make a fresh change, that may include changes from the two branches. Erase the conflict markers <<<<<<<, =======, >>>>>>> and do the changes that you need in the final merge.

7. Use git adds. command to add or stage your changes.

8. Finally, use the git commit -m “message” command to commit your changes with a comment.

To resolve the removed file merge conflict, you need to follow the below steps:

1. Open Git Bash (Git command line).

2. Use cd <repository-name> command to go to the local Git repository that has the merge conflict.

3. Use the git status command to produce the list of files affected by the merge conflict.

4. Open the text editor that you use and traverse to the file that has merge conflicts.

5. Choose if you wish to keep the removed file. You can check the latest changes done in the removed file in your text editor.

6. Use git add <filename> command to add the removed file back to the repository. Or, Use git rm <filename> command to remove the file from your repository.

7. Finally, use the git commit -m “message” command to commit your changes with a comment.

16) How will you fix a Broken Commit?

To fix a broken commit or to change the last commit, the most convenient method is to use the command “git commit -amend’.

It allows you to combine staged changes with the previous commit as an alternative for creating an entirely new commit. This replaces the most recent commit with the amended commit.


17) How will you identify if the branch is already merged into master?

By executing the below commands, you can get to know the branch merge status:

1. git branch –merged master: This will list out all the branches that have been renamed into master.

2. git branch –merged: This will list out all the branches that have been merged into HEAD.

3. git branch –no-merged: This will list out all the branches that are not yet merged.

By default, this command tells the merge status of local branches only. If you want to know about both local and remote branch merge status, then you can use -a flag. If you want to check only for remote branches, then you can use -r flag.

18) What are Hooks in Git?

Answer: Git hooks are certain scripts that Git runs before or after an event like commit, push, update or receive. You will find the ‘hooks’ folder inside .git directory in your local repository. You will find the build-in scripts here pre-commit, post-commit, pre-push, post push.

These scripts get executed locally before or after the occurrence of an event. You can also modify these scripts according to your needs and Git will execute the script when that particular event occurs.


19) What is the use of git fork? How is forking different from cloning?

To fork a project means to create a remote, server-side copy of the original repository. You can rename this copy, and start doing a new project around this without affecting the original project. The fork is not the core concept of Git.

The fork operation is used by Git workflow and this idea exists longer for free and open-source software like GitHub. Generally, once you have forked the project, you will rarely contribute to the parent project again.

For example, OpenBSD is a Unix-like open-source Operating system that was developed by forking NetBSD which is another Unix-like open-source OS.

However, in the fork, a direct connection exists between your forked copy and original repository. At any time, you can contribute back to the original project by using the pull requests.

In the forked copy, all the main data like codes and files get copied from the original repository, however, branches, pull requests and other features do not get copied. Forking is an ideal way for open source collaboration.

Cloning is essentially a Git concept. A clone is a local copy of any remote repository. When we clone a repository, the entire source repository along with its history and branches gets copied to our local machine.

Unlike forking, there is no direct connection between the cloned repository and the original remote repository. If you want to do pull requests and continue back to the original project, then you should get yourself added as a collaborator in the original repository.

Cloning is also a great way for creating a backup of the original repository as the cloned copy also has all the commit history.


20) How will you find out what all files have been changed in a particular Git commit?

By using the hash value of the particular commit, you can execute the below command to get the list of files that have been changed in a particular commit:

git diff-tree -r {hash}

This will list down all the files that have been modified, and also the files that have been added. The -r flag is used to list individual files along with their path instead of collapsing them in their root directory names only.

You can also use the below command:

git diff-tree –no-commit-id –name-only -r {hash}

–no-commit-id will retrain the commit hash numbers to come in the output. Whereas, -name will exclude the file paths and only give the file names in the output.


21) What is the difference between git checkout [branch name] and git checkout -b [branch name]?

The command git checkout [branch name] will switch from one branch to another.

The command git checkout -b [branch name] will create a new branch and also switch to it.

22) What is SubGit?

SubGit is a tool that is used for SVN to Git Migration. It is developed by a company called TMate. It converts the SVN repositories to Git and lets you do work on both the systems concurrently. It auto-syncs the SVN with Git.

23) What is git diff command? How is it different from git status?

Git diff is a multi-use command that can be executed to show the differences between two arbitrary commits, changes between the working tree & a commit, changes between working tree & an index, changes between two files, changes between index & a tree, etc.

The git status command is used to inspect a repository. It shows the state of the working directory and staging area. It will list down the files that have been staged, which haven’t been staged and the files that are untracked.

24) What does a Commit object contain?

The commit object contains the top-level tree object hash, parent commits hash(if any), author and committer information, commit date and commit message.

You can view this through the git log command.

25) What’s the difference between rebase and merge? When should you rebase and when should you merge?

Both rebase and merge commands are used to integrate changes from one branch to another but in a different manner.

As seen in the below two images, suppose you have commits (this is before merge/rebase). After the merge, you will get the result as a combination of commits. It binds together the histories of both the branches and creates a new ‘merge commit’ in the feature branch.

On the other hand, rebase will move the whole feature branch to begin at the tip of the master branch.


ALL THE BEST :)



472 views0 comments

Recent Posts

See All
 

Subscribe Form

©2020 by Linux Advise