What you will learn
Git is the safety net for modern development. In this lesson, you will learn the practical Git workflow used by professional teams: create a repository, work on a branch, stage related changes, write meaningful commits, sync with a remote, fix merge conflicts, and create pull requests for review.
Why Git matters in Visual Studio projects
Git records snapshots of your project over time. This lets you compare changes, restore previous versions, experiment on branches, and collaborate with others through GitHub or Azure DevOps. Visual Studio brings common Git actions into the IDE so you do not need to leave your project for basic version control work.
| Git concept | What it means | Visual Studio area |
|---|---|---|
| Repository | The folder being tracked by Git | Git menu, Git Repository window |
| Branch | A separate line of work for a feature or fix | Branch selector, Git Repository window |
| Commit | A saved snapshot of selected changes | Git Changes window |
| Remote | A hosted repository such as GitHub | Fetch, Pull, Push, Sync |
| Pull request | A review request before merging code | GitHub or Azure DevOps integration |
Configure Git before your first commit
Before using Git seriously, check your name, email, default branch preference, diff/merge settings, and repository ignore rules. This avoids confusing commit authorship and prevents generated files from entering source control.
git config --global user.name "Dr. Liew Voon Kiong"
git config --global user.email "your-email@example.com"
git config --global init.defaultBranch mainFor .NET projects, keep compiled output, local IDE files, and secrets out of Git. A simple .gitignore helps protect the repository.
bin/
obj/
.vs/
*.user
*.suo
appsettings.Development.json
*.db
*.logCreate, clone, and open repositories
You can start in three common ways: create a new project and initialize Git, clone an existing GitHub repository, or open a folder that already contains a Git repository. When Visual Studio detects a repository, it shows Git status and enables Git tools.
Open a project, choose Git > Create Git Repository, then select a local folder, GitHub, or Azure DevOps target.
Use File > Clone Repository or the Visual Studio start window, then paste the repository URL.
git clone https://github.com/yourname/storeapp.git
cd storeapp
git statusUse a safe feature-branch workflow
A feature branch lets you work without changing the main branch directly. This is especially important before large refactoring, AI-assisted edits, database migrations, or API changes.
Update main
Fetch or pull the latest changes so your branch starts from the current code.
Create a branch
Name it clearly, such as feature/orders-api or fix/cart-total-bug.
Commit in small steps
Separate unrelated work into different commits using staging and line staging.
Push and open a pull request
Ask for review before merging to main.
git switch main
git pull
git switch -c feature/orders-api
# make changes
git add .
git commit -m "feat: add orders API endpoint"
git push -u origin feature/orders-apiStage changes and write better commits
The Git Changes window shows modified, added, deleted, and untracked files. You can stage all files, stage selected files, or stage individual lines. Line staging is useful when one file contains two unrelated changes that should become separate commits.
| Task | Visual Studio action | Why it helps |
|---|---|---|
| Stage selected file | Git Changes > plus button beside file | Commit only related changes |
| Stage selected line or hunk | Use line staging in the editor/diff view | Split mixed edits into clean commits |
| Review diff | Open file from Git Changes | Catch accidental edits before commit |
| Amend last commit | Use Amend when you forgot a small change | Fix the previous commit before sharing |
feat: add orders API endpoint
fix: correct discount calculation for empty carts
refactor: move order validation into service layer
test: add unit tests for checkout rules
docs: update setup instructionsFetch, pull, push, and sync with GitHub
When working with a remote repository, your local branch and the GitHub branch can become different. Visual Studio provides buttons and menu actions for fetch, pull, push, and sync.
| Action | Meaning | When to use |
|---|---|---|
| Fetch | Download remote updates without changing your files | Before comparing or deciding what to pull |
| Pull | Fetch and integrate remote changes into your branch | Before continuing work or before pushing |
| Push | Upload your local commits to the remote branch | After local tests pass |
| Sync | Pull then push | When you want one combined update operation |
Browse history with the Git Repository window
The Git Repository window gives you a broader view of branches, commits, remotes, and history. Use it when you need to compare branches, inspect who changed a file, review old commits, cherry-pick a useful change, or understand what happened before a bug appeared.
Inspect what changed between two commits or branches before merging.
Find the last commit that touched a line and read the commit message for context.
Combine noisy work-in-progress commits before opening a pull request.
Bring a specific commit from one branch into another when needed.
Resolve merge conflicts carefully
A conflict happens when Git cannot automatically combine changes from two branches. Visual Studio marks the conflicted files and provides a merge editor so you can compare incoming changes, current changes, and the final result.
<<<<<<< HEAD
return Results.Ok(await service.GetOrdersAsync(customerId));
=======
return Results.Ok(await service.GetOrdersForCustomerAsync(customerId, includeItems: true));
>>>>>>> feature/include-order-items- Open the conflicted file from the Git Changes or Git Repository window.
- Compare current and incoming changes.
- Edit the result so the final code is correct, not merely conflict-free.
- Build and run tests after resolving all conflicts.
- Create the merge commit only after you are confident the result works.
Create pull requests for review
A pull request is where you explain what changed, why it changed, and what reviewers should check. Even if you work alone, a pull request-style review helps you catch mistakes before merging to main.
## Summary
- Added Orders API endpoint
- Added validation for missing customer id
- Added unit tests for order lookup rules
## How I tested
- Ran all unit tests
- Tested GET /api/orders/{id} manually
- Checked unauthorized request behavior
## Review notes
- Please review error handling and route namingA focused pull request is easier to review than a giant mixed change.
Do not ask others to review code that you already know fails basic tests.
Use Copilot with Git responsibly
Copilot can help explain diffs, summarize commits, find missing tests, and draft review notes. Use it as an assistant, not as the final authority. You remain responsible for the code, commit message, pull request description, and merge result.
Explain the staged changes in this branch in beginner-friendly language.
Identify risky areas, missing tests, and possible breaking changes.
Do not rewrite the code yet.Draft a concise pull request description for these changes.
Include summary, test steps, risk notes, and reviewer checklist.
Do not invent completed tests that are not shown in the diff.Review this merge conflict resolution.
Check whether both branches' intended behavior is preserved.
Suggest tests I should run before committing the merge.Git habits for professional projects
| Habit | Why it matters | Example |
|---|---|---|
| Commit before risky edits | Lets you revert safely | Before refactoring or Agent Mode |
| Keep commits focused | Makes review and rollback easier | Do not mix formatting, feature, and bug fix |
| Pull before pushing | Reduces surprise conflicts | Sync with main before PR |
| Review diffs before commit | Catches accidental edits | Inspect generated files and secrets |
| Use pull requests | Encourages review discipline | Explain what changed and how it was tested |
Hands-on exercise: Put the Orders API under Git
- Open the project you created in Lessons 5–8, or create a small ASP.NET Core Orders API.
- Create a Git repository from Visual Studio if the project is not already tracked.
- Add a useful
.gitignoreand make the first commit. - Create a branch named
feature/orders-validation. - Add simple validation logic and one test.
- Stage only the related files and write a clear commit message.
- Push the branch to GitHub and draft a pull request description.
- Ask Copilot to review the diff for missing tests, then manually verify the suggestions.
Visual Studio 2026 Made Easy
Visual Studio 2026 Made Easy gives you a structured path for learning Visual Studio, C#, .NET, debugging, testing, web development, databases, profiling, Git source control, deployment, and AI-assisted workflows.