Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31424 > unrolled thread

Jak lepiej zarządzać gałęziami gita?

Back to article view | Back to pl.comp.programming

Contents

  Jak lepiej zarządzać gałęziami gita? Borneq <borneq@antyspam.hidden.pl> - 2018-01-29 17:24 +0100
    Re: Jak lepiej zarządzać gałęziami gita? Wojciech Muła <wojtek.mula@gmail.com> - 2018-01-29 09:39 -0800
      Re: Jak lepiej zarządzać gałęziami gita? Borneq <borneq@antyspam.hidden.pl> - 2018-01-29 19:43 +0100
        Re: Jak lepiej zarządzać gałęziami gita? Mateusz Bogusz <mabakay@o2.pl> - 2018-01-29 20:19 +0100
          Re: Jak lepiej zarządzać gałęziami gita? Borneq <borneq@antyspam.hidden.pl> - 2018-01-29 21:34 +0100
            Re: Jak lepiej zarządzać gałęziami gita? Borneq <borneq@antyspam.hidden.pl> - 2018-01-30 04:19 +0100
              Re: Jak lepiej zarządzać gałęziami gita? Borneq <borneq@antyspam.hidden.pl> - 2018-01-30 11:34 +0100
                Re: Jak lepiej zarządzać gałęziami gita? Mateusz Bogusz <mabakay@o2.pl> - 2018-02-01 21:56 +0100

#31424 — Jak lepiej zarządzać gałęziami gita?

Najpierw rozwijałem program który korzystał mysql w gałęzi master.
Następnie, zachowałem tę gałąź mysql pod nazwą before_hbase i zacząłem 
rozwijać docelowe HBase jako gałąź master. Rozwijałem również before_hbase.
Teraz zamiast HBase będzie MapR-DB, które będzie rozwijane z gałęzi 
before_hbase, bo gałąź master została nie rozwijana.
Jak zrobić:
- zmienić before_hbase na mysql
- stare master na hbase
- rozwijać MapR jako master

Albo lepiej:
- zmienić before_hbase na master
- stare master na hbase
- rozwijać MapR jako mapr
?

Jak zmieniać tak, by nie było nagłych przeskoków w historii gita i aby 
historia była użyteczna?

[toc] | [next] | [standalone]

#31425

On Monday, January 29, 2018 at 5:24:19 PM UTC+1, Borneq wrote:
> Najpierw rozwijałem program który korzystał mysql w gałęzi master.
> Następnie, zachowałem tę gałąź mysql pod nazwą before_hbase i zacząłem 
> rozwijać docelowe HBase jako gałąź master. Rozwijałem również before_hbase.
> Teraz zamiast HBase będzie MapR-DB, które będzie rozwijane z gałęzi 
> before_hbase, bo gałąź master została nie rozwijana.
> Jak zrobić:
> - zmienić before_hbase na mysql
> - stare master na hbase
> - rozwijać MapR jako master
> 
> Albo lepiej:
> - zmienić before_hbase na master
> - stare master na hbase
> - rozwijać MapR jako mapr
> ?
> 
> Jak zmieniać tak, by nie było nagłych przeskoków w historii gita i aby 
> historia była użyteczna?

Sama zmiana nazw branchy Ci nie wystarczy?

Co masz na myśli pisząc "użyteczną historię"? Jeśli masz
małe, atomowe commity, sensownie opisane to to chyba wystarczy.

w.

[toc] | [prev] | [next] | [standalone]

#31426

W dniu 29.01.2018 o 18:39, Wojciech Muła pisze:
> Sama zmiana nazw branchy Ci nie wystarczy?
> 
> Co masz na myśli pisząc "użyteczną historię"? Jeśli masz
> małe, atomowe commity, sensownie opisane to to chyba wystarczy.

czyli zmieniam master na hbase, na razie hbase=master
trzy wyjścia: 1.master jest nie rozwijany, 2.master to mysql, 3.master 
to mapr.
gdy wybieram 2 lub 3 to master nagle będzie inną gałęzią.
będzie przeskok.

[toc] | [prev] | [next] | [standalone]

#31427

