Post History

I think there are three general strategies:

1. Take notes.
2. Configure everything through some utility that keeps track of it.
3. Learn the default state and diff the system vs. it.

------------------------------

Taking notes is self evident. This is a bit tedious, but taking notes about what you are doing is a good general habit for any adult, not just for Linux but life in general. So if you are already motivated to maintain this habit, you can simply be disciplined about always noting whatever changes you make. You can use something as simple as a paper notebook, or it may be easier to have a bunch of text files on your computer for the sake of copy/paste.

Useful things to note are:

* When you made the change
* If you were following a guide, links to it
* Versions of software you think may be relevant. It helps to learn some shell idioms for [printing the version](https://linux.codidact.com/posts/291632) and [sending it to the clipboard](https://linux.codidact.com/posts/291633).
* If you changed a specific config file, the exact path to it and which line number you changed. You can get the path from `realpath`.
* If you changed it by clicking on things in a GUI, you can describe what exactly you clicked or save a screenshot

If this leads you to think that configuration files are superior to GUI utilities, because of how much easier changes are to record, you are right :)

Sometimes, it is useful to also save things like console output and logs if you feel like you might need it. It takes some time to learn how to judge whether this is overkill or not for a given change, so to start out I'd record as little as possible to avoid overwhelming yourself.

---------------------

The "utility" method is nice because it can reduce the tedium of note taking by leveraging technology to do it. The common way is to use "dotfiles". This means that you use git to track changes to each config file as if it were a piece of code. Git will handle tracking paths, exact lines, reproducing the same change on a nother computer, annotations about why you did something (commit messages), chronology... But you will have the following challenges:

* Git is designed to track files inside a given "project" directory, but your config files will be all over the filesystem
* Many config files require admin privileges (`sudo`) to edit, which git normally doesn't have
* Some things are configured in a way that git cannot handle (exotic binary formats, mixing volatile state information with configs so that it looks like there's many changes even when you didn't change anything)

The first two have many nice solutions in the dotfiles community. The third is harder, you have to either avoid programs that can't be easily configured via dotfiles, or you have to automation write scripts that handle the configuration to avoid making git deal with the config state directly. Firefox and Chrome are a great example: They have a very messy config directory that doesn't separate user configuration from data like history that will always change under normal use. They also have a lot of obfuscated data, like things wrapped up in some binary database file instead of a simple text file. From this you see a third option - for exceptional cases like Firefox, use git only to take notes to manually configure them, while still doing the full dotfiles approach for the majority of other programs which have better design.

-----------

Doing diffs is IMO not practical as a general approach, because most desktop OSes acquire very complex state after a few years of normal use. This is more practical for:

* Things like servers that have a narrow usage
* Distros designed around it, like Guix or NixOS
* As a fallback in when you discover after the fact that you forgot to keep track of something

In Linux these days, configuration that applies to all users on that computer will be somewhere under `/etc`. Boot-time things maybe baked into the initial boot environment (under `/boot`) but they will still be controlled by configs under `/etc` (see GRUB and `mkinitcpio`). Configuration that applies to only one user should be somewhere under `~/.config`.

These days, most Linux systems have only one human user, but usually there is a second, hidden "admin" user that doesn't share your user's config. When you do things with `sudo` you may notice your configuration reverts to default sometimes, the short answer is that `sudo` sometimes looks at `/root/.config` instead of `/home/$USERNAME/.config`.

The above are simply conventions and not every program is guaranteed to follow it. A developer may choose to put the configs in some random place just because. This is discouraged in the community because it makes it harder to find the configs, so you may find it useful to avoid the work of such developers. Also, in past years it was common to put configs in `~/.program_name` instead of `~/.config/program_name` and some older software may still do it.

Generally, I think trying to identify changes post-mortem is a case-by-case thing. So I won't aim to describe it fully in this answer. A better way would be to try some basic naive guesses based on the above, and if you can't find it, ask a new question about specifically that case on this site (or elsewhere).