Get started with GIT in VSTS here in the VSTS GIT today.
What is GIT and Source Control:
In this section, we are going to explain how GIT works and how it is different from traditional source control.
- We will also see how the VSTS GIT is good and one of the most powerful features is the pull request.
- We will see pull request and code review because they are two of the most powerful practice in a team service foundation.
- We will also see why VSTS GIT is one of the most popular version control systems in the market.
- This is to be noted that VSTS GIT how it is different from the traditional version control systems such as team foundation version control
Difference between VSTS GIT and Traditional Version Control System:
- Traditional version control systems are called a centralised version control system.
- It means that we communicate with the central server whenever we want to work with the project code.
- This means that whenever a user needs to create a branch he needs to talk to the central server so that the server we create a branch for the racer
- If the user wants to merge the changes with one of the co-worker, the user will have to ask the server to do the merging for both user and co-worker.
- In some restricted version control systems, in the default configuration, the user will have to ask permission from the server to even be able to edit the file.
- There are high benefits for such systems but fundamentally they slow down the development process and pushing out the completed application anyways.
- For this reason, a different type of version control such as VSTS GIT looks very appealing.
- VSTS GIT is what is called a distributed version control system
- In this, the developers do not need a centralised server but rather every developer has a copy of the centralised saved locally as a local code repository.
- The local computer in which the developers work, due to the above reason, the developers can make changes in code and also commit the changes only locally.
Benefits of VSTS GIT:
- In GIT, the developers are actually encouraged to work independently of the server and the other developers by having the freedom to create a branch and write the code.
- This makes every developer working on a project fast and efficient.
- Whenever a developer wants to do something he can quickly create a branch and develop whatever the code he wants, all the feature he wants and committed to the branch.
- Buy this we surely don’t mean that developers should not have a centralised server but rather all the developers should have a centralised server copy in local
- And like the old ages, when he wants to deliver production build it was made in the developer workstation.
- The centralised server is a single source for the latest version of the software having a centralised server is very important because are the means for all the developers in the team to know which version is the latest version of the software.
VSTS GIT hands-on:
Let’s take a look at VSTS GIT.
- In VSTS GIT, we are able to look at the project structure.
- We are able to navigate into the file structure and see the files as they are in the repositories.
- We can click on a file in the repository and also see the contents of the file in the latest version. This is understood as the latest is what that is stored in the server.
- We are also able to edit the file with the edit option this is a very rich text editor that is included in Visual Studio Code. Just as a food for thought, VS code is based on Atom which is based on Chrome in return.
- This offer syntax highlighting and great editing support like a good code editor software.
- Not only that we can see the structure of the repository, but we can also see the history of the repository for that we just have to come to the commit icon.
- By clicking this is we can see all the commits made by all the users.
- The Push icon lets the users see when someone has uploaded the changes to the repository.
- And finally and not the least, the branches tag allows us to save the structure of the repository.
- But just like most developers feel free to edit the code in code editor for IDE.
- This makes using VSTS GIT very useful because of its incredible popularity. This lets the user use VSTS GIT in VS code and any code editor include Visual Studio IDE.
Let’s look at the VSTS GIT in Visual Studio:
- We get the list of projects and repositories right inside the team explorer
- We can find the repository right click it and select clone this will bring the repository down to the local computer
- Once the cloning is finished we can double click a repository and open it in the team explorer
- We can open the same repository in the solution explorer by navigating to the repository and double-clicking the solution file to open it.
- Now any user can work on the project using the rich code editing features that visual studio offers.
- After making the change we can navigate to the team explorer and click on the changes tab.
- We can see that VSTS GIT notices that the file has been changed and it adds that file to the changes lists automatically.
Branching in VSTS GIT:
One of the most powerful features of GIT is a lightweight branching system. Therefore we are able to create a branch even after we have started working on the file as we can see the file is there listed in the team explorer has changed files. Please follow the image instructions to understand the above step.
- Just go to team explorer homepage and click on branches.
- Make a new branch.
- And now we do I create branch we will see that the new changes will move right into the newly created branch
- We can go back to the changes tab and add a new commit message and commit the changes to the newly created branch.
- Now we can put these changes that have been made locally to VSTS GIT by clicking on the sync button.
- This will push the changes up to the now central server.
- In VSTS GIT webpage we will be able to see both the branches under the same repository.
Now that we have seen how to integrate the code with VSTS GIT we will see some of the powerful features of VSTS GIT and that is the Pull Request:
- From within VSTS GIT web portal, we can navigate to the new branch click on the dropdown and make a new pull request.
- This pull request is what allows other members of the team to be able to see the changes made by a user.
- Other team members will be able to see all the changes that have been made by the user in the branch
- Other users are able to comment on individual lines of code or they can comment generally in the comments section
- We are able to add a description to the pull request and create it.
- This will notify other team members about the presence of the new pull request and will also request them to make a code review.
- This is a very powerful way of making code review and branch policies using a pull request
- In this part, we are going to see about the pull request which is a very powerful technology in modern application development and the version control workflow.
- A Pull Request is a mechanism which can be used to integrate changes from different branches into the main branch.
- This is how we request the code to get pulled into the master branch.
- We do this integration on the server using the web-based collaboration. This web-based integration enables collaboration with the entire team.
Latest take a closer look at non-ideal circumstances of using VSTS GIT.
If you are a developer you will make a branch make some changes and commit the changes into the branch and upon publishing, will merge this new branch into the master branch and try to push it to the server. If a different developer has created some changes into his branch and push to the master branch before you, VSTS GIT will force you to download the new changes and then make the merge manually and then finally push the branch to the server. Here, a lot of manual work that is going on.
This actually makes sense considering lots of people working on the same code let’s just see how this can be made easier with the help of pull request.
During the above process, we can see that the code is directly going into the integration branch without going through the code review which is not very good practice.
We will see how to use the pull request for code review:
If you are working on code and we decide to make a quick bug fix or add a new feature, the best practice is to create a branch and check out the current code into that branch. After creating the new branch you will quickly jump to the new branch and do the changes. In an unsophisticated situation, the developer would directly merger changes of this branch to the to the master branch.but in a sophisticated situation the developer will host the new branch to the server without doing any integration at all.
- To get started all the user has to do is click on the new pull request link.
- This will show a preview of the change that has been made in the local repository which we would like to add to the master branch.
- Once the user has successfully previewed the changes that have been made, a user should add a new comment before merging them to the master branch and therefore providing an opportunity for the other team members to know more about the merging.
- Now the user clicks the create pull request button and therefore the remaining of the team has an opportunity to view it as well. Now all the members can look at the pull request and examine the changes that have been made and even comment on individual lines of code.
- After review by all the necessary members is complete, we can go ahead and give the complete pull request option this will complete the merging.
Branch policies with pull request and how to enforce best practices in VSTS GIT:
With the help of pull request, you are able to make lots of automation possible across merging. This is called branch policies. This enables policy enforcement on the pull request. In Visual Studio Team Services we can go to code hub main branch.
If we click on the three dots and click on branch policies.
The user is able to protect the branch.
This will allow a number of branch policies that will make the other members of the team in order to them to add them.
Here we can add a minimum number of reviewers.
Check for the linked work item will ensure a user know why the code is being written. This lets us handle even large pull request and make sure that any part of the code does not miss the code review. Some of the best parts of VSTS GIT is that it ensures build completion as a branch policy. We can you set an external or an internal Continuous Integration, that is offered by visual studio team services.
The internal one, test a continuous integration set up by vsts. And therefore whenever a new pull request happens visual studio team services continuous integration make sure that the project builds and it qualifies all the test that is being set up by the user. This ensures that any change that is put upon the code is tracked by a work item and therefore we can know any change and the purpose of the change. The continuous integration builder policy prevents checking in a build failing error.
- We will see how to enable pull request with a fork this will enable in a work style within the company.
- All this time we have been looking that pull request as an alternative to pushing the code into the master branch.
- Open source projects often the users have read access but they do not have write access.
- Here, Pull request comes as a solution.
- Pull request enables the ability to fork allowing anybody in the world make contributions make contributions.
- The same workflow can be used in even closed to the source project. And this technique is called the inner source.
Creating a fork means creating a server-side repository as a copy of the main repository. Even if the user does not have the right access to the main repository, that he has to write so he can access the copy of the repository. This means the user can create a branch to make the changes and push it to the repository or to the fork. This will request to the original owner of the product to review the code and merge it with the main project.
Vsts does not offer fork for open source project but it does offer fork for inner source project.
VSTS GIT is easily the best Version and Source control available now. We saw how to make branches in VSTS GIT and in Azure Devops. We can also make pull requests to let other developers know about the changes that are being made before we actually merge the changes to the master branch. We can see that VSTS GIT also offers the feature to make Fork and inner source. This is very easy to learn as well. For more about VSTS GIT please stay tuned to Tec Kangaroo.