git — Distributed Version Control

💬 "git commands"

Git is a distributed version control system that saves the change history of file contents in units called commits, so you can revert to an earlier state at any time or merge with multiple people.

Whether it's a server project or a personal script, keeping a change history lets you recover code you accidentally deleted and quickly track whose change caused a problem.

• Unit of saving: commit — a bundle of changes saved at once
• Working area: working tree (files being modified) → index (staging) → local repository
• Remote repository: a server repository shared through GitHub, GitLab, etc.
• Default branch: usually main — the branch that holds the latest stable state

Frequently used options

3 essential command combinations

• git status && git diff — check what changed, then commit
• git pull --rebase && git push — rebase your work on the latest remote changes and push
• git log --oneline --graph -n 20 — see branch merge points at a glance

💬 "Create an example in the order used during early-morning checks"

Here are common situations you encounter on a production server, arranged in order.

Preparing the repository

Start in an empty folder or register an existing folder.

mkdir demo && cd demo && git init

First commit

Create a README file and commit it.

echo '# demo' > README.md
git add README.md
git commit -m "First commit: add README"

Connecting to a remote

Connect the remote repository URL, then send the first push.

git remote add origin <repository URL>
git push -u origin main

How it's used in practice

1. Recovering something deleted by mistake

Situation — you were editing a log analysis script and completely broke its contents, so you need to roll back to the previous state.

git log --oneline -n 5
git checkout HEAD~1 -- analyze.sh
git status

Result — analyze.sh is restored to its contents at the previous commit.

Key point — if you don't commit after checkout, the restored content won't be recorded in history, so make sure to commit again.

2. Separating branches by feature

Situation — you want to create a new feature without touching the stable server deployment branch (main).

git switch -c feature/nginx-ssl
git commit -m "add nginx ssl configuration"
git switch main

Result — work is isolated in the feature/nginx-ssl branch, and main remains unchanged.

Key point — keeping main on the deployment server always in a working state reduces incidents.

3. Tracking who changed something and when

Situation — a single line in a configuration file changed and broke the deployment, so you need to find out when and who changed it.

git log -L 10,20:deploy.yml --oneline
git show <commit>

Result — the commit that touched that line appears along with the author and time.

Key point — instead of git blame, narrowing the range with -L lets you isolate only the culprit commit even in a long configuration file.

Things to watch out for

• Write commit messages that show “what” and “why” you changed for your future self.
• Exclude files containing passwords or API keys with .gitignore before committing.
• Be careful with force push on shared branches, because it can erase history.

Actual execution screen

This is a hypothetical example of running git status and diff --stat together in a server repository (not actual execution output).

!Example of checking git status and displaying a change summary

Live production server

Source (HTML): https://games.aidebatehub.com/programs/dev/vcs/git.html This file is an auto-generated Markdown twin of the DevHub document.