Git چه مسئله‌ای را حل می‌کند؟ از کپی پوشه تا تاریخچهٔ قابل اعتماد

قبل از اینکه «git init» را حفظ کنید، یک سؤال مهم‌تر است: بدون کنترل نسخه چه چیزی می‌شکند؟ تیم‌هایی که هنوز پروژه را در پوشه‌های final، final2 و final-real نگه می‌دارند، معمولاً چهار درد تکراری دارند — بازیابی نسخهٔ درست، فهمیدن اینکه چه کسی چه چیزی را عوض کرده، کار موازی بدون پایمال کردن هم، و اثبات اینکه نسخهٔ Deploy همان چیزی است که Review شده. Git برای همین دردها طراحی شده است، نه برای زیباتر کردن ترمینال.

کتاب Pro Git در فصل About Version Control همین نیازها را محور قرار می‌دهد: بازیابی، پاسخگویی، و همکاری. مستندات git-scm و GitHub Docs هم Git را به‌عنوان سیستم کنترل نسخهٔ توزیع‌شده معرفی می‌کنند که snapshot می‌گیرد، تقریباً همهٔ کار را محلی نگه می‌دارد، و با checksum یکپارچگی داده را حفظ می‌کند. این مقاله زاویهٔ مسئله را باز می‌کند؛ تعریف ابزاری و گردش فرمان‌ها در ۲۰۲ تا ۲۱۱ همین سری عمیق‌تر می‌شود.

اگر مقالهٔ ۰۷۰ «Git چیست» را خوانده‌اید، اینجا تکرار تعریف نیست: می‌پرسیم چرا اصلاً به چنین ابزاری نیاز دارید و کجا هنوز جایگزین‌های ساده‌تر کافی‌اند.

پاسخ کوتاه

Git مسئلهٔ «کدام نسخه از کد، با چه تغییری، توسط چه کسی، و چرا» را به یک تاریخچهٔ قابل جست‌وجو و قابل برگشت تبدیل می‌کند. به‌جای تکیه به حافظه، چت، یا نام پوشه، هر Commit یک snapshot با هویت و پیام است؛ Branch اجازهٔ آزمایش موازی می‌دهد؛ و چون مدل توزیع‌شده است، هر کلون تاریخچه را دارد و برای ثبت تغییر نیازی به آنلاین بودن دائمی نیست.

آنچه Git حل نمی‌کند: کیفیت محصول، امنیت دسترسی سازمانی، تست خودکار، یا جلوگیری از Commit کردن Secret. کنترل نسخه لایهٔ تاریخچه و همگام‌سازی است؛ بقیه باید روی آن سوار شوند.

کنترل نسخه یعنی بتوانید بگویید الان روی کدام snapshot هستید و چطور به آن رسیده‌اید — نه اینکه پوشهٔ درست را از بین ده کپی پیدا کنید.

چهار دردی که کپی دستی نمی‌تواند حل کند

۱) بازیابی نسخهٔ قبلی بدون حدس

وقتی باگ بعد از «یک تغییر کوچک» ظاهر می‌شود، سؤال این است: کدام فایل، کدام خط، کدام روز؟ پوشهٔ تاریخ‌دار فقط آخرین وضعیت را نگه می‌دارد؛ زنجیرهٔ علت را نمی‌دهد. با Git می‌توانید به Commit مشخص برگردید، diff بگیرید، یا با bisect بازه را نصف کنید. این تفاوت بین «حدس زدم» و «شواهد دارم» است.

۲) پاسخگویی: چه کسی و چرا

در پروژهٔ دو نفره شاید چت کافی باشد؛ در تیم ده‌نفره یا پروژهٔ متن‌باز، بدون نویسنده و پیام Commit، ممیزی و Code Review فرسایشی می‌شود. Pro Git تأکید می‌کند که سیستم کنترل نسخه باید نشان دهد چه کسی تغییر را وارد کرده. این برای دیباگ، امنیت، و انتقال دانش به نفر جدید حیاتی است.

۳) همکاری موازی بدون بازنویسی کور

دو نفر روی یک فایل ZIP یا یک پوشهٔ اشتراکی کار کنند، معمولاً یکی کار دیگری را overwrite می‌کند. Branch و Merge (و بعداً Pull Request) مسیر جدا می‌سازند و ادغام را صریح می‌کنند. Conflict دردناک است، اما پنهان ماندن overwrite دردناک‌تر است.

۴) شناسه برای Deploy و Rollback

«همین چیزی که روی لپ‌تاپم است» شناسه نیست. Commit hash یا Tag یک نقطهٔ ثابت در تاریخچه است که CI و Production می‌توانند به آن قفل شوند. بدون آن، Rollback به «کدام بکاپ؟» تبدیل می‌شود.

جدول: روش دستی در برابر کنترل نسخه

چرا مدل توزیع‌شده (DVCS) برای این مسائل مهم است؟

سیستم‌های متمرکز قدیمی تاریخچه را عمدتاً روی سرور نگه می‌داشتند؛ قطع شبکه یعنی توقف Commit معنادار. Git به‌عنوان DVCS کل تاریخچه را به هر کلون می‌دهد. طبق Pro Git، سه ایدهٔ طراحی — snapshot نه فقط diff خطی، عملیات تقریباً محلی، و یکپارچگی با checksum — مستقیماً به دردهای بالا وصل می‌شوند:

• Snapshot: Branch و مقایسه سریع و مفهومی ساده می‌ماند.
• محلی بودن: سفر، قطع اینترنت، و latency سرور مانع ثبت کار نمی‌شود.
• Checksum: تغییر پنهان در محتوا بدون تغییر شناسه ممکن نیست؛ پایهٔ اعتماد به تاریخچه.

توجه: checksum جایگزین پشتیبان آفلاین و کنترل دسترسی هاست نیست. Git یکپارچگی محتوای تاریخچه را تضمین می‌کند، نه اینکه دیسک نسوزد یا دسترسی اشتباه داده نشود.

سناریوهای واقعی: کجا Git ضروری است و کجا افراط؟

ضروری یا بسیار مفید

• هر پروژهٔ نرم‌افزاری با بیش از یک نفر یا عمر بیش از چند روز.
• کد که به Production می‌رود و باید Rollback داشته باشد.
• کتابخانه، اسکریپت زیرساخت به‌صورت کد، و پیکربندی‌های متنی مهم.
• همکاری با پیمانکار یا متن‌باز که Review رسمی می‌خواهد.

گاهی ساده‌تر کافی است

• پیش‌نویس یک‌بارمصرف که دور انداخته می‌شود و هیچ Deployی ندارد.
• دارایی باینری عظیم بدون استراتژی LFS — Git اینجا دردسر حجم می‌سازد.
• یادداشت شخصی کوتاه؛ هر چند بسیاری همان را هم در مخزن می‌گذارند.

معیار تصمیم: آیا بعدها به سؤال «چرا این‌طور شد؟» یا «کدام نسخه زنده است؟» نیاز دارید؟ اگر بله، کنترل نسخه ارزان‌ترین بیمه است.

اشتباه‌های رایج وقتی «مسئله» را غلط می‌فهمید

1. فکر کردن که Git فقط برای متن‌باز بزرگ است — تیم دو نفره هم Conflict و بازیابی دارد.
2. جایگزین دانستن Git با Google Drive یا Dropbox: همگام‌سازی فایل ≠ تاریخچهٔ معنایی Commit.
3. فرض اینکه Push یعنی بکاپ کامل همه چیز؛ Remote مفید است اما سیاست پشتیبان جداست.
4. Commit کردن Secret و binaryهای سنگین چون «همه چیز باید در Git باشد».
5. نادیده گرفتن پیام Commit؛ بدون چرا، تاریخچه فقط انبار بایت است.

حداقل مدل ذهنی قبل از یادگیری فرمان‌ها

اگر فقط سه جمله از این صفحه بمانند:

1. مسئله = نسخه + همکاری + پاسخگویی، نه «یادگیری دستور».
2. واحد حقیقت = Commit (snapshot)، نه پوشهٔ روی دسکتاپ.
3. Remote و GitHub لایهٔ اشتراک و Review هستند؛ خودِ Git موتور تاریخچه است.

قدم بعدی منطقی: بفهمید Repository چیست (۲۰۲)، سه لایهٔ Working tree / Staging / Repository را جدا کنید (۲۰۳)، بعد Commit و Branch را دقیق بخوانید.

داستان کوتاه: یک باگ که «دیروز کار می‌کرد»

تیم کوچکی بدون Git، نسخهٔ در حال اجرای Production را از روی لپ‌تاپ آخرین نفری که Deploy کرده بازسازی می‌کند. یک رگرسیون ظاهر می‌شود. کسی مطمئن نیست کدام ZIP همان Build است. بعد از نیم‌روز مقایسهٔ دستی، معلوم می‌شود یک خطای پیکربندی دیروز وارد شده ولی در چت گم شده است. با Git، همان سؤال با git log و git bisect و یک hash مشخص در CI در دقیقه‌ها جمع می‌شود — به شرطی که Commitها اتمی و پیام‌ها معنادار باشند.

این داستان اغراق تبلیغاتی نیست؛ الگوی تکراری تیم‌های پیش‌از-کنترل‌نسخه است. هزینهٔ یادگیری Git در برابر هزینهٔ یک بعدازظهر بازیابی کور، معمولاً کوچک است.

لایه‌هایی که روی Git سوار می‌شوند — و جایگزین آن نیستند

وقتی مسئله را درست ببینید، مرز ابزارها روشن می‌شود:

• Git = تاریخچه و همگام‌سازی snapshotها.
• هاست (GitHub/GitLab) = دسترسی، PR، Issue، Actions.
• CI = اثبات خودکار کیفیت روی یک Commit.
• Artifact/Registry = بستهٔ ساخت‌شده از همان Commit.
• پشتیبان زیرساخت = دیسک و بلایا؛ جدا از مدل ذهنی Branch.

تیمی که فقط «پوشه روی سرور» دارد، هیچ‌کدام از این لایه‌ها را به‌صورت یکپارچه ندارد. تیمی که Git دارد ولی Secret را Commit می‌کند، لایهٔ تاریخچه را علیه خودش استفاده کرده است.

معیارهای عملی برای تصمیم «از فردا Git»

1. آیا بیش از یک نفر به همان کد دست می‌زند؟
2. آیا نسخهٔ Production باید قابل نام‌گذاری و Rollback باشد؟
3. آیا ممیزی «چه کسی تغییر داد» روزی لازم می‌شود؟
4. آیا آزمایش بدون ترس از خراب کردن تنها کپی ارزشمند است؟

اگر به دو سؤال یا بیشتر بله می‌گویید، تأخیر در ورود به کنترل نسخه معمولاً بدهی فنی فرآیندی است نه صرفه‌جویی.

Git در برابر همگام‌سازی ابری فایل

سرویس‌های همگام‌سازی فایل Conflict را گاهی با «فایل متعارض کاربر» حل می‌کنند بدون مدل Branch و پیام معنایی. برای اسناد اداری ممکن است کافی باشد؛ برای کد نرم‌افزار که Deploy و Review دارد، واحد Commit و hash ضروری است. اگر تیم کد را فقط در Drive نگه می‌دارد، مسئلهٔ ۲۰۱ هنوز حل نشده — فقط جابه‌جا شده است.

ترکیب درست اغلب این است: کد در Git، سندهای باینری بزرگ در محل مناسب دیگر، و لینک بین آن‌ها در README یا Wiki.

چک‌لیست انتقال تیم از کپی پوشه به Git

