GitLab چیست؟ آشنایی با کاربردها، امکانات و تفاوت گیت‌لب با گیت‌هاب

فرض کنید همراه چند برنامه‌نویس مشغول ساخت یک فروشگاه اینترنتی هستید. یک نفر صفحه محصولات را تغییر می‌دهد، نفر دیگر روی درگاه پرداخت کار می‌کند و شما هم بخش ثبت‌نام را توسعه می‌دهید. با بیشترشدن تغییرات، چند سؤال مهم پیش می‌آید. مثلا هربار یک نفر می‌پرسد آخرین نسخه کد کدام است؟ چه کسی بخش پرداخت را تغییر داده؟ چگونه تغییرات را قبل از انتشار بررسی کنیم؟ گیت‌لب برای مدیریت چنین فرایندی، ابزارهای مختلف را در اختیار تیم قرار می‌دهد. اعضای تیم می‌توانند کدها را در یک مخزن مشترک نگهداری کنند، تغییرات یکدیگر را ببینند، برای باگ‌ها وظیفه بسازند و تست‌های پروژه را به‌صورت خودکار اجرا کنند. در این مطلب از مجله دانشکار می‌خوانیم GitLab چیست، چه کاربردهایی دارد و چه تفاوتی با Git و GitHub دارد. همراه ما باشید.

gitlab چیست؟

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

• نگهداری کد و مشاهده تاریخچه تغییرات؛
• همکاری چند برنامه‌نویس روی یک پروژه؛
• بازبینی کدها با Merge Request؛
• ثبت باگ‌ها و کارهای پروژه با Issue؛
• اجرای خودکار فرایندهای ساخت، تست و انتشار؛
• مدیریت سطح دسترسی اعضای تیم؛
• اضافه‌کردن برخی بررسی‌های امنیتی به چرخه توسعه.

برای آشنایی بیشتر با گیت و گیت‌لب و تسلط به مباحث آن‌ها شرکت در اسکیل‌کمپ گیت دانشکار را به شما پیشنهاد می‌دهیم.

گیت چیست و چه تفاوتی با GitLab دارد؟‌

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

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

ویژگی	Git	GitLab
ماهیت	سیستم کنترل نسخه	پلتفرم توسعه نرم‌افزار مبتنی‌بر Git
کاربرد اصلی	ثبت و مدیریت تغییرات فایل‌ها	میزبانی کد و مدیریت همکاری تیم
محل اجرا	روی سیستم کاربر و سرورهای Git	سرویس ابری یا سرور تحت مدیریت سازمان
مدیریت وظایف	نداشتن ابزار مستقل	Issue، Board و Milestone دارد
بازبینی کد	نداشتن فرایند آماده وب	با Merge Request انجام می‌شود
CI/CD	جزو امکانات گیت نیست	GitLab CI/CD را در اختیار تیم قرار می‌دهد

تاریخچه گیت‌لب

پروژه GitLab در سال ۲۰۱۱ آغاز شد و دیمیتری زاپوروژتس از بنیان‌گذاران اصلی آن بود. این پروژه در ابتدا با هدف مدیریت مخازن Git و همکاری روی کد شکل گرفت و به‌مرور امکانات بیشتری برای برنامه‌ریزی، CI/CD، امنیت و مدیریت چرخه توسعه به آن اضافه شد. گیت‌لب در طول زمان از یک ابزار میزبانی مخزن فراتر رفت. این پلتفرم اکنون خود را به‌عنوان بستری برای هماهنگ‌سازی فعالیت‌های DevSecOps معرفی می‌کند و تلاش دارد ابزارهای توسعه، عملیات و امنیت را در یک محیط به هم متصل کند.

مفهوم مخزن یا Repository در GitLab چیست؟

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

مخزن فقط یک پوشه آنلاین نیست. Commitها، شاخه‌ها، Tagها و تاریخچه تغییرات فایل‌ها نیز در آن نگهداری می‌شوند. این اطلاعات نشان می‌دهند چه تغییری، در چه زمانی و با چه توضیحی ثبت شده است. در گیت‌لب، Repository بخشی از Project است. پروژه علاوه‌بر مخزن می‌تواند Issueها، Merge Requestها، Wiki، Pipelineها، اعضا و تنظیمات دسترسی را نیز در بر بگیرد. اصطلاح‌های مهم مخزن که زیاد با آن‌ها مواجه خواهید شد عبارت‌اند از:

• Commit: ثبت مجموعه‌ای مشخص از تغییرات در تاریخچه؛
• Branch: مسیر جداگانه‌ای برای توسعه یا اصلاح کد؛
• Tag: علامت‌گذاری یک نقطه از تاریخچه، برای مثال نسخه v1.0؛
• Clone: دریافت یک نسخه از مخزن روی سیستم؛
• Push: فرستادن Commitهای لوکال به مخزن راه‌دور؛
• Pull: دریافت تغییرات جدید از مخزن راه‌دور.

کاربردها و ویژگی‌های اصلی GitLab چیست؟

امکانات گیت‌لب بخش‌های مختلف توسعه نرم‌افزار را پوشش می‌دهند. همه تیم‌ها از تمام قابلیت‌ها استفاده نمی‌کنند؛ یک تیم کوچک ممکن است فقط به مخزن و Merge Request نیاز داشته باشد، درحالی‌که یک سازمان بزرگ از مدیریت پروژه، CI/CD و قابلیت‌های امنیتی نیز استفاده می‌کند. درادامه با کابردها و ویژگی‌های اصلی گیت‌لب دقیق آشنا می‌شویم.

• مدیریت کد و پیگیری تاریخچه تغییرات: در GitLab می‌توان فایل‌ها، Commitها و تفاوت نسخه‌های کد را مشاهده کرد. اگر یک خطا پس از تغییر فایل پرداخت ایجاد شود، اعضای تیم می‌توانند تاریخچه را بررسی کنند و ببینند کدام تغییر با آن ارتباط دارد. وجود تاریخچه به معنی غیرقابل‌تغییر بودن همیشگی آن نیست. کاربران دارای دسترسی مناسب می‌توانند عملیاتی مانند Force Push انجام دهند؛ به همین دلیل، حفاظت از شاخه‌های مهم و تعیین قواعد دسترسی ضروری است.
• مدیریت شاخه‌ها و تگ‌ها: Branchها کمک می‌کنند چند تغییر به‌صورت هم‌زمان و جدا از شاخه اصلی توسعه پیدا کنند. برای مثال، تیم می‌تواند برای رفع باگ پرداخت شاخه‌ای با نام fix/payment-error و برای قابلیت جدید شاخه‌ای با نام feature/wishlist بسازد. Tag معمولاً برای مشخص‌کردن نسخه‌های مهم استفاده می‌شود. وقتی نسخه جدید برنامه منتشر می‌شود، تیم می‌تواند Commit مربوط را با برچسبی مانند v2.1.0 مشخص کند تا پیداکردن آن ساده‌تر باشد.
• همکاری تیمی و بررسی کد با Merge Request: MR پیشنهادی برای ادغام تغییرات یک شاخه در شاخه دیگر است. برنامه‌نویس توضیح می‌دهد چه چیزی را تغییر داده و اعضای تیم می‌توانند تفاوت فایل‌ها را ببینند، سؤال بپرسند یا اصلاحات لازم را پیشنهاد دهند. برای مثال، قبل از ورود تغییرات درگاه پرداخت به شاخه main، مسئول فنی می‌تواند منطق محاسبه مبلغ و نتیجه تست‌ها را بررسی کند. بااین‌حال، ساخت MR به‌تنهایی کیفیت کد را تضمین نمی‌کند؛ بازبین، تست مناسب و قواعد روشن همچنان ضروری‌اند.
• مدیریت پروژه و پیگیری مشکلات با Issues: Issue برای ثبت یک باگ، قابلیت جدید یا کار فنی استفاده می‌شود. هر Issue می‌تواند عنوان، توضیح، مسئول، برچسب و موعد داشته باشد. برای مثال، «اصلاح خطای کد تخفیف» یک Issue است که می‌توان آن را به برنامه‌نویس مربوط سپرد. بردهای کاری نیز وضعیت Issueها را به‌شکل ستون‌هایی مانند «در انتظار»، «در حال انجام» و «انجام‌شده» نمایش می‌دهند. Milestoneها برای گروه‌بندی کارهای یک نسخه یا بازه زمانی کاربرد دارند.
• مدیریت دسترسی و امنیت پروژه: همه اعضای تیم نباید امکان یکسانی برای تغییر تنظیمات یا ادغام کد داشته باشند. گیت‌لب نقش‌ها و مجوزهایی دارد که با کمک آن‌ها می‌توان سطح دسترسی افراد را مدیریت کرد. تیم همچنین می‌تواند شاخه‌های حساس را Protected کند تا تغییر مستقیم یا ادغام آن‌ها محدود شود. استفاده از احراز هویت دومرحله‌ای، نگهداری امن کلیدها و متغیرهای CI/CD و به‌روزرسانی منظم نسخه Self-Managed نیز اهمیت زیادی دارد.
• مستندسازی با Wiki و انتشار سایت با GitLab Pages: Wiki محیطی برای نگهداری مستندات پروژه است. راهنمای نصب، توضیح معماری، قواعد نام‌گذاری Branch و شیوه انتشار نسخه‌ها را می‌توان در این بخش ثبت کرد. GitLab Pages برای انتشار سایت‌های استاتیک کاربرد دارد. برای مثال، می‌توان مستندات پروژه یا صفحه معرفی آن را از فایل‌های مخزن ساخت و منتشر کرد. Pages به‌تنهایی محیط عمومی اجرای بک‌اند و پایگاه داده نیست.
• اتصال گیت‌لب به سایر ابزارها: گیت‌لب می‌تواند با ابزارهای ارتباطی، مدیریت کار، مانیتورینگ، فضای ابری و محیط‌های توسعه یکپارچه شود. API و Webhook نیز اجازه می‌دهند رویدادهایی مانند ایجاد Issue یا Pushشدن کد به سیستم‌های دیگر اطلاع داده شوند. استفاده از گیت‌لب الزاماً به معنی کنارگذاشتن ابزارهای فعلی تیم نیست. پیش از انتخاب Integration باید بررسی شود ابزار موردنظر با نسخه و پلن گیت‌لب شما سازگار است یا نه.

GitLab CI/CD چیست و چگونه کار می‌کند؟

GitLab CI/CD مجموعه‌ای از امکانات برای خودکارسازی کارهای توسعه و انتشار است. می‌توان تعیین کرد پس از هر تغییر کد، چه تست‌هایی اجرا شوند، برنامه چگونه ساخته شود و در چه شرایطی به محیط آزمایشی یا عملیاتی برود. تنظیمات معمولاً در فایلی با نام .gitlab-ci.yml داخل مخزن نوشته می‌شوند. قرارگرفتن این فایل کنار کد باعث می‌شود تغییرات فرایند CI/CD نیز در تاریخچه پروژه ثبت شوند. اصطلاح‌های مهم این بخش که زیاد با آن‌ها مواجه خواهید شد عبارت‌اند از:

• Continuous Integration: تغییرات به‌صورت منظم ساخته و تست می‌شوند تا مشکلات زودتر مشخص شوند.
• Continuous Delivery: خروجی پس از بررسی‌ها آماده انتشار می‌شود، اما مرحله نهایی می‌تواند تأیید دستی بخواهد.
• Continuous Deployment: تغییرات تأییدشده براساس قواعد تعریف‌شده به‌صورت خودکار منتشر می‌شوند.

Pipeline در گیت‌لب چیست؟

Pipeline مجموعه‌ای از کارهای خودکار پروژه است. برای مثال، یک Pipeline می‌تواند ابتدا قالب کد را بررسی کند، سپس تست‌ها را اجرا کند، خروجی برنامه را بسازد و در پایان آن را به محیط آزمایشی بفرستد. هر کار مشخص Job نام دارد. Jobها در مرحله‌هایی مانند test، build و deploy قرار می‌گیرند. بسته به تنظیمات، بعضی Jobها هم‌زمان و بعضی پس از پایان مرحله قبلی اجرا می‌شوند. نمونه زیر فقط وجود فایل README.md را بررسی می‌کند:

image: alpine:3.22

stages:
  - test

check_readme:
  stage: test
  script:
    - test -f README.md
    - echo "README check passed"

موفق‌شدن این Pipeline فقط نشان می‌دهد فایل README وجود دارد؛ به معنی تست‌شدن کل برنامه یا نبودن باگ امنیتی نیست.

GitLab Runner چیست؟

Runner برنامه‌ای است که Jobهای Pipeline را اجرا می‌کند. GitLab مشخص می‌کند چه کاری باید انجام شود و Runner دستورهای ساخت، تست یا انتشار را در محیط اجرایی اجرا می‌کند. Runner می‌تواند روی زیرساخت اشتراکی یا سرور اختصاصی تیم قرار بگیرد. نوع Executor نیز تعیین می‌کند Job چگونه اجرا شود؛ برای مثال، استفاده از image در نمونه بالا به Executor سازگاری مانند Docker یا Kubernetes نیاز دارد. نصب Runner با نصب کامل سرور GitLab یکسان نیست. Runner فقط اجرای Jobها را برعهده دارد و باید منابع و سطح دسترسی آن با توجه به نوع پروژه مدیریت شوند.

نقش GitLab در DevOps و DevSecOps چیست؟

دواپس رویکردی برای نزدیک‌ترشدن توسعه و عملیات است. هدف آن این است که تغییرات نرم‌افزار با همکاری بیشتر، خودکارسازی و بازخورد سریع‌تر آماده و منتشر شوند. DevSecOps امنیت را نیز وارد همین چرخه می‌کند. به‌جای اینکه بررسی امنیت فقط در پایان پروژه انجام شود، بعضی کنترل‌ها هنگام توسعه و در Pipeline اجرا می‌شوند. گیت‌لب می‌تواند مدیریت کد، برنامه‌ریزی، CI/CD و برخی بررسی‌های امنیتی را در یک جریان کاری به هم متصل کند.

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

تفاوت GitLab و GitHub چیست؟

گیت‌لب و گیت‌هاب هر دو میزبان مخازن گیت هستند و امکاناتی برای همکاری، Issue، بازبینی کد و CI/CD دارند. تفاوت آن‌ها بیشتر در تجربه کاربری، اکوسیستم ابزارها، نحوه ارائه امکانات و مدل میزبانی دیده می‌شود. در جدول زیر این دو میزبان را دقیق‌تر مقایسه کرده‌ایم.

ویژگی	گیت‌لب	گیت‌هاب
پیشنهاد ادغام کد	Merge Request	Pull Request
CI/CD داخلی	GitLab CI/CD	GitHub Actions
مخزن خصوصی در پلن رایگان	دارد	دارد
اجرای تحت مدیریت سازمان	GitLab Self-Managed	GitHub Enterprise Server
جهت‌گیری شناخته‌شده	یکپارچه‌سازی فرایندهای DevSecOps	جامعه توسعه‌دهندگان و اکوسیستم گسترده
مناسب برای	تیم‌هایی که جریان یکپارچه و گزینه‌های میزبانی می‌خواهند	تیم‌هایی که با جامعه و ابزارهای GitHub کار می‌کنند

اگر به مفاهیمی مثل DevOps، استقرار نرم‌افزار، CI/CD و خودکارسازی فرایندهای توسعه علاقه دارید، بوت‌کمپ دواپس دانشکار می‌تواند مسیر مناسبی برای یادگیری این مهارت‌ها باشد.

آموزش ثبت‌نام در GitLab

برای استفاده از GitLab.com ابتدا باید حساب کاربری بسازید. اگر شرکت یا دانشگاه شما نمونه جداگانه‌ای از GitLab را به‌صورت Self-Managed اجرا می‌کند، ممکن است ثبت‌نام عمومی غیرفعال باشد و حساب را مدیر سیستم در اختیارتان قرار دهد. در ادامه همه مراحلی که باید برای ثبت‌نام در گیت‌لب را طی کنید نوشته‌ایم.

مرحله اول: ورود به صفحه ثبت‌نام و انجام بررسی امنیتی

وارد صفحه ثبت‌نام GitLab.com شوید. گاهی پیش از نمایش فرم، صفحه بررسی امنیتی Cloudflare باز می‌شود. در این حالت، گزینه Verify you are human را انتخاب کنید و منتظر بمانید تا مرورگر به صفحه ثبت‌نام هدایت شود.

