آموزش گیت – قسمت دهم

نویسنده : سید ایوب کوکبی ۲۷ اردیبهشت ۱۳۹۸
آموزش گیت - قسمت دهم

اکنون که با چگونه اشتراک اطلاعات در یک مخزن مرکزی آشنا شده‌اید وقتش رسیده تا با معایب گردش کار متمرکز نیز آشنا شوید. شاید وجود چنین مخزنی در گیت منطقی بدانید ولی اینکه هر کسی بتواند به مخزن دسترسی داشته باشد و هر زمان که بخواهد تغییراتش را ارسال کند ممکن است مشکلاتی به وجود آورد. در پروژه‌های بزرگ که بعضاً هزاران برنامه‌نویس در توسعۀ آن مشارکت دارند، چنین مکانیزمی نه معقول بوده و نه شدنی است.

همانطور که گفتیم گردش کار متمرکز در تیم‌های کوچک ممکن است به خوبی جواب بدهد ولی تصور کنید روی یک پروژۀ متن باز کار می‌کنید و فردی ناآشنا باگی در برنامه پیدا کرده و پس از رفع مشکل می‌خواهد در پروژه اعمال کند. احتمالاً شما هم مثل ما از پوش مستقیم توسط چنین فردی هراسان هستید.

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

ولی چه می‌شد اگر به آن فرد می‌گفتید تغییرات را در مخزن عمومی خودش پوش کند، سپس خودتان بعد از بررسیِ باگ فیکس، تغییرات او را در مخزن اصلی وارد می‌کردید تا اگر احیاناً مشکلی در کدها وجود داشت به مخزن اصلی منتقل نشود. این دقیقاً گردش کار integrator است که تصویر آن را می‌بینید.

جان در مخزن خصوصی‌اش (private repo واقع در سیستم) تغییراتی در پروژه اعمال می‌کند، سپس آن تغییرات را به مخزن عمومی‌اش (public repo روی سرور) پوش می‌کند. صاحب اصلی پروژه تغییرات جان را از مخزن عمومی‌اش به مخزن خصوصی خود منتقل می‌کند و بعد از بررسی و اطمینان از سلامت کدها، آن تغییرات را به مخزن عمومی‌اش (اصطلاحاً Official Repository یا مخزن رسمی) منتقل می‌کند. اکنون سایر توسعه‌دهندگان با دریافت مخزن رسمی تغییرات جان را هم خواهند دید.

گردش کار integrator در گیت
گردش کار integrator در گیت

در این درس اکانتی عمومی در سایت بیت باکت می‌سازیم (با ..ی پی ان باز کنید؛ در ایران فیلتر است) و به عنوان یک فرد ناشناس به نام جان در پروژه مشارکت می‌کنیم. بیت باکت، هاستی توزیع شده (DVCS) مبتنی بر گیت است که به راحتی اجازۀ ساخت مخزن و مشارکت در کارهای تیمی را برای شما فراهم می‌کند. گیت‌هاب، گیت‌لب و سایر سرویس‌های مشابه نیز وجود دارند که هر یک مزایا و معایب خاص خود را دارند.

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

ساخت اکانت در بیت باکت

ابتدا به سایت بیت باکت مراجعه کنید و یک حساب کاربری رایگان بسازید.

لوگوی بیت باکت

شما می‌توانید هر یوزرنیم برای اکانت خود انتخاب کنید ولی ایمیلتان باید همان چیزی باشد که در درس‌های قبلی با دستور git config تنظیم کردیم. در صورت لزوم می‌توانید مجددا با دستور git config –global user.email you@example.com ایمیل‌تان را تغییر دهید؛ سپس با این ایمیل در بیت باکت ثبت‌نام کنید.

ساخت یک مخزن عمومی (شما)

