مرجع فرمان Repo

مخزن (Repo) با ساده‌سازی کار در چندین مخزن، گیت را تکمیل می‌کند. برای توضیح رابطه بین مخزن (Repo) و گیت، به ابزارهای کنترل منبع (Source control tools) مراجعه کنید. برای جزئیات بیشتر در مورد مخزن (Repo)، به فایل راهنمای مخزن (Repo README) مراجعه کنید.

استفاده از مخزن (Repo) به شکل زیر است:

repo command options

عناصر اختیاری در داخل براکت [] نشان داده شده‌اند. برای مثال، بسیاری از دستورات project-list به عنوان آرگومان دریافت می‌کنند. می‌توانید project-list به عنوان لیستی از نام‌ها یا لیستی از مسیرها به دایرکتوری‌های منبع محلی برای پروژه‌ها مشخص کنید:

repo sync [project0 project1 ... projectn]
repo sync [/path/to/project0 ... /path/to/projectn]

کمک

repo help

در مورد دستور repo راهنمایی ارائه می‌دهد. می‌توانید اطلاعات دقیقی در مورد یک دستور Repo خاص را با مشخص کردن یک دستور به عنوان یک گزینه مشاهده کنید:

repo help command

برای مثال، دستور زیر توضیحات و لیستی از گزینه‌های دستور init را ارائه می‌دهد:

repo help init

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

repo command --help

برای مثال:

repo init --help

اولیه

repo init -u url [options]

Repo را در دایرکتوری فعلی نصب می‌کند. این دستور یک دایرکتوری .repo/ با مخازن Git برای کد منبع Repo و فایل‌های استاندارد مانیفست اندروید ایجاد می‌کند.

گزینه‌ها:

• -u : یک URL مشخص می‌کند که از آن می‌توانید مخزن مانیفست را بازیابی کنید. مانیفست رایج در https://android.googlesource.com/platform/manifest یافت می‌شود.

• -m : یک فایل manifest را در مخزن انتخاب می‌کند. اگر هیچ نام manifest انتخاب نشود، پیش‌فرض default.xml است.

• -b : یک ویرایش، یعنی یک manifest-branch خاص، را مشخص می‌کند.

همگام‌سازی

repo sync [project-list]

تغییرات جدید را دانلود کرده و فایل‌های فعال را در محیط محلی شما به‌روزرسانی می‌کند، که اساساً git fetch در تمام مخازن Git انجام می‌دهد. اگر repo sync بدون آرگومان اجرا کنید، فایل‌ها را برای همه پروژه‌ها همگام‌سازی می‌کند.

وقتی repo sync اجرا می‌کنید، این اتفاق می‌افتد:

• اگر پروژه هرگز همگام‌سازی نشده باشد، repo sync معادل git clone است؛ تمام شاخه‌های موجود در مخزن ریموت به دایرکتوری پروژه محلی کپی می‌شوند.

• اگر پروژه قبلاً همگام‌سازی شده باشد، آنگاه repo sync معادل است با:

  git remote update
  git rebase origin/branch
  

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

پس از اجرای موفقیت‌آمیز repo sync ، کد موجود در پروژه‌های مشخص‌شده به‌روز شده و با کد موجود در مخزن راه دور همگام‌سازی می‌شود.

گزینه‌های کلیدی:

• -c : فقط شاخه مانیفست فعلی را از سرور دریافت می‌کند.
• -d : پروژه‌های مشخص شده را به نسخه مانیفست برمی‌گرداند. این گزینه در صورتی مفید است که پروژه روی یک شاخه موضوعی باشد، اما نسخه مانیفست به طور موقت مورد نیاز باشد.
• -f : حتی اگر یک پروژه همگام‌سازی نشود، همگام‌سازی پروژه‌های دیگر را ادامه می‌دهد.
• -j threadcount : برای تکمیل سریع‌تر، همگام‌سازی را بین رشته‌ها تقسیم می‌کند. مطمئن شوید که دستگاه خود را بیش از حد بارگذاری نمی‌کنید - مقداری از CPU را برای سایر وظایف رزرو کنید. برای دیدن تعداد CPUهای موجود، ابتدا nproc --all را اجرا کنید.
• -q : با سرکوب پیام‌های وضعیت، بی‌سروصدا اجرا می‌شود.
• -s : همگام‌سازی با یک نسخهٔ ساخته‌شدهٔ خوب که توسط عنصر manifest-server در manifest فعلی مشخص شده است.

برای گزینه‌های بیشتر، repo help sync اجرا کنید.

آپلود

repo upload [project-list]

تغییرات را در سرور بررسی بارگذاری می‌کند. برای پروژه‌های مشخص‌شده، Repo شاخه‌های محلی را با شاخه‌های راه دور که در آخرین همگام‌سازی Repo به‌روزرسانی شده‌اند، مقایسه می‌کند. Repo از شما می‌خواهد یک یا چند شاخه‌ای را که برای بررسی بارگذاری نشده‌اند، انتخاب کنید.

سپس تمام کامیت‌های روی شاخه‌های انتخاب‌شده از طریق اتصال HTTPS به Gerrit منتقل می‌شوند. برای فعال کردن مجوز آپلود، باید یک رمز عبور HTTPS پیکربندی کنید. برای ایجاد یک جفت نام کاربری/رمز عبور جدید برای استفاده از طریق HTTPS، به مولد رمز عبور مراجعه کنید.

وقتی Gerrit داده‌های شیء را از طریق سرور خود دریافت می‌کند، هر کامیت را به یک تغییر تبدیل می‌کند تا بررسی‌کنندگان بتوانند در مورد یک کامیت خاص نظر بدهند. برای ترکیب چندین کامیت Checkpoint در یک کامیت واحد، قبل از اجرای آپلود git rebase -i استفاده کنید.

