What Is Git?
Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005 that tracks changes to files over time using a directed acyclic graph (DAG) of commit objects. Unlike centralized VCS tools, every Git repository contains the full project history locally, enabling offline work, branching, and merging without a central server. Git stores data as snapshots of the entire file tree rather than delta differences, making most operations O(1) in time complexity.
How Git Works
At its core, Git uses a content-addressable storage model. Every file, directory tree, commit, and tag is stored as an object in the .git/objects directory, identified by its SHA-1 (or SHA-256 in newer versions) hash. There are four object types: blobs (file contents), trees (directory listings), commits (snapshots with metadata and parent pointers), and tags (annotated references). Because objects are named by their content hash, identical files across different commits share storage automatically, Git never duplicates content.
Branching in Git is exceptionally lightweight because a branch is simply a 41-byte file containing a SHA-1 pointer to a commit object. When you run git branch feature-nav, Git writes one file to .git/refs/heads/feature-nav. The HEAD pointer, stored in .git/HEAD, tracks which branch is currently checked out. Merging integrates histories by finding the lowest common ancestor commit (the merge base) using a three-way merge algorithm, then creating a new merge commit with two parent pointers.
The staging area (index), stored in .git/index, is a binary file that acts as a proposed next commit. When you run git add, Git writes blob objects to the object store and updates the index. git commit then reads the index, writes a tree object representing the full directory structure, and creates a commit object pointing to that tree plus the parent commit(s). This separation of working directory, staging area, and repository gives developers fine-grained control over exactly what enters each commit.
Remotes like GitHub, GitLab, or self-hosted Gitea communicate with local repositories via the Git Transfer Protocol, either over HTTPS or SSH. git push uploads missing objects to the remote and updates remote-tracking refs like origin/main. git fetch retrieves new objects without modifying the working tree, while git pull is effectively git fetch followed by git merge (or git rebase if configured with pull.rebase=true). Pack files (.pack files under .git/objects/pack/) compress object storage using delta compression across related blobs, keeping repository sizes manageable even with long histories.
Best Practices for Git
Write atomic commits: each commit should represent exactly one logical change so that git bisect can efficiently pinpoint regressions, a commit titled 'Fix nav z-index and update README and bump version' is three commits, not one. Follow the Conventional Commits specification (e.g., feat:, fix:, chore:) to enable automated changelog generation with tools like semantic-release. Use a .gitignore tuned to your stack from the start, for front-end projects this means ignoring node_modules/, dist/, .DS_Store, and IDE folders like .vscode/, because removing tracked files from history requires git filter-repo which rewrites all downstream SHAs. Adopt a branching strategy appropriate to your team size: GitFlow suits release-based projects with develop, release/*, and hotfix/* branches, while trunk-based development with short-lived feature branches and feature flags is preferred for teams practicing continuous deployment. Always configure git config --global pull.rebase true to keep linear history and avoid noisy merge commits when syncing with upstream.
Git and Canvas Builder
Canvas Builder generates production-ready HTML files built on Bootstrap 5 with clean, properly indented semantic markup, the kind of output that produces readable git diff output where each structural change is traceable to a single line, making code reviews and git blame annotations genuinely useful. Because the HTML uses standard Bootstrap 5 utility classes and semantic elements (<section>, <nav>, <article>) rather than obfuscated or auto-generated class names, developers can commit Canvas Builder output directly into a Git repository and confidently branch, merge, and deploy without parsing machine-generated code. Teams can use Canvas Builder to scaffold a site, commit the baseline to main, then iterate on feature branches, adjusting layout grid columns, swapping components, or updating content, with every change tracked, reversible, and reviewable through standard Git tooling.
Frequently asked questions
What is the difference between git merge and git rebase and when should I use each?
git merge creates a new merge commit that preserves the exact history of both branches, including the point where they diverged, ideal for integrating long-lived branches like release into main where audit history matters. git rebase replays your branch's commits on top of the target branch, producing a linear history without merge commits, preferred for cleaning up feature branches before merging via pull request. Never rebase commits that have already been pushed to a shared remote, as rewriting those SHAs forces everyone else to reconcile diverged histories.
How do I undo a commit that has already been pushed to the remote?
git revert <commit-sha> is the safe approach for shared branches, it creates a new commit that applies the inverse diff, leaving history intact and not causing force-push conflicts for teammates. If the commit is on a personal feature branch and no one else has pulled it, git reset --hard HEAD~1 followed by git push --force-with-lease (safer than --force because it fails if someone else has pushed since you last fetched) rewrites history cleanly. Reserve git reset for unpublished local commits; use git revert for anything already on a shared remote.
How does Canvas Builder's output work with Git workflows?
Canvas Builder exports clean, single-file or multi-file HTML that uses Bootstrap 5 CDN links and semantic markup, meaning the output produces minimal, human-readable diffs, a single color change in a CSS variable or a headline edit appears as exactly one changed line rather than regenerated minified blobs. This makes pull request reviews meaningful: teammates can read the actual Bootstrap 5 class changes (col-md-6 to col-lg-4) directly in the GitHub diff view without a build step. Because Canvas Builder produces no compiled artifacts or lock files, the entire site can live in version control without a .gitignore for dist/ directories, and deployments via Netlify or GitHub Pages trigger directly from the HTML files in the repository.