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

Question

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

MAIN CODEBASE

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

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

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

Я явно упускаю один или несколько пунктов здесь, и меня очень смущает документация, которая, кажется, предполагает, что я знаю «очевидное». В нынешнем виде Git кажется мне бесполезным, и я задаюсь вопросом, стоит ли возвращаться в Subversion - его, безусловно, было легче учить и понимать.

Answer 1

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

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

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

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

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

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

---

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

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 Glossary , то, что означает «origin», является хранилищем upstream по умолчанию.
Bare-main-Repo является «источником», то есть репо по умолчанию для dev1 и dev2, то есть оба репо будут созданы путем клонирования Bare-main-Repo.
(Ничто не мешает вам добавить другие репозитории обратного потока: dev1 может добавить dev2 в качестве другого репозитория обратного потока, например, позволяя извлекать напрямую из dev2)

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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