25 Git questions that will help you to nail your job interview

Version Control System is software that helps you and your team to keep track of changes in your source code and easily share the changes across the team.

• Whenever you do changes in your source code, you can submit the changes to Version Control System.
• The others can then retrieve your changes from the version control system and integrate them to their source code.
• Similarly you can retrieve changes of the others and integrate them to your source code.

When you submit the changes to version control system (this action is referred to as commit), the version control system creates a snapshot of your source code which is like a copy of the code in the specific point in time. The snapshot is usually called version, revision or hash.

Later on you and the others who have the necessary permissions can see the list of all snapshots together with all changes that happened over time.

When more users use Version Control System, one can see the changes of the others and one person can merge own changes with changes of the others.

This allows safe collaboration within wide team while all the history with all changes is preserved. So if anyone breaks anything, it is never a problem to revert the change and get back to the previous version.

Thanks to the version control system (VCS), you can:

• collaborate in a team where each member of the team can easily change the source code and share the changes within the team
• see all source code changes that happened over the time
• see who changed what and when
• compare two versions against each other
• get back in time to any version you want
• work on multiple versions of the source code at a time and merge them together later
• run automated actions whenever someone does any change to the code base

Git is distributed version control system (DVCS) that helps you to keep track of changes in your source code.

It is one of the most modern and most widely used version control systems.

Using Git you can see the history of all changes in your source code together with who made the changes.

Git is very fast and flexible and you can use it even if you are offline.

Git repository is a special database that contains the data of the versioned project.

It contains current version of the project together with all previous versions of the project - all files, all directories and complete history of all changes with information who did each change and when.

• When you have access to the repository of the project, you have access to all source files and complete history of the project.
• When you do any changes to your files and submit the changes, the Git version control system saves the changes to the repository.

The .git folder contains all Git repository data.

When you see the .git folder in some other folder, it means the folder containing the .git folder is versioned and contains the Git workspace.

Whenever you change any file or directory within the workspace, the Git is able to track the changes and you can submit the changes and store them to the repository at any time. When this happens, data describing the changes is stored to the .git folder in a special format.

The .git folder is hidden by default so you won't see it in File Explorer on Windows unless you changed the default configuration of File Explorer. You also won't see the folder while using dir command in command-line unless you use it with -ah parameter (which allows to display directories with hidden attributes).

The local repository is a Git repository that is stored on your computer.

The remote repository is a Git repository that is stored on some remote computer.

The remote repository is usually used by teams as a central repository into which everyone pushes the changes from his local repository and from which everyone pulls changes to his local repository.  

When you are finished with doing changes into your workspace, you can add them to staging area and from there you can commit the changes to your local repository. This can be done even when you are disconnected from the internet and nobody else can see the changes in your local repository.

Once you decide it's a good time to share the changes, you push the changes from your local repository to the remote repository. This copies the changes from .git folder on your local computer to .git folder on the remote computer. From this moment, your changes are visible to people who have access to the remote repository.

They can pull your changes from the remote repository to their local repository and then integrate the changes into their workspaces.

In similar way you can pull changes of the others from from the remote repository to your local repository and then integrate the changes into your workspace.

Your local repository can be created in two ways:

Create empty repository

When you start a new project, you usually want to create a new empty repository. This can be done by executing the following command from the command line:

git init

The command above will create the new repository in your current folder. You can also run the following command:

git init <NameOfYourRepository>

The command above will create the new repository in the folder <NameOfYourRepository>. The folder for the new repository will be created in your current folder.

Clone existing repository

When you join an existing project, you usually want to clone already existing repository. This can be done by executing the following command from the command line:

git clone <AddressToYourRepo>

The remote repository will be downloaded to your local computer as a local repository. The remote repository is often called Upstream, the local repository is called Downstream.

The git clone command is used for creating a local repository from another repository.

It can be executed like this:

git clone <URL> <Folder>

• The URL can be either physical path to anoher local repository (folder), or HTTP, HTTPS or SSH URL to the remote reposiory.
• If you don't provide the <Folder> parameter, the repository will be created in a newly created folder that will be automatically derived from the <URL>
• If you want to clone the repository directly to the current folder (use git clone <URL> .), the current folder must be empty

When the git clone is executed, it does the following steps for you:

• New empty folder is created in your current folder
• New empty .git folder is created in a newly created folder (this .git folder will contain all data of the target repository after the next step is completed)
• Data from the target repository .git folder is copied to your newly created .git folder

The Git workspace is a versioned folder that is being monitored by Git for changes.

Imagine you have the following project structure:

c:\my-project
c:\my-project\.git
c:\my-project\index.html
c:\my-project\images
c:\my-project\photo.png

The path c:\my-project is the root workspace folder. Everything inside this path except the .git folder is part of workspace and is monitored by Git.

If you change anything within the workspace (you edit file, add a new one, remove a file, add or remove a folder or do just any other possible change in data), the Git is able to see the changes.

The .git folder is excluded because it has special meaning - this folder contains the repository data (information about the version history and all changes together with data of previous versions), so it is not supposed to be versioned.

Now, how does the Git know that some folder is a part of workspace and should be monitored for changes? It is looking for a .git folder. If the .git folder is in the folder or in some of its parent folders, it means the folder is a part of workspace and should be monitored.

