> For the complete documentation index, see [llms.txt](https://gitdeveloperguide.solomonmarvel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitdeveloperguide.solomonmarvel.com/git-fundamentals/git-basics-practice-scenarios/committing-changes.md).

# Committing Changes

#### <mark style="color:blue;">Scenario</mark>

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:**&#x20;

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:

```bash
git init
```

Step 2 - **Check the Status:**

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

```bash
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:

```bash
git add file.txt
```

To stage multiple files, list them separated by spaces:

```bash
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:

```bash
git add .
```

Step 4 - **Review Changes:**

To review the changes you have staged before committing, use the command.&#x20;

```bash
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:

```bash
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.

{% hint style="success" %}
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).&#x20;

**Aim for logical units of change that maintain a clear and concise commit history.**
{% endhint %}