Git حرفه‌ای: از درون تا جریان کاری تیمیProfessional Git: Internals to Team Workflow

Almost no software engineering job posting skips "solid Git skills". But there is a world of difference between someone who types git add . && git commit -m "fix" && git push and someone who can rescue a team's history when it breaks mid-release.

We start at the lowest layer — what Git writes to disk — and climb up to team workflow, merge policy, code review and disaster recovery. Once you own the right mental model you stop memorising commands and start deriving them, which is exactly what a senior interviewer measures.

1. What Git really is: a key-value database

Let us build the jargon from zero: an object is Git's smallest unit of storage; a hash / SHA turns any input of any length into a fixed 40-character hex string (Git uses SHA-1, still the default in 2.55), and that string is both the address and the integrity seal:

git init demo && cd demo
printf 'hello world\n' > a.txt
git hash-object a.txt
# 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

Git does not hash the raw content; it first prepends a header of the form <type> <length>\0:

printf 'blob 12\0hello world\n' | sha1sum
# 3b18e512dba79e4c8300dd08aeb37f8e728b8dad  -

Exactly the same number: a simple, reproducible formula.

The four object types

Let us build all four:

mkdir -p src && printf 'x\n' > src/b.txt
git add -A && git commit -m "init"

git cat-file -t HEAD     # commit
git cat-file -p HEAD
# tree 6bbaeff7e1c7c5273a642077161513885b3dd2fa
# author T <a@b.c> 1785444725 +0330
# committer T <a@b.c> 1785444725 +0330
#
# init

git ls-tree HEAD   # the same tree, one level down
# 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad	a.txt
# 040000 tree add4794d9c94872b96c1697c056fb82ae0d72880	src

git tag -a v1.0.0 -m "release 1.0.0"
git cat-file -p v1.0.0
# object b858574c4a9533bfdcadcb7f5fbda5ffb63705dd
# type commit
# tag v1.0.0

Notice the commit contains no files; it only points at a tree. git ls-tree -r HEAD expands it down to the blobs.

Diagram: the Git object graph — each commit points to a tree and to its parent / نمودار گراف object در Git.

flowchart LR
  TAG["tag v1.0.0"] --> C2["commit b858574"]
  C2 --> C1["commit 9f2a1c0 parent"]
  C2 --> T0["tree 6bbaeff root"]
  T0 --> B1["blob 3b18e51 a.txt"]
  T0 --> T1["tree add4794 src/"]
  T1 --> B2["blob 587be6b b.txt"]

2. refs, HEAD, and just how cheap a branch is

The warehouse is full of anonymous boxes with only fingerprints, so we stick a sticky label on some of them — a label you can peel off and move to a newer box. In Git those labels are refs:

• branch: a ref under refs/heads/ that advances automatically with every commit.
• tag: a ref under refs/tags/ that never moves.
• remote-tracking ref: a ref under refs/remotes/<remote>/ — the last thing you saw on the server, not what is on the server right now.
• HEAD: the "where am I standing" pointer; usually a symbolic ref to a branch.

cat .git/HEAD                 # ref: refs/heads/main
git rev-parse HEAD            # b858574c4a9533bfdcadcb7f5fbda5ffb63705dd
git for-each-ref --format='%(refname) -> %(objectname:short)'

In the classic files backend a branch is a text file holding a 40-character hash plus a newline — 41 bytes. That is why branching in Git is effectively free, which explains the rise of branch-centric workflows.

Diagram: how refs and HEAD point into the object graph / نمودار ارجاع ref و HEAD به گراف object.

flowchart LR
  HEAD["HEAD symbolic ref"] --> MAIN["refs/heads/main"]
  MAIN --> C3["commit C3"]
  FEAT["refs/heads/feature"] --> C4["commit C4"]
  ORIGIN["refs/remotes/origin/main"] --> C2["commit C2"]
  TAGV["refs/tags/v1.0.0"] --> C2
  C4 --> C3 --> C2 --> C1["commit C1"]

If HEAD points directly at a commit instead of a branch, that is a detached HEAD: git switch --detach v1.0.0 (modern) or git checkout v1.0.0 (old, same effect).

3. The three trees: the model that explains everything

