Top Git Interview Questions And Answers (2023)

To see local branches, run this command: To see remote branches, run this command:

git branch -r

To see all local and remote branches, run this command:

git branch -a

The key difference is that git is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours. With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it. With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it. SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on. Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN.

Following is the command to change the working branch:

Tagging in Git is a way to mark specific commits in a repository as important milestones or versions. A tag is simply a pointer to a specific commit in the Git history, and it provides a convenient way to reference a particular version of the code. In Git, tags can be created and managed using the git tag command. There are two types of tags in Git: lightweight and annotated. A lightweight tag is simply a name that points to a specific commit, similar to a branch. It is created using the git tag <tagname> command, and can be used to reference a specific version of the code. An annotated tag, on the other hand, is a full Git object that contains additional metadata such as a tagger name and email, a tag message, and a timestamp. Annotated tags are created using the git tag -a <tagname> command, and are useful for creating release versions of the code that include additional information about the release. Tags can also be pushed to remote repositories using the git push command, with the --tags option to push all tags, or the git push origin <tagname> command to push a specific tag. Conclusion: In summary, tagging in Git is a way to mark specific commits in a repository as important milestones or versions, and provides a convenient way to reference a particular version of the code.

Following points should be taken into consideration : 1. Look into all individual commits 2. look first into the files which have relevant changes. 3. We need to make sure that the PR's code should be woking as properly as per the new feature for which the PR is raised. 4. code should not affect any previously existing feature. 3. functions should not be tool long. 4. There should not be redundant code. 5. code should be clean i.e. there should be proper indendentation , no unnecessary blank lines , semicolon after each javascript statement. 6. Variables and function names should be meaningful . 7. If the application contains unit tests than the test coverage should criteria should be met. for more details please refer the following link : What You Should Look Out For When You Review Pull Request

Git is a distributed version control system commonly used for tracking changes in source code during software development. It allows multiple developers to work on a project simultaneously, keeping track of changes made to files over time, and enables collaboration and efficient management of code repositories. Here are some of the most useful Git commands: 1. `git init`: Initializes a new Git repository in the current directory. 2. `git clone `: Creates a copy of a remote repository on your local machine. 3. `git add `: Adds a file to the staging area, preparing it for a commit. 4. `git commit -m ""`: Records changes to the repository, creating a new commit with a descriptive message. 5. `git status`: Displays the current state of the repository, including modified, staged, and untracked files. 6. `git pull`: Fetches and merges changes from a remote repository into the current branch. 7. `git push`: Pushes commits from a local branch to a remote repository. 8. `git branch`: Lists existing branches in the repository. 9. `git checkout `: Switches to a different branch. 10. `git merge `: Merges changes from one branch into the current branch. 11. `git log`: Shows a history of commits, including commit messages and other details. 12. `git diff`: Displays the differences between the current state and the last commit. These are just a few of the many commands available in Git. Git provides a powerful set of tools for managing version control, branching, merging, and collaboration in software development projects.

Git is the most popular version control system for several reasons: 1. Distributed architecture: Git is a distributed version control system, meaning that every developer has a complete copy of the entire repository, including its history. This allows developers to work offline and independently, and it provides redundancy and backup in case of server failures. The distributed nature of Git also makes branching and merging fast and efficient. 2. Speed and efficiency: Git is designed to be fast and perform well even with large repositories and extensive histories. It utilizes advanced algorithms and data structures to optimize operations such as committing, branching, merging, and retrieving historical information. 3. Branching and merging: Git provides powerful branching and merging capabilities. Branching is lightweight and easy to create, allowing developers to create separate lines of development for features, bug fixes, or experiments. Merging branches in Git is usually straightforward and results in minimal conflicts, thanks to Git's advanced merge algorithms. 4. Collaboration and teamwork: Git enables efficient collaboration among developers working on the same project. Multiple developers can work on different branches simultaneously, and changes can be easily shared and merged. Git also provides tools for code review and managing contributions from multiple developers. 5. Large community and ecosystem: Git has a vast and active user community, which contributes to its popularity. Many popular hosting platforms, such as GitHub and GitLab, support Git repositories and provide additional features like issue tracking, pull requests, and project management tools. The availability of numerous third-party tools and integrations further enhances Git's ecosystem. 6. Flexibility and extensibility: Git is highly flexible and can be adapted to various workflows and development processes. It provides hooks, custom scripts, and configuration options, allowing developers to tailor Git to their specific needs. Git also supports various workflows, including centralized, feature branching, and Gitflow, among others. 7. Stability and maturity: Git was initially developed by Linus Torvalds, the creator of the Linux kernel, and it has been widely adopted and extensively tested over the years. It has proven to be stable and reliable for managing version control in both small and large-scale projects. These factors, along with its rich feature set and ease of use, contribute to Git's popularity and make it the preferred choice for version control in the software development community.

