Let's split our changes into separate commits. We'll be able to check over our changes before staging them all from the terminal. Then, we'll see the positive effect it has on our commit history.
Our project consists of an HTML file which is stored in a Git repository. We want to add some animals to the "All About Animals" page that we have. We want to add some information about rhinoceros, lizard and bison. We're just using some example text from Wikipedia.
Now that we've made changes to our HTML file, we're going to want to commit them to our repository. Let's open up the terminal and let's use "git status" to show the files that's changed. At this stage, we could just "git add index.html" and commit the whole lot in one, but instead, we're going to use "git add --patch."
This is going to allow us to selectively choose which changes we can add to staging. We want to split up our changes into three separate commits. Down here, we have a range of choices. We can choose what to do with the change that we're looking at.
If we type "y" for yes, it's going to add all of the changes in one. Instead, we want to type "s" for split. This is going to split each of the changes into separate hunks. I'm going to stage the rhinoceros. Then I'm going to type "q" for quit. Now, I can commit the rhinoceros changes.
Let's do "git add --patch" again. Again, it's showing us all of the changes that are there. Let's split those again. Now we can see the lizard changes. Let's stage those, and quit again, and we'll commit those.
Let's add patch once more. The last change that's there is the bison so we can stage that and apply our last commit. Now if we look at our commit history, it's all split up nicely into separate commits.
This will be much more useful for anyone else that comes to work on our project because all of the features are split up. We also ensured that we're able to check over each change that we staged before we staged it, so it's less likely that bugs will creep into our project.