The index is a binary file at .git/index listing paths with blob hashes and metadata. The next commit is built exactly from the index, not from the working tree:

git ls-files -s
# 100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0	a.txt
# 100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0	src/b.txt

That trailing 0 is the stage number. Normally it is always 0; during a conflict you also see 1 (base), 2 (ours) and 3 (theirs) — we come back to that in section 7.

Diagram: the three trees and the command that moves data between them / نمودار سه درخت و دستور جابه‌جایی بین آن‌ها.

flowchart LR
  WT["Working tree"] -- "git add" --> IDX["Index / staging area"]
  IDX -- "git commit" --> HEADT["HEAD commit"]
  HEADT -- "git restore --staged" --> IDX
  IDX -- "git restore" --> WT
  HEADT -- "git reset --hard" --> WT

git status --short --branch      # compact summary for daily use
git diff                         # working tree vs index  (what you have NOT staged)
git diff --staged                # index vs HEAD          (what WILL be committed)
git diff HEAD                    # working tree vs HEAD   (the sum of both)
git add -p                       # stage hunk by hunk
git log --oneline --graph --decorate --all

The habit that shows an engineer's level is git add -p: instead of dumping one tangled 400-line change into a single commit, you split it into three meaningful commits — "behaviour-preserving refactor", "bug fix", "test" (keys: y, n, s to split, e to edit). Second habit: run git diff --staged before every commit; it is the only reliable way to be sure an API key never enters history.

4. Branching and merging: fast-forward versus three-way

git switch -c feature/checkout        # create + switch  (Git 2.23+)
git branch --merged main              # fully contained in main → safe to delete
git branch -d feature/checkout        # safe delete: only if merged

Case one — fast-forward: if the target branch got no new commit since the fork point, Git has nothing to merge; it drags the main label forward to the feature tip. No commit is created and the graph stays linear.

Case two — three-way merge: if both sides have new commits, Git takes three points — base (nearest common ancestor, from git merge-base), ours (tip of the current branch) and theirs (tip of the incoming branch) — and builds a commit with two parents. Since Git 2.34 the default strategy is ort, which is faster than the old recursive and detects renames better.

git merge --no-ff feature/checkout      # always create a merge commit
git merge --ff-only origin/main         # fail if it would not be a fast-forward
git merge --squash feature/checkout     # dump the changes into the index, do not commit

Diagram: a three-way merge creates a commit with two parents / نمودار three-way merge با دو والد.

flowchart LR
  C1["C1 base"] --> C2["C2 main"]
  C1 --> C3["C3 feature"]
  C2 --> M["M merge commit"]
  C3 --> M

A subtle point about --squash: it is not a merge. The resulting commit has only one parent and no ancestry link to the source branch, so Git does not know that branch was merged — git branch --merged will not list it, and merging it again replays every commit.

5. rebase: rewriting history in a controlled way

With git rebase main, Git takes the commits belonging only to your branch (main..feature) and reapplies them one at a time onto the tip of main. Each new commit gets a new hash, because its parent changed and a commit hash includes the parent hash.

Diagram: rebase replays commits onto a new base; hashes change / نمودار بازپخش commit ها روی پایهٔ جدید در rebase.

flowchart LR
  C1["C1"] --> C2["C2 main"]
  C1 --> C3["C3 old"] --> C4["C4 old, dropped"]
  C2 --> C3p["C3' new hash"] --> C4p["C4' feature"]

Interactive rebase: the main history-cleanup tool

git rebase -i main (or HEAD~5, or --root) opens a "todo" file whose lines look like <command> <hash> <subject>; you reshape history by editing them.

When you spot a mistake in an earlier commit mid-flight, use --fixup instead of a "fix typo" commit:

git add src/Cart.java
git commit --fixup=a1b2c3d          # produces: "fixup! feat(cart): add coupon field"
git rebase -i --autosquash main     # it slots into the right place automatically

git config --global rebase.autoSquash true
git config --global rebase.autoStash true   # auto stash/unstash uncommitted work

There are three forms of --fixup and most engineers know only the first: --fixup=<c> changes the content of <c> only; --fixup=amend:<c> changes content and message; --fixup=reword:<c> changes only the message. Git 2.55 also added the EXPERIMENTAL git history fixup|reword|split <commit>, doing the same jobs without the rebase editor (with --dry-run and --update-refs) — do not depend on it in CI.

