Table of Contents
- Preface
- Create a Project in VSTS
- Check-in the Code
- Code Comparison and Staging, Blame (Annotate)
- Revert and Reset
- Setting up work item check-in and build configuration
- Branching, Pull-Request, Squash Merge, Cherry-picking, Rebase and Fork
- Tagging
- Importing Git Repository from Github in VSTS and VS 2017
What this Article Contains?
This article discusses how to use VSTS and Git with Visual Studio 2017. VSTS and VS 2017 have built-in provision for using Git Repositories. This article uses VSTS and VS 2017 Community edition. It will also touch-base on some parts of scrum board and Build Configuration, but not in its entirety. The focus of this article is to use code repositories with VSTS or Visual Studio. Screenshots are added wherever applicable.
What this Article Doesn’t Contain?
It doesn’t contain code with Visual Studio 2015. Some features may work in VS 2015 as well, but not all. VSTS also provides integration with tools like Command-line interface (CLI), IntelliJ, XCode, and Eclipse but it is not part of this article. It doesn’t contain aspects of Continuous Integration (CI) / and Continuous Delivery (CD).
What is VSTS?
VSTS is an integrated, collaborative environment that supports Git, continuous integration, and Agile tools for planning and tracking work.
How is it Different from TFS?
In simple terms, TFS is on-premises based while VSTS is the cloud offering. VSTS provides a scalable, reliable, and globally available hosted. It is backed by a 99.9% SLA, monitored by Microsoft 24 * 7 operations team, and available in local data centers around the world.
Software Requirements
Visual Studio Community Edition 2017 and VSTS account, and Git account. Git is free and VSTS account is free for up to 5 users.
Getting Started
Click on “New Project” in VSTS.
Enter Project Name, Description, Version control, and Work item process and click Create.
Select “Code” in VSTS and click on “New Repository”. Enter Repository Name, add Readme file and gitignore file.
Readme file is used to give a brief introduction of the project and gitignore file is used to ignore tracking of files such as temp files and build results.
Open Visual Studio 2017 and go to Team Explorer, wherein two options are visible, Visual Studio Team Services and Github.
Connect with Visual Studio Team Services. It will ask for credentials, provide the same credentials you have used while creating VSTS account. Once connected, it looks like this:
Now, VS 2017 is connected to VSTS and “FirstApp” is visible. Click on “FirstApp” and Connect. Once connected, Visual Studio will ask to clone the code. Enter local path to clone the code and click “Clone”. Now, at local path, files are downloaded, and files are visible. File marked in red is gitignore file.
Create a new ASP.NET Core project at the same location (C:\Users\<username>\Source\Repos\Demo) and see Team Explorer in Visual Studio. Click on Changes.
It will show all changes, enter comment and click on “Commit All”.
What is the Difference Among Commit, Push, Fetch, Pull and Sync?
Commit
Refers to check-in to local repository. If we see right-side corner of Visual Studio 2017, we can see a bar. The red marked below is specifying that there are 58 changes to my local code, and is available for commit.
Once code is committed, click on master and “View History”.
And complete history of code committed will be visible in local repository.
Push
Refers to check in to main repository, i.e., VSTS, so that other developers can download the code.
After Successful Commit, the bar will show un-pushed commits. Since we have only 1 commit, the number will show as 1. Click it.
Outgoing Commit shows list of all commits available in local repository. Now, click on Push. Once it is successfully pushed to main repository, the bar will show 0 pending changes and 0 pending commits.
Now, go back to VSTS portal and we can see that the code is checked-in.
Commit Id “dfc54661” is matching with commit Id in “View History” tab, as shown earlier.
Fetch
Fetches check-in by other team members, but doesn’t apply to your local code. For demo purposes, we can change code directly in VSTS using edit option on file.
Click Edit. Add some text to “About.cshtml” and commit. Now, go back to Visual Studio and click on “Sync” option.
After Clicking Sync, it will show three options: Sync, Fetch and Pull.
Click on Fetch and we can see modified code is shown as Incoming commit, but not applied to code yet.
Pull
Apply VSTS check-in of other team members to your local code. Once user clicks pull, it will merge main repository code, i.e., VSTS code with local.
So, the content modified is now visible in local. User can “Pull” even without selecting “Fetch” option first. Pull performs two operations: Fetch + Merge
Sync
All incoming commits (Fetch) and outgoing commits (Push) are done in single click and code is merged in both the VSTS and local repositories or we can say code is synced.
Code Comparison
We can go to a file or folder and click on compare option in VSTS. It will list out all the commits, and we can compare between them.
From VS 2017, it is simple. Go to “View History” and click compare by selecting any two commits. Click “Compare with Source”.
Staging
This is a very important concept if developer wants to commit only few files. It is same as “Excluding – Including files” in previous versions of Visual Studio.
Consider, I have changed both “About.cshtml” and “Contact.cshtml”, but want to commit only “About.cshtml”. Use staging in such scenarios. Right click “About.html” and stage. Dropdown is automatically changed to “Commit Staged” and is available for commit.
Blame (Annotate)
Blame (Annotate) shows the complete commit history vis-à-vis current file.
User can then open the file committed earlier.
Revert
Revert undos a commit by creating a new commit.
e.g. Modify Code in Contact.cshtml, commit it, go to “View History” and click “Revert”. A new commit will be added automatically, once user syncs the code, it contains exactly the same code as before.
Reset
It is resetting master to a different commit in local, other than the latest one.
Reset- Keep Changes
This will keep the changes done in all latest commits locally and all later commits are visible as incoming commits. Master is changed. Since changes are kept, user can again commit the code.
Reset – Delete Changes
This will remove all the latest changes and code changes in later check-ins are not visible locally, but incoming commits are visible as it is.
Go to VSTS dashboard, and create a task. We will associate this task with check-in.
Assign a task to a resource (Rahul.mittal in this case), enter description, set priority, and specify effort. Click Save and Close.
When user saves, unique task number is assigned to each task.
Go back to Visual Studio, make changes and associate work item 4 while committing the code.
When we again go to task board in VSTS, we can see development history associated with this item.
Click on changes committed, and we can see the comparison.
Now, go to Build and Release option in VSTS. Click on “New Definition”. Select “ASP.NET Core” template option. User can choose other templates based on type of application.
Select Agent Queue as “Hosted VS 2017”. Click “Save & Queue”.
Then enter Comment, select branch as “Master” and click “Save & Queue”. In “Commit” textbox, either enter 40 characters or leave it empty, otherwise it will show the following error:
“The value specified for SourceVersion is not a valid commit ID.”
Build definition is queued. We can click on the link to see the details.
It can take some time to build, finally it will show up the below screen with build as successful message.
You will receive an email in the inbox confirming successful build.
If there is error in code, it will throw an error, e.g., In the below example, we have removed semi colon (;) from code. Now, we are pushing this code and then again, we run build definition.
And here, the build fails. :)
Mail notification is received about build failure.
Go to VSTS application page and we can see the statistics related to number of check-ins, build failure count depending on selection of activity timeframe (7 in this case).
Branching
Go to VS 2017, Select “Branches” option and enter a name of new branch to be created (Demo_Branch1 in the below example).
Once it is created, we can see on the right-corner of Visual Studio, two options are available. One is “master”, another is “Demo-Branch1”. Visual Studio will automatically point to branched version, although user can select “master” version as well.
Now, right-click and select “Push Branch” and it is visible in VSTS.
Pull-Request
Modify code in Contacts.cshtml in branch version, commit and push.
Go to VSTS, click on “Pull Requests”, and create a new “Pull Request”. Suppose, we want to merge data from branch to master. Select source and destination. Select branch name (Demo_Branch1) as source code path and “master” as destination path. Add relevant Title. Add Reviewers, if required, else if reviewer is a part of development team, team name is listed by default.
We can see below, the number of pushed files in the branch are shown. And pull-request is also comparing the code in the file, which can be used for quick reference.
Click Create.
This will be sent to the reviewing team for Approval. There are multiple options such as “Approve”, “Approve with suggestions”, “Wait for an author” and “Reject”. If it is rejected, the developer must modify the code and push the code into the branch with latest changes.
In this example, the reviewer approves. Next, assign “Work item”. (I have created a new work item for merging the code from branch to main, and the ID generated is 5).
If we go to the dashboard, we can see Task 5 displayed in the “New” list.
Click On “Complete”. A pop-up will open. Three check-boxes are displayed:
- Complete linked work items after merging. This checkbox is enabled because we have associated the work item with this pull request. Otherwise, it will remain unchecked and disabled.
- Delete
<branch> after merging. It will delete the branch after successful merge of code with master. In this example, it is unchecked because I still must work on the branch. - Squash merge – This merges all commit history into a single commit. Otherwise, a complete list of commits from branch code will be visible in the master version also. Select this checkbox and click “Complete Merge”.
We can see history of commits in master. Pull-request number is also displayed. Note that this pull request number is unrelated to Work-item number.
Also, task automatically moves in board and it is closed.
Go to Visual Studio code and select “master” from right bottom corner of Visual Studio.
We can see incoming commits, merged from branch code. Click pull and master-branch are in sync.
What If We Don’t Squash Merge?
We can see, it is displaying each commit history (in red) and then performing the merge operation (in green) If there are lot of small commits in branched version, it is recommended to Squash merge in “master” for cleaner history.
Cherry-Pick
Cherry-pick, in simple terms, is selective merge, or selecting only limited files out of multiple commits for merging operation.
Suppose, a new Branch is created from “Demo_Branch1” and named as “Demo_Branch2”. Now, file (“About.cshtml” in this example) is wrongly modified (marked as red below) in “Demo_Branch2” and committed.
It should have been modified in “Demo_Branch1”. Go to Manage Branches, select “Demo_Branch1” and click checkout.
Now, view history of “Demo_Branch2”. Select the commit you want to cherry pick. Right click and cherry pick the wrong commit. We can see the change are reflected in “Demo_Branch1”.
Now, we can push commit of “Demo_Branch1” and revert commit of “Demo_Branch2”.
Rebase
Rebase is used to take commits from master to branch at one go. Rebase is not “merge”.
E.g., in master, we have 2 commits in home controller.
And in Demo_Source1, we have a commit in “Index.cshtml” file.
While modifications are on in “Demo_Branch1”, I want to apply commits of “master” to “Demo_Branch1”. This can be done using rebase.
Go to Manage Branches. Right click “Rebase Onto”. Select “master” as “onto branch”. Click Rebase. Merge Code, if required… And we can see changes of “master” is rebased in to “Demo_Branch1”.
Note
- Rebase doesn’t work if changes are not committed.
- It is recommended to rebase only commits, not pushed in changes.
Fork
Fork is used if some developer is developing an exclusive feature and then wants to push it to master. Fork increases isolation from main code and hence increases stability of main code. When fork is created, no other branches are visible in right bottom bar in Visual Studio.
However, code can be merged into master using pull-request.
Use Create Tag option to bookmark the check-in. It is useful for bookmarking and later can be used to search the commits.
Right click and click “Create Tag”. Fill “Tag name” and description and click on “Create Tag”.
Refresh history and see the tag.
However, as of now, tags can’t be pushed to main repository via Visual Studio. Either we should create tag at VSTS or use command line. Right-click commit in VSTS and tag it, e.g., Fork_MainBranch.
Sync the code, and refresh the history in Visual Studio 2017. “Fork_MainBranch” is visible.
Create a project in VSTS as described in step 2. Click on “Import” in Import Repository.
Go to Github account, select any project created in github. And click on “Clone or Download” button.
Copy the URL and fill in the “Import” form of VSTS. Since project is public, no authorization is required, and project can simply be imported from Git.
Mail will be received confirming successful import.
Clone the repository to local as specified in step 2. Add dummy file and commit/push the code. It is now visible in VSTS.
We can use Visual Studio 2017 to import directly from Github. Click on Github option in VS 2017 team explorer. Click Clone.
Click Clone and select project.
Click Clone and add text file at folder location.
Go back to VS 2017 again and click on Changes and Commit/Push.
Go to Github and see the check-in.
Thank you for reading!
Want more such tutorials? Get in touch with us by leaving a comment below.
