Original address: medium.com/edureka/dev… Translation: CODING David Opus

Q1: What is version control?

This is probably the easiest question you’ll ever be asked in an interview. My suggestion is to define version control first: it is a system that logs changes to files so that you can call a particular version of a file later. A version control system consists of a central shared repository where teammates can submit changes to files, and then you can mention the purpose of version control. Version control allows you to:

  • Restore the file to its previous state.
  • Restore the entire project to its previous state.
  • Compare changes over time.
  • View the content that may have caused problems when it was last modified.
  • When the problem was introduced.

Q2: What are the benefits of using version control?

Advantages of version control:

  1. With a version control system (VCS), all team members can work freely on any file at any time. VCS allows you to merge all your changes into a common version.
  2. All past releases and changes are neatly packaged in VCS. When you need it, you can always request any version and you’ll get a snapshot of the complete project.
  3. Every time you save a new version of a project, VCS asks you to provide a brief explanation of what has changed. In addition, you can see exactly what has changed in the file contents. This lets you know who made what changes in the project.
  4. A distributed VCS like Git allows all team members to have a complete history of the project, so if the central server fails, you can use any team member’s local Git repository to recover the code base.

Q3: Describe the branching strategy you use

This question is intended to test your branching experience, so to tell them how you have used branching in previous jobs and what it was used for, you can refer to the following:

  • Feature branching The feature branching model retains all changes to specific functionality within the branch. When the new feature is fully tested and verified, the branch is merged into the Master branch.
  • Task branching In this model, each task is implemented on its own branch, and the task keywords are contained in the branch name. It’s easy to see which code accomplishes which task simply by looking up the keyword in the branch name.
  • Release branch Once the development branch has acquired enough features for release, you can clone the branch to form the release branch. Creating this branch will start the next release cycle, so no new functionality can be added after that, only bug fixes, document completion, and other release-oriented tasks can be included in this branch. Once it is ready for release, the version is merged into master and marked with the version number. In addition, although the development branch may have had new code updates since release, it should still be merged back into the development branch.

Finally, tell them that branching strategies vary from organization to organization, so I know the basic branching operations: delete, merge, check out branches, etc.

Q4: What VCS tools are you familiar with?

You can mention the VCS tools you have used: “I have used Git, and one of its main advantages over other VCS tools such as SVN is that it is a distributed version control system.”

Distributed VCS tools do not necessarily rely on a central server to store all versions of project files. Instead, each developer “clones” a copy of the repository and has a complete history of the project on his or her own hard drive.

Q5: What is Git?

I suggest you answer this question by explaining Git’s architecture, as shown below. You can refer to the following explanation:

  • Git is a distributed version control system (DVCS) that tracks changes to files and allows you to undo any specific changes.
  • Its distributed architecture has many advantages over other version control systems such as SVN, one of the main advantages being that it does not rely on a central server to store all versions of project files. Instead, each developer “clones” a copy of the repository THAT I showed in the figure below using “Local Repository” and has a complete history of the project on its hard drive so that in the event of a server outage, you can recover everything you need from one of your teammates’ local Git repositories.
  • There is also a central cloud repository where developers can commit changes and share them with other team members. As shown, all collaborators commit changes to the “Remote Repository.”

Q6: Explain some basic Git commands?

Here are some basic Git commands:

Q7: How do I restore a commit that has been pushed and made public in Git?

There are two possible answers to this question, and you can use any of the following options depending on the situation:

  • Delete or fix the error file in a new commit and push it to a remote repository. This is the most natural way to fix an error. After making the necessary changes to the file and committing it to a remote repository, I will use: git commit -m “commit message”
  • Create a new commit and undo all the changes you made in the error commit using the command: git Revert

Q8: How do I compress N commits into one?

There are two options for squeezing N commits into a single commit. Include the following two options in your answer:

  • To write a new commit message from scratch, use the following command: **git reset-soft HEAD~N && **git commit
  • If you want to edit new commits by concatenating existing commits, you need to extract these messages and pass them to Git Commit. **git reset-soft HEAD~N && **git commit-edit -m “$(git log-format = % b-reverse.HEAD @ {N})”

