GIT-P4(1) راهنمای گیت GIT-P4(1) نام (NAME) git-p4 - وارد کردن از و ارسال به مخازن Perforce خلاصه دستور (SYNOPSIS) git p4 clone [<گزینه‌های-همگام‌سازی>] [<گزینه‌های-شبیه‌سازی>] <مسیر-انبار-p4>... git p4 sync [<گزینه‌های-همگام‌سازی>] [<مسیر-انبار-p4>...] git p4 rebase git p4 submit [<گزینه‌های-ارسال>] [<نام-شاخه-اصلی>] توضیحات (DESCRIPTION) این دستور راهکاری برای تعامل با مخازن p4 با استفاده از گیت فراهم می‌کند. با استفاده از git p4 clone و دادن یک یا چند مسیر انبار (depot) p4 به آن، یک مخزن گیت جدید از یک مخزن موجود p4 بسازید. کامیت‌های جدید ناشی از تغییرات p4 را با استفاده از git p4 sync ادغام و وارد کنید. دستور sync همچنین برای افزودن شاخه‌های جدید از سایر مسیرهای انبار p4 استفاده می‌شود. تغییرات گیت را با استفاده از git p4 submit به p4 برگردانید و ارسال کنید. دستور git p4 rebase یک عملیات sync به علاوه بازنشانی پایه (rebase) شاخه کنونی روی شاخه دوردست به‌روزشدهٔ p4 انجام می‌دهد. مثال‌ها (EXAMPLES) • شبیه‌سازی یک مخزن: $ git p4 clone //depot/path/project • انجام مقداری کار در مخزن گیت تازه ایجاد شده: $ cd project $ vi foo.h $ git commit -a -m "edited foo.h" • به‌روزرسانی مخزن گیت با تغییرات اخیر از p4، و بازنشانی پایهٔ (rebase) کار شما روی آن: $ git p4 rebase • ارسال کامیت‌های شما به p4: $ git p4 submit دستورها (COMMANDS) شبیه‌سازی (Clone) به طور کلی، git p4 clone برای ایجاد یک دایرکتوری گیت جدید از یک مخزن موجود p4 استفاده می‌شود: $ git p4 clone //depot/path/project این کار: 1. یک مخزن خالی گیت در یک زیردایرکتوری به نام project ایجاد می‌کند. 2. محتوای کامل نسخهٔ سر (head revision) را از مسیر انبار p4 داده‌شده به صورت یک تک‌کامیت در شاخه گیت refs/remotes/p4/master وارد می‌کند. 3. یک شاخه محلی به نام master از این شاخهٔ دوردست ایجاد کرده و آن را تحویل (checkout) می‌گیرد. برای بازتولید تمام تاریخچه p4 در گیت، از تغییردهندهٔ @all در مسیر انبار استفاده کنید: $ git p4 clone //depot/path/project@all همگام‌سازی (Sync) همان‌طور که توسعه در مخزن p4 ادامه می‌یابد، آن تغییرات را می‌توان با استفاده از دستور زیر در مخزن گیت گنجاند: $ git p4 sync این دستور تغییرات جدید را در p4 پیدا کرده و آن‌ها را به عنوان کامیت‌های گیت وارد می‌کند. مخازن p4 را می‌توان با استفاده از git p4 sync به یک مخزن موجود گیت نیز افزود: $ mkdir repo-git $ cd repo-git $ git init $ git p4 sync //path/in/your/perforce/depot این کار انبار مشخص‌شده را در refs/remotes/p4/master در یک مخزن موجود گیت وارد می‌کند. گزینهٔ --branch می‌تواند برای تعیین یک شاخهٔ متفاوت جهت استفاده برای محتوای p4 به کار رود. اگر یک مخزن گیت شامل شاخه‌های refs/remotes/origin/p4 باشد، این شاخه‌ها در طول یک عملیات git p4 sync ابتدا واکشی شده و مورد ارجاع قرار می‌گیرند. از آنجا که وارد کردن مستقیم از p4 به مراتب کندتر از واکشی تغییرات از یک مخزن دوردست گیت است، این قابلیت می‌تواند در یک محیط با چند توسعه‌دهنده مفید باشد. اگر چندین شاخه وجود داشته باشد، اجرای git p4 sync به طور خودکار از الگوریتم «تشخیص شاخه» (BRANCH DETECTION) برای تلاش جهت تفکیک تغییرات جدید به شاخه درست استفاده می‌کند. این رفتار را می‌توان با گزینهٔ --branch لغو کرد تا تنها یک شاخه برای به‌روزرسانی مشخص شود. تغییر پایه (Rebase) یک الگوی کاری رایج، واکشی آخرین تغییرات از انبار p4 و ادغام آن‌ها با تغییرات محلی ثبت‌نشده (uncommitted) است. اغلب اوقات، مخزن p4 مکان نهایی تمام کدها است، از این رو یک گردش کار بازنشانی پایه (rebase) منطقی به نظر می‌رسد. این دستور یک git p4 sync و به دنبال آن یک git rebase را اجرا می‌کند تا کامیت‌های محلی را به بالای تغییرات به‌روزشدهٔ p4 منتقل کند. $ git p4 rebase ارسال (Submit) ارسال تغییرات از یک مخزن گیت به مخزن p4 نیازمند یک فضای کاری کلاینت (client workspace) مجزای p4 است. این مورد باید با استفاده از متغیر محیطی P4CLIENT یا متغیر پیکربندی گیت git-p4.client مشخص شود. کلاینت p4 باید وجود داشته باشد، اما اگر ریشه کلاینت (client root) هنوز وجود نداشته باشد، ایجاد شده و فایل‌ها در آن پر می‌شوند. برای ارسال تمام تغییراتی که در شاخه فعلی گیت هستند اما در شاخهٔ p4/master نیستند، از دستور زیر استفاده کنید: $ git p4 submit برای مشخص کردن شاخه‌ای غیر از شاخه فعلی، از دستور زیر استفاده کنید: $ git p4 submit topicbranch برای مشخص کردن یک کامیت منفرد یا یک محدوده از کامیت‌ها، از دستور زیر استفاده کنید: $ git p4 submit --commit $ git p4 submit --commit مرجع بالادستی (upstream reference) به طور کلی refs/remotes/p4/master است، اما می‌تواند با استفاده از گزینهٔ خط فرمان --origin= بازنویسی شود. تغییرات p4 با هویت کاربری که git p4 submit را اجرا می‌کند ایجاد خواهند شد. گزینهٔ --preserve-user باعث می‌شود مالکیت با توجه به پدیدآورندهٔ (author) کامیت گیت تغییر یابد. این گزینه نیازمند دسترسی‌های مدیر در p4 است که می‌تواند با استفاده از p4 protect اعطا شود. برای قفسه‌بندی (shelve / تعلیق موقت) تغییرات به جای ارسال، از --shelve و --update-shelve استفاده کنید: $ git p4 submit --shelve $ git p4 submit --update-shelve 1234 --update-shelve 2345 خروج از قفسه (Unshelve) عملیات Unshelving یک لیست تغییرات (changelist) تعلیق‌شده در P4 را دریافت کرده و کامیت معادل گیت را در شاخهٔ refs/remotes/p4-unshelved/ تولید می‌کند. کامیت گیت نسبت به نسخه مبدا فعلی (به طور پیش‌فرض HEAD) ایجاد می‌شود. یک کامیت والد بر اساس مبدا ایجاد شده و سپس کامیت unshelve بر اساس آن ساخته می‌شود. نسخه مبدا را می‌توان با گزینهٔ "--origin" تغییر داد. اگر شاخه هدف در refs/remotes/p4-unshelved از قبل وجود داشته باشد، شاخه قدیمی تغییر نام خواهد یافت. $ git p4 sync $ git p4 unshelve 12345 $ git show p4-unshelved/12345 $ git p4 unshelve 12345 گزینه‌ها (OPTIONS) گزینه‌های عمومی (General options) همه دستورها به جز clone این گزینه‌ها را می‌پذیرند. --git-dir تنظیم متغیر محیطی GIT_DIR. راهنمای git(1) را ببینید. -v, --verbose ارائه اطلاعات بیشتر درباره روند پیشرفت. گزینه‌های همگام‌سازی (Sync options) این گزینه‌ها را می‌توان در clone اولیه و همچنین در عملیات‌های بعدی sync استفاده کرد. --branch وارد کردن تغییرات به به جای refs/remotes/p4/master. اگر با refs/ آغاز شود، همان‌طور که هست استفاده می‌شود. در غیر این صورت، اگر با p4/ آغاز نشود، این پیشوند به آن افزوده می‌شود. به طور پیش‌فرض، یک که با refs/ آغاز نشود به عنوان نام یک شاخه ردیابی دوردست (تحت refs/remotes/) در نظر گرفته می‌شود. این رفتار را می‌توان با استفاده از گزینهٔ --import-local تغییر داد. مقدار پیش‌فرض برابر "master" است. این مثال یک شاخه دوردست جدید "p4/proj2" را به یک مخزن موجود گیت وارد می‌کند: $ git init $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2 --detect-branches استفاده از الگوریتم تشخیص شاخه برای یافتن مسیرهای جدید در p4. در بخش "تشخیص شاخه (BRANCH DETECTION)" در زیر مستند شده است. --changesfile وارد کردن دقیقاً همان شماره تغییرات p4 که در file فهرست شده‌اند، در هر خط یکی. به طور معمول، git p4 وضعیت کنونی مخزن p4 را بررسی کرده و تغییراتی را که باید وارد شوند تشخیص می‌دهد. --silent عدم چاپ هرگونه اطلاعات پیشرفت. --detect-labels پرس‌وجو از p4 برای برچسب‌های (labels) مرتبط با مسیرهای انبار، و افزودن آن‌ها به عنوان تگ (tag) در گیت. به دلیل آنکه تنها برچسب‌های مرتبط با changelistهای جدید را وارد می‌کند کاربرد محدودی دارد. منسوخ شده است. --import-labels وارد کردن برچسب‌ها از p4 به گیت. --import-local به طور پیش‌فرض، شاخه‌های p4 در refs/remotes/p4/ ذخیره می‌شوند، جایی که توسط git-branch(1) و سایر دستورات به عنوان شاخه‌های ردیابی دوردست (remote-tracking) در نظر گرفته خواهند شد. این گزینه در عوض شاخه‌های p4 را در refs/heads/p4/ قرار می‌دهد. توجه داشته باشید که عملیات‌های همگام‌سازی آینده نیز باید --import-local را مشخص کنند تا بتوانند شاخه‌های p4 را در refs/heads بیابند. --max-changes وارد کردن حداکثر n تغییر، به جای کل بازه تغییرات موجود در شناسه نسخه داده‌شده. یک کاربرد معمول استفاده از @all به عنوان مشخص‌کننده نسخه، اما سپس استفاده از --max-changes 1000 برای وارد کردن تنها ۱۰۰۰ نسخه آخر به جای کل تاریخچه نسخه‌ها خواهد بود. --changes-block-size اندازه بلوک داخلی برای استفاده هنگام تبدیل یک مشخص‌کننده نسخه مانند @all به فهرستی از شماره‌های تغییر خاص. به جای استفاده از یک فراخوانی منفرد به p4 changes برای یافتن فهرست کامل تغییرات جهت تبدیل، دنباله‌ای از فراخوانی‌ها به p4 changes -m انجام می‌شود که هر کدام یک بلوک از تغییرات را به اندازه داده‌شده درخواست می‌کند. اندازه بلوک پیش‌فرض ۵۰۰ است که معمولاً مناسب است. --keep-path نگاشت نام فایل‌ها از مسیر انبار p4 به گیت به طور پیش‌فرض شامل حذف کل مسیر انبار است. با این گزینه، مسیر کامل انبار p4 در گیت حفظ می‌شود. برای مثال، مسیر //depot/main/foo/bar.c، هنگامی که از //depot/main/ وارد می‌شود، به foo/bar.c تبدیل می‌شود. با --keep-path، مسیر در گیت به جای آن برابر depot/main/foo/bar.c خواهد بود. --use-client-spec استفاده از یک مشخصات کلاینت (client spec) برای یافتن فهرست فایل‌های مورد نظر در p4. بخش "مشخصات کلاینت (CLIENT SPEC)" را در زیر ببینید. -/ مستثنی کردن مسیرهای انبار انتخاب‌شده هنگام شبیه‌سازی یا همگام‌سازی. گزینه‌های شبیه‌سازی (Clone options) این گزینه‌ها را می‌توان در یک clone اولیه به همراه گزینه‌های sync که در بالا توضیح داده شدند استفاده کرد. --destination محل ایجاد مخزن گیت. در صورت ارائه نشدن، آخرین مولفه در مسیر انبار p4 برای ایجاد یک دایرکتوری جدید استفاده می‌شود. --bare انجام یک شبیه‌سازی خام (bare clone). راهنمای git-clone(1) را ببینید. گزینه‌های ارسال (Submit options) این گزینه‌ها می‌توانند برای اصلاح رفتار git p4 submit استفاده شوند. --origin مکان بالادستی که کامیت‌ها از آن برای ارسال به p4 شناسایی می‌شوند. به طور پیش‌فرض، این جدیدترین کامیت p4 قابل دستیابی از HEAD است. -M تشخیص تغییر نام‌ها. راهنمای git-diff(1) را ببینید. تغییر نام‌ها در p4 با استفاده از عملیات‌های صریح move نمایش داده خواهند شد. گزینه متناظری برای تشخیص کپی‌ها وجود ندارد، اما متغیرهایی برای هر دو مورد جابه‌جایی و کپی وجود دارد. --preserve-user بازنویسی پدیدآورنده تغییرات p4 پیش از ارسال به p4. این گزینه نیازمند دسترسی‌های مدیر در p4 است. --export-labels صادر کردن تگ‌ها از گیت به عنوان برچسب‌های p4. تگ‌های یافت‌شده در گیت بر روی دایرکتوری کاری perforce اعمال می‌شوند. -n, --dry-run تنها نشان دادن اینکه چه کامیت‌هایی به p4 ارسال خواهند شد؛ وضعیت را در گیت یا p4 تغییر ندهید. --prepare-p4-only اعمال یک کامیت روی فضای کاری p4، با باز کردن، افزودن و حذف فایل‌ها در p4 همانند یک عملیات عادی submit. اما دستور نهایی "p4 submit" صادر نمی‌شود، بلکه در عوض پیامی درباره نحوه ارسال دستی یا بازگرداندن (revert) چاپ می‌شود. این گزینه همیشه پس از اولین (قدیمی‌ترین) کامیت متوقف می‌شود. تگ‌های گیت به p4 صادر نمی‌شوند. --shelve به جای ارسال، ایجاد مجموعه‌ای از فهرست‌های تغییرات تعلیق‌شده (shelved changelists). پس از ایجاد هر shelve، فایل‌های مربوطه بازگردانی/حذف (reverted/deleted) می‌شوند. اگر چندین کامیت در انتظار داشته باشید، چندین shelve ایجاد خواهد شد. --update-shelve CHANGELIST به‌روزرسانی یک لیست تغییرات تعلیق‌شدهٔ موجود با این کامیت. مستلزم گزینه --shelve است. برای چندین changelist تعلیق‌شده تکرار کنید. --conflict=(ask|skip|quit) هنگام اعمال یک کامیت روی p4 ممکن است تعارض رخ دهد. وقتی این اتفاق می‌افتد، رفتار پیش‌فرض ("ask") این است که سوال شود آیا این کامیت نادیده گرفته شده و ادامه یابد، یا خارج شود. این گزینه می‌تواند برای دور زدن این اعلان استفاده شود و باعث شود کامیت‌های دارای تعارض به طور خودکار نادیده گرفته شوند، یا اینکه تلاش برای اعمال کامیت‌ها بدون درخواست تایید متوقف گردد. --branch پس از ارسال، همگام‌سازی این شاخه نام‌گذاری‌شده به جای شاخه پیش‌فرض p4/master. برای اطلاعات بیشتر بخش "گزینه‌های همگام‌سازی (Sync options)" در بالا را ببینید. --commit (|..) تنها ارسال کامیت یا محدوده کامیت‌های مشخص‌شده، به جای فهرست کامل تغییراتی که در شاخه فعلی گیت وجود دارد. --disable-rebase غیرفعال کردن بازنشانی پایه خودکار پس از اینکه تمام کامیت‌ها با موفقیت ارسال شدند. همچنین می‌تواند با git-p4.disableRebase تنظیم شود. --disable-p4sync غیرفعال کردن همگام‌سازی خودکار p4/master از Perforce پس از ارسال کامیت‌ها. مستلزم گزینه --disable-rebase است. همچنین می‌تواند با git-p4.disableP4Sync تنظیم شود. همگام‌سازی با origin/master در صورت امکان همچنان انجام می‌شود. قلاب‌ها برای ارسال (HOOKS FOR SUBMIT) p4-pre-submit قلاب p4-pre-submit در صورت وجود و قابل اجرا بودن اجرا می‌شود. این قلاب هیچ پارامتری دریافت نمی‌کند و هیچ چیزی از ورودی استاندارد نمی‌گیرد. خروج با وضعیت غیر صفر از این اسکریپت مانع از اجرای git-p4 submit می‌شود. این قلاب را می‌توان با گزینه خط فرمان --no-verify دور زد. یک سناریوی کاربردی اجرای آزمون‌های واحد (unit tests) در این قلاب است. p4-prepare-changelist قلاب p4-prepare-changelist درست پس از آماده‌سازی پیام پیش‌فرض changelist و قبل از شروع ویرایشگر اجرا می‌شود. این قلاب یک پارامتر دریافت می‌کند که نام فایلی است که متن changelist را در بر دارد. خروج با وضعیت غیر صفر از اسکریپت فرآیند را متوقف خواهد کرد. هدف از این قلاب، ویرایش درجا (in place) فایل پیام است و با گزینه --no-verify غیرفعال نمی‌شود. این قلاب حتی در صورت تنظیم --prepare-p4-only نیز فراخوانی می‌شود. p4-changelist قلاب p4-changelist پس از اینکه پیام changelist توسط کاربر ویرایش شد اجرا می‌شود. این قلاب می‌تواند با گزینه --no-verify دور زده شود. این قلاب یک پارامتر واحد دریافت می‌کند که نام فایلی است که متن پیشنهادی changelist را نگه‌داری می‌کند. خروج با وضعیت غیر صفر باعث لغو دستور می‌شود. این قلاب مجاز به ویرایش فایل changelist است و می‌تواند برای یکدست‌سازی متن به قالبی استاندارد در پروژه استفاده شود. همچنین می‌تواند پس از بازبینی فایل پیام، برای رد کردن Submit استفاده شود. p4-post-changelist قلاب p4-post-changelist پس از اینکه ارسال با موفقیت در P4 انجام شد فراخوانی می‌شود. هیچ پارامتری دریافت نمی‌کند و اساساً برای اطلاع‌رسانی در نظر گرفته شده است و نمی‌تواند بر نتیجه عملیات git p4 submit تأثیر بگذارد. گزینه‌های تغییر پایه (Rebase options) این گزینه‌ها می‌توانند برای تغییر رفتار git p4 rebase استفاده شوند. --import-labels وارد کردن برچسب‌های p4. گزینه‌های خروج از قفسه (Unshelve options) --origin تنظیم refspec گیت که changelist تعلیق‌شده در P4 در برابر آن مقایسه می‌شود. پیش‌فرض p4/master است. نحو مسیر انبار (DEPOT PATH SYNTAX) آرگومان مسیر انبار p4 به git p4 sync و git p4 clone می‌تواند یک یا چند مسیر انبار p4 جداشده با فاصله باشد، همراه با یک شناسه نسخه اختیاری p4 در انتها: "//depot/my/project" وارد کردن یک کامیت با تمام فایل‌ها در تغییر #head تحت آن درخت. "//depot/my/project@all" وارد کردن یک کامیت به ازای هر تغییر در تاریخچه آن مسیر انبار. "//depot/my/project@1,6" تنها وارد کردن تغییرات ۱ تا ۶. "//depot/proj1@all //depot/proj2@all" وارد کردن تمام تغییرات از هر دو مسیر انبار نام‌برده‌شده در یک مخزن واحد. تنها فایل‌های زیر این دایرکتوری‌ها گنجانده می‌شوند. در گیت برای هر کدام از "proj1" و "proj2" یک زیردایرکتوری ایجاد نمی‌شود. هنگام مشخص کردن بیش از یک مسیر انبار، باید از گزینهٔ --destination استفاده کنید. مشخص‌کننده نسخه باید روی هر مسیر انبار به طور یکسان تعیین شود. اگر در مسیرهای انبار فایل‌هایی با نام یکسان وجود داشته باشد، مسیری که جدیدترین نسخه به‌روزشدهٔ فایل را دارد در گیت ظاهر می‌شود. برای نحو کامل مشخص‌کننده‌های نسخه در p4، به p4 help revisions مراجعه کنید. مشخصات کلاینت (CLIENT SPEC) مشخصات کلاینت p4 با دستور p4 client نگه‌داری می‌شود و از جمله فیلدهای دیگر، شامل یک View است که مشخص می‌کند چگونه انبار به مخزن کلاینت نگاشت می‌شود. دستورهای clone و sync می‌توانند هنگام دریافت گزینهٔ --use-client-spec یا زمانی که متغیر useClientSpec برابر true است، مشخصات کلاینت را مد نظر قرار دهند. پس از git p4 clone، متغیر useClientSpec به طور خودکار در فایل پیکربندی مخزن تنظیم می‌شود. این کار اجازه می‌دهد دستورهای آیندهٔ git p4 submit به درستی کار کنند؛ دستور submit تنها به این متغیر نگاه می‌کند و گزینه خط فرمانی برای آن ندارد. نحو کامل برای یک view در p4 در p4 help views مستند شده است. git p4 تنها زیرمجموعه‌ای از نحو view را می‌شناسد. این ابزار نگاشت‌های چندخطی، همپوشانی‌ها (overlays) با +، موارد استثنا با - و علامت نقل‌قول دوگانه در اطراف فاصله‌ها را متوجه می‌شود. از میان نویسه‌های عمومی (wildcards) ممکن، git p4 تنها ... را مدیریت می‌کند، و آن هم فقط زمانی که در انتهای مسیر باشد. اگر git p4 با نویسه عمومی پشتیبانی‌نشده‌ای مواجه شود، خطا گزارش می‌دهد. اشکالاتی در پیاده‌سازی نگاشت‌های دارای همپوشانی وجود دارد. اگر چندین مسیر انبار از طریق overlays به یک مکان یکسان در مخزن نگاشت شوند، git p4 ممکن است مسیر اشتباه را انتخاب کند. حل این مشکل بدون اختصاص یک مشخصات کلاینت صرفاً برای git p4 دشوار است. نام کلاینت را می‌توان به روش‌های مختلفی به git p4 ارائه کرد. متغیر git-p4.client در صورت وجود اولویت دارد. در غیر این صورت، سازوکارهای عادی p4 برای تعیین کلاینت استفاده می‌شوند: متغیر محیطی P4CLIENT، یک فایل ارجاع داده‌شده توسط P4CONFIG، یا نام میزبان محلی (local host name). تشخیص شاخه (BRANCH DETECTION) نرم‌افزار P4 مفهومی یکسان با شاخه در گیت ندارد. در عوض، p4 محتوای خود را به صورت یک درخت دایرکتوری سازماندهی می‌کند که بر اساس توافق، شاخه‌های منطقی مختلف در مکان‌های متفاوتی در درخت قرار دارند. دستور p4 branch برای نگه‌داری نگاشت‌های میان بخش‌های مختلف در درخت و نشان دادن محتوای مرتبط استفاده می‌شود. git p4 می‌تواند از این نگاشت‌ها برای تعیین روابط شاخه‌ها استفاده کند. اگر مخزنی دارید که در آن تمام شاخه‌های مورد نظر به عنوان زیردایرکتوری‌های یک مسیر انبار واحد وجود دارند، می‌توانید هنگام شبیه‌سازی یا همگام‌سازی از --detect-branches استفاده کنید تا git p4 به طور خودکار زیردایرکتوری‌ها را در p4 پیدا کرده و آن‌ها را به عنوان شاخه‌هایی در گیت ایجاد کند. برای مثال، اگر ساختار مخزن P4 به صورت زیر باشد: //depot/main/... //depot/branch1/... و دستور "p4 branch -o branch1" یک خط View را نشان دهد که شبیه زیر است: //depot/main/... //depot/branch1/... سپس این دستور git p4 clone: git p4 clone --detect-branches //depot@all یک شاخهٔ جداگانه در refs/remotes/p4/ برای //depot/main به نام master، و یک شاخه برای //depot/branch1 به نام depot/branch1 تولید می‌کند. با این حال، برای اینکه بتوان از آن‌ها مانند شاخه‌ها استفاده کرد، ایجاد شاخه‌ها در p4 الزامی نیست. از آنجا که استنباط روابط شاخه‌ها به طور خودکار دشوار است، می‌توان از تنظیم پیکربندی گیت git-p4.branchList برای شناسایی صریح روابط شاخه‌ها استفاده کرد. این تنظیم فهرستی از جفت‌های "source:destination" است، مانند یک مشخصات ساده شاخه در p4، که در آن "source" و "destination" عناصر مسیر در مخزن p4 هستند. مثال بالا متکی به حضور شاخه p4 بود. بدون شاخه‌های p4، همین نتیجه با دستورهای زیر حاصل خواهد شد: git init depot cd depot git config git-p4.branchList main:branch1 git p4 clone --detect-branches //depot@all . کارایی (PERFORMANCE) سازوکار fast-import مورد استفاده توسط git p4 برای هر بار فراخوانی git p4 sync یک pack file ایجاد می‌کند. معمولاً فشرده‌سازی بازیافت حافظه گیت (git-gc(1)) به طور خودکار این فایل‌ها را به بسته‌های کمتری فشرده می‌کند، اما اجرای صریح دستور git repack -adf ممکن است کارایی را بهبود بخشد. متغیرهای پیکربندی (CONFIGURATION VARIABLES) تنظیمات پیکربندی زیر می‌توانند برای تغییر رفتار git p4 استفاده شوند. همه آن‌ها در بخش git-p4 قرار دارند. متغیرهای عمومی (General variables) git-p4.user کاربر مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با -u . متغیر محیطی P4USER می‌تواند به جای آن استفاده شود. git-p4.password گذرواژه مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با -P . متغیر محیطی P4PASS می‌تواند به جای آن استفاده شود. git-p4.port درگاه (پورت) مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با -p . متغیر محیطی P4PORT می‌تواند به جای آن استفاده شود. git-p4.host میزبان مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با -h . متغیر محیطی P4HOST می‌تواند به جای آن استفاده شود. git-p4.client کلاینت مشخص‌شده به عنوان گزینه‌ای برای همه دستورهای p4، با -c ، شامل مشخصات کلاینت. git-p4.retries تعداد دفعات تلاش مجدد برای یک دستور p4 (به ویژه p4 sync) را در صورت اتمام مهلت شبکه مشخص می‌کند. مقدار پیش‌فرض ۳ است. برای غیرفعال کردن تلاش‌های مجدد یا در صورتی که نسخه p4 شما از تلاش مجدد پشتیبانی نمی‌کند (قبل از 2012.2)، مقدار را روی 0 تنظیم کنید. متغیرهای شبیه‌سازی و همگام‌سازی (Clone and sync variables) git-p4.syncFromOrigin از آنجا که وارد کردن کامیت‌ها از سایر مخازن گیت بسیار سریع‌تر از وارد کردن آن‌ها از p4 است، سازوکاری برای یافتن تغییرات p4 ابتدا در شاخه‌های دوردست گیت وجود دارد. اگر شاخه‌هایی تحت refs/remote/origin/p4 وجود داشته باشند، هنگام همگام‌سازی از p4 واکشی شده و استفاده خواهند شد. این متغیر می‌تواند برای غیرفعال کردن این رفتار بر روی false تنظیم شود. git-p4.branchUser یک مرحله در تشخیص شاخه شامل بررسی شاخه‌های p4 برای یافتن شاخه‌های جدید جهت وارد کردن است. به طور پیش‌فرض، تمام شاخه‌ها بررسی می‌شوند. این گزینه جستجو را تنها به مواردی محدود می‌کند که متعلق به کاربری هستند که نامش در متغیر ذکر شده است. git-p4.branchList فهرست شاخه‌هایی که هنگام فعال بودن تشخیص شاخه باید وارد شوند. هر ورودی باید یک جفت از نام‌های شاخه باشد که با دونقطه (:) از هم جدا شده‌اند. این مثال اعلام می‌کند که هر دو شاخه branchA و branchB از main ایجاد شده‌اند: git config git-p4.branchList main:branchA git config --add git-p4.branchList main:branchB git-p4.ignoredP4Labels فهرست برچسب‌های p4 برای نادیده گرفتن. این فهرست با کشف برچسب‌های غیرقابل وارد کردن به طور خودکار ساخته می‌شود. git-p4.importLabels وارد کردن برچسب‌های p4 به گیت، مطابق با --import-labels. git-p4.labelImportRegexp تنها برچسب‌های p4 که با این عبارت باقاعده مطابقت دارند وارد خواهند شد. مقدار پیش‌فرض برابر است با [a-zA-Z0-9_\-.]+$. git-p4.useClientSpec مشخص می‌کند که مشخصات کلاینت p4 باید برای شناسایی مسیرهای انبار مورد نظر p4 استفاده شود. این معادل تعیین گزینهٔ --use-client-spec است. بخش "مشخصات کلاینت (CLIENT SPEC)" را در بالا ببینید. این متغیر یک مقدار بولی است، نه نام یک کلاینت p4. git-p4.pathEncoding سیستم Perforce کدگذاری یک مسیر را همان‌طور که توسط سیستم‌عامل مبدا تعیین شده نگه‌داری می‌کند. گیت انتظار دارد مسیرها با کدگذاری UTF-8 باشند. از این پیکربندی برای اعلام به git-p4 استفاده کنید که Perforce از چه کدگذاری‌ای برای مسیرها استفاده کرده است. این کدگذاری برای تبدیل مسیرها به UTF-8 استفاده می‌شود. به عنوان مثال، Perforce در ویندوز اغلب از "cp1252" برای کدگذاری نام مسیرها استفاده می‌کند. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره و ماندگار می‌شود. git-p4.metadataDecodingStrategy سیستم Perforce کدگذاری توضیحات changelist و نام کامل کاربران را همان‌طور که توسط کلاینت در یک سیستم‌عامل ذخیره شده حفظ می‌کند. کلاینت p4v از کدگذاری محلی سیستم‌عامل استفاده می‌کند، بنابراین کاربران مختلف ممکن است در نهایت توضیحات changelist یا نام‌های کامل متفاوتی را با کدگذاری‌های متفاوتی در همان انبار ذخیره کنند. گیت کدگذاری‌های ناهماهنگ/نادرست را در پیام‌های کامیت و نام نویسندگان تحمل می‌کند، اما انتظار دارد آن‌ها در قالب utf-8 مشخص شوند. ابزار git-p4 می‌تواند از سه راهبرد مختلف رمزگشایی در مواجهه با عدم قطعیت کدگذاری در Perforce استفاده کند: passthrough صرفاً بایت‌های اصلی را از Perforce به گیت منتقل می‌کند و در صورتی که داده‌های Perforce با چیزی غیر از utf-8 کدگذاری شده باشند، داده‌هایی قابل استفاده اما با کدگذاری نادرست ایجاد می‌کند. strict انتظار دارد داده‌های Perforce با کدگذاری utf-8 باشند، و در غیر این صورت عملیات وارد کردن با شکست مواجه می‌شود. fallback تلاش می‌کند داده‌ها را به عنوان utf-8 تفسیر کند، و در غیر این صورت به استفاده از یک کدگذاری ثانویه بازمی‌گردد - به طور پیش‌فرض کدگذاری رایج ویندوز cp-1252 - که در صورت عدم موفقیت در رمزگشایی با کدگذاری پشتیبان، بایت‌های دامنه بالایی اسکیپ می‌شوند. در پایتون ۲ راهبرد پیش‌فرض به دلایل تاریخی passthrough است، و در پایتون ۳ پیش‌فرض fallback است. هنگامی که strict انتخاب شود و رمزگشایی با شکست مواجه گردد، پیام خطا تغییر این پارامتر پیکربندی را به عنوان راهکار پیشنهاد می‌دهد. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره می‌شود. git-p4.metadataFallbackEncoding کدگذاری پشتیبان (fallback) مورد استفاده هنگام رمزگشایی نام نویسندگان و توضیحات changelist در Perforce با استفاده از راهبرد fallback را مشخص می‌کند (نگاه کنید به git-p4.metadataDecodingStrategy). کدگذاری پشتیبان تنها زمانی استفاده خواهد شد که رمزگشایی به عنوان utf-8 با شکست مواجه شود. این گزینه به طور پیش‌فرض روی cp1252، یک کدگذاری رایج ویندوز، تنظیم است. اگر این گزینه به درخواست p4 clone ارسال شود، در مخزن گیت جدید حاصل ذخیره می‌شود. git-p4.largeFileSystem سیستم مورد استفاده برای فایل‌های بزرگ (باینری) را مشخص می‌کند. لطفاً توجه داشته باشید که سیستم‌های فایل بزرگ از دستور git p4 submit پشتیبانی نمی‌کنند. در حال حاضر تنها Git LFS پیاده‌سازی شده است (برای اطلاعات بیشتر به https://git-lfs.github.com مراجعه کنید). برای استفاده از این گزینه، افزونه خط فرمان Git LFS را دانلود و نصب کرده و آن را به این صورت پیکربندی نمایید: git config git-p4.largeFileSystem GitLFS git-p4.largeFileExtensions تمام فایل‌هایی که با یک پسوند فایل در این فهرست مطابقت دارند توسط سیستم فایل‌های بزرگ پردازش خواهند شد. پیشوند . را به پسوندها اضافه نکنید. git-p4.largeFileThreshold تمام فایل‌هایی که اندازه غیرفشرده آن‌ها از آستانه فراتر رود توسط سیستم فایل‌های بزرگ پردازش خواهند شد. به طور پیش‌فرض این آستانه بر حسب بایت تعریف می‌شود. پسوند k یا m یا g را برای تغییر واحد اضافه کنید. git-p4.largeFileCompressedThreshold تمام فایل‌هایی که اندازه فشرده آن‌ها از آستانه فراتر رود توسط سیستم فایل‌های بزرگ پردازش خواهند شد. این گزینه ممکن است روند شبیه‌سازی/همگام‌سازی شما را کند کند. به طور پیش‌فرض آستانه بر حسب بایت تعریف می‌شود. پسوند k یا m یا g را برای تغییر واحد اضافه کنید. git-p4.largeFilePush متغیر بولی که تعیین می‌کند آیا فایل‌های بزرگ به طور خودکار به سرور ارسال (push) شوند یا خیر. git-p4.keepEmptyCommits اگر این گزینه بولی روی true تنظیم شود، یک changelist که تنها شامل فایل‌های مستثنی‌شده است به عنوان یک کامیت خالی وارد خواهد شد. git-p4.mapUser نگاشت یک کاربر P4 به یک نام و نشانی ایمیل در گیت. از یک رشته با قالب زیر برای ایجاد نگاشت استفاده کنید: git config --add git-p4.mapUser "p4user = First Last " یک نگاشت هرگونه اطلاعات کاربر از P4 را لغو خواهد کرد. نگاشت‌ها را می‌توان برای چندین کاربر P4 تعریف کرد. متغیرهای ارسال (Submit variables) git-p4.detectRenames تشخیص تغییر نام‌ها. راهنمای git-diff(1) را ببینید. این می‌تواند true یا false یا یک امتیاز مورد انتظار توسط git diff -M باشد. git-p4.detectCopies تشخیص کپی‌ها. راهنمای git-diff(1) را ببینید. این می‌تواند true یا false یا یک امتیاز مورد انتظار توسط git diff -C باشد. git-p4.detectCopiesHarder تشخیص دقیق‌تر کپی‌ها. راهنمای git-diff(1) را ببینید. یک مقدار بولی است. git-p4.preserveUser هنگام ارسال، تغییرات را بازنویسی کنید تا نویسنده گیت را منعکس کند، صرف‌نظر از اینکه چه کسی git p4 submit را اجرا می‌کند. git-p4.allowMissingP4Users هنگامی که preserveUser برابر true باشد، git p4 به طور معمول اگر نتواند نویسنده‌ای را در نقشه کاربران p4 پیدا کند متوقف می‌شود. این تنظیم در هر صورت تغییرات را ارسال می‌کند. git-p4.skipSubmitEdit فرآیند submit ویرایشگر را قبل از ارسال هر تغییر p4 فراخوانی می‌کند. با این حال، اگر این تنظیم برابر true باشد، مرحله ویرایش نادیده گرفته می‌شود. git-p4.skipSubmitEditCheck پس از ویرایش پیام تغییر p4، git p4 با بررسی زمان تغییر فایل اطمینان حاصل می‌کند که توضیحات واقعاً تغییر کرده است. این گزینه آن آزمایش را غیرفعال می‌کند. git-p4.allowSubmit به طور پیش‌فرض، هر شاخه‌ای می‌تواند به عنوان منبع برای یک عملیات git p4 submit استفاده شود. این متغیر پیکربندی، در صورت تنظیم، تنها به شاخه‌های نام‌برده اجازه می‌دهد به عنوان منابع ارسال استفاده شوند. نام شاخه‌ها باید نام‌های کوتاه باشند (بدون "refs/heads/") و باید با کاما (",") و بدون فاصله از هم جدا شوند. git-p4.skipUserNameCheck اگر کاربری که git p4 submit را اجرا می‌کند در نقشه کاربران p4 وجود نداشته باشد، git p4 خارج می‌شود. این گزینه می‌تواند برای اجبار به ارسال در هر صورت استفاده شود. git-p4.attemptRCSCleanup در صورت فعال بودن، git p4 submit تلاش خواهد کرد کلیدواژه‌های RCS مانند ($Header$ و غیره) را پاکسازی کند. در غیر این صورت این موارد باعث تعارض ادغام شده و مانع از انجام ارسال می‌شوند. این گزینه در حال حاضر باید آزمایشی در نظر گرفته شود. git-p4.exportLabels صادر کردن تگ‌های گیت به برچسب‌های p4، مطابق با --export-labels. git-p4.labelExportRegexp تنها برچسب‌های p4 که با این عبارت باقاعده مطابقت دارند صادر خواهند شد. مقدار پیش‌فرض برابر است با [a-zA-Z0-9_\-.]+$. git-p4.conflict مشخص کردن رفتار submit هنگام یافتن تعارض با p4، مطابق با --conflict. رفتار پیش‌فرض برابر است با ask. git-p4.disableRebase پس از یک ارسال، شاخه را در برابر p4/master بازنشانی پایه نکنید. git-p4.disableP4Sync پس از ارسال، p4/master را با Perforce همگام‌سازی نکنید. مستلزم git-p4.disableRebase است. همگام‌سازی با origin/master در صورت امکان همچنان انجام می‌شود. جزئیات پیاده‌سازی (IMPLEMENTATION DETAILS) • مجموعه‌تغییرات (changesets) از p4 با استفاده از Git fast-import وارد می‌شوند. • شبیه‌سازی یا همگام‌سازی نیازی به کلاینت p4 ندارد؛ محتویات فایل با استفاده از p4 print جمع‌آوری می‌شوند. • ارسال (Submit) نیازمند کلاینت p4 است، که در همان مکان مخزن گیت قرار ندارد. وصله‌ها (patches) یکی‌یکی بر روی این کلاینت p4 اعمال شده و از آنجا ارسال می‌شوند. • هر کامیت واردشده توسط git p4 یک خط در انتهای پیام لاگ دارد که مکان انبار p4 و شماره تغییر را نشان می‌دهد. این خط توسط عملیات‌های بعدی git p4 sync استفاده می‌شود تا مشخص شود کدام تغییرات p4 جدید هستند. همچنین ببینید (SEE ALSO) git(1), git-branch(1), git-clone(1), git-diff(1) گیت (GIT) بخشی از مجموعه git(1) Git 2.55.0 2026-06-29 GIT-P4(1)