نوشته های نیما هاشمی

اتوماتیک گیت بای سکت یا چگونه با دو نیم کردن اتوماتیک از سکته جلوگیری کنیم

نیما هاشمی — Mon, 01 May 2017 14:41:17 +0430

وقتی پروژه، محصول و تیم ها رشد می‌کنند، به همون اندازه پیدا کردن مشکلات و خطاهای کدها سخت تر میشه. تا جایی که بعضا دیده شده باگ هایی سهمگین موجب حملات قلبی عروقی سازمان‌یافته به مسئولین سالم نگه‌داشتن پروژه شده است. احتمالا چیزی نزدیک به همه تیم هایی که می‌شود ارزش سر آنها را بر تنشان سنجید، از مکانیزم های کنترلی، تست های فراوان، CI و … استفاده میکنند و کمتر با این مشکلات مواجه می‌شوند. امیدوارم برای شما پیش نیاد.این مقاله یک بحث فنی در مورد گیت است و در مورد یکی از امکاناتش برای یافتن کامیت مشکل دار در بین انبوهی از کامیت ها. git bisectتصور کنین یک merge عظیم داشتید و بعد از صدها کامیتِ اعضای مختلف تیم، بیلد شما Fail بشه.(خوش بینانه اگه از CI استفاده میکنید فکر میکنم نمیذارید کار به اینجا برسه و واقعا پروسه کاری شما continuos هست. اصولا تو یه تیم منظم که دائم چند بار در روز پوش و مرج میکنن خیلی این اتفاق نادره ولی همیشه همه چیز منظم پیش نمیره. این بحث که در شرایط عادی و آروم این اتفاق نمیفته و نباید بیفته کاملا درسته ولی دونستن این روش ممکنه یک روز نجاتتون بده)ممکنه پیدا کردن کامیت با بررسی تک تک اون ها از بالا(!) اولین راهی باشه که به ذهن شما برسه. این یک سرچ خطیه و احتمالا میدونید هزینه یک سرچ خطی چقدر بالاست خصوصا توسط یک انسان که باید یک باگ رو پیدا کنه. اگه تو علوم کامپیوتر و الگوریتم دستی داشته باشید باید حدس زده باشید که راه حل یک سرچ باینریه.حتما میدونید که سرچ باینری تو یه مجموعه با هر بار نصف کردن مجموعه و مقایسه جستجو رو محدود تر میکنه تا اینکه با چند پرش به نقطه مورد نظر برسه. چقدر خوب. شما به جای بررسی ۲۰۰ تا کامیت اگه اون ها رو باینری بگردید میتونید با مثلا هفت هشت پرش کامیت مورد نظرتون رو پیدا کنید. شما واقعا تو این حالت نمیدونید کامیت مشکل دار سَرِ هیستوریه یا تهش.خب این ایده قبلا به فکر توسعه دهنده های گیت رسیده و ابزاری رو برای گشتن لابلای کامیت ها توسعه دادند به نام git bisect که کارش دقیقا همینه.ساده ترین نوع استفاده از این ابزار به صورت دستی به ترتیب زیره.گیت bisect رو شروع کنید# git bisect startیه revision بد (خراب، شکسته، معیوب، باگی، گیت بهش میگه بد) معرفی کنید. مثلا HEAD# git bisect bad {your bad revision}یک revision سالم معرفی کنید (مثلا آخرین کامیتی که تو مستر قبل از مرج وجود داشت یا تگ ریلیز قبلی)# git bisect good {your good revision}حلقه bisect شروع میشه. حالا گیت میره به یک کامیت که از طریق باینری سرچ نوبتش شده باشه.شما میتونید اینجا اون کامیت رو تست و بیلد کنید ببینید تا اینجای اوضاع چطوره. بعدش به گیت بگید که مشکل هنوز وجود داره یا نه. با این کامند ها# git bisect good# git bisect badگیت مجددا تو بازه محدودتری سرچ میکنه و با راهنمایی شما کامیت مورد دار رو پیدا میکنه و نشونتون میده! اینجا با یه git show {commit ref} شما اون کامیت رو بررسی میکنین و مشکل رو حل میکنین. به همین سادگی و مجیکالی!خب اینجا اگه کد های شما چیز قابل ارائه تو کنسول باشه مثلا خروجی یه build یا unit test میشه این فرآیند رو automate کرد.امیدوارم تست هاتون پوشش (coverage) قابل اتکایی داشته باشن. اصولا bisect نیاز به یه کاوریج خیلی خوب داره.سکته یاب دو نیم کننده اتوماتیکبرای اتومِیت کردن این فرایند شما به یک اسکریپت احتیاج دارید که بیلد و تست شما رو انجام بده.برای شرح ساده ترین حالت فرض کنید من با node.js یک اپلیکیشن نوشتم که با استفاده از npm و این کامند اون رو تست می‌کنم:npm testو تسک رانر npm مثلا برای من تست های mocha رو اجرا میکنه و خروجی اون رو تو ترمینال نشون میده.یه مشت خروجی که اگه توش کلمه Failed وجود داشته باشه یعنی تست ناموفق بود و اگه نه هم که تست موفقه. این اسکریپت یه حالت خیلی سادست.بعد از اون شما باید با Shell exit code ها آشنا باشید که بتونید از اون ها استفاده کنید. ساده ترین حالت اون exit کد 0 هست که به معنی موفقیت اسکریپت بیلد یا تست شماست و هر کد دیگه ای نشون دهنده ی خطا.من با گِرِپ کردن خروجی npm test خودم و گشتن دنبال کلمه fail به اسکریپت میفهمونم که تست موفق بوده یا نه. شما میتونید از هر مکانیزم و روشی برای این کار استفاده کنید.کد نمونه چیزی شبیه اینه:#!/usr/bin/env bash # Build and grep for failure output. Replace with your own command. npm test 2>&1 | grep 'failed' # Retrieve the exit code of the grep. if [ "$?" -eq "0" ]; then #echo "Fail found." exit 1 else #echo "Fail not found." exit 0 fi بعد از نوشتن لاجیک تست خودتون، از این کامند استفاده کنید: # git bisect start {bad revision} {good revision} # git bisect run {path to your script}گیت هر بار اسکریپت شما رو ران میکنه و با توجه به اون نتیجه براتون کامیت مشکل دار رو پیدا می‌کنه.احتمالا راه های ساده تری برای استفاده از git bisect تو چرخه CI خودتون وجود داره. اگه فکر میکنید چیزی نیازه در تکمیل این متن یا در ادامه منتشر بشه، با ما در تماس باشید!

گیت Rebase به زبان ساده

نیما هاشمی — Wed, 05 Apr 2017 04:01:35 +0430

گیت ریبیسدر طی سال های اخیر بعد از درک این‌که WorkFlow یا جریان کاری در سورس کنترل چقدر در کار تیمی اهمیت داره، به تمام اطرافیانم توصیه میکردم و میکنم که از فلو مناسب برای گیت استفاده کنند. ورک فلو یک قرارداده بین افراد تیم برای یکسان بودن سیاست برنچینگ.برنچینگ در نهایت برای ترکیب شدن کارها به git merge یا git rebase منتهی میشه.اخیرا شاهد بحثی در شبکه های اجتماعی بودم با این مضمون که خیلی از توسعه دهنده های اطرافمون به درستی از مفهوم git rebase استفاده نمی‌کنند. شاید به دلیل اینکه مفهوم اون رو درست متوجه نشدند و یا نیاز اون رو حس نکردند. حتی خودم چون در فلویی که استفاده میکنم rebase وجود نداره خیلی از این قابلیت مفید و کاربردی استفاده نمیکردم. با این حال این متن کوتاه رو نوشتم تا در حد سوادم بتونم این مفهوم رو در ساده ترین حالت تشریح کنم.برای بهتر نوشتن از این مفهوم از چند مقاله الهام گرفته شده است که بهتر و ساده تر از من این مساله رو مطرح کردند.از اینجا و اینجا میتونین اصلشون رو ببینینتوجه کنید که برای خوندن این مقاله لازمه با گیت آشنا باشید و مفهوم برنچ ها رو درک کنید.گیت مرج و ریبیس یک هدف مشترک دارن که ترکیب چند Branch توسعه است. اگرچه هدف نهایی مشترکه، مرج و ریبیس مسیر های مختلفی رو برای رسیدن به این هدف طی میکنن، خروجی مشابه البته با ردپایی متفاوت.در ادامه از یک مخزن (repository) نمونه با دو برنچ جدا از هم master و feature استفاده خواهیم کرد و به جای هش کامیت ها از عدد برای درک بهتر استفاده میکنیم، علاوه بر اون ترتیب شماره ها ترتیب زمانی کامیت ها هم محسوب میشه به این صورت که عدد کوچکتر به معنی زودتر کامیت شدنه. +--3--5 master | 1--2--+ | +--4--6 featureگیت مرج git mergeهر مرج یک کامیت جدید است. این اصلی ترین چیزی است که باید به خاطر داشت. همزمان دلیل علاقه خیلی از توسعه دهنده ها کامیت بودن merge، دلیل نفرت خیلی از توسعه دهنده ها [ی گاها وسواسی :| ] دیگه است. در هر حال هر مرج یک کامیت است با یک تفاوت که هر کامیت مرج دو parent دارد. همه کامیت های معمول تنها یک parent دارند. چطوری بررسی کنیم؟ ترمینال رو آتیش کنین [وفاداری به متن اصلی :)) ] و git status بگیرین. دو خط اول رو برای مرج میبینید؟commit 7777777777777777777777777777777777777777 Merge: 5555555 6666666 Author: Nima Date: Thu Nov 3 10:11:27 2071 +0100 Merge branch 'feature' into master. +--3--5--+ | | 1--2--+ +--7 | | +--4--6--+خب یک مرج انجام شده و اگه شما git log روی برنچmaster بگیرین، یک خروجی خطی به این ترتیب میگیرین:7 6 5 4 3 2 1به ترتیب تاریخ. البته باید گفت که این فقط ظاهر قضیه است. زیر کار(!) تاریخچه این کامیتها خطی نیست. یعنی اگه شما به کامیت 5 چک آوت کنید و لاگ بگیرید هیستوری ای که میگیرید به این ترتیب هست :5 3 2 1کامیت 4 یک child از 5 یا parent کامیت 3 نیست. پس تو خروجی نمیبینیمش.fast-forward mergeتنها حالتی که مرج کردن باعث ساختن کامیت جدید نمیشه، مرج fast-forward هست.وقتی این حالت اتفاق میفته که کامیت دیگه ای تو برنچ‌های دیگه وجود نداشته باشه.Before 1--2--+ master | +--3--4 feature After 1--2--3--4 master/featureگیت ریبیس git rebaseریبیس ایجاد مجدد کاریه که شما رو یه برنچ انجام دادید رو برنچی که میخواید باشن. یعنی به ازای کامیت هایی از شما که در برنچ feature که تو master وجود ندارن کامیت جدید بالای کار ایجاد میشه. یک بار دیگه به آرومی بخونین: کامیت جدید به ازای هر کامیت قدیمی با همون تغییرات.وقتی شما به برنچ feature چک اوت کنین و به مستر ریبیس کنین این چیزیه که اتفاق میفته +--3--5 master | 1--2--+ | +--3--5--7--8 feature (4)(6)ریبیس کامیت های ۴ و ۶ رو پاک میکنه، با گرفتن تغییرات ۳ و ۵ با master سینک میشه و (اون جمله که آروم خوندین رو یادتون بیاد) کامیت جدید به ازای هر کامیت قدیمی با همون تغییرات ایجاد میشه.تو مثال بالا کامیت ۷ با همون تغییرات کامیت ۴ و کامیت ۸ با همون تغییرات کامیت ۶ اضافه میشن. بدین ترتیب برنچ feature همه تغییرات master رو داره به علاوه تغییرات خودش.حالا بعد از یک fast-forward merge بی دردسر شما همچین چیزی خواهید داشت:1--2--3--5--7--8 master/featureحالا git log به شما این خروجی رو میده :8 7 5 3 2 1با این تفاوت که تاریخچه کامیت ها هم به همین ترتیب خطیه و با چک اوت کردن به عقب چیزی که نباید گم شه گم نمیشه.درنهایت کجا merge کنیم کجا rebase ؟ همونطوری که میشه حدس زد و ابتدای مقاله اشاره شد به ورک فلو توافقی تیم بستگی داره. اما به این نکته ها رو توجه کنید:ریبیس کنید وقتی:میخواید تغییرات لوکال خودتون رو مرج کنید و نیازی به تاریخچه دقیق ندارید پس چرا باید با کامیت های اضافه merge کثیفش کنید؟هیستوری خطی براتون مهمه و از git bisect زیاد استفاده میکنیندارین رو یه فیچری کار میکنین که خیلی طول کشیده و تیمتون تو برنچ های دیگه کیلومترها ازتون جلوترن و کار شما بعد مرج چون کامیت های قدیمی تری هستن ممکنه بالای هیستوری نباشن و شما یا هم تیمی هاتون وقتی pull میکنن گمشون کنین. در صورتی که حالت معقولش برای همه اینه که چون تغییرات جدیدی هستن باید بالاتر باشن که کسی سورپرایز نشه.مرج کنید وقتی:شما یه قسمت از تغییراتتون رو با بقیه به اشتراک گذاشتید و مهمه که ریپو های اون ها رو نترکونید. ریبیس کلی از هیستوری رو تغییر میده و مرج ساده امن تر و واسه بقیه قابل فهم تره.شما واقعا به تاریخچه دقیق اهمیت میدین و میخواین که هیستوری مرج ها و کامیت ها دقیقا به همون ترتیب و جزئیات وجود داشته باشه.پس چرا مردم از ریبیس کردن میترسن؟بر اساس تجربه شخصی و مشاهده کامیونیتی، نگرانی توسعه دهنده ها نسبت به ریبیس کردن از اینجا ها ناشی میشه:به خاطر مکانیزم git rebase عموما کانفلیکت های بیشتر و سخت الرفع (!)تری تجربه میشهتجربه قبلی از دست دادن کار به خاطر بی دقتی تو interactive rebase ویا force pushچه کنیم نترسیم ؟ (نصایح الربایس)زود به زود کامیت و ریبیس کنین تا برنچتون خیلی عقب نیفتهاگه وسطش به کانفلیکت خوردین فیکس کنین و git rebase --continue کنین ریبیس بدون تغییر مسیر ادامه پیدا میکنه. البته اینجا مرج کامیت به وجود میاد که چیز لازمیه چون حل کردن کانفلیکت جزو تاریخچه استاگه کانفلیکت انقدر فجیعه که از ریبیس کردن پشیمون شدین میتونینgit rebase --abortکنین و شما رو برگردونه اول جایی که ریبیس کردینپول کردن با ریبیس هم ممکنهgit pull --rebaseبا ریبیس کردن شما میتونین کامیت هارو پاک کنین. چندتا کامیت رو یکی کنین و مسیج های کامیت ها رو تغییر بدین این کار بهتون قدرت تغییر گذشته رو میده و یادتون نره هر تغییری در گذشته ممکنه باعث ایجاد پارادوکس بشه. هیچ وقت پدربزرگتون رو قبل از بدنیا اومدن پدرتون نکشین!با تاریخچه بقیه هم ور نریناگه فورس پوش میکنین هرگز هیچوقت فورس پوش تو ریموتی که بقیه دارن روش کار میکنن نکنین مگه اینکه اولا دقیقا بدونین دارین چیکار میکنین و دوما از تک تکشون رضایت نامه کتبی گرفته باشید :|در نهایت همونطور که اول مقاله اشاره کردم معمولا ریبیس تو فلوی کاری من جایی نداشته و حتی سعی میکنم ازش استفاده نکنم ولی اونقدر خودم رو صاحب نظر نمیدونم که برای کسی تصمیم بگیرم.