# 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gitdeveloperguide.solomonmarvel.com/git-fundamentals/git-basics-practice-scenarios/committing-changes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.