ورژن کنترل چیست و گیت چگونه به روند توسعه سریع محصولات الکترونیکی کمک می کند ؟

امروزه در دنیای الکترونیک و برنامه نویسی مدرن از ابزارهای ورژن کنترل تقریبا در تمامی پروژه های نرم افزاری و سخت افزاری استفاده می شود. ورژن کنترل ابزاری است که به توسعه دهندگان اجازه می‌دهد بدون نگرانی اشتباه کنند! چرا که اشتباهاتشان از طریق ابزار ورژن کنترل قابل پیگیری، بررسی و تصحیح می باشد. البته این مورد تنها یکی از کاربردهای بی نظیر سیستم‌های ورژن کنترل است. از ورژن کنترل در محصولات الکترونیکی در هر دو بخش سخت افزار و نرم افزار استفاده می شود چرا که در هر دو بخش، ورژن های مختلفی در طول زمان ایجاد می شود که اصلاحات و بهبود هایی نسبت به ورژن قبلی در آن صورت می گیرد و ممکن است بنا به روند پروژه امکانات جدیدی نیز به آن اضافه شود. به علت ویژگی های ذاتی سخت افزار، تعداد ورژن های سخت افزاری معمولا همیشه از تعداد ورژن های نرم افزاری کمتر است. چرا که تغییرات سخت افزاری نیاز به ساخت مجدد داشته و قابلیت تغییر کمتری نسبت به نرم افزار دارد. در پروژه های الکترونیکی کوچک و تک نفره ( مانند پروژه های دانشگاهی ) استفاده از ابزارهای ورژن کنترل اغلب کارایی چندانی ندارد اما با این حال کمک قابل توجهی به تسریع روند انجام آن به طراح پروژه می کند. در پروژه های متوسط صنعتی تر تک نفره ( مانند پروژه های خانگی و صنایع کوچک ) استفاده از ابزارهای ورژن کنترل توصیه می شود چرا که در 99.9 درصد مواقع، خطا در طراحی سخت افزار یا نرم افزار وجود دارد که بعدا مشخص می شود و این خطاها می بایست اصلاح شده و ورژن جدید تولید و جایگزین ورژن قبل شود. در نهایت در پروژه های کاملا صنعتی و چند نفره که در آن طراحان سخت افزار و نرم افزار به صورت تیمی روی آن کار می کنند ( مانند پروژه های صنایع خودروسازی، پزشکی، نفت و گاز و پتروشیمی و … ) استفاده از ابزارهای ورژن کنترل الزامی است چرا که بدون آن روند توسعه تیمی بسیار کند و دشوار می شود. بنابراین یک طراح تا زمانی که با نرم افزار ورژن کنترل آشنایی نداشته باشد، هرگز نخواهد توانست برچسب حرفه‌ای روی خود بزند.

---

ورژن کنترل چیست ؟

ورژن کنترل ( Version Control ) نرم افزاری برای کنترل سورس انواع پروژه ها می باشد. از این رو به آن سورس کنترل ( Source Control ) نیز گفته می شود. ورژن کنترل در حقیقت همان مدیریت سورس کد یا SCM ( مخفف Source Code Management ) می باشد. سیستم های ورژن کنترل یا VCS ( مخفف Version Control System )، سیستم هایی هستند که از ابزارهای ورژن کنترل استفاده می کنند. استفاده از نرم افزار ورژن کنترل بهینه ترین راه برای تیم های توسعه ( development team ) است. هر چه تیم بزرگتر شود و افراد بیشتری اضافه شوند تاثیر این سیستم در افزایش سرعت و بالا رفتن کارایی و چابکی تیم ها افزایش می یابد.

نرم افزار ورژن کنترل قادر است تغییرات نسخه های مختلف یک پروژه را ردیابی و مدیریت نماید. بنابراین توسعه دهندگان میتوانند با استفاده از آن ها تغییرات در سورس فایل های پروژه خود را در طول زمان های مختلف ثبت کرده و در موقع نیاز به ورژن مورد نیاز بازگردند. همچنین با استفاده از این سیستم می توان، به صورت تیمی روی بخش های مختلف یک پروژه کار کرده و آن را سریع تر و هوشمند تر توسعه داد. سیستم ورژن کنترل تمامی تغییرات فایل ها را در نوعی بانک اطلاعاتی ذخیره می کند. در صورتی که اشتباهی رخ دهد، توسعه دهندگان میتوانند اصطلاحا زمان را به عقب برگردانده و با مقایسه نسخه فعلی با نسخه های قدیمی تر، با کمترین زحمت و استرس مشکل را پیدا کرده و رفع کنند.

تقریبا در تمامی پروژه ها، سورس فایل ها ( Source Files ) یک جواهر بی بدیل و اصلی ترین سرمایه گروه است که باید بشدت از آن محافظت شود. سورس پروژه حاوی اطلاعاتی بی نهایت ارزشمند و راه حل مشکلاتی است که کل تیم وقت گرانبهای خود را روی پیدا کردن آنها گذاشته اند. ورژن کنترل از این سورس فایل ها در برابر فجایعی که بی دقتی عوامل انسانی گاه به گاه بوجود می آورد، محافظت می کند.

برنامه نویسان در تیم های توسعه ( develop )، بطور مداوم در حال نوشتن کدهای جدید و تغییر در کد های قدیمی هستند. معمولا کدهای یک پروژه نرم افزاری در یک ساختار درختی درون چندین folder قرار میگیرد. ممکن است یک برنامه نویس روی یک ویژگی ( feature ) جدید کار کند در حالی که یک برنامه نویس دیگر در حال برطرف کردن یک باگ در جای دیگر پروژه است، هر برنامه نویس ممکن است تغییراتشان را در قسمت های مختلف پروژه اعمال کنند و ممکن است در این عملیات تداخلی بین کد های جدید برنامه نویسان مختلف بوجود بیاید.

