Use git add -- . instead of git commit -a

[CasperWA]

Fixes #236

Every case of git commit -a usage has been split into a prior line of git add -- . before then committing to ensure the intended result happens, which is to commit all changes, be they changed files, new additions or even deletions (although the last here should not actually happen).

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1b3e997) 81.29% compared to head (073b423) 81.29%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #240 +/- ## ======================================= Coverage 81.29% 81.29% ======================================= Files 12 12 Lines 909 909 ======================================= Hits 739 739 Misses 170 170 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[daniel-sintef]

Can you confirm this AI-generated summary is accurate?

The two Git commands you've shared are used for staging changes and creating commits, but they differ in their approach and scope of action. Let's break down each command to understand their differences, advantages, and situations where one might be preferred over the other.

1. git commit -am "Release ${REF} - Changelog"

This command combines two operations in one:

• -a option automatically stages files that have been modified and deleted, but it does not affect new files (those not previously tracked by Git).
• -m option allows you to add a commit message directly in the command line.

This command is a shortcut that is useful for quickly committing changes to tracked files without explicitly running git add on them. However, because it only stages modifications to already tracked files, any new files you've created since your last commit that haven't been added to the repository won't be included in the commit.

2. git add -- . followed by git commit -m "Release ${REF} - Changelog"

This sequence involves two commands:

1. git add -- . stages all changes in the current directory and subdirectories, including new files, modified files, and deleted files.
2. git commit -m "Release ${REF} - Changelog" commits the staged changes with a specified commit message.

Situations Where the Second Approach is Better:

• Including New Files: When you have added new files to your project that need to be committed to Git, the second approach is necessary because the -a flag in the first command won't stage these new files.
• Granular Committing: In situations where you want more control over what exactly is being committed, the explicit git add step allows for selective staging. For instance, if you have multiple changes in your working directory but only want to commit some of them at a time, you can use git add with specific file paths or patterns before committing.

Specific Example:

Suppose you're working on a project and have made several changes: you've modified some existing code files, deleted others, and added a new feature with new files. You want to commit all these changes together while ensuring that the new feature files are included.

• Using git commit -am "Release ${REF} - Changelog" would not stage or commit the new files related to the new feature, potentially leading to an incomplete commit that doesn't capture the full scope of your changes.
• Using git add -- . followed by git commit -m "Release ${REF} - Changelog" ensures that all modifications, deletions, and new files are staged and included in the commit. This approach captures the complete state of your project changes, making it a better practice for comprehensive and accurate version control.