Слияние кода завершено, страница обновится автоматически
Мы делаем всё возможное, чтобы сделать работу с Git интересной, и мы будем рады вашей помощи.
Принимая участие в разработке libgit2, вы соглашаетесь выпустить свой вклад под условиями лицензии. Исключение составляют директории examples и deps, все остальные коды выпускаются под лицензией GPL v2 с исключением для связи.
Код примеров регламентируется CC0 Общей лицензией, что позволяет вам скопировать его в свои приложения.
Упакованные зависимости в директориях deps регламентируются следующими лицензиями:
Мы общаемся в канале #libgit2 на сервере libera.
Также вы можете открыть заявку, чтобы начать обсуждение любых ваших вопросов. Мы любим использовать заявки для этого, чтобы иметь легко доступный постоянный протокол беседы.
main — это основная ветка, где происходит развитие. Версии помечаются (например, v0.21.0). Критические исправления ошибок для обеспечения обратной совместимости будут выполняться на ветках обслуживания <tag>-maint.## Отчет об ошибкахСначала установите версию libgit2, в которой возникла проблема, и укажите её в своём отчёте об ошибке. Это может быть метка (например, v0.17.0), или хэш коммита (например, 01be7863). Использование команды git describe является отличным способом сообщить нам, какую версию вы используете.
Если вы не работаете против последней версии ветки main, пожалуйста, скомпилируйте и протестируйте против этой версии, чтобы избежать повторного отчёта об уже исправленной ошибке.
Очень полезно, если вы сможете воспроизвести проблему. Пожалуйста, предоставьте список шагов, немного кода и/или архивированное хранилище (если возможно). Учитывайте, что некоторые разработчики libgit2 являются сотрудниками GitHub, поэтому если ваше хранилище закрыто, найдите нас на IRC, и мы поможем вам.
Наш рабочий процесс использует типичный GitHub flow, где участники форкуют репозиторий libgit2, делают изменения в отдельной ветке и отправляют pull request (a.k.a. "PR"). Pull requests обычно должны быть направлены на ветку main.Жизнь будет проще как для вас, так и для нас, если вы будете следовать этому шаблону (то есть форк, названная ветка, отправка PR). Если вы используете основную ветку вашего форка напрямую, это может привести к путанице.Пожалуйста, включите подробное описание ваших изменений при отправке pull request; если нам придётся просматривать весь diff, чтобы понять, почему вы вносите эти изменения, вероятность получения обратной связи и включения ваших изменений снижается.
Кроме того, пожалуйста, попытайтесь документировать вашу мыслительную деятельность в сообщениях коммитов. Мы рады видеть, что каждое изменение сопровождается описанием причин его внесения. Сообщения следует писать настоящим временем и в повелительном наклонении (например, "Добавить функцию foobar", а не "Добавлено функцию foobar" или "Добавление функции foobar"). Строчки должны быть ограничены 80 символами, чтобы люди со слабыми экранами могли читать сообщения коммитов в терминале без проблем.
Чтобы сделать легче связывание коммитов с определёнными частями нашего кодового базиса, мы предпочитаем, чтобы тема каждого коммита начиналась с указания области ("scope"). Например, если вы меняете код в нашей системе слияния, начните тему с префикса "merge:". Первое слово после двоеточия должно начинаться с маленькой буквы. Максимальная длина строки для темы — 70 символов, желательно короче.Если вы начинаете работу над определенной областью, не стесняйтесь отправить pull request, который подчеркнет ваши работы в процессе (и отметьте в заголовке PR, что он еще не готов к слиянию). Эти ранние pull requests приветствуются и помогут получить больше внимания к вашей правке, позволят другим давать раннюю обратную связь на изменения и также известят других, что вы работаете над чем-то конкретным.Перед завершением pull request убедитесь, что вы выполнили следующие шаги:
changelog.md
Мы верим, что наши единичные тесты позволяют нам поддерживать высокое качество библиотеки libgit2: любые новые изменения не должны вызывать сбои в единичных тестах, а новые изменения должны включать единичные тесты, охватывающие исправление ошибок или новых функций. Для исправлений ошибок мы предпочитаем единичные тесты, которые демонстрируют сбой до внесения изменений, но проходят после ваших изменений.
Кроме новых тестов, убедитесь, что ваши изменения не вызывают других сбоев тестов. Выполнение всего набора тестов полезно перед отправкой запроса на слияние. При сборке libgit2 набор тестов также будет собран. Большинство тестов можно запустить просто запустив полученный исполняемый файл libgit2_tests. Если вы хотите запустить конкретный единичный тест, вы можете указать его имя с помощью опции -s. Например:
libgit2_tests -s status::worktree::long_filenames
Или вы можете запустить весь класс тестов. Например, чтобы запустить все тесты состояния рабочего каталога:```bash libgit2_tests -sstatus::worktree
По умолчанию выполнение тестов довольно всестороннее, но некоторые единичные тесты будут исключены по умолчанию: в частности, те, которые взаимодействуют с сетевыми серверами и тесты, манипулирующие файловой системой в сложных условиях (и могут требовать специальных привилегий для выполнения). Чтобы запустить сетевые тесты:
```bash
libgit2_tests -ionline
Кроме того, различные тесты могут быть активированы через переменные окружения, такие как те, которые создают исключительно большие репозитории или манипулируют файловой системой в необычных способах. Эти тесты могут быть опасными для выполнения на обычной машине и могут повредить вашу файловую систему. Это не рекомендуется выполнять эти тесты; вместо этого они будут выполняться на серверах непрерывной интеграции (в изолированном окружении).
libgit2 лицензируется на условиях GPL v2 с исключением связи. Любой переносимый код должен быть совместим с этими условиями.
Наиболее распространённый случай — это перенос кода из основного Git. Git является чистым проектом GPL, что означает, что для переноса кода в этот проект требуется явное согласие автора. Проверьте файл git.git-authors для авторов, которые уже дали своё согласие.Другие лицензии имеют свои требования; проверьте лицензию библиотеки, из которой вы переносите код, чтобы узнать, что вам нужно сделать. В общих чертах лицензии MIT и BSD (трехсторонняя) обычно не являются проблемой. Лицензия Apache 2.0 обычно не работает из-за несовместимости с GPL. Если ваш запрос на слияние использует код из основного Git, другого проекта или код из форума / Stack Overflow, то пожалуйста отметьте это в вашем запросе и убедитесь, что вы правильно указали авторство оригинальному автору в фрагменте кода.
Публичный API библиотеки libgit2 совместим с ANSI C (также известен как C89). Внутри libgit2 используется портабельная подмножество C99 — чтобы скомпилировать с помощью GCC, Clang, MSVC и т.д., мы ограничиваем объявления локальных переменных только вершинами блоков и избегаем комментариев типа //. Кроме того, libgit2 следует некоторым дополнительным соглашениям для названий функций и типов, форматирования кода и тестирования.
Мы стремимся поддерживать исходный код последовательным и легко читаемым. Поддержание этого требует некоторых усилий, но это было более чем оправдано. Посмотрите на файл с соглашениями.
См. наш список проектов.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )