GoldenLine
Zaloguj się
Jakub Rajchowiak

Jakub Rajchowiak właściciel,
Rajchowiak.com

Temat: ponownie o git

witajcie, pewnie juz maja mnie wszyscy dosc. ale uporalem sie juz ze zrozumieneim mniej wiecej jak git dziala. Wykorzystujac serwer zewnetrzny pushuje sobie pliki testowe.

Ale teraz moje pytanie o zasady stosowane w praktyce.

Jesli zdalnie jest projekt w calosci i kazdy z programistow moze sobie wgrywac swoje zmiany. to kto to kontroluje i jak??

Robiac push nie mam mozliwosci edycji zmian, nadpisuje swoja funkcjonalnosc na to co juz tam jest. Przynajmniej tak to rozumiem i mi w testach wychodzilo. Jesli sie myle prosze o sprostowanie.

Wiec jesli dwoch programistow bedzie pracowac nad wspolnym projektem, kazdy bedzie robil lokalnie i zrobi push, i drugi robiac swoje rzeczy zmodyfikuje na przyklad plik szablonu i nadpisze swoimi zmianami zmiany poprzedniego? jak takie zdarzenia rozwiazuje sie w praktyce?
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: ponownie o git

Jakub Rajchowiak:
Wiec jesli dwoch programistow bedzie pracowac nad wspolnym projektem, kazdy bedzie robil lokalnie i zrobi push, i drugi robiac swoje rzeczy zmodyfikuje na przyklad plik szablonu i nadpisze swoimi zmianami zmiany poprzedniego? jak takie zdarzenia rozwiazuje sie w praktyce?
Za dużo wniosków, za mało testów.

Jeśli próbujesz zrobić push bez synchronizacji po swojej stronie, to dostajesz:
[vi@kahlua ~/git_test/b]$ git push ../a master

To ../a

 ! [rejected]        master -> master (non-fast-forward)

error: failed to push some refs to '../a'

To prevent you from losing history, non-fast-forward updates were rejected

Merge the remote changes before pushing again.  See the 'Note about

fast-forwards' section of 'git push --help' for details.
Link do wypowiedziLink
Jakub Rajchowiak

Jakub Rajchowiak właściciel,
Rajchowiak.com

Temat: ponownie o git

przyznam ze mialem podobne bledy ale myslalem ze to cos zle skonfigurowalem polaczenie z zewnetrzym repozytorium bo mialem z tym problemy.

ok napisales cos o synchronizacji, wiec biore sie dalej za lekture i zglebiam zeby nei zadawac znow glupich pytan.
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: ponownie o git

Aha - nazwałem to tylko przez przypadek synchronizacją. Jeśli będziesz googlał na ten temat, to raczej ludzie mówią nt. "merging" między gałęziami (zklonowane repozytoria to też w sumie gałęzie).
Link do wypowiedziLink
Jakub Rajchowiak

Jakub Rajchowiak właściciel,
Rajchowiak.com

Temat: ponownie o git

hmm aha no to chodzilo o laczenie galezi, to przerobilem. a wiec jednak nie opisalem chyba dokladnie jaki mam problem ze zrozumieniem.

Zalozmy ze programista ma juz gotowa galaz master wczesniej sklonowana z zewnetrznego rep. Uwaza ze juz jest wszysko ok i robi push. Nie ma zadnych bledow. Ale czy jest mozliwosc kontroli jakoby odgornej jako menagera projektu czy wprowadzone przez programiste zmiany sa faktycznie dobre?? albo moze nawet nie to ze dobre ale zeby kolejny programista nie nadpisal zmian poprzedniego??

Wiem ze dwie osoby nie powinny pracowac na jednym kodem ale zalozmy ze pracuja nad osobnymi partiami kodu ale modyfikuja ta sama bibloteke i zmiany nastapily w tej samej lini?
Link do wypowiedziLink
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: ponownie o git

Jeśli zmiany nastąpiły w tej samej linii (lub okolicznych) to automatyczny merge się nie uda i trzeba będzie rozwiązać merge conflict ręcznie. Git wrzuca obie wersje tychże linii do pliku jedna pod drugą i każe wybrać która jest właściwa, ewentualnie połączyć je (decyzja programisty). Po rozwiązaniu konfilktu robimy commit -a (wszystko).

Przy jednej gałęzi na zewnętrznym serwerze (origin/master) nie powinny się zdarzać nadpisania kodu, bo każdy musi zrobić najpierw fetch i merge u siebie lokalnie. Nie pwoinny, ale mojemu koledze udało się nadpisać moje zmiany. Do tej pory nie wiem jak to zrobił, ale jego narzędzie GUI (TortoiseGit zdaje się) namieszał w commit tree.
Link do wypowiedziLink
Jakub Rajchowiak

Jakub Rajchowiak właściciel,
Rajchowiak.com

Temat: ponownie o git

czyli jesli dobrze rozumiem praktyka jest, ze zanim zrobimy push, ciagniemy wszystko z rep. do nowej galezi, mergujemy ja z nasza robocza galezia i wysylamy z powrotem do rep?

dodatkowo jesli prgramista zrobi merga i stwierdzi ze jego nowy kod jest lepszy (nie musi miec racji) to nadzorujacy projekt moze powrocic do poprzedniej wersji robiac modyfikacje historii tak?? Sciaga cale rep do siebie i przeglada historie zmian i ew. ja modyfikuje i spowrotem wysyla na rep?

Wybaczcie moje kombinowanie ale staram sie dobrze zrozumiec filozofie pracy aby nie robic pozniej logicznych bledow.

jakby kogos interesowalo to chyba znalazlem potwierdzenie swoich rozmyslan:

"If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push."Jakub Rajchowiak edytował(a) ten post dnia 18.03.10 o godzinie 18:28
Link do wypowiedziLink

konto usunięte

Temat: ponownie o git

Również posiadam mały problem z GIT-em. Może ktoś z szanownego grona będzie w stanie mi pomóc?

Posiadam lokalne repozytorium do którego przyłączyłem dwa zdalne repozytoria poprzez:

git remote add heroku git@heroku.com:appname.git
git remote add origin git@github.com:user/appname.git

Wykonałem pierwszy commit, wysłałem na oba repozytoria zmiany poprzez polecenie "git push heroku master" i "push origin master" i tutaj wszystko było ok. To samo wykonał mój znajomy, który również do swojego lokalnego repozytoria przyłączył te dwa zdalne i również popełnił commit.

Mój problem pojawił się w momencie, gdy chciałem zaktualizować swoją lokalną kopię o nowy kod mojego znajomego, który zamierzałem pobrać ze zdalnego repozytorium na heroku.com. Przez pomyłkę, zamiast wykonać "git pull heroku master", wykonałem polecenie "git pull heroku", co zakończyło się:

"From heroku.com:appname
* [new branch] master -> heroku/master
You asked to pull from the remote 'heroku', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line."

i chwilę poźniej (chyba po push'u) na GitHubie (na heroku nie wiem jeszcze jak przeglądać logi) pojawił się wpis jako nowy commit:

"Merge branch 'master' of heroku.com:appname"

I tutaj mam kilka pytań:

1. Dlaczego utworzył nowe odgałęzienie?
2. Dlaczego pojawiło się to w logach commit'ów na GitHubie? Na GitHubie sprawdzałem ile jest odgałęzień, ale jest tylko jedno, to główne "master".
3. Czy i jak mogę wycofać tę zmianę wraz z usunięciem tego z historii commit'ów?

Z góry dziękuję za wszelką pomoc!
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

bzr, mercurial, darcs i git...




Wyślij zaproszenie do
Anuluj