-
1. شروع به کار
- 1.1 دربارهٔ کنترل نسخه
- 1.2 تاریخچهٔ کوتاهی از گیت
- 1.3 گیت چیست؟
- 1.4 خط فرمان
- 1.5 نصب گیت
- 1.6 اولین راهاندازی گیت
- 1.7 کمک گرفتن
- 1.8 خلاصه
-
2. مقدمات گیت
- 2.1 دستیابی به یک مخزن گیت
- 2.2 ثبت تغییرات در مخزن
- 2.3 دیدن تاریخچهٔ کامیتها
- 2.4 بازگردانی کارها
- 2.5 کار با ریموتها
- 2.6 برچسبگذاری
- 2.7 نامهای مستعار در گیت
- 2.8 خلاصه
-
3. شاخهسازی در گیت
- 3.1 شاخهها در یک کلمه
- 3.2 شاخهسازی و ادغام مقدماتی
- 3.3 مدیریت شاخه
- 3.4 روند کاری شاخهسازی
- 3.5 شاخههای ریموت
- 3.6 ریبیسکردن
- 3.7 خلاصه
-
4. گیت روی سرور
- 4.1 پروتکلها
- 4.2 راهاندازی گیت در سرور
- 4.3 ساختن کلید عمومی SSH
- 4.4 نصب و راهاندازی سرور
- 4.5 دیمن گیت
- 4.6 HTTP هوشمند
- 4.7 گیتوب
- 4.8 گیتلب
- 4.9 گزینههای شخصی ثالث میزبانی شده
- 4.10 خلاصه
-
5. گیت توزیعشده
- 5.1 روندهای کاری توزیعشده
- 5.2 مشارکت در یک پروژه
- 5.3 نگهداری یک پروژه
- 5.4 خلاصه
-
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. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
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 in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.6 Git in Sublime Text
- A1.7 Git in Bash
- A1.8 Git in Zsh
- A1.9 Git in PowerShell
- A1.10 Summary
-
A2. پیوست B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
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 گیت روی سرور - گیتلب
گیتلب
با این همه گیتوب بسیار ساده است. اگر به دنبال یک گیت سرور مدرنتر و با امکانات کامل هستید، چنیدن راه حل متن-باز موجود جایگزین موجود است که میتوانید نصب کنید. از آنجایی که گیتلب یکی از معروفترینهاست، ما نصب و استفاده از آن را به عنوان یک مثال بررسی خواهیم کرد. این مورد کمی پیچیدهتر از گزینه گیتوب است و احتمالاً نگهداری بیشتری نیز میطلبد، اما گزینهای با امکانات بسیار کاملتر است.
نصب
گیتلب یک نرمافزار وب مبتنی بر پایگاهداده است، بنابراین نصب آن کمی درگیرکنندهتر از بعضی دیگر از گیت سرورها است. خوشبختانه، این فرآیند کاملاً پشتیبانی شده و به خوبی مستند شده است.
چندین متد و راه برای دنبال کردن نصب گیتلب وجود دارد. بری شروع سریع، میتوانید یک ایمیج ماشین مجازی یا نرمافزار نصب آسان از https://bitnami.com/stack/gitlab دانلود کنید، و تنظیمات آنرا ویرایش کنید تا متناسب با محیط شما شود. یکی از کارهای قشنگ Bitnami شامل کردن یک صفحه لاگین است (قابل دسترسی با تایپ →+alt)؛ این صفحه به شما آدرس آیپی و نامکاربری و رمز پیشفرض گیتلب نصب شده را میگوید.
برای هر چیز دیگری، راهنماییهای در فایل readme گیتلب ویرایش جامعه را بخوانید که در آدرس https://gitlab.com/gitlab-org/gitlab-ce/tree/master پیدا میشود. آنجا با استفاده از فرمول سرآشپز، ماشین مجازی روی Digital Ocean، پکیجهای RPM و DEB (که به وقت این نوشته در بتا هستند) کمک خواهید یافت. همچنین یک راهنما «غیررسمی» راهاندازی گیتلب با سیستمعاملها و پایگاهدادههای غیراستاندارد، یک اسکریپت نصب دستی و بسیاری تاپیکهای دیگر موجود است،
مدیریت
رابط مدیریتی گیتلب به وسیله وب قابل دسترسی است.
کافیست مرورگر خود را به آدرس هاست یا آدرس آیپی جایی که گیتلب در آنجا نصب شده است هدایت کنید، و به عنوان کاربر مدیر وارد شوید.
نام کاربری پیش فرض admin@local.host
و رمز عبور پیش 5iveL!fe
است (که به محض ورود برای تغییر آن به شما اعلان داده میشود).
هنگامی که وارد شدید بر روی آیکن بالا سمت راست منو «Admin area» کلیک کنید.
کاربران
کابران در گیتلب، حسابهایی متناظر با هر فرد هستند.
حسابهای کاربری پیچیدگی خاصی ندارند؛ به طور کل، مجموعهای از اطلاعات شخصی الحاق شده به اطلاعات ورود هستند.
هر نام کاربری با یک فضانام (Namespace) میآید، که گروهبندی منطقی از پروژههای مربوطی به آن کاربر است.
اگر کاربر jane
پروژهای به نام project
داشته باشد، آدرس آن پروژه http://server/jane/project
خواهد بود.
حذف یک کاربر به وسیله دو راه انجام میشود. «Blocking» یا مسدود کردن یک کاربر باعث جلوگیری از لاگین کردن آنها به اینستنس گیتلب میشود، اما همهٔ دادههای کاربر زیر فضانام او خواهد باقی ماند و همچنین کامیتهای ثبت شده با ایمیل آن کاربر همچنان به حساب کاربری اون لینک خواهند ماند.
از سویی دیگر، «Destroying» یا نابود کردن یک کاربر، به طور کلی او را از پایگاهداده و فایلسیستم حذف میکند. همه پروژهها و دادههای درون فضانام او پاک خواهد شد، و هر گروهی که داشته باشند نیز نیز پاک خواهد شد. بدیهی است که این فعلی بسیار مخربتر و دائمیتر است و کاربردهای آن نادر هستند.
گروهها
یک گروه گیتلب مشتکله از پروژههایی همراه با اطلاعاتی درباره نحوه دسترسی کاربران به آن پروژهها است.
هر گروه یک فضانام پروژه (به همان صورتی که کاربران دارند) دارد، بنابراین اگر گروه training
پروژهای به نام materials
داشته باشند، آدرس آن http://server/training/materials
خواهد بود.
هر گروه به تعدادی از کاربران وصل است، که هر کدام سطح دسترسی نسبت به پروژههای گروه و خود گروه را دارند. این طیف دسترسیها از «Guest» (فقط چت و ایشوها) تا «Owner» (کنترل کامل گروه، اعضای آن و پروژههای آن) میباشد. سطوح دسترسی برای لیست کردن در اینجا بسیار زیاد هستند، منتهی گیتلب لینکی مفید در این رابطه در صفحه مدیریت دارد.
پروژهها
یک پروژه گیتلب به سختی متناظر با یک واحد پروژه گیت است. هر پروژه متعلق به یک فضانام واحد، یا مال کاربر یا گروه، است. اگر پروژهآی متعلق به یک کاربر باشد، مالک پروژه کنترل مستقیم روی تمام افرادی به پروژه دسترسی دارند دارد؛ اگر پروژه متعلق به یک گروه باشد، دسترسیهای سطح کاربری گروه نیز تأثیرگذار خواهند بود.
بعلاوه هر پروژه دارای یک سطح وضوح است که تعیین میکند چه کسی دسترسی خواندن صفحات و مخزن پروژه را دارد.
اگر پروژهای خصوصی باشد، مالک پروژه باید صراحتاً دسترسی به هر کاربر را دهد.
یک پروژه داخلی برای هر کاربری که ورود کرده باشد قابل مشاهده است، و یک پروژه عمومی برای همهٔ افراد قابل مشاهده است.
به خاطر داشته باشید که این هر دو دسترسی git fetch
و دسترسی از طریق رابطه کاربری وب را کنترل میکند.
قلابها
گیتلب از هوکها یا قلابها هم پشتیبانی میکند، هم در سطح پروژه و هم در سطح سیستمی. برای هر کدام از اینها، در هر لحظه که رویدادهای مرتبط اتفاق بیوفتد، سرور گیتلب یک درخواست HTTP POST همراه کمی JSON توصیفی میفرستد. این روش عالی برای اتصال به مخازن گیت و اینستنس گیتلب برای دیگر اتوماسیونهای توسعه شما مانند سرورهای CI، چت رومها یا ابزاهای توسعه است.
استفاده ابتدایی
اولین کاری که میخواهید در گیتلب انجام دهید ساخت یک پروژه جدید است. این عمل با کلیک بر روی علامت «+» بر روی نوار ابزار امکان پذیر است. از شما نام پروژه، فضانامی که باید برای آن تعیین کنید و سطح وضوحی که باید داشته باشد پرسیده خواهد شد. بیشتر چیزهایی که اینجا مشخص میکنید دائمی نیستند و در آینده میتوان آنها را از طریق رابط تنظیمات بازتنظیم کرد. بر روی «Create Project» بزنید و تمام.
بعد از اینکه پروژه به وجود میآید، احتمالاً میخواهید با یک مخزن محلی گیت به آن متصل شوید.
هر پروژهای میتواند از طریق پروتکلهای SSH یا HTTPS قابل دسترسی باشد، هر کدام میتواند برای تنظیم یک ریموت گیت استفاده شود.
URLهای پروژه در قسمت بالای خانهٔ پروژه قابل مشاهده هستند.
برای یک مخزن محلی از پیش موجود، این دستور یک ریموت با نام gitlab
به آدرس میزبانی شده میسازد:
$ git remote add gitlab https://server/namespace/project.git
اگر کپی محلی از مخزن ندارید میتوانید این دستور را اجرا کنید:
$ git clone https://server/namespace/project.git
رابطه کاربری وب برای شما چندین ویوی مفید به خود مخزن ارائه میکند. صفحهٔ اصلی هر پروژه فعالیتهای اخیر را نشان میدهد و لینکها بالا شما را به صفحات فایلها و کامیت لاگ هدایت میکند.
کارکردن با یکدیگر
سادهترین راه برای کارکردن با یکدیگر بر یک پروژه گیتلب، به کاربری دیگر دسترسی پوش مستقیم به مخزن گیت دادن است. با رفتن به قسمت «Members» در بخش تنظیمات پروژه مرتبط بروید میتوانید یک کاربر را به پروژه اضافه، و به کاربر جدید سطح جدید از دسترسی ارائه کنید (کمی درباره سطوح دسترسی در قسمت گروهها بحث کردهایم). با اعطا کردن سطح دسترسی «Devloper» یا بالاتر به کاربر، آن کاربر میتواند به صورت مستقیم برنچ و کامیت به مخزن پوش کند.
راه دیگر گسستهتر مشارکت در پروژه، استفاده از درخواست ادغام یا Merge Request است.
این امکان هر کاربری که بتواند پروژه را ببیند قادر میسازد تا به نحوی قابل کنترل در پروژه مشارکت کند.
کاربران با دسترسی مستقیم میتوانند یک برنچ بساند، کامیت به آن پوش کنند و یک درخواست ادغام از برنچ خودشان به master
یا هر برنچ دیگری باز کنند.
کاربرانی که مجوز پوش مستقیم به مخزنی را ندارند میتوانند آنرا «فورک» کنند (کپی خودشان را بسازند)، به آن کپی کامیت پوش کنند و یک درخواست مرج از فورکشان به پروژه اصلی باز کنند.
این مدل به صاحب این امکان را میدهد که در کنترل کامل اتفاقات و زمان اتفاق افتادن آنها باشد، همه در مادامی که مشارکتها را از کاربران غیرقابل قبول میکند.
درخواستهای ادغام و ایشوها واحدهای اصلی بحثهای طولانی در گیتلب هستند. هر درخواست ادغام اجازه بحث روی خط به خط تغییرات ارائه شده (که از نوعی سبک از بازبینی کد هم پشتیبانی میکند) و همچنین بحث کلی درباره کلیت کار را میدهد. که میتوانند به کاربران یا نقاط طرقی سازماندهی شده واگذار شوند.
این بخش به طور کل به روی ویژگیهای مرتبط با گیت گیتلب تمرکز دارد،اما در پروژههای بالغ، ویژگیهای بیشمار دیگری نیز برای کمک به کار تمیمی ارائه هم ارائه میکند، مثلاً ویکیهای پروژه و ابزارهای نگهداری سیستم.