1. یک مخزن آزمایشی آموزشی بسازید؛ اول روی پروژهٔ واقعی جنگ نکنید.
2. قرارداد: نام Branch، پیام Commit، و ممنوعیت Secret.
3. Remote تیمی با دسترسی حداقل لازم.
4. اولین PR اجباری حتی برای تغییر کوچک تا عادت شکل بگیرد.
5. بعد از دو هفته، یک Retro کوتاه: کجا هنوز ZIP رد و بدل می‌شود؟

مقاومت رایج «وقت نداریم» معمولاً با یک حادثهٔ بازیابی بی‌نسخه بی‌اثر می‌شود؛ بهتر است قبل از حادثه سرمایه‌گذاری کنید.

از دید مدیر محصول و امنیت

مدیر محصول لازم نیست فرمان Git حفظ باشد، ولی باید بداند «هنوز Merge نشده» یعنی تغییر در main و احتمالاً Production نیست، و «روی Branch فیچر است» یعنی کار موازی جداگانه. امنیت هم به تاریخچه برای پاسخگویی و به جلوگیری از Secret در Commit علاقه دارد. وقتی این نقش‌ها مدل ذهنی مشترک داشته باشند، فشار «فقط فایل را بفرست» کمتر می‌شود.

آموزش یک‌ساعته مفهومی برای غیرمهندس‌ها — بدون غرق شدن در rebase — اغلب کافی است تا زبان تیم یکی شود. مقالهٔ ۲۰۸ و ۲۰۹ همان زبان را برای PR و Review گسترش می‌دهند.

جمع‌بندی مسئله‌محور قبل از فرمان‌ها

اگر تا اینجا فقط یک تصمیم بگیرید: از این به بعد هر تغییر معنادار کد یک Commit با پیام چرا-محور باشد، روی Branch جدا از خط پایدار، و از مسیر Review وارد main شود. باقی فرمان‌ها جزئیات اجرای همین تصمیم‌اند. بدون این تصمیم، حفظ کردن init و push فقط واژگان است.

سوالات متداول

اگر تنها کار می‌کنم باز هم Git لازم است؟

بله، اگر پروژه عمر دارد یا Deploy می‌شود. بازیابی و آزمایش بدون ترس از خراب کردن تنها نسخه، همان ارزش را برای یک نفر هم دارد.

آیا Time Machine یا تاریخچهٔ فایل ویندوز جایگزین است؟

بکاپ فایل‌سیستم بازیابی بلایا است؛ مدل ذهنی Branch، Review، و پیام معنایی Commit را نمی‌دهد. مکمل‌اند، جایگزین کنترل نسخهٔ نرم‌افزار نیستند.

Git همان GitHub است؟

خیر. Git ابزار و مدل داده است؛ GitHub (و مشابه) hosting و لایهٔ همکاری روی آن. مقالهٔ ۲۰۸ و ۲۰۹ روی Pull Request و Review تمرکز می‌کنند.

از کجا شروع کنم بدون غرق شدن؟

یک مخزن آزمایشی بسازید، سه Commit معنادار بزنید، یک Branch بسازید و Merge کنید. بعد Remote. جزئیات در ۲۰۲–۲۰۶.

خلاصه

Git قبل از هر چیز پاسخ به شکست روش‌های دستی است: کپی پوشه بازیابی ضعیف، همکاری شکننده، و Deploy بدون شناسه می‌سازد. کنترل نسخهٔ توزیع‌شده این دردها را با snapshot، کار محلی، و تاریخچهٔ قابل ممیزی کاهش می‌دهد — به شرطی که Secret را Commit نکنید و پیام‌ها را جدی بگیرید.

اگر مسئله را درست ببینید، فرمان‌ها معنی پیدا می‌کنند. منابع زیر همان صفحات رسمی‌اند که این چارچوب از آن‌ها آمده است.

منابع و مراجع

• Pro Git — About Version Control — https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
• Pro Git — What is Git? — https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
• Git documentation (git-scm) — https://git-scm.com/doc
• GitHub Docs — About Git — https://docs.github.com/en/get-started/using-git/about-git
• GitHub Docs — Git Guides — https://docs.github.com/en/get-started/git-basics