Git for the TFVC User – Workflow Investigations Part 1: Making Changes

… co-authored with Dan Hellem, complementing the Version Control (ex Branching and Merging) Guide.

In our silent preview of the Git for the TFVC User guide we intentionally excluded walkthroughs for “happy path” workflows, including only guidance and basic workflow steps. For example, the Making Changes section included the following five steps:

objective

In this series we would like to share our notes, NOT guidance, and invite you to give us candid feedback on our proposed walkthroughs that are related to the high-level workflow steps mentioned above:

• Part 1 (this) – Making Changes (using centralized workflow and using topic branch workflow)
• Part 2 – Reviewing Changes (no conflicts)
• Part 3 – Reviewing Changes (with conflicts)
• Part 4 – Converting a TFVC repository

---

walkthrough 1.1 – making changes using centralized workflow

We walk through the centralized workflow without creating merge conflicts to keep this workflow simple.

Step	Instructions
1 Create repo ꙱ - Done	Typically start by creating a centralized origin repo for your Team Project using the Web Portal. You can have one repo or multiple repos for each Team Project, as covered in Many Git Repositories, but one Team Project to rule them all We create a welcome README.md file, which creates the first commit to the origin repo. Origin master is the pointer on the origin (centralized) repo the latest commit ?is associated with (A).
2 Clone repo ꙱ - Done	Each developer clones the repository from the centralized origin to their local repo. Doris, the developer, creates a local clone. As no changes have been made, the origin and Doris pointers point to the same commit ?. Using the Git Extensions we see the following view for Doris’ repo: Dave, the development lead, creates a local clone. As no changes have been made, the origin and Dave pointers point to the same commit ?. At this point we have a central and two distributed repos which are essentially identical. GEM Distributed repo == backup! As we have three distributed repositories, we have three possible repos that could be used to recover a single point-of-truth in case of a disaster.
3 Make changes ꙱ - Done	Doris makes a change by creating her own Demo-Doris.md and adding the file to the local repo. Dave makes a change by creating his own Demo-Dave.md and adding the file to the local repo.
4 Commit changes ꙱ - Done	Doris commits her change to her local repo. Origin master now points to commit (A) and Doris’ master to commit (B): Using Git Extensions we see the following view for Doris’ repo: Dave commits his change to his local repo. Origin master now points to commit ? and Dave’s master to commit (C): At this point the central origin repo is unaware of the changes made in the distributed repos, and Dave’s and Doris’ local repos are unaware of the change made in the other repos. Changes are isolated!
5 Synchronize changes ꙱ - Done	Doris selects Sync, which performs a pull and push operation. NOTE Pull – Pulls the latest changes from origin repo and merges them into working copies. Push – Pushes the local commited changes to origin repo. Both the Origin master and Doris’ master now point to commit (B). Christine, the tester, edits the README.md file twice on the origin repo to reference Doris’ new markdown file and reference Dave’s pending markdown file. Dave selects Sync, which performs a pull and push operation. Doris selects Sync again, which performs a pull operation, but no push as she has made no further commits. The origin, Doris’ and Dave’s master pointers all point to the same commit at this point. GEM Isolation As shown in this simple example, everyone was able to work in their repo, isolated from the others, and synchronizing when appropriate. At this point we again have three identical repos!

---

walkthrough 1.2 – evolve into a topic branch workflow

Again we will walk through the centralized workflow without creating merge conflicts to keep this workflow simple.

Step	Instructions
1 Branch ꙱ - Done	Doris, the developer, continues from the previous walkthrough or clones the repo from the origin to her local. Doris branches from her local master to Doris-Feature-Branch topic branch.
2 Make change ꙱ - Done	Doris ❶ selects the topic branch and makes a change, for example, ❷ creating a new markdown file Demo-Doris-Feature.md and ❸ adding it to the branch.
3 Commit change ꙱ - Done	Commit the change to the local repo.
4 Push change ꙱ - Done	Doris selects Publish branch to publish the topic branch to central repo. Using the Branch explorer on the Web Portal, we see the newly published and isolated branch.
5 Review topic ꙱ - Done	Doris could now Merge her local topic branch to her local master branch and push the changes to the centralized repo. Alternatively and recommended, she could request a Pull Request to initiate a code review and give the team an opportunity to collaborate on the changes before committing the change to the stable master. … to be continued in PART 2 - Reviewing Changes.

Thoughts?