بیا Git ات رو قورت بده ;) (قسمت اخر)

خب سلام ، از اینکه الان تو قسمت سوم این سری مقالاتی ، منکه خیلی ذوق زدم خودتم باش ! این قسمت قرار کلی چیزای باحال بگم برات که بعد از یادگرفتنشون تقریبا میشه گفت برای کار تو یه شرکت تا حد قابل قبولی اماده ای =))) . ( البته حواست باشه که git کلی چیزای باحال و خفن دیگه ای هم داره که خودت باید بری یادبگیری :) )

راستی ، سری اول و پایه ای رو میتونی از اینجا و سری دوم رو از اینجا بخونی

پدیده اسکل کننده ی conflict

اخ اخ اخ من به شخصه کلی سر این اسکل شدم که git لعنتی فازت چیه چرا push نمی کنی ؟! و نمی دونمم چرا عین ابله ها نمی رفتم سرچ کنم (از این اموجیای متفکر)

خب ببین یه زمانی هست که داری با چند نفر رو یه پروژه کار میکنی و از قضا همتون دارین رو یه فایل کار میکنید و و اتفاقا همتونم دارین یه تیکه خاص از اون کد رو تغییر می دین =))) ( حالت پت و مت وارانه ایه ولی برات پیش میاد:) ) خب اتفاقی که میافته اینه که اولین نفر به سلامت میاد و کدش رو push میکنه و میره اما نفرات بعدی که میان push کنن git بهشون میگه حواست هست که داری یه conflict سوکسی ای بوجود میاری ؟! و خب تو ممکنه بگی اره =)) اما اون میگه ندیگه نمی شه ! و تو مجبور میشی که اول بری یه pull بکنی و چیزی که بعد از pull تو اون یه تیکه از کد می بینی یه چیزی تو این مایه هاست

<<<<<< HEAD 
       section 1
====== 
       section 2
>>>>>> snt2h1s3n4tnthd9au8d3324

خب تو section 1 اون کدی قرار داره که الان رو کامپیوتر تو هست و نذاشتش که push اش کنی و تو section 2 هم اون کدی هست که الان رو origin (اگر نمی دونی origin چیه ، برو به مقاله اول ) هست حالا تو باید انتخاب کنی که کدوم تیکه رو دوست داری که در اخر رو origin باشه بعدش یا تیکه خودت رو پاک کن یا تیکه ای که الان رو origin هست و البته که اون تیکه هایی که مارک شده رو هم پاک کن بعد push کن و اینکه git یه بچه ی باهوشیه ، اگر شما ها رو یه فایل کار میکردین اما تو قسمتای مختلفش ، این میومد و تغییراتتون رو merge میکرد و این داستانا رو پیش نمی کشید

ناجی ای به نام Tag !

ببین قبلا فک کنم گفتم بهت که یکی از ویژگی های خفن git اینه که می تونی هر وخ که خواستی برگردی به فلان کامیتی که کردی ، از طرفی هم گفتم بهت که شاخای برنامه نویسی توصیه میکنن زیاد کامیت کنید و این ینی ما هروز کلی کامیت میکنیم و مثلا اگر دو هفته بعد بخوایم برگردیم به یه کامیتی که امروز push کردیم سرویس میشیم چون باید همه کامیت ها رو دونه دونه چک کنیم تا برسیم به اونی که مخوایم :///

اصن دوشواری نداریم ! ببین دیدی اپ هایی که میری دانلود میکنی یه عددی دارن به اسم version که هر بار هم به مقدارش اضافه میشه ، خب ما تو برنامه نویسی یه پروژه دقیقا همینو داریم و پروژه به یسری وضعیت از تکامل که میرسه بهش یه عددی نسبت میدیم که همون version یا نسخه میگن ، حالا تو git ما اینکار رو با tag انجام میدیم . و سه سوت می تونی بری به فلان ورژن تا اینکه بخوای دو ساعت کامیتا رو بررسی کنی ببینی میخوای برگردی رو کدوم

به قول فرنگی آ , let's divine into code

برا اینکه لیست تمام tag ها رو بده بهمون بهش میگیم

git tag

حالا فرض کن می خوام بگم الان با این کامیتی که میکنم ، پروژه م رسیده به ورژن 2.0

git tag -a v2.0 -m ''message&quot

حالا یه موقعی هست که میخوای بری عقب و برا یه کامیتی در گذشته یه tag بذاری

