Git و کنترل نسخه در توسعه موبایل: چیست، دستورات پایه و چگونه کار می‌کند

کنترل نسخه و Git: چیست؟

Git یک سیستم کنترل نسخه توزیع‌شده (VCS) است که توسط لینوس توروالدز در سال ۲۰۰۵ برای توسعه هسته لینوکس ایجاد شد. برخلاف سیستم‌های متمرکز (SVN، CVS)، Git یک کپی کامل از تاریخچه پروژه را روی هر کامپیوتر توسعه‌دهنده ذخیره می‌کند. این بدان معناست که می‌توانید حتی بدون اتصال به اینترنت commit کنید، تاریخچه را مرور کنید و شاخه بسازید.

Git با عکس‌های فوری (snapshot) کار می‌کند — هر commit وضعیت تمام فایل‌های پروژه را در زمان ذخیره‌سازی ثبت می‌کند. اگر فایلی تغییر نکرده باشد، Git به نسخه قبلی ارجاع می‌دهد و فضا صرفه‌جویی می‌کند. بر اساس تحلیل GitHub (۲۰۲۵)، مخزن متوسط شامل ۱۲۰۰ commit و ۱۵ شاخه است.

در IT Sectr، ما از سال ۲۰۱۷ در تمام پروژه‌ها از Git استفاده می‌کنیم. تجربه ما نشان می‌دهد که پیکربندی صحیح Git از روز اول تا ۳۰٪ در زمان ادغام و حل تعارضات به تیم صرفه‌جویی می‌کند. Git به استاندارد دوفاکتو تبدیل شده است — توسط تمام IDEهای مدرن (Android Studio، Xcode، VS Code) و سیستم‌های CI/CD پشتیبانی می‌شود.

# تنظیمات پایه Git
git config --global user.name "نام شما"
git config --global user.email "your@email.com"

# ایجاد مخزن جدید
git init my-project
cd my-project

# افزودن فایل‌ها و commit
git add README.md
git commit -m "Initial commit"

# کار با مخزن راه دور
git remote add origin https://github.com/user/my-project.git
git push -u origin main

کد بالا توالی پایه را نشان می‌دهد: مقداردهی مخزن، اولین commit و انتشار در سرور راه دور. دستور git init یک پوشه مخفی .git ایجاد می‌کند که تمام تاریخچه پروژه را ذخیره می‌کند. هر git commit یک نقطه بازیابی ایجاد می‌کند که می‌توانید هر زمان به آن بازگردید.

مفاهیم پایه: Repository، Branch، Commit

درک سه مفهوم پایه — Repository، Branch و Commit — برای کار با هر سیستم کنترل نسخه ضروری است. مخزن یک ظرف برای کل پروژه است. Commit وضعیت ذخیره‌شده فایل‌ها است. Branch یک خط توسعه جداگانه است.

Repository (مخزن) می‌تواند محلی (روی کامپیوتر شما) یا راه دور (روی سرور GitHub، GitLab) باشد. هر توسعه‌دهنده مخزن راه دور را روی ماشین خود کلون می‌کند و با یک کپی محلی کار می‌کند. تغییرات از طریق push (فرستادن) و pull (گرفتن) همگام‌سازی می‌شوند. در کنترل نسخه توزیع‌شده، هر توسعه‌دهنده یک کپی کامل از تاریخچه ذخیره می‌کند.

Branch (شاخه) اشاره‌گری به یکی از commitها است. شاخه‌ها توسعه موازی را امکان‌پذیر می‌کنند: یک توسعه‌دهنده روی ویژگی جدید (feature branch) کار می‌کند، دیگری باگ را رفع می‌کند (hotfix branch)، سومی انتشار را آماده می‌کند (release branch). بر اساس GitLab Flow (۲۰۲۵)، پروژه متوسط به طور همزمان ۳–۵ شاخه فعال دارد.

Commit یک واحد تغییر است. هر commit شامل یک هش منحصربه‌فرد (SHA-1)، پیام، نویسنده و مهر زمانی است. روش خوب انجام commitهای کوچک و معنادار با پیام‌های توصیفی است — این کار بازبینی کد و بازگردانی تغییرات را ساده می‌کند. کنترل نسخه از طریق commitها تاریخچه کامل پروژه را در اختیار شما قرار می‌دهد.

Feature Branch

Feature Branch (شاخه ویژگی) یک شاخه موقت است که برای توسعه یک وظیفه خاص از develop یا main ایجاد می‌شود. پس از اتمام کار، شاخه از طریق Pull Request ادغام و حذف می‌شود. این روش امکان جداسازی تغییرات را بدون تأثیر بر پایداری پایگاه کد اصلی فراهم می‌کند.

گردش کار typical: ایجاد شاخه feature/add-login → انجام چند commit → ایجاد Pull Request → گذراندن بازبینی کد → ادغام در develop. در IT Sectr دقیقاً از این رویکرد استفاده می‌کنیم: هر وظیفه Jira با یک شاخه ویژگی جداگانه مطابقت دارد. این کار ردیابی تغییرات و بازگردانی در صورت نیاز را ساده می‌کند.

Rebase در مقابل Merge

Merge یک commit ادغام ایجاد می‌کند که دو شاخه را ترکیب می‌کند. این تاریخچه کامل از جمله خطوط توسعه موازی را حفظ می‌کند. Rebase تاریخچه را بازنویسی می‌کند: commitها را از یک شاخه می‌گیرد و آنها را روی شاخه دیگر "دوباره اعمال" می‌کند و تاریخچه خطی ایجاد می‌کند.

Merge برای شاخه‌های عمومی و تیم‌های بزرگ که توالی زمانی مهم است مناسب‌تر است. Rebase برای شاخه‌های ویژگی شخصی قبل از ایجاد PR مفید است — تاریخچه را تمیزتر و قابل‌فهم‌تر می‌کند. با این حال، rebase هرگز نباید روی شاخه‌هایی اعمال شود که توسعه‌دهندگان دیگر روی آنها کار می‌کنند، زیرا تاریخچه را بازنویسی می‌کند.

# ایجاد و تغییر به شاخه ویژگی
git checkout -b feature/add-login main

# کار در شاخه
git add login-screen/
git commit -m "Add login screen layout"

# Rebase روی آخرین main قبل از PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push به مخزن راه دور
git push origin feature/add-login

این مثال یک گردش کار typical را نشان می‌دهد: ایجاد شاخه ویژگی از main، چند commit و rebase برای دریافت تاریخچه خطی تمیز قبل از ارسال برای بازبینی. این رویکرد تعارضات ادغام را به حداقل می‌رساند.

Git Flow در مقابل Trunk-Based Development

Git Flow و Trunk-Based Development دو استراتژی اصلی کنترل نسخه هستند که تعیین می‌کنند تیم چگونه کار با Git را سازماندهی می‌کند. انتخاب به اندازه تیم، تعداد انتشارات و الزامات پایداری بستگی دارد.