If you stack branches, rebasing the base used to strand the upper ones. git rebase --update-refs main (or git config --global rebase.updateRefs true) fixes that: per the documentation, any branch pointing at a commit being rebased is force-updated automatically, except branches checked out in another worktree.

rebase or merge?

The common, defensible strategy: rebase locally to clean up, merge to integrate. Keep your branch current with git pull --rebase, but let it enter main through a pull request and a controlled merge.

6. cherry-pick, stash and the "undo" family

cherry-pick takes a single commit and applies it somewhere else. Its real use is the hotfix: a fix written on main must also reach release/2.4, without the rest of main.

git cherry-pick -x a1b2c3d              # records "cherry picked from ..."; range: a1b2c3d^..e4f5g6h
git cherry-pick --continue | --skip | --abort

cherry-pick creates a new commit with a new hash; if you later merge the source branch Git sees two copies of one change, and when the surrounding lines have moved you get a conflict. Always pass -x so the origin is recorded.

stash is a temporary drawer — really an unreferenced commit in refs/stash that is never pushed:

git stash push -u -m "wip: coupon ui"   # -u also takes untracked files
git stash pop                           # apply and remove from the list
git stash branch fix/coupon stash@{2}   # create a new branch at that point and apply

Three three-month-old stashes on a laptop are three pieces of work that vanish with one dead disk. Beyond "I need to switch branches for five minutes", push a temporary branch instead.

reset versus revert versus restore

Most mistakes happen here, and the three-tree model explains all of it:

git reset --soft HEAD~1        # reopen the last commit, keep the changes
git restore --staged .env      # I staged a file by mistake
git restore src/Cart.java      # throw away local changes (unrecoverable!)

7. Conflicts: what they are and how to resolve them properly

A conflict means Git could not decide: in a three-way merge both sides changed the same region of the same file relative to the base. If only one side changed it, Git takes that side silently.

<<<<<<< HEAD
int total = price * qty;
=======
int total = price * qty - discount;
>>>>>>> feature/coupon

One setting makes conflicts far more understandable and most engineers do not know it: git config --global merge.conflictStyle zdiff3. With zdiff3 a third section appears — the original text (base) between ||||||| and =======; without it you see two outcomes and cannot tell what each started from.

The loop is simple: git status lists the both modified files, you edit each and git add it, then finish with git merge --continue — or git merge --abort to undo everything.

git diff --name-only --diff-filter=U        # only the conflicted files
git checkout --ours|--theirs path/file      # take one whole side
git show :1:path/file                       # base   (:2: = ours, :3: = theirs)
git mergetool                               # your configured three-pane tool
git merge --abort                           # back to before the merge

Those :1:, :2: and :3: are the stage numbers from section 3 — during a conflict the index keeps three versions of the file.

If a long-lived branch produces the same conflict on every rebase, set git config --global rerere.enabled true. rerere means reuse recorded resolution: Git records each conflict's shape and your resolution, then reapplies it automatically (git rerere forget <path> clears a bad one).

8. reflog: the last line of defence — and bisect: finding a regression

Refs only show the current state, but Git also runs a security camera: every time a ref tip moves it records a frame. That is the reflog, and until those frames expire almost nothing is truly lost.

git reflog                       # b858574 HEAD@{0}: commit (initial): init
git reflog show main             # movements of one specific branch
git switch -c rescue HEAD@{5}    # rescue it as a new branch

bisect: finding the guilty commit by binary search

A test that was green a month ago is red now, with 400 commits in between. Git does a binary search — about 9 steps instead of 400. Manually: git bisect start, then git bisect bad and git bisect good v2.3.0, answer good or bad at each step, and finish with git bisect reset. The professional form is automated:

git bisect start HEAD v2.3.0    # or: git rev-list -1 --before="3 weeks ago" main
git bisect run ./bisect-run.sh
git bisect log > bisect.log     # reproducible, attach it to the ticket

#!/usr/bin/env bash
# bisect-run.sh
./gradlew --quiet compileJava || exit 125     # untestable → skip
./gradlew --quiet test --tests '*CartTotalTest*'