مرحله دوم: تکمیل فرم ثب‎ت‌نام

پس از بازشدن فرم Get Started with GitLab، اطلاعات حساب را وارد کنید. فرم فعلی GitLab.com شامل نام، نام خانوادگی، نام‌کاربری، ایمیل سازمانی و رمز عبور است. فیلدها را به‌ترتیب زیر تکمیل کنید:

• در First name نام خود را بنویسید.
• در Last name نام خانوادگی را وارد کنید.
• در Username یک نام کاربری انتخاب کنید. GitLab در دسترس‌بودن آن را بررسی می‌کند. اگر پیام خطا دیدید، نام دیگری انتخاب کنید.
• در Company email ایمیلی بنویسید که به آن دسترسی دارید. GitLab استفاده از ایمیل کاری را پیشنهاد می‌کند، اما اعتبار و پذیرش آدرس در همان فرم بررسی می‌شود.
• در Password یک رمز عبور قوی و منحصربه‌فرد بسازید. از رمزی که در سرویس دیگری استفاده کرده‌اید، دوباره استفاده نکنید.
• گزینه دریافت ایمیل‌های معرفی محصول و رویدادها اختیاری است؛ فقط در صورت تمایل آن را فعال کنید.

پیش از ادامه، شرایط استفاده، بیانیه حریم خصوصی و سیاست Cookie را بخوانید. سپس روی Continue بزنید. می‌توانید به‌جای فرم عادی، Continue with Google یا Continue with GitHub را انتخاب کنید. پیش از تأیید، حساب انتخاب‌شده و مجوزهای درخواستی را بررسی کنید. استفاده از ورود شخص ثالث، ورود حساب GitLab را به آن سرویس وابسته می‌کند.

مرحله سوم: تایید ایمیل

پس از ارسال فرم، GitLab ممکن است صفحه‌ای با پیام Almost there نشان دهد و از شما بخواهد ایمیل خود را تأیید کنید. صندوق ورودی ایمیلی را که در فرم نوشته‌اید بررسی کنید و لینک تأیید داخل پیام را باز کنید. اگر پیام را ندیدید:

• پوشه Spam یا Junk را بررسی کنید؛
• از درست‌بودن آدرس ایمیل مطمئن شوید؛
• کمی صبر کنید و سپس Request new confirmation email را بزنید؛
• اگر چند پیام دریافت کردید، از جدیدترین لینک استفاده کنید.

مرحله چهارم: تکمیل اطلاعات اولیه حساب

پس از تأیید ایمیل و اولین ورود، GitLab.com ممکن است صفحه خوش‌آمدگویی و چند سؤال درباره نقش، نوع استفاده، اندازه تیم یا هدف شما نمایش دهد. پاسخ‌ها را براساس استفاده واقعی خود وارد کنید. اگر گزینه‌ای برای شروع Trial پولی نمایش داده شد، پیش از انتخاب، مدت آزمایشی و امکاناتی را که بعداً غیرفعال می‌شوند بررسی کنید. نمایش یا ترتیب این مرحله برای همه کاربران یکسان نیست. پس از ورود به حساب، نام، نام کاربری، ایمیل اصلی، منطقه زمانی و تنظیمات اعلان‌ها را بررسی کنید.

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

برای افزایش امنیت، وارد تنظیمات حساب شوید و بخش Password and authentication یا Account را باز کنید. سپس گزینه Enable two-factor authentication را انتخاب کنید.

در صفحه بعد، QR Code را با برنامه Authenticator اسکن کنید. سپس کد یک‌بارمصرف نمایش‌داده‌شده در برنامه را در فیلد Pin code وارد کنید.

پس از فعال‌شدن 2FA، گیت‌لب کدهای بازیابی را نمایش می‌دهد. آن‌ها را دانلود، چاپ یا در Password Manager امن ذخیره کنید.

هر Recovery Code معمولاً فقط یک‌بار قابل استفاده است. کدها را در مخزن Git، فایل عمومی، ایمیل اشتراکی یا پیام‌رسان گروهی ذخیره نکنید.

آموزش ورود به GitLab

پس از ساخت حساب، برای ورود به صفحه Sign in بروید. اگر بررسی امنیتی نمایش داده شد، همان مرحله‌ای را انجام دهید که در تصویر ۱ دیدیم.

مرحله اول: واردکردن اطلاعات حساب

در فیلد Username or primary email، نام کاربری یا ایمیل اصلی حساب را وارد کنید. ایمیل ثانویه ممکن است برای ورود پذیرفته نشود. سپس Password را بنویسید و روی Sign in بزنید. گزینه Remember me را فقط روی دستگاه شخصی و مطمئن فعال کنید. اگر رمز را فراموش کرده‌اید، Forgot your password? را انتخاب کنید و لینک بازیابی ارسال‌شده به ایمیل را دنبال کنید.

در صفحه فعلی GitLab.com امکان ورود با Passkey، Google، GitHub، Bitbucket، Salesforce و ChatGPT نیز دیده می‌شود. فقط روشی را انتخاب کنید که قبلاً به همان حساب GitLab متصل شده باشد.

مرحله دوم: واردکردن کد 2FA

اگر احراز هویت دومرحله‌ای را فعال کرده‌اید، پس از پذیرش رمز عبور باید کد برنامه Authenticator را وارد کنید. اگر به برنامه Authenticator دسترسی ندارید، یکی از Recovery Codeهای ذخیره‌شده را وارد کنید. پس از مصرف یک کد، آن را از فهرست خود حذف کنید؛ هر کد فقط یک‌بار قابل استفاده است.

اگر نام کاربری و رمز صحیح هستند اما وارد نمی‌شوید، دامنه GitLab را بررسی کنید؛ حساب GitLab.com با حساب یک نمونه Self-Managed یکسان نیست. همچنین تلاش‌های ناموفق متعدد می‌توانند حساب را موقت قفل کنند.

آموزش شروع کار با GitLab

پس از ساخت و ایمن‌کردن حساب، یک پروژه آزمایشی می‌سازیم، اتصال SSH را آماده می‌کنیم، تغییرات را به مخزن می‌فرستیم و در پایان Merge Request ایجاد می‌کنیم. برای طی کردن این مراحل همراه ما باشید.

مرحله اول: ایجاد اولین پروژه

پس از ورود، روی علامت + بزنید و New project/repository را انتخاب کنید. سپس وارد Create blank project شوید. در این صفحه موارد زیر را تنظیم کنید:

• در Project name نامی مانند demo-project بنویسید.
• مقدار Project slug را بررسی کنید؛ این مقدار بخشی از آدرس پروژه است.
• در Visibility Level، برای تمرین گزینه Private را انتخاب کنید.
• گزینه Initialize repository with a README را فعال کنید تا مخزن با یک فایل اولیه ساخته شود.
• روی Create project بزنید.

اگر قصد دارید یک مخزن لوکال موجود را Push کنید، می‌توانید گزینه ساخت README را غیرفعال بگذارید. ساخت هم‌زمان README در GitLab و داشتن Commitهای مستقل در مخزن لوکال ممکن است هنگام اولین ادغام به تاریخچه‌های جداگانه منجر شود.

مرحله دوم: ساخت و ثبت کلید SSH

SSH کمک می‌کند بدون واردکردن مکرر نام کاربری و رمز، با مخزن ارتباط امن داشته باشید. ابتدا در ترمینال این دستور را اجرا کنید و ایمیل خود را جایگزین مقدار نمونه کنید:

ssh-keygen -t ed25519 -C "you@example.com"

اگر مسیر پیش‌فرض مناسب است، Enter بزنید. برای کلید خود Passphrase امنی در نظر بگیرید. سپس محتوای کلید عمومی را ببینید:

cat ~/.ssh/id_ed25519.pub

در GitLab به Edit profile سپس Access و بعد SSH keys بروید. در بعضی نسخه‌ها مسیر از Preferences یا User Settings شروع می‌شود.

محتوای فایل .pub را در فیلد Key قرار دهید، نامی مانند Personal Laptop در Title بنویسید و کلید را ثبت کنید. کلید خصوصی مانند ~/.ssh/id_ed25519 را هیچ‌وقت در گیت‌لب، مخزن یا پیام‌رسان قرار ندهید. برای بررسی اتصال به GitLab.com دستور زیر را اجرا کنید:

ssh -T git@gitlab.com

در اولین اتصال، اثرانگشت میزبان را فقط پس از تطبیق با مستندات رسمی تأیید کنید.

مرحله سوم: دریافت پروژه و ارسال اولین تغییر

در صفحه اصلی پروژه، دکمه Code یا Clone را پیدا و آدرس SSH را کپی کنید. صفحه پروژه معمولاً فایل‌ها، شاخه فعال، تاریخچه آخرین Commit و گزینه‌های Clone را نشان می‌دهد.

حالا آدرس پروژه خود را جایگزین نمونه زیر کنید:

git clone git@gitlab.com:YOUR_NAMESPACE/demo-project.git
cd demo-project

یک Branch جداگانه بسازید:

git switch -c docs/update-readme

فایل README.md را ویرایش کرده و سپس تغییرات را ثبت و ارسال کنید:

git add README.md
git commit -m "Update project documentation"
git push -u origin docs/update-readme

اگر Git هویت Commit را نمی‌شناسد، نام و ایمیل خود را تنظیم کنید:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

این فرمان‌ها متعلق به Git هستند؛ گیت‌لب مخزن راه‌دوری است که تغییرات به آن ارسال می‌شوند.

مرحله چهارم: ایجاد Merge Request

پس از Push، گیت‌لب معمولاً پیامی برای ساخت Merge Request نشان می‌دهد. می‌توانید از منوی Merge requests نیز وارد New merge request شوید. در این مرحله اقدام‌های زیر را انجام دهید:

• Source branch را روی docs/update-readme بگذارید.
• Target branch را main انتخاب کنید.
• روی Compare branches and continue بزنید.
• عنوانی روشن و توضیحی درباره تغییرات بنویسید.
• در صورت نیاز Reviewer و Assignee را مشخص کنید.
• Merge Request را بسازید و تب Changes و نتیجه Pipeline را بررسی کنید.

پس از تأیید، تغییرات با توجه به قوانین پروژه Merge می‌شوند. اگر Conflict ایجاد شده باشد، باید تفاوت‌های ناسازگار را قبل از ادغام برطرف کنید.

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

گیت‌لب به چند روش ارائه می‌شود. انتخاب روش مناسب به محل داده، توان تیم زیرساخت، بودجه و الزامات امنیتی بستگی دارد.

استفاده از GitLab.com

GitLab.com سرویس SaaS چندمستأجری گیت‌لب است. در این روش، شرکت GitLab زیرساخت اصلی پلتفرم را مدیریت می‌کند و کاربران بدون نصب سرور، حساب و پروژه می‌سازند. این روش برای شروع سریع مناسب است، اما کاربران باید محدودیت‌های پلن، شرایط سرویس و وضعیت دسترسی منطقه‌ای را بررسی کنند.

نصب GitLab به‌صورت Self-Managed

در مدل Self-Managed، گیت‌لب روی زیرساختی اجرا می‌شود که سازمان یا ارائه‌دهنده منتخب آن مدیریت می‌کند. این زیرساخت می‌تواند سرور داخلی، ماشین مجازی یا سرویس ابری باشد. در بسیاری از این زیرساخت‌ها از سیستم‌عامل لینوکس استفاده می‌شود و انتخاب بین انواع لینوکس و توزیع‌های مختلف آن به نیاز و پیکربندی سرور بستگی دارد. این مدل کنترل بیشتری روی محل داده و تنظیمات می‌دهد، اما مسئولیت‌های زیر را نیز به تیم اضافه می‌کند:

• نصب و به‌روزرسانی گیت‌لب؛
• تأمین CPU، RAM و فضای ذخیره‌سازی؛
• تنظیم HTTPS، DNS و ایمیل؛
• مدیریت Runnerها؛
• پایش سرویس و ظرفیت؛
• پشتیبان‌گیری و آزمایش بازیابی؛
• نصب اصلاحیه‌های امنیتی.

برای همه سازمان‌ها نمی‌توان یک مقدار ثابت منابع پیشنهاد کرد. تعداد کاربران، اندازه مخازن، استفاده از Registry و بار CI/CD روی نیاز زیرساخت تأثیر دارند.

