A Safe Git and GitHub Workflow for HND IT Group Projects
A student-friendly branching, commit, pull-request and conflict-resolution routine that protects a shared main branch.
Team projects become difficult when everyone edits the same shared branch without checking one another's work. Git helps you record changes, but a simple process is what prevents accidental overwrites. This guide gives a repeatable workflow for a class assignment.
Start from a known shared state
Before new work, check which branch you are on and whether local files have unsaved changes. Fetch the latest remote commits and update your local main branch only when your own work is safely committed or set aside.
Use a descriptive feature branch such as feature/login-validation or fix/mobile-header. Small branches are easier to test, explain and review than one branch containing unrelated tasks.
Make one clear change at a time
Commit related work together with a message describing the outcome, for example 'Validate registration email before submit'. Avoid committing secrets, API service-role keys, build artifacts or a local environment file.
Review the diff before committing. If you see a configuration file or a teammate's work you did not intend to change, investigate it before pushing.
- git status — inspect changed files and current branch.
- git diff — inspect uncommitted changes.
- git add — stage only the intended files.
- git commit — create a clear local checkpoint.
- git push — publish the feature branch for review.
Review with a pull request
Open a pull request describing what changed, why it changed and how it was tested. Attach screenshots for visible UI changes and include steps for a reviewer to reproduce any fixed bug.
Wait for requested checks and review before merging. A passed build does not guarantee the feature works: test the related workflow and do a quick regression of nearby pages.
Resolve conflicts without discarding teammates' work
Conflicts occur when changes overlap. Read both versions carefully, identify the intended behaviour and agree on a final result rather than choosing the 'ours' or 'theirs' button automatically.
After resolving a conflict, rerun tests and review the combined diff. Never force-push a shared protected branch just to make an error disappear; ask for help if the branch history is unclear.
Quick checklist
- Changes are on a task-specific branch.
- No sensitive files or keys are included in the diff.
- The commit message explains the change.
- A pull request includes testing details.
- Conflicts are resolved intentionally.
- The shared main branch is updated only after review.
Always confirm current syllabus, coursework and assessment rules with your institute or lecturer.