As modern software development relies on version control for collaboration, traceability, and deployment, Git has become the standard tool for managing codebases across teams and organizations. Recruiters must identify professionals who are proficient with Git commands, workflows, and conflict resolution, ensuring seamless integration into Agile and DevOps environments.
This resource, "100+ Git Interview Questions and Answers," is tailored for recruiters to simplify the evaluation process. It covers topics from Git fundamentals to advanced branching strategies and real-world troubleshooting scenarios.
Whether hiring for Developers, DevOps Engineers, or Build & Release Engineers, this guide enables you to assess a candidate’s:
For a streamlined assessment process, consider platforms like WeCP, which allow you to:
✅ Create customized Git assessments aligned to development, DevOps, or release management roles.
✅ Include hands-on tasks, such as resolving simulated merge conflicts, writing Git commands, or explaining workflow scenarios.
✅ Proctor tests remotely to ensure fairness and prevent malpractice.
✅ Use AI-powered grading to assess command accuracy, conceptual understanding, and practical problem-solving.
Save time, improve hiring precision, and confidently recruit Git-proficient professionals who can collaborate effectively and maintain code integrity from day one.
Git is an open-source distributed version control system that is widely used for tracking changes in source code during software development. Developed by Linus Torvalds in 2005, Git was designed to address the shortcomings of existing version control systems at the time, particularly for handling large projects with numerous contributors.
At its core, Git allows developers to maintain a history of their project, manage changes to files, and collaborate efficiently with others. Unlike traditional version control systems, which often rely on a central server, Git distributes the repository across all users’ machines. Each user has a complete copy of the repository, including the entire history of changes. This means that operations such as commits, branches, and merges can be performed locally without needing a network connection.
Git's design facilitates features such as branching, allowing developers to create separate lines of development for new features or bug fixes without affecting the main project. Once work on a branch is complete, it can be merged back into the main branch, maintaining a clean and organized project history.
The system uses a combination of snapshots and references (called commits) to track changes over time, making it easy to revert to previous versions of a project or understand how it has evolved. Overall, Git's flexibility, performance, and collaborative capabilities have made it the go-to choice for version control in modern software development.
Git stands out from other version control systems (VCS) primarily due to its distributed architecture, which contrasts sharply with the centralized approach taken by systems like Subversion (SVN) and Concurrent Versions System (CVS).
In a centralized VCS, there is a single central server that holds the repository, and users check out files from this central location. This means that when developers want to work on a project, they need to be connected to the central server to access the latest version of files or to commit their changes. This setup can create bottlenecks, especially in teams with many contributors, as the central server can become a point of failure or slow down the workflow.
In contrast, Git provides each user with a complete local copy of the repository, including the entire history of changes. This design allows developers to work offline, commit changes locally, and later synchronize with the central repository when they are ready to share their work. This local approach not only enhances speed—since most operations are performed on the local repository—but also improves collaboration by allowing multiple branches to be created and merged with ease.
Another key difference is Git's branching and merging capabilities. Git encourages frequent branching, making it simple to experiment with new features or fixes without risking the stability of the main codebase. The merging process in Git is typically straightforward and can often be done automatically, whereas other systems may require more manual intervention.
Git also employs a unique data structure that records changes as snapshots rather than deltas (differences between file versions). This enables efficient storage and retrieval of project history and simplifies tasks like viewing past states of the project or restoring files.
Overall, Git’s distributed nature, efficient branching model, and snapshot-based history make it a powerful tool for managing complex software projects and facilitating collaboration among teams.
Git offers several compelling advantages that have contributed to its widespread adoption in software development:
In summary, Git's distributed nature, speed, flexible branching and merging, robust history management, and strong collaboration features make it an ideal choice for modern software development projects, enabling teams to work more effectively and efficiently.
In Git, a repository (often abbreviated as "repo") is a storage space where your project files, along with their entire history, are kept. A Git repository contains all the necessary metadata for the project, including all changes made to the files, the history of those changes, branches, tags, and other configurations.
There are two types of repositories in Git: local and remote.
Each repository has a .git directory that contains all the information about the repository, including its history, branches, and configuration settings. The use of repositories allows teams to manage their projects systematically, track changes over time, and collaborate with ease.
Summary: A Git repository is a storage space for project files and their history, consisting of local (on a developer's machine) and remote (on a server) versions, enabling version control and collaboration.
Detailed Answer: To initialize a new Git repository, you typically use the git init command. This command sets up a new Git repository in the current directory, creating a .git subdirectory that contains all the necessary metadata for version control.
Here’s how to do it:
Navigate to Your Project Directory: Use the cd command to change into the directory where you want to create the repository. If the directory doesn’t exist yet, you can create it using mkdir my-project and then navigate into it.
mkdir my-project
cd my-project
Run the Git Init Command: Execute the following command to initialize the Git repository.
git init
This command will create a new subdirectory called .git, which contains all the necessary files and directories for Git to track the project. After this, your directory is now a Git repository, and you can start adding files and committing changes.
In summary, initializing a new Git repository is straightforward: navigate to your project directory, run git init, and you’re ready to start version controlling your project.
Summary: To initialize a new Git repository, navigate to your project directory in the terminal and run git init. This creates a .git directory to manage version control.
Detailed Answer: The .git directory is a crucial component of any Git repository, serving as the storage area for all the information that Git needs to manage the project. When you initialize a new Git repository using git init, Git creates this hidden directory at the root of your project. The .git directory contains several important elements:
Overall, the .git directory is essential for Git's functionality, storing all the necessary data for version control, including history, configurations, and current project states. Understanding this directory is key to grasping how Git operates and manages projects.
Summary: The .git directory is a hidden folder that contains all the information Git needs to manage the repository, including configuration files, an object database, references, the current state pointer (HEAD), and the staging area.
Detailed Answer: To check the status of your Git repository, you use the git status command. This command provides valuable information about the current state of the repository, helping you understand what changes have been made and what actions are required. Here’s how it works:
Run the Git Status Command: Simply type the following command and press Enter:
git status
This command is particularly useful before making a commit, as it allows you to see what changes are staged, what modifications exist that are not yet staged, and whether there are any untracked files in your working directory. It serves as a way to review your current work and ensure everything is in order before proceeding with further actions.
Summary: To check the status of your Git repository, use the git status command, which displays the current branch, staged and unstaged changes, and untracked files, helping you manage your workflow effectively.
Detailed Answer: To add files to the staging area in Git, you use the git add command. This command is essential for preparing changes to be committed to the repository. When you modify files in your working directory, Git tracks those changes, but they need to be staged before they can be included in the next commit. Here’s how to use the git add command:
To add a specific file, you can run:
git add <filename>
Replace <filename> with the name of the file you want to stage. For example:
git add index.html
To add all modified files in the current directory and subdirectories, use:
git add If you want to add all changes (including deletions and new files), you can run:
git add -A
Staging files with git add is a crucial step in the Git workflow, as it allows you to select exactly what changes you want to include in the next commit. This selective staging helps maintain a clean and organized commit history.
Summary: To add files to the staging area in Git, use the git add <filename> command for specific files, git add . for all modified files, or git add -A for all changes, preparing them for the next commit.
Detailed Answer: Committing changes in Git is the process of saving your staged changes to the repository, effectively creating a snapshot of your project at that point in time. To commit changes, you use the git commit command followed by an optional message that describes the changes made. Here’s how to do it:
Run the Git Commit Command: To commit your changes, use the following command:
git commit -m "Your commit message here"Replace "Your commit message here" with a descriptive message that summarizes the changes you made. For example:
git commit -m "Fix bug in the login feature"
Committing changes is an essential part of using Git, as it allows you to save your work incrementally and provides a detailed history of project development. Good commit messages are important as they help team members (and your future self) understand the rationale behind changes.
Summary: To commit changes in Git, ensure your changes are staged with git add, then run git commit -m "Your message" to save them with a descriptive message, creating a snapshot of your project.
Detailed Answer: A commit message is a brief description that accompanies a commit in Git. It serves as a log entry, explaining what changes were made and why they were necessary. When you commit changes, the message becomes part of the project’s history, allowing others (and yourself) to understand the context behind those changes in the future.
Commit messages are important for several reasons:
Best Practices for Writing Commit Messages:
In summary, commit messages are vital for maintaining an understandable and navigable project history in Git. They enhance communication among team members and serve as documentation for the decisions made throughout the development process.
Summary: A commit message is a description accompanying a Git commit, crucial for documenting changes, facilitating team communication, aiding debugging, and providing context for project evolution. Good practices include being concise, using the imperative mood, and referencing related issues.
Detailed Answer: To view the commit history in Git, you use the git log command. This command provides a detailed list of all commits in the current branch, displaying essential information such as the commit hash, author, date, and the commit message. Here’s how to use it:
Run the Git Log Command: Simply type:bash
git log
To view a more condensed log, you can use:
git log --oneline
To see a specific number of recent commits, you can specify:
git log -n 5
For a graphical representation, you can use:
git log --graph --oneline --decorate
By utilizing the git log command, developers can effectively trace the history of a project, understand the progression of changes, and identify when specific modifications were made.
Summary: To view the commit history in Git, use the git log command, which lists all commits in the current branch, displaying the commit hash, author, date, and message.
Detailed Answer: git pull and git fetch are both commands used to update your local repository with changes from a remote repository, but they serve different purposes and operate differently:
Example usage:
git fetch origin
Example usage:
git pull origin main
In summary, use git fetch when you want to update your remote tracking branches and review changes before merging. Use git pull when you want to incorporate those changes directly into your current branch.
Summary: git fetch updates your remote tracking branches without merging, while git pull fetches changes and merges them into your current branch, combining both actions.
Detailed Answer: Creating a new branch in Git is a straightforward process that allows you to develop features or fix bugs independently from the main codebase. Here’s how to do it:
Check Current Branch: Before creating a new branch, you might want to check which branch you are currently on:
git branch
Create a New Branch: To create a new branch, use the git branch command followed by the name of the new branch:
git branch <new-branch-name>
For example:
git branch feature/new-login
Switch to the New Branch: After creating the branch, you need to switch to it to start working. You can do this with:
git checkout <new-branch-name>
Alternatively, you can combine these two steps into one using:
git checkout -b <new-branch-name>
Branching is a powerful feature in Git, allowing for parallel development and the ability to experiment with new ideas without affecting the main branch.
Summary: To create a new branch in Git, use git branch <new-branch-name> to create it, and then switch to it using git checkout <new-branch-name>, or combine both steps with git checkout -b <new-branch-name>.
Detailed Answer: Branching in Git serves as a powerful feature that allows developers to diverge from the main line of development and work on new features, bug fixes, or experiments independently. The primary purposes of branching include:
In summary, branching in Git is essential for organizing development workflows, enabling parallel work, isolating changes, and facilitating smoother integration of features and fixes.
Summary: Branching in Git allows for isolated development of features and fixes, enabling parallel work, simplified merging, experimentation, and better version control, ultimately leading to a more organized project history.
Detailed Answer: Switching between branches in Git is a simple process that allows you to move your working directory to a different branch. Here’s how to do it:
Check Current Branch: You can check which branch you are currently on using:
git branch
Switch Branches Using Checkout: To switch to a different branch, use the git checkout command followed by the name of the branch you want to switch to:
git checkout <branch-name>
For example:
git checkout feature/new-loginUsing Git Switch: In newer versions of Git (2.23 and later), you can also use the git switch command, which is specifically designed for switching branches. This command is more intuitive and straightforward:
git switch <branch-name>
Handling Uncommitted Changes: If you have uncommitted changes in your working directory that would be affected by switching branches, Git will prevent you from switching until you either commit or stash those changes. You can stash changes using:
git stash
By effectively switching between branches, developers can work on different features or fixes without losing track of their changes.
Summary: To switch between branches in Git, use git checkout <branch-name> or the newer git switch <branch-name>, confirming the switch with git branch and managing any uncommitted changes beforehand.
Detailed Answer: The git merge command is used to integrate changes from one branch into another. It is a fundamental part of the Git workflow, enabling the combination of different lines of development. Here’s how it works:
Switch to the Target Branch: Before merging, you must switch to the branch that you want to merge changes into. For example, if you want to merge changes into the main branch, you would do:
git checkout main
Run the Merge Command: To merge another branch (let's say feature/new-login) into your current branch, run:
git merge feature/new-login
Conflict Resolution: If there are conflicting changes that Git cannot automatically resolve, it will mark those conflicts in the files. You will need to manually edit the files to resolve conflicts and then stage the resolved changes using git add. Finally, complete the merge with:
git commit
Merging is a powerful feature that enables collaborative development and keeps project histories clean and organized.
Summary: The git merge command integrates changes from one branch into another, using fast-forward or three-way merging methods, and may require conflict resolution when changes conflict.
Detailed Answer: A conflict in Git occurs when two branches contain changes to the same line in a file or when one branch modifies a file while another branch deletes it. This situation arises during the merging process when Git cannot automatically reconcile differences between branches.
Here’s how to understand and resolve conflicts:
Identify Conflicts: When you attempt to merge branches and Git encounters conflicts, it will stop the merge process and provide a message indicating which files have conflicts. You can check the status with:
git status
Open the Conflicted Files: Conflicted files will contain conflict markers that indicate the differing changes. The markers look like this:
<<<<<<< HEAD
Your changes in the current branch
=======
Changes from the branch being merged
>>>>>>> feature/new-login
Stage Resolved Changes: Once you have resolved the conflicts, stage the changes with:
git add <conflicted-file>
Complete the Merge: After staging all resolved files, finalize the merge with:
git commit
Handling conflicts effectively is essential for maintaining a smooth collaborative workflow in Git. Good communication with team members can also help minimize conflicts.
Summary: A conflict in Git arises when changes in two branches cannot be automatically merged, typically affecting the same lines in files. To resolve conflicts, edit the affected files to combine changes, remove conflict markers, stage the resolved files, and complete the merge with a commit.
Detailed Answer: Deleting a branch in Git is a straightforward process that can help keep your repository clean and organized by removing branches that are no longer needed. There are two types of branches you may want to delete: local branches and remote branches.
Deleting a Local Branch:
Check Your Current Branch: Before deleting a local branch, ensure you are not currently on that branch. You can check your current branch with:
git branch
Delete the Local Branch: To delete a local branch, use the following command:
git branch -d <branch-name>
For example, to delete a branch named feature/new-login, you would run:
git branch -d feature/new-login
If the branch has unmerged changes and you are sure you want to delete it, use the -D flag to force the deletion:
git branch -D feature/new-login
Deleting a Remote Branch:
Delete the Remote Branch: To delete a branch on a remote repository (e.g., origin), you can use:
git push origin --delete <branch-name>
For instance, to delete the same branch on the remote, you would run:
git push origin --delete feature/new-login
For local branches:
git branch
For remote branches:
git branch -r
Deleting branches that are no longer in use helps maintain clarity in your repository and reduces clutter.
Summary: To delete a local branch in Git, use git branch -d <branch-name>. To delete a remote branch, use git push origin --delete <branch-name>, keeping your repository organized.
Detailed Answer: The staging area, also known as the index, is a critical component of the Git workflow. It acts as an intermediary space where changes are prepared before being committed to the repository. Here’s a more detailed explanation of its purpose and functionality:
Inspecting the Staging Area: You can inspect the contents of the staging area using the git status command, which shows you which changes are staged for commit and which are not. Additionally, you can use:
git diff --cached
For example:
git checkout -- index.htmlUnstage Changes: If you have staged changes that you want to unstage (i.e., move them back to the working directory), you can use:
git reset <filename>
Soft Reset: This keeps your changes in the working directory and unstages them:
git reset --soft HEAD~1
Mixed Reset: This keeps your changes in the working directory and removes them from the staging area:
git reset HEAD~1
Hard Reset: This completely removes the commit and all changes associated with it, reverting your working directory to the state of the previous commit:
git reset --hard HEAD~1
Reverting a Commit: If you want to create a new commit that undoes the changes made by a previous commit without modifying the commit history, you can use the git revert command:
git revert <commit-hash>
Using Stash for Temporary Changes: If you want to temporarily set aside your changes without committing them, you can stash them using:
git stash
Understanding how to effectively undo changes in Git is crucial for maintaining the integrity of your project and managing your development workflow.
Summary: To undo changes in Git, you can discard changes in the working directory with git checkout -- <filename>, unstage files with git reset <filename>, undo commits with git reset or git revert, and temporarily set aside changes using git stash.
Detailed Answer: In Git, HEAD is a special pointer that refers to the current branch and the latest commit on that branch. It is a crucial concept for understanding how Git manages versions and navigates through the commit history.
Understanding HEAD is vital for managing your work effectively in Git, as it provides context for where you are in the commit history.
Summary: HEAD in Git is a pointer to the current branch's latest commit, enabling navigation through commit history and indicating your current position in the repository.
Detailed Answer: To check the differences between commits in Git, you can use the git diff command, which allows you to view changes made between two commits or between a commit and your working directory. Here’s how to do it:
Comparing Two Commits: If you want to see the differences between two specific commits, you can use:
git diff <commit-hash1> <commit-hash2>
Comparing Against HEAD: To view the differences between a specific commit and the current state of your working directory (i.e., HEAD), you can run:
git diff <commit-hash>
Comparing with Previous Commits: You can also use relative references like HEAD to compare with previous commits:
git diff HEAD~1 HEAD
Checking Changes in Staging Area: If you want to see what changes are staged for the next commit compared to the last commit, you can use:
git diff --cached
Using git diff effectively allows you to review changes and understand the evolution of your project.
Summary: To check differences between commits in Git, use git diff <commit-hash1> <commit-hash2> for specific commits, git diff <commit-hash> to compare against the current state, and git diff --cached to see staged changes.
Detailed Answer: A remote repository in Git is a version of your project that is hosted on a server, allowing for collaboration and sharing among multiple users. Here are key aspects of remote repositories:
Tracking Remotes: In Git, a remote repository is typically referenced by a name (usually origin for the primary remote). You can view your configured remotes with:
git remote -v
Pushing and Pulling Changes: You can push local changes to the remote repository using:
git push origin <branch-name>
Conversely, to fetch changes from the remote repository, you use:
git pull origin <branch-name>
In summary, remote repositories are essential for collaborative software development, providing a centralized location for sharing and managing code.
Summary: A remote repository in Git is a server-hosted version of your project that facilitates collaboration, allowing multiple users to push and pull changes, commonly hosted on platforms like GitHub or GitLab.
Detailed Answer: Cloning a repository in Git is the process of creating a local copy of a remote repository, allowing you to work on the project on your own machine. Here’s how to clone a repository:
Use the git clone Command: In the terminal, use the git clone command followed by the repository URL:
git clone <repository-url>
For example:
git clone https://github.com/user/repo.git
Directory Creation: By default, cloning a repository creates a new directory with the same name as the repository. If you want to clone it into a specific directory, you can specify the directory name as an additional argument:
git clone <repository-url> <directory-name>
Navigating into the Directory: After cloning, navigate into the newly created directory:
cd <repo-name>
Verify the Clone: You can verify that the clone was successful by checking the remote configuration:
git remote -v
Cloning a repository is often the first step in contributing to an existing project, as it sets up a local workspace that mirrors the remote version.
Summary: To clone a repository in Git, use the command git clone <repository-url>, which creates a local copy of the remote repository, enabling you to work on the project locally.
Detailed Answer: Pushing changes to a remote repository in Git involves transferring your local commits to a remote server, making your changes available to others. Here’s how to do it:
Make Your Changes: Ensure you have made and committed your changes locally. Use the following commands to stage and commit your changes if you haven’t done so:
git add <file-name>
git commit -m "Your commit message"
Check Your Current Branch: Make sure you are on the correct branch from which you want to push changes. You can check your current branch with:
git branch
Push Your Changes: Use the git push command to send your commits to the remote repository. The basic syntax is:
git push <remote-name> <branch-name>
For example, to push changes to the main branch of the default remote (usually named origin), you would run:
git push origin main
Dealing with Upstream Branches: If you are pushing a branch for the first time, you may want to set the upstream reference so that you can use git push and git pull without specifying the remote and branch every time. You can do this by using:
git push -u origin <branch-name>
Verification: After pushing, you can verify that your changes are reflected in the remote repository by checking the repository on its hosting platform or running:
git status
Pushing changes is a critical part of collaborative workflows, ensuring that team members have access to the latest updates.
Summary: To push changes to a remote repository in Git, use git push <remote-name> <branch-name> after committing your changes locally. Use -u to set upstream tracking for easier future pushes.
Detailed Answer: In Git, a tag is a reference that points to a specific commit, typically used to mark significant points in the project’s history, such as releases or milestones. Tags are a way to create a snapshot of your repository at a certain point in time.
For a lightweight tag:
git tag <tag-name>
For an annotated tag:
git tag -a <tag-name> -m "Tag message"
Viewing Tags: You can list all tags in your repository with:
git tag
Pushing Tags: By default, tags are not pushed to remote repositories when you push branches. To push a specific tag, you would use:
git push origin <tag-name>
To push all tags, use:
git push --tags
Summary: A tag in Git is a reference that points to a specific commit, used to mark significant points in the project history. Tags can be lightweight or annotated, with annotated tags providing more context.
Detailed Answer: Creating a tag in Git is a straightforward process that helps you mark specific points in your project’s history, such as releases or significant milestones. Here’s how to create both lightweight and annotated tags:
Choose the Commit to Tag: If you want to tag the most recent commit, you can skip this step. However, if you wish to tag a specific commit, you will need the commit hash. You can find it using:
git log
Creating a Lightweight Tag: To create a lightweight tag, use the following command:
git tag <tag-name>
For example:
git tag v1.0
Creating an Annotated Tag: For an annotated tag, which includes additional information, use:
git tag -a <tag-name> -m "Tag message"
For example:
git tag -a v1.0 -m "Version 1.0 release"
Tagging a Specific Commit: If you want to tag a specific commit, you can add the commit hash at the end of the tag command:
git tag -a <tag-name> <commit-hash> -m "Tag message"
Verifying Tags: To see the tags you’ve created, run:
git tag
Pushing Tags to Remote: After creating a tag, if you want to share it with others, you need to push it to the remote repository:
git push origin <tag-name>
Creating tags is an important part of managing project versions, allowing for easy reference and retrieval in the future.
Summary: To create a tag in Git, use git tag <tag-name> for a lightweight tag or git tag -a <tag-name> -m "Tag message" for an annotated tag, optionally specifying a commit hash.
Detailed Answer: In Git, there are two types of tags: lightweight and annotated. Understanding the difference between these two types is crucial for effectively managing your project’s versioning.
Lightweight Tag:
git tag v1.0
Annotated Tag:
git tag -a v1.0 -m "Release version 1.0"
Summary: Lightweight tags are simple pointers to commits without metadata, while annotated tags are full objects that include the tagger's information and a message, making them better suited for versioning releases.
Detailed Answer: Reverting a commit in Git is a way to create a new commit that undoes the changes made by a previous commit. This approach is particularly useful for maintaining a clear project history without altering existing commits. Here’s how to revert a commit:
Identify the Commit: First, identify the commit you want to revert. You can view the commit history using:
git log
Revert the Commit: Use the git revert command followed by the commit hash:
git revert <commit-hash>
For example:
git revert abc1234
Handling Conflicts: If the commit you are reverting introduces changes that conflict with subsequent commits, Git will pause the revert process and notify you of conflicts. You will need to resolve these conflicts manually in the affected files, stage the resolved files using git add, and then complete the revert with:
git commit
Check the New Commit: After reverting, you can check your commit history to see the new commit that undoes the changes:
git log
Push Changes: If you are working with a remote repository, you may want to push your changes after reverting:
git push origin <branch-name>
Reverting a commit is a safe way to undo changes while preserving the commit history, making it easier for team members to understand the evolution of the project.
Summary: To revert a commit in Git, use git revert <commit-hash>, which creates a new commit that undoes the specified commit's changes. Resolve any conflicts if necessary, and push changes to the remote repository afterward.
Detailed Answer: A fork in Git, particularly in the context of platforms like GitHub, GitLab, and Bitbucket, is a copy of a repository that allows you to freely experiment and make changes without affecting the original project. Here’s a closer look at forks:
Summary: A fork in Git is a copy of a repository that allows for independent development and experimentation. It’s commonly used to contribute to open-source projects, enabling users to make changes and submit them for review without affecting the original repository.
Detailed Answer: Untracked files in Git are files that exist in your working directory but are not being tracked by Git. This means they have not been added to the staging area and are not included in commits. Here’s how to handle them:
Identifying Untracked Files: You can see which files are untracked by running:
git status
Adding Untracked Files: If you want to track an untracked file, you can add it to the staging area with:
git add <file-name>
For example:
git add newfile.txt
Removing Untracked Files: If you want to remove untracked files, you can use the git clean command. Be cautious with this command as it permanently deletes untracked files:
git clean -f
You can also use -d to remove untracked directories and -n to preview what would be deleted:
git clean -fdn
Handling untracked files effectively ensures that your project remains clean and that only relevant files are included in version control.
Summary: To handle untracked files in Git, use git add <file-name> to start tracking them, utilize a .gitignore file to exclude certain files, or use git clean to remove untracked files safely.
Detailed Answer: To view the configuration settings in Git, you can use the git config command. This command allows you to see all the configuration settings at different levels (system, global, and local). Here’s how to do it:
View All Configurations: To see all configuration settings, you can run:
git config --list
Check Specific Configuration: If you want to check a specific configuration setting, use:
git config <key>
For example, to check your user email:
git config user.email
System Level: To view system-wide settings (for all users on the system), use:
git config --system --list
Global Level: To view settings specific to your user account, use:
git config --global --listLocal Level: To view settings specific to the current repository, simply use:
git config --local --list
Editing Configuration: You can also use the git config command to modify settings directly. For example, to set your user name globally:
git config --global user.name "Your Name"
Viewing and managing configuration settings is essential for customizing your Git environment and ensuring your commits are associated with the correct identity.
Summary: To view Git configuration settings, use git config --list for all configurations or git config <key> for specific settings. Configuration can be scoped to system, global, or local levels.
