Git records a change and its reason without relying on copies named nginx.conf.old and nginx.conf.final. It is useful for application source, Ansible files, Kubernetes YAML and operational documentation. Start by separating a working file from the history of the changes made to it.
This series starts with Windows 11, Rocky Linux 9, and Ubuntu 24.04. It creates a private repository in the front, and connects the team’s changes in the back through testing, deployment, and production. You don’t need a server or Kubernetes from scratch.
Git · GitOps All Series · 01 / 24
On this page
Saving files and recording changes
Saving in the editor is an action that writes the current file to disk. Git’s commit leaves the selected file status at that point in the repository history along with a message. A commit also contains parent commit and creation information, so you can compare what has changed since then.
For example, if you change the timeout from 30 seconds to 60 seconds, you can apply it to the service just by saving the file. However, a separate record is required to explain the reason for the change after one month. A commit with a reason, such as Increase timeout for slow upstream, stores that decision along with the settings.
Initially, only three spaces are distinguished.
| terminology | meaning | When to check |
|---|---|---|
| work tree | Files being edited now | Immediately after fixing the file |
| Index/Staging Area | Status to include in next commit | When choosing changes to include in a commit |
| repository | A place to store commits, objects, and references | When compared to past content |
| HEAD | A reference to the currently checked out location. | When you see which branch you are working on |
A typical local repository stores history in .git within the project. If you delete this folder, you may lose any local history and settings, even if any work files remain. This is also why when creating a Git repository, you choose your actual project folder rather than your entire home folder.
파일 편집 → git add → git commit
작업 트리 인덱스 로컬 이력Even if you modify the file again after add, the contents of the index are not automatically updated. If you check git diff --staged right before committing, you can avoid mistakes where the file you see now and the actual content to be recorded are different. You can see this difference for yourself in Part 5.
Where are Git·GitHub·GitOps placed?
Git is a version control tool that runs on my PC. GitHub and Gitea are services that share Git repositories and manage reviews and access rights. You can work on local commits and branches even without an internet connection.
GitOps is an operating method in which the state required for operation is recorded as a version, and an agent retrieves the declaration and continues to match it with the actual system. Simply uploading YAML to Git or running kubectl apply in CI does not fulfill the entire principle. In the latter part, this difference is explained in terms of Argo CD’s tuning process.
| situation | starting point |
|---|---|
| Manage your configuration files and documents alone | Local repositories and commits |
| Two or more people review the change | Remote repositories and Pull Requests |
| Every modification requires testing | CI pipeline |
| Operate Kubernetes status in line with history | GitOps Controller |
What is missing if you think of Git only as a backup?
The running state of untracked files, databases, and servers cannot be recovered through a commit alone. Commits that are not pushed to the remote repository can also be lost if your disk disappears. The scope of Git history, server backup, and data backup must be determined separately.
Conversely, if you commit your password and private key, they will remain in your history even if you delete the files later. In the lab, only example values are used and the actual secret values are left out of the storage from the beginning. After a leak, key disposal and reissuance are carried out first rather than history cleanup.
Choose your operating system first
Install Git for Windows in Part 2, Rocky Linux in Part 3 or Ubuntu in Part 4. Follow the path for your operating system, then continue to the common repository exercise in Part 5. Run the common Bash examples in a Linux terminal or Git Bash; PowerShell-only examples are identified separately.
The terms are organized based on the Git official terminology , and the scope of GitOps is based on the OpenGitOps principles. The environment, actual verification scope, and entire file bundle are collected in the series guide.
Next · [Git and GitOps 02] Install Git on Windows 11: PowerShell and Git Bash · Serial list and example files
.jpg){kind=link}