Let's take a look at the lifecyle of a Git Branch.

Unlike TFVC, branches in Git are typically short lived when it comes to development. In TFVC you may have a branch for each developer or a branch for development in general, another for test then a release branch. In Git, we will be using branches differently. We'll get a change request as a work item in DevOps, review it, create a branch, assign to a developer to do the work plus commit it, optional build automation may occur, next a pull request, or PR, with a review and then the changes are accepted into the parent branch. We'll walk through this in specific details. In this example, we'll be using a bug but you can replace "bug" with "Feature", "Product Backlog Item", "Change Request", "Customization", "Enhancement", or any other word that would indicate the end result of this activity will result in some code that needs to be managed. We'll also be focusing on Azure Devops.

A Bug is Born

First, we're going to create a bug.

This has been assigned to me so I'm going to review the task. I'll confirm it is an issue then create a branch for it. I can do this by going to the ellipsis then selecting "New Branch".

Create a Branch

I've confirmed this is an issue. Next, i'm going create a branch and give that branch a name. 

You'll notice the new branch is already associated with my bug. Next I just have to select the repo and branch I want to create the new branch off of. This is the equivalent of "Branch..." in VS when using TFVC. 

Assign to a Developer and Start work

Once your develop environment is setup based on your package management methodology, you should be able to get started. You can change your branch easily in Git. The first way is with VS. Open VS, open Team Explorer for your repo, click on branch, expand remotes/origin then double click on the branch you'd like. Please see here and here for how to configure your development environment for Git.

Now you can get to work. You would work as you normally would. When you're done, anything not excluded in your .gitIgnore file will automagically show up in "changes", like so:

Now we can commit. We'll also want to be sure to sync changes to the server. However, we aren't quite done yet. The final step is the pull request which we'll cover in great detail later.

(optional) Build Automation

Using YAML, you can create some build automation on actions that may be helpful. in TFVC, we would build our pipelines against a branch. In Git, we're creating and deleting branches much more frequently so YAML can help create a pipeline for each branch. We'll discuss this concept more later.

The Cycle Continues

That was 1 cycle of a typical workflow using Git. That represents what each work item could look like if you branch per work item which I suggest. Each branch can be thought of a work area for a developer. Also, since PR's take everything in the branch, developers can commit when half way done to switch their branch to something else if priorities change. Each developer signals they are done with their dev work when they create a PR so we won't "changeset scumming" to pull out what was approved from a large set of changesets. We'll talk in greater detail how you can configure your branches for managing what goes into your release builds.