ورژن کنترل برای مدیریت کردن و رفع اینگونه مشکلات بوجود آمده است، یعنی ردگیری تمامی تغییرات توسط همه افراد تیم و کمک به جلوگیری از تعارضات میان کدهایی که همزمان توسط افراد مختلف تیم نوشته می شوند. تغییراتی که توسط یک برنامه نویس در قسمتی از برنامه اعمال می شود ممکن است با کدهای جدیدی که توسط برنامه نویس دیگری در همان زمان نوشته می شود ناسازگاری داشته باشد. این ناسازگاری باید توسط یک سیستم، آشکار و حل شود بدون اینکه در کار تیمی برنامه نویسان ایجاد اختلال کند. از سوی دیگر هر تغییری در یک نرم افزار و یا افزودن یک ویژگی (feature) به آن بدون شک باگ هایی ایجاد می کند و تا زمان تست نهایی، نرم افزار جدید غیر قابل اعتماد است. بنابراین مراحل انجام تست و توسعه تا زمان آماده بودن نسخه جدید همزمان با هم باید انجام شود.

یک سیستم ورژن کنترل ( VCS ) خوب، جریان کار ( workflow ) ارجح و معمول برنامه نویس را مختل نمیکند و کاربران را مجبور به استفاده از یک شیوه منحصر به فرد نمیکند. ایده آل آن است که ورژن کنترل روی هر پلتفرمی کار کند نه این که یک سیستم عامل یا زنجیره ای ابزارها را به برنامه نویسان تحمیل کند. از دیگر خصوصیات یک سیستم ورژن کنترل خوب این است که تغییرات کدها را بصورت یک جریان نرم و مداوم تسهیل کند نه اینکه با یک مکانیزم سفت و سخت قفل کردن فایل ها، فقط اجازه تغییر به یک برنامه نویس دهد و قابلیت تغییر را از دیگران سلب کند.

تیم هایی که از سیستم ورژن کنترل استفاده می کنند دچار مشکلاتی خواهند شد مانند اینکه کدام تغییرات ایجاد شده برای کاربران در دسترس است و یا زمانی که دو برنامه نویس تغییراتی در کدها ایجاد میکنند و این تغییرات با هم ناسازگار است، رفع این مشکل بسیار زمانبر و پردردسر خواهد بود. اگر تابحال از ورژن کنترل استفاده نکرده باشید احتمالا نسخه های جدید نرم افزارتان را با فایل هایی با پسوندی نظیر “final” و یا “latest” نام گذاری میکنید در صورتی که در مراحل بعدی باز هم نسخه های جدیدی از نرم افزارتان خواهید ساخت. ممکن است قسمت هایی از کدهایتان را comment کنید تا لازم نباشد برای غیر فعال کردن برخی از کارکردهای برنامه تان، آن قسمت ها را حذف کنید، چون فکر میکنید ممکن است بعدا به آنها نیاز داشته باشید. ورژن کنترل آماده است که این دردسر ها را برایتان رفع کند.

نرم افزار ورژن کنترل امروزه به یک بخش حیاتی از فعالیت هر روزه تیم های مدرن ساخت نرم افزار تبدیل شده است. برنامه نویسانی که در تیم های بزرگ با قابلیت های سیستم های ورژن کنترل آشنا شده اند، در می یابند که حتی در برنامه های کوچک که بصورت انفرادی ساخته می شوند این سیستم چه قابلیت های شگفت انگیزی به آنها ارائه می کند. امروزه و پس از آشکار شدن قابلیت های هیجان انگیز و بی نظیر سیستم های ورژن کنترل، برنامه نویسان کار کردن بدون آن را حتی در پروژه های غیر نرم افزاری، دیگر به مخیله خود هم راه نمی دهند.

---

مزایای سیستم های ورژن کنترل

«سیستم‌های ورژن کنترل » (Version Control Systems | VCS) طی چند دهه اخیر شاهد بهبودهای قابل توجهی بوده‌اند. برخی از VCS‌ها، بهتر از برخی دیگر هستند. سیستم کنترل نسخه، گاهی نیز با عنوان ابزارهای «مدیریت کد منبع» (Source Code Management | SCM) یا «سیستم کنترل بازنگری» (Revision Control System | RCS) شناخته می‌شود. یکی از محبوب‌ترین ابزارهای سیستم کنترل نسخه، نرم‌افزار گیت است. گیت، یک «سیستم کنترل نسخه توزیع شده» (Distributed VCS) (دسته‌ای که با عنوان DVCS شناخته شده است) محسوب می‌شود. در بخش‌های بعدی این مطلب، به طور کامل به گیت پرداخته خواهد شد. همچون دیگر انواع سیستم‌های کنترل نسخه محبوبی که این روزها در دسترس توسعه‌دهندگان هستند، گیت نیز رایگان و متن‌باز است.

صرف‌نظر از اینکه نام این سیستم‌ها چیست و کدام سیستم توسط کاربر استفاده می‌شود، مزایای اولیه‌ای که از سیستم کنترل نسخه انتظار می‌رود، به شرح زیر است :

1. تاریخچه (History) کامل و بلند مدت از هر فایل: یعنی همه تغییراتی که توسط کلیه افراد و طی سال‌ها روی هر فایلی انجام شده، موجود خواهد بود. این تغییرات شامل ساختن و حذف فایل‌ها و همچنین، ویرایش محتوای آن‌ها می‌شود. ابزارهای VCS گوناگون، در چگونگی مدیریت تغییر نام و جابجایی فایل‌ها با یکدیگر متفاوت هستند. این تاریخچه ممکن است شامل نام پدیدآورنده، تاریخ و یادداشت‌های نوشته شده پیرامون هر تغییر شود. داشتن تاریخچه کامل، امکان بازگشت به نسخه‌های پیشین را برای کمک به تحلیل‌های ریشه‌ای اشکالات (باگ‌ها) فراهم می‌کند و هنگامی که نیاز به رفع اشکال در نسخه‌های قدیمی‌تر نرم‌افزار است، قابلیتی حیاتی محسوب می‌شود. اگر نرم‌افزار به طور فعالانه‌ای کار کند، تقریبا هر چیزی را می‌توان به عنوان نسخه قدیمی‌تر نرم‌افزار در نظر گرفت.
2. امکان انشعاب و ادغام (Branching and Merging): به کار گرفتن اعضای یک تیم پروژه به گونه‌ای که به صورت هم‌زمان روی یک پروژه کار کنند، کار عاقلانه‌ای نیست؛ مگر آنکه هر فرد روی بخشی کار کند که کاملا مستقل از بخش های دیگر باشد. ساخت یک انشعاب در سیستم ورژن کنترل، چندین جریان کاری را مستقل از یکدیگر نگه می‌دارد و در عین حال، امکان ادغام این تلاش‌ها با یکدیگر را فراهم می‌کند. این امر، توسعه‌دهندگان را قادر می‌سازد تا تایید کنند که تغییرات در هر شاخه، با دیگر شاخه‌ها ناسازگار نیستند. بسیاری از تیم‌های نرم‌افزاری، امکان انشعاب برای هر ویژگی یا حتی انشعاب برای هر «انتشار» یا هر دو این موارد را فراهم می‌کنند. جریان‌های کاری متفاوتی وجود دارد که تیم‌ها می‌توانند هنگام تصمیم‌گیری پیرامون چگونگی استفاده از تسهیلات انشعاب و ادغام در سیستم‌های کنترل نسخه، از میان آن‌ها انتخاب کنند.
3. قابلیت ردیابی (Traceability): وجود قابلیت ردیابی برای پیگیری هر تغییری که در نرم‌افزار انجام شده و مرتبط کردن آن به مدیریت پروژه و نرم‌افزارهای ردیابی باگ‌ مانند «جیرا» (Jira) و وجود توانایی حاشیه‌نویسی برای هر تغییر با متنی که هدف و نیت تغییر را مشخص می‌کند، به تحلیل ریشه‌ای دلایل تغییر کمک می‌کند. داشتن تاریخچه حاشیه‌نویسی شده برای ردپای توسعه‌دهنده، در هنگام خواندن کد برای فهمیدن کاری که انجام می‌دهد و دلیل طراحی آن به این صورت، به توسعه‌دهنده کمک می‌کند که تغییرات درست و هماهنگی را انجام دهد که با طراحی بلند مدت مورد نظر سیستم سازگار است. این ویژگی، به طور ویژه برای کار کردن موثر با کدهای موروثی نیست و در توانمندسازی توسعه‌دهندگان برای تخمین کارهای بعدی با هر میزانی از صحت، نقش حیاتی دارد.

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

---

دسته بندی انواع سیستم های ورژن کنترل

سیستم‌های ورژن کنترل به دو دسته Distributed و Centeralized تقسیم می‌شوند. تفاوت اصلی این دو دسته در شیوه ذخیره سازی داده‌ها می‌باشد. در ادامه به بررسی هر کدام از این سیستم‌ها می‌پردازیم :

• سیستم‌های کنترل ورژن متمرکز یا Centeralized : در این نوع VCS‌ها تمام داده‌ها بر روی یک سرور مرکزی ذخیره می‌شوند و شیوه دسترسی به اطلاعات به صورت Client / Server می‌باشد. یعنی اگر برنامه نویسان بخواهند تغییراتی در پروژه ایجاد کنند باید به سرور مرکزی متصل باشند، در غیر اینصورت نمی‌توانند به اطلاعات پروژه دست پیدا کنند. از مهمترین سیستم های کنترل ورژن متمرکز میتوان آپاچی ساب‌ورژن (Apache Subversion) به اختصار SVN و سیستم نسخه‌های هم‌روند (Concurrent Versions System) به اختصار CVS را نام برد.
• سیستم‌های کنترل ورژن توزیع شده یا Distributed : در این نوع سیستم ها، اطلاعات پروژه در دسترس هر یک از برنامه نویسان قرار می‌گیرد و هر وقت که بخواهند می‌توانند تغییرات مورد نظرشان در آن ایجاد و سپس در زمان مد نظرشان آن‌ها را با سرور همگان سازی کنند. مزیت این VCS‌ها این است که اگر سرور اصلی در دسترس نبود، همچنان برنامه نویسان می‌توانند تغییرات ایجاد شده را در سیستم خودشان اعمال کنند. سپس در زمانی که ارتباط با سرور برقرار شد، اطلاعات و تغییرات آن‌ها با سرور اصلی هنگام سازی می‌شود. یکی از مهمترین و محبوب ترین سیستم‌های کنترل ورژن توزیع شده، GIT می‌باشد. این ورژن کنترل سیستم، توسط لینوس توروالدز (Linus Torvalds)، خالق و توسعه‌دهنده هسته لینوکس، در سال ۲۰۰۵ میلادی به صورت رایگان و متن باز ساخته شد.

منظور از توزیع شده بودن گیت آن است که هر توسعه‌دهنده (Developer)، تاریخچه کامل مخزن کد خود را به صورت محلی دارد. این امر موجب می‌شود که کلون (Clone) (کپی کردن) اولیه از مخزن کندتر باشد، اما عملیات بعدی مانند کامیت (Commit) (اعمال کردن)، بلِیم (Blame)، دیف (Diff)، مِرج (Merge) (ادغام کردن) و لوگ (Log) (ثبت سوابق) به طور چشم‌گیری سریع‌تر انجام شود. همچنین، گیت دارای پشتیبانی خوبی برای انشعاب (Branching)، ادغام (Merging) و بازنویسی تاریخچه مخزن است. این ویژگی‌ها منجر به جریان‌های کاری (Workflows) و ابزارهای نوآورانه و قدرتمندی می‌شود. درخواست پول (Pull Requests) (دریافت تغییرات از روی تاریخچه) یکی از این ابزارهای محبوبی است که به تیم‌ها این امکان را می‌دهد تا در انشعاب‌های سیستم کنترل نسخه گیت با یکدیگری همکاری داشته باشند و کدهای یکدیگر را به صورت موثری بازبینی کنند. گیت پر استفاده‌ترین سیستم کنترل نسخه در جهان کنونی است و به عنوان یک استاندارد نوین برای توسعه نرم‌افزار در نظر گرفته می‌شود. شکل زیر نمونه ای از تفاوت های میان دو سیستم ورژن کنترل توزیع شده و متمرکز را نشان می دهد.

در شکل زیر لیستی از محبوب ترین سیستم های ورژن کنترل شناخته شده در جهان نشان داده شده است. محبوب ترین سیستم ورژن کنترل شناخته شده در جهان گیت می باشد که توسط لینوس توروالدز ساخته شده است. بعد از آن سیستم ورژن کنترل Subversion که به اختصار SVN گفته می شود توسط بنیاد نرم افزاری Apache ساخته شده است. ورژن کنترل بعدی CVS می باشد که مخفف Concurrent Versions System بوده و از قدیمی ترین ورژن کنترل های شناخته شده می باشد که در حال حاضر استفاده از آن بسیار کم شده است. شرکت مایکروسافت هم با ارائه ورژن کنترل سیستم خود یعنی TFS ( مخفف Team Foundation Server ) و اتصال آن به نرم افزار Visual Studio به یکی از ابزارهای محبوب ویندوزی مبدل گشته است. از دیگر ورژن کنترل های پرکاربرد میتوان به mercurial، PerForce، AWS CodeCommit، Bazaar و Beanstalk اشاره کرد.

---

گیت چیست ؟

تاکنون، پر استفاده‌ترین سیستم کنترل نسخه مدرن در جهان، گیت بوده است. «گیت» (Git) یک پروژه بالغ متن‌باز است که به طور فعالانه‌ای از آن نگهداری می‌شود. این پروژه در سال ۲۰۰۵ توسط لینوس توروالدز توسعه داده شده است. لینوس، خالق و توسعه‌دهنده کرنل سیستم‌عامل لینوکس است.

تعداد فوق‌العاده زیادی از پروژه‌های نرم‌افزاری برای کنترل نسخه، به گیت تکیه دارند که شامل پروژه‌های تجاری و متن‌باز می‌شوند. توسعه‌دهندگانی که با گیت کار کرده‌اند، به خوبی خود را معرفی می‌کنند. گیت در طیف وسیعی در سیستم‌عامل‌ها و «محیط‌های توسعه یکپارچه» (Integrated Development Environment | IDE) کار می‌کند.

سیستم کنترل نسخه گیت به دلیل داشتن معماری توزیع شده، گونه‌ای از سیستم‌های کنترل نسخه توزیع شده (Distributed Version Control System | DVCS) محسوب می‌شود. به جای بهره‌مندی از تنها یک جای مجرد برای کل تاریخچه نسخه نرم‌افزار که حالتی بسیار متداول در سیستم‌های کنترل نسخه CVS یا SVN است، در گیت، کپی هر توسعه‌دهنده‌ای خود یک مخزن است که حاوی کل تاریخچه تغییرات است. علاوه بر توزیع شده بودن، گیت با در نظر داشتن کارایی، امنیت و انطاف‌پذیری طراحی شده است.

کارایی

مشخصه‌های مربوط به کارایی گیت در مقایسه با دیگر جایگزین‌های آن، بسیار قدرتمند است. کامیت (اعمال) کردن تغییرات جدید، برنچینگ (انشعاب)، «مِرجینگ» (ادغام) و مقایسه نسخه‌های قبلی، همه برای کارایی بهینه شده‌اند. الگوریتم‌هایی که درون گیت پیاده‌سازی شده‌اند، از مزیت داشتن دانش عمیق پیرامون خصیصه‌های متداول درخت‌های فایل کد منبع واقعی، چگونگی ویرایش شدن آن‌ها در طول زمان و چگونه بودن الگوهای دسترسی بهره می‌برند.

برخلاف برخی از دیگر سیستم‌های کنترل نسخه، گیت هنگام تعیین اینکه ذخیره‌سازی و تاریخچه نسخه درخت فایل چه باید باشد، به وسیله نام فایل گمراه نمی‌شود؛ در عوض، تمرکز اصلی روی محتوای خود فایل است. بالاخره، کد منبع فایل‌ها بارها تغییر می‌کند، تقسیم (Split) و بازسازمان‌دهی می‌شود. قالب شی فایل‌های مخزن گیت، از ترکیبی از «کدبندی دلتا» (Delta Encoding) (ذخیره‌سازی تفاوت محتوا)، مقایسه و ذخیره‌سازی صریح محتوای پوشه‌ها و شی‌های «فراداده» (Metadata) نسخه استفاده می‌کند.

گیت طراحی شده تا از انشعاب و تگ کردن به عنوان قابلیت‌های اصلی پشتیبانی کند (برخلاف SVN)، و عملیاتی که انشعاب‌ها و تگ‌ها را تحت تاثیر قرار می‌دهد (مانند ادغام یا بازگردانی) نیز به عنوان بخشی از تاریخچه تغییرات ذخیره می‌شوند. همه سیستم‌های کنترل نسخه در این سطح از پیگیری کار نمی‌کنند.

توزیع شده بودن، موجب کارایی قابل توجهی برای سیستم کنترل نسخه گیت می‌شود. برای مثال، یک توسعه‌دهنده به نام آلیس، تغییراتی را در کد منبع ایجاد و ویژگی را به نسخه بعدی که نسخه ۲.۰ است، اضافه می‌کند؛ سپس، این تغییرات را با یک پیام توصیفی کامیت (اعمال) می‌کند. سپس، روی دومین ویژگی کار می‌کند و این تغییرات را نیز کامیت می‌کند. طبیعتا، این موارد به عنوان بخش‌های جدایی از کار در تاریخچه نسخه ذخیره می‌شوند. سپس، آلیس به انشعاب نسخه ۱.۳ همان نرم‌افزار مراجعه می‌کند تا اشکالی (باگ) را حل کند که فقط این نسخه قدیمی را تحت تاثیر قرار داده است. هدف از این کار آن است که تیم آلیس قادر باشند نسخه رفع باگ شده ۱.۳.۱ را پیش از آماده شدن نسخه ۲.۰ داشته باشند. آلیس می‌تواند به انشعاب ۲.۰ بازگردد تا به کار خود روی ویژگی‌های جدید برای نسخه ۲.۰ پایان دهد و همه این کارها بدون داشتن هرگونه دسترسی شبکه‌ای قابل انجام است و بنابراین، این کار سریع و قابل اعتماد خواهد بود. آلیس حتی می‌تواند این کار را وقتی سوار هواپیما است انجام دهد. هنگامی که او آماده ارسال همه تغییراتی که به تنهایی آن‌ها را کامیت کرده به یک مخزن راه دور است، آلیس می‌تواند آن‌ها را با یک دستور «پوش» (Push | ارسال) کند.

امنیت

گیت با در نظر داشتن تمامیت کد منبع‌های مدیریت شده به عنوان یک اولویت اصلی، طراحی شده است. محتوای فایل‌ها، رابطه واقعی بین فایل‌ها و پوشه‌ها، نسخه‌ها، «تگ‌ها» (Tags) و کامیت‌ها در مخزن گیت با یک الگوریتم رمزنگاری امن «درهم‌سازی» (Hashing) به نام «اس‌اچ‌ای-وان» (SHA1 که به فارسی به آن شا-۱ نیز گفته می‌شود)، امن‌سازی شده است. این کار از کد و تغییر تاریخچه چه به طور تصادفی و چه به دلیل تغییرات مخرب، محافظت می‌کند و اطمینان حاصل می‌کند که تاریخچه به طور کامل قابل پیگیری است.

با استفاده از گیت، توسعه دهنده می‌تواند اطمینان حاصل کند که تاریخچه محتوای قابل اعتمادی از کد منبع خود دارد. برخی از دیگر سیستم‌های کنترل نسخه، هیچ محافظتی در مقابل تغییرات پنهانی در تاریخ‌های قدیمی‌تر ندارند. این امر یک آسیب‌پذیری امنیتی بسیار جدی و مهم برای هر سازمانی محسوب می‌شود که به توسعه نرم‌افزار متکی است.

انعطاف‌پذیری

یکی از اهداف کلیدی طراحی سیستم کنترل نسخه گیت، انعطاف‌پذیری است. گیت از جنبه‌های مختلفی انعطاف‌پذیر است که عبارتند از: پشتیبانی از انواع مختلفی از جریان‌های کاری غیر خطی توسعه، بهره‌وری هم در پروژه‌های کوچک و هم پروژه‌های بزرگ و سازگاری با بسیاری از سیستم‌ها و پروتکل‌های موجود.

گیت یک استاندارد غیر رسمی

گیت پذیرفته شده‌ترین ابزار از نوع خودش است. این امر موجب می‌شود که سیستم کنترل نسخه گیت به دلایلی که در ادامه بیان شده‌اند، جذاب باشد. تعداد زیادی از توسعه‌دهندگان در حال حاضر تجربه کار با گیت را دارند و بخش قابل توجهی از دانش‌آموختگان دانشگاهی نیز تنها تجربه کار با گیت را دارند. در حالی که برخی از سازمان‌ها ممکن است هنگام مهاجرت از دیگر سیستم‌های کنترل نسخه به گیت، نیاز به پیمودن منحنی یادگیری داشته باشند و نیروهای آن‌ها نیاز به فراگیری گیت داشته باشند، بسیاری از توسعه‌دهندگان کنونی و حتی آینده، نیز نیاز به اینکه در محل سازمان گیت را یاد بگیرند ندارند.

علاوه بر مزیت بیان شده، غالب بودن گیت بدین معنا است که بسیاری از ابزارهای نرم‌افزاری شخص ثالث و سرویس‌ها، در حال حاضر با گیت یکپارچه شده‌اند که از این جمله می‌توان به «محیط‌های توسعه یکپارچه» (Integrated Development Environment | IDE) و ابزارهای خود کاربر مانند کلاینت دسکتاپ DVCS به نام «سورس‌تری» (Sourcetree)، نرم‌افزار پیگیری مسائل و پروژه مانند «جیرا» (Jira) و سرویس میزبانی کد بیت‌باکت (Bitbucket)، گیت هاب ( Github ) و گیت لب ( Gitlab ) اشاره کرد. افرادی که توسعه‌دهنده بی‌تجربه هستند و قصد دارند مهارت‌های ارزشمندی را در حوزه توسعه نرم‌افزار به دست آورند، در بحث کنترل نسخه، حتما باید گیت (Git) را در لیست خود داشته باشند.

گیت، یک پروژه متن‌باز

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

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

متن‌باز بودن گیت (Git) موجب شده تا حتی افرادی که به عنوان سرگرمی کد می‌زنند نیز بدون پرداخت هزینه‌ای از گیت استفاده کنند. برای استفاده از کنترل نسخه در یک پروژه متن‌باز، گیت بدون شک جایگزین دیگر سیستم‌های کنترل نسخه موفق قدیمی مانند SVN و CVS است.

---

شروع به کار با گیت

