In this last post about Git I’m going to touch on a few odds and ends I came across that are worth mentioning or confused me at first.
Working Directories
Git does not create folders in your local repository for every branch you checkout like TFSVC or SVN does. There’s only one working directory per repository and in that directory is a hidden .git folder where the files are stored.
When you change your active branch by selecting a different branch in Team Explorer, Git retrieves the files for branch into your working folder. If you have changes that were not committed to the local branch Visual Studio will warn you so you don’t loose your work when you switch branches.
Multiple Repositories
When you clone a repository you get everything in the history of that repository and I mean everything, every version of all the file changes that happened since the repository was initialised. This is can be handy since any client repository can be used to recover the server repository should anything happen but it also means the repository can get really big over time.
To keep it manageable you should create multiple repositories in your team project and keep solutions that change together or have a logical reason to be together in a repository.
Keep in mind if you have projects that change together spread across multiple repositories it can add to your headaches, merging and branching and tracking the versions across multiple repositories can be difficult. There are also some practical implications like searching across multiple repositories is not supported by all Git tools.
To create a new repository, open up TFS portal and browse to your team project and click on the Code tab then click on the drop-down arrow next to your current repository name and select Manage Repositories… and click on New Repository.. give the new repository a meaningful name and click on OK.
Back in Visual Studio, open Team Explorer and click on Manage Connections to see the new repository, right click on it and connect to it.
Visual Studio will prompt you to clone the repository to start using it.
Merge conflicts in pull requests
In my previous post I discussed pull requests now I’ll briefly show you how to handle merge conflicts. When you submit a pull request to merge your code back into the master branch and there are other changes that can not be automatically merged by Git you will see this error message.
TFS actually makes it very easy for you to fix it, when you click on the Manual merge help… link under the merge failed message it will show exactly what to do.
After you do a pull to get the latest changes to your local branches you have to merge master into BranchOfMaster. First make sure your branch is the active branch in Git, then right click on it and select Merge From…, we want to merge from master into this branch.
When Team Explorer shows the Resolve Conflicts section click on the Merge button and you will see the merge editor.
In this case I am going to select both changes and click on the Accept Merge button. Still under the Resolve Conflict section of Team Explorer click on Commit Merge. If you now look at the pull request screen in TFS portal you will see there are no more merge conflicts and you can complete the pull request.
Remember to pull down the changes to your local master since the pull request only updated the remote/origin master. I assumed when I right click on my remote/origin branches and view the history it would be real time but it seems you have to do a pull to view the latest history as well.
