Если вы разрабатывали программное обеспечение как часть команды, независимо от его размера, вы, вероятно, использовали систему управления исходным кодом (SCM), будь то Subversion , Mercurial , Bazaar , Git или другие. У каждой организации есть свои собственные рекомендации по отправке кода — от руководства по стилю, которому нужно следовать, до того, какие тесты нужно написать.
В этой статье я объясню общие принципы, которым следуют многие организации с открытым исходным кодом в отношении использования Git, начиная с общего обсуждения открытого кода.
Классический Путь
Еще несколько лет назад большинство организаций принимали участие в своих проектах с открытым исходным кодом по электронной почте. Они разместили свой центральный репозиторий на общедоступном сервере, где вы могли клонировать код. При добавлении и внесении изменений необходимо было создать патч для отправки по электронной почте. Если были внесены изменения, необходимо было сгенерировать новый патч. Этот процесс очень неуклюжий, но все еще используется многими крупными организациями.
В прошлые годы Subversion, Mercurial и Bazaar были очень популярны. Так почему же в наше время мы видим только использование Git?
Появление Git
Запуск GitHub изменил жизнь разработчиков к лучшему. Это избавило от необходимости общаться по электронной почте и сделало проверку кода очень простой. В GitHub огромный набор функций Git получил веб-интерфейс, что привело к переходу многих организаций на Git.
Как следствие, большое количество организаций с открытым исходным кодом перешли на Git с Subversion или Mercurial (хотя Mercurial по-прежнему предпочитают Facebook из-за огромного количества коммитов каждый день). Теперь, когда код размещается в облаке через GitHub, процесс внесения изменений значительно изменился.
Концепция «Форкинг»
Если вы хотите внести свой вклад в проект напрямую, вы можете внести изменения, если у вас есть права на запись в репозиторий. Однако из соображений безопасности доступ на запись предоставляется только давним участникам проекта. Как тогда вы вносите свой вклад?
GitHub представил идею разветвления для этой цели. Разветвление — это ваша собственная копия центрального хранилища, где у вас есть полный доступ на запись. Вы можете поиграть со своей вилкой, сколько захотите, не нарушая основной репозиторий.
После того, как вы исправили ошибку (которую вы можете найти в трекере ошибок проекта или, возможно, запросив через список рассылки или в IRC), вы можете отправить запрос на извлечение для слияния вашего кода в центральном хранилище. Ваша история коммитов и измененные файлы видны, с комментариями для каждой строки.
Существуют и другие облачные решения, такие как BitBucket и GitLab , но процесс остается примерно похожим на GitHub.
Git Remotes
Хотя это на самом деле не является обязательным и не влияет на ваш рабочий процесс, есть две удаленные ветви , которые обычно популярны среди разработчиков: origin и upstream. Происхождение указывает на ваш форк, а вверх по течению — на центральное хранилище. Вы извлекаете информацию из апстрима, чтобы обновлять свой код, и отправляете исправления ошибок и исправления в источник для запроса на извлечение.
Использование филиалов
Если вы работаете над новой ошибкой, начните с новой ветки . Если вы хотите поэкспериментировать, сделайте это в новой ветке. Вы никогда не должны помещать свои изменения в основную ветку; ветвь master должна использоваться только для обновления вашего форка из апстрима.
Сохраняйте значимые имена для веток. Когда вы работаете с большой кодовой базой с частыми изменениями, очень легко потерять след того, что вы делали несколькими днями ранее. Названия ветвей должны указывать цель создания такой ветки. Используйте много веток; не придерживайтесь ни одной основной ветки или ветки разработчика.
Почему вы должны использовать ветки таким образом? Представьте себе сценарий, в котором вы отправили исправление ошибки мастеру вилки и создали запрос на извлечение. Перед тем как объединить запрос на удаление, вы решаете поработать над новой ошибкой и снова нажмите кнопку master. На этом этапе ваш существующий запрос на получение обновлений будет обновлен с помощью кода нового исправления ошибки.
Вот почему ваш хозяин всегда должен быть чистым. Кроме того, вы можете создать ветку, используя другое имя, которое служит ссылкой, но основная ветка была создана для той же цели, поэтому лучше придерживаться метода, который я описал выше.
Держите ваш код обновленным
Если вы работали с организациями с открытым исходным кодом, вы знаете, что они очень строги в отношении принятия кода, особенно от новых участников. Ваш код должен быть идеальным, следуя всем рекомендациям, установленным этой организацией (которые вы обычно найдете в их документации).
Из-за необходимости совершенствования часто случается так, что участнику предлагается внести дальнейшие изменения в патч. За несколько дней до того, как эти изменения были внесены, кодовая база часто существенно менялась. В таких случаях вы должны вытащить из апстрима и объединить все ваши коммиты для патча в один (используя git squash
Инструменты Git GUI
Хотя все команды Git могут быть успешно запущены из терминала, они могут быть подавляющими и даже уродливыми для некоторых. Существуют приложения, которые помогут вам управлять репозиториями Git через графический интерфейс, упрощая визуализацию всех данных. Если ваши основы Git понятны, эти инструменты в конечном итоге ускорят вашу работу! Примером такого инструмента является Source Tree от Atlassian (по совпадению, той же компании, которая владеет BitBucket), бесплатный клиент Git и Mercurial для Windows и Mac.
Если вам нужен только GitHub, вы можете использовать GitHub для Windows , разработанный GitHub только для платформы Windows. Он имеет великолепно выглядящий пользовательский интерфейс, который делает клонирование, ветвление и синхронизацию легкими всего несколькими щелчками мыши. Недостатком является то, что сложные команды невозможны через GitHub для Windows, что означает, что вам нужно запустить терминал через программное обеспечение для их выполнения.
Изучите основы Git в интерактивном режиме
Существует бесплатное интерактивное учебное пособие от Code School , которое фокусируется на обучении Git в целом. Этот учебник отлично подходит для начинающих и учит вас выполнять команды Git прямо из вашего браузера! Если вы раньше не использовали Git, обязательно попробуйте.
Вывод
Вклады с открытым исходным кодом в основном добровольные — вам не платят за них, если вы не управляете параллельной консультационной службой или не работаете в крупной организации. Большинство способствуют этому как хобби. Как следствие, участники, работающие над проектом, часто распространяются по всему миру, что делает использование SCM абсолютно необходимым.
Разработка программного обеспечения — увлекательное, но сложное занятие. Такие инструменты, как Git, изменили командную разработку в лучшую сторону. Я надеюсь, что этот обзор помог вам понять некоторые концепции, относящиеся к Git, и то, как их можно использовать при работе с открытым исходным кодом.
Если у вас есть какие-либо советы по поводу собственного рабочего процесса Git или вашего опыта участия в крупных открытых проектах, мы будем рады услышать их в комментариях.