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?

do góry

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.

do góry

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.

do góry

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

do góry

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.

do góry

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.

do góry

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?

do góry

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

do góry