This article is the sixteenth edition of the Advent of Patterns series. In this series, running from December 1st to December 24th 2024, I will document one design or programming pattern I have noticed recently. Read more about this series.
I was recently working with a web page developed in Webflow. The page was on a “branch”, which means it was independent from the rest of the live website. When I was getting ready to publish the site, Webflow showed a change log summary of how many changes would be merged.
Here is an example of what the pattern looks like in Webflow:
In my case, Webflow highlighted that several global design changes would be made. This encouraged me to check with the designers to make sure that publishing the page would not cause conflicts with other parts of the site.
The change summary helped me understand, at a high level, what changes had been made. With that information, I could then evaluate if the changes were ready to be merged and published with the site.
This got me thinking about the pattern of a “change overview.”
Git implemements the pattern of a change overview. At any time, you can run the git status command to see:
- What files have changed since your last commit.
- What files have been added.
- What files have been removed.
The git status command gives you an understanding of your current state relative to the previous state of your project. Here is an example:
Above, I can see several pieces of important information: the branch I am on, changed, added, and removed files, whether my branch is up to date with the origin, and more. This is an overview of the state of the repository when compared to the last saved commit.
I use the git status command every day to see what files I have changed. I then use the information to decide which ones I am ready to commit. For example, when I am working on documentation sites I sometimes generate a version of the documentation in the same directory as I am working in. The git status command tells me if the generated files would be added to the repository. If I don’t want this, it is a sign that I need to add a declaration in the .gitignore file to ensure the files aren’t committed.
From the information provided in git status, I can decide:
- What I want to commit.
- What I don’t want to commit yet, and;
- What I want to exclude from the repository.
When you commit a change, Git gives you a summary showing the changes:
This gives me further confidence that I have saved the correct changes in my repository history. If I notice a file has been created and committed accidentally, I can go back and modify the commit (although this is difficult and gets to a point about how I wish the Git UX were better!). I can then “push” my code, where it will be saved to a remote origin (i.e. GitHub).
Related to the change summary is the pattern where an application will ask you to confirm closing a window when there are unsaved changes. For example, many web pages will double-check if you want to close the tab if you have filled out a form field. This gives the user a chance to confirm that they want to close the page before the page is actually closed. I appreciate this pattern because it helps prevent me from accidentally deleting changes that I wanted to save.
In what other places does the “change overview” pattern come up?
