Puncte:1

Git branching strategies with a small team to develop a Drupal site

drapel in

We're a small team (5-6 developers) building a Drupal 7 site. Previously, we've used Features (https://www.drupal.org/project/features) to export our configurations from development to production. We've relied largely on assigning developers discrete, unrelated tasks.

Our upcoming work has distinct, but related development. For example, I anticipate we'll need to add fields that will be used by two different tasks (for example, think about a date field for an event. One developer is working on the email invite and the other is working on the event display page). If we are able to anticipate this overlap, we'd be able to do this before either starts work.

However, if we don't realize a common need until after work has begun in separate branches per developer/feature, this becomes trickier. I believe that we would need to merge their branches together to access the common code-which defeats the point of us having separate branches in the first place.

Curious for what you'd suggest or has worked well in the past! Thanks!

Note: I've identified these potential solutions, both with drawbacks:

  • Cherry pick commits. While this could be helpful, it's also likely that a cherry-picked commit will include extraneous changes beyond the narrow scope needed here. And it's just as likely that the single commit won't include all of the changes necessary (For example, if one commit created the feature, and a second created the field, you'd need to cherry pick both commits). This all seems to head for a merge headache down the road.

  • Create a folder within sites/all/features/ignore, manually transfer the needed features there from the other branch. Include this directory in .gitignore. I don't like that:

  1. This has our team sending features files all over outside of git,
  2. That it could introduce dependency errors if features are changed in the original, but not updated in the other places that they are used,
  3. That users may make changes to the ignored features that aren't moved into git,
  4. That switching between computers/development environments would lose these files
  5. That all related branches would need to be merged before deploying to production (which again, undermines the point of branching since these branches are now dependent on each other and would have to be released at once, rather than when ready/needed).
  • Another option is to make the change (export the feature needed or cherry-pick commits) to the parent branch (e.g., Develop or Develop-Feature) so that it's available to all child branches.
Jaypan avatar
drapel de
Acesta nu este răspunsul pe care îl căutați, dar cu toată sinceritatea, nu aș sugera să începeți un nou site pe Drupal 7 în acest moment. EOL este noiembrie 2022, doar un an și ceva de acum înainte. După aceea, Drupal 7 nu va mai primi actualizări de securitate, iar upgrade-ul de la D7 -> D8 NU este ușor. În plus, API-ul de gestionare a configurației din D8 este mai ușor decât Caracteristicile D7 (https://www.morpht.com/blog/drupal-8-configuration-part-1-configuration-api). Aș recomanda să începeți site-uri noi în D9. Majoritatea fiecărui modul a fost deja actualizat de la D8 -> D9, deoarece procesul de actualizare este semnificativ mai ușor.
Grayson Cooper avatar
drapel in
Scuze că nu am lămurit! Acesta nu este un site nou. Am început site-uri noi în D9 și sunt de acord că este mult mai ușor/mai frumos și, deși D9 poate face 99% din ceea ce avem nevoie, 1% este destul de cheie (în mare parte legate de reguli). Construim lucrurile într-un mod prietenos cu D9 pentru a atenua durerile de migrare, încercând, de asemenea, să dezvoltăm anumite abilități în echipa noastră pentru a fi confortabil cu D9 (inclusiv, de exemplu, trecerea la git). Îmi imaginez că această întrebare încă se aplică site-urilor D9 (în afara caracteristicilor) și pare că cherry picking commits este abordarea ideală.
leymannx avatar
drapel ne
Luați în considerare compunerea site-ului pentru a gestiona contribuția și core. Oferiți o modalitate prin care dezvoltatorii pot sincroniza cu ușurință cel mai recent Live DB pe site-ul lor local. De fiecare dată când un dezvoltator începe o nouă ramură de caracteristici (sau schimbă ramuri) sau se dezvoltă într-o ramură de caracteristici existente, acesta sincronizează cel mai recent Live DB pe site-ul local și trebuie să ruleze `composer install`, `drush updb` și `drush fra` . Păstrați ramurile caracteristice mici, toată lumea trebuie să furnizeze o solicitare de îmbinare/extragere cu o stare stabilă până la sfârșitul unei zile lucrătoare. Ignorați fișierele de compilare front-end din depozit. Lasă asta în seama CI.
leymannx avatar
drapel ne
Faceți scripturile Composer, comenzile Drush personalizate, variable_get/_set() și hook_update_N() cei mai buni prieteni.
Kevin avatar
drapel in
Nu mă pot gândi la necesitatea regulilor ca un blocant pentru upgrade. Probabil că puteți recrea multe dintre aceste reguli în câteva rânduri de cod/Evenimente sau puteți utiliza reguli de afaceri.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.