What Git Skills Do You Need to Work in a Company?
Master essential Git skills for professional software development. Learn branching strategies, conflict resolution, pull requests, rebasing, and collaboration workflows used in real-world company environments.

Understanding Git Branching
What is a Git Branch?
A Git branch is a pointer to a specific snapshot of your repository, allowing you to work on different parts of a project independently. Each branch can exist independently, enabling parallel development and collaboration without affecting the main codebase.
Types of Branches: Main, Feature, and Hotfix
- Main Branch (e.g.,
main,master): The main branch is the default branch in a Git repository and holds the stable, production-ready code. - Feature Branch: Created to develop a specific feature or functionality. It allows developers to work on isolated changes without affecting the main branch.
- Hotfix Branch: Used for urgent fixes in the production environment. Hotfix branches are created from the main branch and merged back into it after the fix is applied.
Best Practices for Creating and Managing Branches
- Use descriptive names for branches (e.g.,
feature/login-form,hotfix/server-crash) - Keep branches focused on a single feature or task
- Regularly sync feature branches with the main branch to minimize conflicts
- Delete branches after merging them to keep the repository clean
How Git Branching Works in Teams
Collaboration Using Branches
In a team setting, each developer works on their own branch, which can later be merged into a shared branch (like main or develop). This approach prevents code conflicts and allows simultaneous development without disruptions.
Tracking Changes Across Multiple Branches
Git allows you to easily track changes by showing differences between branches. You can use git diff to view changes or git log to track the commit history across branches.
Merging Branches Without Conflicts
Before merging branches, it's important to pull the latest changes from the remote repository and resolve any conflicts locally. Tools like git merge and git rebase help integrate changes, but best practices for conflict prevention include keeping feature branches up to date and making small, frequent commits.
Configuring Multiple Emails in Git
Using Different Emails for Work and Personal Projects
You might want to use different email addresses for different repositories — one for work projects and another for personal projects. Git allows you to configure multiple email addresses at the repository level.
Configuring Git to Handle Two Emails
To set different emails for different repositories:
git config user.email "[email protected]" # for work repo
git config user.email "[email protected]" # for personal repo
Verifying Email Configuration in Commits
To check the email associated with your commits, use the following command:
git log --format='%ae'
This will display a list of emails used for each commit.
Using GitHub Commit URL:
You can view the commit details by appending .patch to the commit URL:
https://github.com/{username}/{repository}/commit/{commit_hash}.patch
Example:
https://github.com/Dheerajjha451/Design2Code/commit/be7b187393e120e853a68b060c121ddea199f7de.patch
Resolving Git Conflicts
What Causes Merge Conflicts?
Merge conflicts occur when changes are made to the same line in the same file on two different branches. Conflicts can also arise when one branch deletes a file that the other modifies.
Steps to Resolve Conflicts Using Git Commands
- Identify conflicts using
git status - Open the conflicting files and manually resolve conflicts by choosing which changes to keep
- After resolving, add the resolved files using
git add <file> - Complete the merge with
git commit
Tools to Simplify Conflict Resolution in Git
Many IDEs have built-in Git conflict resolution tools. You can also use external tools like:
- VS Code: Provides a visual interface for conflict resolution
- KDiff3: A cross-platform merge tool
- GitKraken: A Git GUI with powerful conflict management
Steps to Follow Before Creating a Pull Request (PR)
Reviewing Code Changes Locally
Use git diff to review changes in your working directory before creating a PR. This helps you ensure that your changes are as expected.
Fetching the Latest Changes from the Remote Repository
Before creating a PR, always pull the latest changes from the remote repository:
git fetch origin
git rebase origin/main
Rebase vs. Merge: Which Should You Use?
- Rebase: Rewrites the commit history, creating a cleaner and linear history
- Merge: Combines changes and creates a new merge commit. This is simpler but can lead to more complex history
Testing Your Code Before Pushing
Always run tests locally and ensure that your code is working as expected before pushing it to a remote branch.
How to Assign a PR for Review
Assigning the PR to a Maintainer
When opening a PR, assign it to a project maintainer or reviewer who is responsible for code review and approval.
Using GitHub, GitLab, or Bitbucket to Notify Reviewers
In platforms like GitHub, GitLab, or Bitbucket, you can add reviewers or request a review directly in the PR interface. Notifications will be sent to the assigned reviewers.
Best Practices for PR Assignment in Teams
- Assign at least one reviewer who is familiar with the codebase
- Add a description that outlines the purpose of the PR and any special instructions
How Git Rebase Works
Differences Between Merge and Rebase
- Merge: Combines branches with a new merge commit
- Rebase: Applies commits from one branch onto another without a merge commit, keeping the history linear
Advantages and Disadvantages of Rebasing
Advantages: Cleaner, linear commit history
Disadvantages: Can be risky when working in shared branches, as it rewrites history
How to Rebase Without Losing Changes
Always rebase local branches against the remote:
git fetch origin
git rebase origin/main
Resolve any conflicts and then push your changes.
Methods to Switch and Create Git Branches
Git Checkout Command to Switch Branches
Use the git checkout command to switch branches:
git checkout <branch_name>
Using Git Switch for Better Workflow
git switch is a newer, more intuitive command for switching branches:
git switch <branch_name>
Creating New Branches Using Git Commands
To create a new branch:
git branch <new_branch_name>
Or, create and switch to a new branch in one step:
git checkout -b <new_branch_name>
Creating a Pull Request (PR)
What is a Pull Request?
A pull request (PR) is a request to merge your changes into another branch, typically the main branch. It allows others to review and approve your code before it's merged.
Steps for Creating a PR
- Push your branch to the remote repository
- Go to the repository on GitHub, GitLab, or Bitbucket
- Select "Create Pull Request"
- Add a meaningful title and description
- Assign reviewers and submit the PR
Review Process for Merging PRs
Reviewers will comment on your PR with feedback, request changes, or approve it. Once all required approvals are obtained, the PR can be merged into the target branch.
Best Practices for Working with Git in a Team
Establishing a Git Workflow: GitFlow, GitHub Flow, etc.
Popular workflows include:
- GitFlow: Branching model with develop, feature, and release branches
- GitHub Flow: Simpler model focused on main and feature branches
- Trunk-based development: Continuous integration with frequent merges into the main branch
Naming Conventions for Branches and Commits
- Use clear and descriptive branch names (e.g.,
feature/login-form) - Write concise commit messages that explain what the commit does
Using Tags for Version Control
Tags are useful for marking releases. To create a tag:
git tag -a v1.0 -m "Version 1.0 release"
git push origin --tags
Using Git Remotes for Collaboration
What is a Git Remote?
A remote is a reference to a remote repository. You use remotes to fetch or push code to shared repositories.
How to Add and Manage Multiple Remotes
To add a new remote:
git remote add <name> <url>
You can fetch from multiple remotes by using their names.
Fetching and Pulling Changes from Multiple Remotes
To fetch changes from all remotes:
git fetch --all
You can also pull changes from a specific remote with:
git pull <remote_name> <branch>
Monitoring Changes in Git
Using Git Log to Track Commits
The git log command shows the commit history for a repository. You can format it to display details like the author, date, and changes made.
Viewing Branch History with Git Commands
To view the history of a specific branch:
git log <branch_name>
Using Diff Tools to Compare Changes
Use git diff to compare changes between branches, commits, or working states. Many GUI tools can also provide visual diffs.
Working with Git Stash
Saving Uncommitted Work with Git Stash
Git stash allows you to temporarily save your uncommitted changes:
git stash
This is useful if you need to switch branches but aren't ready to commit your changes.
How to Apply Stashed Changes to Different Branches
To apply stashed changes to your current branch:
git stash apply
You can also specify a particular stash using git stash apply stash@{0}.
Cleaning Up Stashed Work to Avoid Clutter
Once you're done with a stash, you can delete it using:
git stash drop
Or clean all stashes:
git stash clear
Avoiding Common Git Mistakes
How to Avoid and Recover from Mistakes in Git
- Always pull the latest changes before starting new work
- Commit frequently with descriptive messages
Reverting Commits Safely
To undo a commit without losing the changes:
git revert <commit_hash>
Resetting vs. Reverting: When to Use Each
- Reset: Moves the branch pointer to an earlier commit, altering the commit history
- Revert: Creates a new commit that undoes the changes of a previous commit without modifying the history