Blog - GIT for .NET developers—part two

  • Share
  • Share

GIT for .NET developers

Part two

Stephen Weinrich | November 30, 2016

In part one of this blog series, we covered:

  • Creating a GitHub account & repository
  • Cloning
  • Creating branches
  • Committing code
  • Push vs. pull vs. fetch (aka sync)

We now continue the series with pull requests.

Pull requests

Now that we’ve pushed changes to your feature branch, we can merge them into the develop root branch so they can be deployed out to the development environment or shared with the rest of the team. Merging is done via pull requests (PR).

Pull requests are a valuable tool for reviewing changes being introduced into your branches. Teammates can use pull requests to review code, make comments, and learn more about the codebase.

To create a PR, browse to your GitHub repository and click on the New Pull Request button.

GitHub repository new pull request screenshot

Select develop as your base branch—this is the branch we want to merge into. Select feature/12345-create-console-project as your compare branch—this is the branch we’ll be merging from. The PR title and comments can be changed as needed. You can also find extra information about the pull request, such as the number of commits and file changes, at the bottom of the screenshot. Click on Create Pull Request.

GitHub repository create pull request

Before we merge this into develop, let’s take a look at the changes. Click on the Files changed tab. You can now make comments against lines of code for others to see. You can then make changes, commit the code, push to the server branch, and the PR will update automatically.

Git Merge pull request screenshot

When you’re happy with the changes, click Merge pull request and then Confirm Merge. Take a look at the develop branch—you’ll see the changes there.

Git develop branch screenshot

To see these changes in Visual Studio, switch to the develop branch on the Team Explorer—Branches window by double-clicking it, then on the Team Explorer—Changes window, select sync. This will update your local develop branch with the changes we’ve merged into the server (origin) develop branch.

Merge conflicts

Sometimes when you’re merging into a branch, another developer may have made changes to the same file you were working on. This will cause a merge conflict. To avoid this in our example, you may need to merge from develop into the feature/12345-create-console-project branch. Visual Studio has a great tool for resolving conflicts, and I recommend using it.

Go to the Team Explorer—Branches window and pull down the feature/12345-create-console-project branch. I’ve already made some changes to the develop branch that will cause a merge conflict.

Right-click the branch and select Merge from… I recommend selecting origin/develop, since this will be the most up-to-date version of the develop branch on the server. Click on the Merge button.

Git merge conflicts origin/develop

We have a conflict! Click on the Conflicts: 1 link.

Git merge conflicts

The conflict is in the Program.cs file. We have a few options:

  • Merge: VS will attempt to merge, but you’ll need to resolve each conflict manually.
  • Take Source: In our case, it’d overwrite Program.cs with the version from the develop branch.
  • Keep Target: In our case, it’d keep Program.cs with the version from our current branch, feature/12345-create-console-project. The version on develop would be overwritten.

Click the Merge button.

Git Merge conflict

The tool shows the source on the left, develop branch, and the Target on the right feature/12345-create-console-project branch. We can see that two developers have both changes the same WriteLine statement. Visual Studio is unable to resolve this, hence the conflict. You need to decide which line of code to keep. The result of your choice is displayed in the bottom window.

Git VisualStudio merge conflict console

I’ve selected the Target code, because it looks the most correct. You can see the merged result in the bottom window. Click on Accept Merge, commit it, and push/sync it up to the server. Now, when you create the PR, you won’t have any conflicts.

Using the console—GitBash

While the VS IDE exposes many common Git commands to you through its interface, these won’t always be sufficient when dealing with edge cases and other source control problems. By using the GitBash command line, you can invoke the same Git commands used by VS with a greater degree of flexibility and control.

GitBash console command line

GitBash uses a linux bash command line which may take some time getting used to. Here is a list of common GitBash commands. This is only a brief summary of the console commands available to you:

Useful resources:

  • git clone [repository-url]—Clone a repository from the server to your local machine.
  • git branch—List the branches on my local machine git branch.
  • git checkout -b [new-branch-name]—Create a new branch on your local machine based on the current branch.
  • git push -u origin [branch-name]—Publish a branch from local to the server git.
  • git checkout—Copy a branch from origin (the server) to my local machine git checkout develop.
  • git pull—Copy the latest changes from origin (the server) to my local machine for the current branch git pull.
  • git commit -m "commit message"—Commit changes to local branch git commit.
  • git stash—Temporarily store all changes. You can then switch branches, do some work, switch back, and call git stash apply (below), also useful for abandoning changes and switching to another branch git stash.
  • git stash apply—Apply temporarily stored changes to the current branch git stash apply.
  • git branch -d [branch-name]—Delete a branch from your local machine only.
  • git push origin --delete [branch-name]—Delete a branch from origin (the server).
  • git config --global credential.helper wincred—Signal git that you want to store your credentials so that you don’t need to enter them again.


Git helps create a development environment where people can branch code in a structured way, enabling us to release it in a controlled way. We use pull requests to review code and transfer knowledge of the code base across the development team. GitFlow is used on many of our projects to keep us delivering code in an agile way.

Computer screen with lines of code

Looking for more engineering tips?

Our engineers have a whole lot to say about custom software. They’re in the trenches every day, building, breaking, re-building, and sharing their hard-won wisdom along the way. Find their latest and greatest discoveries on Slalom’s new software engineering blog.

Read our engineering blog
Slalom Consulting Stephen Weinrich

Stephen Weinrich is a solution principal in Slalom’s Chicago office. He’s been delivering software and building teams for over 16 years, and is a Microsoft certified professional, agile evangelist, and novice blog writer. Connect with him on LinkedIn.


Start a conversation

What’s on your mind? Let’s explore the possibilities.