Git is...complicated. This series focuses on breaking git down into commit-sized pieces.
The Server Is Optional
Git is a distributed version control system. Most of the time this isn't very relevant, because we usually work with a single, central repository, but we don't have to. Because we clone the whole repo to our computers, each copy contains everything.
Unlike centralized version control, you don't have to stop collaborating when the server goes down. You can still sync and share and merge work directly with other developers, whether there's an outage or you are working in an environment without Internet access.
Decentralized Differences
This disconnect from "traditional" centralized version control systems dating back to the 1960s can be hard to grasp, as git isn't like most of our models of servers we connect to. We download and view content from a web server, but the server remains the "source of truth". If we make a post or comment on this site, they are stored on the server, not our computer.
You might think of git repos more like operating systems. The device where you are reading this has a full copy of its operating system. It might pull updates from a server, but we each have a whole "working copy" of the OS.
It's more than that, because programs and operating systems are generally artifacts (outputs) of development, and git typically stores the source (inputs).
Going Serverless
Git supports connections using https://
and ssh://
– and its own git://
protocol – but also a local file protocol which allows you to push and pull from the file system. If your repository server is down, you can still share work with others.
# Set up a file system remote
git remote add teammate /Users/alex/work/project
# Load and merge your team's updates
git fetch teammate
git merge teammate/main
Git even supports offline transfer of updates using git-bundle, so you can bundle up changes from a common point that you know another person has in their local clone of the repo, and send them the changes. This was the original use of git. Make changes, bundle them into a patch file, and send them off to a maintainer of the project.
All you need is two laptops and a flash drive to use this flow.
# Bundle the differences between main and my feature
git bundle create updates.bundle main..feature
# Merge in a bundle
git pull path/to/updates.bundle main
Summary
Each Git clone is a complete repository with its own history. Two developers can collaborate using the local file protocol or by exchanging offline bundles. The server is convenient but not required.
Top comments (0)