Zepsuty master

[kaiks]

Poddaję się.

Zwaliłem coś i git nie jest narzędziem dla mnie, tj. usiłowałem się o nim uczyć i czytać przez ostatnie 3 godziny, ale bez rezultatów. Przerosło mnie przetrudne zadanie cofnięcia commita na moim branchu i w rezultacie zepsułem swojego brancha i mastera (mimo że na mastera afaik się nie checkoutowałem do momentu próby naprawy zepsucia!)

Jeśli byś mógł spróbować użyć swojej mocy czarodziejskiej i naprawić mastera, byłoby super, a ja już swojego brancha skasuję i zrobię na nowo. Please.

[jam231]

Sorry, ze tak pozno ale sobotoa mi jakos umknela calkiem przez nieszczesna noc z czwartku na piatek :( Zobacze co narobiłeś i postaram się naprawić.

W ogóle co to jest ten "Merge pull request #54 from jam231/kaiks" ? jedno szybkie spojrzenie do wnetrza, tego pull requesta

Woo... Zrobiłeś (tak to wygląda) merge'a mastera ze swoim branchem, były konflikty które zignorowałeś, nie, jeszcze lepiej, Ty zrobiłeś pull requesta kaiks -> master, którego sam zmergowałeś, sadząc że są jakieś zmiany które trzeba wepchnać na mastera, a w rzeczywistości to były konflikty, lol :D

Jak są jakieś konflikty, to powinien Ci się pojawić odpowiedni komunikat w konsoli (nie wiem jak jest z gui :( ), czy nawet przy probie zrobienia merge pull requesta. To troche wyglądało tak, jakbyś po zobaczeniu, że jakieś pliki mają zmiany commitował je, nie zastanawiając się. Nie ładnie.

Nie rób tak.

* Bezbośrednio do mastera commitujemy wtedy, kiedy jest jakiś mały błąd który trzeba załatać,

* Pull request inny branch -> master służą do feature'ów \ łatania dużych błędów i ktoś inny powinien zrobić merge'a, a przynajmniej ta druga osoba powinna zobaczyć tego requesta.

* Pull request master -> inny branch, to śmiecenie githuba (historii etc.) i fajnie by było robić to ręcznie.

Te zasady trochę ułatwią nam życie, a nie ograniczą go zbytnio. Zdaje sobie sprawę, że czasami dość długo trwa zanim spojrzę na githuba (vide moja nieobecność wczorajsza), ale to nie jest przecież tak, że jak dany pull request będzie sobie wisiał w powietrzu przez parę godzin to się coś stanie. Można zrobić kolejnego i będą wisiały dwa, oczywiście będą pewne problemy jeżeli się okaże, że wcześniejszy nie jest przetestowany i ma bugi ;-)

Ach, no i w związku z pewnymi, moim obserwacjami dot. komunikacji via internet:

Pisałem to tylko z lekka irytacją a dużą dozą chęci usystematyzowanej współpracy, więc nie czuj się atakowany ;-)

[jam231]

Master wydaje się być naprawiony, niestety cześć commitów się jakims cudem zdublowała po zrobieniu merge'a z wcześniejsza wersja mojego brancha - pojęcia nie mam dlaczego, widać kiepski ze mnie czarodziej i tak niestety jest jak się używa potężnego narzędzia, przeczytawszy wcześniej jakiś krótki tutorial i googlając :( Dla utrudnienia mój lokalny branch miał commity, nie będące w remote i których na razie nie chciałem tam dawać.

Niby mógłbym próbować to naprawić, ale chyba tylko na zasadzie usunięcie mastera całkowicie, stworzenia nowego i zrobienia merge'a z moim branchem.

[kaiks]

No dobra. Dzięki.

Jak dla mnie najciekawsze jest to, że (przynajmniej świadomie) ja robiłem tak:

miałem jakiś nadmiar na swoim branchu, więc chciałem cofnąć te zmiany, bo nie mogłem zrobić łatwego merge. Okazuje się że github bardzo nie lubi robić rzeczy w sposób 'straightforward' (jak na narzędzie stworzone dla/przez prawdziwych linuxowców przystało) i żeby cofnąć zmiany trzeba było cofać commity przez tworzenie zmian które kasują poprzednie (?). Radośnie próbowałem to zrobić ale skończyło się o dziwo na tym, że po paru godzinach coś się zmieniło na masterze. Nic świadomie tam nie robiłem. Potem jeszcze próbowałem ręcznie merge'ować, ale to nie pomogło raczej :p

Mógłbym niby przeczytać jakąś książkę(!) o tym, ale chyba nie o to chodzi, żeby do użycia narzędzia, które skraca czas pracy o godzinę tygodniowo (w stosunku do svna), uczyć się obsługi go przez 20 godzin. Zwłaszcza w takim momencie jak jesteśmy teraz.

[jam231]

Nie wiem co to był za nadmiar..

• Jeśli tylko lokalnie:
  • jeśli jakieś drobne zmiany, których nie commitowałes i nie chciałeś commitować (nie zrobiles git add ... ) to wystarczy git checkout .
  • jesli commitowales to pewnie jakis git reset \ git revert w swoich wariacjach.
• Jesli jest tez na remote, to patrz 1.2 + git push -f

Sa pewnie mądrzejsze sposoby, i ja nawet nie ręczę za to, że w/w niczego nie zepsują...

Dobry rant :+1: Co do ostatniego akapitu : no już nie bądź taki.