When multiple developers are working on the same thing, change tracking and attribution becomes important, as does the option to replace broken projects with an earlier and definitive versions.
The Git system has become a really popular version control solution. It’s not limited to any platform, and a team requires only the right software and network-mounted filesystem. Commonly GitHub is used as a ‘master’ repository for large open source projects.
The client for Windows includes a Bash command line and a GUI-based application. After it’s installed, it needs a repository location, which could be a local directory. A repository isn’t much use without something to push code changes to it. Thankfully, Microsoft released a lightweight editor called ‘Visual Studio Code‘ that includes a Git feature.
Using Visual Studio Code, I created a new file in the repo directory. As you can see, there is a little indicator on the Git side panel button, indicating there is one change to ‘commit’. There is also a small ‘U‘ sign showing the change is untracked, and a plus icon to stage the change.
If multiple developers are pushing files to the same repo, they might be listed here also. Another useful feature of VS Code is the editor can be split, so the current source can be compared with a previous version.
To stage an item, click the ‘plus’ icon. When the ‘Rescan‘ button is clicked in the Git application, the list of Staged and Unstaged changes will be updated.
A ‘commit’ is accompanied by a short message containing a short description and reason for the change, which are visible in whatever history.
Viewing Change History
This is possible using the Git GUI application, which could be running on another developer’s system that’s reading the repository.
Click Repository > Visualise master’s history. This will bring up the following interface:
Here we can revert changes and view the commit messages.
Team Foundation Server Walkthrough
Although it’s possible to use Visual Studio and TFS with Git, Microsoft has its own version control system. Before doing anything, the project should be created on the TFS. This can be done within Visual Studio’s by creating a ‘New Team Project‘, or by signing into the TFS web portal and creating it there.
With that set up, we can create the Visual Studio project itself. In this example it’s simply a C# form with a text box and button. If an existing project is being added to a repository, I strongly recommend keeping a back up elsewhere.
When done, save the project, right-click on the top level entry in Solution Explorer, and select ‘Add Solution to Source Control‘. We’re presented with a choice between TFS Version Control and Git. The next window after that is where we can choose which TFS folder the solution files are uploaded to.
However, the project files aren’t simply uploaded to the server. They must be ‘checked in’, following a similar process to Git. Add a comment and click the ‘Check In‘ button in the Team Explorer window. At this point, the source files are uploaded, as are any subsequent changes.
The source files and their histories are now available to other developers using the server.
The useful thing about the TFS system is the other developers can view each others’ work within their own Visual Studio installations, without having to go through the portal. Plus TFS enables the server admin to set really granular permissions for the team members.