Mi a legjobb eljárás a kód felülvizsgálatára a GIT használatakor? Van egy külső GIT-szolgáltatónk (Unfuddle), és korlátozott az erőforrás-felhasználás – így nem állíthatunk be külön távoli adattárakat minden fejlesztőhöz.

Aktuális folyamat:

  • Mi rendelkezzen GIT-kiszolgálóval egy master ággal, amelyre mindenki elkötelezi magát
  • A Dev-ek a helyi master tükröt vagy egy helyi szolgáltatáság
  • A Devs a kiszolgáló “s master elágazása
  • A Devs kódellenőrzést kér a legutóbbi elkötelezettségről

Probléma:

  • Bármelyik hiba a kódellenőrzésben már a masterben van, mire elkapja.
  • Rosszabb, hogy általában valaki néhány órát égett rájönni, mi történt …

Tehát szeretnénk

  • Kódellenőrzést végezni a „master” -be történő átadás előtt.
  • Legyen olyan folyamata, amely globális csapattal működik (nincsenek vállon áttekintve vélemények!)
  • olyasmi, amelyhez nincs szükség arra, hogy az egyes fejlesztők az asztalánál / gépénél legyenek be kell kapcsolni, hogy valaki más távoli legyen n (távolítsa el az emberi függőséget, a dev-ek különböző időzónákon mennek haza)

A TortoiseGIT-et a megváltoztatott fájlok, diff “fájlok stb. listájának vizuális ábrázolásához használjuk. Néhányan belépünk egy A GIT shell, ha a grafikus felület nem elég, de ideális esetben azt szeretnénk, ha a munkafolyamat egyszerű és GUI alapú lenne (azt akarom, hogy az eszköz minden terhet felemeljen, ne a fejlesztőim).

Megjegyzések

  • Egységes tesztet végez, mielőtt elkezdené?
  • @GuyCoder: Többnyire mi.
  • Ha a host nem nyújt kódellenőrzést jobb gazdát. Vessen egy pillantást Gerritre, és hátha talál egy gazdagépet, amely biztosítja.

Válasz

A egyszerű, de hatékony modell a GitHub pull request modell, ahol a közreműködők fájlja “kérjük, olvassa el az én kódomat” kéréseket. A karbantartó áttekinti a változtatásokat, és eldönti, hogy további munkára van-e szükségük, vagy alkalmasak-e az egyesítésre. Ezután beolvadhat a mesterágba. Az elkövetők általában nem léphetnek közvetlenül a fő ágba (ezt az Ön ízlésének megfelelően alakíthatjuk ki, lehetővé tesszük, hogy a “kisebb” elkötelezettségek közvetlenül belemennek).

Megjegyzések

  • Világszerte 7 profi fejlesztőnkből áll (anonim közreműködőkkel), így biztonságosan engedjük, hogy mindegyik közvetlenül a távoli mesterünkhöz nyomuljon. Bár ' ez egy link + intro vs önálló válaszok, amelyeket jobban szeretek, ebben az esetben van értelme. Remek írás a linken, köszönöm!
  • @Sid 3 fős csapattal nem engedném ', hogy mindnyájukat elsajátítsák.
  • A lekérési kérelmek elérhetők a Rhodecode és az Atlassian Stash
  • @Andrew: Miért ne? Sok probléma merülhet fel azzal, ha az egész csapatok fojtó ponton keresztül működnek. Ezek mindegyike mérsékelhető, de az egypontos parancs- és vezérlőstruktúra alkalmasabb bizonyos helyzetekhez, mint mások.

Válasz

A Git egy elosztott verzióvezérlő rendszer: Csak egy repóval rendelkezzen egy ággal!

Több tárhelyet is beállíthat – mindegyik fejlesztőhöz – és egy másik, amely a fő repó. Amikor az egyik águk készen áll az egyesítésre, a fejlesztő egyesítést kér, és módosításaik az águkból / repóikból a masterbe kerülnek.

Mielőtt az összevonás valóban megtörténne, az ellenőr át tudja vonni a változásokat

További előnye, hogy így egy fejlesztőnek annyi ága lehet, amennyit csak akar, megnevezhet bármit, amit csak akar, anélkül, hogy egymásba avatkozna, vagy akár ennyit látni egymás piszkos mosodájából.


Ismerje meg a nyelvet is: a „Devs elkötelezi magát a szerver fő ágának” alatt azt érted, hogy push a változtatásokat, hogy elsajátítsák őket?

Megjegyzések

  • igen, ők push a munkájuk. ' Nem rendelkezhetünk egyedi távoli adattárakkal a GIT-kiszolgálón, mert fizetünk egy GIT-tárhelyet, és azok táronként fizetnek. Arra gondolt, hogy fejlesztőnként több távoli fiókja van? És amikor azt mondod, hogy the reviewer can pull the changes into their environment milyen pontos GIT parancsokra (vagy TortoiseGIT folyamatra) gondolsz?
  • nem, úgy értem, hogy több tárolójuk van; Fejlesztőnként egy, és ezen a táron annyi ága lehet, amennyit csak akar. Ami a pull -t illeti, nem tudom ', hogy mi lenne a parancs a TortoiseGIT-ben – de a parancs git pull . ' a lökés ellentéte – a távoli adattárból változtatásokat hajt végre, hogy frissítse a környezetét olyan munkával, amelyet más fejlesztők is elvégezhettek.
  • Tudom, git pull 🙂 …A teljes szintaxist kértem, hogy megvizsgáljam a repo / branch / tag rendszert az Ön által hivatkozott lökések / húzások szempontjából. Most úgyis git pull t csinálunk, ez ' csak a távirányítóról: mester – ami a problémákat okozza. Egyébként Steven ' linkjei remekek voltak. Köszönet
  • Ebben az esetben minden gyakorlati célból egy fiók a tárolt repóban megegyezik egy másik repóval.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük