سیستم کنترل نسخه، برنامه قدرتمندی است که به وسیله آن می‌توان تاریخچه‌ی تغییرات صورت گرفته روی فایل‌های یک پروژه را در طول زمان دنبال کرد و در صورت نیاز به همه‌ی نسخه‌های قبلی آن دسترسی داشت. هم‌چنین ابزار مناسبی برای توسعه گروهی پروژه‌ها با حفظ نظم کار و کنترل مسیر تغییرات اعمالی توسط هر عضو در نسخه‌ها است.
سیستم‌های کنترل نسخه بر دو نوع‌اند:
متمرکز یا Centralized Version control (CVCS) مانند Subvertion (SVN) ،Concurrent Version System (CVS) و Team Foundation Server (TFS)
توزیع شده یا Diswtributed Version Control (DVCS) مانند Mercurial ،Bazaar و Git
تفاوت این دو در نحوه ذخیره سازی و دسترسی کاربران به اطلاعات است.
در CVCS یک نسخه مرکزی وجود دارد که همه نسخه‌ها با مراجعه و همگام‌سازی با این نسخه به روز می‌شوند و تغییرات اعمالی پس از تأیید به آن اضافه می‌گردد. هم‌چنین در صورت از بین رفتن اطلاعات سرور مرکزی، نسخه پشتیبان کاملی از آن دردست نخواهیم داشت، چون دسترسی هر یک از اعضاء به آن محدود بوده است.
اما در DVCS یک نسخه مرکزی از پروژه وجود ندارد، بلکه هر یک از اعضا همه اطلاعات و تاریخچه‌ی کاملی از تغییرات را در اختیار دارد و هر زمان که تغییراتی در نسخه محلی خود بوجود آورد می‌تواند آن را با سایر نسخه‌ها ادغام کند.
استفاده از سیستم‌های کنترل نسخه، علاوه بر برنامه‌نویسان و توسعه‌دهندگان، مورد توجه دیزاینرها و نویسندگان نیز قرار گرفته است! ( مثلا Trunk یک Version Control System برای فایل‌های گرافیکی است . یا Simul که یک سیستم کنترل نسخه برای نرم‌افزار Microsoft Word است.)
وقتی که هسته لینوکس در سال 1991 توسط لینوس توروالدز و تحت مجوز GPL منتشر شد، برنامه‌نویسان زیادی از سراسر دنیا به توسعه آن کمک کردند.
فایل‌های آرشیو شده‌ی این پروژه عظیم ابتدا توسط Patch و E-Mail بین توسعه‌دهندگان رد و بدل می‌شد تا این که در سال ۲۰۰۲، تیم توسعه لینوکس از DVCS به نام BitKeeper برای سازماندهی کدها و نسخه‌های خود استفاده می‌کردند.
در سال ۲۰۰۵، بابر هم خوردن ارتباط بین جامعه توسعه‌دهنده هسته لینوکس و شرکت تجاری BitKeeper، امتیاز استفاده رایگان از این برنامه برای تیم لینوکس لغو شد. در پی آن توروالدز برای پیشبرد پروژه لینوکس به یک سیستمِ کنترلِ ورژن توزیع شده نیاز داشت، اما هیچ‌کدام از سیستم‌های کنترل ورژنِ موجود برای این کار مناسب نبودند. بنابراین توروالدز مشغول به نوشتن VCS جدیدی شد و همین موجب خلق git در سال 2005 گردید.
هم اکنون گیت یکی از قدرتمندترین و پراستفاده‌ترین سیستم‌های کنترل ورژن است، از سیستم عامل‌های لینوکس، ویندوز، مک و BSD پشتیبانی می‌کند و شرکت‌های بزرگی چون یاهو، گوگل، توییتر، مایکروسافت، اپل و… از آن استفاده می‌کنند.
برای شروع کار در git، ابتدا باید یک مخزن پروژه یا Repository (اصطلاحاً repo) درست کنیم تا تمام اسناد مربوط به پروژه را در آن قرار دهیم و git اعمال مربوط به توسعه و تغییر پروژه را در آن مدیریت کند.
دستور راه‌اندازی local repository در دایرکتوری مورد نظر:
$ git init
این دستور، (initialise) آغاز به کار کردن یک ریپازیتوریِ گیت را در دایرکتوری مورد نظر صادر می‌کند.
- .git (Hidden File)
پس از اعمال این دستور، یک دایرکتوری مخفی با نام .git در دایرکتوری اصلی پروژه ساخته خواهد شد که تمام اطلاعات و تغییرات مربوط به پروژه و نیز تنظیمات گیت در آن ذخیره می‌شود.
اگر می خواهید که پروژه خود را از گیت حذف کنید اما همچنان فایل‌های پروژه خود را داشته باشید، کافی است فقط پوشه .git را حذف کنید.
- clone
هم‌چنین می‌توانیم پروژه‌ای که می‌خواهیم روی آن کار کنیم را به طور مستقیم از یک remote repository مانند github یا gitlab دریافت کنیم. دستور مورد نظر پس از دریافت URL ِ ریپوی مورد نظر به این صورت است:
$ git clone "REPASITORY URL"
- stage
در گیت پس از اعمال هرگونه تغییر در فایل‌های پروژه، باید فایل‌های جدید و تغییر یافته در حالت stage قرار گیرند.
stage وضعیتی است که در آن گیت آماده است تا تغییرات پروژه را ثبت و commit کند.
برای track کردن فایل‌هایی که هنوز توسط git شناسایی نشده‌اند (untracked files) و اضافه کردن آن‌ها به حالت statge، دستور زیر را وارد می‌کنیم:
$ git add "FILE"
این دستور هرفایل را جدا جدا و با ذکر نام فایل اضافه می‌کند.
$ git add -A
با این دستور همه modified fileها در حالت stage قرار می‌گیرند.
اگر خواستیم فایلی را از حالت stage خارج کنیم تا در مرحله بعد commit نشود، از دستور زیر استفاده می‌کنیم:
$ git reset "FILE"
با اعمال این دستور، تغییرات مورد نظر بعد از تنظیم مجدد unstaged می شود.
- commit
با دستور commit، فایل‌های تغییریافته‌ای که در حالت stage قرار گرفته‌بود، به آرشیو گیت اضافه می‌شود و جایگزین فایل‌های قبل از تغییر می‌گردد. (هرچند دسترسی به تاریخچه تغییرات و همه فایل‌های قبلی نیز میسر است.) در واقع git یک snapshot از وضعیت فعلی پروژه در این زمان را، در تاریخچه خود ثبت می‌کند.
دستور ثبت و ذخیره snapshot فعلی از repo:
$ git commit
$ git commit -m "COMMIT MESSAGE"
به جای COMMIT MESSAGE توضیح مختصری از تغیرات صورت گرفته در فایل ها درج شود.
- status
در هر یک از مراحل فوق می‌توانیم وضعیت تغییرات فایل‌ها و قرارگیری آن‌ها در هر مرحله را با دستور زیر دنبال کنیم:
$ git status
- log
هر تغییری که توسط هر یک از اعضا در پروژه commit می‌شود در git ذخیره می‌شود. می‌توان با دستور زیر خلاصه‌ای از همه تغییرات را از commit اولیه تا کنون مشاهده کرد:
$ git log
خروجی این دستور شامل Hash Number ِ کامیت مورد نظر، تاریخ ایجاد کامیت، اطلاعاتی مثل اسم و ایمیل Author و ایجاد کننده کامیت، و توضیحاتی که به عنوان Commit Message درج شده‌است، می‌باشد.
- push
وقتی که روی یک local repository در سیستم شخصی خود کار می‌کنیم، لازم است در نهایت پروژه را به یک remote repository که نسخه‌ای از مخزن پروژه ما بر روی شبکه است، برای همکاری بیشتر با سایر اعضا، منتقل کنیم.
دستور انتقال و فرستادن تغییرات مخزن محلی به مخزن شبکه:
$ git push
- pull
وقتی که روی یک local repository در سیستم شخصی خود کار می‌کنیم، برای مشارکت بهتر در پروژه، لازم است همواره به آخرین ورژن از تغییرات remote repository دسترسی داشته باشیم تا با آگاهی از آخرین تغییراتی که سایر اعضا در پروژه ایجاد کرده‌اند (remote changes)، دچار مغایرت در نسخه و merge conflict نشویم.
این مغایرت در نسخه از آن جایی حاصل می‌شود که کامیت‌های قبلی دو نسخه ازیک فایل در مخزن محلی و مخزن راه دور یکسان نباشند. یعنی پیش از اینکه تغییرات اعمالی خود را بر روی مخزن راه دور push کنیم، فرد دیگری کامیت قبلی فایل مورد نظر ما را تغییر داده و push کرده است. در اینجا برای پیشگیری از merge conflict لازم است ابتدا نسخه مخزن راه دور را pull کنیم.
دستور دریافت آخرین نسخه از remote repo و همگام‌سازی سیستم با شبکه:
$ git pull
- branch
گاهی در فرآیند توسعه یک پروژه لازم است که که افراد به موازات هم روی بخش‌هایی از پروژه اصلی کار کنند، و بعد آن تغییرات را با پروژه اصلی ادغام کنند. راه‌حل هوشمندانه‌ای که git در این باره درنظر گرفته‌است استفاده از مفهوم branch / شاخه است.
پروژه اصلی روی شاخه‌ی master قرار می‌گیرد و تمام commitهای ما به طور پیش‌فرض روی شاخه master به طور خطی پیش می‌روند. اما هر فرد می‌تواند از پروژه اصلی در هر مرحله‌ای که بود، یک انشعاب جدید درست کرده و کار خود را در آن شاخه، به موازات شاخه اصلی جلو ببرد. نکته مهم این است که commitهایی که در این شاخه‌ها انجام می‌شوند کاملا از هم و از شاخه master جدا هستند و در بدنه اصلی برنامه تغییری ایجاد نمی‌کنند. در نهایت می توان این شاخه‌ها را حذف یا در صورت تأیید با بدنه اصلی برنامه ترکیب کرد تا تغییرات منتشر شوند.
دستور نشان دادن branchهای موجود:
$ git branch
در خروجی این دستور، اسم شاخه‌ای را که بر روی آن قرار گرفته‌ایم با علامت * مشخص شده‌است.
دستور ساخت branch جدید:
$ git branch "BRANCH NAME"
دستور رفتن به branch دیگر:
$ git checkout "BRANCH NAME"
دستور حذف branch:
$ git branch -d "BRANCH NAME"
- fork
در github می‌توان به پروژه‌هایی که دیگر افراد بارگذاری کرده‌اند دسترسی داشت و در آن‌ها مشارکت کرد. برای این کار از امکان fork کردن در گیت‌هاب استفاده می‌کنیم.
fork این اجازه را می‌دهد که روی پروژه مورد نظر در یک مخزن مجزا کار کنیم. با fork کردن یک پروژه، یک نسخه جداگانه از مخزن پروژه در اکانت ما کپی می‌شود که می‌توان با clone کردن و ساخت مخزن محلی در سیستم به توسعه آن پرداخت. پس از اعمال تغییرات لازم، چون به مخزن اصلی پروژه دسترسی نداریم که تغییرات را مستقیماً روی آن بنویسیم، باید برای آن فرد pull request فرستاد تا در صورت تأیید، نسخه تغییر یافته را با نسخه اصلی خود merge کند.
- merge
پس از اعمال تغییرات در بخش‌های مختلف برنامه که به موازات پروژه اصلی پیش رفته‌اند، در صورت تأیید باید آن‌ها را با بدنه اصلی برنامه merge / ادغام کرد تا برای همه اعضا در دسترس باشد.
دستور ادغام شاخه‌ها با بدنه اصلی برنامه:
$ git merge "BRANCH NAME"
دستور ادغام دو شاخه با یکدیگر:
$ git merge "BRANCH NAME1" "BRANCH NAME2"
از Distributed VCSها است و هم‌زمان با git تولید شد. اما در مقابل محبوبیت git موفقیت کمتری کسب کرد، با این حال در توسعه پروژه‌های بزرگی مانند Open Office مورد استفاده قرار گرفت.
در سیستم عامل‌های Microsoft Windows و Unix-like پشتیبانی می‌شود و مفاهیمی بسیار شبیه به git دارد (مثل branching و merging ). این برنامه بیشتر از طریق خط فرمان کنترل می‌شود اما رابط‌های گرافیکی هم برای آن در نظر گرفته‌اند (مثل TortoiseHg).
از قدیمی‌ترین سیستم‌های کنترل نسخه Centralized می‌باشد که در سال 1980 منتشر شد.در بین توسعه‌دهندگان پروژه‌های متن‌باز و تجاری محبوبیت زیادی کسب کرد. هرچند امروزه تقریبا استفاده از آن منسوخ شده‌است.