Git Repository Source Control Процесс

Мое понимание Git следующее:

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

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

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

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

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

Это правильно? Или область подготовки должна быть на каждом локальном компьютере?

С уважением

Источник

3 ответа

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

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

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

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

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

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

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

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

Источник

Ну, это может быть технически возможно, но это не идея, стоящая за областью подготовки.

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

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

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

Чтобы сделать это, вы должны создать ветку (что-то вроде "staging_branch"), зафиксировать ее, а затем проверить ее на сервере с помощью некоторого инструмента CI, такого как CruiseControl. Затем, когда все хорошо, вы можете объединить его с вашей основной веткой.

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

Источник

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

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

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

Источник
Другие вопросы по тегам