Процесс контроля версий репозитория Git

Я понимаю Git следующим образом:

1) Рабочее дерево ---> Файловая система, в которой вы вручную вносите изменения.
2) Промежуточная область ---> Где лежат изменения, пока они не будут приняты.
3) Репозиторий ---> Куда отправляются зафиксированные изменения (локальные или удаленные).

По сути, я действительно хочу:

1) Рабочее дерево - локальный файловый каталог на моем рабочем столе.
2) Staging area - лежать где-нибудь на сетевом сервере.
3) Репозиторий - GitHub для отслеживания моего исходного кода.

Я не уверен, запутался ли я, читая все это о Git, и действительно ли ситуация, которую я только что описал, осуществима?

По сути, я хочу, чтобы все разработчики в моей команде имели локальную копию исходного кода в виде дерева, затем могли вносить изменения на сервер в нашей сети, а затем отсюда выполнять окончательную фиксацию на GitHub.

Это верно? Или промежуточная область должна быть на каждой локальной машине?

С уважением

git

Я думаю, что здесь стоит немного изучить терминологию, используемую в git:

git рабочее дерево: файлы, над которыми вы сейчас работаете
git staging area: файлы, которые вы укажете для следующего коммита.
git репозиторий: каталог на вашем компьютере с рабочими файлами, а также .git каталог, содержащий полную историю версий и веток и т. д.

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

Что ты хочешь, это больше вопрос обработать или политика управление рабочим процессом вашей команды. Вы можете настроить это примерно так:

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

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

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

Надеюсь, это немного проясняет ситуацию.

Что ж, это может быть технически возможно, но идея плацдарма не в этом.

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

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

Он не предназначен для размещения вещей на сервере.

Для этого вы должны создать ветку (что-то вроде «staging_branch»), зафиксировать ее, а затем проверить ее на сервере каким-нибудь инструментом CI, например CruiseControl. Затем, когда все в порядке, вы можете объединить его в свою основную ветку.

Или просто зафиксируйте в своей основной ветке и исправьте, если что-то пойдет не так :-).

На самом деле я только что видел классную веб-трансляцию от автора Pro Git (Ссылка на полный текст книги). О'Рейли скоро опубликует архивное видео, следи за этим.

По сути, вы должны изучить несколько основных команд git: init,commit, checkout,push, и branch. Это удовлетворит большую часть ваших потребностей.

(Не забудьте проверить ссылку на Pro Git, это бесплатная книга на git)