Configure Visual Studio 2017 15.5 for pull –rebase

I’m a great fan of rebasing over merge and I’m convinced that the default pull should be a fetch and rebase, using fetch and merge only when it is really needed. Not having the option to configure a GUI to do a pull –rebase is a really annoying problem, that can be somewhat limited configuring pull.rebase git option to true, as explained in previous post. Actually, the lack of rebase on pull option makes me stop using the IDE.

To have a linear history in Git, always consider rebase over merge, especially for everyday pulls.

I’ve used this technique extensively with VS 2017, the only drawback is an error during pull because VS complains about “unknown merge result” since he was not able to find merge commit. Give this, I was always reluctant to suggest to customers, because it is not good having your IDE constantly show error at each pull.

After updating to 15.5 version I noticed that the error went away and the IDE correctly tells me that a pull with a rebase occurred. If I open the global or repository settings in Team Explorer I can found that now, finally, pull.rebase is supported.

image

Figure 1: Pull with rebase is now supported, as well as other interesting options.

Actually these are the basic settings of Git, if you configure the repository or globally the Rebase local branch when pulling, it will set pull.rebase to true, nothing more. The important aspect is that the IDE now honor the settings. Suppose you have one local commit and one remote commit like in Figure 2:

image

Figure 2: Classic situation where you have local commit and remote commits

Now if you simply press the pull command in the IDE, you will see that VS is correctly issuing a rebase. When everything is finished you are informed that indeed a rebase was done, the error went away.

image

Figure 3: Visual  Studio correctly rebased local branch on the remote branch.

With this latest addition I can confirm that Visual Studio is now a really interesting IDE to work with Git (even if, if you are experienced with Git, probably you will still stick in CommandLine most of your time).

P.s: Another nice addition is the support to prune after fetch and support to push –force. If you try to push a commit after an amend, instead of the standard error, you will be prompted with a  MessageBox that asks you if you really want to force the push.

image

Figure 4: MessageBox asking for a push force if needed.

If you are curious about why VS is using a –force-with-lease instead of a standard –force, please read this article. Basically it is a way to force the push if no one had pushed something else in the meanwhile. If you really need to force a push, like when you rebase a feature branch, you can always use commandline.

Gian Maria.

Configure Git repository for automatic pull –rebase

I’m not a great fan of Git Graphical User Interfaces, I use mainly command line, but I needed to admit that, for novice user, the ability to use a GUI is something that can easy the pain of transition to a new tool. Visual Studio 2017 is a decent GUI for Git and since .NET developers are used to it, people want to stay as much as possible inside the IDE, leaving the commandline only for special operation (squash, reflog, etc)

The main problem I found with VS 2017 is the “pull” button, because I’m a great fan of pull –rebase instead that normal pull, because the history will be clearer. Suppose you have this situation:

image

Figure 1: Situation before a pull, one local commit, one remote commit

This is a standard, a developer has created a local commit and we have another commit done in the origin/master branch. This is what the develop see in Visual Studio sync interface:

image

Figure 2: The same situation of Figure 1 as seen in Visual Studio

From the comment you can see that the incoming commit is a simple add of readme.md file , this is unrelated to the modification done by developer, but if he press the pull button here is the result.

image

Figure 3: A merge commit is created due to the pull operation

If everyone will use the default pull option, the team will create a lot of unnecessary merge commits, thus I really prefer the pull –rebase approach, but the problem is: in Visual Studio there is no easy way to issue a pull –rebase and the pull button is just to easy to press to convince people to go to command line and issue a pull –rebase. Luckily there is an option that you can configure globally and that will default pull operation to do a rebase instead that a merge

git config –global pull.rebase true

After this configuration was done, whenever you issue a git pull, the –rebase option will be added automatically for you. Since VS 2017 honors git settings, if you press the pull button you got the right behavior, even if it is complaining that the merge result was unknown. (a rebase happened, not a merge)

image

Figure 4: After the pull, VS is complaining because the merge result is unknown, because a rebase was instead done

image

Figure 5: Indeed GitViz confirm that the pull operation was a pull –rebase

You can just ignore the error in Visual Studio and accept the fact that now, whenever you press the Pull button in Visual Studio you will trigger a pull with a rebase instead that a pull with merge.

This technique is not going to work with older version of Visual Studio, because they used the LibGit2Sharp library.

