2015-01-30 12 views
5

Chciałbym zbudować konkretny przepływ na naszej firmie git.Utwórz prywatną gałąź na zdalnym repozytorium w git

  1. programista tworzy gałąź na swoim komputerze lokalnym i zatwierdza tam kilka plików.
  2. dev wcisnąć ten oddział do zdalnego repo
  3. Inne deweloperów nie ma dostępu do tej gałęzi
  4. po kilka rund off popychanie dev decyzję o opublikowaniu jego zmiany.
  5. Scal swój prywatny oddział w oddziale publicznym
  6. popchnij ten oddział publiczny.

Innymi słowy - czy można skonfigurować prywatną gałąź zdalną w publicznym repozytorium?

+0

Po co pchać, jeśli nikt nie mógł z niego skorzystać ?! – Biffen

+0

Brak odpowiedzi, ale: dlaczego tego chcesz? Czy istnieje jakiś oficjalny wymóg zachowania tajemnicy? Czy to jest tak, że twórcy boją się dzielić swoją pracą? Ogólnie rzecz biorąc, pomocne jest, aby móc widzieć nawzajem swoje prace w toku (pomagać sobie nawzajem, podnosić się za kogoś, kto zachorował itp.). – sleske

+2

Chłopaki, ponieważ mój komputer może ulec awarii, ponieważ kod się nie kompiluje, ale muszę go jakoś zapisać, ponieważ potrzebuję części "prywatnej" w repozytorium dla funkcji eksperymentalnych. Spotkałem to w jakimś projekcie. Ale używają SVN i tworzą dwa "strumienie" prywatne dla codziennego rozwoju, a publiczność dostarcza zgodne funkcje –

Odpowiedz

7

Przepływ, który jest używany w moim zespole, ma mieć oddzielne repozytoria dla każdego członka zespołu oprócz pochodzenia na głównym serwerze git.

  1. Dev tworzy lokalny oddział na lokalnym komputerze i zobowiązuje dala
  2. Pod koniec dnia (lub gdy jest odpowiednia) dev popycha do jego prywatnej repo git push jdoe-private my-cool-branch
  3. Dev zdecyduje, że jest zadowolony z pracy do być publikowane i ewentualnie połączone, dzięki czemu można uporządkować go i rebase go bezkarnie
  4. Dev pcha swój oddział do pochodzenia git push origin my-cool-branch

Uzasadnieniem dla tej konfiguracji dla nas jest t o pozwól programistom swobodnie odnawiać i unikać problemów, które mogą powstać w wyniku ponownego wysyłania, a także mieć pełne kopie zapasowe. Oddzielne repozytoria są tylko prywatne według konwencji, ale w razie potrzeby można łatwo dodać kontrolę dostępu. Istnieje wiele powielania danych, ale jeśli twoje repozytorium nie jest duże, to prawdopodobnie nie jest to problemem.

+0

Ok. Wygląda jak rozwiązanie. Dev mają prywatne zdalne repo, które po prostu scalają to i publiczne. –

0

Powszechnie stosowanym rozwiązaniem jest uzgodnienie "przestrzeni nazw oddziałów" poprzez dodanie ciągu znaków do nazw oddziałów. Na przykład gałęzie, które zaczynają się od "private /", służą do prywatnych eksperymentów. Można by wtedy uzyskać branże jak

  • prywatne/johndoe/refactoring-taxcalculation
  • prywatnej/JohnDoe/newGUILayout
  • prywatne/JaneJones/Java8
  • private/TKirk/build-kosmicznego

Dzięki temu gałęzie się rozdzielają i jasno określają ich cel. Jednak w ten sposób gałęzie są nadal publiczne, ponieważ każdy może je zobaczyć i wyciągnąć.

Jeśli chcesz ograniczyć dostęp do oddziałów w zależności od użytkownika, musisz mieć kontrolę dostępu na poziomie oddziałów. W rdzeniu nie ma czegoś takiego, ale pozwalają na to niektóre serwery hostingowe git (np. Atlassian Stash). Nie znam żadnego serwera, który dopuszcza takie rodzaje oddziałów prywatnych, ale być może jest taki, który pozwala na to lub pozwala skryptować rozwiązanie.

Pamiętaj jednak, że to, o co prosisz, jest dość niezwykłe. Wspólnym rozwiązaniem jest to, które opisałem powyżej.

+0

gitolite ma koncepcję ograniczania dostępu push dla niektórych użytkowników do niektórych oddziałów. Jak młodszy programista nie mógł popchnąć do master branch. Ale w każdym razie wszystkie gałęzie są nadal czytelne. –

+0

Z pewnością wystarczy, że nazwa oddziału wyjaśnia, że ​​jest prywatna? Jeśli w twoim zespole jest ktoś, kto będzie ciągnąć taką prywatną gałąź i pracować z nią, oczekując, że pozostanie stabilny, to powiedziałbym, że problem jest gdzie indziej niż w twoim przepływie pracy git. –

Powiązane problemy