پیش از اینکه بتوانید از گیت استفاده کنید باید آن را نصب کنید. برای نصب هسته اصلی گیت به وبسایت رسمی گیت به نشانی https://git-scm.com مراجعه کرده و نسخه متناسب باسیستم عامل خود را دانلود و نصب نمایید. آخرین نسخه گیت در هنگام نوشتن این مطلب نسخه 2.32.0 می باشد.

با دانلود هسته اصلی گیت دو ابزار به نام های Git Bash و Git GUI نصب می گردد. ابزار Git bash خط فرمان گیت است که مشابه با خط فرمان لینوکس یا cmd ویندوز می باشد و Git GUI رابط گرافیکی گیت است که به صورت گرافیکی و محدود میتوانید به مدیریت سورس فایل های خود بپردازید. روش‌های مختلفی برای استفاده از گیت وجود دارد. ابزارهای خط فرمان و بسیاری از رابط‌های کاربری گرافیکی دیگری نیز با قابلیت‌های مختلف وجود دارد که بر اساس گیت کار می کند( برای دیدن لیست کاملی از این ابزارها به > این لینک مراجعه نمایید). همه این ابزارها بر اساس گیت در خط فرمان می باشد که ما هم از همان استفاده خواهیم کرد. چرا که فقط خط فرمان به شما این امکان را می‌دهد که بتوانید همه دستورات گیت را اجرا کنید ( اکثر رابط‌های گرافیکی جهت ساده بودن فقط بخش جزئی از کارکرد گیت را پیاده‌سازی می‌کنند) اگر می‌دانید که چگونه نسخه خط فرمان را اجرا کنید، احتمالاً می‌توانید از نحوه اجرای نسخه رابط گرافیکی نیز سر دربیاورید، اما برعکس آن لزوماً ممکن نیست. همچنین ممکن است که انتخاب کلاینت گرافیکی حاصل سلیقه شخصی شما باشد، اما همه کاربران همیشه رابط واحد خط فرمان را نصب و در دسترس دارند. بعد از نصب شدن گیت برای راه اندازی کافی است در پوشه مورد نظر خود کلیک راست کرده و یکی از گزینه های Git Bash Here یا Git GUI Here را بزنید تا وارد دنیای گیت شوید.

---

آشنایی با دستورات اولیه کار با گیت

سیستم ورژن کنترل گیت، با تایپ کردن دستورات بیان شده در زیر درون خط فرمان ( Git Bash )، عملیات مدیریت سورس فایل های پروژه را انجام می‌ دهد :

۱. پیکربندی گیت

بعد از نصب گیت، اولین کاری که باید انجام دهید پیکربندی گیت است. برای یک پیکربندی اولیه، دو دستور گیت وجود دارد که باید بدانید. اولین دستور مربوط به ثبت نام نویسنده و دومین ثبت ایمیل نویسنده است. از آن به بعد گیت تمام تغییرات را با استفاده از این مشخصات ثبت می‌کند.

---

۲. ساخت یک مخزن ( Repository ) خالی

برای ساخت یک مخزن گیت از دستور git init استفاده می شود. با اجرای این دستور یک پوشه به نام git. به صورت Hidden ایجاد می شود که درون آن دیتابیس گیت قرار دارد.

---

۳. بررسی وضعیت مخزن

با استفاده از دستور git status میتوان وضعیت مخزن گیت را بررسی نمود.

با اجرای دستور فوق دو موضوع مهم به اطلاع کاربر می رسد. اول اینکه در کدام شاخه ( branch ) هستیم. همواره در اولین استفاده از این دستور در شاخه اصلی برنامه هستیم که به آن شاخه مستر ( master branch ) نیز گفته می شود. موضوع دوم وضعیت تغییرات فایل ها می باشد. سه وضعیت کلی که در پروژه‌های گیت وجود دارد، شامل موارد زیر می‌شود:

• staged
• committed
• modified

در واژه‌شناسی مربوط به گیت، فایل‌ها بعد از اینکه ذخیره و آماده کامیت کردن شدند، در مرحله staged قرار می‌گیرد. بعد از اینکه فایل‌ها در یک دیتابیس محلی واقع در پوشه git. قرار گرفتند به وضعیت committed تغییر پیدا می‌کنند. و وقتی که تغییراتی در آن‌ها قرار دادید اما آن‌ها (تغییرات) را هنوز کامیت نکرده‌اید، به وضعیت modified در می‌آیند. شکل زیر این وضعیت ها و نحوه ارتباط آن ها با هم را نشان می دهند.

۴. Stage کردن فایل‌ها

بعد از هر بار تغییر ( حذف فایل، افزودن فایل، تغییر محتوای فایل ) با استفاده از دستور git add این تغییرات را به پیگیری ( tracking ) گیت اضافه می کنیم.

دستور فوق فایل‌های index.html و style.css و پوشه images را به وضعیت Stage در می‌‌آورد. اگر می‌خواهید تمام موارد قرار گرفته در پوشه‌ای که در حال کار هستید را به حالت stage در بیاورید و دیگر نام آن ها را ننویسید، کافی است دستور زیر را وارد کنید:

اگر یک دایرکتوری سنگین و پر از فایل‌های مختلف دارید، دستور فوق بسیار کاربری خواهد بود.

---

۵. Unstage کردن فایل‌ها

می‌توانید به سادگی فایل‌ها را از قسمت stage نیز حذف کنید:

برای اینکه تمام فایل‌ها و دایرکتوری‌ها را یکجا حذف کنید می‌توانید به صورت زیر عمل کنید:

---

۶. Commit کردن فایل‌های Stage شده

می‌توانید از ناحیه stage مربوط به پروژه‌تان در هر زمان یک ذخیره مانند بگیرید. این حالت را کامیت کردن می‌نامند و فایل‌ها را به بانک اطلاعاتی ارسال می‌کنند.

همواره با ارسال فایل‌های stage یک پیغام ( message ) نیز نوشته می‌شود. برای اینکه بهتر بتوانید کامیت‌های‌تان را قابل استفاده کنید و افراد مختلف کار آن را درک کنند از این پیغام‌ها استفاده کنید.