Q9: What is Git Bisect? How can you use it to determine the source of a bug?

I suggest you start with a small definition of Git bisect — Git bisect is used to find bug-introducing commits using binary search algorithms. Git bisect < subcommand >

Next, I need to explain what this command can do. This command uses a binary search algorithm to find which commit in the project history introduces a bug. First you need to tell it about a known commit that contains the bug and a commit before a known introduction bug. Git Bisect then selects a commit between the two points in time and asks you if the selected commit is “good” or “bad,” after which it Narrows it down until it finds the exact commit that introduced the bug.

Q10: What is Git rebase? How does it resolve conflicts in feature branches before merging?

You should start by saying that Git rebase is a command that merges another branch into the branch you are currently working on and moves all local commits that precede the other branch to the top of the current working branch history.

Next you need to define a Git Rebase time window with an example to show how it can be used to resolve conflicts in a feature branch before merging. If a feature branch is created from the master, and the master has received a new commit, Git rebase can be used to move the feature branch to the top of the master branch.

This command effectively replays the changes made in the feature branch at the top of the master and allows conflicts to be resolved in the process. Once done, feature branches are relatively easy to merge into the master, sometimes as a simple fast-forward operation.

Q11: How do I configure the Git repository to run the code health check tool before committing and prevent committing if tests fail?

I suggest you start with a brief introduction to the reasonableness test. A reasonableness or smoke test can be used to determine the reasonableness and necessity of subsequent testing.

The next section explains how to do this, which can be done with a simple script associated with the repository’s pre-commit hooks. The pre-commit hook is triggered before the commit even before you need to enter the commit message. In this script, you can run other tools, such as Linters, and perform integrity checks on changes submitted to the repository.

To give a final example, you can refer to the following script:

#! /bin/sh
files=$(git diff -cached -name-only -diff-filter=ACM | grep '.go$')
if [ -z files ]; then
exit 0
fi
unfmtd=$(gofmt -l $files)
if [ -z unfmtd ]; then
exit 0
fi
echo "Some .go files are not fmt'd"
exit 1
Copy the code

This script checks that any.go files that are about to be submitted pass the standard GO source formatter, Gofmt. When the check fails, the script effectively prevents the commit from being applied to the repository by exiting with a non-zero status.

Q12: How do I find the list of files that have changed in a particular commit?

You should not only explain what the command is, but what the command does. So you can say, to get a list of files that changed in a particular commit use the command: git diff-tree -r {hash}

Given a commit hash value, this command lists all files that have changed or been added in the commit. The -r flag causes the command to list individual files, rather than just collapsing them into the root directory name.

Your answer can also include the following, which, while completely optional, will help impress the interviewer: The output will also contain some additional information that can be easily removed with the following two flags: git diff-tree-no-commit-id-name-only -r {hash}

Here -no-commit-id disallows commit hashes from appearing in the output, while -name-only prints the file names instead of their paths.

Q13: How do I set up certain scripts to run every time the repository receives a new push commit?

Each time the repository receives a new commit pushed by the developer, there are three ways to configure the script to run, and you need to define a pre-receive, Update, or post-receive script depending on when the script is triggered.

  • When a new commit is pushed to the target repository, the pre-receive hook script in the target repository is invoked. Any scripts bound to this hook will be executed before updating any references. This is a useful hook for running scripts that help enforce development strategies.
  • The Update hook works like a pre-receive hook and also fires before any updates are actually made. However, the UPDATE hook is called once for each commit that is pushed to the target repository.
  • Finally, after the update is accepted to the target repository, the post-receive hook in the repository is invoked. This is an ideal place to configure simple deployment scripts, invoke continuous integration systems, send notification emails to the repository maintainer, and so on.

Hooks are local to each Git repository and are not versioned. Scripts can be created in the hooks directory within the “.git “directory, or elsewhere, and links to these scripts can be placed in the directory.

Q14: How do I know if a branch has merged with the master branch?

Git branch-merged lists branches merged to the current branch. Git branch-no-merged lists branches that are not merged yet.