مثل Senior ها از Git استفاده بکن!

گیت یک ابزار قدرتمند است که وقتی بفهمی چطوری باید ازش استفاده کنی خیلی ازش لذت می‌بری.

من از این ویژگی های گیت برای سال ها توی شرکت ها و تیم هایی که بودم استفاده می‌کردم. من هنوز در حال بررسی نظرات در مورد برخی از روند های کاری هستم (مثل stash یا نه) اما ابزار اصلی قدرتمند و انعطاف‌پذیر است (و قابل نوشتن به صورت اسکریپت است!).

با Git logs شروع کنیم

زشته که git log رو توی بحثمون نیاریم.

مبحثی ساده، Git log

با استفاده از git log می‌توانیم اطلاعاتی رو به دست بیاوریم. اما معمولا این اطلاعات خیلی دقیق هستند و ما به دنبال تمامی آن جزئیات نیستیم.

git log

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

راه بهتری هم وجود دارد.

راهی نمایانتر

با استفاده از graph-- و format-- میتونیم به سرعت یک خلاصه ای از commit های پروژه خودمون ببینم.

git log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset)%C(white)%an%C(reset)%C(bold yellow)%d%C(reset) %C(dim white)- %s%C(reset)' --all

به به :)
ما تونستیم log های تر و تمیزی پیدا کنیم. حتی یک شبه درخت از branch خودمون هم می‌تونیم کنارش ببینیم.

این log ها به ما نشون می‌دن که چه کسی روی چه چیزی کار می‌کرده، چه زمانی تغییرات رخ داده‌اند و کجا تغییرات شما قرار گرفته‌اند.

با استفاده از graph-- ما می‌تونیم گراف درخت را به سمت چپ اضافه کنیم. قبول دارم که خیلی گراف زیبایی نیستش، اما این می‌تونه به مصورسازی تغییرات در branch پروژه‌مون کمک کنه. (مطالعه داکیومنت گراف)

با استفاده از format-- ما می‌تونیم log خود را فرمت کنیم.تعدادی فرمت از قبل موجود برای استفاده هستند همچنین ما می‌تونیم فرمت خودمون رو درست کنیم. (مطالعه داکیومنت format)

و all-- می‌تواند تمامی ref ها، tag ها و branch ها (شامل branch های remote هم میشود.)ی موجود در لاگ را نشان دهد که شاید شما این موارد را لازم نداشته باشید. (مطالعه داکیومنت all)

همچنین با مشاهده git log شما می‌توانید اطلاعات بیشتری برای ارتقا سطح خودتون در این زمینه کسب کنید.

فهمیدن یک commit خاص

اوقاتی هست که ما به دنبال فهمیدن یک commit خاص هستید. git show می‌تواند به ما دید عمیقی از نحوه تغییر یک commit دهد، اما همچنین به ما اجازه می‌دهد تغییرات در فایل های خاص را هم ببینید.

مشاهده خلاصه ای از یک commit

git show <commit> --stat

با استفاده از stat-- ما می‌توانیم خلاصه ای از commit ها در کنار فایل هایی که دارای تغییراتی بوده اند و نحوه تغییراتشان را ببینیم.

دیدن تغییرات یک فایل مشخص برای یک commit

وقتی ما می‌خواهیم که تغییرات یک خط در یک فایل مشخص برویم، باید از git show با مسیر فایل استفاده کنید.

git show <commit> -- <filepath>

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

همچنین با مشاهده git show شما می‌توانید اطلاعات بیشتری برای ارتقا سطح خودتون در این زمینه کسب کنید.

ایجاد تغییرات

ما یک branch برای پروژه‌‌مان ساخته‌ایم و تغییراتی را commit کرده‌ایم، و آماده هستیم که آن تغییرات را با branch اصل (main) ادغام (merge) کنیم. از آنجایی که ما روی branch دیگری هستیم، یک برنامه نویس دیگر تغییراتی را روی همان فایل انجام داده است.

اگر ما از سرویسی مانند github استفاده بکنیم، PR ما به ما می‌گوید که conflict ها را merge کنیم.

گیت از ما می‌خواهد قبل از اینکه تغییرات خود را به branch اصلی (main) برگردانیم، این merge conflict ها را حل کنیم. این اتفاق خوبی هست چون ما نمی‌خواهیم تمام سخت کوشی همکارانمان را خراب کنیم.

برای رفع این مشکل معمولا از یکی از دو روش زیر عمل می‌کنیم:

merge یا rebase

مقایسه git merge با git rebase

وقتی تغییراتی در branch اصلی ایجاد می‌شود که می‌خواهیم در branch خود بگنجانیم، می‌توانیم تغییرات را در شاخه خود merge کنیم یا branch خود را از نقطه ای به نقطه دیگر rebase کنیم.

مورد اول merge تغییرات را از branch ای میگیرد و آن ها را با branch دیگری merge می‌کند با یک merge commit.

git merge origin/main your-branch

و مورد دوم rebase نقطه ای را تنظیم می کند که در آن شاخه واقعاً منشعب شده است (یعنی شاخه را به نقطه شروع جدیدی از شاخه پایه منتقل می کند).

git rebase origin/main your-branch

عمدتا ما از rebase زمانی استفاده می‌کنیم که تغییراتی در branch بالاتر مانند main رخ داده است که ما می‌خواهیم آنها را در branch خود داشته باشیم. ما از merge زمانی استفاده می‌کنیم که تغییراتی در یک branch رخ داده است که می‌خواهیم آن ها را به برنچ اصلی یا main برگردانیم.

از squash استفاده بکنیم یا نه؟

من عادت داشتم که همیشه از squash استفاده کنم. اما مقاله ای از دکتر درک آستین نظر من را به کلی در این باره تغییر داد. من به شدت به شما پیشنهاد می‌کنم که آن مقاله را مطالعه بکنید و مطمئن باشید که من هیچ دانشی فراتر از حرف ایشون ندارم.

"شایان رادی هستم و این اولین ترجمه من در سایت ویرگول هست. امیدوارم از قلم من خوشتون آمده باشد و خوشحال می‌شوم که نظراتتون رو با من در این باره به اشتراک بگذارید"

لینک مقاله اصلی:

" https://medium.com/gitconnected/use-git-like-a-senior-engineer-ef6d741c898e "