docs: explain why bare repos exist and why pushing to non-bare fails

Add paragraph connecting the structural difference to the practical
consequence — bare repos accept pushes because there is no working
tree to desynchronize; non-bare repos reject pushes to protect the
checked-out files.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: braboj

chapters/02-building-blocks.md

@@ -88,6 +88,19 @@ The `.git` folder contains the same structure as a bare repository.
 The difference is that a non-bare repository also has a working tree
 next to it — the place where you do your actual work.
 
+A bare repository is designed to be a shared hub — it accepts pushes
+from other repositories. You cannot run `git add` or `git commit`
+inside it because there is no working tree to stage files from. All
+changes must arrive via `git push` from another repository.
+
+Pushing to a non-bare repository is rejected by default. The reason:
+a push updates the branch reference, but it does not touch the working
+tree. If Git allowed it, the person working in that repository would
+have files from the old commit while the branch points to the new one —
+their working tree and their branch would be out of sync, and any
+staged work could be silently lost. Bare repositories avoid this
+problem entirely because there is no working tree to desynchronize.
+
 ## 3. Object Model
 
 Every time you commit, Git takes a **snapshot** — a complete picture of