/ / Dlaczego programiści Git Commit, Git Pull, Git Push zawsze tworzą Git Merge? - git, github, scalanie

Dlaczego programista Git Commit, Git Pull, Git Push zawsze tworzą Git Merge? - git, github, scalanie

Mam programistę, który wciąż się sprawdza, i za każdym razem - robi git scala gałąź z zatwierdzeniem gałęzi; każdego razu. Nawet z własnym kodem.

Tj. Moja historia tak wygląda prawie cały czas. Czasami jeden z moich 6 deweloperów połączy gałąź z gałęzią; ale w większości mają po prostu zobowiązania. Ten jeden twórca zawsze go ma.

  • Dev Scal gałąź do gałęzi
  • Dev Commit
  • Dev Scal gałąź do Oddziału
  • Dev Commit
  • Inne zobowiązanie
  • Me Commit
  • Inne zobowiązanie
  • Me Commit
  • Me Commit
  • Dev Merge Branch na Branch
  • Dev Commit
  • Dev Scal gałąź do gałęzi
  • Dev Comm

Był w biegu 1.7; teraz 2.0

  • git commit
  • git pull
  • git push

? Jakieś pomysły?

Reszta z nas ma się dobrze w terminalu (Mac); Wygrana GH; GH wygrywa PowerShell itp.

Jest to denerwujące, ponieważ połączenia śmieci powodują ból, aby móc się cofnąć.

Odpowiedzi:

1 dla odpowiedzi № 1

Poinstruuj dewelopera, aby dokonał świeżych zatwierdzeń dopiero po wykonaniu pociągnięcia.

git tworzy zatwierdzenia scalania tylko wtedy, gdy gałąź lokalna i gałąź nadrzędna odbiegają od wspólnego punktu. Tak więc, podczas gdy reszta deweloperów wydaje się podążać za tym (tzn. Robią to git pull przed dokonaniem jakichkolwiek zatwierdzeń), dany deweloper dokonuje lokalnych zatwierdzeń, a następnie wykonuje polecenie git pull, dlatego też gałęzie są już rozbieżne. Dlatego git jest zmuszony do rekurencyjnego scalania zmian, powodując pojawienie się zatwierdzenia scalania.

Innym sposobem uniknięcia tego całkowicie jest zrobienie git fetch w połączeniu z git rebase w całej organizacji, dzięki czemu historia jest utrzymywana prawie liniowo, bez konieczności łączenia.