گیت لب چیست؟ – از کاربرد تا نحوه استفاده GitLab

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

«گیت لب» یکی از محبوب‌ترین ابزارها برای برنامه‌نویسان به‌شمار می‌رود زیرا باعث بهبود چرخه‌تولید محصول نرم‌افزاری می‌شود و در نتیجه، ارزش بیشتری را برای کاربران به‌همراه‌ دارد.

گیت لب چیست ؟

تیم‌های توسعه نرم‌افزار به کمک «گیت لب» (GitLab) می‌توانند «چرخه تولید» (Lifecycles) محصول را کاهش و بازدهی آن را افزایش دهند که در نهایت اعتبار و ارزشمندی محصول برای کاربران را به‌دنبال خواهد داشت.

گیت لب، پلتفرم خود را به‌صورت «فریمیوم» عرضه می‌کند. یعنی محصول یا خدمات آن به‌طور رایگان عرضه می‌شوند ولی برای دسترسی به امکانات ویژه و خدمات بیشتر آن نیاز است تا هزینه‌ای پرداخت شود. از دیگر نکات جالب شرکت «GitLab» می‌توان به این مورد اشاره کرد که از زمان تأسیس، شرکتی تماماً ریموت بوده است، یعنی با تیمی بالغ بر ۲۰۰۰ نفر از ۶۵ کشور جهان، هیچ دفترِکاری ندارد.
«گیت لب» (GitLab)، به‌وسیله آقایان «Dmitriy Zaporozhets» و «Valery Sizov» در سال ۱۳۹۰ (اُکتبر ۲۰۱۱) راه‌اندازی شد. این سرویس با زبان‌های روبی، جاوا اسکریپت و Go نوشته و تحت مجوز MIT توزیع شده است. از گیت لب، ۲ نسخه جداگانه شامل «GitLab CE» (نسخه کامیونیتی) و «GitLab EE» (نسخه تجاری) وجود دارد.

در «گیت لب» نیازی نیست که کاربران، مجوزهای مربوط به هر ابزار را مدیریت کنند و همین‌که مجوزها یک مرتبه تنظیم شوند، پس از آن هر یک از افراد سازمان می‌تواند به مؤلفه‌های مربوطه دسترسی داشته باشد.

دلیل استفاده از گیت لب چیست ؟

«گیت لب»، راهی عالی برای مدیریت مخازن گیت روی سِروری متمرکز محسوب می‌شود. «GitLab» امکان کنترل کامل مخازن یا پروژه‌هایمان را فراهم می‌کند و به ما اجازه می‌دهد تا «عمومی» (Public) یا «خصوصی» (Private) بودن آن‌ها را تعیین کنیم.

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

ویژگی های گیت لب چیست ؟

در ادامه، برخی از ویژگی‌های گیت لب را بیان کرده‌ایم.

• GitLab، پلتفرمی برای مدیریت مخازن «گیت» (Git) است.
• «گیت لب» از پروژه‌های نرم‌افزاری (خصوصی) ما به‌طور رایگان میزبانی می‌کند.
• «گیت لب»، امکاناتی مانند مخازن عمومی و خصوصی رایگان، «رهگیری مشکلات» (Issue-Tracking) و «ویکی‌ها» (Wikis) را فراهم می‌کند.
• GitLab در حقیقت، لایه‌ای (رابطِ وبِ کاربر پسندی) روی گیت Git است که سرعت کار با گیت را افزایش می‌دهد.
• «گیت لب»، برای مدیریت پروژه‌ها، سیستم «ادغام پیوسته» (Continuous Integration | CI) مخصوصِ خود، رابط کاربری و سایر ویژگی‌ها را عرضه می‌کند.

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

«GitLab» مزیت‌های مهمی را به برنامه‌نویسان عرضه می‌کند. در ادامه برخی از این مزایا را بیان کرده‌ایم.

• راه‌اندازی بسیار ساده‌ای دارد.
• ابزارها و رابط کاربر پسندی را عرضه می‌کند.
• سرویس‌های شخص ثالث و API-های زیادی را فراهم می‌کند.
• گیت لب، نسخه «GitLab Community Edition» را به کاربران عرضه می‌کند تا از این طریق بفهمند که کُدهایشان روی کدام سرورها موجود است.
• GitLab تعداد بی‌شماری از مخازن عمومی و خصوصی را به‌طور رایگان برای کاربران فراهم می‌کند.
• با وجود قسمت «Snippet» (اسنیپِت | تِکه)، به‌جای اشتراک‌گذاری تمام پروژه می‌تواند قطعاتی از کدهای پروژه را به اشتراک بگذارد.
• «برقراری» (آپ‌تایم | Uptime) بالا و مطمئنی دارد.

معایب گیت لب چیست ؟

مانند هر ابزار دیگری که امروزه در در اختیار داریم، برای «GitLab» نیز می‌توان معایبی را برشمرد که در ادامه به آن می‌پردازیم.

• هنگام انجام عملیات push

   و pull

   مخازن، به‌اندازه گیت هاب سریع نیست.

• رابط «گیت لب» به‌گونه‌ای است که هنگام انقال از صفحه‌ای به صفحه دیگر کمی زمان می‌برد.

آموزش استفاده از گیت لب

برای استفاده از امکانات «GitLab» لازم است تا در وب‌سایت رسمی گیت لب «+» ثبت‌نام کنیم و پس از آن وارد حساب کاربری خود شویم.

پس از اینکه وارد حساب «GitLab» خود شدیم، پروژه جدیدی را ایجاد می‌کنیم (با کلیک روی گزینه Create a project).

در حین ایجاد پروژه جدید، می‌بایست اطلاعاتی همچون «نام پروژه» (Name)، «توصیف» (Description) و خصوصی یا عمومی بودن آن را تعیین کنیم.

پس از ساختن پروژه جدید، ابزار «Git Bash» را باز می‌کنیم. این ابزار، مانند خطِ فرمانی برای گیت عمل می‌کند و می‌توانیم دستورات گیت را در آن وارد کنیم. توجه داشته باشید که «Git Bash» همراه با «Git» نصب می‌شود. بنابراین، در صورتی‌که «Git Bash» روی سیستم شما نصب نیست، با توجه به سیستم عامل خود، می‌توانید آن را از وب‌سایت رسمی گیت «+» دانلود و نصب کنید.

تنظیم SSH در گیت لب چگونه است؟

در این قسمت می‌خواهیم نحوه تنظیم و پیکربندی «کلیدهای SSH»، به منظور اتصال ایمنِ نمونه گیت محلی با مخازن راه دور را بیان کنیم. مراحل پیکربندی «کلیدهای SSH» در ادامه آورده شده است.

اول از همه باید یک جفت «کلید SSH»، شامل کلیدهای عمومی و خصوصی را ایجاد کنیم. برای این منظور، «Git Bash» را باز و دستور ssh-keygen

 را در آن تایپ و اجرا می‌کنیم.

با این کار جفت کلیدهای مورد نیاز، در پوشه‌ای به‌نام .ssh

 ساخته می‌شوند. این پوشه به‌طور پیش‌فرض در دایرکتوری Users

 ویندوز وجود دارد.

همان‌طور که ملاحضه می‌کنید فایل‌های مربوط به کلیدهای «عمومی» (با پسوند ‎.‎pub‎) و «خصوصی» (بدون پسوند) ساخته شده‌اند. id_rsa.pub

 را در ویرایشگر متنی (مانند Notepad) باز و محتویات آن را کپی می‌کنیم. اکنون به حسابی که در گیت لب ساخته‌ایم می‌رویم و همان‌گونه که در ادامه ملاحضه می‌کنید، از قسمت Preferences

  ، گزینه SSH Keys

 را انتخاب و روی دکمه Add new key

 کلیک می‌کنیم.

در کادر Key

 ، کلید عمومی – که پیش از این کپی کرده بودیم – را «الصاق» (Paste) و در آخر روی دکمه Add key

 کلیک می‌کنیم.

