آموزش گیت

دسته بندی: فریمورک ها

گیت

آنچه در این صفحه می خوانید:

گیت چیست؟

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

کنترل نسخه چیست؟

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

سیستم های کنترل نسخه محلی

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

سیستم های کنترل نسخه متمرکز

مسئله مهم بعدی که مردم با آن روبرو می شوند این است که آنها نیاز به همکاری با توسعه دهندگان در سایر سیستم ها دارند. برای مقابله با این مشکل، سیستم های کنترل نسخه متمرکز (CVCS) توسعه داده شد. این سیستم ها (مانند CVS ،Subversion و Perforce) دارای یک سرور واحد هستند که شامل کلیه پرونده های نسخه شده و تعدادی مشتری است که پرونده ها را از آن مکان مرکزی بررسی می کنند. سالهاست که این استاندارد برای کنترل نسخه بوده است. این راه اندازی مزایای بسیاری دارد ، خصوصاً در مورد VCS محلی به عنوان مثال، همه تا حدودی می دانند که همه افراد در این پروژه چه کاری انجام می دهند. سرپرستان کنترل دقیق و دقیق بر چه کسی می توانند انجام دهند و مدیریت CVCS بسیار ساده تر از آن است که مقابله با بانکهای اطلاعاتی محلی برای هر مشتری انجام شود.

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

سیستم های کنترل نسخه توزیع شده

اینجاست که سیستم های کنترل نسخه توزیع توزیع شده (DVCS) قدم می گذارند. در DVCS (مانند Git ،Mercurial ،Bazaar یا Darcs)، مشتریان فقط آخرین عکس فوری پرونده ها را بررسی نمی کنند. در عوض، آنها به طور کامل از مخازن، از جمله تاریخچه کامل آن آینه می گیرند. بنابراین، اگر هر سرور از بین برود و این سیستم ها از طریق آن سرور همکاری می کنند، می توان هر یک از مخازن مشتری را برای بازیابی آن به سرور کپی کرد. هر کلون واقعاً پشتیبان کامل از تمام داده ها است. علاوه بر این، بسیاری از این سیستم ها با داشتن چندین مخزن از راه دور که می توانند با آنها کار کنند بسیار خوب است، بنابراین می توانید همزمان با همان پروژه با گروه های مختلفی از افراد به روش های مختلف همکاری کنید. این امر به شما امکان می دهد چندین نوع گردش کاری را تنظیم کنید که در سیستم های متمرکز مانند مدل های سلسله مراتبی امکان پذیر نیست.

تاریخچه گیت

توسعه Git از آوریل 2005 شروع شد، پس از آنكه بسیاری از توسعه دهندگان هسته لینوكس از دسترسی به سیستم BitKeeper، سیستم مدیریت كنترل منبع اختصاصی (SCM) كه قبلاً برای حفظ پروژه استفاده كرده بودند، دست كشیدند. لینوس توروالدز سیستم توزیع شده ای را می خواست که بتواند مانند BitKeeper از آن استفاده کند، اما هیچ یک از سیستم های رایگان موجود پاسخگوی نیازهای وی نبود. توروالدز مثالي از يك سيستم مديريت كنترل منبع را نياز به 30 ثانيه براي اعمال يك پچ و به روز كردن تمام ابرداده همراه را عنوان كرد و خاطرنشان كرد كه اين امر به نيازهاي توسعه هسته لينوكس نياز نخواهد داشت. وی برای معیارهای طراحی خود تصریح کرد که پچینگ نباید بیش از سه ثانیه طول بکشد و سه نکته دیگر اضافه کرد:

  • از سیستم نسخه های همزمان (CVS) به عنوان نمونه ای از کاری که نباید انجام شود ، استفاده کنید. اگر شک دارید ، تصمیم خلاف آن بگیرید.
  • گردش کار توزیع شده و شبیه BitKeeper را پشتیبانی کنید.
  • از اقدامات محافظتی بسیار شدید در برابر فساد ، چه تصادفی و چه بدخواهانه استفاده کنید.

این معیارها هر سیستم کنترل نسخه فعلی موجود را از بین برد، بنابراین بلافاصله پس از انتشار نسخه هسته هسته 2.6.12-rc2 لینوکس، توروالدز تصمیم گرفت که گیت را بنویسد.توسعه Git از 3 آوریل 2005 آغاز شد. توروالدز این پروژه را در 6 آوریل اعلام کرد. اولین ادغام شاخه های مختلف در 18 آوریل انجام شد. توروالدز به اهداف عملکردی خود دست یافت. در 29 آوریل، Git نوظهور تکه های ضبط شده را به درخت هسته Linux با سرعت 6.7 تکه در ثانیه محک زده است. در 16 ژوئن گیت مدیریت هسته 2.6.12 هسته را مدیریت کرد.Torvalds تعمیر و نگهداری را در 26 ژوئیه 2005 به جونیو هامانو، یكی از سهم های اصلی این پروژه، واگذار كرد. Hamano مسئولیت انتشار نسخه 1.0 در 21 دسامبر 2005 و همچنان نگهدار پروژه است.

معماری گیت

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

گیت چگونه کار می کند؟

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

هر گردش کار: به دلیل ماهیت توزیع شده و سیستم انشعاب فوق العاده گیت، تعداد تقریباً بی پایان جریان کار با سهولت نسبی قابل اجرا است.

گردش کار به سبک براندازی: گردش کار متمرکز بسیار رایج است، به خصوص در افرادی که از یک سیستم متمرکز عبور می کنند. اگر شخصی از آخرین باری که واگذاری کرده اید جایگذاری کند، Git به شما اجازه نمی دهد جایگذاری را انجام دهید، بنابراین یک مدل متمرکز که در آن همه توسعه دهندگان به همان سرور جایگذاری می کنند درست کار می کند.

ساختار گیت
گردش کار مدیر ادغام: یکی دیگر از گردش های رایج Git شامل یک مدیر ادغام است. تعدادی از توسعه دهندگان سپس از آن مخزن کلون می شوند و به مخزن مستقل خود جایگذاری می کنند و از یکپارچه ساز می خواهند که تغییرات خود را جلب کند. این نوع مدل توسعه است که اغلب با مخازن منبع باز یا GitHub مشاهده می شود.

ساختار گیت

گردش کار دیکتاتور و ستوان: برای پروژه های گسترده تر، یک گردش کار توسعه مانند هسته لینوکس اغلب مؤثر است. در این مدل، برخی از افراد "ستوان" مسئولیت یک زیر سیستم خاص پروژه را بر عهده دارند و در همه تغییرات مربوط به آن زیر سیستم ادغام می شوند. یکی دیگر از ادغام کنندگان "دیکتاتور" می توانند تغییراتی را از تنها ستوان خود بگیرند و سپس به مخزن "blessed" سوق دهند که همه پس از آن دوباره کلون می شوند.

ساختار گیت

چرا باید از گیت استفاده کنیم؟

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

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

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

آیا این نوشته را دوست داشتید؟