GitHub 'stacked pull requests' പബ്ലിക് പ്രിവ്യൂവിലേക്ക് മാറ്റിയിരിക്കുന്നു. ഇതിലൂടെ വലിയ മാറ്റങ്ങളെ (changes) പരസ്പരം ആശ്രയിക്കുന്ന ഒരു പരമ്പരയായി (chain of dependent PRs) വിഭജിക്കാനും അവ ഓരോന്നും സ്വതന്ത്രമായി റിവ്യൂ ചെയ്യാനും മെർജ് ചെയ്യാനും ഡെവലപ്പർമാർക്ക് സാധിക്കും.

ഈ ഫീച്ചർ പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ഒരു വലിയ (monolithic) PR പലപ്പോഴും മാസങ്ങളോളം നീണ്ടുനിൽക്കുന്ന റിവ്യൂവായി മാറുകയും, റിവ്യൂവർമാർക്ക് അനാവശ്യമായ കോഡുകൾ പരിശോധിക്കേണ്ടി വരികയും ചെയ്യുന്നു. ബേസ് ബ്രാഞ്ച് (base branch) മാറുന്നതിനനുസരിച്ച്, ഇത്തരം വലിയ മാറ്റങ്ങളിൽ മെർജ് കോൺഫ്ലിക്റ്റുകൾ (merge conflicts) ഉണ്ടാകാനും അത് റിലീസുകളെ തടസ്സപ്പെടുത്താനും സാധ്യതയുണ്ട്. ഒരു വലിയ ഡിഫിനെ (diff) ചെറിയതും കൃത്യവുമായ ഡിഫുകളുടെ പരമ്പരയാക്കി മാറ്റുന്നതിലൂടെ, ഓരോന്നും തൊട്ടുമുമ്പുള്ളതിനെ അടിസ്ഥാനമാക്കി നിർമ്മിക്കപ്പെടുന്നു. ഇത് മേൽപ്പറഞ്ഞ രണ്ട് പ്രശ്നങ്ങളും പരിഹരിക്കുന്നു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു

ആദ്യം മെയിൻ ബ്രാഞ്ചിന് (main branch) എതിരെ ഒരു PR ക്രിയേറ്റ് ചെയ്യുക, തുടർന്ന് അടുത്ത PR ആദ്യത്തേതിനെയും, മൂന്നാമത്തേത് രണ്ടാമത്തേതിനെയും അടിസ്ഥാനമാക്കി നിർമ്മിക്കുക. GitHub ഈ ബന്ധങ്ങൾ സ്വയമേവ ട്രാക്ക് ചെയ്യുന്നു: നിങ്ങൾ ബേസ് PR പരിഷ്കരിച്ചാൽ (amend), അതിനെ ആശ്രയിച്ചിരിക്കുന്ന PR-കൾ പുതിയ മാറ്റങ്ങൾക്കനുസരിച്ച് അപ്ഡേറ്റ് ചെയ്യപ്പെടും. റിവ്യൂവർമാർക്ക് മുഴുവൻ സ്റ്റാക്കിനെയും (stack) ഒറ്റ ക്ലിക്കിലൂടെ അപ്രൂവ് ചെയ്യാനോ അല്ലെങ്കിൽ ഓരോ ലെയറുകളും പ്രത്യേകം പരിശോധിക്കാനോ സാധിക്കും.

  • റിവ്യൂകൾ പരിമിതമായ പരിധിയിൽ നിൽക്കുന്നതിനാൽ ഫീഡ്‌ബാക്ക് വേഗത്തിലാകുന്നു.
  • ഓരോ PR-ഉം അതിന്റെ സ്വന്തം ലെയറിലെ കോഡുകളിൽ മാത്രം മാറ്റം വരുത്തുന്നതിനാൽ കോൺഫ്ലിക്റ്റുകൾ കുറയുന്നു.
  • UI സ്റ്റാക്ക് ഹൈരാർക്കി (stack hierarchy) കാണിക്കുന്നുണ്ട്, കൂടാതെ സ്റ്റാക്ക്ഡ് PR-കളുടെ ഒരു പരമ്പര വേഗത്തിൽ തുടങ്ങാൻ GitHub CLI ഒരു വൺ-ലൈനർ കമാൻഡ് നൽകുന്നു.
gh pr create --title Feature A --base main
gh pr create --title Feature B --base feature-a
gh pr create --title Feature C --base feature-b

കമാൻഡ് ലൈൻ ഉദാഹരണം മൂന്ന് ലിങ്ക്ഡ് PR-കൾ നിർമ്മിക്കുന്നു, ഇതിൽ ഓരോന്നും തൊട്ടുമുമ്പുള്ളതിനെ ആശ്രയിച്ചിരിക്കുന്നു. വെബ് ഇന്റർഫേസിലൂടെയും ഇതേ വർക്ക്ഫ്ലോ ലഭ്യമാണ്; അവിടെ മറ്റുള്ളവയെ ബാധിക്കാതെ തന്നെ നിങ്ങൾക്ക് ഒരു PR സ്റ്റാക്കിൽ നിന്ന് മാറ്റാനോ ക്രമീകരിക്കാനോ സാധിക്കും.

ആർക്കൊക്കെ ഇതിന്റെ പ്രയോജനം ലഭിക്കും

വലിയ ഫീച്ചർ ടീമുകൾക്കും ഓപ്പൺ സോഴ്സ് മെയിന്റൈനർമാർക്കും അനാവശ്യമായ കോഡ് മാറ്റങ്ങൾ റിവ്യൂവർമാർക്ക് മുന്നിൽ വെക്കാതെ തന്നെ ഘട്ടം ഘട്ടമായുള്ള ജോലികൾ പൂർത്തിയാക്കാൻ സാധിക്കും. ഓരോ സ്റ്റാക്ക് ലെയറും അവയുടെ സ്വന്തം ഷെഡ്യൂളിൽ മെർജ് ചെയ്യാൻ കഴിയുന്നതിനാൽ, എന്തൊക്കെ റിലീസ് ചെയ്യാൻ തയ്യാറാണെന്നതിനെക്കുറിച്ച് റിലീസ് മാനേജർമാർക്ക് വ്യക്തമായ ചിത്രം ലഭിക്കുന്നു.

ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

ഈ ഫീച്ചർ ഇപ്പോഴും പ്രിവ്യൂ ഘട്ടത്തിലായതിനാൽ, പൂർണ്ണമായ റിലീസിന് മുമ്പ് ഇതിൽ മാറ്റങ്ങൾ വരാം. ബ്രാഞ്ചിംഗുമായി (branching) ബന്ധപ്പെട്ട് ടീമുകൾ പുതിയ രീതികൾ സ്വീകരിക്കേണ്ടി വരും, കൂടാതെ ഭാഗികമായി മെർജ് ചെയ്ത ഒരു സ്റ്റാക്ക് റീബേസ് (rebase) ചെയ്യുമ്പോൾ ചില സങ്കീർണ്ണമായ സാഹചര്യങ്ങൾ (edge cases) നേരിടേണ്ടി വന്നേക്കാം. ഡോക്യുമെന്റേഷൻ ഇപ്പോഴും വികസിച്ചുകൊണ്ടിരിക്കുകയാണ്, അതിനാൽ തുടക്കക്കാർക്ക് UI മനസ്സിലാക്കാൻ കൂടുതൽ സമയം ചിലവഴിക്കേണ്ടി വന്നേക്കാം.

ഇനി എന്താണ് പ്രതീക്ഷിക്കേണ്ടത്

കോഡ്-ഓണേഴ്സുമായി (code-owners) കൂടുതൽ മെച്ചപ്പെട്ട സംയോജനവും ഓട്ടോമേഷൻ ടൂളുകളും GitHub കൊണ്ടുവന്നേക്കാം, കൂടാതെ കോൺഫ്ലിക്റ്റുകൾ കുറയുന്നതിനെക്കുറിച്ചുള്ള മെട്രിക്സുകളും ലഭ്യമായേക്കാം. GA (general availability) സമയത്തെക്കുറിച്ചുള്ള അപ്ഡേറ്റുകൾക്കായി പ്രിവ്യൂ അനൗൺസ്‌മെന്റ് പേജ് ശ്രദ്ധിക്കുക.

ചുരുക്കത്തിൽ: വലിയ മാറ്റങ്ങളെ നിയന്ത്രിക്കാൻ ഡെവലപ്പർമാർക്ക് പ്രായോഗികമായ ഒരു മാർഗമാണ് സ്റ്റാക്ക്ഡ് പുൾ റിക്വസ്റ്റുകൾ (stacked pull requests). ഇത് കോൺഫ്ലിക്റ്റുകൾ നിറഞ്ഞ ഒരു വലിയ PR-നെ എളുപ്പത്തിൽ റിവ്യൂ ചെയ്യാവുന്ന ഒരു പരമ്പരയാക്കി മാറ്റുന്നു. നിങ്ങളുടെ വർക്ക്ഫ്ലോയിൽ നീണ്ട റിവ്യൂകളും മെർജ് പ്രശ്നങ്ങളും ഉണ്ടെങ്കിൽ, ഈ പ്രിവ്യൂ പരീക്ഷിച്ചു നോക്കുന്നത് നന്നായിരിക്കും.