Dwa repozytoria, jeden kod

Czy da się prowadzić projekt na dwóch różnych repozytoriach w taki sposób

REPO1 ---> klonuje i robi REPO 2

REPO1 ---> commi1
REPO1 ---> commi2
REPO1 ---> commi3

REPO2 ---> commtX = commi1 + commi2 + commi3

REPO1 ---> commi4
REPO1 ---> commi5
REPO1 ---> commi6

REPO2 ---> commtY = commi4 + commi5 + commi6

W tym monecie oba repozytoria maja identyczny kod ale w REPO2 historia jest inna

Tak, pod warunkiem, że zamiast słowa "repozytorium" użyjesz "gałąź". W szczególności możesz pchać jeden branch do jednego remote, a drugi branch do drugiego remote.

Z perspektywy gita nie ma znaczenia, czy to jedne repo z dwoma branchami czy dwa z jednym. Można tak robić, ale ciężko integrować zmiany pomiędzy takimi branchami. Jeśli historie nie są zgodne, to przenoszenie commitów polega na cherry-pick, które mniej więcej polega na ponownym zaaplikowaniu zmian z danego commita, ale w innych okolicznościach. Takie przeniesione commity mają inne hashe, więc historia nie jest zgodna, ale czasami to jest pożądane np. jak masz branch na release i chcesz wrzucić jakiegoś hot fixa, który jest commitem na głównej gałęzi. Jeśli cię to interesuje to poczytaj o git cherry, git cherry-pick i git rebase

Można, ale po co? Dodatkowa robota a zysku nie widzę. Boisz się że ktoś będzie historię gita czytać?

KamilAdam napisał(a):

Można, ale po co? Dodatkowa robota a zysku nie widzę. Boisz się że ktoś będzie historię gita czytać?

Nie widzę tu zadnej dodstkowej roboty. Dwa branche - develop i master, w developie wrzucamy wszystko, do mastera lecą squashe. Kwestie ustawienia odpowiednich remote są jednorazowe.

Adamek Adam napisał(a):

Czy da się prowadzić projekt na dwóch różnych repozytoriach w taki sposób

REPO1 ---> klonuje i robi REPO 2

REPO1 ---> commi1
REPO1 ---> commi2
REPO1 ---> commi3

REPO2 ---> commtX = commi1 + commi2 + commi3

REPO1 ---> commi4
REPO1 ---> commi5
REPO1 ---> commi6

REPO2 ---> commtY = commi4 + commi5 + commi6

W tym monecie oba repozytoria maja identyczny kod ale w REPO2 historia jest inna

No da się, tylko że jak historia będzie inna to nie będziesz mógł nigdy korzystać z nich tak jakby miały ten sam kod. No nie zmergujesz sobie tak branchy, nie zrobisz rebase'a, i innych takich. Jeśli zmienisz historię na obu z nich, to nie ważne czy to będzie jedno repo z dwoma remote'ami czy dwa repo osobne, efekt będzie taki sam jak w przypadku dwóch osobnych repo w którym po prostu zdażyło się tak, że mają taki sam kod. Jeśli masz różne historię to idea "jednego repo" tak na prawdę troche tu zanika.

Nie widzę żadnej przewagi w takim rozwiązaniu, oprócz tego żeby sobie udowodnić koncept.

Jedyny sens takiego rozwiązania jaki bym widział, to taki że chciałbyś mieć "czystą historię" na jednym repo, i "brudną historie" na drugim; tylko po co komuś brudna historia. Jakiekolwiek szczegóły masz w tej brudnej historii, to możesz je zawrzeć też w czystej.

Miało by dla mnie sens gdybyś miał mieć dwa repozytoria z tą samą historią (np masz remote'a pod orginalne repo i fork). Ale jeśli mają różną historię? I don't see it yet.

Może powiesz nam jaki efekt chcesz uzyskać? To znajdziemy jakieś lepsze rozwiazanie ku temu.

brudna historia dla mnie :)
trochę ogładzona historia dla osób na zewnątrz
generuje trochę sporo commitów i opisow na temat tego co sie dzieje

No to git merge --squash jeśli nie chcesz przepisywać historii na swoim feature branchu. Wtedy przy merge'u feature branch -> develop do tego drugiego brancha trafi uproszczona historia, a na feature branch zostanie po staremu.