Kiedy zatwierdzenie kontroli wersji jest zbyt duże? [Zamknięte]

Słyszałem w kilku miejscach: „Nie dokonuj dużych zobowiązań”, ale tak naprawdę nigdy nie zrozumiałem, co to jest „duże” zobowiązania. Czy jest duży, jeśli pracujesz na wielu plikach, nawet jeśli są one powiązane? Ile części projektu powinieneś pracować jednocześnie?

Dla mnie mam problem z podejmowaniem „małych zobowiązań”, ponieważ zapominam lub tworzę coś, co tworzy coś innego, co tworzy coś innego. W efekcie powstają takie rzeczy:

Wykonano niestandardową kolejkę wychodzącą

Nerw
-Nowe pole msgQueue, które jest niczym więcej niż SingleThreadExecutor
-sendMsg blokuje, aż wiadomość zostanie wysłana, i dodaje czas oczekiwania między otrzymaniem wiadomości
wysłane
Zaktualizowano połączenia -adminExist (patrz kontroler)
-Usunięto calles do sendMessage

Kontroler
-Nowe pole msgWait oznacza czas oczekiwania między wiadomościami
-Starting wtyczek serwisowych przeniesiony do reloadPlugins
-adminExists przeniesiono z serwera z powodu globalnych administratorów. Kontrole na kanale,
serwer i poziom globalny

Admin
-Nowe metody getServer i getChannel, które pobierają odpowiedni obiekt Administrator
należy do

BotEvent
-toString () także pokazuje dodatkowe i dodatkowe 1

Kanał
-channel zmieniono nazwę na name
-Naprawiono literówkę w kanale (int)

serwer
-Przesunięty administrator istnieje dla kontrolera

PluginExecutor
-Dodano mniejsze testy, zostaną usunięte później

Wtyczki JS
-Zaktualizowano do zmian w ramach
-Replaced InstanceTracker.getController () with Controller.instance
-VLC mówić teraz we własnym pliku

Różne aktualizacje i zmiany projektu NB

---

Dotknięte pliki
Zmodyfikuj /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Zmodyfikuj /trunk/Quackbot-Core/dist/README.TXT
Zmodyfikuj /trunk/Quackbot-Core/nbproject/private/private.properties
Zmodyfikuj /trunk/Quackbot-Core/nbproject/private/private.xml
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/Bot.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/Controller.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Zmodyfikuj /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Zmodyfikuj /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Zmodyfikuj /trunk/Quackbot-GUI/dist/README.TXT
Zmodyfikuj /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Zmodyfikuj /trunk/Quackbot-GUI/nbproject/private/private.properties
Zmodyfikuj /trunk/Quackbot-GUI/nbproject/private/private.xml
Zmodyfikuj /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Zmodyfikuj /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Usuń /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Zmodyfikuj /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Zmodyfikuj /trunk/Quackbot-Impl/dist/README.TXT
Zmodyfikuj /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Zmodyfikuj /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Zmodyfikuj /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Zmodyfikuj /trunk/Quackbot-Impl/lib/javarebel.stats
Dodaj /trunk/Quackbot-Impl/lib/jrebel.info
Zmodyfikuj /trunk/Quackbot-Impl/nbproject/private/private.properties
Zmodyfikuj /trunk/Quackbot-Impl/nbproject/private/private.xml
Zmodyfikuj /trunk/Quackbot-Impl/nbproject/project.properties
Zmodyfikuj /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Dodaj / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Zmodyfikuj /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Zmodyfikuj /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Zmodyfikuj /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Zmodyfikuj /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Zmodyfikuj /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Zmodyfikuj /trunk/Quackbot-Impl/plugins/testCase.js
Dodaj /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Zmodyfikuj /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Dodaj / trunk / Quackbot-Impl / vlc_http
Dodaj /trunk/Quackbot-Impl/vlc_http/current.html
Zmodyfikuj /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Zmodyfikuj /trunk/Quackbot-Plugins/dist/README.TXT
Zmodyfikuj /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Zmodyfikuj /trunk/Quackbot-Plugins/nbproject/private/private.properties
Zmodyfikuj /trunk/Quackbot-Plugins/nbproject/private/private.xml
Zmodyfikuj /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Dodaj / trunk / Quackbot-Plugins / vlc_http
Dodaj /trunk/global-lib/jrebel.jar

Tak....

W przypadku pytań:

