Git
Analysera typer av arbetsflöden

Anmärkningar

Gitflow-arbetsflöde

Ursprungligen föreslagen av Vincent Driessen , Gitflow är ett utvecklingsarbetsflöde med Git och flera fördefinierade grenar. Detta kan ses som ett speciellt fall för Feature Branch Workflow .

Idén med den här är att ha separata grenar reserverade för specifika delar under utveckling:

• master branch är alltid den senaste produktionskoden . Experimentell kod tillhör inte här.
• develop grenen innehåller all den senaste utvecklingen . Dessa utvecklingsförändringar kan vara nästan vad som helst, men större funktioner är reserverade för sina egna grenar. Koden här bearbetas alltid och slås samman till release innan släpp / distribution.
• hotfix är för mindre bugfixar, som inte kan vänta till nästa utgåva. hotfix kommer från master och slås samman till både master och develop .
• release grenar används för att släppa ny utveckling från develop till master . Alla ändringar i sista minuten, till exempel stöta versionnummer, görs i släppgrenen och slås sedan samman till master och develop . När man installerar en ny version, ska master taggas med det aktuella versionnumret (t.ex. med semantisk versionering ) för framtida referens och enkel återuppspelning.
• feature är reserverade för större funktioner. Dessa är specifikt utvecklade i utsedda grenar och integreras med develop när de är färdiga. Dedikerade feature hjälper till att separera utvecklingen och kunna distribuera gjorda funktioner oberoende av varandra.

En visuell representation av denna modell:

Den ursprungliga representationen av denna modell:

Forking Workflow

Den här typen av arbetsflöde skiljer sig i grund och botten än de andra som nämns i detta ämne. Istället för att ha en central repo som alla utvecklare har tillgång till, har varje utvecklare sin egen repo som gaffas från huvudreporten. Fördelen med detta är att utvecklare kan lägga till sina egna repor snarare än en delad repo och en underhållare kan integrera ändringarna från gaffelrepos i originalet när så är lämpligt.

En visuell representation av detta arbetsflöde är som följer:

Centraliserat arbetsflöde

Med denna grundläggande arbetsflödesmodell innehåller en master all aktiv utveckling. Bidragsgivare måste vara särskilt säkra på att de drar de senaste ändringarna innan de fortsätter utvecklingen, för denna gren kommer att förändras snabbt. Alla har tillgång till denna repo och kan göra ändringar direkt till mastergrenen.

Visuell representation av denna modell:

Detta är det klassiska versionskontrollparadigmet, på vilket äldre system som Subversion och CVS byggdes. Programvaror som fungerar på detta sätt kallas centraliserade versionskontrollsystem, eller CVCS. Medan Git kan arbeta på det här sättet, finns det betydande nackdelar, såsom att krävas för att föregå varje drag med en sammanslagning. Det är mycket möjligt för ett team att arbeta på det här sättet, men den ständiga lösningen av konfliktkonflikter kan äta mycket värdefull tid.

Det är därför Linus Torvalds skapade Git inte som en CVCS, utan snarare som ett DVCS , eller distribuerat versionskontrollsystem , liknande Mercurial. Fördelen med detta nya sätt att göra saker är flexibiliteten som visas i de andra exemplen på denna sida.

Feature Branch Workflow

Grundidén bakom Feature Branch Workflow är att all funktionsutveckling ska ske i en dedicerad filial istället för master . Denna kapsling gör det enkelt för flera utvecklare att arbeta med en viss funktion utan att störa huvudkodbasen. Det innebär också att master grenen kommer aldrig att innehålla brutna kod, vilket är en stor fördel för miljöer kontinuerlig integration.

Inkapsling av funktionsutveckling gör det också möjligt att utnyttja dragförfrågningar, vilket är ett sätt att inleda diskussioner kring en gren. De ger andra utvecklare möjlighet att logga in på en funktion innan den integreras i det officiella projektet. Eller, om du fastnar i mitten av en funktion, kan du öppna en begäran om förfrågan och be om förslag från dina kollegor. Poängen är att dragförfrågningar gör det oerhört enkelt för ditt team att kommentera varandras arbete.

baserat på Atlassian Tutorials .

GitHub Flow

Populärt inom många open source-projekt men inte bara.

Master gren av en viss plats (Github, Gitlab, bitbucket, lokal server) innehåller den senaste shippable versionen. För varje ny funktion / bug fix / arkitektonisk förändring skapar varje utvecklare en gren.

Förändringar sker på den grenen och kan diskuteras i en pull-begäran, kodgranskning osv. När de väl godkänts slås de samman till mastergrenen.

Fullt flöde av Scott Chacon:

• Allt i mastergrenen är distribuerbar
• För att arbeta med något nytt skapar du en beskrivande gren utanför mästaren (dvs: new-oauth2-scopes)
• Åtag dig till den grenen lokalt och tryck regelbundet ditt arbete till samma namngivna gren på servern
• När du behöver feedback eller hjälp eller om du tror att filialen är redo att slås samman öppnar du en begäran om dragning
• När någon annan har granskat och loggat ut på funktionen kan du smälta den till master
• När den har släppts samman och pressats till "master" kan och bör du distribuera omedelbart

Ursprungligen presenterades på Scott Chacons personliga webbplats .

Bild med tillstånd av GitHub Flow-referensen