Методология Github?

Question

Я немного новичок в github и хочу попробовать его, но я немного запутался в том, как правильно это сделать.

Я хочу иметь мастер-репо,в значительной степени это копия живой версии, и я хочу иметь репозиторий для разработчиков (который будет сливаться с репо-репозиторием каждую неделю, или нет), и разработчики будут отрабатывать репо для разработки на своей «вилке», я думаю?

В значительной степени

1. Я хочу, чтобы группа разработчиков работала над «клоном» развивающей версии главного репо.
2. I 'Мне бы хотелось, чтобы «клоны» в версии для разработки можно было легко обновлять с помощью новейшего репозитория разработки.
3. Мне бы хотелось, чтобы «клоны» из репозитория разработки можно было быстро объединить с разработкой.репо, так что, например, если я редактирую файл css, а репозиторий разработки добавил кучу новых файлов, он не должен требовать часа, чтобы разобраться в конфликтах.
4. Я хочу, чтобы репозиторий разработки можно было объединитьбыстро интo Мастер репо.

Как лучше всего это сделать?В SVN я бы просто использовал целую кучу веток (вместе с 15 часами слияния), но github, похоже, сбивает с толку в отношении ветвей.

Любая помощь?

Answer 1

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

Прекрасно просто иметь один репозиторий на Github с "живой" веткой и "веткой разработки". У каждого есть разрешение подтолкнуть к репо. Разработчики работают над веткой «разработка», и кто-то назначен для управления слиянием вещей в «живой». Это прекрасное использование git первого порядка при переходе с SVN, и оно поддерживает централизованный рабочий процесс SVN, но на самом деле оно не использует Github или git.

Следующий трюк - привыкнуть к элементным веткам. Когда разработчик хочет добавить новую функцию или исправить ошибку, он делает ветку «разработки» для этой цели И ТОЛЬКО ДЛЯ ЭТОЙ ЦЕЛИ. Эту ветку можно отправить в Github, чтобы позволить другим разработчикам участвовать. Когда все будет готово, функция перейдет в «разработку». Это позволяет разработчикам совместно работать над функциями, одновременно делая небольшие и резкие коммиты. Это предотвращает запутывание множества функций и исправлений ошибок. И становится понятным, почему были внесены изменения при просмотре истории, потому что она является частью более широкой ветви функций.

Затем вы попадаете на модель Github "fork and pull" , и тогда вы действительно пользуетесь Git. Вы сохраняете репозиторий с ветвями "live" и "development" и продолжаете использовать функциональные ветви, но вместо того, чтобы иметь принудительный доступ к репозиторию, каждый разработчик делает форк своего собственного репозитория и выполняет свою работу там в ветви Feature.

Когда они готовы, они отправляют запрос на извлечение , чтобы объединить их работу. Этот запрос на извлечение информации дает возможность проанализировать, прокомментировать и, возможно, улучшить работу. Основным преимуществом запроса на удаление является то, как сам запрос становится разговором о слиянии, используя как слова, так и код. Это лучше всего иллюстрируется на примере . Первоначальный пул-запрос содержит две фиксации, которые легко просмотреть, открыв их во вкладках. Затем, когда код обсуждается и выполняется больше коммитов, все они появляются в запросе. Даже обсуждения внутри самих различий. Эти запросы на извлечение являются фантастическим способом поговорить о коде, и они являются IMO убийственной функцией Github.