Rebase om je branch te verversen

Ik zit in een paar softwareteams en we committen heel vaak code naar onze main branch. In mijn teams hebben we meestal geen develop branch en zelfs geen releasecycli. We releasen gewoon regelmatig.

Dit is bij grote bedrijven niet gebruikelijk, maar bij wendbare softwarebedrijven is het heel normaal.

De vraag is: hoe doe je dat zonder elkaar op de tenen te trappen?

Git

Het draait om git en agile. De tool waarmee we versiebeheer doen en een stukje van de mentaliteit achter onze projectaanpak.

Git is gewoon een manier om verschillen tussen kopieën te vinden. Als de productiekopie A bevat, Joe aan B werkt en Sally aan C, kan Git de verschillen uitrekenen en de kopieën zonder conflict samenvoegen.

Lastig wordt het als werk lang duurt en bijdragen op verschillende momenten worden gecommit.

Dan komt rebase om de hoek kijken. git rebase origin/main zorgt ervoor dat mijn werk, het werk dat vanaf main is vertakt, up-to-date is met alles wat mijn collega’s hebben bijgedragen. Het is de juiste manier en het scheelt later herwerk als er conflicten opduiken. Zo weet ik zeker dat mijn werk actueel is voordat het in de main branch gaat. De bron van waarheid.

Flow

Veel teams houden zich aan git-flow. Atlassian heeft het heel goed beschreven, dus daar hoef ik niets aan toe te voegen.

Maar ik vind het niet perfect.

In software engineering zetten we soms automatisering op de processen die ons dierbaar zijn, om productiever te worden. Dat werkt goed, maar het heeft eigen tekortkomingen.

Een feature branch is bijvoorbeeld een goede manier om een specifieke feature te testen, dus elke commit kan een soort deployment starten om te laten zien wat een nieuwe functie kan.

Het onvolmaakte gevolg is dat de feature branch een geautomatiseerd proces start om die demonstratiefeature uit te rollen.

Dat is duur en onbevredigend.

Work branches

Een simpele aanpak die ik in mijn team invoer zijn work/* branches. Het idee lijkt op feature branches, maar ze hebben een eigen naamruimte zodat de geautomatiseerde processen ze negeren.

Work branches beginnen met work/ en zijn expliciet uitgesloten van geautomatiseerde pipelines. Ze zijn bedoeld als de “Auto Save” van versiebeheer.

Ik moedig mijn teams actief aan om vooral in hun work/* branch te werken en features pas naar hun feature/* branch te mergen als ze willen dat er een pipeline draait.

Tot slot

Ik geef toe dat ik dit pas kort in mijn teams toepas. Ondanks de extra moeite om feature/* en work/* branches uit elkaar te houden lijkt het goed te werken.

Ik zie ook dat block steps een goede manier zijn om onnodige deployments en onnodige builds te verminderen. Daarmee bereik je vergelijkbare dingen, maar ze zijn helaas niet beschikbaar in de omgevingen waarin ik werk.

Ik hoor graag feedback en misschien suggesties voor nieuwe manieren van werken. Heb je ideeën, neem dan contact op.