git-parsec — एक ही टिकट से worktree बनाने से लेकर PR merge तक

यह Git worktree-आधारित parallel development workflow को automate करने वाला एक CLI टूल है।

यह किस समस्या को हल करता है

ब्रांच बदले बिना कई टिकटों पर एक साथ काम करते समय, git worktree एक अच्छा विकल्प है।
लेकिन इसे वास्तविक काम में इस्तेमाल करने पर कई दोहराए जाने वाले काम सामने आते हैं:

• worktree बनाना और branch का नाम देना → parsec start PROJ-123 की एक लाइन में
• push करना, PR बनाना, और ticket link जोड़ना → parsec ship PROJ-123 की एक लाइन में
• CI जांचना, merge करना, और worktree साफ़ करना → parsec merge PROJ-123 की एक लाइन में

हर बार दोहराए जाने वाले काम अब एक-एक command line में सिमट जाते हैं।

मुख्य workflow

parsec start PROJ-123       # worktree + 브랜치 + Jira 티켓 연동  
# ... 코딩 ...  
parsec ship PROJ-123        # push → PR 생성 (티켓 제목/링크 자동 포함)  
parsec ci PROJ-123          # CI 상태 테이블 출력  
parsec merge PROJ-123       # CI 대기 → squash 머지 → worktree 자동 정리  

प्रमुख फीचर्स

ट्रैकर इंटीग्रेशन

• Jira / GitHub Issues — ticket title का automatic reflection, status transition, board view, inbox
• parsec ticket — टर्मिनल में ticket details देखना
• parsec board — Jira sprint board को CLI में देखना

worktree प्रबंधन

• Shell integration — parsec switch से worktree के बीच cd अपने-आप move होता है
• Stack PR — --on option से PR chain बनाना, stack sync से bulk rebase
• Undo — गलती से साफ़ किए गए worktree को भी एक बार में restore

ऑटोमेशन

• Release — tag + merge + GitHub Release + changelog का automatic generation
• Human / JSON / Quiet output mode — CI script integration आसान
• 27 subcommands — start, list, status, ship, merge, ci, diff, sync, adopt, rename आदि

इंस्टॉलेशन

cargo install git-parsec  

या GitHub Releases से macOS / Linux binaries डाउनलोड किए जा सकते हैं।

यह किन लोगों के लिए उपयोगी है

• जो कई टिकटों पर एक साथ काम करते हैं (worktree-आधारित parallel development)
• जिन्हें Jira + Git के बीच के दोहराए जाने वाले कामों से थकान हो गई है
• जो monorepo में context switching की लागत कम करना चाहते हैं
• जो AI agents (Claude Code आदि) को स्वतंत्र कार्य वातावरण देना चाहते हैं

लिंक

• GitHub: https://github.com/erishforG/git-parsec
• इंस्टॉलेशन: cargo install git-parsec

यह Rust में लिखा गया है, हल्का है, और मौजूदा git repository पर तुरंत लागू किया जा सकता है।
फ़ीडबैक या सवालों का स्वागत है!

[puddingman220]

मैंने हाल ही में parallel worktree पर एक tech blog देखा और उसमें रुचि जगी, लेकिन implementation details नहीं देख पाया, इसलिए अफसोस हुआ—लगता है इस open source के साथ इसे एक बार गहराई से देखना चाहिए!

नीचे वह blog post है जो मैंने देखी थी।
https://medium.com/ajd-tech/…

[erish2150]

धन्यवाद! आपने ब्लॉग में जो लिखा है, वह हल्के से देखने पर भी बेहद शानदार तरीके से लिखा गया है.
अगर मौका मिले, तो देखकर बताइए—कुछ पसंद न आए या कुछ सुधारना चाहें, तो बेझिझक issue दर्ज करें या PR भेज दें!

[shaun0927]

मुझे लगता है कि parallel worktree का तरीका work dirty -> clean nicely जैसा है,
और मुझे लगता है कि आगे चलकर यही मुख्य development तरीका बन जाएगा.
अच्छा repo लगता है।

[erish2150]

धन्यवाद :) आपने उन बिंदुओं को अच्छी तरह लिखा है जिनके बारे में मैं सोच रहा था।

[bigcataroido]

worktree-आधारित parallel काम को मजबूर करने वाला यह approach काफ़ी प्रभावशाली लग रहा है.

मैं भी जब कई tickets को एक साथ संभालता हूँ,
तो हर काम के environment को अलग रखने के लिए tmux + कई branch के combination के साथ काम करता हूँ,
लेकिन आखिर में state management लगातार उलझ जाने की समस्या रही है.

parsec की तरह start/ship/merge से lifecycle को बाँध देना
शायद उल्टे गलतियाँ कम करने की दिशा में ज़्यादा मददगार लगेगा.

एक बात जानने की जिज्ञासा है:
जब कई PR एक साथ खुले हों और merge का क्रम बदल जाए
या rebase की ज़रूरत पड़े, तब stack sync कैसे काम करता है?

[erish2150]

रुचि दिखाने के लिए धन्यवाद!

stack sync parent-child संबंध के आधार पर topological order में rebase चलाता है.

काम करने का तरीका

parsec start PROJ-1                 # main आधारित  
parsec start PROJ-2 --on PROJ-1     # PROJ-1 branch आधारित  
parsec start PROJ-3 --on PROJ-2     # PROJ-2 branch आधारित  
  
parsec stack sync                   # नीचे दिए गए क्रम में automatic rebase  
# 1. PROJ-1 → origin/main के ऊपर rebase  
# 2. PROJ-2 → PROJ-1 branch के ऊपर rebase  
# 3. PROJ-3 → PROJ-2 branch के ऊपर rebase  
  
रूट से BFS के साथ traverse करते हुए, हर child को parent branch के ऊपर rebase किया जाता है. अगर main अपडेट हो गया हो, तो बदलाव रूट से स्वाभाविक रूप से आगे propagate हो जाते हैं.  
  
## जब merge का क्रम बदल जाए  
  
अभी यह stack के निचले हिस्से (parent) से merge करने की धारणा के साथ डिज़ाइन किया गया है. अगर बीच का कोई PR पहले merge हो जाए, तो उसके child अगले `stack sync` के समय parent को नहीं ढूँढ पाएँगे और process fail हो जाएगा. इस स्थिति में  
base को manually फिर से assign करना होगा.  
  
## conflict होने पर  
  
rebase के दौरान conflict होने पर सिर्फ उसी branch को `rebase --abort` से rollback किया जाता है और बाकी process जारी रहती है. कौन-सा ticket सफल/असफल हुआ, यह परिणाम table में दिखाया जाता है, इसलिए केवल failed वाले ticket को manually ठीक करना होता है.