---

۷. نمایش جزئیات تغییرات فایل های Unstaged نسبت به آخرین کامیت

برای اینکه بتوانید تمام تغییرات اتفاق افتاده در یک مخزن گیت را نسبت به آخرین کامیت ثبت شده در مخزن گیت مشاهده کنید، می‌توانید از دستور زیر استفاده نمایید:

این دستور نه تنها نام فایل‌ها را برمی‌گرداند بلکه تغییرات درونی مربوط به آن‌ها را نیز در قالب متن به شما برگشت می‌دهد. این دستور موارد اضافی را با +++ و موارد حذف شده را با — نمایش می‌دهد.

---

۸. نمایش تاریخچه کامل کامیت‌ها

گیت همچنین به شما اجازه می‌دهد تا تاریخچه کامل کامیت‌های‌تان را در پروسه توسعه مشاهده کنید. برای انجام این کار می‌توانید دستور زیر را وارد کنید:

خروجی دستور فوق شامل آی‌دی، نویسنده، تاریخ و پیغام های ذخیره شده مربوط به هر کامیت است. هر کامیت دارای آی دی منحصر به فردی است که با آن Hash ID نیز گفته می شود که توسط یک تابع هش ( Hash Function ) ساخته می شود. الگوریتم این تابع هش SHA-1 نام دارد که به منظور شناسایی هر کامیت استفاده می شود.

---

۹. بازگشت به آخرین کامیت

برای بازگشت کلیه فایل ها به آخرین کامیت از دستور زیر استفاده می شود:

این دستور زمانی که تغییراتی در یک یا چند فایل داده ایم و نمیخواهیم آن ها را کامیت کنیم ( مثلا وقتی یک کد جدید نوشتیم و کار نمی کند ) کاربرد دارد. البته این دستور روی فایل های پیگیری نشده ( Untracked ) تاثیری نمی گذارد.

---

۱۰. بازگشت به کامیت دلخواه

برای بازگشت به کامیت دلخواه از دستور زیر استفاده می شود:

که در آن Hash ID آی دی منحصر به فرد کامیتی است که میخواهیم به آن برگردیم. دقت کنید بعد از دستور فوق همه چیز به کامیت مورد نظر برمی گردد بنابراین به کامیت های بعدی دسترسی نخواهیم داشت مگر اینکه آی دی آن ها را قبل از اجرای این دستور توسط دستور git log گرفته باشیم و آن ها را ذخیره کرده باشیم.

---

۱۱. ایجاد یک شاخه ( branch ) جدید

دستور زیر کلیه شاخه های موجود در پروژه را نمایش می دهد:

زمانی که با استفاده از گیت یک ریپازیتوری جدید می‌سازیم، به صورت خودکار یک برنچ (شاخه) تحت عنوان master ساخته می‌شود که نقش شاخهٔ اصلی ریپازیتوری مذکور را بازی خواهد کرد و هر کامیتی که انجام دهیم نیز روی این شاخه اِعمال خواهد شد. اما میتوان با استفاده از دستور زیر شاخه جدید ساخت :

با اجرای دستور فوق یک شاخه جدید به نام develop ایجاد شده و سیستم کنترل ورژن گیت به آن سوئیچ می کند. برای سوئیچ کردن به یک شاخه موجود از پیش تعریف شده از دستور فوق بدن b- استفاده می شود. برای پاک کردن شاخه develope نیز از دستور زیر استفاده می شود.

---

۱۲. ادغام کردن ( merge ) یک شاخه با شاخه اصلی

ابتدا با استفاده از دستور git checkout master به شاخه اصلی می رویم و سپس برای ادغام یک شاخه دلخواه از دستور زیر استفاده می کنیم :

این دستور ممکن است با خطای conflict مواجه شود که در آن صورت بایستی خطای مورد نظر را رفع و سپس دستور فوق را اجرا نمود.

---

۱۳. کلون کردن یک مخزن ریموت

دستوراتی که همراه با ابزارهای آنلاینی مانند گیت‌هاب و… استفاده می‌شوند از جمله کاربردی‌ترین دستورات مربوط به گیت است. برای اینکه یک کپی محلی از یک مخزن گیت آنلاین داشته باشید می‌توانید دستور زیر را در دایرکتوری دلخواه ( یک پوشه خالی ) اجرا نمایید:

---

۱۴. ایجاد ارتباط با مخزن ریموت

جدای از اینکه می‌توانید یک مخزن را دریافت کنید، می‌توانید به صورت برعکس نیز عمل نمایید. برای کپی کردن یک مخزن محلی در یک سرور آنلاین مانند گیت‌هاب، ابتدا نیاز است که یک ارتباط را با مخزن آنلاین داشته باشید، پس از آن مخزن محلی را به سرور push کنید:

با استفاده از دستور بالا، مخزن آنلاین پروژه ( ریموت سرور ) به پروژه محلی‌تان ( Local ) متصل می گردد. بعد از اجرای این دستور هر کجا که بخواهید با ریموت سرور ارتباط برقرار کنید می‌توانید از طریق نام origin این ارتباط را برقرار کنید.

---

۱۵. Push‌ کردن تغییرات محلی به مخزن آنلاین

بعد از اینکه ارتباط بین مخازن آنلاین و محلی را ایجاد کردید، می‌توانید تغییرات یکی از شاخه ها را با استفاده از دستور زیر push کنید:

با اجرای دستور فوق آخرین تغییرات پوشه محلی در شاخه master به سرور آنلاین انتقال می یابد. دقت کنید در دستور فوق کلمه کلیدی origin برای اشاره به مخزن آنلاین استفاده می‌شود، در حالیکه master نام شاخه اصلی مخزن محلی است. برای پوش کردن هر شاخه بایستی این دستور را جداگانه اجرا کنید.

---