That 125 is gold: when the build does not compile at some commits, bisect skips them instead of drawing a wrong conclusion. With a history full of merge commits, --first-parent follows only the mainline and narrows the culprit to "which PR"; and good/bad can be renamed with --term-new/--term-old.

The hardest step is writing a deterministic reproducing test; bisect without a reliable signal is useless. Bisect is also why atomic, always-green commits matter — if half a team's commits do not build, bisect is worthless, which is itself an argument for squash-merge.

9. Tags and semantic versioning

git tag -a v1.4.2 -m "release 1.4.2"   # annotated: a real object (without -a: lightweight)
git tag -s v1.4.2 -m "release 1.4.2"   # annotated + signed; verify with -v
git push origin v1.4.2                 # tags are NOT pushed automatically!
git tag -d v1.4.2 && git push origin :refs/tags/v1.4.2   # delete locally and on the server
git describe --tags --dirty            # v1.4.2-7-gb858574

For releases always use annotated tags: git describe only sees annotated ones by default, so lightweight tags make build versioning scripts produce the wrong version. And never move a published tag — people who already fetched keep the old one; if you made a mistake, publish a new number.

SemVer 2.0.0 uses MAJOR.MINOR.PATCH: MAJOR for a breaking public-API change, MINOR for a backward-compatible feature, PATCH for a bug fix. A pre-release such as 1.5.0-rc.1 ranks below the final version, and build metadata such as 1.5.0+20260731 is ignored when comparing.

Its natural companion is Conventional Commits 1.0.0, a machine-readable convention: <type>[optional scope][!]: <description>, plus an optional body and footers.

feat(cart): apply coupon at checkout
fix(pricing): round tax to 2 decimals

feat(api)!: drop v1 endpoints

