Слияние кода завершено, страница обновится автоматически
Git Crash Course
Git — это распределённая система управления версиями с открытым исходным кодом, которую проект Eclipse OMR использует для отслеживания изменений кода. Git считается распределённой системой контроля версий, потому что каждый участник проекта может иметь полную копию репозитория и вносить изменения независимо. Затем участники могут запросить проверку и объединение своих изменений в основной репозиторий проекта, что позволяет крупным проектам с открытым исходным кодом, таким как Eclipse OMR, иметь множество участников.
Вам потребуется работать с git, чтобы вносить код в Eclipse OMR. Это руководство предназначено для того, чтобы помочь вам начать работу и понять рабочий процесс проекта с использованием git и GitHub, проведя вас через процесс внесения вашего первого вклада в проект Eclipse OMR, размещённый на GitHub. Оно ни в коем случае не является полным руководством по всему, что вы можете делать с git — для этого существует множество отличных онлайн-ресурсов.
Настройка git и GitHub
В этом руководстве основное внимание уделяется использованию git в командной строке. Вы можете использовать приложение git GUI дополнительно/вместо него, если захотите.
Linux
Чтобы установить git в дистрибутиве Linux на основе RPM (например, RHEL), выполните следующие команды оболочки:
1. yum update
2. yum install git
Если вы используете дистрибутив на базе Debian (например, Ubuntu):
1. apt-get update
2. apt-get install git
Примечание: в зависимости от ваших пользовательских настроек вам может потребоваться добавить к командам выше префикс sudo.
macOS Запустите Terminal.app и установите инструменты командной строки, выполнив следующую команду:
```
xcode-select --install
```
Эта команда установит git, а также ряд других инструментов разработки для командной строки, таких как make, clang, svn и т. д.
Windows 10 Существует много способов установки и использования git в Windows, но самый простой способ — загрузить установщик со страницы загрузки git-scm и следовать мастеру установки.
Настройте git Настройка идентификатора автора коммита После установки вы должны настроить своё имя и адрес электронной почты для связи с любыми коммитами, которые вы делаете, используя следующие команды:
```
git config --global user.name "Ваше Имя"
git config --global user.email "your.email@yourdomain.com"
```
Аргумент --global, использованный выше, указывает git настроить user.name/email глобально и связать их с любыми вашими коммитами. Если вы хотите переопределить имя или адрес электронной почты в конкретном проекте, просто перейдите в каталог проекта и введите любую из вышеуказанных команд с именем/адресом электронной почты проекта для использования и исключите аргумент --global.
Обратите внимание, что адрес электронной почты... Гит не знает, является ли клонированный репозиторий форком.
Чтобы быть в курсе обновлений, сделанных в eclipse/omr, вам нужно отслеживать изменения в этом репозитории и называть его upstream. Заметьте, что от upstream к origin нет стрелки, а это значит, что поддерживать актуальность вашего форка — ваша ответственность. Для этого выполните fetch из upstream в локальный репозиторий, обновите локальные ветки, а затем выполните push в свой форк origin.
В следующих разделах мы рассмотрим различные этапы этого процесса разработки.
Проблемы на GitHub — отличный способ для участников проекта сотрудничать. Проект Eclipse OMR использует Issues в основном для отслеживания задач, ошибок и открытых обсуждений.
Проблемы можно классифицировать с помощью цветных меток (например, compiler, good first issue, backlog, help wanted). Если вы впервые вносите свой вклад в Eclipse OMR, рекомендуется заняться проблемой с меткой good first issue, прежде чем браться за более сложные задачи. Выбрав метку good first issue в раскрывающемся меню Labels, вы увидите проблемы с этой меткой.
После выбора проблемы, над которой вы будете работать, вам нужно создать форк, чтобы открыть запрос на вытягивание (Pull Request), который будет рассмотрен и объединён. Чтобы создать форк, просто нажмите Fork в верхней части страницы репозитория OMR на GitHub.
Теперь, когда вы создали форк, у вас тоже есть копия репозитория OMR в вашем аккаунте GitHub, как и у других участников!
Рисунок 3: Создан новый форк.
Следующий шаг — клонировать ваш форкнутый репозиторий OMR, чтобы внести изменения локально. Перейдите в каталог, в который вы хотите клонировать репозиторий, и введите следующую команду:
git clone git@github.com:yourgithub/omr.git <каталог-для-клонирования> <-b ветка-для-проверки>
Приведённая выше команда клонирует репозиторий omr на вашу машину с использованием SSH. Части внутри угловых скобок необязательны. Без этих опций ваш репозиторий будет клонирован в каталог с именем omr, а по умолчанию будет использоваться ветка master.
Перейдите в каталог, куда был клонирован репозиторий. Чтобы проверить состояние репозитория, введите команду git status, которая должна вывести:
On branch master
nothing to commit, working tree clean
Это указывает на то, что вы сейчас находитесь в основной ветке, и в этой ветке не было сделано изменений, которые вы могли бы зафиксировать.
Рисунок 4: Основная ветка.
Разветвление позволяет разделить цепочку коммитов, сделанных в репозитории. Имя ветки используется для идентификации разных веток в репозитории. Основную ветку не следует использовать для внесения изменений. Вместо этого используйте её для создания новых веток.
Для создания новой ветки введите следующую команду:
git branch new-branch
Рисунок 5: Создание новой ветки.
У вас теперь есть новая ветка с именем new-branch, и поскольку вы создали новую ветку из вашей текущей ветки (master), обе ветки будут указывать на один и тот же коммит.
На данный момент вы просто создали новую ветку, но всё ещё находитесь в ветке master. Чтобы переключиться на новую ветку, введите следующую команду:
git checkout new-branch
Чтобы выполнить две команды выше за один шаг, введите:
git checkout -b new-branch
Добавление новых коммитов в ваши ветки оставит master нетронутым. Используя ветки, вы можете создавать несколько независимых цепочек коммитов, как показано на диаграмме ниже с дополнительной веткой another-branch:
Рисунок 6: Несколько веток с их независимыми цепочками коммитов.
Чтобы увидеть текущие ветки в вашем локальном репозитории, просто введите git branch, и он покажет ваши локальные ветки и выделит ветку, над которой вы работаете.
Теперь у вас есть новая ветка для работы, вы можете... Внесите свои изменения.
После того как вы это сделаете, вам нужно будет подготовить файлы и зафиксировать их после подготовки.
Подготовка файлов похожа на «сохранение» их для включения в фиксацию. Чтобы подготовить файл, введите следующую команду:
git add <имя файла>
Вы также можете подготовить все изменённые файлы за один шаг. Опция, следующая за add, определяет, что будет подготовлено:
git add -u — подготовка только всех изменений существующих файлов;git add . — подготовка всех изменений существующих файлов и любых добавленных новых файлов;git add -A — подготовка всего, включая удаление файлов.После подготовки вы можете выполнить фиксацию, и откроется текстовый редактор, где вам нужно написать сообщение фиксации. Введите команду ниже, чтобы выполнить фиксацию:
git commit
Ваше сообщение фиксации должно быть написано в соответствии с рекомендациями по фиксации Eclipse OMR, которые можно найти в документе CONTRIBUTING.md в репозитории. Вот пример сообщения фиксации, соответствующего рекомендациям проекта OMR, взятый из этого раздела CONTRIBUTING.md:
Update and expand the commit guidelines
Elaborate on the style guidelines for commit messages. These new
style guidelines reflect the conversation found in #124.
The guidelines are changed to:
- Provide guidance on how to write a good first line.
- Elaborate on formatting requirements.
- Relax the advice on using issues for nontrivial commits.
- Move issue references from the first line to the message footer.
- Encourage contributors to put more information into the commit
message.
Issue: #124
Первая строка в сообщении фиксации — заголовок фиксации, который должен обобщать то, что делает эта фиксация. После пустой строки идёт тело сообщения фиксации, содержащее более подробную информацию о том, о чём эта фиксация. Вы можете описать изменения так подробно, как пожелаете.
Затем вы можете включить проблему в OMR, которую решает эта фиксация.
Советы: git commit -a объединяет две команды:
git add -u;git commit.После фиксации вы можете отправить свою ветку new-branch в свой форк на GitHub, создав новую ветку с таким же именем в вашем форке. Для этого введите следующую команду:
git push origin new-branch
В команде выше origin — это псевдоним URL вашего форка. По умолчанию git устанавливает origin как «удалённый» репозиторий, из которого вы клонировали.
Перейдите на страницу своего форка на GitHub и выберите свою недавно отправленную ветку из раскрывающегося меню в левом верхнем углу. Затем нажмите кнопку New Pull Request рядом с ним, чтобы перейти на страницу создания запроса на вытягивание.
На странице создания запроса на вытягивание вы можете увидеть, в какую ветку eclipse/omr вы собираетесь объединить фиксацию (или фиксации) в вашей ветке. Заголовок вашего запроса на вытягивание должен описывать, что делается, а тело запроса на вытягивание можно использовать для добавления дополнительных сведений о том, что вы делаете, а также для объяснения значимости вашего вклада.
Если вы не готовы к тому, чтобы ваш запрос на вытягивание был рассмотрен и объединён, но хотели бы получить обратную связь, пока продолжаете добавлять больше фиксаций, просто добавьте префикс WIP (то есть Work In Progress) к заголовку вашего запроса на вытягивание или откройте запрос на вытягивание как черновик запроса на вытягивание. Это покажет, что вы не готовы объединить эти изменения.
Предположим, вы открыли PR с префиксом WIP, потому что хотели протестировать свои изменения, пока ваш код может получить некоторую обратную связь. GitHub позволяет вам обновить свой PR, отправив обновлённую ветку на GitHub.
Если вы хотите добавить больше фиксаций, связанных с проблемой, над которой работаете, ещё не поздно это сделать. Следуя шагам по созданию фиксации выше, вы можете отправить свои изменения в ту же ветку своего форка, и вы увидите, что запрос на вытягивание обновился с новой фиксацией, которую вы добавили. Исправление ошибок в коде и сообщении коммита после пуша
Если вы заметили опечатку в части кода, который вы зафиксировали, а также в сообщении коммита, то можно легко изменить последний сделанный коммит. Вот шаги для изменения изменений последнего коммита и сообщения:
Эта команда откроет текстовый редактор, который позволит вам отредактировать сообщение коммита. Если вам не нужно изменять сообщение коммита, вы можете использовать команду git commit -a --amend --no-edit вместо этого.
Следующий шаг после внесения изменений — обновить вашу ветку, чтобы отразить ваш запрос на вытягивание. К сожалению, вы не сможете отправить свои изменения так же, как раньше, поскольку ваш коммит теперь отличается от того, что находится в вашей удалённой ветке из-за внесённых вами изменений, что приводит к расхождению между вашей локальной и удалённой ветками. Поэтому вам придётся перезаписать свою удалённую ветку своей локальной веткой. Для этого вам нужно выполнить принудительный пуш в вашу новую ветку:
git push -f origin new-branch
Перебазирование и разрешение конфликтов слияния
Если прошло некоторое время между тем, когда вы открыли свой запрос на вытягивание, и тем, когда он был готов к рассмотрению, рекомендуется обновить свою ветку, чтобы вы могли протестировать изменения кода, сделанные на основе более свежей версии OMR. Процесс выполнения этого называется перебазированием. Чтобы объяснить перебазирование, давайте посмотрим, как вы начали разработку в своей новой ветке. Вы создали новую ветку, основываясь на ветке master, которую вы получили, когда впервые клонировали свой форк. Предположим, вы добавили коммиты b1 и b2 в новую ветку. Это будет выглядеть примерно так:
Рисунок 7: Коммиты, добавленные в вашу новую ветку.
Учитывая количество участников проекта Eclipse OMR, вполне вероятно, что в eclipse/omr было добавлено больше коммитов, в результате чего ваша базовая (локальная мастер-ветка, от которой вы создали новую ветку) ветка расходится с основной веткой eclipse/omr, в которую вы пытаетесь объединить свои изменения.
Рисунок 8: Устарелая база.
Цель перебазирования — применить ваши коммиты поверх текущей версии ветки, в которую вы пытаетесь внести изменения (в данном случае, мастер-ветки eclipse/omr).
Рисунок 9: Получившаяся цепочка коммитов после перебазирования.
Перебазирование также полезно при попытке разрешить конфликты слияния. Конфликты слияния возникают, когда другие разработчики получают свои коммиты объединёнными в мастер в eclipse/omr после точки, на которой основана ваша ветка, если ваши коммиты изменяют/удаляют строки, затронутые их коммитами. Git не может автоматически определить, что сохранить, а что удалить. Вам придётся вручную вносить изменения в эти конфликтующие области в исходных файлах.
Предположим, у вас есть конфликт слияния, который необходимо разрешить. Первым шагом будет добавление репозитория eclipse/omr в качестве удалённого для получения обновлений. Давайте обозначим URL-адрес eclipse/omr как upstream.
git remote add upstream https://github.com/eclipse/omr
Затем получите историю из upstream. Выполнение выборки удалённого репозитория обновляет то, что git знает о его истории.
git fetch upstream
Далее вам нужно перебазировать свои изменения поверх основной ветки upstream.
git rebase -i upstream/master
Опция -i в команде выше — это опция для входа в интерактивное перебазирование. Она открывает ваш текстовый редактор со списком коммитов, добавляемых из вашей ветки (строки, начинающиеся с pick) поверх основной ветки upstream. Есть много других вещей, которые вы можете сделать в интерактивном перебазировании (например, переформулировать, сжать, изменить порядок коммитов и т. д.), но в этом случае никаких изменений в операциях перебазирования не требуется. Сохранение и закрытие редактора заставит git применить коммиты в том порядке, в котором они были, пока вы не столкнётесь с первым конфликтом слияния.
Git сообщит вам о файлах, где есть неразрешённые конфликты. Откройте конфликтующий файл и найдите <<<<<<<. Это отмечает начало конфликтующей области. Конфликтующий регион выглядит так:
<<<<<<
// существующий код в upstream/master
=======
// ваши изменения
>>>>>>
======= используется для отделения ваших изменений от существующих.
>>>>>>> отмечает конец конфликтующего региона. Вручную отредактируйте конфликтующий регион и удалите 3 строки, указывающие на конфликт.
После того как вы разрешите эти конфликты, подготовьте изменённые файлы с помощью команды git add.
Теперь, когда ваши файлы не содержат конфликтов и подготовлены, операцию перебазирования можно продолжить с помощью следующей команды:
git rebase --continue
Повторите шаги по разрешению конфликтов, если возникнет ещё один конфликт.
Перебазирование отделяет вашу локальную new-branch от new-branch вашего форка, поскольку они больше не основаны на одной и той же истории коммитов. Поэтому вам нужно будет перезаписать удалённый филиал своим локальным филиалом с помощью следующей команды:
git push -f origin new-branch
Как только ваш PR будет готов к проверке, коммиттер просмотрит ваши изменения, оставив комментарии с просьбой о разъяснениях и/или запросив изменения. Затем вам придётся ответить на эти комментарии и обновить свою ветку, если это необходимо.
После того, как вы ответите на комментарии рецензента и решите все проблемы, ваш PR может быть одобрен и объединён коммиттером.
В этом разделе содержатся ссылки на некоторые полезные документы/учебники по git, которые вы можете использовать, если пытаетесь сделать что-то, не описанное здесь.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )