Если я создаю форк проекта, размещенного на github. Разветвить все ветки? Как узнать, на какой ветке основана моя вилка? Другими словами, какая ветка будет загружена на мой компьютер?
Если я создаю форк проекта, размещенного на github. Разветвить все ветки? Как узнать, на какой ветке основана моя вилка? Другими словами, какая ветка будет загружена на мой компьютер?
Ответы:
Все ветки на GitHub будут скопированы в вилку. (Очевидно, это не включает ветки, которые никогда не были отправлены на GitHub.)
Но форк - это операция GitHub-to-GitHub; на ваш компьютер ничего не копируется. Это не совсем то же самое, что клон Git . Если вы хотите спросить «что копируется при клонировании проекта?», См. Руководство для git-clone(1)
.
Подумайте об этом так:
Репо [ситория] соответствует совместной работе команды в одном или нескольких филиалах. У всех участников есть свои копии.
Каждая вилка основного репо соответствует работе участника. Форк - это действительно конструкция Github (а не Git) для хранения клона репозитория в вашей учетной записи пользователя. Как клон, он будет содержать все ветки в основном репо на момент создания форка.
Каждая ветка в вилке и / или в основном репо может соответствовать нескольким типам вещей, в зависимости от того, как вы хотите работать. Каждая ветвь может относиться к версии проекта, но также может соответствовать различным каналам разработки, таким как исправления или экспериментальная работа.
Запрос тянуть (в экосистеме GitHub) соответствует задаче. Каждый раз, когда я хочу внести изолированную завершенную задачу в основное репо, я создаю пул-реквест, соответствующий коммитам, сделанным в этой задаче. Эти коммиты переносятся либо из моей вилки, либо из моей ветки в основное репо .
Фиксации представляет собой набор изменений в коде. Это одна из самых интересных вещей в Git. Вы не передаете файлы, вы передаете логи изменений.
Fork - это клон на стороне GitHub (он клонирует все).
Когда вы клонируете репо, вы получаете всю историю этого репо со всеми его ветвями.
Хотя теоретически вы можете изменить ветвь удаленного репо по умолчанию , клон из репозитория GitHub в основном ищет основную ветку. Это означает, что для изменения ветки «по умолчанию», которую получит клон GitHub, вам необходимо переименовать главную ветку.
Если вы создаете форк проекта с веб-сайта Github, вы получаете все ветки из вышестоящего проекта.
Если вы клонируете свою недавно созданную вилку на локальный компьютер, у вас будет origin
удаленный компьютер на вашем ПК, указывающий на основную ветку вашей вилки на Github.
upstream
вы должны сделать форк проекта , создать ветку; и они говорят вам, как это сделать.
Это очень хорошо объясняется. У вас есть центральный репозиторий на GitHub. Всякий раз, когда вы берете его клон на свой персональный компьютер для внесения некоторых изменений, этот локальный клон основного репозитория называется вилкой.
Ветка другая и включена в форк / репо. Собственно ветка - это ваша работа на разной стадии развития. Они создаются по мере необходимости для сохранения набора функций, предоставления доступа различным пользователям, демонстрации сайта клиенту и т. Д.
Я хотел бы поделиться реальным примером того, когда мы используем ветки, а когда - вилки.
В нашем магазине есть GitLab, и иногда нам приходится работать с пакетами из проекта Laravel. Обычно мы создаем ветку и отправляем изменения в ветку, которую мы тестировали в нашей локальной среде разработки виртуальных машин при работе с фактическим проектом Laravel.
Допустим, наш проект находится по адресу
https://github.com/yardpenalty/mainproject.git
Использование отделения:
Допустим, ветка называется It_doesnt_matter
Как только у нас будет наша ветка так, как мы хотим для производства, мы затем делаем последний толчок к этой ветке и создаем запрос на слияние, который затем переходит в UAT для тестирования. После того, как тест прошел QC, изменения объединяются в производство.
Слияние с It_doesnt_matter
ветви теперь толкнул на мастер - проект
в https://github.com/yardpenalty/mainproject.git
Допустим, проект пакета находится по адресу
https://github.com/yardpenalty/mypackage.git
Имейте в виду, что mainproject использует этот пакет в производстве, поэтому мы не можем вносить изменения, просто отправляя их в этот пакет (среди других причин). Допустим, веб-разработчик должен отредактировать этот пакет, чтобы внести изменения в производственную среду.
Простая ветка тоже не будет работать, потому что мы не можем увидеть наши изменения, не опубликовав пакет и т. Д.
Использование форка: Теперь, когда нам нужно проделать небольшую хитрость с нашим пакетом, чтобы создать клон производственного пакета с помощью форка. Файлы composer.json можно обновить, чтобы они указывали на вилку, которая теперь находится по пути пользователя или группы.
Итак, мы создадим вилку в https://github.com/yardpenalty/mypackage.git
и назови это https://github.com/yardpenalty/yards/mypackage.git
Теперь мы можем обновить наш файл composer.json, чтобы он указывал на этот пакет в наших "репозиториях": [массив вроде такой, и вперед!
{
"type": "github",
"url": "https://github.com/yardpenalty/yard/mypackage.git"
}
]