Jak mogę utworzyć repozytorium Git z domyślną nazwą gałęzi inną niż „główna”?

W książce Pro Git jest napisane

„Pochodzenie” nie jest czymś wyjątkowym

Podobnie jak nazwa gałęzi „master” nie ma żadnego specjalnego znaczenia w Git, podobnie jak „origin”. Podczas gdy „master” jest domyślną nazwą gałęzi startowej, gdy uruchamiasz git init, co jest jedynym powodem, dla którego jest powszechnie używany , „origin” jest domyślną nazwą dla pilota po uruchomieniu git clone. Jeśli zamiast tego uruchomisz git clone -o booyah, będziesz mieć booyah / master jako domyślną gałąź zdalną.

Oznacza to, że możemy użyć domyślnej nazwy gałęzi jako gałąź główna lub gałąź główna lub coś w tym rodzaju. Nie widziałem żadnej opcji, man git-initktóra zainicjuje mój repoz inną domyślną nazwą gałęzi.

GitHub pokazuje, jak ustawić domyślną nazwę gałęzi na stronie ustawień. Ale nie mówię o tym, jak ustawić to w żadnej konkretnej witrynie hostingowej Git . Dokładnie pytam tylko o Git, a nie o jakąś konkretną witrynę hostingową Git .

Czy jest na to sposób?

Nowszy Git, nowe repozytorium

Od wersji 2.28.0 gita git initpolecenie przyjmuje teraz --initial-branch(lub -bw skrócie) parametr. Te dwie komendy tworzą nowe repozytorium Git z gałęzią o nazwie „trunk”, która zawsze miała dla mnie więcej sensu niż „master” (master?):

git init --initial-branch=trunk
git init -b trunk

Można to skonfigurować za pomocą init.defaultBranchustawienia. Jeśli chcę, aby wszystkie nowe repozytoria miały domyślną gałąź „trunk”:

git config --global init.defaultBranch trunk

Starszy Git, nowe repozytorium

Niektóre systemy nadal mają starsze instalacje Git. Mój serwer Debian 10 (Buster, aktualna stabilna wersja z października 2020 r.) Zawiera Git 2.20, który nie obsługuje tej -bopcji. Jedną z opcji jest utworzenie repozytorium, a następnie zmiana nazwy gałęzi. Ta technika działa w przypadku zwykłych (nie nagich) repozytoriów:

git init
git checkout -b trunk

Spowoduje to utworzenie nowego repozytorium z trunkbieżącą gałęzią zamiast master. Gałąź mastertak naprawdę nie istnieje - gałęzie nie są tworzone, dopóki nie będą miały co najmniej jednego zatwierdzenia. Dopóki gałąź nie zostanie utworzona, gałąź istnieje tylko w .git/HEAD, co wyjaśnia, dlaczego mastergałąź zniknie po przełączeniu się na trunk.

Nagie repozytoria

W przypadku gołych repozytoriów nie można uruchomić git checkout(to znaczy być gołym). Zamiast tego możesz zmienić HEAD, aby wskazywał inną gałąź:

git init --bare
git symbolic-ref HEAD refs/heads/trunk

Stare repozytoria

Jeśli już się zdecydowałeś, możesz git branch -mzamiast tego uruchomić :

git init
touch file.txt
git add file.txt
git commit -m 'commit 1'
git branch -m trunk

Spowoduje to zmianę nazwy gałęzi z masterna trunkpo jej utworzeniu.

Wydaje się to trochę niezgrabne, ponieważ mechanizm różni się w zależności od tego, czy repozytorium jest puste, ale działa. Możesz również potraktować to jako „tworzenie nowej gałęzi i usuwanie master”.

Możesz pośrednio skonfigurować git initużycie innej gałęzi domyślnej: bieżąca gałąź jest definiowana przezHEAD , która jest „tylko” plikiem tekstowym informującym Git, który ref jest bieżący.

Używając init.templateDir, możesz poprosić git inito użycie innego:

# ~/.config/git/config or ~/.gitconfig
[init]
    templateDir = ~/.config/git/template/

aw ~/.config/git/template/HEADśrodku wstaw pojedynczą linię (+ podział wiersza): ref: refs/heads/main(domyślnie to branchmain ).

Cała zawartość templateDirjest kopiowana do .gitkatalogu podczas tworzenia repozytorium; domyślny (tutaj /usr/share/git-core/templates) zawiera kilka przykładowych punktów zaczepienia i innych plików, ale możesz użyć nowego katalogu szablonów, aby na przykład ustawić domyślne punkty zaczepienia.

$ tree /usr/share/git-core/templates
/usr/share/git-core/templates
├── branches
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── update.sample
└── info
    └── exclude

3 directories, 13 files

Jak mogę utworzyć repozytorium Git z domyślną nazwą gałęzi inną niż „ master”?

Użyłbyś Git 2.28 (Q3 2020): nazwa głównej gałęzi w istniejących repozytoriach i domyślna nazwa używana dla pierwszej gałęzi w nowo utworzonych repozytoriach jest konfigurowalna, dzięki czemu możemy ostatecznie odzwyczaić się od zakodowanego na stałe 'master ”.

I przypomnienie z sierpnia 2020 r. Z GitHub :

Jeśli 1 października 2020 r. Nie zmienisz domyślnej gałęzi dla nowych repozytoriów dla użytkownika, organizacji lub przedsiębiorstwa, zmieni się ona automatycznie z masternamain .
Możesz zrezygnować z tej zmiany w dowolnym momencie:

• Dla użytkowników na https://github.com/settings/repositories stronie
• W przypadku właścicieli organizacji w https://github.com/organizations/YOUR-ORGANIZATION/settings/repository-defaults stronie
• Dla administratorów firmowych, na https://github.com/enterprises/YOUR-ENTERPRISE/settings/member_privilegesstronie

Ta zmiana jest jedną z wielu zmian, które GitHub wprowadza, aby wspierać projekty i opiekunów, którzy chcą zmienić nazwę swojej domyślnej gałęzi.
Aby dowiedzieć się więcej o zmianach, które wprowadzamy, odwiedź github / renaming .

Ale wracając do samego Gita: (2.28, III kw.2020 ) Zobacz commit 508fd8e (29 czerwca 2020) autorstwa Đoàn Trần Công Danh ( sgn) .
Zobacz zatwierdzenie 0068f21 , zatwierdzenie a471214 , zatwierdzenie 0cc1b47 , zatwierdzenie 32ba12d , zatwierdzenie 6069ecc , zatwierdzenie f0a96e8 , zatwierdzenie 4d04658 (24 czerwca 2020) i zatwierdzenie 489947c (23 czerwca 2020) autorstwa Johannesa Schindelina ( dscho) .
Zobacz zatwierdzenie 8747ebb (24 czerwca 2020) autorstwa Don Goodman-Wilson ( DEGoodmanWilson) .
^{(Scalone przez Junio ​​C Hamano - gitster- incommit 11cbda2 , 06 lipca 2020)}

init: zezwól na określenie początkowej nazwy gałęzi dla nowego repozytorium

^{Podpisał: Johannes Schindelin}

Coraz więcej projektów i firm chce zmienić główną branżową nazwę swoich repozytoriów (patrz np. Tweet Mislav Marohnić ).

Aby zmienić nazwę tej gałęzi dla nowych repozytoriów, obecnie jedynym sposobem, aby zrobić to automatycznie, jest skopiowanie całego katalogu szablonów Gita, następnie wkodowanie żądanej domyślnej nazwy gałęzi do .git/HEADpliku, a następnie skonfigurowanieinit.templateDir aby wskazywało na te skopiowane pliki szablonów.

Aby uczynić ten proces znacznie mniej uciążliwy, niech wprowadzi nową opcję: --initial-branch=<branch-name>.

git init --initial-branch=hello myLocalRepo
# or
git config --global init.defaultBranch hello
git init myLocalRepo

I:

init: pozwala na ustawienie domyślnej nazwy początkowej gałęzi poprzez plik config

^{Pomoc: Johannes Schindelin
Pomoc: Derrick Stolee
Podpisanie: Don Goodman-Wilson}

Właśnie wprowadziliśmy opcję wiersza poleceń, --initial-branch=<branch-name>aby umożliwić inicjalizację nowego repozytorium z inną początkową gałęzią niż ta zakodowana na stałe.

Aby umożliwić użytkownikom bardziej trwałe nadpisywanie początkowej nazwy gałęzi (tj. Bez konieczności ręcznego określania nazwy dla każdego git initwywołania), wprowadźmy init.defaultBranchustawienie konfiguracyjne.

Uwaga: zatwierdzenie 489947c , dotyczące komunikatu o zatwierdzeniu przez scalanie, zostało cofnięte w Git 2.29, zobacz " Jak mogę dostosować komunikat zatwierdzenia przez git? ". Ustawienie pozostaje.
init.defaultBranch

Ma to wpływ na moduły podrzędne:

submodule: cofnij się do HEAD pilota w celu wykrycia brakującej gałęzi pilota

^{Pomoc: Philippe Blain
Podpisał: Johannes Schindelin}

Gdy remote.<name>.branchnie jest skonfigurowany, git submodule updateobecnie wraca do używania nazwy gałęzi master.
O wiele lepszym pomysłem jest jednak użycie pilota HEAD: na wszystkich serwerach Git, na których działają stosunkowo najnowsze wersje Gita, symref HEADwskazuje na główną gałąź.

Uwaga: t7419 pokazuje, że mogą istnieć przypadki użycia, które oczekują git submodule update --remote aktualizacji podmodułów do zdalnej mastergałęzi, nawet jeśli zdalna HEADwskazuje na inną gałąź.
Prawdopodobnie ta poprawka sprawia, że ​​zachowanie jest bardziej intuicyjne, ale istnieje niewielkie prawdopodobieństwo, że może to spowodować regresję w niejasnych konfiguracjach.

