بحث های زیادی در مورد ادغام git و git rebase وجود دارد که کدام بهتر است. امروز در وبلاگ Git Rebase vs Merge همه ابهامات شما را در مورد Git Rebase vs Git Merge برطرف خواهیم کرد. هر دو تکنیک برای یک هدف مورد استفاده قرار می گیرند، بنابراین به دلیل شباهت هایی که دارند درک آنها کمی دشوار است. در پایان وبلاگ، زمان استفاده از Git Rebase در مقابل Merge را خواهید آموخت.
دستورات Git Merge و Git Rebase برای ترکیب کار چندین توسعه دهنده در یک کد واحد استفاده می شود. هدف نهایی هر دو دستور یکسان است، اما استفاده از آنها متفاوت است. امروز در این وبلاگ سعی خواهیم کرد Git Merge در مقابل Git Rebase را درک کنیم.
اگر دوست ندارید مطالعه کنید، در اینجا یک ویدیو در مورد Git Rebase در مقابل Merge وجود دارد تا به شما در درک آنچه در این وبلاگ نوشته شده است کمک کند.
بنابراین، موضوعات زیر در این وبلاگ مورد بررسی قرار می گیرد:
Git چگونه کار می کند؟
برای درک نحوه عملکرد git، باید دو مفهوم اساسی در git یعنی git commit و git branch را درک کنیم. اجازه دهید این دو اصطلاح را به ترتیب درک کنیم.
تعهد چیست؟
commit به عنوان محلی که کد و تغییرات آن ذخیره می شود تعریف می شود. اجازه دهید مثالی بزنیم و به طور خلاصه از نمودار نشان داده شده در زیر بحث کنیم:
شکل 1: تغییرات ایجاد شده در یک commit ثبت می شود
در شکل: 1، فرض کنید چهار فایل پایتون داریم. ما آنها را در git ذخیره کردیم. این چهار فایل پایتون در یک commit ذخیره خواهند شد. هر commit یک commit-id دارد، بگذارید در مورد ما 1234 باشد. حالا فرض کنید با افزودن یک فایل پایتون دیگر تغییراتی در کد ایجاد کردیم. این تغییرات git به عنوان یک commit دیگر با شناسه commit دیگر 14343 ذخیره می شود. این را می توان در شکل مشاهده کرد. 2. بنابراین هر بار که ما تغییراتی ایجاد می کنیم، یک commit جدید ایجاد می کند.
شکل 2: تغییرات ایجاد شده در مخزن به عنوان یک commit جدید با یک شناسه commit جدید ذخیره می شود.
شعبه چیست؟
یک شاخه نمایشی از نسخه های جدا شده مختلف کد است. برای درک این موضوع مثالی می زنیم. فرض کنید یک وب سایت دارید که در حال حاضر راه اندازی شده است. سایت چیزی شبیه این به نظر می رسد.
شکل 3: نمونه وب سایت قبل از تغییرات
شما می خواهید ویژگی های بیشتری را به این وب سایت اضافه کنید. برای این کار باید کد وب سایت را تغییر دهید. اما اگر کد را تغییر دهید، نمی خواهید تغییرات در وب سایت اصلی که مستقر شده است منعکس شود. خوب چکار می کنی؟ در حالت ایده آل، کد این وب سایت را در یک پوشه جدید کپی کنید. تغییراتی در کد ایجاد کنید، و پس از نهایی شدن تغییرات، کد را در پوشه root جایگزین می کنید، درست است؟ بیایید ببینیم چگونه می توانیم کار بالا را در git انجام دهیم.
بنابراین در git برای جداسازی نسخه‌های مختلف کد، فورک داریم. به طور پیش فرض، تمام کد شما در یک شاخه اصلی ذخیره می شود. بنابراین وب سایتی که در بالا به شما نشان دادیم شعبه اصلی است. حالا نمی‌خواهیم کد شاخه اصلی را لمس کنیم، می‌خواهیم کد شعبه اصلی را در مکانی جدید کپی کنیم تا بتوانیم کد را آزمایش یا تغییر دهیم. بنابراین، بدون تأثیر بر شاخه اصلی. بنابراین ما یک شاخه جدید از شاخه اصلی ایجاد می کنیم، اجازه دهید آن را “شاخه ویژگی ها” بنامیم. اکنون هر تغییر جدیدی که در شاخه ویژگی ایجاد کنید، روی کد در شاخه اصلی تأثیری نخواهد داشت.
شکل 4: شاخه اصلی و شاخه ویژگی
هنگامی که تغییرات را تمام کردید، ما به سادگی تغییرات شاخه “ویژگی” را به شاخه “مستر” “ادغام” می کنیم. و حالا تغییراتی که در شاخه feature انجام شد در شاخه master نیز وجود خواهد داشت.
شکل 5: ادغام یک شاخه ویژگی با شاخه اصلی
اگر به مثال بالا از یک وب سایت پس از ادغام نگاه کنیم، تغییرات را می توان در نمودار زیر مشاهده کرد:
شکل 6: پس از ادغام تغییرات در شاخه اصلی، تغییرات در وب سایت ارائه شد.
اگر ادغام را متوجه نشدید، نگران نباشید، در قسمت بعدی همه چیز مشخص خواهد شد.
ادغام چیست؟
به طور کلی، ادغام به معنای ترکیب چیزی در یک کل است.
Git Merge تکنیکی است که برای ترکیب تغییرات از یک شاخه به شاخه دیگر استفاده می شود.
بنابراین بیایید یک مثال از نمودار زیر بگیریم که وضعیت قبل و بعد از ادغام دو شاخه، یک ویژگی و یک شاخه اصلی را نشان می دهد. کامیت های آبی در شاخه اصلی و کامیت های زرد در شاخه عملکردی قرار دارند.
شکل 7: قبل از ادغام
در شکل 7: قبل از ادغام، می بینیم که تعدادی commit در شاخه اصلی وجود دارد. پس از commit ‘2’ در master یک شاخه ویژگی ایجاد کردیم. بعداً تغییراتی را در شاخه ویژگی به صورت commit های A و B انجام دادیم و در شاخه master نیز در قالب commit 3 تغییراتی ایجاد کردیم.
در سناریوی فعلی، شاخه اصلی دارای کد روی Commit 1،2 و 3 است، اما هیچ تغییری در Commit A و B از شاخه ویژگی وجود ندارد.
به طور مشابه، از آنجایی که شاخه ویژگی از master در commit ‘2’ جدا شده است، تغییرات کد از Commits 1، 2، A و B دارد، اما هیچ تغییری از Commit 3 در Master وجود ندارد.
در زیر شاخه تابع master را ادغام کرده ایم، بیایید بفهمیم چه اتفاقی افتاده است.
شکل 8: پس از ادغام
ما شاخه ویژگی را به master ادغام کردیم، که منجر به commit 4 شد. Commit 4 در master تمام تغییرات کد را دارد. commit 1،2،3، A و B. حالا که ادغام را فهمیدیم، بیایید انواع مختلف ادغام را که می توانیم در git انجام دهیم، درک کنیم. در Git، ادغام دو نوع است:
بگذارید هر دو را با جزئیات درک کنیم
Git Merge
ادغام Git یکی از تکنیک های ادغام در git است که در آن لاگ های commit شاخه ها دست نخورده هستند.
بیایید مثالی بزنیم اگر پروژه ای با 3 commit master شاخه به عنوان commit های 1،2،3 و commit های شاخه ویژگی به عنوان commit های A و B داشته باشیم. اگر یک عملیات ادغام git را انجام دهیم، commit های A و B به عنوان commit 4 ادغام می شوند. شعبه اصلی این در شکل 9 نشان داده شده است.
شکل 9: قبل و بعد از Git Merge.
مزایای:
- گزارش‌ها بسیار جامع هستند و می‌توانند به درک تاریخچه کامل چگونگی و زمان وقوع هر ادغام کمک کنند
- پیدا کردن خطاها و حل آنها آسان است.
معایب:
- نتیجه یک گزارش/داستان بی‌هدف است
- خیلی کاربر پسند نیست
شکل 10: مثالی که یک مخزن با چندین شاخه را نشان می دهد که با استفاده از git-merge ادغام شده اند.
Git-Rebase
Git Rebase مشابه git merge است، اما لاگ ها پس از ادغام در این تکنیک تغییر می کنند. برای غلبه بر محدودیت ادغام، یعنی خطی نشان دادن گزارش‌های تاریخچه مخزن، rebase Git معرفی شد.
بیایید مثالی بزنیم اگر پروژه ای با 3 کامیت اصلی شاخه به عنوان کامیت های 1،2،3 و کامیت های شاخه ویژگی به عنوان کامیت های A و B داشته باشیم. اگر یک عملیات rebase git را انجام دهیم، commit های A و B به شاخه اصلی مانند commits تغییر خواهند کرد. 4 و 5 را انجام دهید و هیچ گزارش شاخه ویژگی وجود نخواهد داشت. این در شکل نشان داده شده است. 12.
شکل 12: قبل و بعد از rebase git
مزایای:
- لاگ ها خطی هستند
- پیمایش در پروژه آسان است.
معایب:
- ما نمی توانیم زمان و نحوه ادغام commit ها در شاخه هدف را پیگیری کنیم
Git Merge در مقابل Git Rebase:
| ادغام | Rebasing |
| Git merge دستوری است که به شما امکان می دهد شاخه های Git را ادغام کنید. | Git rebase دستوری است که به توسعه دهندگان اجازه می دهد تغییرات را از یک شاخه به شاخه دیگر ادغام کنند. |
| در Git Merge، لاگ ها تاریخچه کامل ادغام commit را نشان خواهند داد. | فایل‌های گزارش در rebasing Git خطی هستند، زیرا commitها در حال تغییر مجدد هستند |
| تمام commit ها در شاخه ویژگی به عنوان یک commit در شاخه اصلی ترکیب می شوند. | همه کامیت ها مجدداً پایه گذاری می شوند و به همان تعداد commit به شاخه اصلی اضافه می شود. |
| Git Merge زمانی استفاده می شود که شاخه هدف یک شاخه مشترک باشد | Git Rebase باید زمانی استفاده شود که شاخه هدف یک شاخه خصوصی است |
چه زمانی از Git Merge در مقابل Git Rebase استفاده می کنیم؟
بیایید آن را با یک مثال درک کنیم، لطفا نمودار زیر را ببینید:
شکل 13: تفاوت مخزن را بعد از Git Merge در مقابل Git Rebase ترسیم می کند.
در git merge، با نگاه کردن به نمودار نهایی، می توانید ببینید که Commit A و B از شاخه ویژگی آمده اند. با این حال، در نمودار git-rebase، تشخیص اینکه commit های A و B از کجا آمده اند، دشوار است. بنابراین، زمانی که می خواهیم تیم ما گزارش ها را به گونه ای درک کند که بتواند تشخیص دهد که هر commit از کجا آمده است، ادغام git را انجام می دهیم. ما زمانی از Git Rebase استفاده می کنیم که لاگ های مخزن توسط شخص دیگری ارسال نشود. به طور خلاصه، می‌توانیم از Git Rebase هنگام کار بر روی شاخه‌هایی که توسط توسعه‌دهندگان دیگر دیده نمی‌شوند، استفاده کنیم. و زمانی از Git Merge استفاده می کنیم که شاخه هدف و منبع توسط توسعه دهندگان دیگر قابل مشاهده باشد.
چگونه می توان از Git Rebase و Git Merge با هم استفاده کرد؟
بیایید مثالی بزنیم اگر پروژه ای داریم که شامل یک شاخه اصلی با 3 تعهد به عنوان 1،2،3 و 2 شاخه تابعی با تعهدات A، B از شاخه عملکردی 1 و متعهدهای C، D از شاخه عملکردی 2 است که در زیر نشان داده شده است. شکل. 14.
شکل 14: نمایش مثال بالا
بیایید فرض کنیم که توسعه دهنده A روی شاخه 1 ویژگی کار می کند.
برای آزمایش کد، شاخه دیگری به نام Feature branch 2 ایجاد می کند، تغییراتی در آن ایجاد می کند و با Commits C و D آن را نهایی می کند.
او نمی خواهد کسی در مورد شعبه خصوصی او بداند زیرا غیر ضروری است. بنابراین او می تواند تابع 2 را بر روی تابع 1 تغییر دهد.
اکنون او می تواند در نهایت ویژگی 1 شاخه را با هم ادغام کند و در نمودار زیر ایجاد شود.
موارد بالا همان چیزی است که لاگ نهایی برای سایر توسعه دهندگان به نظر می رسد. آنها فقط می توانند commit های انجام شده در شاخه عملکردی 1 را ببینند که در نهایت با commit 4 در شاخه اصلی ادغام شد.
این وبلاگ Git Merge در مقابل Git Rebase را به پایان می رساند. ما مطمئن هستیم که تمام ابهامات شما در مورد Git Merge در مقابل Git Rebase باید تا کنون روشن شده باشد. اگر نه، توصیه می کنیم ابتدا اصول Git را مرور کنید، برای اطلاعات بیشتر به وبلاگ آموزش Git ما مراجعه کنید.
همچنین، اگر می‌خواهید یک مهندس Devops شوید و به کمک حرفه‌ای نیاز دارید، آموزش گواهینامه Devops Edureka را بررسی کنید و توسط مهندسین Devops در سطح جهانی از سراسر جهان آموزش ببینید!