Репозиторий Git, созданный без основной ветки

Я хочу создать новый общий репозиторий git для нового проекта (на виртуальной машине).

Я побежал git --bare init из /.../git/new_proj.git, но главная ветка не создана в каталоге .../git/new_proj.git/refs/heads. Я также запускал sudo chmod 777 -R в моем каталоге, но это не помогло, и все еще не создано мастер после команды init.

Edit: Я даже пытался использовать git init (без голого флага), но все же главная ветвь не была создана.

Google не очень помог в этом вопросе...

Кто-нибудь знает, в чем проблема? Что-то мне не хватает? Спасибо!

ОТВЕТЫ

Ответ 1

Это уже в комментариях к другому ответу до сих пор, но это совершенно нормально: новый репозиторий, "голый" или нет, не имеет коммитов, поэтому он также не имеет ссылок.

Он имеет HEAD, который представляет собой файл с именем HEAD в репозитории (каталог .git), содержащий ссылку на название символической ветки. Если вы cat HEAD, вы увидите ref: refs/heads/master, что означает, что новый репозиторий "на главном ветки", даже если мастер ветвления еще не существует. Опять же, это совершенно нормальное положение вещей. На данный момент вас называют "на неродившейся ветке".

Когда вы добавляете одну или несколько коммитов в этот пустой репозиторий, ветвь master может, если это голое репо, вы можете добавить это через git push, которая может не содержать ветвь master, поэтому не допускайте скажем, "делает":-), хотя обычно master действительно возникает в этой точке, с ссылкой, указывающей на новую фиксацию (или новое накопление накопления цепочки коммитов).

В любом репо (голое или нет, снова) вы можете быть "on" ветвью, которая не существует. В частности, в обычном репо вы можете сделать:

$ git checkout --orphan newbranch

который помещает вас "on" newbranch (путем записи ref: refs/heads/newbranch в HEAD) без фактического создания newbranch, тем самым делая newbranch "нерожденным ветвью". Следующая фиксация приводит к появлению newbranch, и это commit не имеет родительских коммитов (следовательно, часть --orphan): это новый корневой фиксатор. Точно так же master возникает при его первом фиксации.

Если вам нравится, вы можете посмотреть на него с точки зрения основного механизма: когда git создает новую фиксацию, шаги, используемые для обновления HEAD, выглядят следующим образом: 1

  • Прочитайте содержимое файла HEAD.
  • Является ли это символом ref, например ref: refs/heads/master? если да, переходите к шагу 4.
  • Нет (случай "отсоединенный HEAD" ): создайте фиксацию с родителем, указанную идентификатором commit в HEAD, и напишите новый SHA-1 в HEAD. Остановитесь, мы закончили.
  • Прочитайте SHA-1 упомянутой ветки (например, .git/refs/heads/master или из упакованных ссылок).
  • Если SHA-1 недоступен, потому что ветка еще не существует, создайте корневую фиксацию, иначе создайте фиксацию, чей родитель является данным SHA-1. Напишите новый SHA-1 в ответную ветвь. Остановитесь, мы закончили.

Как интересно отметить, когда refs упаковываются, "активные" (например, независимо от того, какая ветка вы разрабатываете, скажем, devel, например) завершаемся в .git/packed-refs, но быстро обновляются новыми значениями, Эти новые значения идут только в файле .git/refs/heads/devel: в файле .git/packed-refs сохраняется запись refs/heads/devel, но она устарела (и, следовательно, игнорируется). (Вы не должны зависеть от этого: внешние программы, такие как shell-скрипты, должны использовать git branch или git update-ref или git symbolic-ref, если это необходимо, для чтения и записи имен ссылок и значений SHA-1. тем не менее, полезно иметь возможность напрямую входить и редактировать ссылки. Подумайте об этом как о современном эквиваленте шестнадцатеричного редактора для дисковых секторов.:-))

1 Все это предполагает, что вы не создаете фиксацию слияния. Если вы находитесь в середине слияния, другой файл в репозитории (.git/MERGE_HEAD) предоставляет дополнительные идентификаторы родительских слияний.

Ответ 2

Bare git repos (репозиции, созданные путем выпуска git init --bare), не будет иметь к ним рабочего дерева. Что вы можете сделать, это перейти к repo /.../git/new_proj.git и добавить голый репозиторий, который вы создали как удаленный: git remote add bare_origin <link to bare repo>, а затем попытаться нажать на свои коммиты в этой bare_origin форме репо.

Кроме того, есть ли у вас какая-либо особая причина при создании голого репозитория вместо обычного?

Ответ 3

У меня такая же проблема и исправлено - прежде всего используйте команду git add после этого, используя команду commit, наконец, используйте ветвь git, чтобы показать разветвленную my git версия 1.9

git add -A
git commit -m "initialize"
git branch