اگر repo upload بدون آرگومان اجرا کنید، تمام پروژه‌ها را برای یافتن تغییرات جهت آپلود جستجو می‌کند.

برای ویرایش تغییرات پس از آپلود شدن، از ابزاری مانند git rebase -i یا git commit --amend برای به‌روزرسانی کامیت‌های محلی خود استفاده کنید. پس از اتمام ویرایش‌ها:

• تأیید کنید که شاخه‌ی به‌روزرسانی‌شده، شاخه‌ی بررسی‌شده‌ی فعلی است.
• برای باز کردن ویرایشگر تطبیق تغییرات repo upload --replace PROJECT استفاده کنید.

• برای هر کامیت در این مجموعه، شناسه تغییر Gerrit را داخل پرانتز وارد کنید:

  # Replacing from branch foo
  [ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
  [ 2829 ] ec18b4ba Update proto client to support patch set replacements
  # Insert change numbers in the brackets to add a new patch set.
  # To create a new change record, leave the brackets empty.
  

پس از اتمام آپلود، تغییرات دارای یک مجموعه پچ اضافی هستند.

اگر می‌خواهید فقط شاخه‌ی گیتِ بررسی‌شده‌ی فعلی را آپلود کنید، از پرچم --current-branch (یا به اختصار --cbr ) استفاده کنید.

برای تغییرات مرتبط، بهتر است همه CLها را در یک موضوع نگه دارید. می‌توانید هنگام آپلود با استفاده از --topic=TOPIC نام موضوع را اضافه کنید. یا فقط با استفاده -t نام موضوع را با نام شاخه محلی تنظیم کنید.

تفاوت

repo diff [project-list]

تغییرات برجسته بین کامیت و درخت کاری را با استفاده از git diff نشان می‌دهد.

دانلود

repo download target change

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

برای مثال، برای دانلود تغییر ۲۳۸۲۳ در دایرکتوری platform/build خود:

repo download platform/build 23823

اجرای repo sync هر commit بازیابی شده با repo download حذف می‌کند. یا می‌توانید با استفاده از git checkout m/main شاخه ریموت را بررسی کنید.

برای همه

repo forall [project-list] -c command

دستور shell داده شده را در هر پروژه اجرا می‌کند. متغیرهای محیطی اضافی زیر توسط repo forall در دسترس قرار می‌گیرند:

• REPO_PROJECT برابر با نام منحصر به فرد پروژه تنظیم شده است.
• REPO_PATH مسیری نسبت به ریشه کلاینت است.
• REPO_REMOTE نام سیستم راه دور از فایل manifest است.
• REPO_LREV نام نسخه‌ای از مانیفست است که به یک شاخه ردیابی محلی ترجمه شده است. اگر نیاز دارید نسخه مانیفست را به یک دستور گیت که به صورت محلی اجرا می‌شود، ارسال کنید، از این متغیر استفاده کنید.
• REPO_RREV نام ویرایش از مانیفست است، دقیقاً همانطور که در مانیفست نوشته شده است.

گزینه‌ها:

• -c : دستور و آرگومان‌هایی که باید اجرا شوند. دستور از طریق /bin/sh ‎ ارزیابی می‌شود و هر آرگومان پس از آن به عنوان پارامترهای موقعیتی شل ارسال می‌شود.
• -p : نمایش هدرهای پروژه قبل از خروجی دستور مشخص شده. این کار با اتصال pipeها به جریان‌های stdin، stdout و sterr دستور و پایپ کردن تمام خروجی‌ها به یک جریان پیوسته که در یک جلسه pager نمایش داده می‌شود، انجام می‌شود.
• -v : نمایش پیام‌هایی که دستور در stderr می‌نویسد.

هرس کردن

repo prune [project-list]

موضوعاتی را که قبلاً ادغام شده‌اند، حذف می‌کند (هرس می‌کند).

شروع

repo start branch-name [project-list]

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

آرگومان BRANCH_NAME توضیح مختصری از تغییری که می‌خواهید در پروژه‌ها ایجاد کنید ارائه می‌دهد. اگر نمی‌دانید، می‌توانید از نام default استفاده کنید.

آرگومان project-list مشخص می‌کند که کدام پروژه‌ها در این شاخه موضوعی شرکت دارند.

وضعیت

repo status [project-list]

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

برای دیدن وضعیت شاخه فعلی، repo status . اطلاعات وضعیت بر اساس پروژه فهرست شده است. برای هر فایل در پروژه، از یک کد دو حرفی استفاده می‌شود.

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

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

مدیریت خطاهای مخزن

git commit -a # Commit local changes first so they aren't lost.
repo start branch-name # Start the branch
git reset --hard HEAD@{1} # And reset the branch so that it matches the commit before repo start
repo upload .

خطای repo: error: no branches ready for upload زمانی ظاهر می‌شود که دستور repo start در ابتدای جلسه اجرا نشده باشد. برای بازیابی، می‌توانید شناسه commit را بررسی کنید، یک شاخه جدید شروع کنید و سپس آن را ادغام کنید.

ساختار مخزن گیت

برای اندروید، مخازن (پروژه‌ها) گیت تو در تو نیستند. هر پروژه با یک دایرکتوری خاص در درخت منبع مرتبط است و تمام زیردایرکتوری‌ها و فایل‌های زیر آن دایرکتوری بخشی از همان پروژه هستند. از استفاده از ویژگی git submodule در Repo برای توسعه اندروید خودداری کنید.