Лучший рабочий процесс с Git и Github

Я ищу несколько советов о том, как правильно структурировать рабочий процесс для моей команды с помощью Git и GitHub.

Мы недавно конвертируем svn, и это путается, как нам лучше всего настроить наш повседневный рабочий процесс.

Вот немного фона: мне комфортно работать с командной строкой, и моя команда очень к ней знакома, но может следовать за командами использования. Мы все работаем над тем же проектом с 3 средами (разработка, постановка и производство). Мы - разработчики и дизайнеры, поэтому некоторые используют графический интерфейс Git и некоторые CLI.

Наша настройка в svn прошла примерно так:

У нас была ветка для разработки, постановки и производства.
Когда люди были уверены в коде, они фиксировали, а затем сливали его в стадию.
Сервер будет обновляться сам, а в день выпуска (еженедельно) мы будем делать diff и нажимаем изменения на производственный сервер.

Теперь я настроил эти ветки и получил процесс с запущенным сервером, но это фактический рабочий процесс, который меня сбивает с толку.

Кажется, что каждый раз, когда кто-то вносит изменения в файл, он создает новую ветвь, фиксирует, объединяет и удаляет эту ветку. Из того, что я прочитал, они смогут сделать это на определенной фиксации (используя хэш), есть ли у меня это право? Является ли это приемлемым способом работы с Git?

Приветствуются любые советы.

Ответ 1

Вы можете скопировать рабочий процесс из svn verbatim. Git может делать все, что может svn (но он может сделать больше!). Но ваш рабочий процесс можно было бы улучшить, несмотря на использование CVS.

Если вы хотите, чтобы количество наименьших ветвей (что в случае, если вы новичок в Git на самом деле упростите вещи) в описанном вами рабочем процессе, я бы предложил иметь (вместо одной ветки разработки) три для каждого разработчика: devel-john, devel-mary и т.д.:

devel-john >--\
               \
devel-mary >------> staging ---> production
               /
devel-peter >-/

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

Ответ 2

Идеи, которые следует учитывать при работе с DVCS:

: даже если у вас есть один центральный GitHub, разработчик не ограничивается публикацией (push) только для этого репо GitHub. Они могут разблокировать репо и публиковать в своей собственной версии (при получении из официального центрального репозитория GitHub - "вверх" ).
Преимущество состоит в том, что они могут переписать историю (reset, rebase --onto, rebase -i,...) столько раз, сколько они хотят, в конце концов, они сделают запрос на растяжение, позволяя интегратору управлять своими изменениями.
одна из публикаций: в своем локальном репо вы можете настроить столько веток, сколько хотите (не для каждой модификации файла, конечно, но для любой новой задачи или набора задач, которые необходимо разработать).
Но вы также можете настроить публичные ветки, которые будут нажаты ( "опубликованы" ) на ваше дистанционное репо.
См. Этот вопрос в Git рабочем процессе, а также статьи JC Hamano на удаленных ветких:
o Развлечения с удаленными ветками (1)
o Развлечения с удаленными ветками (2)
Фраза "Когда люди были уверены в том, что код, который они совершили, а затем объединили в промежуточную стадию", не должны применяться к DVCS: совершать ранние, фиксировать часто, а push ( "публиковать" ) только тогда, когда вы хотите.
/li >

Ответ 3

Существуют также некоторые рабочие процессы проекта, описанные в книге ProGit, в которых отображаются команды Git, которые разработчики будут использовать ежедневно.

Существует хорошо рассмотренная Git ветвящаяся модель, описанная в http://nvie.com/git-model

Ответ 4

Отличная публикация в рабочем процессе GitHub одним создателем GitHub Скоттом Чаконом и автором упомянутого Pro Git книга: P

Ответ 5

В зависимости от вашего рабочего процесса вы можете иметь несколько "важных" ветвей в своем центральном репозитории (т.е. на github), которые люди могут клонировать локально. Они будут соответствовать "стабильным", "бета", "разработкам" и т.д. Хорошая статья о возможном наборе ветвей this.

После этого вы можете позволить людям использовать свою собственную стратегию. Я предпочитаю сохранять темы для крупных проектов, и один из них называется "быстрыми исправлениями" для быстрых вещей, которые мне нужно сделать. Если у вас есть команда, работающая над крупным проектом, который они хотят оставить на отдельной ветке, отрезанной от основного репо, вы можете позволить им сделать это без какого-либо вмешательства. Если люди предпочитают иметь много крошечных веток, чтобы попробовать что-то и т.д., Они тоже могут это сделать.

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