12+ Git Source control must know basics interview Q&As

Q1. How does Git differ from SVN?

Git Vs SVN

Git Vs SVN

#1. Git is a distributed source control system meaning that there will be multiple client repositories. SVN is one repository with lots of clients. GIT is decentralized to a point where people can track their own edits locally without having to push things to an external server.


You checkout from a trunk or a branch from a central SVN repository with the checkout or “co” command.

In Git:

a) You “clone” a company wide “master” repository to your local repository. When you clone, you are making a copy of the whole repository including the branches and the tags. After cloning the whole repository, you can switch to a particular branch or tag within your local repository with the “checkout” command.

b) Since the “clone” command copied the whole repository to your local machine, you can perform your own diff, logs, etc without requiring to remotely connect to your origin (e.g. master repository or where you cloned your local repository from). (i.e. where you cloned your local repository from).

You can list the value of origin with:

What if your target repo URL has changed?

c) In Git, the key building blocks are remote repository, local repository, staging & indexing area, and working area. Different git commands work on different segments of the flow as depicted below.

Git key concepts

#2. Git is a file content management tool made to merge files, evolved into a true Version Control System.

How can Git copy the whole repository? Wouldn’t it be too many files to copy?


Branches & tags are copy of a directory. So, you have many copies of same files in various folders.

In Git:

You work with changes, and not files. In Git, branches are part of the history of data (i.e. and not data itself), and where tags are a true meta-data. This is why you can clone the whole repository without having to worry too much about if you have enough space.

Q2. Does Git provide a better version control compared to SVN?

#3. SVN is designed to be a more centralized version control system whereas GIT is based on each user having his/her own GIT repository and those repositories push changes back up into a central one from time to time. In other words decentralized or distributed as shown above in the diagram. With your Git local repository cloned from the central repository, you can perform diffs, merges, log, etc for a better local version control. When you are happy with your changes, then you can share it with your team by “push” ing your changes to the master by making a remote call via ssh or http.

You can even clone the local repositories from the other users before those changes are pushed to the central repository. Git shines when you are decentralized and want to work not only at your regular job, but withe your server at home and the laptop on the move you have the clone of the whole repository to work on. You can “push” (i.e. sync) your local repository back to your central repository when you have network connection. You can’t do this with SVN, which is a centralized client/server paradigm.

SVN is a bit simpler to learn and understand as it has a few commands “via ssh or http” that you execute against the central repository from you SVN client. With Git, you have both local commands that you execute against your local repository, and remote ssh or http commands that you use to sync from your local repository with a remote one.

#4. Even though Git has been there for a while, it has really gained momentum after “GitHub” where many open-source projects are stored. The flagship functionality of GitHub is “forking” , which is copying a repository from one GitHub user’s account to another. This enables you to take a project that you don’t have write access to, and use it for learning & modifying it under your own account. If you make changes you’d like to share, you can send a notification called a “pull request” to the original owner. That user can then, with a click of a button, merge the changes found in your repo with the original repo.

So, you can make an international level collaborative effort in building your own products and services with other developers in different parts of the world. You can show off your work to prospective employers, investors, and clients by having a “GitHub” account.

Both Git and SVN have their strengths and weaknesses, but knowing Git will be like having another powerful tool in your toolkit.

Q3. In Git, which commands make remote calls and which are local commands?

Remote: clone, push, pull, and fetch. Requires an internet connection.

Local: status, commit, checkout, merge, diff, log, add, reset, init, tag, revert, hist, mv, etc. Within your local machine.

git flows local & remote

Q4. In Git, how do you create a new repository?

Step 1: Create a project directory and a file.

Step 2: Create a repository.

This would have created a “.git” directory for meta data under “myproject”.

Step 3: Add the file “hello.html” to the repository

After staging, if you want to look at the status you can do

If not happy with the changes, you can revert it with

Step 4: Checking the status of your repository as to if there are any changes to be committed.


Step 5: push it to the central repository if you have one.

to make further changes

Step 6: git pull to get the changes other users may have made

Step 7: make your changes in eclipse or other IDEs.

Step 9: add (i.e. staging or queuing the changes) & commit the changes to your local repository with comments.

Step 10: See the history. check the status.

Step 11: push the changes to the central repository.

Q5. What if your organization already has a corporate wide master repository, how would you go about working with Git?

Step 1: Clone the master repository to your local. This brings the whole repository including the branches and the tags, which are actually changes or history,


Note: You can also clone local repositories by providing the path. So, you can have multiple local repositories.

Step 2: Your cloned local repository may have multiple branches. So, select which branch to be the current to work on. You do this with a “checkout” command.

Step 3: You can use the status command to see what your current branch is. It will have an * next to it. You can switch branches within your cloned local repo with the “checkout” command.

Step 4: You can also list your tags with


Step 5: Once you are happy with your committed changes, you can push them to the origin. In this case the corporate wide master repository is our origin. This could be your other users’ local repositories.

Note: The origin being “ssh://mycompany.com/path/to/myproject.git”

Step 6: You can sync your local repository with the others’ changes.

