Professional and Academic Purpose

Version control is part of normal professional software development. It records how software changes over time, provides meaningful recovery points, supports collaboration, and creates a development history that can be reviewed later.

In these courses, version control serves both a professional and an academic purpose. You are expected to learn and use Git as part of the development process. Commit history is also one source of evidence used in the AI-Integrated Classroom to help evaluate how a project developed. The history is evidence of development, but it is not by itself proof of competence or authorship.

Small, Smart, Often

Good commits should be small, smart, and often. This does not mean committing according to a timer or creating artificial commits simply to increase the commit count. A commit should represent a meaningful point in the development of the software.

Small: One Logical Change

A good commit represents one coherent change. This is often called an atomic commit: the changes belong together and have one understandable purpose.

Examples include:

• implementing and testing one function or method;
• fixing and testing one specific bug;
• adding validation for one behavior or input;
• refactoring one part of the program without changing its behavior; or
• adding or updating one related group of tests or documentation.

Whenever practical, a commit should leave the project in a coherent, working, and tested state. Avoid combining unrelated changes into the same commit. If several unrelated changes have accumulated before you commit, you probably waited too long.

Smart: Write Specific, Meaningful Commit Messages

Every commit message must be specific. The summary must identify both the specific thing or behavior changed and the meaningful change made to it.

action + specific target + meaningful effect

The diff records exactly how the code changed. The commit message explains what meaningful change the diff represents and, when necessary, why that change was made. A developer reading only the commit history should be able to identify the purpose of the commit without opening the diff.

Generic messages are not acceptable:

Add code
Fix bug
Update program
Make changes
Add validation
Implement methods

These are appropriately specific:

Implement Celsius-to-Fahrenheit conversion
Fix incorrect Fahrenheit conversion formula, change / to * and add parentheses
Reject non-numeric temperature input with error message
Preserve Square length after invalid update
Implement Square accessors and mutator as simple return and assignment with validation
Separate square comparison from reporting into different functions for better modularity

Write the summary in the imperative mood when practical:

Add input validation
Fix square area calculation
Implement square comparison
Refactor report formatting

Short messages are appropriate for simple changes, but brevity is not an excuse for vagueness. A summary such as Add input validation may still be too vague if the project contains several forms of input or several validation paths. In that case, write something more specific, such as Reject non-numeric temperature input.

When a Longer Commit Message Is Required

A one-line summary is enough when it completely explains the purpose of the change. Add a message body when important context cannot reasonably be captured in the summary. A longer message is expected when the change involves:

• a non-obvious bug or bug cause;
• an important design decision;
• a significant refactor;
• a meaningful change in program behavior; or
• another change whose reason is not obvious from the code or summary alone.

For example:

Fix default-length handling in Square

Invalid values were replacing the current length after
construction. Preserve the existing length instead and
use DEFAULT_LENGTH only during initialization.

Or:

Separate reporting from square comparison

Move output behavior into report_squares() so
compare_squares() only determines the comparison result.
This keeps calculation separate from presentation.

A useful commit body explains the reason, design decision, bug cause, or important behavior change. It should not narrate every line of code.

Commit messages should be as short as they can be while still being complete. Detail is required when it adds necessary meaning; unnecessary narration is not.

Often: Commit at Logical Development Boundaries

Commit whenever you complete a coherent, tested unit of work. There is no required number of minutes between commits. A difficult bug may take hours to resolve, while several small development steps may produce several commits in a short period of time.

The goal is not a high commit count. The goal is a development history made of useful, understandable checkpoints.

Commit and Push

A commit records a change in your local Git repository. A push sends your local commits to the remote repository on GitHub. Commit as you develop and push regularly so that GitHub reflects your current development history.

A local commit that has not been pushed exists only on your computer. Before an assignment is submitted or graded, make sure all completed work has been committed and pushed.

Academic Standard

Commit history is part of the professional record of your development process and is evaluated as part of Process & Professionalism. A weak, artificial, incomplete, vague, or missing development history may result in significant deductions.

The objective is simple: develop incrementally, test your work, create a commit when you complete a logical change, describe that change specifically and completely, and continue.