GIT: Как увидеть сдвинутые/сдвинутые изменения в происхождении

Я только начал использовать Git (ранее Subversion). У меня возникают реальные проблемы с тем, чтобы я не мог увидеть нажатые или вытащенные изменения в исходном репозитории. Моя "архитектура" такова:

MAIN CODEBASE

  -->Development repository 1
  -->Development repository 2

Когда я нажимаю изменения от одного из dev-репозитов dev до MAIN CODEBASE, я не вижу изменений там.

Когда я потом вытягиваю из MAIN CODEBASE, все предыдущие изменения в этом dev-репо перезаписываются.

Мне явно не хватает одного или нескольких пунктов здесь, и я очень смущен документацией, которая, кажется, предполагает, что я знаю "очевидное". Как бы то ни было, Git кажется мне бесполезным, и мне интересно, вернуться ли в Subversion - это было, конечно, легче узнать и понять.

ОТВЕТЫ

Ответ 1

Похоже на вопрос Почему я не вижу изменений в удаленном репо после "git push" ?

Операция push всегда связана с распространением истории репозитория и обновлением ссылок, а никогда не касается рабочих файлов дерева.
В частности, если вы нажмете для обновления ветки, которая выгружена в удаленном репозитории, файлы в дереве работ не будут обновляться.

Это предосторожное дизайнерское решение.
Дерево работы удаленного репозитория может иметь локальные изменения, и вы не можете вдаваться в удаленный репозиторий, чтобы разрешать конфликты между изменениями, которые вы нажимаете, и теми, что в дереве работ

Как сказано, голое дистанционное репо здесь лучше.
Вы можете настроить не-обнаженное репо в том же месте, что и MAIN CODEBASE, чтобы увидеть изменения в этом "негладком основном реестре кодовой базы".

Примечание: с предстоящий Git 1.7, git push в ветку, которая в данный момент проверена (т.е. указана HEAD в репозиторий, который не является голым) будет отказано по умолчанию.

git pull не должен перезаписывать ничего, по крайней мере, без больших предупреждений. Вы видите какое-либо из этих предупреждающих сообщений?

Как kibitzer aptly описывает в комментарии:

bare означает репозиторий, который не содержит фактических файлов, а только метаданные (коммиты). Выталкивание в такой репозиторий безопасно, потому что между состоянием файлов на диске не возникает несоответствий и совершается в .git

Тот факт, что это удаленное репо "пусто" (оно имеет только папку .git, но без файла) не означает git clone приведет к пустым местным репо.
Он будет создавать и проверять начальную ветвь, которая разветвляется из активной активной ветки клонированного репозитория.

Таким образом, "публикационная архитектура" будет выглядеть следующим образом:

/---
| MAIN SERVER   :   [     BARE-MAIN-REPO    ] == (pull only) ==> [ MAIN-REPO ]
\---                    ^^    ||   ^^   ||
                        ||    ||   ||   ||
                       push  pull push pull
                        ||    ||   ||   ||
/---                    ||    vv   ||   ||
|DEV1 PC        :    [ DEV1 REPO ] ||   ||
\---                               ||   ||
                                   ||   ||
/---                               ||   vv
|DEV2 PC        :               [ DEV2 REPO ]
\---

Примечание. Если вы ссылаетесь на Git Глоссарий, то, что означает "происхождение", является репозиторий по умолчанию вверх.
Bare-main-Repo - это "происхождение", то есть репозиторий по умолчанию по умолчанию для dev1 и dev2, что означает, что оба репозитория wll были созданы путем клонирования Bare-main-Repo.
(Ничто не мешает вам добавить другие восходящие репозитории: dev1 может добавить dev2 в качестве другого восходящего репо, что позволяет напрямую извлекать из dev2)

Ответ 2

Когда вы нажимаете изменения на основную кодовую базу, архив git обновляется, но загрузочный рабочий каталог основной кодовой базы не является.

Я настоятельно рекомендую вам сделать основной код базы данных --bare, что предотвратит эту путаницу.

Я не знаю, в чем проблема, это переписывание предыдущих изменений, что для меня не кажется правильным - можете ли вы привести пример?

В справочнике нет инструкций для новичков, но чтобы напомнить тем, кто уже понимает, как использовать некоторую функцию, с которой они туманны. В Интернете есть много документации и howtos, в том числе руководство пользователя.

Ответ 3

Я думаю, что другие ответы используют много технологий, чтобы попытаться ответить на очень простое недоразумение о том, как работают репозитории, поэтому я постараюсь ответить более просто:

A репозиторий - это управляемая версия каталога, в котором отслеживаются каждый файл, который добавляется или изменяется каждый. Это может выглядеть не похоже на каталог, к которому вы привыкли. Например, вы не можете открыть его в проводнике Windows или введите "ls" в UNIX, чтобы увидеть его содержимое.

A git репозиторий находится внутри каталога .git в вашей обычной файловой системе. Если вы откроете его, он выглядит несколько неузнаваем. В вашем случае есть один из этих репозиториев на каждой машине разработки и на машине MAIN CODEBASE (поэтому git называется системой управления распределенной версией). Помните, что этот репозиторий отличается от фактических файлов, которые обычно появляются в том же каталоге, что и каталог .git. Поэтому, если вы нажмете на свой основной репозиторий, фактические файлы, сидящие рядом с репозиторием, не будут изменены вообще - только репозиторий. Если эти файлы вообще не существуют, у вас есть голый репозиторий, о котором говорили другие.

Для сравнения, svn репозиторий находится только в одном месте, обычно на сервере, в совершенно другом месте, из самих файлов. Как и в репозитории git, при открытии этого каталога отображаются некоторые неузнаваемые файлы. Большинство людей даже не заботятся об этом, так как, когда они проверяют файлы, они получают все содержимое на свою локальную машину.

Чтобы сделать длинный рассказ коротким, если вы хотите иметь основную машину кода, ему вообще не нужны файлы, просто репозиторий. Это справедливо как для SVN, так и для git.

Ответ 4

Я думаю, нам нужна дополнительная информация, возможно, вывешиваем некоторый вывод git status и т.д.?

Из того, что у вас здесь, я бы сказал, что ваши удаленные (исходные) репозитории не "голые". Все "центральные" хранилища должны быть голыми. Просто потому, что вы нажимаете на репозиторий, это не значит, что он должен обновить рабочую копию (что, если оно имеет изменения!?).

В других вопросах вы спрашиваете, что такое голый репозиторий.

Голый репозиторий - это просто, репозиторий без рабочей копии.