W dniu 29.01.2018 o 19:43, Borneq pisze:
> 
> czyli zmieniam master na hbase, na razie hbase=master
> trzy wyjścia: 1.master jest nie rozwijany, 2.master to mysql, 3.master 
> to mapr.
> gdy wybieram 2 lub 3 to master nagle będzie inną gałęzią.
> będzie przeskok.

Jakieś poplątanie z pomieszaniem. Zasadniczo na masterze każdy by się 
spodziewał znaleźć kompilowalną wersję projektu w aktualnie wybranej 
architekturze (programistycznej). W pozostałych branczach rozwijana 
równolegle np. inna architektura - w Twoim przypadku widzę że sprowadza 
się to do bazy danych. Mastera ewentualnie traktować jak core/część 
wspólną a w branczach implementacja fasad/fasady. Wszystko w połączeniu 
z rebase+cherry pick i jest schludnie i czytelnie.

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [next] | [standalone]

#31428

W dniu 29.01.2018 o 20:19, Mateusz Bogusz pisze:
> wspólną a w branczach implementacja fasad/fasady. Wszystko w połączeniu 
> z rebase+cherry pick i jest schludnie i czytelnie.

Jak to zrobić?
zmiana:
jestem w gałęzi master i zmieniam na hbase
git checkout -b hbase
git push origin hbase

teraz gorzej:
jestem w gałęzi before_hbase i zmieniam na master
w jaki sposób? git checkout -b master nie zadziała bo już jest master

jest jeszcze rebase+cherry pick ale w książce Gajdy piszą że rebase nie 
można wykonać na publicznych zmianach, czyli tylko tych, które są w 
katalogu .git a nie na githubie.
Jest jeszcze metoda siłowa: przechodzę na master, wrzucam tam pliki ze 
stanu ostatniej before_hbase i robię commit. Ale wtedy brakuje mi 
historii atomowej.

[toc] | [prev] | [next] | [standalone]

#31429

W dniu 29.01.2018 o 21:34, Borneq pisze:
> W dniu 29.01.2018 o 20:19, Mateusz Bogusz pisze:
>> wspólną a w branczach implementacja fasad/fasady. Wszystko w 
>> połączeniu z rebase+cherry pick i jest schludnie i czytelnie.
> 
> Jak to zrobić?

Może się komuś przyda:
Zrobiłem tak:
najpierw commity wrzuciłem do githuba (git push) z before_hbase, które 
ma być głównym.
Utworzyłem katalog test, tam sklonowałem z githuba i miałem master.
Będąc w master zrobiłem "merge origin/before_hbase"
były konflikty , więc nadpisałem pliki tymi z katalogu before_hbase.
add, potem commit
Nie ma kłopotu z nagłym nieatomowym przyrostem historii.
Teraz trzeba tylko teraz zrobić git push aż 96 commitów.

[toc] | [prev] | [next] | [standalone]

#31430

W dniu 30.01.2018 o 04:19, Borneq pisze:
> Będąc w master zrobiłem "merge origin/before_hbase"

w moim wypadku nie odwrotnie;
gdy w before_hbase zrobiłem "merge  master" powstała gałąź to 
before_hbase a nie o to mi chodziło.
Czy jednak w moim wypadku nie lepsze rebase?

[toc] | [prev] | [next] | [standalone]

#31436

W dniu 30.01.2018 o 11:34, Borneq pisze:
> 
> w moim wypadku nie odwrotnie;
> gdy w before_hbase zrobiłem "merge  master" powstała gałąź to 
> before_hbase a nie o to mi chodziło.

Nie musisz bać się eksperymentowania bo zawsze masz git reset do 
dyspozycji - tylko doczytaj sobie różnicę hard/soft/mix najpierw a potem 
sprawdź organoleptycznie.

> Czy jednak w moim wypadku nie lepsze rebase?

Napiszę Ci że ciężko zrozumieć co Ty chcesz zrobić. Wszystkie komendy 
jak merge/rebase dają efekt docelowy na aktualnej gałęzi. Z rebasem 
bardzo fajne efekty daje używanie również rebase children.

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web