-
1. Почеток
- 1.1 За верзиска контрола
- 1.2 Кратка историја на Git
- 1.3 Основи на Гит
- 1.4 Командната линија
- 1.5 Инсталирање на Git
- 1.6 First-Time Git Setup
- 1.7 Getting Help
- 1.8 Заклучок
-
2. Основите на Git
-
3. Гранење во Git
- 3.1 Гранење објаснето
- 3.2 Основно разгранување и спојување
- 3.3 Branch Management
- 3.4 Работни процеси
- 3.5 Далечински гранки
- 3.6 Ребаза
- 3.7 Заклучок
-
4. Git на Сервер
- 4.1 Протоколите
- 4.2 Добивање на Git на сервер
- 4.3 Генерирање на вашиот SSH јавен клуч
- 4.4 Поставување на серверот
- 4.5 Гит демон
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опции за домаќини на трети лица
- 4.10 Заклучок
-
5. Дистрибуиран Git
- 5.1 Дистрибуирани работни процеси
- 5.2 Придонес кон проект
- 5.3 Приватен мал тим
- 5.4 Одржување на проект
- 5.5 Заклучок
-
6. GitHub
-
7. Git Алатки
- 7.1 Revision Selection
- 7.2 Интерактивно стажирање
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Напредно спојување
- 7.9 Rerere
- 7.10 Дебагирање со Git
- 7.11 Submodules
- 7.12 Збивање
- 7.13 Заменување
- 7.14 Складирање на ингеренции
- 7.15 Заклучок
-
8. Персонализација на Git
- 8.1 Git Configuration
- 8.2 Git Атрибути
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Заклучок
-
9. Git и други системи
- 9.1 Git како Клиент
- 9.2 Мигрирање кон Git
- 9.3 Заклучок
-
10. Внатрешноста на Git
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Заклучок
-
A1. Appendix A: Git во други околини
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Заклучок
-
A2. Appendix B: Вметнување на Git во вашите апликации
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Appendix C: Git команди
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
10.3 Внатрешноста на Git - Git References
Git References
If you were interested in seeing the history of your repository reachable from commit, say, 1a410e
, you could run something like git log 1a410e
to display that history, but you would still have to remember that 1a410e
is the commit you want to use as the starting point for that history.
Instead, it would be easier if you had a file in which you could store that SHA-1 value under a simple name so you could use that simple name rather than the raw SHA-1 value.
In Git, these simple names are called “references” or “refs”; you can find the files that contain those SHA-1 values in the .git/refs
directory.
In the current project, this directory contains no files, but it does contain a simple structure:
$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/tags
$ find .git/refs -type f
To create a new reference that will help you remember where your latest commit is, you can technically do something as simple as this:
$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master
Now, you can use the head reference you just created instead of the SHA-1 value in your Git commands:
$ git log --pretty=oneline master
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
You aren’t encouraged to directly edit the reference files; instead, Git provides the safer command git update-ref
to do this if you want to update a reference:
$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
That’s basically what a branch in Git is: a simple pointer or reference to the head of a line of work. To create a branch back at the second commit, you can do this:
$ git update-ref refs/heads/test cac0ca
Your branch will contain only work from that commit down:
$ git log --pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
Now, your Git database conceptually looks something like this:
![Git directory objects with branch head references included.](png/data-model-4.png)
When you run commands like git branch <branch>
, Git basically runs that update-ref
command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create.
The HEAD
The question now is, when you run git branch <branch>
, how does Git know the SHA-1 of the last commit?
The answer is the HEAD file.
The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, we mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this:
$ cat .git/HEAD
ref: refs/heads/master
If you run git checkout test
, Git updates the file to look like this:
$ cat .git/HEAD
ref: refs/heads/test
When you run git commit
, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to.
You can also manually edit this file, but again a safer command exists to do so: git symbolic-ref
.
You can read the value of your HEAD via this command:
$ git symbolic-ref HEAD
refs/heads/master
You can also set the value of HEAD using the same command:
$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test
You can’t set a symbolic reference outside of the refs style:
$ git symbolic-ref HEAD test
fatal: Refusing to point HEAD outside of refs/
Tags
We just finished discussing Git’s three main object types (blobs, trees and commits), but there is a fourth. The tag object is very much like a commit object — it contains a tagger, a date, a message, and a pointer. The main difference is that a tag object generally points to a commit rather than a tree. It’s like a branch reference, but it never moves — it always points to the same commit but gives it a friendlier name.
As discussed in Основите на Git, there are two types of tags: annotated and lightweight. You can make a lightweight tag by running something like this:
$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
That is all a lightweight tag is — a reference that never moves.
An annotated tag is more complex, however.
If you create an annotated tag, Git creates a tag object and then writes a reference to point to it rather than directly to the commit.
You can see this by creating an annotated tag (using the -a
option):
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
Here’s the object SHA-1 value it created:
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2
Now, run git cat-file -p
on that SHA-1 value:
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
test tag
Notice that the object entry points to the commit SHA-1 value that you tagged. Also notice that it doesn’t need to point to a commit; you can tag any Git object. In the Git source code, for example, the maintainer has added their GPG public key as a blob object and then tagged it. You can view the public key by running this in a clone of the Git repository:
$ git cat-file blob junio-gpg-pub
The Linux kernel repository also has a non-commit-pointing tag object — the first tag created points to the initial tree of the import of the source code.
Remotes
The third type of reference that you’ll see is a remote reference.
If you add a remote and push to it, Git stores the value you last pushed to that remote for each branch in the refs/remotes
directory.
For instance, you can add a remote called origin
and push your master
branch to it:
$ git remote add origin git@github.com:schacon/simplegit-progit.git
$ git push origin master
Counting objects: 11, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 716 bytes, done.
Total 7 (delta 2), reused 4 (delta 1)
To git@github.com:schacon/simplegit-progit.git
a11bef0..ca82a6d master -> master
Then, you can see what the master
branch on the origin
remote was the last time you communicated with the server, by checking the refs/remotes/origin/master
file:
$ cat .git/refs/remotes/origin/master
ca82a6dff817ec66f44342007202690a93763949
Remote references differ from branches (refs/heads
references) mainly in that they’re considered read-only.
You can git checkout
to one, but Git won’t point HEAD at one, so you’ll never update it with a commit
command.
Git manages them as bookmarks to the last known state of where those branches were on those servers.