Git Flow یک مدل سختگیرانه با چندین شاخه دائمی است: main (کد انتشار)، develop (توسعه فعلی)، feature/* (ویژگی‌های جدید)، release/* (آماده‌سازی انتشار) و hotfix/* (رفع‌های فوری). این مدل برای پروژه‌هایی با چرخه‌های انتشار مشخص (مثلاً برنامه‌های موبایل با نسخه‌های ۱.۰، ۲.۰) مناسب است.

Trunk-Based Development رویکردی با یک شاخه اصلی (trunk/main) است که همه توسعه‌دهندگان چند بار در روز تغییرات را در آن ادغام می‌کنند. از پرچم‌های ویژگی برای پنهان کردن ویژگی‌های ناقص استفاده می‌شود. این رویکرد در توسعه وب و استارتاپ‌هایی که سرعت تحویل مهم است محبوب است.

Git Flow

Git Flow که توسط Vincent Driessen در سال ۲۰۱۰ ارائه شد، یکی از محبوب‌ترین مدل‌ها باقی مانده است. مزیت اصلی آن جداسازی دقیق کد بر اساس مراحل چرخه عمر است. شاخه main فقط شامل کد انتشار است، develop شامل توسعه فعلی است و شاخه‌های ویژگی ویژگی‌های جدید را از یکدیگر جدا می‌کنند.

شاخه‌های hotfix از main برای رفع‌های فوری ایجاد می‌شوند و پس از ادغام به هر دو main و develop بازگردانده می‌شوند. شاخه‌های release از develop ایجاد می‌شوند وقتی تیم برای انتشار آماده است. فقط رفع باگ‌ها و فراداده‌ها (نسخه، بیلد) به آنها اضافه می‌شود. پس از انتشار، شاخه release در main و develop ادغام می‌شود. بر اساس نظرسنجی JetBrains (۲۰۲۴)، ۳۷٪ تیم‌ها از Git Flow استفاده می‌کنند. این مدل کنترل نسخه استاندارد پروژه‌هایی با انتشارات ثابت باقی مانده است.

# مثال Git Flow: شروع کار روی انتشار
git checkout -b release/1.2.0 develop

# رفع باگ در شاخه release
git commit -m "Fix login button crash"

# تکمیل انتشار — ادغام در main و develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# حذف شاخه release
git branch -d release/1.2.0

کد ایجاد شاخه release، تثبیت آن و ادغام در شاخه‌های اصلی را نشان می‌دهد. پرچم --no-ff یک commit ادغام را تضمین می‌کند و اطلاعات اینکه تغییرات از شاخه release آمده‌اند را حفظ می‌کند.

Pull Request و بازبینی کد

Pull Request (PR) مکانیزمی است که توسط آن یک توسعه‌دهنده تغییرات را از شاخه خود به شاخه اصلی پیشنهاد می‌کند. PR یک عنصر کلیدی کنترل نسخه در کار تیمی است — این فقط راهی برای ادغام کد نیست، بلکه فرآیندی برای بحث، بازبینی و بررسی کیفیت است. در GitLab، مکانیزم مشابه Merge Request (MR) نامیده می‌شود، اما ماهیت یکسان است: اطلاع‌رسانی به تیم درباره تغییرات و دریافت تأیید.

یک PR خوب باید کوچک (تا ۳۰۰ خط کد)، متمرکز بر یک وظیفه و شامل توضیح اینکه چه کاری و چرا انجام شده باشد. بر اساس تحقیق Google (۲۰۲۵)، PRهای بیش از ۴۰۰ خط دو برابر بیشتر زمان بازبینی می‌برند و احتمال تشخیص باگ ۳۰٪ کاهش می‌یابد. بازبینی کد (Code Review) بررسی کد توسط توسعه‌دهنده دیگر قبل از ادغام است.

در IT Sectr، ما برای هر PR بازبینی اجباری کد را انجام می‌دهیم. این نه تنها کیفیت کد را بهبود می‌بخشد، بلکه به انتشار دانش در تیم نیز کمک می‌کند. بازبینی کد بررسی می‌کند: آیا کد از اصول معماری پیروی می‌کند، آیا باگی وجود دارد، آیا تست‌های کافی وجود دارد، آیا متغیرها به درستی نام‌گذاری شده‌اند. تمام نظرات تا زمان ادغام در PR بحث می‌شوند.

پلتفرم‌ها: GitHub، GitLab، Bitbucket

Git یک پروتکل است، اما برای همکاری به یک پلتفرم کنترل نسخه نیاز است که رابط وب، مدیریت دسترسی، CI/CD و ابزارهای بازبینی ارائه دهد. سه پلتفرم بر بازار تسلط دارند: GitHub، GitLab و Bitbucket.

GitHub بزرگترین پلتفرم با بیش از ۵۶ میلیون توسعه‌دهنده است. متعلق به Microsoft، Actions (CI/CD)، Pages (میزبانی)، Discussions و Copilot را ارائه می‌دهد. طرح رایگان شامل مخازن خصوصی نامحدود برای تیم‌های تا ۳ نفر است. GitHub در جامعه منبع‌باز محبوب است.

GitLab یک پلتفرم کامل DevOps با CI/CD یکپارچه، ثبت کانتینر و مدیریت زیرساخت است. برخلاف GitHub، GitLab را می‌توان روی سرور خود نصب کرد (Self-Managed). Bitbucket متعلق به Atlassian با Jira و Confluence یکپارچه شده است و آن را به انتخابی برای تیم‌هایی تبدیل می‌کند که قبلاً از اکوسیستم Atlassian استفاده می‌کنند.