برای ساخت اولین مخزن تحت شبکه کافی است به حساب خود در بیت باکت لاگین کنید و از قسمت Repositories دکمۀ آبی رنگ Create Repository را انتخاب نمایید. برای نام مخزن my-git-repo را وارد کنید و توضیحی اختیاری هم در بخش Description بنویسید. از آنجایی که این پروژه صرفاً یک مثال است، تیک گزینۀ This is a private repository را بردارید.

وقتی این گزینه را تیک می‌زنید، مخزن شما روی سرور ساخته می‌شود ولی کسی از وجود آن باخبر نخواهد شد و فقط خودتان می‌توانید کدهای آن را دریافت کنید. (ساخت مخازن خصوصی در بیت باکت از ابتدا رایگان بود که اخیراً گیت‌هاب هم رایگان کرده است). در فیلد Language گزینۀ HTML/CSS را انتخاب کنید و نهایتاً دکمۀ Create Repository را کلیک کنید. ممکن است در نسخه‌های جدید بیت‌باکت، اینترفیس آن تغییر کرده باشد ولی در کل با همین آیتم‌ها سروکار خواهید داشت.

فرم ساخت مخزن جدید در بیت باکت

در حال حاضر تنها کاری که انجام داده‌ایم ساخت یک مخزن خالی در بیت باکت بوده است (git init –bare). اکنون می‌توانیم تغییرات را در مخزن پوش یا از آن بگیریم همانطور که در درس قبلی همین کار را با central-repo.git انجام دادیم.

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

بخوانید  خصوصیات افرادی که مناسب کار تیمی نیستند

پوش کردن به مخزن عمومی (شما)

قبل از پر کردن مخزن با پروژۀ my-git-repo ابتدا باید ریموتی به مخزن جدیدمان بسازیم. مطمئن باشید که بخش username را با نام کاربری خود در بیت باکت جایگزین کرده‌اید. حالا دستورات زیر را وارد کنید:

cd /path/to/my-git-repo
git remote rm origin
git remote add origin https://<username>@bitbucket.org/<username>/my-git-repo.git

در دستورات بالا کاربرد remote را به خوبی می‌بینید. به جای آدرس طولانی فقط از کلمۀ origin برای دسترسی به مخزنمان در بیت باکت استفاده می‌کنیم. فکرش را بکنید هر بار مسیر کامل مخزن را وارد می‌کردید؛ چقدر خسته‌کننده بود. برای پر کردن مخزن با کدهای پروژه می‌توانید از همان روش گردش کار متمرکز استفاده کنید؛ یعنی ارسال شاخه با دستور push. در هنگام اجرای این دستور، یوزر و پسورد اکانت بیت‌باکت شما درخواست می‌شود. معمولاً فیلد پسورد هنگام تایپ چیزی نمایش نمی‌دهد که باید اندکی بیشتر دقت کنید. توجه کنید اینجا هم باید با و… پی ان به سایت متصل شوید چون برای کشور ایران مسدود است.

git push origin master

اکنون اگر به اکانت خود در بیت باکت مراجعه کنید. تمام فایل‌ها و فولدرهای my-git-repo را در آن خواهید دید. استفاده از چنین سایت‌هایی برای بکاپ‌گیری از کدها هم بسیار ضروری است. اگر مخزن شما به هر دلیلی از سیستم‌تان حذف شود به راحتی می‌توانید از بیت باکت رونوشت آن را مجددا Clone کنید. سایر توسعه‌دهندگان نیز می‌توانند این کار را انجام دهند.

بررسی مخزن عمومی (شما)

تب Source در بیت باکت، تمام فایل‌های موجود در پروژه و تب Commits تاریخچۀ کامیت‌ها را نمایش می‌دهد. توجه کنید که اینجا ساختار شاخه‌ها به صورت ویژوال ترسیم شده است. پیام کامیت‌ها، تاریخ ارسال و ارسال کننده به همراه تصویر نمایش داده می‌شود:

تاریخچۀ ما در تب Commit بیت باکت

این مخزن اکنون به عنوان کپی اصلی پروژۀ ما در سرور قرار گرفته است. ما به سایر توسعه‌دهنده‌ها آدرس مخزن را می‌دهیم تا به آن متصل شده و محتویاتش را دریافت کنند. از این پس می‌توانیم تغییرات اعمالی خودمان را به مخزن عمومی‌مان (my-git-repo روی سرور) پوش کنیم. اینکه هر توسعه‌دهنده‌ای علاوه بر مخزن خصوصی (روی سیستم)، یک مخزن عمومی (روی سرور) هم داشته باشد، روند مشارکت اشخاص ثالث را آسان‌تر می‌کند؛ حتی افراد ناشناس و غیرقابل اعتماد.

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

کلون کردن مخزن (جان)

حالا فرض کنید جان هستید و به عنوان یک توسعه‌دهندۀ ثالث می‌خواهید در پروژه مشارکت کنید. جان متوجه شده که سایت ما فاقد صفحۀ صورتی است؛ پس تصمیم می‌گیرد این صفحه را به سایت اضافه کند. ما از همکاری جان استقبال می‌کنیم ولی دوست نداریم دسترسی مستقیم به او بدهیم تا تغییرات خود را مستقیماً به مخزن پروژه روی سرور پوش کند. با این کار ممکن است جان (ناخواسته) تمام زحمات ما را از بین ببرد.

خوشبختانه او راه‌حل این مشکل را می‌داند. با دستورات زیر نسخه‌ای از پروژه را در مخزن جدیدش به نام johns-repo کلون می‌کند:

cd /path/to/my-git-repo
cd ..
git clone http://bitbucket.org/<username>/my-git-repo.git johns-repo
cd johns-repo

اکنون شما (که نقش جان را بازی می‌کنید) باید پوشۀ دیگری کنار my-git-repo به نام johns-repo داشته باشید. این مخزن خصوصیِ جان است که کاملاً در یک محیط ایزوله و ایمن می‌تواند صفحۀ صورتی را توسعه دهد. اجازه دهید ابتدا نام و ایمیل او را کانفیگ کنیم:

git config user.name "John"
git config user.email john.example@rypress.com

افزودن صفحۀ صورتی (جان)

جان توسعۀ پروژه را در شاخۀ جدیدی تحت عنوان pick-page انجام می‌دهد:

git checkout -b pink-page

ساخت شاخۀ جدید، علاوه بر اینکه یک best practice محسوب می‌شود به توسعه‌دهنده اجازه می‌دهد تا بفهمد چه کامیت‌هایی را باید ارسال کند. ما نیز به راحتی می‌توانیم شاخه‌ای که توسعه‌دهنده قابلیت جدیدی به پروژه اضافه کرده را شناسایی و با کمترین تلاش با مخزن اصلی ترکیب کنیم.

فایل pink.html را با محتویات زیر ایجاد کنید:

<!DOCTYPE html>
<html lang="en">
<head>
  <title>The Pink Page</title>
<link rel="stylesheet" href="style.css" />
  <meta charset="utf-8" />
</head>
<body>
  <h1 style="color: #F0F">The Pink Page</h1>
  <p>Pink is <span style="color: #F0F">girly,
  flirty and fun</span>!</p>

  <p><a href="index.html">Return to home page</a></p>
</body>
</html>

سپس لینک صفحه را به index.html اضافه کنید:

<li style="color: #F0F">
  <a href="pink.html">The Pink Page</a>
</li>

و نهایتاً استیج و کامیت کنید:

git add pink.html index.html
git status
git commit -m "Add pink page"

انتشار صفحۀ pink (جان)

اکنون جان صفحۀ صورتی را اضافه کرده و می‌خواهد تغییرات را به مخزن عمومی ارسال کند. به خاطر دارید که ما نمی‌خواهیم تغییرات جان در مخزن ریموت ما که آدرسش در origin او ذخیره شده، پوش شود. در حقیقت او به دلایلی نمی‌تواند در مخزن عمومی ما (مخزن رسمی پروژه) عمل پوش را انجام دهد.

بخوانید  آموزش گیت - قسمت سوم

به همین خاطر مثل ما مخزنی در بیت باکت می‌سازد تا تغییرات را به مخزن عمومی خودش ارسال کند و ما از آنجا تغییرات او را pull و در صورت صحت با مخزن اصلی‌مان پوش کنیم. در دنیای واقعی، جان اکانت خودش را در بیت باکت دارد ولی برای تسریع در روند آموزش، مخزن او را با اکانت خودمان می‌سازیم. به هوم پیج بروید و مانند قبل به روی Repositories > Create repository کلیک کنید تا مخزن عمومی جان را بسازید. در فیلد نام بنویسید johns-repo.

فرم ساخت مخزن جدید جان

به مخزن خصوصی جان روی سیستمش برگردید و دستور زیر را برای معرفی ریموت جدید وارد کنید. اگر دقت کرده باشید ریموت مخزن خودمان را با نام origin قرار دادیم ولی برای جان از johns-public استفاده کردیم. به جای origin هم می‌توانستیم هر اسم دیگری انتخاب کنیم ولی معمولاً در گیت مخزن عمومی شخصی که به عنوان مخزن رسمی شناخته می‌شود را origin نام‌گذاری می‌کنند تا از سایر مخازن تفکیک شود. این موضوع صرفاً یک قرارداد است.

git remote add john-public https://<username>@bitbucket.org/<username>/johns-repo.git

اکنون جان می‌تواند تغیرات اعمالی را به مخزن عمومی خودش در بیت باکت پوش کند تا در دسترس ما قرار گیرد. دقت کنید آدرس ریموت یک آدرس HTTPS است. بنابراین جان باید یوزر و پسوردی که با آن در سایت ثبت‌نام کرده را در هنگام پوش وارد کند (که در مثال ما همان یوزر و پس خودمان است):

git push john-public pink-page

حالا تنها کاری که جان باید انجام دهد ارسال نام شاخه و فرستادن لینک مخزنش به ماست که این آدرس است تا ما (صلاحب مخزن رسمی) بتوانیم تغییرات او را pull و در صورت صلاحدید به مخزن اصلی کد پوش کنیم.

http://bitbucket.org/<username>/johns-repo.git

اگر دقت کرده باشید مسیری که جان برای پوش کردن تغییرات در مخزن عمومی‌اش به کار برده با مسیر بالا که برای فچ کردن از مخزنش به ما داده متفاوت است. تنها فرقشان پروتکل مورد استفاده است. اولی //:https و دومی //:http. دسترسی به مخزن با پروتکل https (یا ssh) اجازه می‌دهد تا هر دو عمل فچ و پوش را بتوانیم انجام دهیم اما همانطور که می‌دانید نیازمند یوزر و پس است. این موضوع از بازنویسی کامیت‌ها توسط افراد ناشناس جلوگیری می‌کند.

از سوی دیگر پروتکل http نیازی به یوزنیم و پسورد ندارد ولی پوش کردن در آن مجاز نیست. این پروتکل اجازه می‌دهد هر کسی عمل فچ را انجام دهد. در مدل integrator workflow سایر توسعه‌دهندگان با پروتکل http به مخزن دسترسی دارند و شما با https تغییرات را به مخزن خودتان (مخزن عمومی خودتان که ممکن است مخزن رسمی هم باشد) پوش می‌کنید. به همین دلیل جان اجازۀ پوش در ریموت origin را نداشت چون آدرس https بود. البته در صورت کار روی یک مخزن خصوصی (با زدن تیک This is a private repository)، حتی امکان دسترسی http هم وجود ندارد؛ بنابراین هیچ کسی از وجود پروژۀ شما مطلع نخواهد شد.

دیدن تغییرات جان در پروژه (شما)

بسیار خوب، کار جان تمام شده و اکنون نوبت ماست که تغییرات او را بازبینی و سپس در پروژه ادغام کنیم. ابتدا به مخزن خودمان سوئیچ کرده و مخزن عمومی جان را به عنوان ریموت به مخزنمان معرفی می‌کنیم تا بتوانیم تغییراتش را فچ کنیم:

cd ../my-git-repo
git remote add john http://bitbucket.org/<username>/johns-repo.git

توجه کنید که ما کاری با تغییرات جان در مخزن خصوصیِ واقع روی سیستمش نداریم. تنها تغییرات موجود روی مخزن عمومی او برای ما مهم است. شاخه‌های او را دانلود می‌کنیم تا ببینیم روی چه چیزهایی کار کرده است:

git fetch john
git branch -r
git log master..john/pink-page --stat

ابتدا با دستور fetch شاخه‌های ریموت جان را به فهرست شاخه‌های ریموت خود اضافه می‌کنیم. دستور branch -r اسامی شاخه‌های ریموت را نشان می‌دهد. نهایتاً با دستور آخر چیزهای موجود در شاخۀ ریموت john/pink-page را که در شاخل مسترِ ما وجود ندارد نمایش می‌دهیم. یادتان هست که فلگ stat– جزئیات بیشتری را (مثلاً تعداد خطوط اضافه و حذف شده و اسامی فایل‌های تغییر کرده) نمایش می‌دهد. اگر از این فلگ استفاده نکنید فقط کامیت‌هایی جدید را نشان می‌دهد.

تاریخچۀ پروژه بعد از اجرای دستورات بالا به شکل زیر در می‌آید:

قبل از ادغام شاخۀ pink-page جان

حالا می‌خواهیم تغییرات را به صورت واقعی مشاهده کنیم، پس شاخه را چک‌اوت می‌کنیم:

git checkout john/pink-page

فایل pink.html را باز کنید تا بررسی کنید همه چیز اکی است. به خاطر دارید که جان یک مشارکت‌کنندۀ ناشناس است و نباید تغییرات او را چشم‌بسته با پروژۀ اصلی ادغام کنیم. هیچ‌گاه بدون بررسی محتوای contributor ها عمل ادغام را انجام ندهید.

یکپارچه‌سازی تغییرات با مخزن جان (شما)

فرض می‌کنیم تغییرات جان هیچ مشکلی نداشته و اکنون می‌خواهیم این تغییرات را با در پروژه ادغام کنیم. طبق معمول به شاخۀ مستر سوئیچ می‌کنیم و سپس عمل merge را انجام می‌دهیم:

git checkout master
git merge john/pink-page

توجه کنید که این دقیقاً مشابه وقتی است که تغییرات ماری را در گردش کار متمرکز با پروژۀ اصلی ادغام می‌کردیم. تنها تفاوتش این است که حالا از جای دیگری تغییرات را pull و در جای دیگری پوش می‌کنیم.

گردش کار integrator با مشارکت جان

گردش کار جان مشابه ماست: در یک شاخۀ لوکال که در واقع یک مخزن خصوصی است پروژه را توسعه می‌دهد؛ سپس به مخزن عمومی‌اش پوش می‌کند. گردش کار integrator صرفاً راهی برای ساماندهی بهتر فایل‌های پروژه است و دستورات جدیدی را شامل نمی‌شود.

بخوانید  آموزش گیت - قسمت دوم

انتشار تغییرات جان به مخزن اصلی پروژه (شما)

ما مخزن لوکال خود را (my-git-repo) با تغییرات جان هماهنگ کردیم ولی هنوز تغییرات مخزن لوکال یا خصوصی خود را به مخزن عمومی‌مان (که دراینجا مخزن رسمی است) ارسال نکرده‌ایم. اکنون زمان آن رسیده تا تغییرات را در شاخۀ مسترِ مخزن رسمی منتشر کنیم.

git push origin master

از آنجایی که مخزن عمومی‌مان در بیت‌باکت را مخزن اصلی پروژه در نظر گرفتیم. اکنون همۀ افراد (ماری، جان و …) می‌توانند با تغییرات جدید آن سینک شوند.

