آنچه در این صفحه می خوانید:
معرفی گیت
گیت یک سیستم کنترل نسخه توزیع شده برای ردیابی تغییرات در کد منبع در هنگام تهیه نرم افزار است. این برای هماهنگی کار در بین برنامه نویسان طراحی شده است، اما می توان از آن برای ردیابی تغییرات در هر مجموعه ای از فایل ها استفاده کرد. اهداف آن شامل سرعت، یکپارچگی داده ها و پشتیبانی از گردش کار غیر خطی توزیع شده است. 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 که باعث می شود تقریباً از سایر SCM های موجود جدا باشد، مدل شاخه ای آن وجود دارد. Git به شما امکان می دهد چندین شعبه محلی داشته باشید که کاملاً مستقل از یکدیگر باشند. ایجاد، ادغام و حذف آن خطوط توسعه ثانیه ای طول می کشد.
این بدان معنی است که شما می توانید کارهایی مانند:
- تغییر متن بدون اصطکاک. یک شعبه ایجاد کنید تا یک ایده را امتحان کنید، چند بار متعهد شوید، به جایی که از آن شاخه جدا شده اید برگردید، وصله ای را اعمال کنید، به همان جایی که آزمایش می کنید برگردید و آن را ادغام کنید.
- Codelines مبتنی بر نقش. یک شاخه داشته باشید که همیشه فقط شامل موارد تولید شود، شاخه دیگری که کار را برای آزمایش در آن ادغام می کنید و چندین شاخه کوچکتر برای کارهای روزمره داشته باشید.
- گردش کار مبتنی بر ویژگی. برای هر ویژگی جدیدی که روی آن کار می کنید شاخه های جدید ایجاد کنید تا بتوانید بی وقفه بین آنها رفت و برگشت کنید، سپس وقتی این ویژگی در خط اصلی شما ادغام شد، هر شاخه را حذف کنید.
- آزمایش یکبار مصرف. یک شاخه ایجاد کنید تا آزمایش کنید، متوجه شوید که کارایی نخواهد داشت و فقط آن را حذف کنید - کار را رها کنید - هیچ کس دیگر آن را نمی بیند (حتی اگر شاخه های دیگر را در این بین Push داده اید).
قابل توجه است، هنگامی که شما به یک مخزن از راه دور Push می کنید، نیازی نیست که همه شاخه های خود را Push کنید. می توانید انتخاب کنید که فقط یکی از شعب خود را به اشتراک بگذارید، چند شاخه یا همه آنها. این امر باعث می شود افراد بدون نگرانی در مورد چگونگی و زمان برنامه ریزی برای ادغام یا به اشتراک گذاشتن آن با دیگران، ایده های جدید را امتحان کنند. روش هایی وجود دارد که می توانید برخی از این موارد را با سایر سیستم ها انجام دهید، اما کار بسیار دشوارتر و مستعد خطا است. Git این فرآیند را فوق العاده آسان کرده و نحوه کار اکثر توسعه دهندگان را هنگام یادگیری تغییر می دهد.
گیت چگونه کار می کند؟
پشتیبان گیری های متعدد: این بدان معناست که حتی اگر از یک گردش کار متمرکز استفاده می کنید، هر کاربر در اصل از پشتیبان کامل سرور اصلی برخوردار است. در صورت خرابی یا فساد، می توان هرکدام از این نسخه ها را جایگزین سرور اصلی کرد. در واقع، هیچ نقطه شکست در Git وجود ندارد، مگر اینکه فقط یک کپی از مخزن موجود باشد.
هر گردش کار: به دلیل ماهیت توزیع شده و سیستم انشعاب فوق العاده گیت، تعداد تقریباً بی پایان جریان کار با سهولت نسبی قابل اجرا است.
گردش کار به سبک متمرکز: گردش کار متمرکز بسیار رایج است، به خصوص در افرادی که از یک سیستم متمرکز عبور می کنند. اگر شخصی از آخرین باری که واگذاری کرده اید جایگذاری کند، Git به شما اجازه نمی دهد جایگذاری را انجام دهید، بنابراین یک مدل متمرکز که در آن همه توسعه دهندگان به همان سرور جایگذاری می کنند درست کار می کند.
گردش کار مدیر ادغام: یکی دیگر از گردش های رایج Git شامل یک مدیر ادغام است. تعدادی از توسعه دهندگان سپس از آن مخزن کلون می شوند و به مخزن مستقل خود جایگذاری می کنند و از یکپارچه ساز می خواهند که تغییرات خود را جلب کند. این نوع مدل توسعه است که اغلب با مخازن منبع باز یا گیت هاب (GitHub) مشاهده می شود.
گردش کار دیکتاتور و ستوان: برای پروژه های گسترده تر، یک گردش کار توسعه مانند هسته لینوکس اغلب مؤثر است. در این مدل، برخی از افراد "ستوان" مسئولیت یک زیر سیستم خاص پروژه را بر عهده دارند و در همه تغییرات مربوط به آن زیر سیستم ادغام می شوند. یکی دیگر از ادغام کنندگان "دیکتاتور" می توانند تغییراتی را از تنها ستوان خود بگیرند و سپس به مخزن "blessed" سوق دهند که همه پس از آن دوباره کلون می شوند.
چرا باید از گیت استفاده کنیم؟
ویژگی Git که واقعاً باعث می شود تقریباً از هر SCM دیگری جدا شود، مدل انشعاب آن وجود دارد. Git به شما امکان می دهد چندین شعبه محلی داشته باشید که کاملاً مستقل از یکدیگر باشند. ایجاد، ادغام و حذف آن خطوط توسعه چند ثانیه طول می کشد. این بدان معنی است که شما می توانید کارهایی مانند:
- تعویض متن بدون اصطحکاک: یک شعبه ایجاد کنید تا یک ایده را امتحان کنید، چند بار متعهد شوید، به جایی که از آن شاخه دارید برگردید، یک پچ بچسبانید، به جایی که آزمایش می کنید بازگردید و آن را ادغام کنید.
- برنامه های مبتنی بر نقش: شاخه ای داشته باشید که همیشه فقط شامل مواردی باشد که به تولید می پردازد، دیگری که کار را برای آزمایش و چندین کار کوچکتر برای کار روزانه در آن ادغام می کنید.
- گردش کار مبتنی بر ویژگی: برای هر ویژگی جدیدی که روی آن کار می کنید شاخه های جدید ایجاد کنید تا بتوانید بین آنها یکپارچه به جلو و عقب بروید، سپس وقتی این ویژگی در خط اصلی شما ادغام شد، هر شاخه را حذف کنید.
- آزمایش یکبار مصرف: شعبه ای را ایجاد کنید تا در آن آزمایش کنید، متوجه شوید که کار نخواهد کرد و فقط آن را حذف کنید - کار را رها کنید - هیچ کس دیگری هرگز آن را ندیده است (حتی اگر در عین حال شاخه های دیگری را هم جایگذاری کرده اید).
نکته قابل توجه، وقتی در مخزن از راه دور جایگذاری می کنید، دیگر نیازی نیست که همه شاخه های خود را جایگذاری کنید. می توانید فقط یکی از شاخه های خود، تعدادی از آنها یا همه آنها را به اشتراک بگذارید. این امر باعث می شود افراد آزاد شوند تا ایده های جدیدی را امتحان کنند بدون اینکه نگرانی در مورد برنامه ریزی چگونگی و زمانی که قصد دارند آن را ادغام کنند یا آن را با دیگران به اشتراک بگذارند، داشته باشند. روش هایی برای تحقق برخی از این موارد با سایر سیستم ها وجود دارد، اما کار مربوط به آن بسیار سخت تر و مستعد خطا است. Git این فرآیند را فوق العاده آسان می کند و نحوه کار بیشتر توسعه دهندگان هنگام یادگیری آن را تغییر می دهد. Git سریع است و با استفاده از Git، تقریباً تمام عملیات به صورت محلی انجام می شود و این مزیت سرعت بسیار خوبی را در سیستم های متمرکز ایجاد می کند که دائماً باید در جایی با یک سرور ارتباط برقرار کنند. Git برای کار در هسته لینوکس ساخته شده است، به این معنی که از روز اول مجبور شد به طور موثری مخازن بزرگ را اداره کند. Git به زبان C نوشته شده و سربار زمان اجرای برنامه های مرتبط با زبانهای سطح بالاتر را کاهش می دهد. سرعت و عملکرد از ابتدا هدف اصلی طراحی Git بوده است.
تفاوت بین Git و GitHub
با توجه به اینکه برنامه نویسی تا حد زیادی بر سینتکس دقیق متکی است، قرارداد نامگذاری پیرامون زبان ها و منابع برنامه نویسی چیزی جز بصری نیست. جاوا و جاوا اسکریپت تقریباً مشابه هم هستند و لوگوی پایتون ممکن است تصویری از مارهای در هم تنیده باشد، اما در واقع از نام گروه طنز طرح Monty Python گرفته شده است. HTML و CSS کلمات اختصاری هستند که توصیف می کنند که کد در واقع چیست یا چه کاری انجام می دهد (به ترتیب HyperText Markup Language و Cascading Style Sheets)، در حالی که ++C ریشه های آن را شرح می دهد. و این فقط سطح ماجرا است.
بنابراین، برای کسی که اولین بار در مورد تفاوت Git و GitHub از او سوال کنید، ممکن است ارتباط ظاهری چندان آشکاری بین این دو پیدا نکند.
گیت یا گیتهاب؟
آیا آنها مشابه هم هستند؟ اگر نه، آیا آنها به نحوی با هم ارتباط دارند؟ یا مانند جاوا و جاوااسکریپت، ارتباط سطحی دارند؟
این سوالات قطعاً ارزش پرسیدن را دارند. از این گذشته، مایکروسافت مایل بود 7.5 میلیارد دلار برای خرید گیت هاب (GitHub) در سال 2018 جمع آوری کند، بنابراین توسعه دهندگان در هر سطحی باید به آن توجه داشته باشند. اما حقیقت این است که Git و GitHub بسیار نزدیکتر از جاوا و جاوا اسکریپت با هم ارتباط دارند - اما برخی تفاوت های کلیدی آنها را از هم متمایز می کند.
تفاوت بین Git و GitHub چیست؟ Git که اولین بار در سال 2005 توسعه یافت، یک سیستم کنترل نسخه بسیار محبوب است که در قلب طیف گسترده ای از پروژه های برجسته قرار دارد. Git بر روی سیستم محلی شما نصب شده و نگهداری می شود (نه در ابر) و یک نسخه مستقل از برنامه های در حال برنامه نویسی شما را در اختیارتان قرار می دهد. می توان از آن به طور کامل در هر سرویس میزبانی ابری استفاده کرد - شما حتی نیازی به دسترسی به اینترنت ندارید، مگر برای دانلود آن.
در مقایسه با سایر سیستم های کنترل نسخه، Git واکنشگرا، آسان برای استفاده کردن و ارزان (در واقع رایگان) است. Git همچنین به گونه ای طراحی شده است که به خوبی با فایل های متنی کار می کند. اما چیزی که واقعاً Git را متمایز می کند، مدل شاخه ای آن است. Branching به شما اجازه می دهد تا در کد خود شعبه های محلی مستقل ایجاد کنید. این بدان معناست که می توانید ایده های جدید را امتحان کنید، شاخه هایی را برای کارهای تولیدی کنار بگذارید، به شاخه های قبلی برگردید و با کلیک یک دکمه به راحتی شاخه ها را حذف، ادغام و فراخوانی مجدد کنید.
درواقع Git یک سیستم کنترل نسخه با کیفیت بالا است. اما در مورد GitHub چطور؟
در بحث تفاوا بین Git و GitHub، گفته شده است که GitHub همان چیزی است که فیس بوک برای چهره واقعی انجام داده است. یعنی چی؟ خب، این بدان معناست که در حالی که فیس بوک به نوعی شبیه به پایگاه داده چهره آنلاین است، GitHub به عنوان یک سرویس میزبانی مخزن گیت (Git repository hosting) طراحی شده است.
و سرویس میزبانی Git repository دقیقاً چیست؟ در واقع پایگاه داده آنلاین است که به شما امکان می دهد پروژه های کنترل نسخه Git خود را خارج از رایانه/سرور محلی خود پیگیری کرده و به اشتراک بگذارید. برخلاف گیت، GitHub منحصراً مبتنی بر ابر است. همچنین بر خلاف گیت ، GitHub یک سرویس است (اگرچه ویژگی های اصلی میزبانی مخزن برای کسانی که مایل به ایجاد نمایه کاربر هستند بدون هیچ هزینه ای در دسترس است و GitHub را به یک انتخاب محبوب برای پروژه های منبع باز تبدیل کرده است).
دلیل این امر این است که GitHub علاوه بر ارائه همه ویژگی ها و مزایای Git، قابلیت های اصلی Git را نیز گسترش می دهد. این برنامه یک رابط کاربری بسیار بصری و گرافیکی ارائه می دهد و ابزارهای کنترل و وظیفه داخلی را در اختیار برنامه نویسان قرار می دهد. ویژگی های اضافی را می توان از طریق سرویس GitHub Marketplace پیاده سازی کرد. و از آنجا که GitHub مبتنی بر ابر است، مخازن Git افراد، می تواند از راه دور توسط هر شخص مجاز، از هر رایانه، در هر نقطه از جهان (به شرط اتصال به اینترنت) قابل دسترسی باشد.
از طریق GitHub، می توانید کد خود را با دیگران به اشتراک بگذارید و به آنها این قدرت را بدهید که در شعب (branches) مختلف Git خود تجدید نظر یا ویرایش کنند. این امر باعث می شود که کل تیم ها بتوانند در پروژه های واحد در زمان واقعی با هم هماهنگ شوند. با ایجاد تغییرات، شاخه های جدیدی ایجاد می شود که به تیم اجازه می دهد بدون بازنویسی آثار یکدیگر به بازنویسی کد ادامه دهد. این شاخه ها مانند کپی هستند و تغییرات ایجاد شده در آنها در فهرست اصلی دستگاه های دیگر کاربران منعکس نمی شود مگر اینکه کاربران push/pull تغییرات را برای ترکیب آنها انتخاب کنند. همچنین یک برنامه دسکتاپ GitHub در دسترس است که برخی از قابلیت های دیگر را برای توسعه دهندگان با تجربه ارائه می دهد.
سایر سرویس های میزبانی Git repository نیز وجود دارد. GitLab ، BitBucket و SourceForge همه گزینه های مناسب GitHub هستند و GitLab حتی یک گزینه داخلی نیز ارائه می دهد که به کاربران GitHub اجازه می دهد پروژه های خود را مستقیماً به GitLab منتقل کنند.