نحوه کار با گیت لب چگونه است؟

دوباره به سراغ «Git Bash» می‌رویم و با تایپ و اجرای دستوراتی که در ادامه ملاحضه می‌کنید، «نام کاربری» (User name) و «آدرس ایمیل» (Email ID) خود را در «گیت لب» پیکربندی می‌کنیم.

Git config --global user.name "divanairuop"

Git config --global user.email divanairuop@gmail.com

نحوه تایپ و اجرای این دستورات را در ادامه آورده‌ایم.

ایجاد مخزن جدید

سپس، اولین «مخزن» (ریپوزیتوری | ریپو | Repository) خود را می‌سازیم. برای ایجاد ریپوزیتوری در دایرکتوی فعلی، از دستورات آورده شده استفاده می‌کنیم. با دستور اول دایرکتوری را ایجاد و با دستور دوم به آن منتقل می‌شویم.

mkdir divanairuop

cd divanairuop

تصویری که در ادامه آمده است، اجرای این دستورات در Git Bash را نشان می‌دهد.

دستور PWD

اکنون می‌توانیم با استفاده از دستور pwd

 به شکلی که در ادامه آمده است، «دایرکتوری کاری» را مشاهده کنیم.

دستور git init

پس از ورود به این پوشه، متوجه می‌شویم که در حال حاضر چیزی درون آن وجود ندارد. حالا وقت آن رسیده است که یک مخزن گیت را راه‌اندازی کنیم. برای این منظور از دستور Git init

 استفاده می‌کنیم.

اگر به خروجی دقت کنیم متوجه عبارت master

 می‌شویم. هنگامی‌که مخزن گیت برای نخستین بار ساخته می‌شود، «شاخه‌ای» (Branch) می‌سازد که master

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

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

توجه داشته باشید که نباید هیچ گونه تغییری در این دایرکتوری ( .git

) و محتوای آن – که به‌صورت خودکار تولید شده‌اند – ایجاد کنیم.

ایجاد فایلی جدید در مخزن

حالا می‌خواهیم برای آزمایش، فایلی متنی (به‌نام input

) درون دایرکتوری کاریِ مخزن ایجاد کنیم. فایلی که قرار است در آینده به مخزن گیت لب push

 شود. دستوراتی که در ادامه آمده است نحوه ایجاد یک فایل متنی و همچنین باز کردن آن با نرم‌افزار Notepad ویندوز را نشان می‌دهد.

touch input.txt

notepad input.txt

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

دستور status

حالا وقت آن رسیده است که «وضعیت» (Status) مخزن بررسی شود. برای این منظور از دستور git status

 استفاده می‌کنیم.

دستور git add

همان‌طور که ملاحضه می‌کنید، خروجی این دستور بیان‌گر این است که هنوز فایلی «Commit» نشده است و همچنین فایل‌هایی به‌صورت «Untracked» را مشاهده می‌کنیم که به‌رنگ قرمز نشان داده شده‌اند. لازم است یادآوری کنیم که فایل‌های «Untracked»، فایل‌هایی هستند که در دایرکتوری ریپوزیتوری وجود دارند اما هنوز به فهرست «Tracking» مخزن اضافه نشده‌اند. برای افزودن این فایل به ناحیه «Staging» (مرحله‌بندی) از دستور git add .

 کمک می‌گیریم.

دستور commit

اکنون می‌خواهیم فایل input

 را Commit کنیم. برای این کار از دستور commit

 به‌صورتی که آورده شده، استفاده می‌کنیم.

git commit -m "input"

در صورت اجرای صحیح، نتیجه به‌‌شکلی که در ادامه آمده، قابل مشاهده است.

حال اگر دوباره با استفاده از دستور git status

، وضعیت را بررسی کنیم، نتیجه آن مانند تصویری است که در ادامه می‌بینیم.

خروجی، بیان‌گر این است که در شاخه master

 موردی برای Commit وجود ندارد. به‌دلیل اینکه تنها یک فایل برای «Commit» وجود داشت که آن هم در مرحله پیشین انجام شد.

دستور git remote origin

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

 کنیم. برای این کار به رابط تحت وب GitLab می‌رویم و به‌صورتی که در ادامه ملاحضه می‌کنید دستور git remote origin

 را از آن کپی می‌کنیم.

دستور git push

پس از انجام این کار، به «Git Bash» بر می‌گردیم و دستور کپی شده در مرحله قبل را در آن Paste و اجرا می‌کنیم. حالا برای اینکه فایل input

 را به مخزن remote

 (راه دور) push

 کنیم، از دستور git remote -v

 و به‌دنبال آن از دستور git push -u origin master

 استفاده می‌کنیم.

پس از انجام مراحل فوق، اگر به حساب گیت لب خود برگردیم، فایل input

 را خواهیم دید که به پروژه اضافه شده است. همچنین می‌توانیم این فایل را باز و محتویات آن را بررسی کنیم.

روش ساخت پروژه در گیت لب چیست ؟

در این قسمت می‌خواهیم نحوه ساخت پروژه‌ای جدید در گیت لب را با هم مرور کنیم.

برای این منظور وارد حساب «GitLab» خود می‌شویم و از داشبورد «GitLab» روی دکمه «New project» کلیک می‌کنیم.

در صفحه نمایان شده، روی Create Blank Project

 کلیک می‌کنیم.

نام پروژه جدید و همچنین «عمومی» یا «خصوصی» بودن آن را تعیین می‌کنیم و در آخر روی دکمه Create project

 کلیک می‌کنیم. به این ترتیب پروژه جدید با نام my_new_prj

 ساخته می‌شود که این موضوع را در قالب پیامی در بالای پنجره نشان‌داده می‌شود.

نحوه درج مخزن در پروژه گیت لب چیست ؟

به منظور «درج» یا Push

 کردن «مخزن» (Repository) در پروژه، مراحل ادامه مطلب را دنبال می‌کنیم.

با استفاده از دستور git clone

 می‌توانیم نسخه‌ای از مخزن را به سیستم محلی خود کپی (یا اصطلاحاً Clone) کنیم.

دستور  clone، یک کپی از مخزن، درون دایرکتوری جدیدی به نام my_new_prj  ایجاد می‌کند. اکنون به این دایرکتوری جدید می‌رویم و دستوری که در ادامه آمده است را در آن اجرا می‌کنیم.

touch README.md

با این دستور یک فایل README.md ساخته می‌شود که می‌توانیم اطلاعات راجع به پوشه و پروژه خود را در آن قرار بنویسیم. این فایل را می‌توانیم با استفاده از دستوری که در ادامه آمده است به دایرکتوری ایجاد شده خود اضافه کنیم.

git add README.md

با استفاده از دستوری که در ادامه آمده است، تغییرات صورت گرفته را به‌همراه پیامی (گزارشی)، در مخزن ذخیره می‌کنیم.

git commit -m "add README"

لازم به ذکر است که فلگ -m

  به منظور افزودن پیامی در Commit مورد استفاده قرار گرفته است.

حالا با استفاده از دستوری که در ادامه آورده‌ایم، Commit-ها را به مخزن راه دور که در شاخه محلی ساخته شده است Push

   می‌کنیم.

git push -u origin master

انشعاب پروژه در گیت لب چیست ؟

«انشعاب» (Fork)، در حقیقت یک «کپی» (Duplicate) از مخزن اصلی ما محسوب می‌شود که تغییرات صورت گرفته در آن، پروژه اصلی را تحت تأثیر قرار نمی‌دهد. برای «Fork» کردن پروژه مورد نظر، روی گزینه Fork  کلیک می‌کنیم.

در صفحه نمایان شده کافی است روی دکمه Fork project

 کلیک کنیم تا عمل «Fork» انجام شود.

روش ایجاد شاخه در گیت لب چیست ؟

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

 ، پروژه خود را انتخاب می‌کنیم. برای ایجاد شاخه‌ای جدید، در داشبورد، روی علامت «+» کلیک و گزینه New branch

 را انتخاب می‌کنیم.

در صفحه «New Branch»، نام دلخواه برای شاخه جدید را وارد و روی دکمه Create branch

 کلیک می‌کنیم.

پس از ساخت موفقیت آمیز شاخه جدید، با صفحه‌ای شبیه به آنچه در ادامه آمده است روبه‌رو می‌شویم.

روش افزودن فایل در پروژه گیت لب چیست ؟

در این قسمت می‌خواهیم نحوه افزودن یک فایل به پروژه گیت لب را با هم مرور کنیم. برای این منظور ۲ روش پیشِ‌رو داریم که در ادامه فهرست کرده‌ایم.

• افزودن فایل از طریق رابط خطِ فرمان
• افزودن فایل از طریق رابط وب (وب‌سایت گیت لب)

ایجاد فایل با استفاده از رابط خطِ فرمان

برای ساخت فایل جدید با نام test_file.txt

 با استفاده از رابط خطِ فرمان، دستوری که در ادامه آمده است را در دایرکتوری پروژه اجرا می‌کنیم.

برای ایجاد فایل از دستور touch

 و برای فهرست کردن محتویات دایرکتوری کاری از دستور dir

 استفاده کرده‌ایم. اکنون با رفتن به دایرکتوری پروژه، فایلی جدیدی که ساختیم را در کنار سایر فایل‌ها می‌توانیم مشاهده کنیم.

ایجاد فایل با استفاده از رابط وب گیت لب

در محیط وبِ «گیت لب» و در بخش داشبورد، روی علامت «+» کلیک و گزینه New file

 را انتخاب می‌کنیم.

در پنجره نمایان شده، نام فایل را تعیین می‌کنیم و محتویاتی که برای آن در نظر گرفتیم را در ویرایشگر مربوطه اضافه می‌کنیم. در آخر با کلیک روی دکمه «Commit Changes»، فایل جدید ساخته می‌شود.

عملیات Rebase در گیت لب چیست ؟

«احیا» (Rebase) در گیت لب، راهی است که به کمک آن می‌توانیم شاخه master

 را با شاخه خود ادغام کنیم. مثل زمانی‌که در حال کار روی «long-running branch» (شاخه‌ای تحت توسعه، که مدت زیادی است به شاخه اصلی همچون master

 ادغام نشده است) هستیم.

برای انجام عملیات «Rebase»، لازم است تا مراحلی که در ادامه بیان می‌شود را دنبال کنیم. اول از همه به دایرکتوری پروژه خود می‌رویم و به کمک دستور git checkout

 شاخه‌ای جدید به‌نام rebase-example

 و می‌سازیم.

فلگ -b

 بیان‌گر نام شاخه جدید است.

اکنون، فایل جدیدی می‌سازیم و محتوایی به آن اضافه می‌کنیم.

محتوای «Welcome to Tutorialspoint» به فایل rebase_file.md

  اضافه می‌شود. فایل جدید را به پوشه کاری اضافه می‌کنیم و تغییرات را در مخزن (همراه با پیام)، با استفاده از دستور git commit

   ذخیره می‌کنیم.

فلگ -m

   برای افزودن پیامی به «Commit»، مورد استفاده قرار می‌گیرد.
اکنون به شاخه master

 می‌رویم. با استفاده از دستور git checkout

   می‌توانیم شاخه راه دور ( master

 نام شاخه اصلی) را «واکشی» (Fetch) کنیم.

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

 ، «Commit» می‌کنیم.

به شاخه rebase-branch

 می‌رویم تا «Commit» شاخه master

 را داشته باشیم.

حالا، می‌توانیم Commit شاخه master

را با شاخه rebase-branch

 را به کمک دستور git rebase

 ترکیب کنیم.

Squashing کامیت ها در گیت لب چیست ؟

«Squashing» یا «فشردن»، روشی است که با آن می‌توان چندین «Commit» را با هم ترکیب و به یک مورد تبدیل کرد (به‌خصوص هنگام دریافت «خواست ادغام» (Merge Request). برای انجام «Squashing»، می‌بایست مراحلی که در ادامه است را دنبال کنیم.

ابتدا به دایرکتوری پروژه می‌رویم و با دستور git checkout command

 ، شاخه جدیدی به‌نام squash-chapter

 می‌سازیم.

فلگ -b

 بیان‌گر نام شاخه جدید است.

اکنون، فایلی جدید با ۲ «Commit» ایجاد و سپس آن را به پوشه کاری اضافه می‌کنیم. در آخر، همان‌طوری که در ادامه ملاحضه می‌کنید، تغییرات را در مخزن ذخیره می‌کنیم.

حالا، با توجه به دستوری که در ادامه آمده است، «Commit-های فوق را به تنها یک «Commit» اصطلاحاٌ «Squash» می‌کنیم.

git rebase -i HEAD~2

دستور git rebase

در اینجا به منظور یکی کردن تغییرات از شاخه‌ای به شاخه دیگر استفاده شده است. HEAD~2

 نیز ۲ ‌‌کامیتِ «Squash» شده آخر را مشخص می‌کند.

یعنی اگر بخواهیم ۴ کامیت را «Squash» کنیم کافی است آن را به‌صورت HEAD~4

 بنویسیم. نکته قابل توجه در اینجا این است که برای انجام عملیات «Squash» حداقل به ۲ کامیت نیاز داریم.

پس از وارد کردن دستور فوق، ویرایشگری که در ادامه ملاحضه می‌کنید باز می‌شود که در خطِ دوم آن می‌بایست کلمه pick

 را به squash

 تغییر دهیم (باید این «Commit» را «Squash» کنیم).

حالا کلید Esc

 را می‌فشاریم، پس از آن :

و در نهایت wq

 را برای ذخیره و خروج از صفحه تایپ می‌کنیم. تنها کار باقی‌مانده این است که شاخه را به مخزن راه دور Push

 کنیم.

راهنمای دستورات گیت

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

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

git --version

برای افزودن نام کاربری و آدرس ایمیلِ «Git»، که به منظور شناسایی هویت کاربر هنگام «Commit» کردن اطلاعات به‌کار می‌رود، دستورات بخصوصی وجود دارد. با دستوری که در ادامه آمده است می‌توانیم «نام کاربری» (Username) را ثبت کنیم.

git config --global user.name "USERNAME"

پس از وارد کردن نام کاربری، می‌توانیم آن را با دستوری که در ادامه آمده است، بازبینی کنیم.

git config --global user.name

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

$ git config --global user.email "email_address@example.com"

همچنین، برای بررسی آدرس ایمیل از دستور آورده شده استفاده می‌کنیم.

git config --global user.email

اگر بخواهیم تمامی اطلاعات وارد شده را بررسی کنیم، دستور آورده شده را به‌کار می‌بریم.

git config --global --list

برای Pull

 یا «بیرون کشیدن» آخرین تغییرات صورت گرفته در شاخه master

 ، می‌توانیم دستور آورده شده را به‌کار ببریم.

git checkout master

با به‌کارگیری دستوری که در ادامه آمده است می‌توانیم آخرین تغییرات صورت گرفته را، در دایرکتوری کاری واکشی کنیم.

git pull origin NAME-OF-BRANCH -u

«NAME-OF-BRANCH» در اینجا می‌تواند master

یا هر شاخه موجودِ دیگری باشد. برای ایجاد «شاخه‌ای» (Branch) جدید، دستور آورده شده را به‌کار می‌بریم.

git checkout -b branch-name

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

git checkout branch-name

آرگومان branch-name

 بیان‌گر نام شاخه مورد نظر است.

با دستوری که در ادامه امده است می‌توانیم تغییرات ایجاد شده در فایل‌های خود (وضعیت) را بررسی کنیم.

git status

تغییرات با رنگ قرمز نشان داده می‌شوند که می‌توان آن‌ها را به صورتی که آورده شده به ناحیه «Staging» اضافه کرد.

git add file-name

همچنین، با به‌کارگیری دستوری که در ادامه آمده است، می‌توانیم تمامی فایل‌ها را به «Staging» اضافه کنیم.

git add *

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

git push origin branch-name

با دستور زیر می‌توانیم تمامی تغییرات به‌جز آن‌هایی‌که «Unstaged» هستند را حذف کنیم.

git checkout .

تغییرات «مرحله‌بندی نشده» (Unstaged)، تغییراتی هستند که توسط گیت ردیابی نمی‌شوند.

اگر بخواهیم تمامی تغییرات و همچنین فایل‌های «Untracked» راحذف کنیم می‌بایست دستور آورده شده را به‌کار ببریم.

$ git clean -f

فایل‌های «ردیابی نشده» (Untracked)، فایل‌هایی هستند که در دایرکتوری کاری مخزن ساختیم اما هنوز با استفاده از دستور git add

 به فهرست ردیابی مخزن اضافه نشده‌اند.

برای ادغام شاخه‌های ‌مختلف با شاخه «اصلی» (Master)، دستور آورده شده را مورد استفاده قرار می‌دهیم.

git checkout branch-name
git merge master 

همچنین می‌توانیم با استفاده از دستوری که در ادامه آمده است، شاخه «اصلی» (Master) را با شاخه ساخته شده «ادغام» (Merge) کنیم.

git checkout master
git merge branch-name 

ویژگی های متمایز کننده گیت لب کدام اند؟

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

• ابزاری قدرتمند برای برنامه‌نویسان: «گیت لب» ابزار پر قدرتی است که می‌تواند به برنامه‌نویسان در مدیریت مخازن کدهای خود، رصد مشکلات و مشارکت با سایر برنامه‌نویسان کمک کند. وجود رابط کاربری نسبتأ ساده، شروعِ کار با این ابزار را تسهیل می‌کند. علاوه بر این موارد، «گیت لب» طیف وسیعی از ویژگی‌ها از جمله «ردیابی مشکل» (Issue Tracking)، بازبینی و «بررسی کدها» (Code Reviews) و «درخواست‌های ادغام» (Merge Requests) را فراهم می‌کند که می‌تواند برای برنامه‌نویسان بسیار مفید باشد.
• آزاد و اوپن سورس: استفاده از گیت لب، آزاد و رایگان است. یعنی می‌توانیم از حساب شخصی خود برای ذخیره و مدیریت کدهایمان بدون پرداخت هیچ‌گونه هزینه‌ای استفاده کنیم. اما برای دسترسی به ویژگی‌های پیشرفته مانند «برنامه‌نویسی مشارکتی» (Collaborative Coding) و پایپلاین‌های CI/CD و غیره می‌بایست حساب خود را به طرح‌های پولی ارتقا دهیم. یکی از بزرگ‌ترین مزایای گیت لب، اوپن سورس بودن آن است. به بیان ساده‌تر یعنی هر کسی می‌تواند به‌صورت رایگان و بدون پرداخت هیچ‌گونه هزینه‌ای این ابزار را مورد استفاده قرار دهد. سورس کد GitLab نیز برای همگان در دسترس است و هرکسی می‌تواند آن را مشاهده یا اینکه در توسعه آن مشارکت کند. این ویژگی، GitLab را به‌گزینه‌ای عالی برای افرادی که می‌‌خواهند از ابزاری رایگان و اوپن سورس استفاده کنند، تبدیل کرده است.
• دارای انجمن قوی: دلیل دیگری که نشان می‌دهد گیت لب می‌تواند انتخابی مناسبی باشد این است که «جامعه‌ای» (Community | کامیونیتی) قوی از آن حمایت می‌کند. کامیونیتی گیت لب از برنامه‌نویسانی تشکیل شده است که از سراسر جهان در این پروژه مشارکت دارند. با وجود این قضیه مطمئن می‌شویم که گیت لب همیشه در حال بهبود و معرفی ویژگی‌های جدید است. علاوه بر این، اگر هنگام استفاده از این ابزار با مشکلی مواجه شدید، می‌توانیم روی کمک و پشتیبانی جامعه آن حساب کنیم.

• فرصت‌های شغلی با یادگیری گیت لب: امروزه، کارفرمایان به‌طور معمول به دنبال افرادی هستند که آشنایی و تجربه کار با ابزارها و فناوری‌های خاص را داشته باشند. دانستن طرز کار گیت لب در این مورد کمک زیادی به ما می‌کند تا از سایر افراد، متمایز و برای کارفرمایان تبدیل به انتخاب مناسب‌تری شویم. علاوه بر این، بسیاری از کارفرمایان میل دارند روی کارمندانی سرمایه‌گذاری کنند که حاضر به یادگیری مهارت‌های جدید هستند، بنابراین یادگیری نحوه استفاده از گیت لب نیز می‌تواند پیشرفت شغلی را برایمان به‌دنبال داشته باشد.
• گیت لب، انتخاب عالی برای مهندسان DevOps: بسیاری از مهندسان «دِوآپس» برای کمک به مدیریت پروژه‌هایشان به «GitLab» روی می‌آورند. «گیت لب» پلتفرمی قدرتمند برای خودکارسازی فرایندهای توسعه محسوب می‌شود که برنامه‌نویسان را قادر می‌سازد تا به‌راحتی و با سرعت زیادی اپلیکشن خود را با کمٰ‌ترین زحمت پیاده‌سازی کنند. علاوه بر این، انعطاف پذیری «GitLab» این امکان را فراهم می‌کند تا از آن در طیف وسیعی از موارد و به روش‌های مختلفی استفاده شود، همچنین آن را به انتخابی ایده آل برای مهندسان «DevOps» تبدیل می‌کند که به دنبال بهترین ابزار برای استفاده هستند.
• API قدرتمند: API «گیت لب» ابزار قدرتمندی است که امکان دسترسی به خدمات «GitLab» را از طریق برنامه‌نویسی برایمان فراهم می‌کند. از API «گیت لب» می‌توانیم برای خودکارسازی، ایجاد و مدیریت پروژه‌ها و کاربران استفاده کنیم، که در نهایت کل فرآیند توسعه را ساده می‌کند.
• یکپارچگی با سایر ابزارها: «گیت لب» به‌طور معمول با سایر ابزارهای مورد استفاده برنامه‌نویسان به‌خوبی ادغام می‌شود. به ‌طور مثال ، گیت لب می‌تواند با «Slack» ادغام شود و در نتیجه برای تعاملات و ارتباطات تیمی مفید باشد. علاوه بر این، پلاگین‌های زیادی برای «گیت لب» وجود دارد که می‌توانند قابلیت‌های بیشتری نظیر «نظارت بر مشکل» (Issue Trackers) و«ابزارهای بازبینی و بررسی کد» (Code Review Tools) و غیره را به آن اضافه کنند.

گیت لب CI/CD چیست؟

گیت لب CI/CD، ابزاری برای توسعه نرم‌افزار محسوب می شود که از «متدلوژی‌های پیوسته» (Continuous Methodologies) استفاده می‌کند.

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

اصطلاح «Software Deployment» با معادل‌هایی مانند «استقرار نرم‌افزار» یا «به‌کاراندازی نرم‌افزار»، به فرایندی اشاره دارد که در آن نرم‌افزار برای استفاده، روی دستگاه مورد نظر راه‌اندازی و آماده انجام کار می‌شود.

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

روش پیوسته (مداوم | مستمر)، ۳ رویکرد اصلی دارد که در ادامه فهرست کرده‌ایم.

• «یکپارچه‌سازی مداوم» (Continuous Integration | CI)
• «تحویل مستمر» (Continuous Delivery | CD)
• «استقرار پیوسته» (Continuous Deployment | CD)

گیت لب CI/CD، بخشی از «گیت لب» محسوب می‌شود که از آن برای تمامی روش‌های پیوسته (ادغام، تحویل و استقرار ). با استفاده از «CI/CD» می‌توانیم نرم‌افزار خود را بی‌نیاز از برنامه‌های شخص ثالث، «تست»، «بیلد» و «منتشر» کنیم.

یکپارچه سازی مداوم یا CI در گیت لب چیست ؟

برای درک «CI» می‌توانیم برنامه‌ای را در نظر بگیریم که کدهای آن در یک مخزن «Git» در «GitLab» ذخیره شده است. برنامه‌نویسان به‌طور روزانه و شاید هر روز چندین مرتبه، تغییرات کد را push

 می‌کنند. برای هر push

که به مخزن انجام می‌شود، می‌توانیم مجموعه‌ای از اسکریپت‌ها را به منظور «بیلد» و «تست» خودکار اپلیکیشن فراهم کنیم. در حقیقت، این اسکریپت‌ها به کاهش احتمال اینکه در اپلیکیشن با خطا روبه‌رو شویم، کمک می‌کنند.

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

برای مثال، خودِ «GitLab» را می‌توان به‌عنوان پروژه‌ای در نظر گرفت که از «CI» به‌عنوان روشی برای توسعه نرم‌افزار استفاده می‌کند. برای هر push

به پروژه، مجموعه‌ای از بررسی‌ها برای کدها اجرا می‌شود.

تحویل مستمر یا CD در گیت لب چیست ؟

تحویل مستمر، مرحله‌ای است که پس از «CI» انجام می‌شود. علاوه بر اینکه هر مرتبه با push

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

پس در تحویل مستمر، کدها به‌طور خودکار بررسی می‌شوند، اما برای استقرار تغییرات، نیازمند دخالت انسانی است.

استقرار پیوسته در گیت لب چیست ؟

«استقرار پیوسته»، مانند «تحویل مستمر»، مرحله دیگری است که پس از «CI» انجام می‌شود. تفاوتی که با آن دارد این است که به‌جای «مستقر کردن» (Deploying) برنامه به‌صورت دستی، آن را به‌صورت خودکار تنظیم می‌کنیم و بدین ترتیب دیگر نیازی به مداخله انسانی نیست.

روند کار CI/CD گیت لب چیست ؟

گیت لب CI/CD، «روند کاری» (Workflow) متداول و معمولی دارد. این روند را می‌توانیم با بحث در مورد پیاده‌سازی کدهایی در مورد یک مسئله و کار به‌صورت محلی روی تغییرات پیشنهادی خود شروع کنیم. سپس می توانیم Commit-های خود را به شاخه ویژگی در مخزن راه دوری که در «GitLab» میزبانی شده است «Push» کنیم. عمل «Push»، پایپ‌لاین CI/CD را برای پروژه‌مان ایجادمی‌کند. پس از آن برای «گیت لب CI/CD» مواردی که در ادامه آمده است را داریم.

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

• اسکریپت‌های خودکار را (به‌صورت متوالی یا موازی) اجرا می‌کند.
  • اپلیکیشن را «بیلد» و «تست» می‌کند.
  • تغییرات را در برنامه بازبینی نشان می‌دهد. همان‌طور که آن را در localhost

     مشاهده می‌کنیم.

پس از اینکه پیاده‌سازی، طبق انتظار اجرا شد.

• کدهایمان را بررسی و در نهایت تأیید می‌کنیم.
• شاخه ویژگی را با شاخه پیش‌فرض ادغام می‌کنیم.
  • ویژگی CI/CD گیت لب، تغییرات را (به‌صورت خودکار) در محیط تولید، مستقر می‌کند.

لازم به ذکر است که «شاخه ویژگی» (Feature Branch) در گیت هاب، نسخه‌ (یا کپی) از پایگاه کُدِ اصلی است که در آن فرد یا تیمی از برنامه‌نویسان می‌توانند روی یک ویژگی جدید کار کنند و تا زمان تکمیل، آن را توسعه دهند. اگر هم اشتباهی رخ داد، می‌توانند تغییرات را خنثی کنند (Roll back | بازگشت به وضعیت قبل قبلی).

گیت لب Runner چیست؟

«گیت لب Runner»، اپلیکیشنی است که به منظور اجرای «کارها» (Jobs) در یک «پایپ‌لاین» (pipeline) با «CI/CD» گیت کار می‌کند.

«GitLab Runner»، پروژه‌ای اوپن سورس است که برای اجرای «کارهای» (Jobs) ما و ارسال نتایج آن به «GitLab» مورد استفاده قرار می‌گیرد. «گیت لب رانر» همراه با «گیت لب CI» به‌کار برده می‌شود، «سرویس ادغام پیوسته اوپن سورسی» همراه با «GitLab» که کارها را هماهنگ می‌کند.

«GitLab Runner» را می‌توان با پیکربندی عمومی یا اختصاصی مورد استفاده قرار داد. به‌طوری‌که این امکان برای ما وجود دارد تا آن را بر اساس نیازهای «DevOps» خود سفارشی کنیم.

برخی از ویژگی‌های GitLab Runner را در ادامه ملاحضه می‌کنید.

• بخشی از «گیت لب» است و می‌تواند به‌عنوان «کانتینرِ Docker»، «خوشه Kubernetes» یا یک «Single Binary» مستقر شود.
• اوپن سورس است و می‌توانیم آن را به‌سادگی روی زیرساخت خود نصب و پیکربندی کنیم.
• روشی ایمن و مطمئن برای مدیریت فرایند «CI/CD» عرضه می‌کند تا از این طریق روی ساخت محصولات بهتر تمرکز کنیم.
• به کمک آن مطمئن می‌شویم که فرایندهای «DevOps» ما اجرای بدون دردسر و کارآمدی داشته باشند.

با گیت لب Runner، می‌توانیم از اینکه کدهایمان به‌سرعت و بطور قابل اعتمادی آزمایش و تحویل داده می‌شود اطمینان حاصل کنیم. این سرویس همچنین، به‌طور مؤثری فرایندهای «CI/CD» را از طریق «خودکارسازی و مقیاس‌پذیری» (Automation and Scalability) مدیریت و آن را به ابزاری ارزشمند برای تیم «DevOps» تبدیل می‌کند. انعطاف‌پذیری «GitLab Runner»، بیان‌گر این است که پایپلاین‌های «ادغام مداومی» که داریم، اجرای کارآمدی خواهند داشت.

«GitLab Runner» اجرای Job-های تعریف شده در gitlab-ci.yml

 (یا سایر فایل‌‌های پیکربندی) را بر عهده دارد. به این صورت که «کار» بررسی می‌شود، وابستگی‌ها (Dependencies | متعلقات) نصب می‌شوند و مجموعه تست اجرا می‌شود. پس از تکمیل همه کارها، موفقیت یا شکست هر کار به «GitLab» گزارش می‌دهد. علاوه بر این، می‌توان آن را برای اجرای Job-های خاص روی پلتفرم‌های گوناگون پیکربندی کنیم که امکان آزمایش و استقرار در محیط‌های مختلف را برایمان فراهم می‌کند.

نصب GitLab Runner چگونه است؟

این قسمت می‌خواهیم نحوه نصب گیت لب Runner روی ویندوز ۱۰ را با هم مرور کنیم. توجه داشته باشید که برای نصب این سرویس لازم است تا Git را روی سیستم نصب داشته باشم. Git را می‌توانیم از سایت رسمی آن «+» دانلود و نصب کنیم.

1. پوشه‌ای در مکان دلخواه روی سیستم می‌سازیم. (به‌طور مثال C:GitLab-Runner

    )

2. نسخه باینری گیت لب رانر را برای سیستم‌های ۶۴ بیتی از «+» و ۳۲ بیتی از «+» دانلود و در پوشه‌ای که ساختیم قرار می‌دهیم. ما در این‌جا نام فایل دانلود شده را به gitlab-runner.exe

    تغییر دادیم.

3. خطِ فرمان را باز می‌کنیم و به دایرکتوری ساخته شده می‌رویم.
4. با دستوراتی که در ادامه آمده است سرویس GitLab‌ Runner را نصب و اجرا می‌کنیم.

gitlab-runner.exe install

gitlab-runner.exe start

با استفاده از دستور زیر می‌توانیم نسخه GitLab‌ Runner نصب شده را برررسی کنیم.

gitlab-runner --version

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

در ادامه ۵ مزیت GitLab Runner را برشماردیم.

1. نصب ساده
2. اوپن سورس
3. مقیاس‌پذیری زیاد
4. پشتیبانی از Job-ها و تگ‌های مختلف
5. قابلیت استفاده بودن در پیکربندی عمومی یا خصوصی

بهترین روش‌ها برای کار با GitLab Runner کدام اند؟

بهترین تجربه‌هایی که می‌توان برای کار با ‌GitLab Runner در نظر گرفت را در ادامه آورده‌ایم.

1. Runner خود را به‌روز نگه داریم: توجه داشته باشیم که از آخرین نسخه گیت لب رانر استفاده کنیم. چون ویژگی‌های جدید و رفع‌باگ‌ها به‌صورت مستمر منتشر می‌شوند.
2. از برچسب‌گذاری استفاده کنیم: برای Job-ها برچسب بسازیم تا از این طریق بتوانیم آن‌ها را بر مبنای هدفی که دارند گروه‌بندی کنیم و به هر برچسب، سیاست‌هایی را اعمال کنیم. با این کار می‌توانیم مراحل مختلف فرایند CI/CD خود را به‌راحتی متمایز کنیم.
3. Runner-های متعددی را راه‌اندازی کنیم: می‌توانیم به منظور توزیع بار (Load) و فراهم کردن افزونگی، از چندین Runner (اشتراکی یا اختصاصی) استفاده کنید.
4. Runner خود را ایمن کنیم: مطمئن شویم که هنگام پیکربندی Runner،محافظت با پسورد یا رمزگذاری را فعال کرده‌ایم.
5. بر Runner نظارت داشته باشیم: معیارهای گوناگونی را برای نظارت بر عملکرد Runner به‌کار ببریم و هر مشکلی را پیش از تأثیرگذاری روی پایپلاین بیابیم.
6. از نهان‌سازی (caching | کَش کردن) استفاده کنیم: از نهان‌سازی به منظور سرعت بخشیدن به فرایند «ساخت» (Build) و کاهش استفاده از دیسک در در حین آن استفاده کنیم.
7. ابزارهای مربوط به CI/CD را به‌کار ببریم: برای تسهیل فرایندهای CI/CD، از ابزارهای موجود مانند GitLab CI/CD استفاده کنیم.

با در نظر داشتن این توصیه‌ها، می‌توانیم مطمئن باشیم که فرایندهای CI/CD، به‌خوبی و به‌طور قابل اعتماد اجرا می‌شوند. با استفاده از آن، می‌توانیم از خودکارسازی و مقیاس‌پذیری فرآیندهای «DevOps» بیشترین بهره را ببریم و مطمئن شویم که پایپلاین ما به‌طور کارآمدی اجرا می‌شود.

نحوه نصب گیت لب روی داکر

در این قسمت می‌خواهیم نحوه نصب «گیت لب» با استفاده از ایمیج رسمی گیت لب برای «داکر» (Docker) را با هم مرور کنیم.

توجه داشته باشید که ایمیج‌های داکر فاقد «عامل انتقال مِیل» (Mail Transport Agent | MTA) هستند. راه‌حلی که برای این مورد پیشنهاد می‌شود، افزودن «MTA» به‌صورتی است که در «کانتینر» (Container) جداگانه‌ای اجرا شود. راه‌حل دیگر این است که «MTA» را مستقیماً در کانتینر گیت لب نصب کنیم که هزینه نگهداری را افزایش می‌دهد به این دلیل که بعد از هر ارتقا یا ری‌استارت نیاز است تا «MTA» را دوباره نصب کنیم.

با فرض اینکه «Docker» روی سیستم ما نصب است. کار را شروع می‌کنیم.

روش های نصب گیت لب روی داکر کدام اند؟

روش‌های مختلفی برای اجرای ایمیج‌های گیت لب برای داکر وجود دارد که در ادامه با آن‌ها آشنا می‌شویم.

• استفاده از«موتور داکر» (Docker Engine)
• استفاده از Docker Compose
• استفاده از «حالت ازدحامی داکر» (Docker swarm mode)

تنظیم موقعیت Volumes ها چگونه است؟

قبل از اینکه به سراغ تنظیم سایر موارد برویم، لازم است «متغیری محیطی» (Environment Variable) جدیدی به‌نام $GITLAB_HOME

ایجاد کنیم که به دایرکتوری مربوط به «پیکربندی» (Configuration)، «گزارش‌ها» (Logs) و «فایل‌های داده» (Data Files) اشاره دارد. پس می‌بایست از موجود بودن این دایرکتوری و همچنین از اینکه مجوز‌های مناسبی به آن اعطا شده است، اطمینان حاصل کنیم.

کاربران لینوکس، می‌بایست مسیر را به‌صورت /srv/gitlab

 تنظیم کنند.

export GITLAB_HOME=/srv/gitlab

کاربران macOS، باید از دایرکتوری $HOME/gitlab

 کاربران استفاده کنند.

export GITLAB_HOME=$HOME/gitlab

متغیر محیطی GITLAB_HOME

 می‌بایست به «پروفایل پوسته» (Shell’s Profile) افزوده تا در تمامی جلسات بعدی ترمینال، اِعمال شود.

• ‌Bash: ~/.bash_profile
• ZSH: ~/.zshrc

کانتینر گیت لب از Volume-های نصب شده میزبان، برای ذخیره داده‌های «دائمی» (Persistent) استفاده می‌کند.

موقعیت محلی	موقعیت کانتینر	کاربرد
$GITLAB_HOME/data	/var/opt/gitlab	ذخیره داده‌های اپلیکیشن
$GITLAB_HOME/logs	/var/log/gitlab	ذخیره لاگ‌ها (گزارش‌ها)
$GITLAB_HOME/config	/etc/gitlab	ذخیره فایل‌های پیکربندی گیت لب

نصب گیت لب با Docker Engine چگونه است؟

به‌صورتی که در ادامه نشان داده‌ایم، دایرکتوری‌ها را تنظیم می‌کنیم تا نیازهایمان را برآورده کنند. وقتی‌که متغیر GITLAB_HOME

 را تنظیم کردیم، می‌توانید ایمیج را اجرا کنیم.

sudo docker run --detach 
  --hostname gitlab.example.com 
  --publish 443:443 --publish 80:80 --publish 22:22 
  --name gitlab 
  --restart always 
  --volume $GITLAB_HOME/config:/etc/gitlab 
  --volume $GITLAB_HOME/logs:/var/log/gitlab 
  --volume $GITLAB_HOME/data:/var/opt/gitlab 
  --shm-size 256m 
  gitlab/gitlab-ee:latest

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

 ، HTTP

 و HTTPS

 را فراهم می‌کند. تمامی داده‌های «گیت لب» به‌عنوان زیردایرکتوری‌های $GITLAB_HOME

 ذخیره خواهد شد. کانتینر به‌طور خودکار پس از راه‌اندازی مجدد سیستم restart

 خواهد شد.

اگر از «SELinux» استفاده می‌کنید، لازم است تا دستورات زیر به‌جای مواردی که بیان شد تنظیم کنید.

sudo docker run --detach 
  --hostname gitlab.example.com 
  --publish 443:443 --publish 80:80 --publish 22:22 
  --name gitlab 
  --restart always 
  --volume $GITLAB_HOME/config:/etc/gitlab:Z 
  --volume $GITLAB_HOME/logs:/var/log/gitlab:Z 
  --volume $GITLAB_HOME/data:/var/opt/gitlab:Z 
  --shm-size 256m 
  gitlab/gitlab-ee:latest

از این طریق اطمینان حاصل می‌شود که فرایند داکر، مجوز‌ها و دسترسی‌های کافی به منظور ساخت، فایل‌های پیکربندی در Volume-های «نصب شده» (Mounted) را دارد.
فرایند «شروع اولیه» (Initialization) ممکن است مدت زمانی به طول بیانجامد. می‌توانیم با دستوری که در ادامه آمده است این روند را زیر نظر داشته باشیم.

sudo docker logs -f gitlab

پس از راه‌اندازی کانتینر، می‌توانیم به آدرس gitlab.example.com

 (یا http://192.168.59.103

 در صورت استفاده از boot2docker در macOS) مراجعه کنید. شروع پاسخ دادن کانتینر Docker به پرس‌وجوها ممکن است مدتی طول بکشد.

به URL گیب لب مراجعه و با نام کاربری root

 و رمز عبور، از دستور زیر وارد می‌شویم.

sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

نصب گیت لب با Docker Compose چگونه است؟

با استفاده از Docker Compose به آسانی می‌توانیم «گیت لب» مبتنی بر داکر را پیکربندی و نصب کنیم و همچنین آن را ارتقا دهیم.

اولین قدم این است که «Docker Compose» را از «+» نصب کنیم. در گام بعدی، فایلی با نام docker-compose.yml

 می‌سازیم.

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.example.com'
        # Add any other gitlab.rb configuration here, each on its own line
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

با قرار گرفتن در دایرکتوری docker-compose.yml

، گیت لب را اجرا می‌کنیم .

docker compose up -d

در ادامه، نمونه دیگری از docker-compose.yml

را با گیت لبی که روی پورت HTTP و SSH سفارشی اجرا شده است، ملاحضه می‌کنید. به نحوه تطابق متغیرهای «GITLAB_OMNIBUS_CONFIG»  با بخش ports

دقت کنید.

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com:8929'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
    ports:
      - '8929:8929'
      - '2224:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

نصب گیت لب با Docker swarm mode چگونه است؟

با استفاده از «Docker swarm mode»، به‌آسانی می‌توانیم نصب گیت لب مبتنی بر داکر را در «خوشه ازدحامی» (Swarm Cluster) پیکربندی و اجرا کنیم.

در حالت ازدحام می‌توانیم «Docker Secrets» و «Docker Configurations» را به منظور استقرار بهینه و ایمن نمونه گیت لب خود مورد استفاده قرار دهیم. با استفاده از «Secrets» می‌توانیم رمز عبور root

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

در ادامه، مثالی را بیان می‌کنیم که گیت لب را با ۴ اجرا کننده (Runner) به‌عنوان پشته و با به‌کارگیری «Secrets» و «Configurations» پیاده‌سازی می‌کند. با هدف سادگی، پیکربندی network

 حذف شده است.

version: "3.6"
services:
  gitlab:
    image: gitlab/gitlab-ee:latest
    ports:
      - "22:22"
      - "80:80"
      - "443:443"
    volumes:
      - $GITLAB_HOME/data:/var/opt/gitlab
      - $GITLAB_HOME/logs:/var/log/gitlab
      - $GITLAB_HOME/config:/etc/gitlab
    shm_size: '256m'
    environment:
      GITLAB_OMNIBUS_CONFIG: "from_file('/omnibus_config.rb')"
    configs:
      - source: gitlab
        target: /omnibus_config.rb
    secrets:
      - gitlab_root_password
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    deploy:
      mode: replicated
      replicas: 4
configs:
  gitlab:
    file: ./gitlab.rb
secrets:
  gitlab_root_password:
    file: ./root_password.txt

در گام سوم، یک فایل gitlab.rb

 می‌سازیم .

external_url 'https://my.domain.com/'
gitlab_rails['initial_root_password'] = File.read('/run/secrets/gitlab_root_password').gsub("n", "")

در گام چهارم نیز می‌بایست فایل root_password.txt

 را ایجاد کنیم.

MySuperSecretAndSecurePassw0rd!

در گام پنجم، ابتدا مطمئن می‌شویم که در دایرکتوری docker-compose.yml

 قرار داریم و سپس دستوری که در ادامه آمده است را اجرا می‌کنیم.

docker stack deploy --compose-file docker-compose.yml mystack

نحوه نصب گیت لب روی داکر

کانتینر از بسته رسمی گیت لب «Omnibus» استفاده می‌کند. بنابراین تمام تنظیمات در فایل پیکربندی بخصوصی /etc/gitlab/gitlab.rb

 انجام می‌شود.

برای اینکه به فایل پیکربندی گیت لب دسترسی پیدا کنیم، می‌توانیم یک «Shell Session» را در کانتینرِ در حال اجرا شروع کنیم. با این کار می‌توانیم به تمام دایرکتوری‌ها دسترسی داشته باشیم و از ویرایشگر متن دلخواهمان استفاده کنیم.

sudo docker exec -it gitlab /bin/bash

همچنین می‌توانیم تنها /etc/gitlab/gitlab.rb

 را ویرایش کنیم.

sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb

زمانی‌که فایل /etc/gitlab/gitlab.rb

 را باز کردیم. می‌بایست external_url

 را به‌گونه‌ای تنظیم کنیم که به URL معتبری اشاره کند.

برای اینکه بتوانیم از گیت لب، ایمیل دریافت کنیم می‌بایست تنظیمات «SMTP» را نیز پیکربندی کنیم چون ایمیجِ داکرِ گیت لب، سرور «SMTP» را نصب نمی‌کند. پس از اینکه تغییرات مورد نظر را انجام دادیم، برای پیکربندی مجدد گیت لب با این تنظیمات، نیاز است تا کانتینر را دوباره «راه‌اندازی مجدد» (ری‌استارت) کنیم.

sudo docker restart gitlab

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

آشنایی بیشتر با گیت لب

«GitLab» یکی از کمپانی‌های خصوصی آمریکایی در حوزه نرم‌افزار است که سروری مرکزی برای مدیریت «مخازن گیت» (Git Repositories) فراهم می‌کند و برای کمک به ساده‌سازیِ وظایف مدیریتی، در اختیار شرکت‌های زیادی در سراسر دنیا قرار می‌دهد.

گیت لب به میلیون‌ها کاربر در سراسر جهان خدمت‌رسانی می‌کند. این محصول همچنین توسط سازمان‌های بزرگ و شناخته شده‌ای نظیر IBM، Sony و NASA مورد استفاده قرار گرفته است. در ادامه برخی مفاهیم و تعاریف اولیه مانند «سیستم کنترل نسخه» و «سیستم کنترل نسخه گیت» را با هم بررسی می‌کنیم.

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

«کنترل نسخه» به تیم‌ها کمک می‌کند تا برای برطرف کردن ناسازگاری‌ها (مثل زمانی که با هم روی یک پروژه کار می‌کنند) و همچنین ایجاد مکانی متمرکز برای کدهایشان، با هم مشارکت داشته باشند.

با استفاده از «سیستم‌های کنترل نسخه» (Version Control Systems | VCS) می‌توان تغییرات صورت گرفته در کدهای پروژه را رصد کرد. این قابلیت به برنامه‌نویسان اجازه می‌دهد تا تغییراتی که به‌وسیله افراد و در زمان‌های مختلف انجام شده است را ببینند و همچنین در صورت لزوم، از نسخه کنونی به نسخه پیشین پروژه بازگردند.

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

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

• «محلی» (Local): در این حالت، «فایل‌های منبع» (Source Files) درون سیستمی محلی، ذخیره و نگهداری می‌شوند.
• «متمرکز» (Centralized): «VCS» متمرکز، تغییرات را در یک سِروِر ذخیره می‌کند.
• «توزیع شده» (Distributed): این حالت از VCS-ها «کِلونینگ» یا «همانندسازی» (Cloning) مخزن گیت را در بر می‌گیرند.

لزوم استفاده از کنترل نسخه چیست؟

با توجه به اینکه سازمان‌ها به‌وسیله «DevOps» ارائه راهکارهای نرم‌افزاری خود را سرعت می‌بخشند، کنترل و مدیریت نسخه‌های مختلف محصولات نرم‌افزاری، (از کدها تا پیکربندی و از طراحی تا استقرار)، به طور فزاینده‌ای دشوار می‌شود.

نرم‌افزارِ کنترل نسخه، مواردی همچون هماهنگی، اشتراک‌گذاری و مشارکت را در کل تیم توسعه نرم‌افزار تسهیل می‌کند. همچنین امکان کار در محیط‌های توزیع شده و ناهمزمان، مدیریت تغییرات و نسخه‌های کدها و محصولات و همین‌طور رفع «ناسازگاری‌ها در ادغام» (Merge Conflicts) و ایراد‌های مرتبط را برای تیم‌ها فراهم می‌کند.

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

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

به‌کارگیری سیستم‌های کنترل نسخه، مزایایی به‌همراه دارد که در ادامه به آن‌ها اشاره کرده‌ایم.

• کیفیت (Quality): امکان بررسی، نظر دادن و بهبود کدها و Asset-های یکدیگر، برای تیم‌ها وجود دارد.
• سرعت (Acceleration): ایجاد «شاخه‌ای» (Branch) از کدها، اِعمال تغییرات و «ادغام کامیت‌ها» (Merge Commits) به‌صورت سریع‌تری انجام می‌شود.
• شفافیت (Visibility): وضوح و شفافیت بیشتر، هر موردی را، از مدیریت پروژه گرفته تا کیفیت کدها، بهبود می‌بخشد.

گیت چیست؟

«گیت» (Git)، سیستم کنترل نسخه‌ای است که برای ردیابی و پیگیری تغییرات فایل‌های کامپیوتری استفاده می‌شود.

هدف اصلی «Git» این است که هرگونه تغییری که در فایل‌های یک یا چند پروژه ایجاد می‌شود را در دوره زمانی معین، مدیریت کند. این کار به ایجاد هماهنگی وظایف، بین اعضای تیم پروژه، کمک به‌سزایی می‌کند و پیشرفت آن را در طول زمان پایش می‌کند. گیت می‌تواند با نظارت فایل‌های پروژه، برای برنامه‌نویسان حرفه‌ای و همین‌طور کاربران غیر حرفه‌ای مفید باشد. این ابزار همچنین می‌تواند برای مدیریت پروژه‌ها (با هر اندازه‌ای که دارند) به‌کار گرفته شود و این امکان را برای کاربران متعدد فراهم می‌کند که بدون تأثیرگذاری و مزاحمت در کار یکدیگر، با هم مشارکت و همکاری داشته باشند.

گیت لب، گیت هاب و بیت باکِت چه نوع خدماتی هستند؟

«GitLab» ،«GitHub» و «Bitbucket»، سرویس‌هایی هستند که دسترسی ریموت (از راه دور | Remote) به مخازن «Git» را فراهم می‌کنند. این سرویس‌ها علاوه بر «میزبانی» (Hosting) کدهایمان، ویژگی‌های بیشتری را نیز ارائه می‌دهند که به منظور کمک به مدیریت چرخه‌تولید نرم‌افزار، طراحی شده‌اند. این ویژگی‌ها، مواردی همچون مدیریت اشتراک‌گذاری کدها بین افراد گوناگون، رهگیری باگ‌ها، «Wiki space» و سایر ابزارهای مربوط به «کدنویسی اجتماعی» را در بر می‌گیرند.

در یکی از مطالب پیشین تم آف، به‌طور مفصل توضیح دادیم که گیت هاب چیست و اشاره کردیم که GitHub، سرویسی رایگان است و راهکارهایی را در اختیارمان قرار می‌دهد که فرایند توسعه پروژه‌هایمان را ساده می‌کند و سرعت می‌بخشد. سایر توسعه‌دهندگان می‌توانند کدهایی که به گیت هاب «Push» می‌کنیم را ببیند و برای بهبود آن پیشنهاداتی را ارائه دهند. در حال حاضر، گیت هاب از سورس کد ده‌ها هزار پروژه اوپن سورس میزبانی می‌کند.

سوالات متداول

در این قسمت می‌خواهیم برخی از پرسش‌های رایج و پرتکرار در مورد موضوع «گیت لب» را با هم بررسی کنیم و پاسخ بدهیم.

تفاوت گیت هاب و گیت لب چیست ؟

با توجه به اینکه «GitHub» و «GitLab» هر دو، سیستمِ کنترلِ نسخه محسوب می‌شوند و امکانات مفیدی را در اختیار برنامه‌نویسان قرار می‌دهند، انتخاب یکی از آن‌ها به لحاظ برتر بودن، کار سختی می‌تواند باشد. مهم‌ترین تفاوت بین این ۲ ابزار را می‌توان به این صورت بیان کرد که «GitHub» به‌عنوان «پلتفرم همکاری» (Collaboration Platform) به بررسی و مدیریت کدها «از راه دور» (Remotely) کمک می‌کند اما تمرکز «GitLab» تا حد زیادی روی «DevOps» و «CI/CD» قرار دارد.

آیا استفاده از گیت لب رایگان است؟

بسیاری از قابلیت‌های گیت لب به‌صورت رایگان در دسترس کاربران قرار دارد. اما ویژگی‌هایی مخصوص به مدیران را عرضه می‌کند که با پرداخت هزینه می‌توان به آن دسترسی داشت.

آیا گیت لب قابل اعتماد است؟

بله. گیت لب، دارای برنامه امنیتِ اطلاعاتِ مستند است که سیاست‌ها (خطِ‌مشی‌ها) و رویه‌هایی نظیر مدیریت دسترسی، دسته‌بندی و حفاظت از داده‌ها و سایر موارد را در بر می‌گیرد.

سطوح رویت پذیری پروژه ها در گیت لب کدام اند؟

در سطح «خصوصی» (Private)، دسترسی پروژه به‌طور صریح به هر کاربر اعطا می‌شود. اگر این پروژه بخشی از یک گروه باشد، دسترسی به اعضای گروه داده می‌شود. در سطح «داخلی» (Internal)، هر کاربری که احراز هویت شده باشد (غیر از کاربران بیرونی) می‌تواند به پروژه دسترسی داشته باشد. در سطح «عمومی» (Public)، پروژه بدون هیچ گونه احراز هویتی قابل دسترسی است.

گیت لب CI چیست؟

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

کاربرد گیت لب رانر چیست؟

GitLab Runner، یک از مهم‌ترین اجزای پایپلاین «ادغام و تحویل مداوم» (CI/CD) گیت لب محسوب می‌شود که کارهای CI/CD ما را اجرا می‌کند و نتایج را به گیت لب باز می‌گرداند.

جمع‌بندی

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

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

با استفاده از «GitLab»، می‌توانید اطمینان حاصل کنید که پایپلاین CI/CD شما به‌طور قابل اعتماد و کارآمدی اجرا می‌شود و آن را به ابزاری ارزشمند برای هر تیم DevOps تبدیل می‌کند. جدای از این موارد، انعطاف‌پذیری را برای برآورده ساختن نیازهای خاص شما عرضه و به شما کمک می‌کند تا از قدرت «خودکارسازی» استفاده کنید. فرآیندهای CI/CD خود را ساده کنید و منابعی را در اختیار تیم‌های DevOps خود قرار بدهید که برای موفقیت پروژه، به‌ آن نیاز دارند.