بروزرسانی مخزن ماری (ماری)

حالا ماری می‌تواند به جای دریافت تغییرات از یک مخزن مرکزی، آن‌هارا از مخزن بیت باکت ما دریافت کند. این کار به سادگی انجام می‌گیرد:

cd ../marys-repo
git remote rm origin
git remote add origin http://bitbucket.org/<username>/my-git-repo.git

فراموش نکنید که به جای username، نام کاربری خود در بیت باکت را قرار دهید. برای اختصار، بدون بررسی کدهای جان، تغییرات او را در مخزن ماری اعمال می‌کنیم (در حالت عادی، ماری باید قبل از انجام چنین کاری حتماً تغییرات جان را چک کند).

برای ماری مهم نیست که تغییرات جدید official master (شاخۀ مستر در مخزن رسمی) از طرف جان اعمال شده است. او فقط این را می‌داند که مخزن اصلی پروژه تغییر کرده و باید آخرین تغییرات را در مخزن خصوصی خود دریافت کند. به همین خاطر با دستور rebase به origin/master فست فوروارد (fast-forward) می‌کند.

git checkout master
git fetch origin
git rebase origin/master

بروزرسانی مخزن جان (جان)

جان هنوز تغییرات صفحۀ صورتی را به شاخۀ مستر خود منتقل نکرده است. او نمی‌تواند عمل ادغام را مستقیماً از شاخۀ pink-page محلی‌اش انجام دهد چون این شاخه قبلاً وارد مخزن اصلی پروژه شده و ممکن است تاکنون توسط سایر برنامه‌نویس‌ها تغییر کرده باشد. به جای این کار او از شاخۀ مستر در مخزن اصلی عمل pull را انجام می‌دهد:

cd ../johns-repo
git checkout master
git fetch origin
git rebase origin/master

اگر جان شاخۀ مستر را مستقیما از pink-page محلی آپدیت می‌کرد ممکن بود نسبت به پروژۀ اصلی از هماهنگی خارج می‌شد. به همین خاطر، در گردش کار integrator قاعده این است که هر شخص تغییرات را از مخزن اصلی یا official فچ کند ولی تغییرات جدید را در مخزن عمومی خودش پوش کند:

گردش کار integrator با چندین توسعه‌دهنده

با این روش، تغییرات اعمالی توسط یک توسعه‌دهنده می‌تواند تایید، یکپارچه‌سازی و در دسترس دیگران قرار گیرد بدون اینکه کدهای شخص دیگر با مشکل مواجه شود.

جمع‌بندی

در گردش کار integrator بخش عمده‌ای از کارها که در مخزن خصوصی انجام می‌دهیم همانند گذشته است (توسعه در شاخه‌ای مجزا، ادغام با شاخۀ master و سپس انتشار). ولی برای همکاری افراد ناشناس در پروژه یک سری کارهای دیگر هم به این فرایند اضافه می‌شود که البته نیازی به یادگیری مهارت‌های جدید نیست؛ صرفاً دسترسی به چند مخزن ریموت است.

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

البته نکتۀ جالب دیگری هم در این روش وجود دارد که ایمنی آن را بسیار بالا می‌برد. گردش کار integrator به خاطر وجود مخزن عمومی برای هر توسعه‌دهنده، محیط ایمن‌تری برای توسعۀ پایدار پروژه فراهم می‌کند که این موضوع در پروژه‌های متن‌باز به وضوح احساس می‌شود. به عنوان مثال ممکن است صاحب مخزن رسمی یا Official بی‌خیال آن شود و تغییرات ارسالی جدید از سوی دیگران را در آن اعمال نکند یا اصلاً مخزن را حذف کند. اینجا اگر از گردش کار مرکزی استفاده کرده بودیم، زحمات همه از بین می‌رفت.

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

مخزن ماری به عنوان مخزن رسمی اعلام شده است

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

سید ایوب کوکبی

نویسنده و مترجم...

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *