Summarize this content to 400 words in Persian Lang
نمونه هایی در این وبلاگ از “Pro Git” نوشته اسکات چاکن، بن استراوب آمده است
بیایید به جنبه‌های جالب‌تری درباره Git بپردازیم که ممکن است به درک شما از آن در سطح عمیق‌تری کمک کند.
1 – وقتی صحنه سازی می کنیم و متعهد می شویم در پشت صحنه چه اتفاقی می افتد؟
فرض کنید یک دایرکتوری حاوی 3 فایل داریم و همه آنها را مرحله بندی کرده و commit می کنیم.
در طول صحنه سازی چه اتفاقی می افتد؟
برای هر فایل با استفاده از جمع کنترلی محاسبه کنید SHA-1 هش کردن
نسخه فعلی فایل ها را در مخزن Git به عنوان ذخیره می کند حباب ها، عکس های فوری نسخه شده از یک فایل.
چک جمع را برای هر فایل در آن ثبت کنید منطقه صحنه سازی.
در طول یک commit چه اتفاقی می افتد؟
Git هر زیر شاخه را جمع‌بندی می‌کند (معمولاً سطح بالایی دایرکتوری اصلی پروژه است) و آنها را به عنوان یک فهرست ذخیره می‌کند. شی درخت در مخزن Git. این شیء ساختار پروژه را در آن لحظه ثبت می کند، از جمله نام فایل ها و حباب های مربوط به آنها (محتوای فایل).
Git a ایجاد می کند ارتکاب شی که حاوی ابرداده + یک اشاره گر به شی درخت است. این به Git اجازه می دهد تا در صورت نیاز کل عکس فوری پروژه را دوباره ایجاد کند.
در این مرحله، مخزن Git شما حاوی 5 شی است:
3 حباب
1 شی درختی (محتویات دایرکتوری را فهرست می کند و نام فایل ها را به حباب ها نشان می دهد)
1 شی commit که به شی درختی اشاره می کند و حاوی ابرداده است
اگر تغییرات بیشتری ایجاد کنیم و دوباره commit کنیم، تاریخچه commit به این صورت خواهد بود:
2 – استفاده از سوئیچ git به جای پرداخت git
ممکن است قبلاً با استفاده از آن آشنا باشید پرداخت git برای جابجایی بین شاخه ها، و آن روش کاملاً خوب کار می کند.
با این حال، اگر می‌خواهید راه بصری‌تری برای جابه‌جایی بین و ایجاد شاخه‌ها داشته باشید، از آن استفاده کنید سوئیچ git!
گیت سوئیچ شاخه-نام – به یک شعبه موجود تغییر دهید
git switch -c new-branch – ایجاد شعبه جدید و تغییر به آن
سوئیچ git – – بازگشت به شعبه ای که قبلاً بررسی شده است
3 – پشت صحنه در حین ادغام چه اتفاقی می افتد؟
وقتی دو شاخه را ادغام می کنیم، به طور شهودی می توانیم بگوییم که فقط دو تاریخچه را می گیرد و کار آنها را ترکیب می کند. اما واقعا به چه معناست؟ بیایید به این مثال نگاه کنیم:
فرض کنید کارمان تمام شده است iss10 شاخه و می خواهید آن را با آن ادغام کنید استاد.
git switch master
git merge iss10
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
از آنجایی که iss53 جد مستقیم نیست استاد، هنگام ادغام باید کارهایی انجام دهیم. ادغام پیش فرض a را انجام می دهد ادغام سه طرفه در میان دو عکس فوری که توسط استاد و iss53 و جد مشترک آنها.
در ادغام سه طرفه، Git یک a را ایجاد می کند عکس فوری جدید که از آن حاصل می شود و به طور خودکار یک commit جدید ایجاد می کند که به عکس فوری اشاره می کند. این commit a نام دارد ادغام commit. این ویژه است زیرا بیش از 1 والدین دارد.
در این مرحله، همه چیز ادغام می شود و می توانید آن را حذف کنید iss10 شاخه
4 – دو نوع متداول گردش کار انشعاب
شاخه های طولانی مدت
در این گردش کار، می توانید چندین شعبه همیشه باز داشته باشید که هر کدام نشان دهنده مراحل مختلف چرخه توسعه شما هستند.
استاد / اصلی – کدی که کاملاً پایدار است
توسعه/بعدی – کدی که لزوماً پایدار نیست (برای آزمایش پایداری)
موضوع-شاخه – ویژگی فعلی که روی آن کار می کنید
همچنین می‌توانید این گردش کار را به‌عنوان سیلوهای کاری مشاهده کنید، جایی که مجموعه‌ای از تعهدات پس از آزمایش کامل به سیلوی پایدارتر تغییر می‌کنند.
شاخه های موضوع
این گردش کار برای پروژه هایی با هر اندازه ای مفید است. الف شاخه موضوع یک شاخه کوتاه مدت است که شما ایجاد می کنید و برای یک ویژگی استفاده می کنید. این تکنیک به شما امکان می دهد تا به سرعت و به طور کامل تغییر زمینه را انجام دهید، زیرا کار شما به سیلوهایی تقسیم می شود که در آن همه تغییرات در آن شاخه به آن موضوع مربوط می شود.
بیایید این گردش کار را دنبال کنیم:
کمی کار کنید استاد
شعبه به iss91
انشعاب به شعبه دیگر iss91v2 و مقداری کار انجام دهید
بازگشت به استاد و مقداری کار انجام دهید
شعبه به dumbidea برای آزمایش یک ایده
در اینجا تاریخچه commit چگونه خواهد بود:
فرض کنید کار روی آن را دوست دارید iss91v2 و dumbidea معلوم شد یک ایده نابغه است دور بریزیم iss91 (کمیت های C5 و C6 از دست دادن) و در دو شاخه دیگر ادغام می شوند.
5 – Rebasing چیست؟
در Git، 2 راه برای ادغام تغییرات از یک شاخه به شاخه دیگر وجود دارد: ادغام و روباه. ما قبلاً ادغام را پشت سر گذاشته‌ایم. بیایید به یک تغییر پایه اولیه بپردازیم.
بیایید به این مثال از یک تاریخ واگرا نگاه کنیم:
یک ادغام یک ادغام سه طرفه را انجام می دهد و یک تعهد ادغام ایجاد می کند. در یک rebase، ما همان نتیجه را به روشی متفاوت دریافت می کنیم. در اصل، ما تغییرات را در آن اعمال خواهیم کرد C4 و دوباره آن را در بالای آن قرار دهید C3متعهد است. در این مورد، شما باید تسویه حساب کنید آزمایش و دوباره آن را بر روی آن قرار دهید استاد.
در واقع اینجا چه اتفاقی می افتد؟
Rebasing به جد مشترک 2 شاخه می رود
می شود تفاوت معرفی شده توسط هر commit از شاخه ای که در آن هستید (آزمایش) و آن را به طور موقت در یک فایل ذخیره می کند
به شاخه فعلی استراحت می دهد (آزمایش) به همان commit شعبه ای که در حال تغییر آن هستیداستاد)
در نهایت، هر تغییر (از فایل با متفاوت است).
در این مرحله، می توانید به آن بازگردید استاد و یک ادغام سریع به جلو انجام دهید.
در اینجا، آخرین عکس فوری دقیقاً همان عکسی است که از ادغام پیش‌فرض حاصل می‌شود. تفاوت در اینجا این است که rebasing تاریخچه تمیزتری ایجاد می کند.
یه چیز دیگه بیایید در مورد معایب rebasing بحث کنیم زیرا به نظر می رسد آنقدر خوب است که درست نباشد. در را می توان در یک خط خلاصه کرد: تعهداتی را که خارج از مخزن شما وجود دارد و افراد ممکن است بر اساس آنها کار کرده باشند، تغییر ندهید.
چرا؟ خوب، به این گردش کار فکر کنید:
شما commitها را به جایی هل می‌دهید و دیگران آنها را پایین می‌آورند و کار را از آنها خارج می‌کنند.
شما این تعهدات را با آن بازنویسی کنید git rebase و دوباره آنها را به سمت بالا هل دهید.
در این مرحله، همکاران شما باید کار خود را مجدداً ادغام کنند و زمانی که می‌خواهید کار آنها را به کار خود بازگردانید، ممکن است بسیار کثیف شود.
6- کدام بهتر است؟ ادغام یا Rebase؟
حالا به بحث قدیمی که باعث ایجاد شکاف در بین برنامه نویسان شده است. ادغام یا Rebase بهتر است؟ در واقع نمی توانیم بگوییم. این بستگی به مورد استفاده و تیم/پروژه دارد.
شخصاً فکر می کنم این تصور غلط وجود دارد که این دو کار مشابهی را انجام می دهند و این فقط به ترجیحات شخصی بستگی دارد. در حالی که این بیشتر درست است، بسیار مهم است که بدانیم هر کدام چگونه کار می کند و هر کدام چه سناریوهایی ممکن است به همراه داشته باشند.
«پرو گیت» به نکته خوبی در مورد مقایسه این دو اشاره می کند. وقتی درباره تاریخچه یک پروژه صحبت می کنیم، باید از خود بپرسیم که چگونه باید آن را درک کرد.
یک دیدگاه بیان می کند که تاریخچه تعهد مخزن شما یک است ثبت آنچه در واقع اتفاق افتاده است. تاریخی است و نباید دستکاری شود.
دیدگاه مخالف این است که commit history داستان چگونگی ساخت پروژه شما است. پیش‌نویس‌هایی قبل از نسخه نهایی و تمیز وجود خواهد داشت.
احتمالاً می‌توانید بگویید که POV اول به استفاده از ادغام می‌پردازد در حالی که دومی به استفاده از rebase پاسخ می‌دهد. باز هم هیچکدام بهتر از دیگری نیست و بستگی به پروژه و تیم دارد.
اگر نمی توانید تصمیم بگیرید که از کدام یک استفاده کنید، حتی می توانید بهترین های هر دو دنیا را داشته باشید:
قبل از انجام فشار برای پاکسازی کار خود، تغییرات محلی را تغییر دهید
هرگز چیزی را که به جایی فشار داده اید تغییر ندهید
همین! امیدواریم از این وبلاگ لذت برده باشید و درباره Git و نحوه استفاده از آن در کار خود اطلاعات بیشتری کسب کرده باشید!
نمونه هایی در این وبلاگ از “Pro Git” نوشته اسکات چاکن، بن استراوب آمده است
بیایید به جنبه‌های جالب‌تری درباره Git بپردازیم که ممکن است به درک شما از آن در سطح عمیق‌تری کمک کند.
1 – وقتی صحنه سازی می کنیم و متعهد می شویم در پشت صحنه چه اتفاقی می افتد؟
فرض کنید یک دایرکتوری حاوی 3 فایل داریم و همه آنها را مرحله بندی کرده و commit می کنیم.
در طول صحنه سازی چه اتفاقی می افتد؟
- برای هر فایل با استفاده از جمع کنترلی محاسبه کنید SHA-1 هش کردن
- نسخه فعلی فایل ها را در مخزن Git به عنوان ذخیره می کند حباب ها، عکس های فوری نسخه شده از یک فایل.
- چک جمع را برای هر فایل در آن ثبت کنید منطقه صحنه سازی.
در طول یک commit چه اتفاقی می افتد؟
- Git هر زیر شاخه را جمع‌بندی می‌کند (معمولاً سطح بالایی دایرکتوری اصلی پروژه است) و آنها را به عنوان یک فهرست ذخیره می‌کند. شی درخت در مخزن Git. این شیء ساختار پروژه را در آن لحظه ثبت می کند، از جمله نام فایل ها و حباب های مربوط به آنها (محتوای فایل).
- Git a ایجاد می کند ارتکاب شی که حاوی ابرداده + یک اشاره گر به شی درخت است. این به Git اجازه می دهد تا در صورت نیاز کل عکس فوری پروژه را دوباره ایجاد کند.
در این مرحله، مخزن Git شما حاوی 5 شی است:
- 3 حباب
- 1 شی درختی (محتویات دایرکتوری را فهرست می کند و نام فایل ها را به حباب ها نشان می دهد)
- 1 شی commit که به شی درختی اشاره می کند و حاوی ابرداده است
اگر تغییرات بیشتری ایجاد کنیم و دوباره commit کنیم، تاریخچه commit به این صورت خواهد بود:
2 – استفاده از سوئیچ git به جای پرداخت git
ممکن است قبلاً با استفاده از آن آشنا باشید پرداخت git برای جابجایی بین شاخه ها، و آن روش کاملاً خوب کار می کند.
با این حال، اگر می‌خواهید راه بصری‌تری برای جابه‌جایی بین و ایجاد شاخه‌ها داشته باشید، از آن استفاده کنید سوئیچ git!
- گیت سوئیچ شاخه-نام – به یک شعبه موجود تغییر دهید
- git switch -c new-branch – ایجاد شعبه جدید و تغییر به آن
- سوئیچ git – – بازگشت به شعبه ای که قبلاً بررسی شده است
3 – پشت صحنه در حین ادغام چه اتفاقی می افتد؟
وقتی دو شاخه را ادغام می کنیم، به طور شهودی می توانیم بگوییم که فقط دو تاریخچه را می گیرد و کار آنها را ترکیب می کند. اما واقعا به چه معناست؟ بیایید به این مثال نگاه کنیم:
فرض کنید کارمان تمام شده است iss10 شاخه و می خواهید آن را با آن ادغام کنید استاد.
git switch master
git merge iss10
از آنجایی که iss53 جد مستقیم نیست استاد، هنگام ادغام باید کارهایی انجام دهیم. ادغام پیش فرض a را انجام می دهد ادغام سه طرفه در میان دو عکس فوری که توسط استاد و iss53 و جد مشترک آنها.
در ادغام سه طرفه، Git یک a را ایجاد می کند عکس فوری جدید که از آن حاصل می شود و به طور خودکار یک commit جدید ایجاد می کند که به عکس فوری اشاره می کند. این commit a نام دارد ادغام commit. این ویژه است زیرا بیش از 1 والدین دارد.
در این مرحله، همه چیز ادغام می شود و می توانید آن را حذف کنید iss10 شاخه
4 – دو نوع متداول گردش کار انشعاب
شاخه های طولانی مدت
در این گردش کار، می توانید چندین شعبه همیشه باز داشته باشید که هر کدام نشان دهنده مراحل مختلف چرخه توسعه شما هستند.
- استاد / اصلی – کدی که کاملاً پایدار است
- توسعه/بعدی – کدی که لزوماً پایدار نیست (برای آزمایش پایداری)
- موضوع-شاخه – ویژگی فعلی که روی آن کار می کنید
همچنین می‌توانید این گردش کار را به‌عنوان سیلوهای کاری مشاهده کنید، جایی که مجموعه‌ای از تعهدات پس از آزمایش کامل به سیلوی پایدارتر تغییر می‌کنند.
شاخه های موضوع
این گردش کار برای پروژه هایی با هر اندازه ای مفید است. الف شاخه موضوع یک شاخه کوتاه مدت است که شما ایجاد می کنید و برای یک ویژگی استفاده می کنید. این تکنیک به شما امکان می دهد تا به سرعت و به طور کامل تغییر زمینه را انجام دهید، زیرا کار شما به سیلوهایی تقسیم می شود که در آن همه تغییرات در آن شاخه به آن موضوع مربوط می شود.
بیایید این گردش کار را دنبال کنیم:
- کمی کار کنید استاد
- شعبه به iss91
- انشعاب به شعبه دیگر iss91v2 و مقداری کار انجام دهید
- بازگشت به استاد و مقداری کار انجام دهید
- شعبه به dumbidea برای آزمایش یک ایده
در اینجا تاریخچه commit چگونه خواهد بود:
فرض کنید کار روی آن را دوست دارید iss91v2 و dumbidea معلوم شد یک ایده نابغه است دور بریزیم iss91 (کمیت های C5 و C6 از دست دادن) و در دو شاخه دیگر ادغام می شوند.
5 – Rebasing چیست؟
در Git، 2 راه برای ادغام تغییرات از یک شاخه به شاخه دیگر وجود دارد: ادغام و روباه. ما قبلاً ادغام را پشت سر گذاشته‌ایم. بیایید به یک تغییر پایه اولیه بپردازیم.
بیایید به این مثال از یک تاریخ واگرا نگاه کنیم:
یک ادغام یک ادغام سه طرفه را انجام می دهد و یک تعهد ادغام ایجاد می کند. در یک rebase، ما همان نتیجه را به روشی متفاوت دریافت می کنیم. در اصل، ما تغییرات را در آن اعمال خواهیم کرد C4 و دوباره آن را در بالای آن قرار دهید C3متعهد است. در این مورد، شما باید تسویه حساب کنید آزمایش و دوباره آن را بر روی آن قرار دهید استاد.
در واقع اینجا چه اتفاقی می افتد؟
- Rebasing به جد مشترک 2 شاخه می رود
- می شود تفاوت معرفی شده توسط هر commit از شاخه ای که در آن هستید (آزمایش) و آن را به طور موقت در یک فایل ذخیره می کند
- به شاخه فعلی استراحت می دهد (آزمایش) به همان commit شعبه ای که در حال تغییر آن هستیداستاد)
- در نهایت، هر تغییر (از فایل با متفاوت است).
در این مرحله، می توانید به آن بازگردید استاد و یک ادغام سریع به جلو انجام دهید.
در اینجا، آخرین عکس فوری دقیقاً همان عکسی است که از ادغام پیش‌فرض حاصل می‌شود. تفاوت در اینجا این است که rebasing تاریخچه تمیزتری ایجاد می کند.
یه چیز دیگه بیایید در مورد معایب rebasing بحث کنیم زیرا به نظر می رسد آنقدر خوب است که درست نباشد. در را می توان در یک خط خلاصه کرد: تعهداتی را که خارج از مخزن شما وجود دارد و افراد ممکن است بر اساس آنها کار کرده باشند، تغییر ندهید.
چرا؟ خوب، به این گردش کار فکر کنید:
- شما commitها را به جایی هل می‌دهید و دیگران آنها را پایین می‌آورند و کار را از آنها خارج می‌کنند.
- شما این تعهدات را با آن بازنویسی کنید git rebase و دوباره آنها را به سمت بالا هل دهید.
در این مرحله، همکاران شما باید کار خود را مجدداً ادغام کنند و زمانی که می‌خواهید کار آنها را به کار خود بازگردانید، ممکن است بسیار کثیف شود.
6- کدام بهتر است؟ ادغام یا Rebase؟
حالا به بحث قدیمی که باعث ایجاد شکاف در بین برنامه نویسان شده است. ادغام یا Rebase بهتر است؟ در واقع نمی توانیم بگوییم. این بستگی به مورد استفاده و تیم/پروژه دارد.
شخصاً فکر می کنم این تصور غلط وجود دارد که این دو کار مشابهی را انجام می دهند و این فقط به ترجیحات شخصی بستگی دارد. در حالی که این بیشتر درست است، بسیار مهم است که بدانیم هر کدام چگونه کار می کند و هر کدام چه سناریوهایی ممکن است به همراه داشته باشند.
«پرو گیت» به نکته خوبی در مورد مقایسه این دو اشاره می کند. وقتی درباره تاریخچه یک پروژه صحبت می کنیم، باید از خود بپرسیم که چگونه باید آن را درک کرد.
یک دیدگاه بیان می کند که تاریخچه تعهد مخزن شما یک است ثبت آنچه در واقع اتفاق افتاده است. تاریخی است و نباید دستکاری شود.
دیدگاه مخالف این است که commit history داستان چگونگی ساخت پروژه شما است. پیش‌نویس‌هایی قبل از نسخه نهایی و تمیز وجود خواهد داشت.
احتمالاً می‌توانید بگویید که POV اول به استفاده از ادغام می‌پردازد در حالی که دومی به استفاده از rebase پاسخ می‌دهد. باز هم هیچکدام بهتر از دیگری نیست و بستگی به پروژه و تیم دارد.
اگر نمی توانید تصمیم بگیرید که از کدام یک استفاده کنید، حتی می توانید بهترین های هر دو دنیا را داشته باشید:
- قبل از انجام فشار برای پاکسازی کار خود، تغییرات محلی را تغییر دهید
- هرگز چیزی را که به جایی فشار داده اید تغییر ندهید
همین! امیدواریم از این وبلاگ لذت برده باشید و درباره Git و نحوه استفاده از آن در کار خود اطلاعات بیشتری کسب کرده باشید!
