GitHub ਨੇ stacked pull requests ਨੂੰ public preview ਵਿੱਚ ਲਿਆ ਦਿੱਤਾ ਹੈ, ਜਿਸ ਨਾਲ developers ਇੱਕ ਵੱਡੇ ਬਦਲਾਅ ਨੂੰ ਨਿਰਭਰ PRs ਦੀ ਇੱਕ ਲੜੀ ਵਿੱਚ ਵੰਡ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ review ਅਤੇ merge ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਇਹ ਫੀਚਰ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਇੱਕ ਸਿੰਗਲ, monolithic PR ਅਕਸਰ ਇੱਕ ਮਹੀਨੇ ਦੇ ਲੰਬੇ review ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ reviewers ਨੂੰ ਬੇਲੋੜੇ ਕੋਡ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ। ਜਦੋਂ base branch ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਵੱਡੇ ਬਦਲਾਅਾਂ ਵਿੱਚ merge conflicts ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ ਜੋ releases ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹਨ। Stacked PRs ਇੱਕ ਵੱਡੇ diff ਨੂੰ ਛੋਟੇ, ਕੇਂਦ੍ਰਿਤ diffs ਦੀ ਇੱਕ ਲੜੀ ਵਿੱਚ ਬਦਲ ਕੇ ਇਹਨਾਂ ਦੋਵਾਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕਰਦੇ ਹਨ, ਜਿੱਥੇ ਹਰ ਇੱਕ ਪਿਛਲੇ ਵਾਲੇ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦਾ ਹੈ।

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਪਹਿਲਾਂ main branch ਦੇ ਵਿਰੁੱਧ ਪਹਿਲਾ PR ਬਣਾਓ, ਫਿਰ ਅਗਲੇ PR ਨੂੰ ਪਹਿਲੇ 'ਤੇ, ਤੀਜੇ ਨੂੰ ਦੂਜੇ 'ਤੇ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਅੱਗੇ ਅਧਾਰਤ ਕਰੋ। GitHub ਰਿਲੇਸ਼ਨਸ਼ਿਪਸ ਨੂੰ ਆਪਣੇ ਆਪ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ: ਜੇਕਰ ਤੁਸੀਂ base PR ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਵੇਂ ਸਟੇਟ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਨਿਰਭਰ PRs ਨੂੰ ਅਪਡੇਟ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। Reviewers ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਪੂਰੇ stack ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੇ ਹਨ ਜਾਂ ਵੱਖ-ਵੱਖ ਲੇਅਰਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਸਕਦੇ ਹਨ।

  • Reviews ਇੱਕ ਸੀਮਤ ਦਾਇਰੇ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ feedback ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦਾ ਹੈ।
  • Conflicts ਘਟ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ PR ਸਿਰਫ਼ ਆਪਣੀ ਲੇਅਰ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਕੋਡ ਨੂੰ ਹੀ ਛੂਹੰਦਾ ਹੈ।
  • UI stack hierarchy ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ GitHub CLI stacked PRs ਦੀ ਇੱਕ ਲੜੀ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ-ਲਾਈਨ ਵਾਲੀ command ਦਿੰਦਾ ਹੈ।
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

Command line ਉਦਾਹਰਨ ਤਿੰਨ ਲਿੰਕ ਕੀਤੇ PRs ਬਣਾਉਂਦੀ ਹੈ, ਜਿੱਥੇ ਹਰ ਇੱਕ ਆਪਣੇ ਤੋਂ ਪਹਿਲੇ PR 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। ਇਹੀ workflow web interface ਰਾਹੀਂ ਵੀ ਉਪਲਬਧ ਹੈ, ਜਿੱਥੇ ਤੁਸੀਂ ਦੂਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ stack ਵਿੱਚੋਂ ਕਿਸੇ PR ਨੂੰ ਦੁਬਾਰਾ ਵਿਵਸਥਿਤ (reorder) ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਹਟਾ ਸਕਦੇ ਹੋ।

ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ

ਵੱਡੀਆਂ feature teams ਅਤੇ open-source maintainers reviewers ਨੂੰ ਬੇਲੋੜੇ ਬਦਲਾਵਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹੋਏ ਕੰਮ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ (incrementally) ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹਨ। Release managers ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਸਪੱਸ਼ਟ ਜਾਣਕਾਰੀ ਮਿਲਦੀ ਹੈ ਕਿ ਕੀ ਸ਼ਿਪ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ, ਕਿਉਂਕਿ ਹਰ stack layer ਨੂੰ ਆਪਣੇ ਅਨੁਸਾਰ ਮਰਜ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਯੋਗ ਗੱਲਾਂ

ਇਹ ਫੀਚਰ ਅਜੇ preview ਵਿੱਚ ਹੈ, ਇਸ ਲਈ ਪੂਰੀ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਵਿੱਚ ਬਦਲਾਅ ਹੋ ਸਕਦੇ ਹਨ। Teams ਨੂੰ branching ਦੇ ਸਬੰਧ ਵਿੱਚ ਨਵੀਆਂ ਆਦਤਾਂ ਅਪਣਾਉਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਅਤੇ ਜਦੋਂ ਕਿਸੇ ਅਜਿਹੇ stack ਨੂੰ rebase ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਮਰਜ ਹੋ ਚੁੱਕਾ ਹੈ, ਤਾਂ edge cases ਆ ਸਕਦੇ ਹਨ। Documentation ਅਜੇ ਵੀ ਬਣ ਰਹੀ ਹੈ, ਇਸ ਲਈ ਸ਼ੁਰੂਆਤੀ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ UI cues ਸਿੱਖਣ ਵਿੱਚ ਵਾਧੂ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

GitHub ਸੰਭਵ ਤੌਰ 'ਤੇ code-owners ਅਤੇ automation tools ਨਾਲ ਬਿਹਤਰ ਇੱਕੀਕਰਨ (integration) ਲਿਆਵੇਗਾ, ਅਤੇ conflict ਘਟਾਉਣ ਦੇ metrics ਵੀ ਦਿਖਾ ਸਕਦਾ ਹੈ। GA (general availability) ਦੇ ਸਮੇਂ ਬਾਰੇ ਅਪਡੇਟਸ ਲਈ preview announcement page 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ।

ਸਿੱਖਿਆ (Takeaway): Stacked pull requests developers ਨੂੰ ਵੱਡੇ ਬਦਲਾਅਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਇੱਕ ਵਿਹਾਰਕ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ, ਜੋ ਇੱਕ ਸਿੰਗਲ, conflict-ਭਰਪੂਰ PR ਨੂੰ ਇੱਕ ਪ੍ਰਬੰਧਨਯੋਗ ਅਤੇ review-friendly ਲੜੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਹਾਡਾ workflow ਲੰਬੇ reviews ਅਤੇ merge ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨਾਲ ਜੂਝ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਸ preview ਨੂੰ ਅਜ਼ਮਾ ਕੇ ਦੇਖਣਾ ਫਾਇਦੇਮੰਦ ਹੋਵੇਗਾ।