Track and Commit

Learning Competencies

• Define "commit"
• Demonstrate best practices for commit messages
• Describe the three states of a file in git (working, staged, commit)

Summary

Git works by following all of the changes in the files inside a git tracked folder. The save point in git is called a commit. Think of a commit like a checkpoint in a video game. It is a point where you can go back to and look at the state of the files at that commit. Like in a video game, if you make the wrong decision, you can go back to the checkpoint. A commit is your safety net if you accidentally introduce bugs in your code. You can revert to a working state while you debug your code. It is a great idea to commit often to create more frequent save points to fall back on.

Your git commit history is visible to us, and we use it to assess your participation and engagement. Throughout the course, we'll be looking at frequency and consistency. So we encourage you to engage daily and commit often. That means: whenever you add something that works, remove something, or fix something, commit it.

Time Box

Good Commit Messages

Because commits are 'save points', it is essential to write good commit messages, so you (and others) know what each commit includes.

We ask that you follow Git's convention and use imperative language for your commits. E.g. Use "Make dog bark" (imperative) instead of "Makes dog bark" or "Made the dog bark".

Excerpt from git.kernel.org

Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz" as if you are giving orders to the codebase to change its behaviour. Try to make sure your explanation can be understood without external resources. Instead of providing a URL to a mailing list archive, summarize the relevant points of the discussion.

Reflect

Open your reflections text file and answer:

• How would you describe stage and commit to your non-tech-savvy friend?