Designed as a peer-to-peer VCS, Git allows development work to be transferred directly and immediately from one repository to another using both a push and a pull model.
Git implements its own transfer protocol to exchange data between repositories. For efficiency (to save time and space), Git’s transfer protocol performs a small handshake, determines what commits in the source repository are missing from the target, and finally transfers a binary, compressed form of the commits. The receiving repository incorporates the new commits into its local history, augments its commit graph, and updates its branches and tags as needed.
Chapter 12 mentioned that HTTP can also be used to exchange development between repositories. HTTP is not nearly as efficient as Git’s native protocol, but it is just as capable of moving commits to and fro. Both protocols ensure that a transferred commit remains identical in both source and destination repositories.
However, the Git-native and HTTP protocols aren’t the only mechanisms for exchanging commits and keeping distributed repositories synchronized. In fact, there are times when using these protocols is infeasible. Drawing on tried-and-true methods from an earlier Unix development era, Git also supports a “patch and apply” operation, where the data exchange typically occurs via email.
Git implements three specific commands to facilitate the exchange of a patch:
git format-patch generates a patch in email form
git send-email sends a ...