git tag -a v1.2.2   هش اون کامیت رو اینجا بنویس   -m &quotmessage&quot

و اگر بخوای ببینی که فلان تگ رو چه کسی گذاشته و رو چه کامیتی هم سوار شده

git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

یه نکته مهم

الان که tag رو گذاشتی اگر همینطوری بگی push ، خب push نمی شه :)))

برا اینکار باید بگی

git push origin --tag
یا
it push origin v2.0

وقت مچگیریه ^-^

یه وقتایی هست که داری به زندگانیت ادامه می دی و یهو میبینی که اوه شت ! برنامه کار نمی کنه یا سرورتون پایینه در صورتی که دیروز همه چی داشت به زیبایی کار میکرد . خب احتمال داره که یکی از contributor های پروژه یه چیزی رو اضافه کرده به پروژه که علت اصلی این فاجعه شده =))

ما در اینجور مواقع میریم پیش git و میگیم که بگو کی گند زده ؟

یا ما میدونیم که bug برا کدوم خط از کدوم فایله که در اینصورت از blame استفاده میکنیم

git blame   پسوند.اسم فایل  -L 112

که جلو L- میای و اون خط مورد نظر رو مینویسی . بعد رسوایی بزرگ اتفاق می افته و تمام کسانی که از اول تا اینجای کار این جا رو کامیت کردن رو بهمون لیستش رو میده

حالا مثلا اگر بخوای بگی از فلان خط تا فلان خط

git blame   پسوند.اسم فایل -L 10,15

اینجا دیگه اکتفا می کنه به اخرین کامیت .

یا ما اصن نمی دونیم برا کدوم خط و کدوم کامیت

اینجاست که زیبارویی بنام bisect میاد کمکمون

اگرچه کار خفنی انجام میده ولی موجودی به غایت ساده و کوچولوعه . کلا سه تا کامند داره start bad good

منطقش خیلی ساده و ادمیزادیه ، براش بازه هایی از کد رو مشخص میکنیم و این هر بار بازه رو کوچیک تر میکنه و ازمون میپرسه که ایا همچنان تو این بازه باگی که دنبالشی هست یا نه که اگر بود میگی bad و اگر نبود میگی good

برا شروع میگی

git bisect start

و چون الان ما باگ داریم بلافاصله بهش میگیم که

git bisect bad

خب بعدش باید بهش بگیم که کجا بوده که باگی توش نبوده و یا درواقع نزدیک ترین جایی که کد ما سالم بوده رو باید از طریق هش کامیتش ، به git اطلاع بدیم

git bisect good   هش کامیت 

بعد شروع میکنه بهت یسری کامیت رو از طریق هش هاشون نشون میده و میگه چک کن ببین خوبه یا نه که صرفا با good و bad براش مشخص میکنی و این کار رو انقدر ادامه میدی تا برسی به منبع فساد !

یه چیز زیبا diff هست

اگر میخوای بدونی که وضعیت الان کد هات نسبت به اخرین کامیت پوش شده چطوریه خیلی ساده مینویسی

git diff head

و اگرم میخوای ببینی اونایی که الان تو وضعیت stage هستن چیاشون عوض شده می تونی بزنی

git diff --staged

مادر همه چی

ببین git خیلی چیز بزرگیه ، و این طبیعیه که چیزیشو بلد نباشی اما خیلی راحت میتونی از

git help

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

git help   اسم دستور

خب اولین سری اموزش های برنامه نویسی من تموم شد ، حس وقتی رو دارم که به تیتراژ اخرین قسمت سریال محبوبم نگاه میکنم :///

ولی قول میدم که ظرف یکی دو روز اینده این بار با اموزش یه زبون زیبا برگردم =)))

اگر با مقاله ها و خودم حال کردی بیا از اینجا باکم رو هر چقد دوست داشتی پر کن =)))))

اول از همه از جناب Linus Torvalds به خاطر ساختن git تشکر میکنیم ، زندگیمون رو زیباتر و راحت تر کردن از جادی هم کلی تشکر میکنم که ویدیو هاش منبع من برا نوشتن این سری از اموزش های git هست و اینکه خیلی خوش حال شدم که نشستی و این مقاله رو خوندی ، لطفا هر سوالی داشتی حتی بدیهی ترین هارو هم بپرس اینجا و اینکه

بخخخخند =)))))