Hansel and Gretel were abandoned since Hansel left bread crumbs to help him and his sister follow the return way back home. They found that birds had eaten the crumbs and Hansel and Gretel were lost in the woods.

Code commits a.k.a check-in/s are synonymous with leaving trails behind to come back home if need be. Overlooking good code commit practices is like leaving a trail of bread that may not be found when required, we need to build a trail with pebbles.

The most basic rule for a code commit is not to mix multiple topics together in a single commit. One commit => One topic(only)

However, an interesting situation would be when changes are made to the same file for two different topics. There are 3 ways to handle it :

1) Single check-in: Augmented with additional commit message 👎

2) Multiple check-in: Edit the file with change for topic#1, commit and edit the file again for topic#2 and commit, OK but can be better.👎

3) Partial check-in: Topic for this post 👍

GIT allows committing only a subset of the file in a commit, let's see how ?

Let's say we have 3 different files in the repository, file1, file2, and file3.

$ ls -al
total 15
drwxr-xr-x 1 manish 1049089  0 May 28 20:09 ./
drwxr-xr-x 1 manish 1049089  0 May 28 20:01 ../
drwxr-xr-x 1 manish 1049089  0 May 28 20:09 .git/
-rw-r--r-- 1 manish 1049089 11 May 28 20:08 file1.txt
-rw-r--r-- 1 manish 1049089 22 May 28 20:08 file2.txt
-rw-r--r-- 1 manish 1049089 11 May 28 20:09 file3.txt

Changes were made across 2 different topics.

- change for topic#1 edited contents in file1 and file2 and

- second change for topic#2 made changes to file2 and file3. 

"file2" share the changes for both the topics.

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   file1.txt
        modified:   file2.txt
        modified:   file3.txt

Add file2 to the staging area with -p flag. Git by default distribute the changes to a file in different hunks(parts). You can control the hunks with 'e' flag.

$ git add -p file2.txt
diff --git a/file2.txt b/file2.txt
index 0c90c4c..0057839 100644
--- a/file2.txt
+++ b/file2.txt
@@ -1 +1,7 @@
 I am file2 - Original
+
+<hunk1 - topic#1>
+       change to file2, topic1
+
+<hunk2 - topic#2>
+       change to file2, topic2
(1/1) Stage this hunk [y,n,q,a,d,e,?]?

With 'e' git will open an editor and the user can delete the lines of code that you wish to remove from the current commit and lineup for a later commit.

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1 +1,7 @@
 I am file2 - Original
+
+<hunk1 - topic#1>
+       change to file2, topic1
+
+<hunk2 - topic#2>  **--> Delete**
+       change to file2, topic2 **--> Delete**
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
#

Once you save the file, partial changes to file2 will be staged. Now add the file1 explicitly to the staging area.

_file (master)
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   file1.txt
        modified:   file2.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   file2.txt
        modified:   file3.txt

You are now good to commit for topic#1 with changes in file1 and "partial" changes in file2.

```$ git commit -m "Changes for topic#1, file1, file2-partial" [master f25b568] Changes for topic#1, file1, file2-partial 2 files changed, 5 insertions(+)

```

Traceability is important when we have to revert because of unintended system behavior and maintaining a good commit practice is an important tenet of a strong engineering team.