• Jakie są czynniki, gdy zatwierdzenie staje się zbyt duże ( rzeczy nieoczywiste )?
• Jak możesz zapobiec takim zobowiązaniom? Proszę podać szczegóły
• Co powiesz na to, kiedy jesteś na półwczesnym etapie rozwoju, kiedy wszystko idzie szybko? Czy ogromne zobowiązania wciąż są w porządku?

Dla mnie mam problem z podejmowaniem „małych zobowiązań”, ponieważ zapominam lub tworzę coś, co tworzy coś innego, co tworzy coś innego.

To jest problemem. Wygląda na to, że musisz nauczyć się rozkładać swoją pracę na mniejsze, łatwiejsze do opanowania części.

Problem z dużymi zatwierdzeniami to:

• W projekcie wieloosobowym większa szansa, że ​​twoje zobowiązania spowodują konflikty dla innych programistów do rozwiązania.
• Trudniej jest dokładnie opisać, co zostało zrobione w komunikatach dziennika.
• Trudniej jest śledzić kolejność wprowadzania zmian, a tym samym zrozumieć przyczynę problemów.
• Zwiększa to prawdopodobieństwo utraty wielu niezaangażowanych prac.

Czasami duże zmiany są nieuniknione; np. jeśli musisz zmienić główny interfejs API. Ale tak zwykle nie jest. A jeśli znajdziesz się w takiej sytuacji, prawdopodobnie dobrym pomysłem jest utworzenie oddziału i wykonywanie tam swojej pracy ... z wieloma małymi zobowiązaniami ... i reintegracja po zakończeniu.

(Innym przypadkiem jest początkowy import, ale NIE jest to problematyczne z punktu widzenia wyżej wymienionych problemów).

Zasada jednolitej odpowiedzialności.

Każde zatwierdzenie kontroli źródła powinno służyć tylko jednemu celowi. Jeśli musisz umieścić słowo „i” lub „również” w podsumowaniu, musisz je podzielić.

Bardzo często zdarza się, że w kopii roboczej pojawia się wiele oddzielnych niezwiązanych lub częściowo powiązanych zmian. Nazywa się to „problemem splątanych kopii roboczych” i jest to bardzo trudne do uniknięcia nawet dla zdyscyplinowanych programistów. Jednak zarówno Git, jak i Mercurial zapewniają narzędzia do rozwiązania tego problemu - git add -p lub zaznaczanie porcji i kolejki Mercurial odpowiednio w TortoiseHg .

Wyobraź sobie, że klient poprosił o dokonanie konkretnej zmiany - na przykład dodanie reguły, że czegoś takiego nie można zrobić w ciągu dwóch dni od daty „cokolwiek”. Następnie, po dokonaniu zmiany, zmieniają zdanie. Będziesz chciał cofnąć swoje zatwierdzenie. Jeśli wszystko jest wmieszane w pewne rzeczy związane ze zmianą sortowania niepowiązanych raportów, twoje życie jest nędzą.

Jeden element pracy, jeden zestaw zmian. Jedno żądanie od klienta, jeden zestaw zmian. Jedna rzecz, o której możesz zmienić zdanie, jedna zmiana. Czasami oznacza to, że jest to jeden wiersz kodu. Czasami jest to dziesięć różnych plików, w tym schemat bazy danych. W porządku.

Duże zatwierdzenia mają miejsce, gdy masz mnóstwo zmian, które tak naprawdę nie wszystkie idą w tym samym segmencie. Jeśli zmienię logikę kontrolera, to model połączenia z bazą danych, a potem trochę innych. skrypty, nie powinienem łączyć tego wszystkiego w ramach jednego zatwierdzenia.

Zapobieganie polega na zatwierdzaniu zgodnie z tym, co wypełniasz. W powyższym przykładzie zatwierdziłbym po logice kontrolera, po pracy bazy danych i po skryptach. Nie odkładaj popełniania po prostu dlatego, że wiesz, co się zmieniło. Inne osoby spojrzą wstecz na komunikat dziennika zatwierdzenia „Zmienione rzeczy” i będą się zastanawiać, co paliłeś.

Początkowy import to prawdopodobnie największe zobowiązania, jakie powinieneś mieć. Konfigurujesz system od zera? Pewnie masz kilka dużych zobowiązań. Po wyrównywaniu go jednak nadszedł czas, aby wszystko było uporządkowane.

Jeśli wiesz, że będziesz wcześniej pracował nad dużą częścią kodu, sugerowałbym utworzenie gałęzi dla określonej funkcji, okresowo ściągając kod z linii głównej, aby upewnić się, że kod pozostaje zsynchronizowany. Po zakończeniu pracy nad oddziałem scal wszystkie zmiany z powrotem do linii głównej. W ten sposób inni członkowie zespołu nie będą zaskoczeni i / lub zirytowani, gdy zobaczą ogromne zobowiązanie. Ponadto istnieje znacznie mniejsza szansa na uszkodzenie. Ćwicz dalej, aby rozbić rzeczy na mniejsze zobowiązania. Z czasem stanie się drugą naturą.

Ten przykład pokazuje, że zatwierdzenie jest zbyt duże.

Zasadniczo opisz zmianę w jednym zdaniu lub jednym wierszu tekstu. (W oparciu o tę zasadę, zatwierdzenie należy podzielić na 10-15 mniejszych). Jeśli nie możesz odpowiednio skomentować zatwierdzenia w jednym wierszu, oznacza to, że jest on już zbyt duży.

Aby ćwiczyć mniejsze zatwierdzenia, rób notatki w notatniku (lub Notatniku) o tym, co już zmieniłeś lub dodałeś. Zatwierdź, zanim stanie się długą listą lub zanim dokonasz zmiany kodu niezwiązanej z tym, co już masz w notatniku.

W mojej dziedzinie (modelowanie fizyki) odkryłem dzisiaj błąd w danych wyjściowych, którego nie było w repozytorium przed 6 miesiącami. Kiedy to się stanie, przeszukuję binarnie wersje:

1. Uruchom model sprzed 3 miesięcy
2. Jeśli błąd nadal występuje, uruchom model sprzed 4,5 miesiąca
3. ... powtarzaj, aż znajdę zatwierdzenie, które daje złą wydajność

Kiedy błąd został wprowadzony w monstrualnym zatwierdzeniu, muszę usiąść z grzebieniem o drobnych zębach, aby znaleźć źródło problemu. Jeśli zatwierdzenie dotknęło niewielką liczbę plików, śledzenie linii kodu, która spowodowała problem, jest mniej bolesne.

Polecam podział problemu na szereg mniejszych zadań (najlepiej umieścić każde zadanie w narzędziu do śledzenia błędów). Dokonaj zatwierdzenia po zakończeniu każdego zadania (i zamknij ten błąd / funkcję w swoim narzędziu do śledzenia błędów).

To nie wielkość zatwierdzenia jest naprawdę ważna, to zakres zmiany powinien określać sposób organizacji twoich zobowiązań.

Możesz na przykład zmienić każde wystąpienie __macro1na __macro2na dużą bazę kodu, która zmienia 200 plików. W takim przypadku 200 zobowiązań nie byłoby rozsądnych.

To, co chcesz skończyć, to możliwość ściągnięcia repozytorium przy każdej pojedynczej wersji i wykonania kompilacji. Zmieniłeś się z libfoona libbar? Mam nadzieję, że zmiana obejmuje również aktualizację skryptów kompilacji i plików Makefile (lub cokolwiek innego, co ma zastosowanie).

Czasami może być konieczne wprowadzenie szeregu eksperymentalnych zmian, które dokonają jednej rzeczy, w takim przypadku musisz określić, który zakres jest dla Ciebie ważniejszy, jeśli chcesz później przywrócić. Czy jedno zależy od drugiego? Zatwierdź je wszystkie naraz w jednej wersji. W przeciwnym razie w takim przypadku sugerowałbym jeden zatwierdzenie na zmianę. Powinieneś robić coś takiego w innej gałęzi lub w innym repozytorium.

Chociaż tak, możesz przywrócić pojedynczy plik do poprzedniej wersji (w ten sposób utworzyć kopię zapasową jednego pliku z większego zaangażowania), robiąc to naprawdę psuje narzędzia, takie jak bisection później, i zanieczyszcza historię.

Jeśli zatrzymasz się i pomyślisz „Ok, testy zdają pomyślnie, myślę, że to działa… ale jeśli pójdzie źle, czy mogę to łatwo wycofać?” .. skończysz na rozsądnych zobowiązaniach.

Chodzi tutaj o to, że „Large” w tym kontekście dotyczy liczby wyraźnych zmian, a nie fizycznego rozmiaru zatwierdzenia (chociaż ogólnie oba idą w parze).

Nie chodzi o to, by „nie dokonywać dużych zobowiązań”, jak robić małe zobowiązania - idealna istota do dokonywania małych samodzielnych zmian.

Z dziennika zmian wynika, że ​​masz szereg rzeczy, które można było popełnić osobno (i bezpiecznie), a zatem jest dość oczywiste, że jest za duży.

