Information Technology Reference
In-Depth Information
ies easy. Everyone who wants to synchronize his or her work with mine needs a copy
of this commit. When I push, the remote end will receive the following object:
6c69fa3372f7099836176c8d0f123895adea58f1 Unique commit by
gajdaw
It will be an exact copy of my revision, with an identical SHA-1 name.
We can say the same fact in yet another way. Every time you analyze a history in
any of your repositories, look for this:
6c69-
fa3372f7099836176c8d0f123895adea58f1
name. Once you find it you can
always say:
Oh, I have in my repository the revision committed by Włodzimierz Gajda
on September 6th, 2013, for the sake of “Summary” in chapter 10 of his book
. There is
no other revision with the same name.
Once you understand how to add and remove remotes and how revisions are copied,
the next step to master group work concerns branches. Until now, we concentrated on
ordinary local branches. These are your personal local branches that you use for your
work. Nobody knows about them. You don't have to consult on your work in these
branches with anyone. You can create, modify, and destroy them.
The same rule applies to all repositories—not only yours. Thus we need the rules
that allow for both independence and collaboration. These rules are very simple: your
local branches are stored in other repositories inside a separate directory named after
the remote's name.
When in loose format, your ordinary local branches
a
and
b
are stored in:
.git/refs/heads/a
.git/refs/heads/b
If someone aliases your repository as
foo
with:
$ git remote add foo [URL]
and fetches from your repository with
$ git fetch foo
, then your local branches
a
and
b
will be stored in his or her repository in:
.git/refs/remotes/foo/a
.git/refs/remotes/foo/b
