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)
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.
… co-authored with Dan Hellem, complementing the Version Control (ex Branching and Merging) Guide.
