گردش کار Git برای تیم‌های نرم‌افزاری

Git فقط ذخیره‌ی کد نیست

بیشتر توسعه‌دهنده‌ها Git را با سه دستور add، commit و push می‌شناسند. این برای پروژه‌ی شخصی کافی است، اما وقتی چند نفر هم‌زمان روی یک کدبیس کار می‌کنند، نبودن یک گردش کار (Workflow) مشخص به تداخل‌های مکرر، تاریخچه‌ی ناخوانا و انتشار کدهای ناقص منجر می‌شود. در این مقاله یک گردش کار ساده و کاربردی برای تیم‌های کوچک و متوسط معرفی می‌کنم.

انتخاب مدل شاخه‌بندی

مدل‌های مختلفی وجود دارد، اما برای بیشتر تیم‌های امروزی، Trunk-Based Development یا نسخه‌ی ساده‌ی GitHub Flow بهترین نتیجه را می‌دهد:

• شاخه‌ی main همیشه سالم و قابل استقرار است.
• هر تغییر در یک شاخه‌ی کوتاه‌عمر ساخته می‌شود.
• تغییرات از طریق Pull Request و پس از بازبینی وارد main می‌شوند.
• شاخه‌ها حداکثر چند روز عمر دارند تا تداخل‌ها کوچک بمانند.

نام‌گذاری شاخه‌ها

یک قرارداد ساده، پیدا کردن شاخه‌ها و ارتباط آن‌ها با تسک‌ها را آسان می‌کند:

git switch -c feat/jalali-date-picker
git switch -c fix/login-otp-timeout
git switch -c chore/upgrade-next-16

پیام کامیت خوانا با Conventional Commits

پیام کامیت برای شما در شش ماه بعد و برای هم‌تیمی‌هایتان نوشته می‌شود. قالب Conventional Commits هم خوانایی را بالا می‌برد و هم امکان تولید خودکار Changelog را فراهم می‌کند:

feat: add shared categories for blog and portfolio
fix: prevent duplicate OTP requests within 60 seconds
refactor: extract upload validation into lib/uploads
docs: explain deployment steps in README

Rebase یا Merge؟

قبل از باز کردن Pull Request، شاخه‌ی خود را با آخرین تغییرات main به‌روز کنید. استفاده از rebase تاریخچه‌ای خطی و تمیز می‌سازد:

git fetch origin
git rebase origin/main
# حل تداخل‌ها در صورت وجود
git add .
git rebase --continue
git push --force-with-lease

از --force-with-lease به‌جای --force استفاده کنید؛ اگر کسی در این فاصله روی همان شاخه چیزی پوش کرده باشد، دستور متوقف می‌شود و کار او از بین نمی‌رود. قاعده‌ی طلایی: هرگز شاخه‌ای را که دیگران روی آن کار می‌کنند rebase نکنید.

Pull Request خوب چه ویژگی‌هایی دارد؟

• کوچک باشد: بازبینی ۲۰۰ خط کد دقیق انجام می‌شود؛ بازبینی ۲۰۰۰ خط معمولاً سطحی.
• توضیح داشته باشد: چه چیزی تغییر کرده، چرا و چطور می‌توان آن را تست کرد.
• تصویر اضافه کنید: برای تغییرات ظاهری، اسکرین‌شات قبل و بعد را قرار دهید.
• CI سبز باشد: پیش از درخواست بازبینی، تست‌ها و لینت باید موفق باشند.

دستورهایی که روزی نجاتتان می‌دهند

# کامیت آخر را اصلاح کن (قبل از push)
git commit --amend

# تغییرات نیمه‌کاره را موقتاً کنار بگذار
git stash push -m "wip: navbar"

# پیدا کردن کامیتی که باگ را ایجاد کرده
git bisect start
git bisect bad
git bisect good v1.4.0

# بازگرداندن کامیتی که قبلاً منتشر شده
git revert <commit-sha>

# پیدا کردن کاری که فکر می‌کردید از دست رفته
git reflog

محافظت از شاخه‌ی اصلی

در تنظیمات مخزن، برای main قانون Branch Protection تعریف کنید: پوش مستقیم ممنوع، حداقل یک تأیید برای ادغام و الزام موفقیت CI. این قوانین ساده جلوی بسیاری از اشتباهات عجولانه را می‌گیرند.

جمع‌بندی

یک گردش کار Git خوب پیچیده نیست: شاخه‌های کوتاه‌عمر، پیام‌های کامیت خوانا، Pull Requestهای کوچک و شاخه‌ی اصلی محافظت‌شده. این عادت‌ها در ابتدا کمی زمان می‌برند، اما در ادامه سرعت تیم را چند برابر و استرس انتشار را به حداقل می‌رسانند.