D197 Version Control carries the banner number ITSW 2110 and is worth one competency unit in the School of Technology, which makes it the smallest course most computer science and software engineering students meet and one of the easiest to underestimate. The catalog frames it as version control taught as the collaborative workflow every multi-file programming project depends on, so what the course really builds toward is the habit that every later programming course assumes you already have: a repository whose history explains itself. Search either D197 or ITSW 2110 and you land on the same one competency unit of work.
What D197 is really asking you to prove
The subject matter is small and the standard is not. Version control at WGU is taught as a workflow rather than a tool list, which means the competency being measured is whether you can keep a multi-file project coherent while more than one person changes it. Branching, merging, resolving a conflict, reverting a bad change and reading a history you did not write are the moves. A student who can run the commands but cannot explain why a branch existed has learned half the course.
One competency unit means the course is meant to be short, not shallow. The one-unit weighting sets an expectation about time, and students read it as an expectation about depth, which is where the trouble starts. A repository with three commits called update, update2 and final will run perfectly and still fail to demonstrate a workflow, because nothing in the artifact shows a decision being made.
If your version of the course is assessed by a performance assessment, the artifact is usually the repository itself plus something written about it, and the written part is where the competency is actually visible. If it is assessed by an objective assessment, the same understanding is tested through scenarios: given this history, what happened, and what would you do next. Either way the underlying question is identical. Can you account for the state of a codebase over time.
The course sits early in the technology sequence on purpose. Every later course that asks for a submitted application assumes you can produce a clean repository, and students who treated D197 as a formality relearn it under deadline where the stakes are higher.
Working backward from the aspects your evaluator scores
WGU scores performance assessment work aspect by aspect. Each aspect gets its own judgment, you need a score of 2 in every one of them to pass the task, and there is no averaging that lets a strong section carry a weak one. That single fact is the whole planning method: your outline should have exactly as many parts as the rubric has scored aspects, in the same order, using the rubric's own nouns as your headings.
Open the rubric in your Course of Study and count the scored rows. Do not count the general submission requirements, and do not count the professional communication row separately from the writing itself. What is left is your section list.
Here is the arithmetic worked through. Suppose your rubric shows seven scored aspects and you have decided the written portion should run about 1,400 words, which is a reasonable size for a one unit course. Seven into 1,400 is 200 words per aspect, which is roughly two solid paragraphs each. Now adjust, because aspects are not equal in weight. Aspects that ask you to describe something you did, such as the branching approach you chose, need the evidence and the reason, so give those 250. Aspects that ask for a single identification, such as naming the tool or the repository host, need 100 and no more. Move the 150 words you saved from the two thin aspects into the two that carry explanation, and the plan lands back at 1,400 with the weight in the right place.
Then attach evidence to each line before drafting. Next to every aspect write the commit, the branch, the file or the screenshot that proves it. An aspect with no artifact behind it is the one that comes back, and finding that out at the planning stage costs a minute rather than a week in the evaluation queue.
Sitting on D197 right now?
Send the aspects you can read plus a description of what is already in your repository, and you get an aspect map that says which commits are doing work and which are noise.
A structure that fits a version control deliverable
Version control submissions are part artifact and part explanation, and the explanation is what gets read closely. The shape below is a starting frame you adapt to whatever aspects your own rubric lists.
| Part | What belongs there | Rough share |
|---|---|---|
| Project and repository setup | What the project is, how many files it spans, where the repository lives and why that host was chosen | 10 percent |
| Branching approach | The naming pattern you used, what each branch was for, and the rule you followed for when a branch gets created | 20 percent |
| Commit history walkthrough | Selected commits in order, each with the change it made and why it was a separate commit | 25 percent |
| Merge and conflict handling | One real merge, the conflict if there was one, the resolution and what was kept | 20 percent |
| Recovery and rollback | How a bad change would be undone, named by the actual mechanism rather than described in general terms | 15 percent |
| Collaboration reflection | What changes when a second developer is in the repository, stated in workflow terms | 10 percent |
The middle three rows take almost two thirds of the space. Setup and reflection are the parts students overwrite and the parts an evaluator moves through fastest.
Evidence in this course is the history itself
Most WGU writing asks you to support claims with sources. Here the primary evidence is something you produced, which changes the craft. A claim like the branch was created to isolate the input validation work is worth nothing on its own and worth full credit the moment it is attached to a branch name and a commit hash that a reader can find.
Three habits carry the evidence load. Write commit messages in the imperative present, describing the change rather than the session, so that add input length check reads correctly and worked on stuff does not. Keep each commit to one logical change, because a commit that touches six unrelated files cannot be cited for any of them. Take screenshots that include the surrounding interface rather than a cropped rectangle, since an evaluator needs to see which repository and which branch is on screen.
When your writing needs an outside source, the official documentation for the version control system is the one to reach for, cited in APA like any other web source with the organization as author and a retrieval date where the page is versioned. A tutorial blog is a weaker citation for a definition than the documentation that defines the behavior. If your program requires APA formatting, the reference list applies to the written portion whether or not the rubric names it, and a submission with in-text citations and no matching reference entries is a preventable return.
Screenshots need captions that say what the reader is looking at. A figure labeled screenshot 1 makes the evaluator do the interpreting.
What separates Competent from a return
There are no letter grades at WGU and no ordinary grade point average behind them. Work is Competent or Not Competent, and a task that is not yet there comes back with evaluator comments so you can revise and resubmit without any grade penalty. That is a genuinely forgiving system, and it costs time rather than points, which for a student on a six month flat rate term is the currency that matters.
The submissions that clear on the first pass share a pattern in this course. Every claim about the workflow points at something in the repository. The history reads as a sequence of decisions rather than a series of saves. Commands and mechanisms are named precisely, so a merge is described as a merge and a rebase is not called a merge. The writing answers the aspect that was asked instead of the adjacent one, which sounds obvious until you read a section on branching strategy that spends four paragraphs explaining what a branch is.
Returns cluster around thin evidence. An aspect asks you to demonstrate conflict resolution, the response explains conflict resolution in the abstract, and no conflict appears anywhere in the artifact. Another asks for the rationale behind a branching model and gets a definition instead of a reason. Both are fixable in an hour, but only after the evaluation queue hands them back, which is why the aspect map matters more than the drafting speed.
Six mistakes that cost students time in D197
- Building the repository in one sitting at the end. A history created in twenty minutes looks like a history created in twenty minutes. Commits carry timestamps and the story they tell is part of the artifact.
- Treating the one competency unit as a signal about effort. The unit count describes weight in your program, not the number of aspects the rubric scores. A one unit course and a three unit course can have similar aspect lists.
- Writing about version control instead of about your project. Generic explanation of what merging is reads as filler. The aspect wants your merge, in your repository, on your files.
- Squashing everything into a single commit before submitting. Students tidy up and delete the evidence. Whatever the final state of the code, the history is part of what is being scored.
- Ignoring the professional communication expectation. Technical courses lull students into bullet fragments and unexplained jargon. The written portion is still read as writing.
- Leaving the repository private with no access note. If an evaluator cannot open what you cited, the citation does not exist. Confirm visibility or supply the screenshots that stand in for it.
None of these are conceptual problems. They are process problems, and process is the entire subject of the course, which is the small joke buried in D197.
How we work on this course
Support here is planning and drafting help around the artifact you own. Send the aspects your rubric shows and a description of the project, and you get back a section plan mapped aspect by aspect, a model of the written portion in the register WGU evaluators expect, and notes that explain the reasoning so the next course is easier rather than more dependent. Where the course or a section of it is assessed by an objective assessment, support is preparation only: concept notes, practice questions and an honest read on whether your preassessment says go or wait. Objective assessments are proctored, we prepare you for them and never sit them, never assist during one, and never ask for or touch your WGU portal credentials.
Terms are six months at a flat rate, so a course cleared in week two rather than week nine lowers what every other course in that term effectively costs you. A one unit course is the cheapest place to prove that the method works before you apply it to something with six units riding on it.
Three questions D197 students ask
Is D197 the same course as ITSW 2110?
How many tasks does D197 have?
Do I need a real project, or can I use a sample repository?
Where D197 sits in WGU's programs
The July 2026 catalog places this code in 10 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.