Управление несколькими людьми, работающими над проектом с помощью GIT

32

Я очень новичок в GIT / GitHub (как новичок, начиная со вчерашнего дня). Я хотел бы знать, как лучше всего управлять несколькими людьми, работающими над одним проектом с Github. В настоящее время я управляю одним проектом с четырьмя разработчиками.

Как мне выполнить рабочий процесс и убедиться, что все синхронизировано?

(Примечание: у всех разработчиков будет один универсальный аккаунт.)
Каждый разработчик должен быть в другой ветке?
Смогу ли я работать с двумя людьми, работающими над одним файлом?

Пожалуйста выложите подробный ответ, я не стеснительный читатель. Мне нужно это хорошо понять.

git github

— badZoke
источник

7

Один аккаунт для всех разработчиков? Это может сработать, но, скорее всего, это не очень хорошая идея.

— Марстато

1

См. Nvie.com/posts/a-successful-git-branching-model

— Брэд Томас

Возможно стоит взглянуть на GitFlow и Trunk Based Development . Лично у меня был большой успех с последним

— J Lewis

29

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

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

При желании можно также создать конкретные клоны для работы с определенными функциями. Использование того же рабочего процесса с pull-запросами для внесения изменений в основной репозиторий после завершения функции.

Если под «Все разработчики будут иметь одну универсальную учетную запись» вы имеете в виду, что все разработчики будут использовать одну учетную запись GitHub и выступать в качестве одного и того же коммиттера в репо, это плохая идея. Создайте отдельные учетные записи и настройте их в качестве соавторов, если вы хотите, чтобы у всех них был доступ к коммитам.

Что касается ваших конкретных вопросов:

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

Удачи!

— Harald
источник

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

— badZoke

Счастлив, если это поможет тебе. Git и DVCS требуют некоторого привыкания, но они становятся чрезвычайно гибкими, когда вы к ним привыкнете.

— Геральд

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

— Ишвар Раджеш Пинапала

Нет, не каждый раз, просто когда вы хотите синхронизироваться. Рассматривайте свою локальную копию ветви как свою частную ветвь, а восходящую ветвь как ту, в которую вы хотите объединиться. Использование чего-то вроде git fetch upstreamследующего git merge upstream/branchдолжно привести к вашей синхронизации без переписывания локальной истории коммитов. Если это не проблема, просто git pull --rebaseпереместите ваши локальные невыдвинутые изменения в верхнюю часть ветки вверх по течению.

— Геральд

@badZoke .... что вы сделали для решения своего 3-го вопроса (2 человека, работающие над одним файлом) ...

— Moumit

25

Мы работаем с 2 разработчиками и используем этот рабочий процесс:

На Github у нас есть ветка master и ветка dev
Основная ветвь аналогична рабочей или содержит готовый к развертыванию код
Ветвь dev находится впереди master и содержит весь новый код, над которым в данный момент работает
Локально мы оба работаем над веткой dev и отправляем github, когда что-то готово
Другой разработчик извлекает любые новые изменения из ветви dev перед тем, как отправлять свой новый код.
Когда ветка dev хороша, мы объединяем ветку master
Локально у нас есть несколько тематических веток и т.д.

— Джон
источник

1

Красиво и просто, большое спасибо! Начну с этого, прежде чем перейти к сложным

— вещам

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

— wayofhefuture

+1, это действительно самый простой для начала, и прекрасно работает. То, что вы используете, называется упрощенным gitflow: marcgg.com/assets/blog/git-flow-before.jpg

— Jelle

5

Я вижу только текстовые ответы здесь, поэтому я решил опубликовать картинку с хорошим gitflow для начала. Картина описывает более тысячи слов:

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

— Элле
источник

+1, поток мерзавцев или что-то подобное, вероятно, правильный ответ на этот вопрос.

— Может быть,

0

Я работаю с 3-мя другими разработчиками, и мы немного с этим боремся. Разработчики иногда помещают коммиты в производство, которые действительно еще не готовы к прайм-тайму, потому что они включат другие коммиты в свои изменения, а затем подтолкнут в производство. Версии версий, кажется, работают нормально для нас. Итак, если версия 1.0 является текущей стабильной версией, мы создадим ветку для v1.1-development. Разработчики внесут изменения в эту ветку. Наш тестовый сервер проверяет эту ветку и извлекает изменения по мере необходимости. Когда все функции v1.1 готовы к работе и тестирование завершено, мы объединим v1.1 с master и push. С ветвями команда разработчиков A может работать на v1.1, а команда разработчиков B может работать на v1.2. Обе команды могут работать, не влияя друг на друга. Если команда A разрабатывает что-то, что B может использовать,

Мы также используем ветку исправлений, которая используется для немедленных изменений.

Вот ссылка на изображение того, как это выглядит. http://nvie.com/img/git-model@2x.png

— Greg
источник

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

— Брэд Томас