Wybrałem ten dział, bo w oprogramowaniu komputerowym nie ma działu na oprogramowanie wieloplatformowe.
Jak zmienić default branch w bare repozytorium?
Jakby ktoś się upierał, że czegoś takiego nie ma w kontekście samego repozytorium, polecam: git clone --bare https://github.com/github/gitignore
cd gitignore
git log
Tak, jest coś takiego w przypadku każdego niepustego repozytorium.
Dokonałem rozgałęzienia z powodu zmian w kodzie, których nie chcę zatwierdzać w dotychczasowej głównej gałęzi. Po wielu zmianach w obu gałęziach chcę zmienić nowy branch na główną gałąź. Niestety zmiana nazewnictwa (z master na tcp oraz udp na master) tego stanu rzeczy nie zmienia. Dalej jako domyślna jest wyświetlana gałąź od początku istnienia repozytorium. Klonowanie repozytorium po zmianie nazw też nie wykazuje jakichś zmian. Dalej default checkout idzie na tcp.
Jak zmienić default branch w (bare) repozytorium? Jak zmienić aby nowy klon tego repozytorium automatycznie miał wybrany branch na udp?
Wszelkie Argumentum Ad Googlum są nieuzasadnione.
Z powodu jakiegoś dziwnego ataku niewolnictwa w mózgach niektórych ludzi doszło do zaśmiecenia Google’a artykułami jak zmienić nazwę domyślnego brancha z master na main/default/cokolwiek-tylko-nie-niewolnictwo. Po przejrzeniu po 5 stron z dwóch zapytań straciłem całkowicie nadzieję w ludzkość. Zero pożytecznych informacji.
O ile dobrze rozumiem to chodzi Ci o to by po zrobieniu git clone domyślnie nie była ustawiona brach master (nawet jak istnieje) tylko jakaś Twoja wybrana?
Jeśli dobrze zrozumiałem, to z tego co pamięta, to nie ma czegoś takiego. To jaka branch jest brana jako „domyślna” zależy od serwera lub klienta gita, domyślnie utarło się, że jest to po prostu master. Ale np na github możesz zmienić domyślną branch dla projektu na np. development. Wtedy po wejściu na github na projekt domyslnie otworzy się ostatni commit z tej branchy a nie z mastera. Jednak po zrobieniu git clone z takiego projektu trzymanego na github domyslnie i tak ustawi Ci mastera.
Jednak musiałbym sprawdzić w sumie to dokładniej, a w tym momencie nie mam za bardzo czasu na eksperymenty .
Mikrosoft nie przeją gita, tylko github, a github to jest po prostu serwer gita. Więc to co pisałem dalej ma sens.
I domyślna branch pewnie teraz jest main a nie master bo ktoś wpadł na pomysł, że master kojarzy się z niewolnictwem i to dyskryminacja czarnych … dalej łatwo domyśleć się jak historia się potoczyła, ewentualnie poczytać można nawet na dp bo tutaj też się o tym rozpisywali.
Poczytałem, poczytałem i dałem radę coś z tego wyczytać.
Stworzyłem nowe repozytorium kid1. Zatwierdziłem plik tekstowy z jedną linijką tekstu (zatwierdzenie nr 1 - root commit). Następnie stworzyłem nowy branch udp. W nim zatwierdziłem zmianę w pliku tekstowym (zatwierdzenie nr 2-udp). Następnie przełączyłem się z powrotem do brancha master. Zatwierdziłem inne zmiany do pliku tekstowego (zatwierdzenie nr 2-master).
W ten sposób przygotowane repozytorium postanowiłem sklonować dwa razy. Pierwszy bare klon (parent1) wykonałem, gdy kid1 miał wybrany aktywny branch master, drugi klon (parent2) wykonałem, gdy kid1 miał wybrany aktywny branch udp. Następnie usunąłem dowiązania z tych repozytoriów do kid1. Oto wyniki:
Co ciekawe, parent1 ma tylko gałąź master (w sumie logiczne), zaś parent2 ma gałąź udp… i master. Klony tych repo zachowują się analogicznie. Klon parent1 ma domylny checkout na master, klon parent2 ma domyślny checkout na udp.
Zawsze mogłem gdzieś walnąć się w eksperymencie, ale raczej wszystko jest ok.
Zastanawia mnie, skąd taki wniosek, że to repo mam na GitHubie? Skąd taki wniosek, że w ogóle korzystam z jakiegokolwiek zewnętrznego serwisu? W pierwszym poście tylko podałem link do przykładowego, lekkiego repo. Nawet tytuł zaczyna się od [Git], nie [GitHub], [GitLab] czy [Bitbucket].
Rzeczywiście taka zmiana działa, default checkout idzie na wybrany branch. Mimo wszystko pytanie dotyczy samego gita, specjalne posiłkowanie się serwisami firm trzecich mija się z prostym, domowym osiągnięciem celu.
De facto to nie jest problem związany z niepoprawnym działaniem programu. To jest raczej szukanie odpowiedzi na jak zrobić ABC aby wyszło DEF, bo zachodzi warunek, że nie można zrobić w klasyczny sposób GHI. Zwykłe szukanie sposobu na osiągnięce jakiegoś efektu (możliwym do osiągnięcia konwencjonalnymi, powszechnie znanymi sposobami) przy tych samych danych, tylko że w nietypowych warunkach, które uniemożliwiają zastosowanie tych konwencjonalnych sposobów. Chyba zwykło się te sposoby określać jak workaround, ale pewnym tego być nie mogę.
Muszę przyczepić się do kilku słówek, żeby zrozumieć co chcesz osiągnąć.
Co przez to rozumiesz? Jak stworzyłeś to repozytorium? Jakiego typu to jest repo?
Odpowiadając na Twoje wczorajsze pytanie. Żeby zmienić defaultową branch na serwerze gita (bare repo) musisz zaktualizować jego HEAD komendą git symbolic-ref HEAD refs/heads/mybranch (doc: https://git-scm.com/docs/git-symbolic-ref). Bare repo nie obsługuje komendy checkout.
Kolejny zwrot akcji .
Zakładam że odpowiedzi na moje pytania z początku postu są takie, że pierwsze repo kid1 było zwykłym repo nie bare.
W takim przypadku masz sytuację (niepoprawną logiczne, ale dozwoloną) gdzie tworzysz bare repo zależne od zwykłego. Zwykłe jest potraktowane jako bare, więc jeśli HEAD był ustawiony na branch master to bare jest tworzone z HEAD na masterze. Gdy robisz drugie bare repo, kiedy kid1 jest na innej branchy, drugie bare repo ustawia swoje HEAD zgodnie z HEAD kid1 (które traktuje jako bare repo).
Generalnie repo powinno się klonować z bare repo, które służy do przechowywania repo (plików/zmian -zwał jak zwał), a nie do pracy z nim. Więc powinieneś zrobić tak, że masz to kid1 (powiedzmy, że najpierw zacząłeś lokalne eksperymenty i teraz chcesz je trzymać jednak na serwerze) i teraz gdzieś indziej tworzysz gdzieś bare:kid1. Na kid1 dodajesz origina (serwer) (git remote) z adresem bare:kid1 i pushujesz tam branche z kid1.
Drugi sposób (prostrzy). Robisz bare:kid1. Robisz git clone żeby mieć kid1. Pracujesz na kid1 i wypychasz zmiany git push.
Kolejny twist opowieści.
Gdy chcesz mieć dwa bare repo ze względów bezpieczeństwa. Wtedy musisz zapewnić ich synchronizację. Wystarczy zrobić co jakiś czas git fetch na takich repo (muszą mieć skonfigurowane remote na siebie lub master repo - zależy jak chcesz mieć to zorganizowane) np. przy pomocy crona. Oczywiście jeśli używałbyś serwera gita który wspiera replikację repozytoriów wtedy prawdopodobnie sam się tym zajmie.
Raczej nie robisz nowej wersji programu GIT, to „3 linkowy skrypt bash” ma mało wspólnego z realnym programowaniem - pewnie ta sama szuflada co HTML i dość stare standardy JavaScript (by nie obrażać aplikacji webowych).
Nie zgadzam się. Git to szereg, zestaw mini programów i nie są one bashowe. Ba sam git też nie jest napisany w bashu .
Nie zgadzam się również, że ma mało wspólnego z realnym programowaniem. Wręcz przeciwnie, jest podstawowym narzędziem do pracy z kodem, tak samo jak intepreter lub kompilator. Ba IDE jest zbędne, ale kompilator/interpreter i git to podstawy.
Uważam, też że akurat w przypadku tak specjalistycznego narzędzia dział jest odpowiedni. Wątpię by ktoś był w stanie pomóc autorowi w innym dziale. A jeśli by były jakieś komentarze to na poziomie filozofowania na podstawie tego co udało się komuś znaleźć w 30 sekund w dokumentacji. Czyli bez zrozumienia jak git działa i jak należy z go używać.
W skrócie opiszę, bo źródło może zniknąć. Na repozytorium „bare” musisz wykonać:
git symbolic-ref HEAD refs/heads/mybranch
To powinno uaktualnić HEAD, który odpowiada za to co będzie domyślnym branchem przy checkout. Oczywiście „mybranch” to nazwa twojego branch’a, którą musisz dostosować.
.
” z prawego rogu
.