Я очень новичок в GIT / GitHub (как новичок, начиная со вчерашнего дня). Я хотел бы знать, как лучше всего управлять несколькими людьми, работающими над одним проектом с Github. В настоящее время я управляю одним проектом с четырьмя разработчиками.
Как мне выполнить рабочий процесс и убедиться, что все синхронизировано?
(Примечание: у всех разработчиков будет один универсальный аккаунт.)
Каждый разработчик должен быть в другой ветке?
Смогу ли я работать с двумя людьми, работающими над одним файлом?
Пожалуйста выложите подробный ответ, я не стеснительный читатель. Мне нужно это хорошо понять.
Ответы:
Если все разработчики имеют доступ к репо, вам не нужно делать ничего особенного. Они извлекают изменения из репо, вносят свои собственные изменения, фиксируют локально, а затем возвращают в публичное репо, когда у них что-то работает.
Если, с другой стороны, у вас есть один (или несколько) разработчик (и), отвечающий за фиксацию репо, а другие предоставляют исправления для них. Пусть каждый из них клонирует репо в свои собственные учетные записи, и пусть они отправляют пул-запросы, когда у них есть изменения, которые они хотят внести в основное репо.
При желании можно также создать конкретные клоны для работы с определенными функциями. Использование того же рабочего процесса с pull-запросами для внесения изменений в основной репозиторий после завершения функции.
Если под «Все разработчики будут иметь одну универсальную учетную запись» вы имеете в виду, что все разработчики будут использовать одну учетную запись GitHub и выступать в качестве одного и того же коммиттера в репо, это плохая идея. Создайте отдельные учетные записи и настройте их в качестве соавторов, если вы хотите, чтобы у всех них был доступ к коммитам.
Что касается ваших конкретных вопросов:
Нет, используйте ветки для функций, исправлений и т. Д., Которые потребуют более одного коммита. В одной ветке может работать более одного разработчика.
Да, git действительно хорошо обрабатывает конфликты, поэтому нет проблем с тем, чтобы люди работали над одним файлом. Никаких проблем, за исключением того, что разрешение конфликтов не всегда может быть тривиальным, если есть фундаментальные изменения в файле, который был отредактирован несколькими участниками. Это, однако, ничто, что не может быть преодолено, разговаривая вместе. Контроль версий не заменяет связь.
Удачи!
источник
git fetch upstreamследующегоgit merge upstream/branchдолжно привести к вашей синхронизации без переписывания локальной истории коммитов. Если это не проблема, простоgit pull --rebaseпереместите ваши локальные невыдвинутые изменения в верхнюю часть ветки вверх по течению.Мы работаем с 2 разработчиками и используем этот рабочий процесс:
источник
Я вижу только текстовые ответы здесь, поэтому я решил опубликовать картинку с хорошим gitflow для начала. Картина описывает более тысячи слов:
источник
Я работаю с 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
источник