BREAKING CHANGE: /api/v1/* removed, migrate to /api/v2/*

Mapping to SemVer: fix → PATCH, feat → MINOR, ! or a BREAKING CHANGE: footer → MAJOR. That is what lets release tooling compute the version and changelog without a human.

Write the commit message for "the person six months from now": subject ≤ 72 characters, imperative mood ("add", not "added"), no full stop; a blank line; then a body answering why, not what — the what is readable from the diff, the why lives only in your head. For metadata there are trailers: git commit --trailer "Refs: PROJ-1421".

10. Remotes: fetch, pull and push without disaster

A remote is an alias for another repository's address; origin is a convention, nothing special. A refspec says which ref over there maps to which ref over here:

git remote show origin                     # full status, including stale branches
git config --get remote.origin.fetch
# +refs/heads/*:refs/remotes/origin/*

Read that refspec as "take every branch on the other side and put it under refs/remotes/origin/". The + means non-fast-forward updates are allowed — which is why origin/main moves without complaint when a colleague force-pushes.

Diagram: fetch only downloads; merge or rebase is what changes your work / نمودار: fetch فقط دانلود می‌کند و merge یا rebase کار تو را عوض می‌کند.

sequenceDiagram
  participant W as Working tree
  participant L as Local branch main
  participant R as Remote-tracking origin/main
  participant S as Server
  W->>L: git commit
  L->>S: git push
  S-->>R: git fetch updates origin/main
  R->>L: git merge origin/main
  R->>L: or git rebase origin/main
  Note over R,L: git pull = fetch + merge (or rebase)

git fetch --prune origin               # download + drop deleted remote-tracking refs
git log --oneline HEAD..origin/main    # what arrived that I do not have? (reverse it for unpushed)
git pull --rebase                      # = fetch + rebase

The configuration nearly every professional team sets:

git config --global pull.rebase true          # make pull rebase instead of merge
git config --global fetch.prune true
git config --global push.autoSetupRemote true # first push sets upstream automatically (Git 2.37+)
git config --global merge.conflictStyle zdiff3
git config --global diff.algorithm histogram  # more readable diffs for code
git config --global init.defaultBranch main

git push --force                                   # ❌ never on a shared branch
git push --force-with-lease                        # ✅ only if the remote is where you think
git push --force-with-lease --force-if-includes    # ✅✅ the safest form
git config --global alias.pushf 'push --force-with-lease --force-if-includes'

11. .gitignore, .gitattributes, hooks and large files

target/                 # build output
.env                    # environment and secrets
.idea/                  # developer tooling — better placed in ~/.config/git/ignore
!config/default.env     # exception

Precedence, weakest to strongest: $HOME/.config/git/ignore → .gitignore in parent directories → .gitignore in the same directory → .git/info/exclude. A later pattern wins, and git check-ignore -v <path> names the rule and file responsible.

.gitattributes is under-appreciated but powerful:

* text=auto                        # LF in the repo, native line endings in the working tree
*.sh text eol=lf                   # shell scripts always LF, even on Windows
*.png binary                       # never diff or convert line endings
CHANGELOG.md merge=union           # keep both sides: no conflict
.github/ export-ignore             # excluded from release archives

merge=union is a genuine trick for append-only files such as CHANGELOG.md, which always conflict because everyone appends. Use it only where order and duplication are harmless; on code the result does not compile while the merge reports success.

Hooks

A hook is an executable script Git runs at specific lifecycle points. Their default home is .git/hooks/, which is never pushed; to share them set git config core.hooksPath .githooks, or use the pre-commit framework, which manages versions and installation from a .pre-commit-config.yaml.

Submodules, subtrees and monorepos

A submodule is a Git repository inside another one, where the parent stores only a pointer to one specific commit; a subtree brings the other repository's content into your own history so cloning stays ordinary; a monorepo puts everything in one repository.

git submodule add https://example.org/team/lib.git libs/lib
git clone --recurse-submodules <url>
git submodule update --init --recursive       # if you forgot
git subtree add --prefix=libs/lib <url> main --squash

The trade-off: submodules keep the version boundary explicit and the repository light, but everyone must learn extra commands and forgetting --recurse-submodules is common; subtrees keep cloning ordinary but inflate history and make contributing upstream harder; a monorepo enables atomic refactors across services but needs tooling:

git clone --filter=blob:none <url>            # partial clone: blobs arrive later
git clone --depth=1 <url>                     # shallow clone: good for CI
git sparse-checkout init --cone && git sparse-checkout set services/payments
scalar clone <url>                            # auto-configuration for large repositories

Large files and Git LFS

Git was built for small text files. A 200 MB video changed ten times makes the repository 2 GB forever, because history is never deleted. The standard answer is Git LFS (current stable line: 3.7.x): git lfs install && git lfs track "*.psd" writes the rule into .gitattributes (*.psd filter=lfs diff=lfs merge=lfs -text), after which Git stores a small pointer file instead of the content.

Three real traps: (1) platforms bill LFS storage and bandwidth against a quota, and CI that clones fully every time burns it — use GIT_LFS_SKIP_SMUDGE=1; (2) anyone without the LFS client sees pointer text instead of the file; (3) leaving LFS requires rewriting history. Before adopting LFS, ask whether the file belongs in version control at all, or in an artifact repository.

12. Four team workflows — and when to pick which

A workflow is the team's contract about which branches exist, how code travels and how a release is built. Let us compare four common patterns.

a) Git Flow — two permanent branches (main, develop) plus three temporary types

Diagram: Git Flow with two permanent and three temporary branch types / نمودار Git Flow با دو branch دائمی و سه نوع موقت.

flowchart LR
  F1["feature/x"] --> D["develop"]
  F2["feature/y"] --> D
  D --> R["release/1.4"]
  R --> M["main tagged v1.4.0"]
  R --> D
  H["hotfix/1.4.1"] --> M
  H --> D

Right when you ship numbered versions customers install (a library, a mobile app, on-premise software). Wrong for a SaaS deploying daily, where develop only doubles the merges.

b) GitHub Flow — a single always-deployable main

Diagram: GitHub Flow keeps a single always-deployable main / نمودار GitHub Flow با یک main همیشه سبز.

flowchart LR
  M0["main"] --> B["feature/short-lived"]
  B --> PR["Pull Request + CI + review"]
  PR --> M1["main merged"]
  M1 --> DEP["deploy to production"]

Right for a service that deploys constantly and has fast rollback; wrong when you must support two versions at once.

c) GitLab Flow — GitHub Flow plus environment branches

Diagram: GitLab Flow promotes code forward through environment branches / نمودار GitLab Flow و جریان رو به جلوی کد در محیط‌ها.

flowchart LR
  FT["feature branch"] --> MAIN["main"]
  MAIN --> STG["pre-production"]
  STG --> PRD["production"]
  HF["hotfix"] --> PRD
  HF --> MAIN

Right when deployment is scheduled, or compliance demands that "what is in production" be an auditable ref.

d) Trunk-Based — the branch lives in the code, not in Git

Everyone works on one trunk with sub-day branches, and unfinished work hides behind a feature flag.

Diagram: trunk-based moves the branch into the code, behind a flag / نمودار trunk-based و انشعاب پشت flag.

flowchart LR
  DEV["short-lived branch under 1 day"] --> TRUNK["main trunk"]
  TRUNK --> CI["CI on every commit"]
  CI --> ART["build artifact once"]
  ART --> ENVS["deploy to all environments"]
  FLAG["feature flag off by default"] --> ENVS

Right for a mature team with strong automated tests and feature flags. Wrong when coverage is weak — trunk-based without tests means broken production.

13. Pull requests and code review at a professional level

Review quality falls off a cliff with PR size: a two-thousand-line PR gets "LGTM", a 150-line PR gets a real opinion. Three tactics: separate refactors from behaviour changes; send mechanical changes such as renames on their own; and use stacked PRs, which git rebase --update-refs keeps maintainable.

Shift the language of review from "you" to "the code": instead of "why didn't you null-check here?", write "what happens if order is null here?". And make severity explicit; many teams use prefixes: blocking: before merge, suggestion: optional, nit: taste, question: I want to understand — then the author knows what is holding up the merge.

Server-side gates

The rules that get enforced are the ones the platform enforces, not the ones in a wiki. Protected branches / rulesets: no direct pushes, required PRs, a minimum number of approvals, required green status checks, no force-push or branch deletion, required commit signing, and dismissal of approvals on every new push. Rulesets are the modern replacement: several apply at once, they are defined organisation-wide, and they carry bypass lists with an audit trail.

CODEOWNERS assigns an owner to each path and makes their approval mandatory:

# .github/CODEOWNERS  (or CODEOWNERS at the root or in docs/)
*                       @org/platform-team
/services/payments/**   @org/payments-team
/infra/**               @org/sre @org/security

The patterns behave like .gitignore and the last matching pattern wins — so put the general rule at the top and the specific ones below.

Merge queue: the platform lines PRs up, tests each on top of the previous result, and merges only if it stays green — the only scalable way to prevent "both PRs were green separately but together broke main".

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git log --show-signature -1

14. Release branches and hotfixes

Diagram: hotfix flow — fix on the release line, then merge back to trunk / نمودار چرخهٔ hotfix و بازگرداندن آن به trunk.

sequenceDiagram
  participant P as production v2.4.0
  participant R as release/2.4
  participant M as main
  P->>R: incident reported
  R->>R: create hotfix/2.4.1 and fix
  R->>P: tag v2.4.1 and deploy
  R->>M: merge back or cherry-pick -x
  Note over R,M: never let the fix live only on the release branch

git switch -c hotfix/2.4.1 v2.4.0        # from the exact tag in production, not from main
git commit -m "fix(order): prevent NPE when coupon is null"
git tag -a v2.4.1 -m "hotfix 2.4.1"
git push origin hotfix/2.4.1 v2.4.1
git switch main && git cherry-pick -x <hotfix-sha>

15. Disasters and the exact recovery command

ORIG_HEAD is the point before the last merge/rebase/reset. Two more investigative tools: git log -L :calculateTotal:src/Cart.java shows how one function evolved, and git range-diff main old-feature new-feature compares two versions of the same commit series (before and after a rebase).

And a gift to your team's future: after a repo-wide reformat, git blame is broken forever unless you record that commit's hash in .git-blame-ignore-revs and set git config --global blame.ignoreRevsFile .git-blame-ignore-revs.

16. Cheat sheet

git worktree is the least known and most time-saving of these: when an urgent hotfix arrives mid-feature you need not stash — git worktree add ../project-hotfix -b hotfix/2.4.1 v2.4.0 gives a second working directory backed by the same repository. Objects are shared, so it costs almost no space and each keeps its own build cache.