GitLab Dedicated چیست؟

GitLab Dedicated یک سرویس SaaS با محیط اختصاصی برای هر سازمان و مدیریت‌شده توسط GitLab است. این مدل برای سازمان‌هایی ارائه می‌شود که به جداسازی محیط، محل نگهداری مشخص داده و امکانات سازمانی نیاز دارند. با مطالعه جدول زیر اطلاعات دقیق‌ترینسبت به هر سرویس به دست می‌آورید.

ویژگی	GitLab.com	Self-Managed	Dedicated
مدیریت زیرساخت اصلی	GitLab	سازمان یا پیمانکار	GitLab
زمان شروع	سریع	به نصب و آماده‌سازی نیاز دارد	براساس فرایند سازمانی
کنترل مستقیم زیرساخت	محدود به تنظیمات سرویس	بیشتر	مطابق امکانات سرویس و قرارداد
مسئولیت به‌روزرسانی	GitLab	سازمان	GitLab
کاربرد معمول	افراد و تیم‌های مختلف	نیاز به کنترل بیشتر	سازمان‌هایی با نیاز جداسازی و انطباق

مزایای گیت‌لب چیست؟

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

• پیگیری بهتر تغییرات: Commitها، Branchها و Merge Requestها تاریخچه تصمیم‌ها را قابل مشاهده می‌کنند.
• همکاری تیمی منظم‌تر: بازبینی کد، گفت‌وگو و نتیجه تست‌ها کنار تغییرات قرار می‌گیرند.
• خودکارسازی کارهای تکراری: Pipelineها می‌توانند تست، ساخت و بخشی از انتشار را انجام دهند.
• مدیریت کد و کار در یک محیط: Issueها را می‌توان به Commitها و Merge Requestها مرتبط کرد.
• امکان انتخاب مدل میزبانی: تیم می‌تواند GitLab.com یا Self-Managed را براساس نیاز بررسی کند.
• اضافه‌کردن امنیت به Pipeline: برخی بررسی‌های امنیتی در جریان توسعه اجرا می‌شوند.
• قابلیت توسعه و یکپارچه‌سازی: API، Webhook و Integrationها ارتباط با ابزارهای دیگر را ممکن می‌کنند.

معایب و محدودیت‌های گیت‌لب چیست؟

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

• پیچیدگی رابط و تنظیمات: تعداد زیاد منوها و قابلیت‌ها ممکن است برای کاربر تازه‌کار گیج‌کننده باشد.
• هزینه نگهداری Self-Managed: سرور، پشتیبان‌گیری، پایش و به‌روزرسانی به زمان و تخصص نیاز دارند.
• مصرف منابع: نمونه‌های بزرگ و Pipelineهای پرتعداد می‌توانند به زیرساخت قابل‌توجهی نیاز داشته باشند.
• محدودیت پلن رایگان: تعداد کاربران گروه سطح بالا، Compute Minute، فضای ذخیره‌سازی و بعضی امکانات محدود هستند.
• وابستگی به پیکربندی صحیح: اشتباه در مجوزها، Runnerها یا متغیرهای CI/CD می‌تواند ریسک امنیتی ایجاد کند.
• نیاز به یادگیری Git و CI/CD: رابط گیت‌لب جای درک اصول کنترل نسخه و تست را نمی‌گیرد.

در نهایت؛ GitLab پلتفرمی مبتنی‌بر Git برای مدیریت کد و فرایند توسعه نرم‌افزار است. مخزن، Issue، Merge Request و CI/CD به تیم کمک می‌کنند تغییرات را ثبت، بررسی، آزمایش و منتشر کند. اگر فقط می‌خواهید یک پروژه کوچک را شروع کنید، ساخت حساب در GitLab.com و تمرین Branch، Commit و Merge Request نقطه شروع مناسبی است. اگر سازمان شما به کنترل بیشتر روی داده و زیرساخت نیاز دارد، Self-Managed یا Dedicated را با درنظرگرفتن هزینه و مسئولیت نگهداری بررسی کنید. انتخاب بین GitLab، GitHub و Bitbucket نیز باید براساس نیاز واقعی تیم باشد.

منابع: carpentries-incubator.github.io، coursera.org