Docelowi odbiorcy
  • Inżynierowie oprogramowanie pracujący z Git, którzy używają "patch stacks"/"stacked diffs", na przykład w jaki sposób Git jest używany w projektach Git i Linux, a także w wielu firmach wprowadzających "trunk-based development".
  • Nie użytkownicy Git, który uważają, że graf zatwierdzeń Git powinien odzwierciedlać rzeczywisty proces rozwijania.
Pochodzenie Moja praca nad git-branchless.
Nastrój Prawdopodobnie niezważany.
Język Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

Spis treści:

Pewna kategoria programistów używa Git z przypływem pracy “patch stack”, na którym zbierają ciąg małych, indywidualnie przeglądanych zatwierdzeń, które razem realizują znaczną zmianę. W takich przykładach, często przydatne jest uruchamianie linters lub formatters na każdym zatwierdzeniu w stosie i zastosowanie wyników. Może to być jednak żmudne, a naiwne podejście może powodować niepotrzebne konflikty scalania. (Jednym z obejść jest zastosowanie formatter na każdym zatwierdzeniu w stosie wstecz.)

Komenda git test z git-branchless przedstawia rozwiązanie do szybkiego uruchamiania formatters, itd., na całym stosie zatwierdzeń bez produkowania konfliktów scalania. Dodatkowo, może to zostać wykonywany równoległe, i zapisuje wyniki, żeby ponowne formatowania tego samego zatwierdzenia zostawił pominięte. Możesz zobaczyć post z ogłoszeniem lub dokumentację git test.

Oto demonstracja formatowania zatwierdzeń w stosie (przewiń do 0:35, aby zobaczyć tylko demonstrację git test fix):

Ja zwykle ustawiam git fmt na alias na coś takiego

git test run --exec 'cargo fmt --all' --strategy worktree --jobs 8

Powiązane posty

Poniżej znajduje się kilka ręcznie wybranych postów, które mogą Cię zainteresować.

Date Title
11 Apr 2023 (this post) Szybkie formatowanie stosu zatwierdzeń

Chcesz zobaczyć więcej moich postów? Obserwuj mnie na Twitterze albo subskrybuj za pomocą RSS.

Komentarze