Git & GitHub: Branching and Conflict Resolution Guide

author
By Vikram Singh

5/22/2026

2

Master the essentials of Git version control. Learn how to manage branches, collaborate on GitHub, and resolve merge conflicts like a pro software engineer.

image

When students transition from writing solo code for college assignments to working on collaborative software projects, they inevitably encounter version control. Git and GitHub are the undisputed industry standards for managing source code.

While learning the basic git commit and git push commands takes only a few minutes, real-world software development requires understanding how to manage parallel feature branches and how to resolve the dreaded "merge conflicts" without breaking the main application.

In this guide, we break down the Git workflow, explain how branching works under the hood, and provide a step-by-step strategy for resolving merge conflicts.


Table of Contents

  1. Git vs. GitHub: What's the Difference?
  2. The Core Git Workflow (Local vs. Remote)
  3. Mastering Feature Branching
  4. Pull Requests and Code Reviews
  5. How to Safely Resolve Merge Conflicts
  6. Frequently Asked Questions (FAQs)
  7. Conclusion

1. Git vs. GitHub: What's the Difference?

Before diving into commands, you must understand the distinction between the two:

  • Git is a command-line software installed on your local computer. It tracks changes to files and manages version history locally.
  • GitHub is a cloud-based hosting service that stores Git repositories online. It provides a web interface for collaboration, issue tracking, and code reviews.

You can use Git without GitHub, but using GitHub without Git defeats its primary purpose.


2. The Core Git Workflow (Local vs. Remote)

Git operates across three primary local "trees" (areas) before interacting with the remote GitHub server.

  1. Working Directory: The actual files you are currently editing in VS Code.
  2. Staging Area (Index): Where you "stage" files that are ready to be committed using git add <file>.
  3. Local Repository (HEAD): Where your commits are permanently saved locally using git commit -m "Message".
  4. Remote Repository: The server (GitHub) where you push your local commits using git push origin <branch>.

3. Mastering Feature Branching

In professional environments, you never push code directly to the main or master branch. Instead, developers use a "Feature Branch" workflow.

A branch is essentially a lightweight, independent pointer to a specific commit. When you create a branch, you create an isolated environment to test new features without affecting the stable main codebase.

Branching Commands:

  • Create and switch to a new branch: git checkout -b feature/login-page
  • View all branches: git branch
  • Switch back to main: git checkout main

By working on feature/login-page, you can write code, make mistakes, and commit freely. If the feature fails, you can simply delete the branch without touching the production code.


4. Pull Requests and Code Reviews

Once you have finished developing your feature on your branch, how do you merge it back into the main branch?

In modern workflows, you do not merge it locally. Instead, you push your feature branch to GitHub and open a Pull Request (PR).

  1. Push the branch: git push origin feature/login-page
  2. Go to GitHub and click "Compare & pull request".
  3. A PR allows senior developers to review your code, leave comments, and request changes before the code is merged into main.

5. How to Safely Resolve Merge Conflicts

A merge conflict is often the most terrifying thing a beginner developer encounters. However, it is a completely normal part of working in any collaborative team. A conflict occurs when two different branches have modified the exact same line in the same file, or when one developer deletes a file that another developer is actively editing. Because Git is extremely cautious, it refuses to guess which version is correct and instead pauses the merge, handing the control back to you.

A. The Anatomy of a Merge Conflict

When you attempt to pull changes from main or merge a branch (git merge main), and Git detects a conflict, it will stop and output an error message saying: "Automatic merge failed; fix conflicts and then commit the result."

If you open the conflicted files in an editor (like VS Code), you will see that Git has highlighted the problem area using standard conflict markers:

<<<<<<< HEAD
const buttonColor = "blue"; // Your local changes on the current branch
=======
const buttonColor = "green"; // The incoming changes from the branch you are merging
>>>>>>> feature/update-ui

To resolve this conflict, you must:

  1. Analyze: Decide which line of code is correct. Sometimes it is your code (HEAD), sometimes it is their code (incoming), and sometimes you need to combine parts of both.
  2. Clean: Manually delete the conflict marker lines (<<<<<<<, =======, >>>>>>>).
  3. Save: Edit the text until it looks exactly the way it should, then save the file.

B. Step-by-Step Resolution via Command Line

Here is the precise command line workflow to handle conflicts safely:

  1. Check Conflicted Files: Type git status to see exactly which files are blocking the merge. They will be marked as both modified.
  2. Open and Edit: Open each conflicted file in VS Code. If you are using VS Code, look for the helpful inline buttons at the top of the conflict block:
    • Accept Current Change: Keeps your local code (blue).
    • Accept Incoming Change: Overwrites your code with the remote branch's code (green).
    • Accept Both Changes: Keeps both lines of code.
  3. Stage the Fixes: Once all files are resolved and saved, stage them to tell Git you are finished:
    git add path/to/resolved-file.js
    
  4. Finalize the Merge: Run a normal commit without a message flag. Git will automatically generate a default merge commit message like "Merge branch 'main' of repository":
    git commit
    

C. Proactive Strategies to Avoid Merge Conflicts

While you cannot eliminate conflicts entirely, you can minimize their frequency by adopting these professional best practices:

  • Pull Frequently: Never work in isolation for days. Run git pull origin main every morning to ensure your local branch is synchronized with the latest changes from your teammates.
  • Keep Branches Small and Focused: Do not try to build five different features in a single branch. Keep your branches extremely small and merge them quickly. Smaller branches mean fewer overlapping modifications.
  • Communicate with Your Team: If you are about to refactor a core component (like a main layout file or database helper), let your team know on Slack or WhatsApp. This prevents others from making overlapping changes at the same time.

6. Frequently Asked Questions (FAQs)

Q1. What is the difference between git fetch and git pull?

git fetch downloads the latest changes from the remote repository to your local machine but does not merge them into your working directory. git pull does both: it fetches the data and immediately attempts to merge it into your current branch.

Q2. I accidentally committed something wrong. How do I undo it?

If you haven't pushed it to GitHub yet, use git reset HEAD~1. This removes the last commit but keeps your file changes in the working directory so you can edit them.

Q3. What should go in a .gitignore file?

The .gitignore file tells Git which files to ignore. Always include node_modules/, environment variable files (.env), and OS-generated files like .DS_Store.


7. Conclusion

Mastering Git branching and conflict resolution removes the fear of breaking the codebase and allows you to collaborate seamlessly with other developers. Start using branches for every new assignment or project feature, push your code to GitHub, and practice resolving conflicts. It is one of the most practical skills you can develop before your first internship!

Suggested Images:

  • Featured Image: A sleek vector graphic showing a Git branch diverging and merging back into a main timeline. (Prompt: Git branching and merging timeline visualization, tech vector graphic, clean dark theme).
  • Inline Image: A screenshot of VS Code's merge conflict resolution interface.

Alt Texts:

  • Featured Image: "Git branching and merging version control timeline"
  • Inline Image: "VS Code git merge conflict resolution interface"

Internal Linking Suggestions:

Popular Tags :

Share this post :

Comments (0)

Leave a Comment

Loading comments...