"Deployment Basics (2/7) — Git Fundamentals for Deployment: commit, branch, merge, push"

5월 18, 2026

Deployment incidents often begin in Git before they show up in production. If you do not know what changed, you also do not know what to roll back.

Key Takeaways

Git is not just a backup mechanism. It is the history layer that tells you what can be released and what can be restored.
commit fixes one unit of change in time, branch isolates work, merge moves reviewed work into shared history, and push sends that history to the remote.
push is not deployment. It is the handoff to the systems that may later deploy.
Small commits and deliberate branching are operational habits, not style preferences.

1. Git from a deployment perspective

Beginners often learn Git as a place to save code. For deployment, its role is sharper: Git is the record of which state is safe to promote, which state came before it, and why a change was introduced.

Without that record, deployment failure becomes guesswork. "It worked yesterday" is not useful unless yesterday's state is still identifiable.

2. What commit, branch, merge, and push actually mean

commit

A commit names and freezes one set of changes. Good commits carry intent, not just file movement.

branch

A branch is an isolated work lane. It lets you experiment without shaking the main release line.

merge

Merge moves branch work into shared history. Once reviews and tests attach to that step, merge becomes an approval signal rather than a file-combining step.

push

Push sends local history to a remote repository such as GitHub. Many beginners confuse push with deployment, but real deployment usually happens later through GitHub Actions, Vercel, Railway, or another platform.

3. The minimum Git flow to understand

The smallest useful pattern looks like this:

git checkout -b feature/login-copy
git add .
git commit -m "Update login page copy"
git push origin feature/login-copy

At that point the work exists on a remote branch. A Pull Request can review it. Tests can run against it. Only after merge to main does a deployment system usually act.

4. Why small commits help deployment

When one large commit mixes UI edits, environment changes, build updates, and content tweaks, debugging becomes expensive.

Small commits make release operations easier because:

the likely source of failure narrows faster
rollback is more precise
review becomes clearer
deployment history stays readable

In other words, small commits reduce recovery cost.

5. Common mistakes

The first mistake is working directly on main. That mixes experiments with release history.

The second is meaningless commit messages like fix, update, or asdf. Those are almost useless during rollback.

The third is stuffing too many unrelated changes into one commit. That makes deployment timing and blame assignment harder.

The fourth is thinking only in local terms. Deployment automation usually starts from the remote repository, so remote state matters more than local comfort.

6. Four rules that prevent many release problems

Start new work on a branch.
Keep each commit focused on one intent.
Merge only reviewable changes into main.
Treat deployment as something that happens after merge, not after random push events.

Those habits make the next layer, GitHub-based deployment, much easier to reason about.

References

GitHub Training, Git Cheat Sheet — https://training.github.com/downloads/github-git-cheat-sheet.pdf
Git SCM, Git Branching — https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
GitHub Docs, Understanding GitHub Actions — https://docs.github.com/en/actions/get-started/understand-github-actions

This is Part 2 of the Deployment Basics series. Next: how GitHub separates repository, Pages, and Actions.

이 블로그 검색

MaJu Tech Notes