۱۶. ‌ Pull کردن تغییرات سرور به مخزن لوکال

بعد از اینکه ارتباط بین مخازن آنلاین و محلی را ایجاد کردید، می‌توانید تغییرات یکی از شاخه ها را با استفاده از دستور زیر pull کنید:

با اجرای دستور فوق آخرین تغییرات سرور آنلاین در شاخه master به پوشه محلی انتقال می یابد. دقت کنید در دستور فوق کلمه کلیدی origin برای اشاره به مخزن آنلاین استفاده می‌شود، در حالیکه master نام شاخه اصلی مخزن محلی است. برای پوش کردن هر شاخه بایستی این دستور را جداگانه اجرا کنید.

---

۱۷. دریافت آخرین تغییرات در مخزن آنلاین

اگر با یک مخزن آنلاین ارتباط دارید و قصد دارید تغییرات آن را مشاهده کنید، نیازی نیست که یک کپی از آن بگیرید، بجای آن می‌توانید با استفاده از دستور زیر به صورت بسیار ساده تغییرات را مشاهده کنید:

دستور git fetch تنها تغییرات را دریافت کرده و آن‌ها را به هیچ‌ جایی منتقل نمی‌کند. 

---

۱۸. انتقال تغییرات دریافت شده

وقتی که مطمئن شدید تغییرات هیچ مشکلی ندارند، بعد از آن می‌توانید تغییرات را به مخزن محلی خود انتقال دهید. برای انجام این کار می‌توانید از دستور زیر استفاده کنید:

همیشه برای انجام انتقال نیاز است که نام branch مورد نظرتان را معلوم کنید. در دستور بالا ما تغییرات را به branch مربوط به master انتقال داده‌ایم.

---

معرفی میزبان های ریپازیتوری در گیت ( ریموت سرور های اینترنتی گیت )

اگر می‌خواهید شروع به استفاده از محبوب ترین ورژن کنترل کنید، باید بدانید که کجا می‌توانید ریپازیتوری‌های خود را میزبانی کنید. پلتفرم‌های میزبانی به دو روش در دسترس هستند که یکی روش کلود (میزبانی آنلاین در بستر اینترنت) و دیگری میزبانی مستقل روی سرور شخصی (میزبانی خصوصی) است. پلتفرم‌های میزبانی آنلاین زیادی وجود دارند که می‌توانید کد خود را به طور رایگان روی آن‌ها میزبانی کنید. برخی گزینه‌ها رایگان نیستند، اما شما به جز در موارد خاص، به اغلب آن‌ها نیازی نخواهید داشت. در ادامه سه مورد از محبوب‌ترین سرویس‌های میزبانی آنلاین گیت را ملاحظه می‌کنید:

• گیت‌هاب (GitHub): در سال 2008 راه‌اندازی شده و اخیراً از سوی مایکروسافت خریداری شده است. در پاییز 1397 حدود 31 میلیون کاربر داشته است.
• گیت‌لب (GitLab): در سال 2011 راه‌اندازی شده و تحت مالکیت شرکت GitLab است.
• بیت‌باکت (BitBucket): در ژوئن 2008 راه‌اندازی شده است و تحت مالکیت شرکت نرم‌افزاری Atlassian قرار دارد.

---

مدیریت کدها با استفاده از شاخه ها ( branch )

شاخه ها یکی از ویژگی های بسیار کاربردی در گیت می باشد که با استفاده از آن میتوان بدون دست زدن به کدی که سالم است آن را در شاخه ای دیگر مورد بازبینی قرار داد و ویژگی ( feature ) به آن اضافه یا از آن کم کرد. همچنین برای تیم های توسعه استفاده از شاخه اهمیت بیشتری دارد چرا که در این تیم ها سعی می شود شاخه اصلی یا همان master branch شامل کدهای پایدارتر باشد. بنابراین یک شاخه develope ساخته می شود که دارای تغییرات زیاد و بنابراین کامیت های زیادی می باشد که توسعه دهندگان روی این شاخه کار می کنند و هر کجا که به کد پایدار و قابل تولید رسیدند توسط مدیر تیم به شاخه اصلی merge می شود. شکل زیر این موضوع را نشان می دهد :

علاوه بر شاخه های بالا، شاخه های پشتیبان هم در پروژه وجود دارد که شامل سه نوع زیر است:

• شاخه توسعه ویژگی ها

هر یک از توسعه دهندگان که روی یک ویژگی از نرم افزار کار می کند، می تواند در ماشین لوکال خود یک شاخه جدید برای توسعه ویژگی بسازد. پس از نهایی شدن ویژگی، کد های این شاخه در شاخه develop ادغام (Merge) می شود. استفاده از شاخه ویژگی کمک می کند هر یک از اعضا مستقل از سایر اعضا به توسعه ویژگی‌ها بپردازد.

• شاخه ریلیز

وقتی که تست های لازم بر روی کد شاخه develop انجام شد، یک شاخه ریلیز بسازید، در این شاخه هیچ ویژگی جدید توسعه پیدا نمی کند و صرفا باگ های احتمالی فیکس می شود. در انتهای این شاخه کد نهایی هم در شاخه develop و هم در شاخه master، ادغام می شود.

• شاخه رفع باگ

اگر احیانا در کد شاخه master، باگی دیدید، یگ شاخه رفع باگ بسازید، باگ را فیکس کنید و نهایتا در شاخه master ادغام نمایید.

کلیات ایده های ارائه شده در شکل های بالا در شکل زیر نمایش داده شده است.

---

مقاله تکمیلی : آموزش افزودن ورژن کنترل SVN/Git به پروژه آلتیوم دیزاینر

---

منابع :

https://www.atlassian.com/git/tutorials/what-is-version-control

https://www.atlassian.com/git/tutorials/what-is-git

https://onextrapixel.com/best-git-commands-web-developers

https://nvie.com/posts/a-successful-git-branching-model