گیت را در یک مطلب قورت بده! (۲)

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

این مطلب ادامه مقاله «گیت را در یک مطلب قورت بده!» است. پس بهتر است پیش از خواندن این مطلب، آن را مطالعه کنید. 

۱- برنچ‌ – شاخه

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

دلایل استفاده از برنچ:

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

۲- ایجاد یک برنچ جدید

به صورت پیشفرض گیت یه برنچ به اسم master برای ما ایجاد میکنه که پروژه اصلی ما روی اونه. برای اینکه یه برنچ جدید بسازید کافیه دستور زیر رو وارد کنید:

git branch new_feature

حالا من یه برنچ جدید با نام new_feature ساختم. با استفاده از دستور branch به صورت خالی، می‌تونید لیستی از برنچ‌های موجود رو ببینید:

git branch

اون علامت ستاره قبل از هر کدومش باشه به این معناست که ما روی اون کار می‌کنیم. حالا بزارید از روی برنچ master بریم روی برنچ جدیدی که ساختیم. برای اینکار دستور checkout رو وارد می‌کنیم:

git checkout new_feature

حالا یه بار دیگه git branch رو وارد کنید که مطمئن بشید علامت ستاره روی گزینه new_feature قرار داره.

اگه بود می‌تونیم فرایند توسعه رو ادامه بدیم. برای اینکه ببینیم دقیقا چه اتفاقاتی می افته، توی این برنچ جدید یه فایل می‌سازیم و اون رو کامیت می‌کنیم:

touch new_file.txt git add new_file.txt git commit -m "new file in new branch"

حالا جالبی قضیه می‌دونید کجاست؟ وقتی که برگردید سراغ برنچ master می بینید که فایل new_file.txt مخفی شده و نمی‌تونید ببینیدش. خب دلیل‌ش اینه که این فایل توی یه برنچ دیگه قرار داره نه برنچ مستر.

۳- Merge کردن برنچ‌ها

خب حالا که من بخوام تمام برنچ‌های ساخته شده رو به برنچ اصلی یعنی برنچ master بیارم باید چیکار کنم؟ سوال خوبیه. تنها کافیه که فایل‌های مختلف برنچ‌های مختلف رو بریزید توی master برای اینکار از دستور merge استفاده می‌کنیم.

اولا که وارد برنچ مستر میشم:

git checkout master

بعد عملیات مرج کردن رو شروع می‌کنم:

git merge new_feature

خب حالا می‌تونید ببینید که فایل new_file.txt به برنچ مستر اضافه شد. حالا که کارمون با برنچ قبلی تموم شد می‌تونیم حذفش بکنیم.

git branch -d new_feature

۴- بررسی تفاوت‌های بین دو کامیت

هر کامیتی که شما توی مخزن‌تون می‌کنید یه آی‌دی منحصر به فرد داره که به ما قابلیت دسترسی رو میده. اگه می‌خواید لیست تموم کامیت‌هایی که تا به حال کردید رو ببینید کافیه دستور git log رو وارد بکنید.

commit 2e3e8df76377cb0a8e162892215de93a30f74b03 (HEAD -> master) Author: Arastoo test@test.com> Date: Tue Nov 27 01:09:48 2018 +0330 Second Commit commit 6522647a9fa63906d2216d505b8c9578de30ba97 Author: Arastoo test@test.com> Date: Tue Nov 27 01:08:08 2018 +0330 First Commit

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

برای هر لیست از کامیت‌ها می‌تونید اطلاعاتی مثل آی‌دی کامیت، نام کسی که کامیت کرده، تاریخ کامیت و پیغام کامیت رو مشاهده بکنید.

حالا برای اینکه جزئیات کاملتری از هر کامیت رو ببینیم کافیه از دستور git show همراه با آی‌دی کامیت مورد نظر استفاده بکنید:

git show 652264

commit 6522647a9fa63906d2216d505b8c9578de30ba97 (HEAD) Author: Arastoo test@test.com> Date: Tue Nov 27 01:31:24 2018 +0330

Second Commit

diff –git a/index.html b/index.html new file mode 100644 index 0000000..557db03 — /dev/null +++ b/index.html @@ -0,0 +1 @@ +Hello World

یه دستور کاربردی دیگه هم که می‌تونیم ازش استفاده بکنیم دستور diff هستش که میاد تغییرات و تفاوت‌های بین دو کامیت رو بررسی می‌کنه. برای اینکار کافیه آی‌دی دو کامیت رو داشته باشیم:

git diff 6522..9a83

شاید خروجی دستور براتون پیچیده باشه، بجای اون می‌تونید از ابزاری مثال git difftool استفاده بکنید.

5- بازگشت به نسخه قبلی

خب یکی از هدف‌هایی که ما از استفاده گیت داریم اینه که به ما کنترل خوبی رو روی مدیریت نسخه‌های مختلف یه پروژه بده. خب برای اینکار ما از دستور git checkout استفاده می‌کنیم. قبلا از این دستور برای کنترل برنچ‌ها هم استفاده کردیم.

حالا تصور کنید که من می‌خوام فایل index.html رو به اولین کامیتی برگردونم که کردم. یعنی همون کامیت inital … برای اینکار کافیه آی‌دی کامیت و آدرس index.html رو داشته باشم:

git checkout 6522 index.html

حالا اگه محتویات index.html رو بررسی کنیم می‌بینیم که خالیه یا همون چیزی داخلش قرار داره که توی کامیت اول نوشتیم.

حالا موضوع مهم اینه که اگه من git log رو وارد کنم هنوز هم با کامیت‌های جدیدتر برخورد می‌کنم و می‌تونم به اونا برگردم. گیت فوق العاده‌س ?

6. تغییر در یک کامیت

اگه توی آخرین کامیتی که کردید یه اشتباهی توی نوشتن پیامش کرده باشید چیکار می‌کنید؟ خب شاید بگید برمی‌گردم عقب یه کامیت جدید میزنم و… . خب این کار منطقی نیست. برای یه تغییر سریع روی کامیت ما دستور git commit –amend رو در اختیار داریم که به ما اجازه می‌ده تا پیغام آخرین کامیت رو اصلاح کنیم.

اما اگه مشکل کمی پیچیده‌تر باشه و بخوایم به یه کامیت منحصر به فرد دسترسی داشته باشیم چی؟

خب برای اینکار کافیه دستور revert رو همراه با آی‌دی کامیت وارد کنیم:

git revert 6522 # or git revert HEAD

HEAD به آخرین کامیتی که شده اشاره می‌کنه.

7- حل کردن Merge conflicts

تصور کنید که یک برنچ جدید ایجاد کردید و فایل قرار گرفته در برنچ قبلی رو در این برنچ تغییر دادید. حالا به برنچ master برمی‌گردید و عملیات مرج رو انجام می‌دید. اما با یه مشکل بر خورد می‌کنید:

Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.

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

حالا برای حل این مشکل می‌تونید به صورت دستی وارد عمل بشید. چطوری؟ خب فایل index.html رو باز کنید: می‌بینید که کلی تغییرات توش اعمال شده:

HEAD Hello World ======= Hello Again >>>>>>> new

در واقع گفته که شما در آخرین کامیت که HEAD آدرسشه نوشتید: Hello World اما در برنچ جدید که اسمش New هستش نوشتید Hello Again … من کدومشون رو نگه داری کنم؟

اینجاست که نیازه به صورت دستی وارد کار بشید و کدهای مربوط به برنچی که می‌خواید رو بزارید و مورد دیگر رو حذف کنید. در آخر هم git add index.html و git commit.

8- .gitignore

بعضی وقت‌ها در یک پروژه قصد این رو ندارید که بعضی از فایل ها و دایرکتوری‌ها رو کامیت بکنید و یا اونا رو به استیج ببرید. خب شاید بگید که توی git add اسمی ازش نیاریم ولی خب ما وقتی پروژه بزرگی داشته باشیم بیشتر وقتا از git add -A استفاده می‌کنیم. اما اگه بخوایم همین دستور هم یه سری فایل ها رو شامل نشه از یه فایلی به اسم .gitignore استفاده می‌کنیم.

کافیه که یه فایل با نام .gitigonre درست کنید و تموم مواردی که نمی‌خواید گیت اونا رو استیج بکنه درش قرار بدید. مثلا:

*.log build/ node_modules/ .idea/ my_notes.txt

در این حالت فایل‌هایی با پسوند .log، تمام محتویات دایرکتوری‌های build, node_modules,.idea و فایل my_notes.txt در مخزن گیت شما قرار نمی‌گیرند.

در پایان

برای پیشرفت کردن در این موضوع می‌تونید از لینک‌های زیر استفاده بکنید. و همچنین سراغ دوره آموزش رایگان گیت و گیت هاب در وبسایت راکت بروید.