Gian Maria.

Optimize your local git repository from time to time

Git is an exceptional piece of software and I really cannot think living without it. Now with superfast SSD, you can use git without performance problem even for large repositories (maybe you converted an old Subversion or TFVC).

When your repository has thousands of object and especially if you adopt flows of work where you rebase often, probably your repository has large number of unnecessary object that can be deleted safely. Git runs for you in the background a special command called

git gc

It is a Garbage Collection command, that will cleanup your local repository, nothing changes in the remote repository. Sometimes you can also run manually a deeper cleaning of your repository with the command

 

git gc --aggressive

You can run from time to time (documentation say you can run every few hundreds commits), it will take longer that a normal git gc, but it will help keeping your local git repository fast even if you work with really large codebase.

Gian Maria.

Check pull request with build, without enforcing pull request

With TFS / VSTS Build system it is possible to configure Git to require that a specific branch is protected, and you need to use Pull Requests to push code into it, and the pull request can be accepted only if a specific build is green. Here is the typical configuration you can do in admin page for your Git repositories.

image

Figure 1: Branch policies in VSTS/TFS

In Figure 1 it is represented the configuration for branch policies; in this specific configuration I require a specific build to run whenever a member create a pull request against develop branch. The effect is: if a developer try to directly push to develop branch, the push is rejected.

image

Figure 2: Push was rejected because Branch Policies are defined for develop branch.

Branch Policies are used to force using pull requests to reintegrate code to specific branches, and sometimes it could be too restrictive. For small teams, it could be perfectly reasonable to avoid always forcing pull request and letting the owner of the feature branch to decide if the code needs a review. Such relaxed policies is also used when you start introducing Pull Request to the team, instead of telling everyone that they will be completely unable to push against a branch except from a Pull Request, you can gradually introduce Pull Request concept doing Pull Request only for some of the branches, so the team can be familiar with the tool.

Always be gentle when introducing new procedure in your process, being too restrictive usually creates resistance, unless the new procedure is enforced and requested by all  members of the team

Luckily enough it is simple to obtain such result, in Figure 1 you should see an option “Block Pull Requests Completion unless there is a valid build”. Simply unchecking that checkbox will allows you to normally push on develop branch, but if you create a pull request, you will have a build that verify the correctness of the code.

Gian Maria.

Update GitVersion for large repositories

As you know I’m a fanatic user of GitVersion in builds, and I’ve written a simple task to use it in a TFS Build automatically. This is the typical task that you write and forget, because it just works and you usually not have the need to upgrade it. But there is a build where I start to see really high execution timing for the task, as an example GitVersion needs 2 minutes to run.

image

Figure 1: GitVersion task run time it is too high, 2 minutes

This behavior is perfectly reproducible on my local machine, that repository is quite big, it has lots of tags, feature branches and seems that GitFlow needs lot of time to determine semantic versioning.

Looking in the GitHub page of the project, I read some issue regarding performance problem, the good part is that all performance problem seems to disappear with the newer version, so it is time to upgrade the task.

Thanks to the new build system, updating a task in VSTS / TFS is really simple, I just deleted the old GitVersion executable and libraries from the folder where the task was defined, I copied over the new Gitversion.exe and libraries and with a tfx build tasks upload command I can immediately push the new version on my account.

Since I changed GitVersion from version 2 to version 3, it is a good practice to update the Major number of the task, to avoid all build to automatically use the new GitVersion executables, because it could break something. What I want is all build to show me that we have a new version of the task to use, so you can try and stick using the old version if Gitversion 3.6 gives you problems.

Whenever you do major change on a TFS / VSTS Build task it is a good practice to upgrade major number to avoid all builds to automatically use the new version of the task.

Thanks to versioning, you can decide if you want to try out the new version of the task for each distinct build.

image 

Figure 2: Thanks to versioning the owner of the build can choose if  the build should be upgraded to use the new version of GitVersion task.

After upgrading the build just queue a new build and verify if the task runs fine and especially if the execution time is reduced.

image

Figure 3: New GitVersion executable have a real boost in performance.

With few minutes of work I upgraded my task and I’m able to use new version of GitVersion.exe in all the builds, reducing the execution time significantly. Comparing this with the old XAML build engine and you understand why you should migrate all of your XAML Build to the new Build System as soon as possible.

Gian Maria.