-
1. شروع به کار (getting started)
-
2. مقدمات گیت (git basics chapter)
- 2.1 گرفتن یک مخزن گیت (Getting a Git Repository)
- 2.2 ثبت تغییرات در مخزن (Recording Changes to the Repository)
- 2.3 مشاهده تاریخچه کامیتها (Viewing the Commit History)
- 2.4 بازگرداندن تغییرات (Undoing Things)
- 2.5 کار کردن با ریموت ها (Working with Remotes)
- 2.6 تگ کردن (Tagging)
- 2.7 نام مستعار گیت (Git Aliases)
- 2.8 خلاصه (summary)
-
3. انشعابگیری در گیت (Git Branching)
-
4. گیت روی سرور (Git on the server)
- 4.1 پروتکلها (The Protocols)
- 4.2 راهاندازی گیت روی یک سرور (Getting Git on a Server)
- 4.3 ایجاد کلید عمومی SSH شما (Generating Your SSH Public Key)
- 4.4 نصب و راهاندازی سرور (Setting up server)
- 4.5 سرویسدهنده گیت (Git Daemon)
- 4.6 HTTP هوشمند (Smart HTTP)
- 4.7 گیتوب (GitWeb)
- 4.8 گیتلب (GitLab)
- 4.9 گزینههای میزبانی شخص ثالث (Third Party Hosted Options)
- 4.10 خلاصه (Summary)
-
5. گیت توزیعشده (Distributed git)
-
6. GitHub (گیت هاب)
-
7. ابزارهای گیت (Git Tools)
- 7.1 انتخاب بازبینی (Revision Selection)
- 7.2 مرحلهبندی تعاملی (Interactive Staging)
- 7.3 ذخیره موقت و پاکسازی (Stashing and Cleaning)
- 7.4 Signing Your Work (امضای کارهای شما)
- 7.5 جستجو (Searching)
- 7.6 بازنویسی تاریخچه (Rewriting History)
- 7.7 بازنشانی به زبان ساده (Reset Demystified)
- 7.8 ادغام پیشرفته (Advanced Merging)
- 7.9 بازاستفاده خودکار از حل تضادها (Rerere)
- 7.10 اشکالزدایی با گیت (Debugging with Git)
- 7.11 سابماژول ها (Submodules)
- 7.12 بستهبندی (Bundling)
- 7.13 جایگزینی (Replace)
- 7.14 ذخیرهسازی اطلاعات ورود (Credential Storage)
- 7.15 خلاصه (Summary)
-
8. سفارشیسازی Git (Customizing Git)
-
9. گیت و سیستمهای دیگر (Git and Other Systems)
-
10. (Git Internals)
- 10.1 ابزارها و دستورات سطح پایین (Plumbing and Porcelain)
- 10.2 اشیا گیت (Git Objects)
- 10.3 مراجع گیت (Git References)
- 10.4 فایلهای بسته (Packfiles)
- 10.5 نگاشت (The Refspec)
- 10.6 پروتکلهای انتقال (Transfer Protocols)
- 10.7 نگهداری و بازیابی دادهها (Maintenance and Data Recovery)
- 10.8 متغیرهای محیطی (Environment Variables)
- 10.9 (Summary)
-
A1. پیوست A: گیت در محیطهای دیگر (Git in Other Environments)
- A1.1 رابط های گرافیکی (Graphical Interfaces)
- A1.2 Git در ویژوال استودیو (Git in Visual Studio)
- A1.3 Git در Visual Studio Code (Git in Visual Studio Code)
- A1.4 Git در IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine (Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine)
- A1.5 Git در Sublime Text (Git in Sublime Text)
- A1.6 گیت در بش (Git in Bash)
- A1.7 Git در Zsh (Git in Zsh)
- A1.8 Git در PowerShell (Git in PowerShell)
- A1.9 خلاصه (Summary)
-
A2. پیوست B: گنجاندن گیت در برنامههای شما (Embedding Git in your Applications)
-
A3. پیوست C: دستورات گیت (Git Commands)
- A3.1 تنظیم و پیکربندی (Setup and Config)
- A3.2 گرفتن و ایجاد پروژهها (Getting and Creating Projects)
- A3.3 نمونهبرداری پایهای (Basic Snapshotting)
- A3.4 انشعابگیری و ادغام (Branching and Merging)
- A3.5 بهاشتراکگذاری و بهروزرسانی پروژهها (Sharing and Updating Projects)
- A3.6 بازرسی و مقایسه (Inspection and Comparison)
- A3.7 عیبیابی (Debugging)
- A3.8 اعمال تغییرات به صورت پچ (Patching)
- A3.9 ایمیل (Email)
- A3.10 سیستمهای خارجی (External Systems)
- A3.11 مدیریت (Administration)
- A3.12 دستورات سطح پایین گیت (Plumbing Commands)
4.8 گیت روی سرور (Git on the server) - گیتلب (GitLab)
گیتلب (GitLab)
گیتوب نسبتاً ساده است. اگر به دنبال یک سرور گیت مدرن و کامل هستید، چندین راهحل متنباز وجود دارد که میتوانید به جای آن نصب کنید. از آنجایی که گیتلب یکی از محبوبترینهاست، نصب و استفاده از آن را به عنوان نمونه بررسی میکنیم. این گزینه نسبت به گیتوب سختتر است و نیاز به نگهداری بیشتری دارد، اما یک گزینه کاملاً مجهز است.
نصب (Installation)
گیتلب یک برنامه وب مبتنی بر پایگاه داده است، بنابراین نصب آن پیچیدهتر از برخی سرورهای گیت دیگر است. خوشبختانه این فرایند به خوبی مستندسازی و پشتیبانی شده است. گیتلب به شدت توصیه میکند که آن را روی سرور خود از طریق بسته رسمی Omnibus GitLab نصب کنید.
گزینههای نصب دیگر عبارتند از:
-
چارت Helm گیتلب برای استفاده با کوبرنتیز.
-
بستههای داکریزه شده گیتلب برای استفاده با داکر.
-
نصب از فایلهای منبع.
-
ارائهدهندگان ابری مانند AWS، Google Cloud Platform، Azure، OpenShift و Digital Ocean.
برای اطلاعات بیشتر به GitLab Community Edition (CE) readme مراجعه کنید.
مدیریت (Administration)
رابط مدیریت گیتلب از طریق وب قابل دسترسی است.
فقط مرورگر خود را به نام میزبان یا آدرس IP که گیتلب روی آن نصب شده است، هدایت کنید و با کاربر root
وارد شوید.
رمز عبور بسته به نوع نصب شما متفاوت است اما به طور پیشفرض، Omnibus GitLab به صورت خودکار رمز عبوری ایجاد میکند و آن را حداقل به مدت ۲۴ ساعت در /etc/gitlab/initial_root_password ذخیره میکند.
برای جزئیات بیشتر مستندات را دنبال کنید.
پس از ورود، روی آیکون «منطقه مدیریت» در منوی بالای سمت راست کلیک کنید.
کاربران (Users)
همه کسانی که از سرور گیتلب شما استفاده میکنند باید حساب کاربری داشته باشند.
حسابهای کاربری ساده هستند و عمدتاً شامل اطلاعات شخصی مرتبط با دادههای ورود به سیستم میشوند.
هر حساب کاربری یک فضای نام دارد که گروهبندی منطقی پروژههایی است که به آن کاربر تعلق دارند.
اگر کاربر jane پروژهای به نام project داشته باشد، آدرس آن پروژه به صورت http://server/jane/project
خواهد بود.

