Как сделать кодревью в гитхабе
Обновлено: 05.07.2024
Хотя большинство разработчиков используют командную строку при работе с системами контроля версий, существует много доступных клиентов с графическим интерфейсом, которые потенциально могут упростить процесс. Такие инструменты могут быть полезны, когда нужно увидеть, что изменилось в файле, поскольку графический интерфейс пользователя может быстро выделить и указать на происходящие изменения.
Типичный процесс использования десктопного клиента
В этом разделе мы научимся использовать десктопный клиент GitHub для управления процессом Git.
Note: Вместо работы в Wiki GitHub (как делали в предыдущем разделе по GitHub ), будем работать в обычном Git-репозитории. В Wiki GitHub есть некоторые ограничения, когда дело касается отправки запросов.
Для настройки репозитория Git используя клиента GitHub Desktop:
В списке измененных файлов зеленый знак + означает добавление нового файла. Желтый круг означает изменения существующего файла.
- В левом нижнем углу клиента GitHub Desktop (где написано Summary и Description) вводим описание коммита и кликаем Commit to master.
Если посмотреть репозиторий в сети, то увидим, что внесенные изменения были перенесены в основную ветку в источнике. Можно перейти на вкладку History в клиенте GitHub Desktop (вместо вкладки Changes) или перейти в меню View > Show History, чтобы просмотреть ранее внесенные изменения.
Note: Многие предпочитают использовать терминал вместо графического интерфейса GitHub для рабочего стола, графический интерфейс упрощает визуальное восприятие изменений, внесенных в репозиторий. При желании можно комбинировать использование командной строки и клиента рабочего стола.
Создание ветки
Теперь создадим ветку, внесем изменения и посмотрим как влияют изменения на ветку.
После создания ветки, в центре раскрывающееся меню будет указывать на ту ветку, в которой мы работаем. Создание ветки копирует существующий контент (из ветки master) в новую ветку (development).
Изменения в файле показывают удаленные строки красным и новые строки зеленым цветом. Цвета помогают увидеть, что изменилось.
- Закоммитим изменения в левом нижнем углу и кликнем на Commit to development.
- Нажимаем Publish branch (в верхней части окна GitHub Desktop), чтобы сделать локальную ветку также доступной в Origin (GitHub). (Всегда существует две версии ветки: локальная версия и удаленная версия.)
- Вернемся в основную ветку (выбираем master в раскрывающемся меню). Затем посмотрим на свой файл (в текстовом редакторе). Стоит обратить внимание, что изменения, внесенные нами во время редактирования в ветке development , не отображаются в основной ветке.
Посредством ветвления можно ограничить свои изменения конкретной версией, которая не запускается, пока не будут готовы изменения к объединению с master веткой.
Слияние (merge) ветки development с master
Теперь научимся объединять наши ветки.
- В GitHub Desktop переключитесь на ветку, в которую вы хотите объединить ветку development. В селекторе веток выберите ветку master.
- Переходим Branch > Merge into Current Branch
- В окне слияния выбираем ветку development и кликаем Merge development into master
После слияния веток изменения будут отображаться и в файле в ветке master.
- Нажимаем Push origin для отправки изменений в удаленный репозиторий.
После этого наши изменения будут отображены в репозитории на GitHub.
Слияние ветки через pull request
Теперь объединим ветку development с master, используя процесс pull request. Мы притворимся, что клонировали репозиторий разработчика, и хотим, чтобы разработчик влил наше изменение в ветку development. (Другими словами, у нас может нет прав на слияние веток в мастер.) Для этого мы создадим запрос на извлечение (pull request).
На сайте GiHub pull request выглядит так:
Pull Request
- Напишем причину запроса на извлечение и нажмем Create pull request.
- На этом этапе разработчики получат запрос по электронной почте с просьбой объединить их изменения. Попробуем себя в роли разработчика, перейдя на вкладку Pull requests (на GitHub), чтобы проверить и подтвердить запрос. Пока запрос на слияние не вызывает конфликтов, видна кнопка Merge pull request.
Чтобы увидеть, какие изменения объединяются с мастером, можете щелкнуть вкладку Files changed (которая появляется на дополнительной навигационной панели вверху). Затем кликаем Merge pull request для объединения в ветке и Confirm merge, чтобы завершить объединение.
Теперь получим обновления, которые мы слили в master ветку, в свою локальную копию. В GitHub Desktop выбираем master ветку и кликаем кнопку Fetch origin. Fetch получает последние обновления из источника, но не обновляет локальную рабочую копию с изменениями.
После нажатия кнопка Fetch origin изменится на Pull Origin.
- Нажимаем на Pull Origin чтобы обновить локальную копию с полученными изменениями.
Проверим файлы и обратим внимание, что обновления, которые изначально были в ветке development, теперь отображаются и в master.
Note: Более подробное руководство по созданию запросов извлечения с использованием интерфейса GitHub см. В разделе Процесс Pull request на GitHub. Работать с Pull Request нужно уметь, если планируется участие в опен-сорс проектах.
Управление конфликтами слияния
GitHub Desktop отображает восклицательный знак рядом с файлами с конфликтами слияния. Откройте файл конфликта и найдите маркеры конфликта ( и >>>>>>> ). Например, такие:
В командной строке можно запустить git status , чтобы увидеть, какие файлы имеют конфликты.) Содержимое в HEAD показывает локальные изменения. Содержание ниже ======= показывает изменения, внесенные в другом месте.
Устраняем все конфликты, изменив содержимое маркеров, а затем удалив маркеры. Например, обновите содержимое до этого:
Теперь нужно снова добавить файл в Git. В GitHub Desktop внесем изменения в обновленные файлы. Кликаем Push origin. Обновления на локальном компьютере отправляются на удаленный компьютер без каких-либо конфликтов.
Заключение
Чем больше использовать GitHub, тем больше опыта работы с нужными рабочими процессами. Git - это мощная платформа для совместной работы, в которой есть множество команд, рабочих процессов и функций, которые можно использовать для различных сценариев. Несмотря на разнообразие команд и рабочих процессов Git, наиболее используемые сценарии ограничены по объему и доступны для изучения без особых усилий. Довольно скоро такие рабочие процессы станут автоматическими.
Используемые в этом занятии команды в интерфейсе GitHub Desktop можно попробовать и в командной строке. Возможно, что командная строка понравится больше. Но GitHub Desktop может стать хорошей отправной точкой.
Пример: есть репозиторий X (url которого - гитхаб.ком/Хозяин_репо/ X , в нем есть ветки: A,B,C, хозяин репозитория поставил по дефолту репозиторий B, а нам надо скачать исходники с ветки A .
Делаем:
1. Заходишь, нажимаешь кнопку зеленого цвета Clone or download и копируешь адресс, в данном репо он к примеру такой
3. К примеру тебе нужно скачать папку dct по пути mediatek/dct из ссылки полученной в 1 пункте удаляешь .git в конце и дописываешь
trunk - trunk соответствует master. Можешь использовать svn ls чтобы просмотреть доступные теги и ветви перед скачиванием.
git add . - помечаем все измененные файлы для выгрузки
git commit -a название_коммита
git push - льем на гитхаб
Предложу альтернативу. :wink_kind:
Создаём новый пустой репозиторий с помощью командной строки:
USER_NAME - ваш никнейм на github.
demo - название репозитория.
Далее последует запрос на ввод пароля от вашей учётной записи github. Вводим и получаем пустой репозиторий, с которым можно работать выполняя команды ниже.
Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?
Тогда эта статья специально для вас!
На самом деле, в Git нет ничего сложного. Если вы быстро читаете и не тратите уйму времени на установку и регистрацию, то начать работать с GitHub вы сможете уже через 10 минут.
Прочитав данную статью вы научитесь клонировать существующий репозиторий, создавать ветки, вносить изменения и отправлять запросы на изменения. Параллельно освоите работу в терминале, терминальные команды и редактирование файла Markdown ( .md ).
Если вы сможете все это с делать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте — Стене на GitHub.
Если вы хотите стать настоящим профессионалом в Git и GitHub, то придется еще многому научиться. Однако информации ниже будет вполне достаточно для изучения основ.
Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. Это настоящая Мекка для технарей. Здесь вы можете попрактиковаться в разработке и придумать что-то свое, найти множество open-source проектов, передовых технологий, различных функций и дизайнов.
На GitHub вы учитесь и участвуете в других проектах, храните код для работы или учебы, берете код других проектов и вникаете во все детали. А еще вы можете создавать сайты бесплатно напрямую из репозитория! (Научиться можно здесь)
Если вы хотите работать на GitHub, то вовсе не обязательно быть гуру в программировании, ведь все самое основное делается прямо на сайте.
Не лишним будет разобраться с терминалом, поскольку терминальные команды действительно упрощают жизнь.
Если в статье вы видите команду с угловыми скобками: , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.
Пример: git add . Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py .
Для начала необходимо запомнить следующие терминальные команды:
Затем к ним добавим еще вот эти:
Эти команды вам пригодятся в случае, если вы будете работать с другими людьми или захотите внести какие-то изменения в проект и протестировать их до создания коммита.
Не лишней будет и вот такая команда:
О ней мы также поговорим ниже.
(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal ).
Зайдите на GitHub и создайте свой аккаунт. В принципе, этим можно и ограничиться. При желании можете установить Git. Но для работы с GitHub это вовсе не обязательно. Однако если вы планируете заниматься проектами на локальном компьютере, то установка вам все-таки нужна. Можете скачать установщик или установить файлы через менеджер пакетов.
Теперь перейдите в терминал, и начнем работу. Если хотите задать одно имя пользователя для всех репозиториев на компьютере, то напишите:
замените на свое имя в кавычках. Можете написать все, что угодно. Если хотите задать имя только для одного репозитория, то удалите из команды слово global .
Теперь напишите свой адрес электронной почты. Проследите, чтобы он совпадал с адресом, указанным при регистрации на GitHub.
При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.
Теперь вы готовы к работе с Git на локальном компьютере.
Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта.
Вариант 1. Я уже знаком с терминалом
Вот как начать работу с Git из терминала.
Если у вас есть директория проекта, то просто перейдите в терминал, а в самой директории проекта выполните команду
Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду
Допустим, в вашем проекте есть папка new_project . Вы можете перейти в нее из окна терминала и добавить локальный репозиторий. Это делается через следующую команду:
В вашем проекте появилась новая скрытая директория с названием .git . Именно здесь Git хранит все, что ему нужно для отслеживания проекта. Теперь вы можете последовательно добавлять файлы в область подготовки:
или добавьте сразу все файлы через:
Создать коммит с этими изменениями можно через команду:
Если изменения вас устраивают, напишите:
и отправьте эти изменения в репозиторий. Проверить, есть ли изменения для отправки, можно в любое время по команде:
При внесении изменений следует обновить и сами файлы:
Вариант 2. Я вообще ничего не знаю
Этот вариант выбирают совсем новички в разработке. Вполне возможно, у вас уже есть целая папка с файлами проекта для размещения на GitHub, но вы не знаете, с чего начать.
Ну что ж, приступим к делу!
Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.
Лучше сразу добавлять в репозиторий README-файл с информацией о проекте. Это можно сделать в момент создания репозитория, поставив галочку в соответствующем поле.
- Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
- Придумайте имя репозитория и добавьте короткое описание.
- Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
- Нажмите Initialize this repository with a README для добавления README-файла. Настоятельно рекомендую снабжать все ваши проекты файлом-описанием, ведь README — это первая вещь, на которую люди обращают внимание при просмотре репозитория. К тому же, здесь можно разместить нужную информацию для понимания или запуска проекта.
При желании можете уже сейчас начинать работать над проектом. Добавляйте файлы, вносите в них изменения и т.д. напрямую с сайта GitHub. Однако конечный результат подобной деятельности может вас немного огорчить.
Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.
Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.
Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request. Запомните ее, скоро к ней вернемся.
Как вы видите — ничего сложного!
Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.
Подайте мне вот этот проект!
Возможно, вы захотите клонировать свой новый репозиторий для дальнейшей работы с ним на локальном компьютере. Либо у вас уже есть существующий репозиторий, который вы хотели бы клонировать.
Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:
Затем клонируйте туда репозиторий по следующей команде:
Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки .
Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.
Совсем не обязательно создавать репозиторий на Рабочем столе. Клонировать можно в любое место на компьютере. Команду git clone можно выполнять и сразу после открытия терминала. Однако, если вы не очень любите копаться в папках на компьютере, то неплохо будет разместить проект на виду, то есть на Рабочем столе…
Если хотите просто покопаться в каком-то проекте, то вместо клонирования можете сделать форк проекта на GitHub. Для этого нажмите кнопку Fork в верхнем правом углу сайта. Так вы добавите копию этого проекта в свои репозитории и сможете вносить туда любые изменения без вреда для оригинала.
Вот, чем мы займемся:
Но ничего сложного здесь нет!
Должно быть, у вас уже есть файлы, которые вы бы хотели разместить в новом репозитории. Отыщите их на компьютере и перетащите в новую папку репозитория на Рабочем столе.
Проверьте статус проекта.
Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:
Если вы перетаскивали файлы в папку проекта, то потребуется обновить состояние репозитория. Добавлять файлы в репозиторий можно по одному:
Это ваши предлагаемые изменения. Операцию можно повторить с новыми файлами либо с уже существующими, но измененными. По сути, ничего нового в сам проект вы не добавляете. Вы всего лишь загружаете новые файлы и указываете Git на эти изменения.
Процесс создания коммитов с изменениями начинается с выполнения команды:
Теперь ваши изменения сохранены в указателе локальной копии проекта. Для отправки изменений на удаленный репозиторий выполните команду:
Тем самым вы отправляете изменения напрямую в репозиторий. Если вы работаете на локальном компьютере и хотите, чтобы коммиты отображались в онлайн, то необходимо своевременно отправлять эти изменения на GitHub по команде git push .
Актуальность версии можно проверить в любое время через команду git status .
Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.
После того, как вы создали несколько коммитов или же клонировали репозиторий с уже существующей историей коммитов, вероятно вам понадобится возможность посмотреть, что было сделано, – историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда git log .
Если вы запустите команду git log в каталоге клонированного проекта, вы увидите следующий вывод:
Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
Одним из самых полезных аргументов является -p или --patch , который показывает разницу (выводит патч), внесенную в каждый коммит. Так же вы можете ограничить количество записей в выводе команды; используйте параметр -2 для вывода только двух записей:
Эта опция отображает аналогичную информацию, но содержит разницу для каждой записи. Данную опцию очень удобно использовать для код-ревью или для быстрого просмотра последовательности внесенных изменений. Так же есть возможность использовать ряд опций для обобщения. Например, если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию --stat :
Как вы видите, опция --stat печатает под каждым из коммитов список и количество измененных файлов, а также сколько строк в каждом из файлов было добавлено и удалено. В конце можно увидеть суммарную таблицу изменений.
Следующей действительно полезной опцией является --pretty . Эта опция меняет формат вывода. Существует несколько встроенных вариантов отображения. Опция oneline выводит каждый коммит в одну строку, что может быть очень удобным если вы просматриваете большое количество коммитов. Опции short , full и fuller делают вывод приблизительно в том же формате, но с меньшим или большим количеством информации соответственно:
Наиболее интересной опцией является format , которая позволяет указать формат для вывода информации. Особенно это может быть полезным, когда вы хотите сгенерировать вывод для автоматического анализа – так как вы указываете формат явно, он не будет изменен даже после обновления Git:
В таблице ниже показаны наиболее полезные опции для изменения формата.
| Опция | Описание вывода |
|---|---|
| %H | Хеш коммита |
| %h | Сокращенный хеш коммита |
| %T | Хеш дерева |
| %t | Сокращенный хеш дерева |
| %P | Хеш родителей |
| %p | Сокращенный хеш родителей |
| %an | Имя автора |
| %ae | Электронная почта автора |
| %ad | Дата автора (формат даты можно задать опцией --date=option ) |
| %ar | Относительная дата автора |
| %cn | Имя коммитера |
| %ce | Электронная почта коммитера |
| %cd | Дата коммитера |
| %cr | Относительная дата коммитера |
| %s | Содержание |
Опции oneline и format являются особенно полезными с опцией --graph команды log . С этой опцией вы сможете увидеть небольшой граф в формате ASCII, который показывает текущую ветку и историю слияний:
Данный вывод будет нам очень интересен в следующей главе, где мы рассмотрим ветвление и слияние.
Мы рассмотрели только несколько простых опций для форматирования вывода команды git log – на самом деле их гораздо больше. Таблица 2, приведенная ниже, содержит описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
Ограничение вывода
В дополнение к опциям форматирования вывода, команда git log принимает несколько опций для ограничения вывода – опций, с помощью которых можно увидеть определенное подмножество коммитов. Вы уже видели одну из таких опций – это опция -2 , которая показывает только последние два коммита. В действительности вы можете использовать - , где n – это любое натуральное число, представляющее собой n последних коммитов. На практике вы не будете часто использовать эту опцию, потому что Git по умолчанию использует постраничный вывод и вы будете видеть только одну страницу за раз.
Однако, опции для ограничения вывода по времени, такие как --since и --until , очень удобны. Например, следующая команда покажет список коммитов, сделанных за последние две недели:
Примечание
Допускается указывать несколько параметров --author и --grep для поиска, которые позволят найти коммиты, соответствующие любому указанному --author и любому указанному шаблону --grep ; однако, применение опции --all-match заставит искать коммиты соответствующие всем указанным шаблонам --grep .
Следующим действительно полезным фильтром является опция -S , которая принимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки. Например, если вы хотите найти последний коммит, который добавил или удалил вызов определенной функции, вы можете запустить команду:
Последней полезной опцией, которую принимает команда git log как фильтр, является путь. Если вы укажете каталог или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире ( -- ), чтобы отделить пути от опций:
В таблице 3 вы можете увидеть эти и другие распространенные опции.
Например, если вы хотите увидеть, в каких коммитах произошли изменения в тестовых файлах в исходном коде Git в октябре 2008 года, автором которых был Junio Hamano, и которые не были коммитами слияния, вы можете запустить следующую команду:
Из почти 40 000 коммитов в истории исходного кода Git, эта команда показывает только 6, которые соответствуют этим критериям.
Подсказка
Предотвращение отображения коммитов слияния
В зависимости от используемого порядка работы, история коммитов в вашем репозитории может содержать большое количество коммитов слияния, которые сами по себе не очень информативны. Чтобы исключить их из вывода команды git log используйте опцию --no-merges .
На GitHub размещены миллионы Open Source проектов, но для начинающих разработчиков бывает достаточно сложно поначалу разобраться в принципах их работы, а также в интерфейсе сайта. Это краткое руководство поможет участвовать в проектах с открытым кодом, которые размещаются на GitHub.
Адаптированный перевод статьи The beginner's guide to contributing to a GitHub project. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.
Шаг 0: Выберите проект
На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект Хекслет Sicp.
Шаг 1: Создайте рабочую копию на своем компьютере
Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:
Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.
Результат будет выглядеть примерно так:
Перейдите в директорию нового проекта:
Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:
- origin, который указывает на ваш форк проекта на GitHub. Вы можете читать его, и писать в этот репозиторий.
- upstream, который указывает на GitHub-репозиторий основного проекта. Этот репозиторий можно только читать.
Шаг 2: Заставьте его работать на вашей машине
Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.
Если у вас все работает, но документация неясна, то улучшение этого раздела должно стать вашим первым PR в проекте. Это одновременно и самый простой и полезный способ войти в проект!
Шаг 3: Сделайте что-нибудь полезное
Теперь, когда вы выбрали проблему, воспроизведите ее на своей локальной версии проекта. Как только вы воспроизвели проблему, изучите код, чтобы понять, где она возникла. Как только вы нашли проблему в коде, можно переходить к ее устранению.
Ветвление
В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:
В первую очередь мы убеждаемся, что находимся на master-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.
Теперь вы можете заняться устранением проблемы.
Если в проекте есть тесты, запустите их, чтобы убедиться, что вы ничего не сломали. Вы также можете добавить новый тест, чтобы показать, что ваше изменение устраняет первоначальную проблему.
Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью Как правильно составлять описания коммитов и почему это важно.
Шаг 4: Создайте Pull Request
В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.
Нажмите эту кнопку!
Если вы видите выделенную надпись, как показано ниже:
Нажмите на ссылку, которая приведет вас к файлу CONTRIBUTING проекта, и прочитайте его! Он содержит ценную информацию, как работать с кодовой базой проекта, и поможет вам добиться одобрения вашего вклада.
Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.
Шаг 5: Проверка разработчиками проекта
Чтобы ваши изменения были приняты в проект, разработчики должны проанализировать вашу работу. После этого они либо запросят изменения, либо объединят ее с основной веткой (либо отклонят их).
Как участвовать в Open Source проектах Хекслета: На Хекслете есть множество Open Source проектов разной сложности — нам всегда нужна помощь разработчиков для развития этих сервисов.
Итоги
Главные этапы работы в Open Source:
- Форкни проект и склонируй его на свой компьютер.
- Установи связь с основным репозиторием проекта (upstream remote) и синхронизируй с ним локальную копию.
- Создавай локальный бранч для каждого логического блока работы.
- Внеси изменения, создавай хорошие описания коммитов и читай файл CONTRIBUTING, если он есть.
- Синхронизируй изменения со свом форком (origin remote).
- Создай Pull Request на GitHub.
- Отвечай на все замечания, полученные в ходе код-ревью.
Дополнение от переводчика
Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.
Читайте также: