GitHub Interview Questions- Part 4

Answer:

The types of Version Control Systems are:

• Local Version Control System- It is a local database located on a local computer; wherein every file change is stored as a patch. Each patch set contains only the changes made to the file since its last version. To see what a file looks like at a given point; it is essential to add all the relevant patches to a file in order until that given moment. So, the main problem here is that everything is stored locally. If anything happens to a local database, all the patches would be lost. If anything were to happen to the single version, all changes made after that version would also be lost. Moreover, it would be difficult and nearly impossible to collaborate with other developers or teams.
• Centralized Version Control System– It has only a single server that has all the file versions. Centralized VCS enables multiple clients to access files simultaneously on the server and pull them to the local computer or push them onto a server from the local computer. This way, everyone will know what everyone else on a project is doing. This prompts easy collaboration with other teams and developers. The biggest issue with the Centralized Version Control System is that everything is stored on a centralized server. If anything happens to that server, nobody can pull files, save their versioned changes, or collaborate. Also, if the central database gets corrupted, and there are no backups, then you will lose the entire history of a project except the single snapshots people have on their local machines.
• Distributed Version Control System – In this VCS, clients don’t just check the latest snapshot of files from a server; they completely mirror the repository, including its entire history. Thus, everyone collaborating on the project has a local copy (local database) of the project. With this Distributes VCS model, if a server becomes unavailable, any client repositories can send a project’s version copy to the other client or back into a server when it becomes available. It is enough that a client contains the correct copy, which can be easily distributed further.

Answer:

As Git is a free and open-source version control system, it allows us to run multiple versions of a project so that it displays the changes made to a code over time.  If needed, one can keep track of all changes that were made. Thus, a large number of developers can make and upload their own changes so that changes can be attributed to the particular developers.

Answer:

Git Bash implies an application for Microsoft Windows. It provides an emulation layer for the Git command-line experience. Bash stands for Bourne Again Shell. A shell means a terminal application used to interface with OS through the written commands. Bash is the most popular default shell in use on Mac OS and Linux. It is a package that installs Bash along with its common utilities and Git on the Windows operating system.

Answer:

A fork isn’t a built-in feature in Git; rather, it is a concept provided by several hosting services of Git. The fork of a repository simply means a copy of that repository, having all its branches, code, and history on a server. A fork will “know” from which repository it has been forked. It can be perceived as a server-side clone of the repository.

Answer:

A Git pull command is used to download and fetch content from the remote repository and update it on the local repository. Integrating remote upstream changes into the local repository is a common task in Git-based collaboration workflows. A Git pull command is a combination of two other commands, git fetch and git merge.

Answer:

The git revert command is an undo-type command. It figures how to invert the changes introduced by a commit and appends the new commit with a resulting inverse content instead of removing the commit from a project history. Thus, the revert command prevents Git from losing history, which is crucial for a reliable collaboration and the integrity of revision history.

Answer:

The log refers to a public record of a commit history for the branch. On the other hand, a reflog is a private record of the repository’s local commits. Unlike reflog, the log is a part of the Git repository, and it can be replicated after a pull, push, or fetch. Developers can’t access a local repository’s reflog without having access to the system where it is located.

Answer:

When you create a repository, you will see a .git directory present in it. That directory includes all repository’s metadata and keeps a commit history for maintaining a track of all changes made to the files in the repository.

All the information related to hooks, refs, object databases, commits, remote repository addresses, etc., are stored inside this folder. It is an essential part of Git. When you clone a Git repository on your local system, the .git directory actually gets copied.

Answer:

If a .git directory gets deleted, you will lose track of a project’s history. The repository will no longer remain under version control.

Answer:

Git branches are lightweight in terms of the data they carry. In other VCS like SVN, creating a branch is a cumbersome process. Besides, once you create a branch, the entire main code from the main branch gets copied to a newly created branch. Whereas in Git, a code is separated only from the branch’s point of creation. Once the creation of a new branch occurs, one can switch to it and start development.