شما میتوانید یک حساب کاربری را به دو روش حذف کنید: «مسدود کردن» کاربر مانع از ورود او به نمونه گیتلب میشود، اما همه دادههای زیر فضای نام آن کاربر حفظ میشود و کامیتهایی که با ایمیل آن کاربر امضا شدهاند همچنان به پروفایل او لینک میشوند.
«حذف» کاربر، از سوی دیگر، او را به طور کامل از پایگاه داده و سیستم فایل پاک میکند. تمام پروژهها و دادههای فضای نام او حذف شده و هر گروهی که مالک آن باشد نیز برداشته میشود. این اقدام بسیار دائمی و مخرب است و به ندرت به آن نیاز خواهید داشت.
گروه ها (Groups)
گروه گیتلب مجموعهای از پروژهها به همراه اطلاعاتی درباره نحوه دسترسی کاربران به آن پروژههاست.
هر گروه یک فضای نام پروژه دارد (مانند کاربران)؛ بنابراین اگر گروه training پروژهای به نام materials داشته باشد، آدرس آن پروژه http://server/training/materials
خواهد بود.

هر گروه با تعدادی کاربر مرتبط است که هر کدام سطح دسترسی خاصی به پروژههای گروه و خود گروه دارند. این سطوح از «مهمان» (فقط مسائل و چت) تا «مالک» (کنترل کامل گروه، اعضا و پروژهها) متغیر است. انواع مجوزها بسیار زیاد است و نمیتوان همه را اینجا فهرست کرد، اما گیتلب لینک مفیدی در صفحه مدیریت دارد.
پروژه ها (Projects)
یک پروژه در گیتلب تقریباً متناظر با یک مخزن گیت است. هر پروژه به یک فضای نام تعلق دارد، یا یک کاربر یا یک گروه. اگر پروژه متعلق به یک کاربر باشد، مالک پروژه مستقیماً کنترل دسترسی به آن را دارد؛ اگر پروژه متعلق به یک گروه باشد، مجوزهای سطح کاربر گروه اعمال میشود.
هر پروژه یک سطح دسترسی دارد که مشخص میکند چه کسانی میتوانند به صفحات و مخزن آن دسترسی خواندنی داشته باشند.
اگر پروژه خصوصی باشد، مالک پروژه باید به طور صریح دسترسی به کاربران خاصی بدهد.
پروژه داخلی برای هر کاربر وارد شده قابل مشاهده است و پروژه عمومی برای همه قابل دیدن است.
توجه داشته باشید که این کنترل هم دسترسی git fetch
و هم دسترسی به رابط وب پروژه را شامل میشود.
هوک ها (Hooks)
گیتلب از هوکها پشتیبانی میکند، هم در سطح پروژه و هم در سطح سیستم. در هر یک از این موارد، سرور گیتلب هر زمان رویدادهای مرتبط رخ دهد، یک درخواست HTTP POST با یک JSON توصیفی ارسال میکند. این راهی عالی برای اتصال مخازن گیت و نمونه گیتلب شما به سایر ابزارهای اتوماسیون توسعه مانند سرورهای CI، اتاقهای گفتگو یا ابزارهای استقرار است.
استفاده پایه (Basic Usage)
اولین کاری که با گیتلب میخواهید انجام دهید، ایجاد یک پروژه جدید است. میتوانید این کار را با کلیک روی آیکون "`{plus}`" در نوار ابزار انجام دهید. از شما خواسته میشود نام پروژه، فضای نامی که باید به آن تعلق داشته باشد، و سطح دید آن را مشخص کنید. بیشتر مواردی که اینجا تعیین میکنید دائمی نیستند و بعداً میتوان آنها را از طریق رابط تنظیمات تغییر داد. روی "`Create Project`" کلیک کنید و کار تمام است.
پس از ایجاد پروژه، احتمالاً میخواهید آن را به یک مخزن گیت محلی متصل کنید.
هر پروژه از طریق HTTPS یا SSH قابل دسترسی است و هرکدام میتوانند برای پیکربندی یک ریموت گیت استفاده شوند.
آدرسهای URL در بالای صفحه اصلی پروژه قابل مشاهدهاند.
برای یک مخزن محلی موجود، این فرمان یک ریموت به نام gitlab
به مکان میزبانی شده ایجاد میکند:
$ git remote add gitlab https://server/namespace/project.git
If you don’t have a local copy of the repository, you can simply do this:
$ git clone https://server/namespace/project.git
رابط کاربری وب دسترسی به چندین نمای مفید از خود مخزن را فراهم میکند. صفحه اصلی هر پروژه فعالیتهای اخیر را نشان میدهد و لینکهای بالای صفحه شما را به نمای فایلها و گزارش کامیتهای پروژه هدایت میکنند.
همکاری گروهی (Working Together)
سادهترین روش برای همکاری در یک پروژه گیتلب، دادن دسترسی مستقیم برای پوش به هر کاربر است. میتوانید با رفتن به بخش “Members” در تنظیمات پروژه، یک کاربر را اضافه کنید و سطح دسترسی مناسبی به او اختصاص دهید (سطوح دسترسی مختلف در گروه ها (Groups) کمی توضیح داده شدهاند). با دادن سطح دسترسی “Developer” یا بالاتر به یک کاربر، آن کاربر قادر خواهد بود کامیتها و شاخهها را مستقیماً به مخزن پوش کند.
روش دیگری که همکاری را مستقلتر میکند، استفاده از درخواستهای ادغام (merge requests) است.
این ویژگی به هر کاربری که بتواند پروژه را ببیند اجازه میدهد به شیوهای کنترل شده مشارکت کند.
کاربرانی که دسترسی مستقیم دارند، میتوانند به سادگی یک شاخه بسازند، کامیتها را به آن پوش کنند و یک درخواست ادغام از شاخه خود به شاخه master
یا هر شاخه دیگری باز کنند.
کاربرانی که مجوز پوش ندارند، میتوانند مخزن را “fork” کنند تا نسخه خود را بسازند، کامیتها را به نسخه خود پوش کنند و سپس درخواست ادغام از فورک خود به پروژه اصلی باز کنند.
این مدل به مالک اجازه میدهد کنترل کامل روی موارد وارد شده به مخزن و زمان آنها داشته باشد، در حالی که امکان مشارکت کاربران غیرمطمئن را فراهم میکند.
درخواستهای ادغام و مسائل (issues) واحدهای اصلی بحثهای طولانیمدت در گیتلب هستند. هر درخواست ادغام امکان بحث خط به خط درباره تغییر پیشنهادی (که نوعی بازبینی کد سبک است) و همچنین یک رشته بحث کلی و عمومی را فراهم میکند. همگی میتوانند به کاربران اختصاص داده شده یا در قالب مایلستونها سازماندهی شوند.
این بخش عمدتاً بر ویژگیهای مرتبط با گیت در گیتلب تمرکز دارد، اما به عنوان یک پروژه بالغ، امکانات بسیاری دیگر برای کمک به همکاری تیمی ارائه میدهد، مانند ویکیهای پروژه و ابزارهای نگهداری سیستم. یکی از مزایای گیتلب این است که پس از راهاندازی و اجرای سرور، به ندرت نیاز به تغییر فایل پیکربندی یا دسترسی به سرور از طریق SSH خواهید داشت؛ بیشتر مدیریت و استفاده عمومی از طریق رابط مرورگر انجام میشود.