This page describes the common GitHub workflow used for IT 140 assignments and projects.
It explains the shared workflow rather than replacing the instructions in an activity repository. When supporting a specific assignment or project, follow that repository's current README.md for exact commands and files.
GitHub is used to:
- host public course repositories;
- create private student assignment and project repositories from course templates;
- maintain remote backups of student work;
- practice Git-based development workflows;
- provide repository Issues, Discussions, and Wikis where appropriate; and
- support course technical documentation and automation.
GitHub is not the grading or submission system for normal IT 140 assignments and projects.
D2L Brightspace remains authoritative for:
- activity requirements;
- what to submit;
- grading;
- deadlines; and
- instructor feedback.
Course instructions beginning in Module Two assume that the student has:
- access to a GitHub account;
- completed the GitHub account readiness steps in Module One;
- configured two-factor authentication as required by GitHub;
- identified the GitHub username used for IT 140;
- recorded the GitHub-provided
@users.noreply.github.comemail address used for Git configuration; and - access to a configured course IDE.
For exact account-setup instructions, use the current Module One GitHub Account Setup.
For a new assignment repository, the normal flow is:
Read Brightspace Guidelines and Rubric
↓
Read the GC-STEM activity README
↓
Confirm the correct GitHub account
↓
Create a private student repository from the current template
↓
Clone the private repository into ~/Repos
↓
Open the local clone in VS Code
↓
Complete work
↓
Commit and push periodically
↓
Submit required deliverables in D2L Brightspace
The course repositories commonly use GitHub CLI.
A useful first check is:
gh auth statusConfirm that the active account is the GitHub account the student intends to use for IT 140.
When multiple GitHub accounts are configured, the activity README may direct the student to switch accounts.
Do not create a new assignment repository until the correct active account is confirmed.
The course workflow uses GitHub templates, not forks, for student assignment and project repositories.
A typical activity command pattern is:
cd ~/Repos
gh auth setup-git
gh repo create <repository-name> --template GC-STEM/<repository-name> --private --clone
cd <repository-name>
git remote -vThe exact activity README may include additional commands, such as starring the course template.
Use the complete command block from the current activity README rather than reconstructing it from this example.
After creation and cloning, git remote -v shows which GitHub repository the local copy is connected to.
For normal student work, the local assignment/project repository should point to the student's private repository, not directly to the GC-STEM public template.
Students normally open the repository folder from:
~/Repos/
The repository itself should be the top-level folder shown in the VS Code Explorer.
Examples:
~/Repos/it140-m2-assignment
~/Repos/it140-m3-assignment
~/Repos/it140-m4-assignment
~/Repos/it140-projects
The student edits the files identified by the activity README.
Provided READMEs, configuration, tests, SRS/SDD documents, and other course-managed files should remain unchanged unless the activity explicitly permits or requires editing them.
Saving a file in VS Code saves it to the local filesystem. It does not automatically place the latest work on GitHub.
Students periodically use Git to:
- review changes;
- stage the intended files;
- commit those changes; and
- push commits to GitHub.
Typical commands include:
git status
git add <files>
git commit -m "Describe the saved work"
git pushActivity READMEs may provide a specific git add command that stages only the student working and deliverable files for that activity.
Supporters should prefer the activity-specific command when available.
A student normally creates the private repository once.
When returning later on the same computer:
- open VS Code;
- open the existing repository folder in
~/Repos; and - continue working.
Do not create another repository from the template merely because the student is returning to the assignment.
If the student's private GitHub repository already exists but the local clone does not:
- clone the student's existing private repository;
- do not create another private repository from the course template.
A common pattern is:
cd ~/Repos
gh repo clone "$(gh api user --jq .login)/<repository-name>"
cd <repository-name>
git statusUse the current activity README for the exact command.
it140-projects is different from the one-module assignment repositories.
The student creates the private it140-projects repository once in Module Five and continues using the same repository through:
- Module Five / Project One;
- Module Six / Milestone; and
- Module Seven / Project Two.
The student should not create a new it140-projects repository for each module.
If:
- the local folder is damaged, confusing, or incomplete; but
- the student's private GitHub repository contains a good current copy,
the normal recovery model is:
- preserve or rename the current local folder;
- clone the existing private GitHub repository again; and
- verify the new local clone before deleting any backup.
Activity repositories may provide exact Restore Your Local Copy From GitHub commands.
Caution
Never delete the student's only copy of work before confirming that a good copy exists elsewhere.
Starting over is appropriate only when the student intentionally needs a fresh copy of the current course starting point.
The normal course recovery pattern preserves the previous work by renaming:
- the existing local repository; and
- the existing private GitHub repository,
before creating a new repository from the current template.
This is different from recloning an existing student repository.
Use the activity's current Start Over From the Original Course Template instructions when available.
Students repeating part or all of IT 140 should create and use repositories from the current course templates for the new course attempt.
They should not use an old assignment or project repository as the active working repository for the new attempt.
Using the current template ensures that the student receives the current:
- repository layout;
- instructions;
- starter files;
- tests;
- configuration; and
- support resources.
A prior repository may be preserved under a different name for reference or backup, subject to applicable course and academic-integrity requirements.
A student's assignment or project repository is private.
When an instructor or LSS needs to inspect the repository directly, the student may grant collaborator access when that support workflow is appropriate.
Do not require a student to make a graded-work repository public merely to obtain support.
Role-specific guides should explain when direct repository access is useful and how the supporter should handle student work.
Public course repositories may provide:
- Issues for technical problems or requested improvements; and
- Discussions for repository-related questions or course-community discussion when appropriate.
Do not post in public GitHub areas:
- passwords;
- authentication or verification codes;
- personal access tokens;
- recovery codes;
- private identifying information;
- confidential student information; or
- complete solutions to graded assignments.
Questions about assignment requirements, grading, deadlines, accommodations, and instructor feedback belong through the course/instructor support path rather than a public repository issue.
These GitHub features serve different purposes:
- Star — bookmark a repository so it is easier to find.
- Watch — receive repository notifications; generally optional.
- Fork — create a linked fork of another repository; not the standard IT 140 student assignment workflow.
- Use as template / template creation — create a new independent repository from the course starting point; this is the IT 140 assignment/project model.
Before changing a repository, identify:
GitHub username:
Repository name:
Repository owner:
Repository visibility:
Local path:
Remote URL:
Useful commands include:
gh auth status
git status
git remote -vThese checks often reveal whether the problem is:
- the wrong GitHub account;
- the wrong repository owner;
- the wrong local folder;
- a missing local clone;
- a local clone connected to an unexpected remote; or
- a repository that already exists.
A failed command or confusing local folder does not automatically mean the student should start over.
Before recreating a repository:
- identify the student's existing GitHub repository;
- determine whether current work has been pushed;
- determine whether the local clone can be recovered;
- preserve existing work; and
- use the activity's documented reset process if a restart is truly needed.
- Course Overview
- Course Repository Architecture
- Terminology
- Supported Environments
- Support Boundaries
- Escalation Model
Return to the Shared Documentation Index.