Answer:

 You can use the git revert command with the –no-commit option followed by the commit hash you want to revert. This will stage the changes but won’t create a new commit. You can then make additional modifications if needed and commit them all together.

Answer:

Git LFS is an extension for Git that handles large files by storing them outside the Git repository and replacing them with text pointers. It’s used when you have binary files, such as images, videos, or large datasets, that would bloat your Git repository. By using Git LFS, you can efficiently manage large files, reduce repository size, and speed up cloning and fetching.

Answer:

Git hooks are scripts that can be executed at specific points in the Git workflow, such as before or after a commit, push, or receive. They allow you to automate tasks and enforce project-specific workflows. For example, you can use a pre-commit hook to run code formatting checks or a post-receive hook to trigger automated deployments to a server when changes are pushed to a repository.

Answer:

Git rebase is a way to incorporate changes from one branch into another by moving or “replaying” the commits from the source branch onto the target branch. It creates a linear commit history and is useful when you want to keep your branch history clean and free of unnecessary merge commits. You would use rebase when you want a more streamlined history, while you might use merge when you want to preserve the branch’s original history.

Answer:

A Git submodule is a reference to another Git repository inside your own Git repository. It allows you to include another project as a subdirectory within your project. This is useful for managing dependencies or including external code while keeping them separate and versioned. Submodules enable you to track specific versions of external repositories within your project.

Answer:

A Git fork is a copy of a repository on GitHub that allows you to make changes without affecting the original repository. A Git clone, on the other hand, creates a local copy of a repository on your own machine. The main difference is that a fork is typically used for contributing to someone else’s project on GitHub, whereas a clone is used for working with a repository locally.

Answer:

The git pull origin master command is used in Git to update your local repository with changes from the remote repository’s master branch. Here’s a breakdown of what each part of the command does:

1. git pull: This is the main Git command that combines two actions: fetch and merge. It fetches changes from a remote repository and then merges those changes into your current branch.
2. origin: This is the default name Git uses to refer to the remote repository from which you initially cloned your repository. Typically, origin points to the repository from which you cloned your local repository.
3. master: This is the name of the branch on the remote repository that you want to pull changes from. In Git, master is a common default branch name, but it could be different if the remote repository uses a different naming convention.

So, when you run git pull origin master, you are essentially telling Git to:

• Fetch the latest changes from the remote repository (in this case, named “origin”).
• Merge those changes into your current branch, which is usually the master branch in your local repository.

Answer:

A Git merge conflict occurs when you try to merge two branches that have competing changes in the same part of a file.

Answer:

 The git ls-tree command in Git is used to display the contents of a tree object in the Git repository. It allows you to inspect the contents of a specific Git tree, which can be a snapshot of the working directory or a specific commit.

Answer:

A bare repository in Git is different from a standard initialized repository in terms of its purpose and structure.

1. Purpose:
   • Bare Repository: A bare repository is typically used as a central repository in a collaborative Git workflow. It doesn’t have a working directory and is meant solely for storing the version history and facilitating collaboration among multiple developers. It doesn’t contain the actual project files.
   • Standard Initialized Repository: A standard initialized Git repository, on the other hand, is what you typically create when you start tracking a new project with Git. It includes a working directory where you can modify and work on your project files.
2. Contents:
   • Bare Repository: It contains only the Git data, such as the version history (commits, branches, tags) and the Git configuration. It lacks the actual project files or a working directory.
   • Standard Initialized Repository: It includes the Git data (version history, configuration) as well as the actual project files in a working directory.
3. Use Cases:
   • Bare Repository: Used in scenarios where you want a central repository to share changes with other developers in a team. It’s often found on a server and doesn’t allow direct editing of project files.
   • Standard Initialized Repository: Used when you want to work on a project locally, track changes, and have a working directory to edit files.

A bare repository serves as a central storage point for collaboration, while a standard initialized repository is used for local development and includes both the version history and the working directory with project files.