Check: Git

Git is a distributed version control system (distributed VCS). Every clone holds the whole history, so you can commit, view the log and switch branches without a network connection. From Git's point of view, the server (origin) is just another clone the team agreed to sync with. In SVN, the history lives on a central server, and a participant only has a working copy.

Let's make a "server," clone it and delete it. The history in the clone stays intact:

(
cd "$(mktemp -d)"
git init -q -b main server && cd server
git config user.name demo && git config user.email demo@example.com
echo v1 > app.txt && git add app.txt && git commit -qm "first version"
echo v2 > app.txt && git commit -qam "second version"
cd .. && git clone -q server laptop && rm -rf server
git -C laptop log --oneline
)

30e410b second version
c55b38a first version

git add moves the file's current state from the working directory into the index. That's a draft of the next commit. A commit only happens after git commit, and changes only reach the remote after git push.

(
cd "$(mktemp -d)"
git init -q -b main && git config user.name demo && git config user.email demo@example.com
echo hello > file.txt
git add file.txt
git status --short
git log
)

A  file.txt
fatal: your current branch 'main' does not have any commits yet

The letter A in the first column means "added to the index." There are no commits yet.

A branch stores only the SHA of its latest commit. In a plain repository that's a 41-byte file at .git/refs/heads/<name>: 40 characters of SHA and a newline. Git sometimes packs refs into a shared file, .git/packed-refs, but the idea is the same. That's why creating or deleting a branch is instant, no matter how large the history is.

(
cd "$(mktemp -d)"
git init -q -b main && git config user.name demo && git config user.email demo@example.com
echo a > a.txt && git add a.txt && git commit -qm "first commit"
git branch feature
cat .git/refs/heads/feature
git rev-parse HEAD
wc -c < .git/refs/heads/feature
)

164d13e29995b1bfb83a0120dcffac5f7d3283f6
164d13e29995b1bfb83a0120dcffac5f7d3283f6
      41

The branch file's contents match the SHA of the current commit. Since Git 2.45 there's a second ref storage format, reftable (git init --ref-format=reftable). It has no refs/heads folder with files, but a branch is still a pointer to a commit.

Merge creates a new merge commit with two parents, and leaves the old commits alone. Rebase lifts your commits off and reapplies them on top of the new base. Each such commit has a different parent, so it has a different SHA: these are new objects. Both operations can be undone, for example with git reflog.

(
cd "$(mktemp -d)"
git init -q -b main && git config user.name demo && git config user.email demo@example.com
echo a > a.txt && git add a.txt && git commit -qm "base"
git switch -qc feature && echo f > f.txt && git add f.txt && git commit -qm "feature"
git switch -q main && echo m > m.txt && git add m.txt && git commit -qm "fix in main"
git switch -q feature
git log --oneline -1
git rebase -q main
git log --oneline -1
)

e771220 feature
5332f4d feature

Same message, different SHA: after the rebase it's a different commit.

Technically, Git doesn't forbid rebase. The problem is that rebase (and commit --amend) creates commits with new SHAs, while your teammates still have the old ones in their clones. A plain git push won't accept that history, because it doesn't build on what's in origin. The only way to force it through is --force, and then your teammates end up with two diverging versions of the same commits. You can still rewrite your own branch, as long as nobody has pulled it yet.

Anya publishes a commit, then rewrites it with --amend and tries to push again:

(
cd "$(mktemp -d)"
git init -q --bare -b main origin.git
git clone -q origin.git anya 2>/dev/null
cd anya && git config user.name anya && git config user.email anya@example.com
echo a > a.txt && git add a.txt && git commit -qm "base" && git push -q origin main
echo b > b.txt && git add b.txt && git commit -qm "Anya's feature" && git push -q origin main
git commit -q --amend -m "Anya's feature, rewritten"
git push origin main
)

To /var/folders/.../origin.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '/var/folders/.../origin.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
...

The --amend itself went through without a hitch. Only the push failed, and the only way to force it through is --force on a shared branch.

Git doesn't read the file to figure out whether a conflict is resolved. It waits for you to mark the file with git add. After that, you can continue the operation: git commit or git merge --continue for a merge, git rebase --continue for a rebase. git merge --abort undoes everything, and you'll have to resolve it all over again.

Here the conflict is already resolved in the file, but the commit fails without git add:

(
cd "$(mktemp -d)"
git init -q -b main && git config user.name demo && git config user.email demo@example.com
echo "port = 8080" > app.conf && git add app.conf && git commit -qm "base"
git switch -qc feature && echo "port = 9090" > app.conf && git commit -qam "port 9090"
git switch -q main && echo "port = 8081" > app.conf && git commit -qam "port 8081"
git merge feature
echo "port = 9090" > app.conf
git commit -qm "merge"
git add app.conf
git commit -q --no-edit && git log --oneline -1
)

Auto-merging app.conf
CONFLICT (content): Merge conflict in app.conf
Automatic merge failed; fix conflicts and then commit the result.
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
U	app.conf
2a4df95 Merge branch 'feature'

The first git commit failed, even though the file was already fixed. After git add, the same commit went through.