Hệ thống quản lý phiên bản & VCS HostingVersion Control Systems & VCS Hosting

Part of the DevOps Roadmap knowledge base.

Overview

Version control systems (VCS) track every change made to a codebase over time, letting teams collaborate on the same files without overwriting each other’s work, review history, and roll back to any previous state. Git — a distributed VCS created by Linus Torvalds in 2005 to manage Linux kernel development — has become the de facto standard: every developer has a full copy of the repository, so work continues offline and no single server is a point of failure.

For DevOps, version control is not just a developer convenience — it is the foundation of the entire delivery pipeline. CI/CD systems trigger on commits and pull requests; infrastructure-as-code, Kubernetes manifests, and pipeline definitions all live in Git; GitOps tools (Argo CD, Flux) treat a Git repository as the single source of truth for what runs in production. If it isn’t in version control, it effectively doesn’t exist — you cannot review it, audit it, roll it back, or reproduce it.

VCS hosting platforms (GitHub, GitLab, Bitbucket) add the collaboration layer on top of Git: pull/merge requests, code review, branch protection, issue tracking, and built-in CI/CD. Choosing a platform and a branching strategy shapes how fast and safely a team can ship. This page focuses almost entirely on Git because it has won the market decisively — but the concepts (history, branching, merging, review) apply to any VCS.

A short history of version control

Understanding where Git came from clarifies why it works the way it does:

• Local VCS (RCS, ~1982) — versioned single files on one machine with patch sets. No collaboration.
• Centralized VCS / CVCS (CVS 1990, Subversion/SVN 2000) — one central server holds all history; clients check out a working copy. Simple mental model, but the server is a single point of failure and every operation (log, diff, commit) needs network access.
• Distributed VCS / DVCS (Git 2005, Mercurial 2005) — every clone is a full repository with complete history. Branching and merging are cheap, most operations are local (and therefore instant), and there is no mandatory central server (though teams designate one by convention, e.g. origin).

Git’s distributed model is the single most important thing to internalize: your laptop holds the entire history, so git log, git diff, git blame, git bisect, and committing all work offline at memory speed.

Fundamentals

The three trees and the object model

Git’s mental model rests on three “trees” (states) and a content-addressable object database.

Files move through three areas:

working directory → staging area (index) → repository (committed history)

• Working directory — the actual files you edit on disk.
• Staging area / index — a proposed next commit you build up with git add. Staging lets you craft a clean, logical commit out of a messy working tree (git add -p stages individual hunks).
• Repository — the committed, immutable history in .git/.

Git stores snapshots, not diffs. Internally there are four object types, each addressed by the hash of its content:

Because objects are content-addressed, identical content is stored once, and any tampering changes the hash — history is tamper-evident. Git is migrating from SHA-1 to SHA-256 hashes to remove a theoretical collision risk.

Key references (pointers into the object graph):

• Commit — an immutable snapshot of the whole tree, identified by a hash, pointing to its parent(s). A merge commit has two (or more) parents.
• Branch — a movable pointer to a commit, stored as a one-line file under .git/refs/heads/. Cheap to create, cheap to delete — creating a branch just writes a 40-character hash to a file.
• Tag — a fixed pointer to a commit, typically marking a release (v1.4.2). Lightweight tags are just a ref; annotated tags are full objects carrying author, date, message, and optional GPG signature (use annotated tags for releases).
• HEAD — a pointer to the branch (or commit) you currently have checked out. Normally HEAD → a branch → a commit. When HEAD points directly at a commit you are in detached HEAD state.
• Remote — a reference to another copy of the repository (origin by convention). Remote-tracking branches like origin/main are Git’s local cache of where the remote’s branches were at your last fetch.

git init                        # create a repository
git add file.py                 # stage changes
git add -p                      # stage selected hunks interactively
git commit -m "Add parser"      # record a snapshot
git log --oneline --graph --all # visualise the commit DAG
git tag -a v1.0.0 -m "Release"  # annotated tag
git push origin main --tags     # publish branch and tags
git cat-file -p HEAD            # inspect the raw commit object

Commit graph, fetch / pull / push

History is a directed acyclic graph (DAG) of commits, not a straight line. Understanding the three network operations prevents most confusion:

• git fetch — download new objects and update remote-tracking refs (origin/*). Never touches your working tree or local branches. Always safe.
• git pull — fetch + integrate (merge by default, or rebase with --rebase). Because it mutates your branch, prefer fetch then look before you integrate. Set git config pull.rebase true (or pull.ff only) to avoid surprise merge commits.
• git push — upload your commits and move the remote branch. Rejected if it isn’t a fast-forward (someone else pushed first) — fetch and integrate, then push again.

Merge vs rebase

Both integrate changes from one branch into another; they differ in the history they produce.

A fast-forward merge happens when the target hasn’t diverged: Git just slides the pointer forward, no merge commit. Force a merge commit with --no-ff when you want the feature boundary recorded.

# Update a feature branch with latest main, keeping history linear
git checkout feature/login
git fetch origin
git rebase origin/main          # replay my commits on top of main
# resolve conflicts, then:
git rebase --continue
git push --force-with-lease     # safe force-push of a rewritten branch

# Clean up local history before opening a PR
git rebase -i HEAD~5            # squash/reword/reorder the last 5 commits

Rule of thumb: rebase your own unpublished work; merge everything shared. --force-with-lease is safer than --force: it refuses to overwrite the remote if someone else pushed in the meantime.

Resolving conflicts

A conflict occurs when two branches change the same lines. Git marks them and stops:

<<<<<<< HEAD
timeout = 30
=======
timeout = 60
>>>>>>> feature/login

Resolve by editing to the intended result, git add the file, then continue (git merge --continue / git rebase --continue). Useful helpers: git mergetool, git checkout --ours/--theirs <file>, and git rerere (reuse recorded resolutions) for repetitive conflicts on long-running branches.

Undoing things

The single most reassuring fact about Git: committed work is very hard to truly lose. Know these and you can experiment fearlessly.

git restore file.py             # discard working-tree changes (was: git checkout -- file)
git restore --staged file.py    # unstage, keep working-tree changes
git commit --amend              # rewrite the most recent commit (local only)
git revert <sha>                # new commit that undoes a commit (safe on shared branches)
git reset --soft  <sha>         # move branch pointer, keep changes staged
git reset --mixed <sha>         # move pointer, unstage (default)
git reset --hard  <sha>         # move pointer, discard everything (local only, destructive)
git reflog                      # log of everywhere HEAD has been — your safety net
git stash / git stash pop       # shelve dirty changes to switch context

git reflog records every move of HEAD for ~90 days, so even a reset --hard or a deleted branch is recoverable: find the lost commit’s hash in the reflog and git checkout or git branch it back.

Key Concepts

Branching strategies

The branching model is a team-level decision that trades release cadence against process overhead.

Modern DevOps guidance (DORA research, the Accelerate book) consistently favors trunk-based development with short-lived branches: fewer merge conflicts, faster feedback, higher deployment frequency, and lower change-failure rate. The heavier Git Flow was designed for scheduled desktop-software releases and is usually overkill for services deployed many times a day.

Feature flags are the enabler that makes trunk-based development possible: merge incomplete code to main behind a flag that is off in production, decoupling deploy (shipping the binary) from release (turning the feature on). This also enables canary rollouts and instant kill switches.

VCS hosting platforms

All three speak the same Git protocol, so switching hosts is mostly a matter of migrating issues/PRs and CI config — the repository itself is portable.

PR/MR workflow and code review

A typical pull request lifecycle:

1. Branch from main, commit small focused changes.
2. Open a PR/MR early (draft) — CI runs automatically on every push.
3. Reviewers comment; author pushes fixes (each push re-runs CI).
4. Required checks pass → approvals given → merge.
5. Branch is deleted; deployment pipeline picks up main.

Merge methods — the choice shapes your history:

Good review culture matters more than the tool: keep PRs small (ideally < 400 lines changed), review promptly, comment on the code not the person, and use “request changes” sparingly. Reviews spread knowledge and catch defects earlier than any later stage.

Protected branches and policy

Branch protection rules turn process into enforcement. On main (and release branches) typically:

• Require a PR before merging (no direct pushes).
• Require N approving reviews (often 1–2), and dismiss stale approvals on new pushes.
• Require status checks to pass (CI, lint, security scan) and to be up to date with the base.
• Require conversation resolution, signed commits, and/or a linear history.
• Forbid force pushes and branch deletion.
• Optionally require review from CODEOWNERS — a file mapping paths to owning teams so the right people are auto-requested.

# .github/CODEOWNERS
/infra/            @org/platform-team
*.tf               @org/platform-team
/services/billing/ @org/billing-team @alice

Monorepo vs polyrepo

Neither is universally better. Monorepos optimize for atomic changes and code sharing but demand serious build tooling at scale; polyrepos give clean isolation but push complexity into version coordination and dependency management. Team size, tooling maturity, and how coupled your services are should decide.

Git hooks

Hooks are scripts Git runs at lifecycle events — automation that fires without anyone remembering to run it.

Client-side (local, can be bypassed): pre-commit (lint/format before a commit is created), commit-msg (validate the message, e.g. Conventional Commits), pre-push (run tests before publishing). Server-side (authoritative, cannot be bypassed by clients): pre-receive and update (reject pushes that violate policy), post-receive (trigger deployments, notifications — the basis of many CI and GitOps systems).

# .git/hooks/pre-commit  (must be executable: chmod +x)
#!/bin/sh
ruff check . || exit 1          # block commit if lint fails

Because .git/hooks/ isn’t versioned and client hooks are skippable, teams manage hooks with the pre-commit framework or Husky (Node.js) so hooks are versioned, shared, and installed automatically — and always re-check the same rules in CI, which cannot be skipped.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: detect-private-key       # cheap, high-value secret guard
      - id: check-merge-conflict

Handling large files and monorepo scale

Git stores every version of every file forever, so committing large binaries (media, datasets, compiled artifacts) permanently bloats history. Mitigations:

• Git LFS — replaces large files with small pointer objects and stores the real bytes on a separate server.
• .gitattributes — normalize line endings (* text=auto), mark binaries, and configure LFS filters.
• Partial/shallow clone — git clone --depth 1 (shallow), --filter=blob:none (blobless), and sparse checkout let you work with a slice of a huge monorepo.

Powerful tools worth knowing

• git bisect — binary search over history to find the commit that introduced a bug in O(log n) steps; can be fully automated with a test script (git bisect run ./test.sh).
• git blame / git log -S "text" (pickaxe) — find when and why a line or string changed.
• git worktree — check out multiple branches into separate directories from one repo (e.g. build a hotfix without stashing).
• git cherry-pick <sha> — copy a specific commit onto the current branch (e.g. backport a fix to a release branch).
• git submodule / subtree — embed one repo inside another (submodules are powerful but a common source of confusion; use deliberately).

Best Practices

1. Commit small and often, with meaningful messages — small commits are easier to review, bisect, and revert. Write the subject in the imperative (“Add retry to uploader”), keep it under ~50 chars, and explain why in the body. Follow a convention such as Conventional Commits (feat:, fix:, chore:) to enable automated changelogs and semantic versioning.
2. Keep branches short-lived — merge within a day or two. Long-lived branches accumulate conflicts, hide work, and delay integration feedback (a core DORA finding). Integrate main into your branch frequently.
3. Protect main — require PRs, passing CI, and at least one review; disable force pushes and direct pushes. Production should only ever be built from a protected branch.
4. Never commit secrets — use .gitignore, secret scanning (GitHub secret scanning/push protection, gitleaks, trufflehog) in a pre-commit hook and in CI, and a real secrets manager. A secret that touched Git history must be rotated, not just deleted — it lives forever in clones and reflogs.
5. Rebase local work, merge shared work — never rewrite history that others may have pulled; use --force-with-lease, never bare --force, when you must push a rebased branch.
6. Use git revert on shared branches — it undoes changes with a new commit, keeping every clone consistent, instead of rewriting published history.
7. Tag releases and automate versioning — annotated (and signed) tags plus CI-driven release pipelines make every production artifact traceable to an exact commit. Adopt SemVer.
8. Adopt CODEOWNERS and required reviews — routing changes to domain owners raises review quality, spreads knowledge, and prevents lone-wolf changes to critical paths.
9. Automate quality gates with hooks and CI — lint, format, test, and scan in pre-commit for fast local feedback, and again in CI as the authority (hooks can be skipped; required CI cannot).
10. Store everything as code in Git — application code, infrastructure (Terraform), pipelines, Kubernetes manifests, dashboards, alerts, and runbooks. This enables GitOps: the repo is the source of truth and drift becomes detectable and revertible.
11. Use .gitattributes for line endings and Git LFS for large binaries — * text=auto prevents cross-OS CRLF/LF churn; LFS keeps history from ballooning.
12. Write a good .gitignore early — exclude build artifacts, dependencies (node_modules), local env files, and IDE cruft. Use a starter from github.com/github/gitignore; committing generated files causes noisy diffs and merge conflicts.
13. Learn git bisect and git reflog — bisect finds a regressing commit in logarithmic time; reflog recovers “lost” commits after a bad reset or deleted branch. Knowing they exist turns Git from scary to safe.
14. Sign your commits and tags — GPG/SSH signing (or GitHub’s verified commits) proves authorship and prevents spoofed commits in security-sensitive supply chains.
15. Prefer squash-merge for feature PRs on a linear-history repo — one clean commit per feature keeps main readable and makes reverts trivial, while the full detail stays on the (now-deleted) branch and in the PR.
16. Keep the repository the source of truth, not a mirror — decisions, config, and process live in the repo (via files, PR templates, CODEOWNERS), not in tribal knowledge or chat history.

References

• Pro Git book (free, official): https://git-scm.com/book/en/v2
• Git official documentation / reference: https://git-scm.com/docs
• Git internals (objects, refs) — Pro Git ch. 10: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
• roadmap.sh DevOps roadmap: https://roadmap.sh/devops
• GitHub Docs — About pull requests: https://docs.github.com/en/pull-requests
• GitHub Docs — About protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches
• GitLab Docs — Merge requests: https://docs.gitlab.com/ee/user/project/merge_requests/
• Trunk-Based Development: https://trunkbaseddevelopment.com/
• Atlassian Git tutorials (merge vs rebase, Git Flow): https://www.atlassian.com/git/tutorials
• Conventional Commits: https://www.conventionalcommits.org/
• Semantic Versioning: https://semver.org/
• pre-commit framework: https://pre-commit.com/
• Git LFS: https://git-lfs.com/
• GitHub’s collection of .gitignore templates: https://github.com/github/gitignore
• DORA / Google Cloud — DevOps capabilities (version control, trunk-based dev): https://dora.dev/capabilities/