Committing Changes

Committing changes is a fundamental aspect of using Git, as it allows you to save and track the progress of your project.

Scenario

You're a developer working on a new learning management system's backend api and you're about to commit the changes made on your project files. Here's a pattern for such workflow:

Step1 - Initialise a Git Repository:

Before committing changes, you need to initialise a Git repository in your project directory. Open a terminal and navigate to your project's root directory. Use the following command to initialize Git:

git init

Step 2 - Check the Status:

Once the repository is initialised, you can check the status of your files using the command:

git status

It displays information about untracked, modified, and staged files.

Step 3 - Stage Changes:

Staging is the process of preparing files for a commit. To stage changes, use the git add command followed by the file or files you want to stage. For example, to stage a single file:

git add file.txt

To stage multiple files, list them separated by spaces:

git add file1.txt file2.txt

To add all changes in your working directory to the staging area, this command adds both new and modified files. For example:

git add .

Step 4 - Review Changes:

To review the changes you have staged before committing, use the command.

git diff --staged

Step 5 - Commit Changes:

Committing creates a new snapshot of your project with the changes you have staged. Use the git commit command followed by the -m flag and a descriptive message. For example:

git commit -m "Added feature XYZ"

Write meaningful commit messages that describe the purpose of the changes.

---

Benefits of Making Smaller, Focused Commits

Making smaller, focused commits offers several benefits:

1. Improved Readability: Smaller commits with focused changes are easier to understand and review. Each commit represents a specific set of changes, making it simpler to track the project's evolution.

2. Granular Versioning: Smaller commits allow for more granular versioning. If you need to roll back a specific change or introduce a hotfix, it's easier to identify the relevant commit when changes are compartmentalised.

3. Easier Collaboration: Smaller commits facilitate collaboration within a team. When multiple developers are working on the same project, smaller commits reduce the chances of conflicts and make it easier to merge changes.

4. Reverting Changes: With smaller commits, reverting a particular change becomes less daunting. If a commit introduces an issue or breaks functionality, it can be rolled back without affecting other unrelated changes.

5. Better Code Review: Smaller commits enable more effective code reviews. Reviewers can focus on specific changes, providing more targeted feedback and catching potential issues more easily.

It's essential to strike a balance between making commits too small (resulting in a commit history cluttered with numerous tiny changes) and making commits too large (which can make it harder to understand and review changes).

Aim for logical units of change that maintain a clear and concise commit history.