Note: The “pull” command does two things 1) fetch the changes from the origin 2) merge the changes into your repository’s active branch. You can also do a fetch, followed by a status command to review the changes others have made, and then merge those changes into your local repository.

Q6. What tools do you use to work with Git? Are there any graphical tools?
A6. Git is very powerful with Unix like commands. In windows, you can use Cygwin or msysGit. There are graphical tools like SourceTree, which is a graphical git client for windows. gitk is another GUI tool.

“git difftool” will launch “WinMerge” GUI for understanding the differences and merging.

Atlassian Stash is Git repository software, which enables collaboration on Git repositories. It provides enterprise level support and integration to other SDLC tools like JIRA (for defect management), Bamboo (for continuous integration & build), etc.

Q7. How do SVN and Git commands differ?
A7. Modifying an existing file SVN vs Git.


1) make changes to a file.
2) svn commit # a ssh, file or http call


1) make changes to a file.
2) git add (i.e. staging) #local
3) git commit -m “changed x to y” #local
4) git push # (i.e. ssh to the central rep)

Q8. What is a feature branch in Git?
A8. Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming releases.

The core idea behind the feature branch workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

The maintainers (e.g team leads, etc) of Git repository prefer the team members’ changes to be on a feature branch, as they can be reviewed or signedoff by the maintainer(s) before merged to the main codebase.

The “feature branch workflow” still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature . Feature branches should have descriptive names, like “floating menu feature” or JIRA-#999.

1) Clone from the origin. Origin can be a remote master repository.

2) Switch to the feature branch once you have clone the whole repository to your local machine.

3) Make some changes to files within your feature branch.

4) Stage the changes to the feature branch in the local repository.

5) Commit the changes to the feature branch in the local repository.

6) Push the changes to the remote repository’s feature branch.

7) log into web based central repository managers like Github or Atlassian Stash to see your changes.

8) switch to “JIRA-#999” feature branch, and issue a “pull request” so that the maintainer can merge it. The pull request is more than just a notification to the fellow repository users of your changes. It’s a dedicated forum for discussing the proposed feature & reviewing your code for any improvements. If there are any problems with your changes, your team mates can reject your pull request with comments. When your pull request gets approved by your team mates, the changes in the feature branch gets merged to the master. All of these pull request activities are tracked.

You need 4 pieces of information to file a pull request:

a) the source repository,
b) the source branch,
c) the destination repository,
d) and the destination branch.

What is the key benefit of a “pull” request?

Once someone completes a feature, he/she doesn’t immediately merge it into master. Instead, he/she pushes the feature branch to the central server and file a pull request asking the fellow developers to review & merge his/her additions into master. This gives other developers an opportunity to review the changes before they become a part of the main code base. The 3 key benefits of this approach are:

1) Improves code quality due to continuous code reviews.

2) Communicates changes promptly to the team mates.

3) Enforces better & collective code ownership. Do you want your fellow developers to comment on or take ownership of your sloppy code?

Q9. What is a HEAD in Git?
A9. HEAD is a reference to the last commit in the currently checked-out branch. You can use the following command to check the HEAD.

What is a detached HEAD? A detached HEAD is the situation you end up in whenever you check out anything besides a local repository like a remote repository, a specific commit or tag.

Q10. How do you discard, unstage, or uncommit changes in Git?
A10. There are 3 commands like checkout, reset (with different modes like –soft, –hard, and –mixed) & revert.

1) Discard changes in working area

2) Discard changes in index & staging area. In other word unstage file(s).

3) Uncommit changes in Git.

Uncommit from local repo and put the changes in the staging area.

Uncommit from local repo and put the changes in the working area.

“mixed” mode is the default for the reset command.

Remove a commit completely from the local repository, and the change will be lost for ever.

4) All the above commands loose the commit history. If you want to reverse a change with a new commit use the “revert” command. You can see this as an extra commit in the commit history with the “git log –oneline” command.

If you have untracked files that you want to get rid of:

“d” for directories, and “f” for the files.

Q11. How do you diff between two branches?
A11. Firstly, to get the summary of changes between two branches say “master” and “feature/feature_a_branch”:

Now, to learn more about the diffs of a particular file say “src/folder/file1.py” in both the branches:

Q12. What git clients have you used to connect to git servers like GitHub Enterprise, BitBucket, etc?
A12. There are a lot of different ways to use Git. There are the original command-line tools, and there are many graphical user interfaces of varying capabilities. You can open a Terminal in Mac or Command Prompt or Powershell in Windows. For windows, download and install from “https://git-scm.com/downloads”.

For Mac, install Homebrew first,

and then install the git command-line tools

For Ubuntu,

Git comes with built-in GUI tools (git-gui and gitk), but there are several third-party tools like Egit, which is a plugin for Eclipse IDE, SourceTree, etc. Git GUI is a cross platform GUI that works on Linux, Windows and Mac OS X. GITK is another handy UI.

Q13. How do you bring in specific folder or file from a different branch into your current branch?
A13. The use of the “source branch name” followed by “” and file/folder name to bring in from the source branch.

Firstly, switch to the target or destination branch into which you want to bring a folder/file.:

Next, bring a folder/file from the source branch:

Categories Menu - Q&As, FAQs & Tutorials