Appendix 2 — Part 4: How Changes Are Recorded and Reach GitHub

In the previous part, we learned how to connect AI to GitHub, make changes on a separate branch, and bring them into the main line after reviewing the result.

But GitHub is not just a place to store files. One of its most important features is keeping a history of a project's changes.

What does that mean?

Imagine you are preparing a PowerPoint presentation

You are going to speak at a dental conference and are creating your slides.

You have prepared the first ten slides and spent several hours on them. Now you want to continue, but you would like to be able to return to this state if something goes wrong later.

You might make a copy of the PowerPoint file and name it “Version 1.”

You make ten more slides and save another copy: “Version 2.”

If you keep doing this, after a while you will have several files and may not even remember how each version differs from the previous one.

One GitHub feature lets us record the state of a project at different stages and keep its history.

For example, after preparing the first ten slides, we record one state. After completing the second section, we record another.

If we later decide the new changes were not suitable, we can return to an earlier recorded version.

In dentistry, imagine you are digitally designing a crown. You complete the initial design, refine the contours, and then work on the occlusion.

It would be useful to save the design at each important stage, so you could return to an earlier one if later adjustments did not work out.

These are examples to help explain version history. GitHub is especially suited to text files and software projects; PowerPoint files and dental designs have their own limitations.

Now let us see how changes are recorded and reach GitHub.

One note before we continue: you do not need to learn technical commands or perform these steps yourself. AI can handle the operational work. We just want to understand the workflow and a few terms, so when AI reports what it did, we can tell what happened and whether the changes actually reached GitHub.

From the practice to the laboratory: three simple stages

Imagine that today we took impressions for several patients and are preparing to send their cases to the laboratory.

The impressions, bite records, and patient information are ready, but we have not handed them over to the laboratory yet.

There are three stages.

1. Stage: selecting and preparing changes

First, we select the impressions and case information we want to send from among the practice's work and place them on a table.

For example, we bring the first patient's impression together with its bite record. Then we place the second patient's impression beside it.

These are now the cases we have selected to send.

But nothing is final yet. We might notice that one patient's shade information is incomplete, so we set that case aside for now.

In a project, several files may have changed, but we may want only some of those changes included in the next recorded update.

Selecting and preparing changes this way is called staging, or Stage.

At this point, we have only decided what to record; no new version has been added to the history yet.

2. Commit: recording a specific state of the project

Now imagine that we review the cases on the table and make sure the set we want is complete.

We record the date and contents of this set in the case log, so that even if more work is added to the table later, we can still tell what was ready at this stage.

In a project, we similarly record a specific state of the selected changes in its history.

This is called a commit.

Each commit usually has a short description, such as “Revise postoperative care instructions.”

The difference from Stage is that staging only selected the changes, while a commit actually records a specific version of them in the history.

And importantly, nothing needs to have been sent to the GitHub website yet.

GitHub uses a system called Git, which can also run on a computer. If we work on our own laptop, the commit may be recorded there for now. If AI works in its own cloud workspace, the commit may be there instead.

3. Push: sending changes to GitHub

Let us return to the laboratory example.

We selected the cases, prepared the set, and recorded it in the log.

But they are all still on the practice's table!

Now we send the package to the laboratory.

In GitHub work, sending commits recorded in a workspace to the online repository is called a push.

So if AI says “I committed,” that means it recorded the changes in the history, but they may not have reached the GitHub website yet.

When a push succeeds, the commits that were sent have also reached the GitHub repository.

Some AI tools make changes directly on GitHub. In that case, the commit is recorded there, so a separate push is not needed.

If changes were recorded on a separate branch, reaching GitHub does not mean they have been merged into main. We can review them first and then decide whether they should enter the main line.

Let us try it

In Work (ChatGPT), say:

“In the my-prompts repository, add to the postoperative care instructions that the final text should be reviewed before it is given to the patient. Do it on a separate branch, record the changes on GitHub, and do not merge yet.”

After the work is done, you can simply ask:

“Send me the link to the changes and tell me what was changed.”

AI can carry out the necessary steps and provide the result for us to review.

What if we want to return to an earlier version?

Let us go back to the PowerPoint example.

Imagine you have prepared twenty slides. Now you decide to change their appearance: you choose a new template, change the colors and fonts, and move some details around.

You like the result, so you record this new state too (you commit it).

But when you look at the presentation again tomorrow, you realize the earlier design was much better!

If you recorded the earlier state (committed it), you can return to it and undo the newer changes.

This is another capability we can use with AI: reverting changes.

It is useful for more than undoing the latest change.

Imagine that over several months you have revised the postoperative care instructions many times and recorded the changes each time (committed them).

Now you can ask AI:

“Review the change history for these instructions. Tell me the dates when changes were recorded and what changed each time.”

AI can report when each version was recorded and what changed at each stage.

Then you can say:

“Review the changes we made on that date. I want to see what things looked like before then.”

Or even:

“I did not like the changes we made that day. I want to undo those changes without losing the others. First tell me what would be affected.”

This way, we do not have to start all over or search through old files for the version we want.

We just need the change history and can tell AI what we want to review or restore.

This applies to changes that were actually recorded in the history; unrecorded changes are not necessarily recoverable.

In the next part, we will learn about another GitHub feature: Pull Requests, where we can review a branch's changes before they enter the main line.