If you delete the .git folder, you make the parent folder and all its content unversioned as you removed all the versioning information and left the current version only.

The workspace and data versioning can be managed by using Git commands.

To see all the changes that were done to your Git workspace and were not yet committed, use the git status command.

Simply run the following from the command-line:

git status

This displays the default long-format output. You can also try the short format running the following command:

git status -s

Imagine you have fifty changes in your workspace and you want to send just five of them to the local repository while the rest would be skipped. How will you do it in such a way that all the five changes would be sent to the local repository at once?

The Staging Area is here to the rescue.

The Staging Area is like a box. All changes that should later go to the repository will be put into this box. The changes that you want to skip won't be put there.

After you carefully selected changes and put them into the box (staged), you can quickly check what is in the box. If you are satisfied with what you see, you can then take all the items from the box and put them to the repository.

The Staging Area is sometimes called as Index.

Before you start adding changes to Staging area (Index), it is good idea to first check what changes you have in your workspace. This can be done by executing the following command from command line:

git status

You can then add changes to Index by using git add command.

The following command adds all changes from the current directory and all its children:

git add .

The following command adds all html files from the folder Views that have some changes:

git add Views\*.html

The following command adds file index.html:

git add index.html

When you execute the git commit command from the command line, the staged changes from your Staging Area (Index) will be sent to your local repository.

In any version control system it has always been a good practice to append a message with description of changes that are included in the commit. In Git it can be done using the following command:

git commit -m "Something has changed"

If you omit the -m parameter with description of changes, the Git will automatically display the default editor and will let you enter the commit message using the editor. The command looks like this:

git commit

The command git push is used for sending changes from your local repository to a remote repository. All commits that weren't previously sent will be sent.

Use git push command after the git commit command. If you forget to do this, the committed changes will be only in your local repository, but they won't be visible for your team members who can see only changes that are present in the remote repository.

The git pull command is an alternative to executing two separate commands: git fetch and git merge. The first one fetches all new changes from the remote repository to your local repository. The second command merges the fetched changes into your current branch that is currently checked out.

Remember: git pull = git fetch + git merge

Tip:

Before you start using git pull, we recommend you to use git fetch and git merge first. Once you understand the behavior of those two commands well, feel free to start using git pull.

The git config command is used for managing git configuration settings.

• All configuration settings are stored in a text file .gitconfig.
• The file consist of sections and key-value pairs where each key defines one property and value defines its value.
• There are multiple levels of configuration - System/Global/Local

 

Important configuration settings

• user.name - defines user name that will be used as an identifier of the person who committed the changes (Author)
• user.email - defines e-mail of a person who committed the changes (Author) - this e-mail will be visible in list of commits.
• core.editor - defines path to custom file editor

Configuration levels

• System - configuration settings from this level are used across all user acounts on the computer.
• Global - configuration settings from this level are used for all repositories within a useraccount
• Local - configuration settings from this level are used for one repository only.

The configuration settings are inherited fromt he highest level (System) to the lowest level (Local). Each configuration setting can be overridden on the lower level.

There is one .gitconfig file for each configuration level, each file is stored in different location depending on the operating system and level

In Git, each commit has 40 character identifier that is calculated using SHA-1 hashing algorithm. This commit identifier is called hash.

When you execute git log command, you can see that each commit has hash.

Run the command line and execute the following command:

git log

The command will show you the list of all commits.

More convenient way to see commit history is to use some Git user interface like TortoiseGit or Git client integrated in Visual Studio or other IDE.

In order to send changes from your local Git repository to a remote repository, run the git push command?

The following sequence of commands is usually used in the basic Git workflow:

• Use git status to see what are the changes in your workspace, in other words what files were added, changed or deleted
• Use git add . to add all changes from workspace to index (stage)
• Use git commit -m "Change description" to commit all changes from index (stage) to your local repository
• Use git push to send all commits that weren't sent previously to a remote repository

To get changes from the remote repository to your computer, use git fetch command. This will download all commits from the remote repository that haven't yet been downloaded to your local repository.

Many people use the git pull command. This command however does more than just fetching the data from a remote repository to a local repository. It is a combination of git fetch and git merge command. Which means that it also merges new changes to your currently checked out branch.

To add a new file, to the remote repository, you first need to add it to index (staging area). Use git add . command for this.

Then you need to commit the change to your local repository. Use git commit -m "Change description" command for this.

Then you need to push commits from the local repository to the remote repository. Use git push command for this.

You can use two different git commands.

• git blame file.txt - this command will show you the content of the file together with commints and their authors, so you can see who created/changed which line and when
• git log file.txt - this command will show you the list of all commits that contain any change done to the file

To discard all changes from your local Git workspace, you can use the following commands:

• git reset --hard - this will discard all changes permanently, discarded changes won't be preserved in any way
• git stash - this will discard all changes, but will stash them away and you can restore them later using git stash pop command

Every day, you usually use the following git commands:

• git pull (or git fetch and git merge) - get changes of other team members from the remote repository and merge them into your current branch
• ...do some changes...
• git status - see what are the changes in your workspace
• git add . - add all changes to index (staging area)
• git commit -m "Description of your changes" - commit changes from index (staging area) to your local repository
• git push - send all changes from your local repository to the remote repository