Git
Сам Git не имеет понятия о базовой ветви.Ветвь - это (в основном - люди используют слово по-разному; см. Что именно мы подразумеваем под «ветвью»? ) - просто имя, имя которого содержит идентификатор хеша коммита.Коммит, который идентифицирует имя, называется tip commit .Этот коммит почти наверняка имеет по крайней мере один родительский коммит , а родительский (ие) также находятся в ветвиРодительский коммит имеет своих родителей;эти коммиты тоже на ветке.Цепочка, которую вы получаете, начиная с кончика и работая в обратном направлении, перечисляет все коммиты, которые находятся в ветви.
Если вы переместите метку ветви - Git позволит вам переместить еепроизвольно - это изменения, которые фиксируются в ветке, не изменяя ничего внутри каких-либо коммитов.Пока сами коммиты все еще находятся в хранилище, вы можете создать столько имен веток, сколько захотите, чтобы найти их.Думайте о коммитах как о формировании серии соединений:
C--D--E <-- branch1
/
...--A--B
\
F--G--H <-- branch2
Вы можете добавлять и удалять метки где угодно, фактически не меняя ничего (кроме того, что теперь есть имя для коммита B):
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
Что делает git rebase, это копирует некоторый набор коммитов, например, чтобы поместить новые копии в более подходящее место в этом наборе коммитов.Например, предположим, что три коммита, которые в настоящее время только достижимы с branch2 - начиная справа и работая влево, находим H, затем G, затем F - должны бытьулучшается, если они появились после последнего коммита branch1.Чтобы это произошло, вы можете выполнить:
git checkout branch2
git rebase --onto branch1 branch3
, который сообщает Git: Найти коммиты, начиная с того места, где я нахожусь, branch2, но останавливаясь на branch3, где сходятся две ветви.Теперь, когда у вас есть список правильных коммитов, скопируйте их один за другим, начиная с F и затем G и заканчивая H.Перед тем, как начать копировать коммиты, проверьте коммит E.
Давайте назовем копию F, F', чтобы обозначить, насколько она похожа на F, даже если она имеетдругой хэш-идентификатор.Как только копия будет завершена, картинка будет выглядеть следующим образом:
F' <-- HEAD
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H <-- branch2
Перебазирование будет продолжено для копирования G и H, а затем в качестве последнего действия вернет имя branch2 так, чтобы он указывал на копию H:
F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
\
F--G--H [abandoned]
Поскольку git log по умолчанию не покажет любой из оставленных коммитов при запуске git log вы увидите:
F'-G'-H' <-- branch2 (HEAD)
/
C--D--E <-- branch1
/
...--A--B <-- branch3
и будет похоже на перемещенные коммиты.Они этого не сделали: их вытеснили новые более блестящие коммиты, а старые унылые по-прежнему находятся в хранилище.(Если новые блестящие оказываются сломанными, вы можете переключить свое имя branch2 обратно на оригиналы, если вы поймали их до истечения срока их действия. По умолчанию они все еще хороши в течение как минимум 30 дней.)
GitHub
Понятие GitHub базовой ветви, согласно этой странице GitHub :
родительскийветвь репозитория по умолчанию.
Понятие родительского репозитория аналогично GitHub: репозитории Git не имеют родителей.
Страница справки GitHub переходит кскажем:
Если родительский репозиторий по умолчанию не верен, вы можете изменить как родительский репозиторий, так и ветвь с помощью выпадающих списков ...
Следовательно, чтобы изменить родительский репозиторий , используйте веб-интерфейс GitHub.После того, как вы выбрали правильный родительский репозиторий, базовая ветвь станет веткой по умолчанию для этого репозитория.Чтобы изменить ветку по умолчанию для репозитория, размещенного на GitHub, используйте веб-интерфейс GitHub (как описано в на этой странице ).
Для получения дополнительной информации о совместной работе GitHub, начните с thisстраница .