Przyczyną tego może być to, że ostatnie zatwierdzenie jest punktem odniesienia dla wprowadzanych zmian, a jeśli na przykład pierwszy bit jest poprawny, a następny źle, nie ma łatwego sposobu przywrócić pracę do punktu, w którym zacząłeś popełniać błędy (BTDTGTTS).

Oczywiście czasami zmiany są po prostu duże - refaktoryzacja na dużą skalę - i jak sugerują inni, tutaj trzeba rozgałęzić, w ten sposób, chociaż twoje indywidualne zatwierdzenia mogą teoretycznie zniszczyć rzeczy, które są oddzielone od głównego pnia rozwoju, więc nie problem, a będziesz mógł nadal popełniać wcześnie i często.

Jeszcze jedno - jeśli coś pojawia się w trakcie pracy, co wymaga bardziej natychmiastowej uwagi, musisz to zmienić osobno (najlepiej w całkowicie odrębnym zestawie folderów) i zatwierdzić osobno.

Prawdziwym wyzwaniem w tym wszystkim nie jest sposób myślenia - że zatwierdzenie to nie tylko kopia zapasowa, którą tworzysz od czasu do czasu, ale że każde zatwierdzenie jest po calu kamykiem i że nie ma nic złego w wielu losach małych zatwierdzeń i to, że mungowanie różnych rzeczy razem w mob-mowie jest równie złe, jak mungowanie niejasno powiązanych ze sobą kawałków funkcjonalności razem w kawałku kodu.

Przynajmniej wytrenuj się, by popełniać, kiedy tylko pomyślisz: „Jak dotąd podoba mi się mój postęp i nie chcę go stracić, jeśli zmiany, które zamierzam wprowadzić, są katastrofą”. Następnie masz możliwość skorzystania z VCS, aby wysadzić wszelkie ślepe zaułki, które próbowałeś lub specjalny kod debugowania dodany w celu wyśledzenia problemu. (np. z git reset --hardlub rm -rf *; svn update)

Nie ma twardej i szybkiej reguły, żadnej linii podziału, za którą twoje zatwierdzenie jest zbyt duże.

Nie jest jednak wskazówką, że mniejsze rewizje są lepsze, w granicach rozsądku (tzn popełnienia każdy wiersz jest probaby nadmierne).

Pamiętam o tych wskazówkach:

• Pojedyncze zatwierdzenie powinno zawierać zmiany tylko dla jednej poprawki błędu
• Jedno zatwierdzenie nie powinno obejmować więcej niż pół dnia pracy
• Pojedyncze zatwierdzenie nie powinno przerwać kompilacji

Oczywiście - o tym pamiętam - YMMV. Różni programiści preferują różne poziomy szczegółowości.

Im mniejszy jest zatwierdzenie, tym łatwiej będzie znaleźć dokładnie to, skąd pochodzi potencjalna regresja.

Idealnie zatwierdzenie powinno być atomowe , w sensie najmniejszej spójnej zmiany podstawy kodu (związane z błędem, cechą itp.).

Jeśli chodzi o konkretne wskazówki, aby zachować niewielki rozmiar zatwierdzania, zależy to w dużej mierze od twojego VCS i jego konfiguracji: musisz być w stanie zatwierdzić lokalnie lub pracować we własnym oddziale na serwerze.

Kluczem jest zaangażowanie się w swój „prywatny” oddział za każdym razem, gdy dokonujesz zmiany atomowej, a następnie możesz regularnie łączyć swój oddział, na przykład co tydzień.

Za pomocą dvcs Twój przepływ pracy może wyglądać następująco:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Korzystanie ze scentralizowanego vcs:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Prawdopodobnie słyszałeś powiedzenie, że doskonałość ma miejsce wtedy, gdy nie możesz już nic więcej zabrać. To powinno również opisać Twój standard zatwierdzania.

To zależy od twojego projektu, gdzie jest ten „idealny” rozmiar. Jeśli wysyłasz do klientów zewnętrznych, dobry rozmiar może być najmniejszym przyrostem, który byłby wygodny, gdyby nie dokończyć następnego na czas. Jeśli budujesz wewnętrzne, często wdrażane aplikacje, najlepszym rozmiarem może być najmniejszy przyrost, który niczego nie psuje (i przybliża Cię do miejsca, w którym chcesz się znaleźć).

Nowoczesne systemy kontroli wersji pomagają tworzyć dobre zatwierdzenia dzięki łatwemu rozgałęzianiu, interaktywnemu bazowaniu, obszarowi przemieszczania itp.

