Post
Ask Question

Source Control (8), Git, Azure Repos, And Visual Studio

This is a series of articles related to Source Control or Version Control issues, from the stand-alone app, such as MS SourceSafe, to Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We tried to category this series of articles as Source Control or Version Control, but this site does not have these categories, so we make the articles in Category as DevOps, as explained in the wiki:

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.

The structure of this article series will cover:

  • Stand Alone App:
    • MS Source Safe
  • Server App
    • MS TFS (Team Foundation Server)
  • Online (Cloud) Centralized Service:
    • MS Azure: DevOps
      • Boards
      • Repos
      • Pipelines
      • Test Plans
      • Artifacts
    • GitHub
    • AWS GitHub Enterprise
  • Distributed App:
    • Git

Because these are huge topics, so I will not step by step, instead, I write any section when I feel I am ready for it, but each section will be relatively independent to become a reading unit.

Introduction

In this article we will concentrate on the topic of Git, Azure Repos, and Visual Studio interactions:

  • Azure Repos (GitHub) --- Centralized Source Control Service on Cloud
  • Git --- Distributed Local Source Control App
  • Visual Studio --- Tool to integrate both Azure Repos and Git

In this article,

  • we will not discuss concepts, such as what DevOps is, what GitHub is, what Git is, and so on;
  • we will not discuss how to get an account for any of Git or centralized depository, or access, instead
  • we discuss the interactions (Processes) between Repos and Git by Visual Studio. and
  • we assume one already has an account of Azure and has access to DevOps.

The same is true for GitHub, or AWS (AWS uses the same interface with GitHub, actually is Enterprise GitHub). For the access to that server or called online services, we will discuss in another article, while when one accesses the online depository (ies), the interaction between the server and local (Git) through Visual Studio is the same, that will be discussed here.

Summary: Interactions between Azure Repos and Git by Visual Studio

This graph is from the video GIT and Visual Studio with Azure DevOps Repos - Step by Step, it is very informative about Azure DevOps, we got this screenshot and something related in our discussion just for our specific topic. If you are interested in these DevOps, or App management/Code Control topics, the video is a very good one to view.

A: Get Local Copy of Reposit --- Clone

By default, initially, there will be a master reposit in server, whatever it is MS Azure DevOps, or GitHub, or GitHub Enterprise (AWS), we start from here.

We have assumptions that

  • you have an account of an online Source Control server, such as DevOps, GitHub, or AWS whatever from company or yourself
  • you can access the account
  • you have cloned a master copy to your local

For a company account, it might be setup well, when you open a computer or Visual Studio, you can link the account automatically. Otherwise, it might need a complex setup process.  In the DevOps or GitHub server, besides the master repository, there might be some other reposits there, they might be called, such as develop, master, QA, etc. 

I assume you have got the local copy of repos by clone. I will not discuss the cloning process here, because that is also quite involved, different product (DevOps, or GitHub) has a different way to do the job, you could make it in server or client (VS), even in Visual Studio, you might have several ways to do it. So I will discuss it in another article.

Now, you have a master repo in both your server and local. This is our starting point:

In Git Changes Tab, by default, it will show master, that is local master, click the arrow on the right-hand side, we have

Click Remote below, we can see the remote server: called origin/master and something else, such as origin/Feature/test1

B: Create a Local Branch

Starting from a local master, 

Click the arrow on the right of master, then click New Branch:

Make Branch name as user_story_01:

Click Create, we have:

Now, we create a local branch:user_story_01

Note

  1. Never work on the master branch directly, always create a local Feature Branch such as user_story_01 (we usually call it a feature branch, or something like hot_fix branch if this is a bug fix);
  2. For the created local Feature Branch, if it will be worked by other people, you can push to the server (remote), otherwise, if it is only worked by yourself, it is not necessary to do that.

C: Modifications and Save

Make any modifications in the code or any document in the solution: you will see the modified file have a red checkmark on it: 

For any modifications, we have three ways to save the change,

  • Save to local disk
  • Save to local Branch
  • Save to remote Branch

Step 1

Save to local disk: that we are familiar with.

Step 2 - Save to local Brach

Go to the Git Changes tab, Click Plus Mark to Stage All.

Make name for the change to the stage.

Commit Staged: we got a commit Branch version (4274bd93) created locally.

Go back to the solution, you will see the "Check out" file (used with a Red Check Mark) has been Checked In.

Step 3

Save to Remote Brach,

Then we have this, in server-side (remote), we add (push) a new Branch user_story_01,

Note
In the graph above, besides the Commit All, there are other two options: Commit All & Push, and Commit All & Sync we can do it in the way shown below, but we will not discuss the details here. When you play on it, you will see different alternatives to complete the same task.

D: Save to the Remote Master (GitHub)

After the push, we got this: Successfully pushed to origin/user_story_01, Click Create a Pull Request,

Then we will be redirected to Server (for this example, we use GitHub) online,

In server, Click Create Pull Request button,

To request SAVE from server-side user_story_01 to master Branch,

Click the Merge Pull Request button on the next page,

Click Confirm Merge button,

Done: now the server-side user_story_01 branch SAVE into the Master Branch.

As shown,

Back to Visual Studio: update the local master by pull,

Then you finish the whole process to make a modification and save them into server (remote) master Branch, and update the local master Branch,

E: Save to the Remote (Azure DevOps)

For Branch name consistent, in D, we demo by using GitHub server, we do have a set of the demo for MS Azure DevOps, we originally planned to make another article to show it, but a lot of other staff will be duplicated. So, we make a section here to demo those processes, the name might not be consistent with the staff previously,

Push

After the push, we got this: Successfully pushed the local Feature/124766_migrate01 to the server, Click Create a Pull Request,

Note
Sometimes, for whatever reason, you might not get  Create a Pull Request like this.

Then, you need to get a pull request page (in DevOps server) to make a New Pull Request,

In the New Pull Request form of the DevOps server,

  • Fill in the Title (it usually be auto-created by your Request)
  • Fill in Description, if not auto-filled
  • Add reviewer
  • Add Work Item (Story)
  • Add a tag if any

After Create, you got this form, and waiting for peer review,

After approval, Click Complete,

You got the Complete Pull Request Form, If the organization requires to remove the current branch after the merge, then choose it in Post-Complete Options,

Complete Merge, you got,

Note
This DevOps Demo is not MS DevOps original one, it has been configured with some features.

Summary

This article discussed interactions between local Git and Remote DevOps by Visual Studio and the whole process from after getting the local copy from remote, till saving back to remote master with modifications. Here, we use GitHub as the server for the demo, but the whole process is the same as DevOps and AWS (GitHub Enterprise).

Although the internal behavior of DevOps, GitHub, and AWS (GitHub Enterprise) are the same or much similar, the interfaces are quite different (GitHub and AWS the same), so we will discuss the accesses to them and publish solutions to them separately, to enforces the different features.

Appendix

For the case, we have the main branch and a develop branch in the server (remote), while develop is against Dev server, main is against Prod server after development is done, how should we move the develop Branch to the main Branch,

Create Main branch package

  1. Checkout Develop & Pull to get the latest
  2. Checkout remotes/origin/main - Will create a local main branch
  3. Create a new local feature branch from the main
  4. Checkout local feature branch created out of main
  5. Merge develop into you feature branch created from main and create the pull request.
  6. On the pull request select main from the drop-down instead of developing and submit it for review.
  7. Once approved, complete the merge and trigger the build from the main branch

​Only one step is not covered from this article, Step 5, and we show here,

Reference


Similar Articles