Mimo to powinno być w porządku, aby naprawić to zachowanie bez dłuższego okresu przejściowego:

• git submodule update --remoteKomenda nie jest to powszechne.
• Bieżące zachowanie Gita podczas uruchamiania tego polecenia jest całkowicie mylące, chyba że bieżąca gałąź zdalnego repozytorium to master (w takim przypadku proponowane zachowanie pasuje do starego zachowania).
• Jeśli użytkownik napotka regresji związku ze zmianą zachowań, poprawka jest właściwie banalna: ustawienie submodule.<name>.branch, aby masterprzywróci stary zachowanie.

Zauważ, że w Git 2.29 (Q4 2020) testy w programie contrib/są dostosowywane do ostatniej zmiany wfmt-merge-msg .

Zobacz commit b87528c (03 sierpnia 2020) autorstwa Emily Shaffer ( nasamuffin) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 83b8250 , 10 sierpnia 2020 r.)}

Revert "contrib:: subtreedostosuj test, aby zmienić fmt-merge-msg„

^{Podpisał: Emily Shaffer}

To przywraca zatwierdzenie 508fd8e8baf3e18ee40b2cf0b8899188a8506d07 .

W 6e6029a8 ( fmt-merge-msg: zezwalaj na ponowne pominięcie miejsca docelowego scalania) otrzymujemy zachowanie, w którym łączy się z ' master', domyślnie nie dołącza się znaku „ into 'master'” na końcu wiadomości łączenia. Ta poprawka testowa nie jest już potrzebna.

Również:

W Git 2.29 (Q4 2020) zaktualizuj testy, aby usunąć masterz nich słowo „ ”.

Zobacz commit f33f2d3 , commit b6211b8 (26 września 2020) i commit 432f5e6 , commit 5a0c32b , commit 659288c (21 września 2020) autor: Johannes Schindelin ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 58138d3 , 05 października 2020 r.)}

tests: unikaj zmian w masternazwie gałęzi

^{Podpisał: Johannes Schindelin}

Termin master ten ma ładną historię, która nieustannie przypomina o niesprawiedliwości rasowej. Projekt Git nie ma zamiaru tego utrwalać i już zaczął tego unikać.

Zestaw testów używa odmian tej nazwy dla gałęzi innych niż domyślna. Oprócz t3200, gdzie właśnie zajęliśmy się tym w poprzednim zatwierdzeniu, nazwy tych instancji można zmienić w sposób zautomatyzowany, ponieważ nie wymagają one żadnych zmian poza skryptem testowym, więc zróbmy to.

Widząc, że dotknięte gałęzie mają bardzo niewiele (jeśli cokolwiek) wspólnego z gałęzią domyślną, zdecydowaliśmy się na użycie całkowicie oddzielnego schematu nazewnictwa: topic_<number>(nie może tak być, topic-<number>ponieważ t5515 używa test_oidmaszyny z terminem, a maszyna używa wewnętrznie zmiennych powłoki, których nazwy nie mogą zawierać myślników).

Ta sztuczka została wykonana przez to wywołanie seda (GNU):

$ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh

I nadal z Git 2.29:

Zobacz commit 538228e , commit a15ad5d (08 października 2020) autorstwa Johannesa Schindelina ( dscho) .
^{(Scalenie przez Junio ​​C Hamano -gitster - w zatwierdzeniu 62564ba , 08 października 2020 r.)}

t1415: unikaj używania mainjako nazwy referencyjnej

^{Podpisał: Johannes Schindelin}

W ramach przygotowań do serii poprawek, która zmieni rozwiązanie awaryjne dla init.defaultBranch na main, nie mainużywajmy nazwy referencyjnej w tym skrypcie testowym.

W przeciwnym razie ⁽git for-each-ref ... | grep main ^{mężczyzna ),} który chce złapać te referencje, również by się nieoczekiwanie złapałrefs/heads/main.

Ponieważ odnośniki są lokalnymi dla danego obszaru roboczego (tj. Każde drzewo robocze ma swoje własne, tak jak HEAD ), a przypadek testowy używa już dodatkowego drzewa roboczego o nazwie " second", użyjmy nazwy "first zamiast " dla tych odnośników.

W tym czasie dostosuj tytuły testów, które mówią o „repozytorium”, a zamiast tego oznaczają „drzewo robocze”.

Od Git 2.28 (wydanego 27 lipca 2020 r.) Nowa opcja konfiguracji,init.defaultBranch Wprowadzono która ma zastąpić zakodowany termin master.

Domyślnie pozostaje master !

Użytkownik może nadpisać domyślną wartość zmiennej konfiguracyjnej za pomocą:

$ git config --global init.defaultBranch main

Przeczytaj rozdział dotyczący git doc, aby uzyskać więcej informacji. Wprowadzenie do init.defaultBranch