This cheat sheet guides Linux system administrators on installing Git and using it to track changes in system configuration files.
Initializing Git Repository
Tracking Configuration Files
git add on your configuration files, you can stage multiple files for a single commit by running
git add separately for each file. This approach allows you to selectively choose which changes to include in your next commit. It’s important to note that if you modify a file after staging it with
git add, these new changes will not be included in the upcoming commit. To include these latest modifications, you must run
git add again for the affected file before committing. This feature is especially useful when you want to review or adjust your changes before finalizing them in a commit.
Using the wildcard ‘*‘ with ‘git add‘ allows you to stage all modified files in the current directory at once. This is particularly efficient when you have multiple changes across different files and wish to include all of them in a single commit. However, be mindful of this approach, as it will add all changes, including any that you might not have intended to commit yet. It’s a good practice to use ‘git status‘ before committing to verify which changes are staged.
This step finalizes the changes in your local version of the repository.
Viewing Commit History
Use-Case examples for Admins
Scenario 1: Reviewing an Older Commit
When you want to review a specific older commit, especially when there have been several commits since then, use the ‘git log‘ to find the commit ID and then ‘git checkout’ to view the state of the files at that commit.
sudo git log --oneline
This command lists the commit history with concise one-line messages, making it easier to identify the specific commit you are interested in.
sudo git checkout [commit-ID]
This checks out the repository state at the specified commit ID. Replace ‘[commit-ID]’ with the actual ID from the log. This command temporarily switches your repository to the state at that commit, allowing you to review changes or configurations from that point in time.
Returning to the Current Codebase
After reviewing an older commit, it’s important to return to the latest state of your repository (the ‘main‘ or ‘master‘ branch).
sudo git checkout main
This command will switch you back to the main branch, updating your working directory to reflect the latest committed state. It’s essential to ensure you’re working with the most current version of your files after reviewing past commits.
Scenario 2: Discarding Uncommitted Changes
When you have made changes to a configuration file but decide not to keep them, Git allows you to easily revert to the last committed state.
sudo git checkout -- [file]
This command reverts the specified file back to the last committed state. Replace ‘[file]’ with the actual file name. It’s useful for quickly undoing changes that you do not wish to keep, ensuring your configuration remains consistent with the last known good state.
Scenario 3: Comparing Changes Before Committing
Before committing, it’s often necessary to review what changes you have made since the last commit. Git provides a straightforward way to compare these changes.
sudo git diff
This command shows the differences between the current state of the files and the last committed state. It’s a useful way to review all your changes in detail before finalizing them with a commit, ensuring accuracy and preventing unintended modifications.
Scenario 4: Reverting a Recent Commit
If you’ve committed changes but then realize you need to undo that commit, Git provides a straightforward method to revert it.
sudo git revert [commit-ID]
This command creates a new commit that undoes all changes made in the specified commit. Replace ‘[commit-ID]’ with the ID of the commit you want to revert. It’s a safe way to undo changes without altering the history, as it keeps the record of the original commit and the revert.