In Git, a rollback typically refers to the act of reverting a repository or a specific commit to a previous state. It allows you to undo changes and return to a previous point in the commit history.

There are a few different ways to perform a rollback in Git, depending on the specific situation and your requirements. Here are a couple of common scenarios:

1. Rollback a single commit: If you want to undo the changes introduced by a specific commit while keeping the subsequent commits intact, you can use the `git revert` command. This command creates a new commit that undoes the changes made by the specified commit. The `` represents the identifier of the commit you want to revert, such as the commit hash or a reference like a branch or tag name. Git will create a new commit that applies the inverse of the changes introduced by the specified commit. 2. Rollback multiple commits: If you want to remove a series of commits and make it as if they never happened, you can use the `git reset` command. This command allows you to move the branch pointer to a previous commit, effectively discarding the commits that follow. The `` specifies the commit to which you want to roll back. Git will move the branch pointer to this commit and discard the subsequent commits. By default, this command preserves the changes introduced by the discarded commits as unstaged changes in your working directory. If you want to completely discard the changes introduced by the rolled-back commits, you can use the `--hard` option: Note: Exercise caution when using the `git reset` command with the `--hard` option, as it permanently removes the changes from your repository. Conclusion : It's important to note that rolling back commits modifies the commit history, so it's generally recommended to avoid rolling back commits that have already been shared with others. Instead, consider creating a new commit that introduces the desired changes or communicating with collaborators to coordinate any necessary changes.

The `git bisect` command in Git is a helpful tool for finding the commit that introduced a bug or issue. It allows you to perform a binary search through the commit history to pinpoint the specific commit where the problem was introduced. The process involves marking specific points in the commit history as "good" or "bad" and using this information to narrow down the range of commits to search.

Here's an overview of how the `git bisect` command works:

1. Start the bisect process: Begin the bisect process by running the following command: 2. Mark the current commit as "bad": Identify the commit at which the bug is present and mark it as "bad" using the following command: 3. Mark a known good commit: Specify a commit known to be free of the bug and mark it as "good". You can provide a commit hash, a branch name, a tag, or any other valid reference to indicate a known good commit: 4. Git performs a binary search: Git will automatically check out a commit halfway between the known good and bad commits. It then prompts you to test and determine if the bug is present in that commit. Based on your feedback, Git will mark it as "good" or "bad". 5. Repeat the process: Git will continue performing binary searches, checking out commits based on your feedback, until it finds the exact commit where the bug was introduced. 6. Finish the bisect process: Once the problematic commit has been identified, you can end the bisect process by running the following command: This command returns your repository to the original state, discarding any temporary changes made during the bisect process. Conclusion : The `git bisect` command helps you efficiently identify the commit that introduced a bug, making it easier to analyze, understand, and resolve the issue. It's a powerful tool for debugging and finding the root cause of problems in your codebase.

The reflog in Git is a helpful tool that keeps a record of changes to the tips of branches and other references in your repository. It allows you to recover lost commits, undo complex operations, troubleshoot issues, and manage branches. Let's walk through an example to illustrate its use: 1. Accidental branch deletion: Suppose you accidentally delete a branch called "feature/xyz" using the following command: You realize your mistake and want to recover the branch. 2. Recovering the deleted branch with reflog: You can use the reflog to find the commit at which the branch was last pointing. Run the following command: The output will show a chronological list of reflog entries with reference names, commit hashes, and actions performed. 3. Locate the deleted branch entry: In the reflog output, find the entry related to the deleted branch "feature/xyz". It will show something like: The `HEAD@{1}` represents the reflog entry for the second-to-last action. 4. Recover the deleted branch: With the identified reflog entry, you can recreate the deleted branch at the specific commit. Run the following command: Replace `<commit-hash>` with the commit hash from the reflog entry. This command recreates the branch at the specified commit. 5. Verify the branch recovery: Run `git branch` to see the list of branches. You should now find the recovered branch "feature/xyz" among the branches. Conclusion: The reflog helps you recover lost branches, commits, or other references by providing a history of changes to your repository. It acts as a safety net when you accidentally delete or modify references, allowing you to easily identify previous states and recover them. Additionally, the reflog is instrumental in troubleshooting and understanding the history of your repository, making it a valuable tool in Git.