Rules to Better Version Control with Git
Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see.
If you still need help, visit Application Lifecycle Management and book in a consultant. Rules to Better Version Control with Git
Source control is the backup of your code, as well as your change history to track changes.
With the source control (we use TFS), we can share project code and cooperate with other team members. Using it allows us to track changes, compare code, and even roll-back if required. Moreover, it keeps our code safe that is the most important.
Don't just fix the problem, see who caused the problem and correct them. - Adam Cogan
Git Reset – Discard your local changes and revert to your last Commit
Note: A common cause of Visual Studio failing to undo changes is an incomplete .gitignore file. See http://adamstephensen.com/2014/05/13/update-your-gitignore/ for more information.
Do you know the best way to manage NuGet packages with Git? You can get into all sorts of trouble by including your packages in source control.
** Do not check packages into Git **
The following are a few issues that are related to having your NuGet packages in source control:
- Over time the packages will grow to be too many and cloning the repository will be slow.
- You could get duplicate NuGet packages in your packages folder as new versions are updated.
- NuGet shows packages to update that have already been updated. This can happen if you have duplicate NuGet packages but they are different versions.
- It becomes harder to "clean" your solution of any unused package folders, as you need to ensure you don't delete any package folders still in use.
Nuget will automatically restore packages with out checking them in to source control
Beginning with NuGet 2.7, the NuGet Visual Studio extension integrates into Visual Studio's build events and restores missing packages when a build begins. This feature is enabled by default and packages.config will be automatically included in souce control.
Here's how it works:
- On project or solution build, Visual Studio raises an event that a build is beginning within the solution.
- NuGet responds to this event and checks for packages.config files included in the solution.
- For each packages.config file found, its packages are enumerated and checked for existence in the solution's packages folder.
- Any missing packages are downloaded from the user's configured (and enabled) package sources, respecting the order of the package sources.
- As packages are downloaded, they are unzipped into the solution's packages folder.
Support in legacy versions of NuGet
It is highly recommended that you upgrade to the latest version of NuGet to to avoid having to configure your solution to not check in NuGet pagages to source control.
With Visual Studio Online now supporting Git, more developers are changing their source control repositories. What happens if an application you developed relies on the TFS Client Object Model to get information out of source control (e.g. changeset comments) and the developers start using Git?
That's where the new Visual Studio Online REST APIs come in. You can get a list of commits from your VSO Git repository with only a HTTP request.
Using HTTPS with basic authentication, make a GET request to a URL as below, substituting in your VSO details. A JSON object will be returned. To quickly create classes from a JSON response, see the rule Do you know how to easily get classes from a JSON response?
For a C# implementation, see this blog post Getting Git Commits with the VSO REST API.
Like most skills, it can take a little while to get your head around Git.We rate our devs and the devs that we mentor on the following scale.
Where are you?
** Level 1 - Understanding the basic principles
At this level, you need to have an understanding of the basic operations (including branching).
Your workflow looks like this:
- init local repository / clone
** Level 2 - Working with Git on a team
Now that you know the basic Git commands you can start working on projects with more than one developer.
You should be using local feature branches for your work.
Your workflow involves:
** Level 3 - Learning to use pull requests
Pull requests can be used for code reviews within your team, or to accept suggested changes from people outside your team.
Pull requests should preferably be used with policies (TFS Git only - harder with GitHub).
** Level 4 - Working with a team advanced - Rebasing (harder, but worth it)
When working in a team, Git does a pretty good job of merging code together from different branches... but it can be very messy. True Git masters master rebasing. It lets you keep a much cleaner project history.
Git process for Git masters:
- pull master
- rebase feature branch on top of remote master
- push feature branch to remote or create pull request
Use the VSTS Branch Policies feature. This is a super sexy feature.
When you merge a branch you end up with messy merge commits.
Rebasing might take a bit to get your head around, but you get a much cleaner project history.
- it eliminates the unnecessary merge commits required by git merge
- rebasing also results in a perfectly linear project history - you can follow the tip of feature all the way to the beginning of the project without any forks.
This makes it easier to navigate your project with commands like git log, git bisect, and gitk.
Warning: If you don’t follow the Golden Rule of Rebasing, you could end up in a world of pain.
Rebasing is great for ensuring a clean project history... but it can be dangerous in inexperienced hands.
The golden rule of git rebase is to never use it on public branches. (ie. never rebase master).
You should never rebase master onto a feature branch. This would move all of the commits in master onto the tip of the feature branch (not the other way around).
Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s. If you were to Push this to the server... expect lots of pain to fix it up!
Do you know that remote branches on your machines are not automatically removed in most of Git clients?
Git pro tip
If you use console for fetching data use this command to fetch and prune remotes/origin folder at the same time!
git fetch -p
Git has become the defacto standard for version control systems. It's distributed and decentralized and promotes working disconnected as default. It also takes away the pain of branching and merging and has a built in code review system with pull requests. Everybody should be using Git, and if you're not, you should be migrating the Git using one of the below tools.
- VisualStudio.com - Import Repository
- Git-Tfs (recommended)
VisualStudio.com - Import Repository
VisualStudio.com gives you the ability to import from a TFVC repository into a new Git repository.
Bad Example - Built in tool has several limitations
If you don't care about source control history, then this inbuilt tool is the easiest to use. It has the limitations of:
- 180 days of history
- No branches
TIP - Use this if you don't care about source control history
Git-Tf is an open source command line tool that works cross platform and use the Java TFS SDK. This tool is useful for migration if you're not on a Windows environment. This tool is not maintained and has issues with migrating branches.
To see how to use this to migrate see "Migrate an existing project from TFS to Git with changeset history intact" from Chris Kirby
TIP - Use Git-Tf if you don't have a Windows environment
Git-Tfs ( Recommended)
Git-Tfs is an open source command line tool that uses the .NET TFS SDK to interface between Git and TFVC. It has the following advantages over the other tools:
- Actively maintained
- Good support for branches
- Author mapping
- Migrates all history
When you create a new git repository and need to push it to VSTS you need to provide login credentials.
It isn't always clear how to do this.
Instead, you should use Personal Access Token. You can do this in two ways.
The first option is to make sure your Git for Windows is up-to-date and when cloning the repository, you use Microsoft Account to log in. Personal Access Token for Git will be created for you.
Option 2 is to manually create Personal Access Token and use it as a password for Git login.
You can follow this blog post for full instructions: Using Personal Access Tokens to access Visual Studio Online.
After you use the right tool to migrate from TFVC to Git, there's a few more things you need to do to clean things up for a new user joining the project. By default, if there is a TFVC repository, that will become the default in the UI.
Unfortunately, you can't kill the TFVC repository and make Git the default one, so there's a few steps you need to follow.
Figure: Bad Example - Can't delete the now deprecated TFVC repository
Delete files from TFVC
Go into the repository, delete any existing files. Add a new document saying "_Migrated_to_Git.md". This will stop people from getting the wrong code.
**Note : All the source code is still there, it's just flagged as being deleted.
Lock down TFVC
In the TFVC repository, click Security
Figure: Configure the security of the TFVC repository ** Then deny check-ins to **Contributors , P roject Administrators and Project Collection Administrators . This should stop anyone from committing new code to the repository.
Update the Dashboard
Next step is to update the dashboard to let new developers know.
Figure: Good example - Let new users know that the source control is now on Git
Suggestions for the VSTS team
- Give us the ability to hide a repository
- Give us the ability to set a repository as the default for all users
- Give us the ability to delete a TFVC repository
Having any of these suggestions will avoid the confusion on this screen
Figure: Bad Exmaple - This is confusing for a new dev