Visual Studio For Mac Git Merge

Visual Studio Code for Mac as diff/merge tool in SourceTree. Ask Question. Up vote 2 down vote favorite. Is there a way that I can set on Mac the Visual Studio Code as the default diff/merge tool in SourceTree? Thank you in advance. Git macos visual-studio-code atlassian. Using Git with Visual Studio. Showing which files have changed.

title	description	author	ms.author	ms.date	ms.assetid	ms.custom
Using Git in Visual Studio for Mac.	jomatthi	852B6A9D-AEFA-4EF4-A5DD-94A506019D20

Git is a distributed version control system that allows teams to work on the same documents simultaneously. This means that there is a central server that contains all the files, but when a repository is checked out from this central source, the entire repository is cloned to the local machine.

The sections below will explore how Git can be used for version control in Visual Studio for Mac.

Git version control menu

The image below illustrates the options provided by Visual Studio for Mac by the Version Control menu item:

Push and Pull

Pushing and Pulling are two of the most commonly used actions within Git. To synchronize changes that other people have made to the remote repository, you must Pull from there. This is done in Visual Studio for Mac by selecting Version Control > Update Solution.

Once you have updated your files, reviewed and committed them, you must then Push them to the remote repository to allow others to access your changes. This is done in Visual Studio for Mac by selecting Version Control > Push Changes. This will display the Push dialog, allowing you to view the committed changes, and select the branch to push to:

You can also Commit and Push your changes at the same time, via the Commit dialog:

Blame, Log, and Merge

Visual Studio For Mac Git Merge Conflict

At the bottom of the window, there are five tabs displayed, as illustrated below:

These allow the following actions:

Source - Displays your source code file.
Changes - Displays the change in code between your local file and the base file. You can also compare different versions of the file from different hashes:
Blame - Displays the username of the user associated with each section of code.
Log - Displays all the commits, times, dates, messages, and users that are responsible for the file:
Merge - This can be used if you have a merge conflict when committing your work. It shows a visual representation of the changes made by you and the other developer, allowing you to combine both sections of code cleanly.

Switching branches

By default, the first branch created in a repository is known as the Master branch. There isn't technically anything different between the master branch and any other, but the master branch is the one that is most often thought of in development teams as the 'live' or 'production' branch.

An independent line of development can be created by branching off Master (or any other branch, for that matter). This provides a new version of the master branch at a point in time, allowing for development independently of what is 'live.' Using branches in this way is often used for features in software development

Users can create as many branches as they like for each repository, but it is recommended that once they have finished using a branch, it is deleted it to keep the repository organized.

Branches are viewed in Visual Studio for Mac by browsing to Version Control > Manage Branches and Remotes...:

Switch to another branch by selecting it in the list and pressing the Switch to Branch button.

To create a new branch select the New button in the Git repository configuration dialog. Enter the new branch name:

You can also set a remote branch to your tracking branch. Read more about tracking branches in the Git documentation.

See the current branch in the Solution Pad, next to the project name:

Reviewing and committing

To review changes in the files, use the Changes, Blame, Log, and Merge tabs on each document, illustrated earlier in this topic.

Review all changes in your project by browsing to the Version Control > Review Solution and Commit menu item:

This allows viewing of all the changes in each file of a project with the option to Revert, Create a Patch, or Commit.

To commit a file to the remote repository, press Commit, enter a commit message, and confirm with the Commit Button:

Once you have committed your changes, push them to the remote repository to allow other users to see them.

If like me you are new to Git there are a lot of things to learn. This last two weeks I have been onsite in Athens moving source from StarTeam to Git in TFS. As we have just started getting users onto Git we have started hitting workflow issues. In StarTeam they were not really using branching and were doing manual merges. This was for many reasons all of them seemingly perfectly reasonable but it takes up a lot of time. With nearly 50 coders it was well past being manageable and they are currently looking at 100 man-days to do a merge.

I am trying to move them to a much more supportable model and for that I am moving them towards Git. I know this would be a steep learning curve for them but I believe it is the only reasonably way to support the issues that they have in their software strategy.

More on that later, but for now I have been running into an issue with merge conflicts in Git when coders try to Pull from the server. It seems that whatever workflow they are used to when they follow it in Git they get a “libgit2.Catagory = FetchHead (MergeConflict)” message that adds that there are 3 conflicts that prevent a checkout. While my first thought is that they have uncommitted changes locally this is not the case. They maybe have 2-3 local commits and no outstanding uncommitted changes.

While this should be able to be handled it is not and I have 50 coders hitting it reputedly. The only way I have found so far to resolve the issue is to move their changes onto a temporary branch and rollback the local copy of the server branch. This allows them to do a Pull and then merge their local branch changes across.

@MrHinsh @nakedALM Yep, that one's my bad. Sorry about that. (These are checkout conflicts, though, not merge conflicts, FWIW.)

— Edward Thomson (@ethomson) October 9, 2014

Note: This is a bug in Visual Studio 2013.3 that has been fixed in 2013.4. You can download and install, as we did, the 2013.4 CTP to resolve the issue.

While not ideal it does work. So in order to mitigate this issue permanently, pending an update from the TFS team, I am changing their workflow. When planning on working on an originbranch all developers will:

Create a new “feature-[name]” or “hotfix-[name]” branch locally.
They make all changes on this branch
Pull regularly from originbranch and merge to FEATURE or HOTFIX branch

When they are ready to Push to the server they then:

Pull from originbranch to bring it up to date
Merge into “feature-[name]” and get working
Merge from “feature-[name]” to branch
Push to originbranch
DONE

If they are then done with the feature of hotfix they can delete it, if not they can keep it around for reuse. Simple…and it works for them every time. However sometimes they forget to do the change on the feature or hotfix branch and end up in the position above.

It depends when they figure out what they have done what the solution is. If they have not committed to the branch then they can solve this in a few clicks.

Create a new “feature-[name]” or “hotfix-[name]” unpublished branch
Commit to the new unpublished branch

Visual Studio Git Merge Tool

One of the nice features of Git is that I you made a bunch of changes and have not checked in you can just “checkout” another branch and the local changes you have made will be preserved. Simple quick fix.

Visual Studio For Mac Git Merge Request

If they only figure it out after they have committed one or more times to the branch then they have a few extra steps to resolve the committed bits on the published branch.

Create a new “feature-[name]” or “hotfix-[name]” unpublished branch – This will take a copy of the commits that have not yet been pushed to the server. This preserving the changes they have already made.
1. Checkout the branch you want to rollback
2. Use “git reset –hard HEAD~[n]” where [n] is the number of commits you want to back peddle
Pull from originbranch to bring it up to date

After that they can happily Pull to the published branch and continue to code away on the unpublished local branch. Yes this means that every developer effectively has one or more (they may have more than one set of work on the go) personal branches. While this was a bad practice in a Server Version Control System (SVCS) it is a perfectly good practice for a Distributed Version Control System (DVCS) where merging and branching is cheap and easy.

If you can you should install the Visual Studio 2013.4 CTP that fixes this issue and you can carry on as normal.

Move an Azure storage blob to another store

Visual Studio For Mac Git Merge Slow

Move an Azure storage blob to another store took a little bit longer than I thought that it would. All…

Creating training virtual machines in Azure

I am teaching the Managing Projects with Microsoft Visual Studio Team Foundation Server 2013 class next week in Cheltenham and…

Join to our community to gain access to Martin and many other Scrum experts around the world. Join the Professional Scrum Community or the Professional Devops Community and learn from others.