Git — одна проблемка

Question

[tac]

Я тут решил попробовать контроль версий Git. Не понимаю одну вещь — организовал центральный репозиторий и свой локальный (Уточняю. Работаю через TortoiseGit, центральный репозиторий создаю командой Git Create repository here .., локальный путем клонирования центрального Git clone. Может тут я неверно понимаю что? ). И вроде все как коммитится (делаю коммит и push на центральный), но в центральном репозитории реальных исходников не появляется. Как их там получить/влить?

P.S. (Это логика отличается от SVN, но как-то я не нашел где этому вопросу уделяется внимание при описании GIT)

Comments

[tac]

Может надо как-то настраивать центральный репозиторий для этого?

[tac]

После ряда советов. Хочу переформулировать вопрос. Действительно мне не нужно чтобы в центральный репозиторий копировались исходники каждый раз. Но вот допустим я контролирую выпуск продукта и сижу только на центральном репозитории и смотрю как работают программисты. И в один прекрасный день заказчик говорит — давай продукт. Как мне его собрать.

Действительно ли правильно делать git clone. Мне казалось — это создание локального репозитория, а для сборки продукта есть что-то другое? Или нет?

Answer 1

[Григорий]

Судя по тому, что написано вверху — центральный репозитарий у вас bare, то есть репозитарий хранящий данные о коммитах, но не хранит какую-либо версию рабочего дерева в явном виде (на самом деле хранит, но немного своеобразно, как именно читайте тут habrahabr.ru/post/143079/). Когда вы делаете push в такой репозитарий, то git раскидывает данные всех коммитов по этому репозитарию.

Кроме bare-репозитоия вы можете делать push и в обычный репозиторий. Сделайте clone в другую папку и попробуйте из своего локального сделать push туда (для этого добавьте еще один удаленный репозитарий, где адрес — папка .git в новой, только что склонированной копии), только в этом случае вы не сразу получите измененные файлы (данные о них уже есть в этой копии репозитария, но их надо оттуда «наложить» — сделать pull в этом репозитарии).

Теперь про заказчика. При разработке, несмотря на то что git — распределенная система, есть центральный репозиторий, в котором хранится большинство веток и изменений. Когда заказчик говорит «ДАЙ», человек, отвечающий за выпуск, забирает себе данные определенного коммита (на основе которого строится новая версия) и формирует инсталятор/пакет/что-то еще.

И еще про вопрос на тему «а как получить не bare». Когда нажимаете «Create new repository here» появляется окно, в котором надо убрать галочку «Create bare repository». В этом случае у вас в папке появится только скрытая папка .git. Ну и все — это будет новый репозиторий в котором можено создавать и править файлы, коммитить и прочее.

PS. Еще я понял, что вы до этого работали с Subversion. Сам я так же пришел к git. Сначала будет трудно и непонятно, но оно, на мой взгляд, того стоит.

Comments

[tac]

Спасибо, за обстоятельный ответ

[Григорий]

Всегда пожалуйста :)

Answer 2

[radarlog]

в терминах git ответ я бы сформулировал следующим образом:
в bare-репозитарии не существует working tree, на то он и bare

Comments

[tac]

А верно ли, в терминах git, что центральный репозиторий — это ВСЕГДА bare-репозитарии?

[tac]

Ну это понятно. Но все же есть такая разница "(Работаю через TortoiseGit, центральный репозиторий создаю командой Git Create repository here .., локальный путем клонирования центрального Git clone)" Так вот верно ли, что репозиторий созданный командой (в TortoiseGit) Git Create repository here… — будет bare-репозитарий?

Answer 3

[google_fan]

Вам совершенно правильно пишут — центральный репозиторий должен быть bare и вы не должны ничего с ним делать.
Если нужно что-то сбилдить — делаете клон на билд машину и там собираете.

Comments

[tac]

Спасибо за четкий ответ, я уже понял. Хотя представлял себе немного по другому. (что на центральном репозитории сидит как раз сборщик релизов — но видимо это не так)

Answer 4

[Singerofthefall]

Чтобы обновить удаленный репозиторий вам мало закоммитить, нужно еще сделать git push.
Посмотрите например здесь.

Comments

[tac]

Да делаю я это. Не в этом дело видимо.

Answer 5

[denver]

Действительно мне не нужно чтобы в центральный репозиторий копировались исходники каждый раз

При желании пушать можно и не в баре-репу. Баре от не-баре отличается наличием *локальной бранчи* master (копии origin/master в какой-то момент). Пуш в любую удаленную (remote) репу делается в её origin/master, а чтобы еще обновились ее локальные файлы («исходники» они же working copy) надо еще зайти и обновить локальную master (например git fetch && git reset --hard origin/master, при такой комманде еще отменятся все локальные правки, но вам, от «центральной репы» с которой никто никогла не пушает, это и требуется). Как сделать чтобы это обновление происходило автоматом — зависит, но вам можно и вручную (или по крону) это делать периодически.

Comments

[denver]

Ой, git fetch для центральной репы лишний, конечно.

Answer 6

[radarlog]

anarsoul, делать push не в bare-репозиторий чревато проблемами, особенно, если с ним кто-то работает напрямую.
представь ситуацию, когда ты работаешь над функцией, а твой коллега push'ит в ту же ветку в ту же функцию и удаляет строчки, на которых основываются твои текущие наработки.
третий bare-репозитарий должен быть и являться накопительным — это общепризнанная схема работы.
а в него можно навешать хуков, чтобы делать с working tree что угодно

Comments

[radarlog]

сорри, ошибся веткой — это коммент к моему предыдущему

[denver]

radarlog, не соглашусь. Если кто-то пушает в твой локальный репо, а ты в это время делаешь в нем что-то, ничего страшного — просто придется смерджиться перед пушем (используя pull) и всего делов. И ровно то же самое придется сделать если кто-то пока ты работал запушает НЕ в твою репу (центральную), но в ту куда ты хочешь делать пуш. И то что удаляют строки над которыми ты расчитываешь — все это разрешится тобой в мердже, и вообще не относится к вопросу.

[google_fan]

Вам git даже не даст сделать пуш в таком случае. Git запрещает push ветки которая в данный момент активна в репозитории — приемнике.

[denver]

anarsoul, это если коллеги не делают потом commit --amend или rebase, что не гарантируется :)

[radarlog]

мой редактор (geany) скажет, что файл изменился локально и предложит его обновить. когда разработчиков тысячи (утрирую), это парализует работу. согласен, гит позволяет работать по такой схеме (скорее, не запрещает), но я не видел ее ни в одном мануале как рекомендуемую. еще один довод в пользу bare — когда надо юзать одни хуки при коммите в «центральный» репозиторий, а другие на локальном. в любом случае, используя общепринятую схему, у тебя инфраструктура гибче.

[denver]

anarsoul, мердж после ребэйса увидит одинаковые коммиты как разные, оставит оба и покажет много конфликтов в них (хотя это даже не твои коммиты и ты их не трогал). В любом случае нехорошо менять коммиты которые ушли, а то что они «ушли» у вас можно и не догадаться.