Komunikaty zatwierdzania powinny składać się tylko z jednej linii (i dla git maksymalnie 60 znaków). Ilość przekazywanego kodu musi być wystarczająco mała, aby utrzymać opisowy komunikat w tym limicie.

Mam skłonność do popełniania za każdym razem (tym bardziej, że teraz przeszliśmy na git) Mam już kawałek, ponieważ pozwala uchwycić „dlaczego” rzeczy zostały zrobione w ten sposób.

Czasami pracujesz cały dzień nad kilkoma różnymi logicznie odmiennymi chagnes i zapomniałeś poświecić swój kod pomiędzy. Używanie git citoolmoże być bardzo pomocne w podziale pracy na ładne kawałki wielkości kęsa pod koniec dnia, nawet jeśli nie byłeś tak ostrożny w ciągu dnia podczas pracy.

git citool pozwala ci wybrać, które konkretne fragmenty pliku (lub które wiersze) zatwierdzić w konkretnym zatwierdzeniu, dzięki czemu możesz rozbić (nie nakładające się) zmiany dokonane w tym samym pliku na kilka zatwierdzeń.

(Wygląda na to, że używasz Subversion. Nie znam narzędzia, które robi to dla Subversion, ale możesz rozważyć użycie git-svnadaptera Subversion dla git, który zmieni twoje życie.)

Im większe zatwierdzenie, tym większe prawdopodobieństwo, że złamiesz kompilację i zostaniesz wypłacony przez resztę twojego zespołu. Próbuję zatwierdzić zmiany dwa razy dziennie. Tuż przed lunchem i przed powrotem do domu. Więc o 12.00 i 16.30 staram się, żeby wszystko działało i było gotowe do zatwierdzenia. Uważam, że ta praktyka działa dla mnie.

Aby odpowiedzieć na pytania:

1) Dla mnie standardowe zatwierdzenie jest uważane za duże, jeśli robi więcej niż jedną rzecz. Rozumiem przez to naprawienie błędu lub dodanie funkcji.

2) Zapobiegaj takim zobowiązaniom, nadając im przyzwyczajenie i zasadę, gdy tylko coś skończysz.

3) Na pół-wczesnych etapach rozwoju zezwalam, aby zatwierdzenia obejmowały pierwsze tworzenie plików, które zostaną wykorzystane później.

Chciałbym zauważyć, że po skończeniu mam na myśli, że wszystkie błędy, które można zidentyfikować, zostały naprawione i nie złamiesz kompilacji przez zatwierdzenie.

Tak, generuje to dużą liczbę zatwierdzeń, ale pozwala cofnąć dokładnie to, co się zepsuło, zamiast cofać dużą serię zmian, które zostały popełnione w tym samym czasie, gdy tylko jedna ze zmian powoduje problem.

Chciałbym również zauważyć, że zasady nieco się zmieniają w przypadku rozproszonych systemów kontroli wersji (DVCS), takich jak Mercurial i Git. W przypadku korzystania z jednego z nich, zatwierdzasz za każdym razem, gdy dokonałeś zmiany, ale jeszcze jej nie przetestowałeś, a następnie przesuwasz się do centralnego repozytorium, gdy działa. Jest to preferowane, ponieważ pozwala zweryfikować więcej zmian w kodzie bez obawy o uszkodzenie kompilacji.

W moim przypadku próbuję zatwierdzić pliki serwera do systemu repozytorium (SVN). To jest początkowe zatwierdzenie i nie chcę go pobierać, ponieważ jest to naprawdę duży projekt (kilka GB) i chcę wykonać wstępne zatwierdzenie z serwera klienta.

Problem polega na tym, że klient jest na serwerze współdzielonym, klient svn zostaje zabity (lub jakiekolwiek inne oprogramowanie), jeśli działa dłużej niż minutę.

Jedną z możliwości byłoby pobranie projektu na mój komputer i wykonanie początkowego zatwierdzenia stamtąd, ale jestem zainteresowany, aby wiedzieć, czy w SVN istnieje opcja podzielenia dużego zatwierdzenia na więcej, coś podobnego do metod transakcyjnych.

Deweloper przede mną nigdy nie używał systemu kontroli wersji.

Firma, dla której pracuję, wymusza weryfikację kodu równorzędnego dla każdego zatwierdzenia. Dlatego każde zatwierdzenie, które utrudnia rówieśnikowi ustalenie, co się dzieje i dokonanie przeglądu w rozsądnym czasie, jest zbyt duże.