مقدمه خاصی نمیخوام اضافه کنم به این متن فقط میخوام که با روش ترجمه آشنا بشید. من توی این ترجمه تلاش کردم تا جایی که میشه به متن کتاب پایبند باشم و مو به مو ترجمه روان که نزدیک به محاوره است انجام بدم اما خوب بعضی از اصطلاحات انگلیسی معادل فارسی مستقیم نداره مخصوصا زمانی که با یه متن تخصصی سر و کار داریم. بنابراین گاها مجبور شدم تا از متن فاصله بگیرم تا موضوع قابل فهمتر باشه، بعلاوه همزمان هم از اصطلاح انگلیسی و تخصصی استفاده کنم هم معنی لغوی کلمات رو بیارم. برای همین سعی کنید متن رو با آرامش و دقت بخونید من هم سعی میکنم علاوه بر متن دقیق کتاب خودم هم نکاتی رو برای درک بهتر موضوع اضافه کنم تا مفاهیم بطور کامل جا بیوفته. هر جایی که احساس کردید متن و اصطلاحات گنگ و تخصصی شد یکم بهم زمان بدید و یکی دو خط رو دنبال کنید تا به توضیحاتی که خودم اضافه کردم برسید. قول میدم تمام تلاشم رو کنم تا موضوع رو ساده توضیح بدم. اگه متن هم مشکلی داشت یا مشکلی دیدید چه از نظر لغوی چه ساختار جمله بندی یا هر چیز دیگه بهم پیام بدید تا اصلاحش کنم.
در نهایت ممنون که وقتتون رو بهم دادید و امیدوارم این ترجمه بتونه کمکتون کنه.
خوب وقتشه که شروع کنیم...
یه سوال خوب برای شروع میتونه این باشه که
مدیریت سورس کد چیه؟
Source Code Management یا SCM رو میشه اینطوری تعریف کرد: فرآیند زیر نظر گرفتن و مدیریت تغییرات یه سورس کد یه محصول نرم افزاری.
خوبه که بدونید Source Code Management و Version Control هر دو به یک چیز اشاره میکنه. که به زودی باهاشون آشنا میشیم. فقط باید حوصله داشته باشید و یکم به این کتاب وقت بدید
علاوه بر اسامی بالا ممکنه تو حوزه نرم افزار با کلمات دیگه ای هم برخورد کنید که همه این ها میتونن به جای همدیگه استفاده بشن، اسامی مثل: SCM ، VCS ، Source Control ، Version Control ، Revision Control و غیره...
Version Control خودش میتونه معنا و کاربرد گسترده تری داشته باشه - مدیریت نسخهها یا تغییرات هر چیزی. یکی از مهمترین کاربرد های سیستم های مدیریت نسخ (version control ها) میتونه زیر نظر گرفتن و مدیریت تغییرات یک کشور باشه.
بطور کلی در سیستمهایی که یه تغییر خیلی کوچیک میتونه بر اجزای دیگه سیستم تاثیر بذاره، مدیریت و زیر نظر داشتن تغییرات خیلی مهمه. اینکه چه کسی تغییرات رو اعمال کرده، در چه زمانی این تغییرات رو ایجاد کرده و لیستی از تغییرات اعمال شده میتونه دید کامل و دقیق از تغییراتی که بوجود آومده بهمون بده.
شاید برای ما شاید مسخره باشه ولی گاها این اتفاق افتاده که قانونگذارها کلی زمان گذاشتن برای بحث راجب بندی از قانون که بعدا متوجه شدن دارن راجب نسخه قدیمی از قانون بحث میکنن و وقتشون رو هدر دادن، فقط به خاطر اینکه نتونستن تشخیص بدن که نسخه قانونی که به بحث گذاشتن تغییر کرده.
از همین نوع مشکلات رو هم میشه توی توسعه نرم افزار دید - یک یا چند دستور در کد ممکنه تغییر کنه، حتی تغییر یه کاراکتر توی یه ماژول میتونه مشکلات زیادی رو توی همون ماژول یا رفتار ماژول های دیگه و نهایتا توی کل سیستم ایجاد کنه.
برنامه نویسها میتونن وقت زیادی رو به بحث کردن، دیباگ کردن و نهایتا رفع مشکلات یه نرم افزار صرف کنن، از دست دادن زمان ارزشمند، خیلی ساده بخاطر اینکه نمیتونن تغییراتی که باعث ایجاد اختلال در code-base شده رو revert کنن (تغییرات رو برگردونن به حالت قبل)
این فقط در خصوص برگردوندن - revert - تغییرات نیست. داریم راجب انعطاف و توانایی جلو رفتن، عقب رفتن در خط زمانی توسعه نرم افزار و یا جدا کردن یه تغییر خاص در این خط زمانی صحبت میکنیم. تا بتونیم با وصل کردن تغییراتی که روی سورس نرم افزار میدیم توسعه و نگهداشت اش رو مدیریت کنیم. این امکان زمانی بیشتر معنا پیدا میکنه که یه تیم از افراد روی یک سورس کار کنن. اگه برای این کار یه ابزار داشته باشیم بهمون اجازه میده افراد راحتتر با هم ارتباط برقرار کنن و با هم کار کنن.
این دقیقا همون شرایط و نیازمندی بود که نهایتا باعث شد تا در سال ۱۹۷۲ اولین سیستم مدیریت سورس کد تولید بشه.
مشکل خیلی مشهوده ولی بیاید با یه سناریو خیلی ساده شروع کنیم. فرض کنید که یه سرور داریم که روی اون سورس محیط عملیاتی (production) نگهداری میشه، چند تا برنامه نویس هم عضو تیم هستن و قراره با هم روی اون سورس کد کار کنن. قراره به اون محصول نرم افزاری ویژگی جدید (feature) اضافه کنن یا باگ های احتمالی رو رفع کنن.
توی بهترین و خوشبینانه ترین حالت ممکن هر کدوم از افراد دارن روی یه ویژگی کاملا مجزا کار میکنن و هیچ کدوم از اعضای تیم برای انجام وظایفهاش یک فایل یکسان رو تغییر نمیده. یعنی این تغییرات اونقدری از هم مجزا است هیچ دو نفری قرار نیست روی یه فایل تغییر ایجاد کنن.
توی این حالت (که واقعا خیلی خوشبینانه است) هر کدومشون باید فایل هایی که تغییر دادن رو به سرور انتقال بدن، و با این کار همه چیز درست میشه، همه چیز خوب مدیریت میشه و مشکلی پیش نمیاد.
حالا بیاید یه کمی واقعبینانه به موضوع نگاه کنیم. سناریو محتمل تری رو در نظر بگیریم، اگه دو نفر از این افراد برای انجام وظایفشون مجبور بودن دقیقا روی یک فایل کار کنن و تغییرش بدن چه اتفاقی میوفته؟! (هیچ کدومشون هم نمیدونن که اونیکی هم داره روی اون فایل کار میکنه)
در این شرایط یه مسابقه پیش میاد، تغییرات اون کسی که فایلش رو آخر به سرور انتقال میده به عنوان تغییرات نهایی شناخته و اعمال میشه. در واقعا اون تغییراتی که آخر از همه به سرور انتقال داده میشه تغییرات قبلی رو بازنویسی میکنه و فایلش رو جای فایل قبلی میذاره بدون اینکه بدونه نفر قبلی تغییراتی رو در فایل اعمال کرده.
اینجا دوتا مشکل وجود داره:
وجود این مشکلات باعث شد تا اولین سیستم مدیریت سورس کد یا SCCS (Source Code Control System) ایجاد بشه. این سیستم توسط فردی به نام Marc Rochkind در شرکت IBM توی سال ۱۹۷۲ ایجاد شد و زیربنای تمام سیستم های مدیریت سورس امروزی رو ایجاد کرد.
در طی زمانش سیستم های زیادی تولید شدن برای اینکه مشکلات گفته شده رو حل کنن و یکی از اونها هم Git بود که کاربران زیادی داره و به عنوان یکی از محبوب ترین VCS ها بین توسعه دهندگان در سراسر جهان شناخته میشه.
گیت سال ۲۰۰۵ توسط Linus Torvalds ساخته شد. هدف از تولید Git هم این بود که جایگزین version control system ای بشه که سورس کد کرنل یا هسته سیستم عامل لینوکس روی اون قرار داشت. از اونجایی که در VCS ای که سورس کد لینوکس چند تا مشکل توی کارکرد گروهی داشت بعلاوه قرار بود این ابزار مدیریت سورس کد دیگه رایگان نباشه.
لینوس توروالدز وقتی دید که version control system های دیگه هم نمیتونه نیازمندی های مد نظرش رو تامین کنه، تصمیم گرفت VCS خودش رو توسعه بده. ۱۰ سال بعد توی این مصاحبه توضیح میده که چرا Git متولد شد و دقیقا چه Version Control Source ای نیازمندی مورد نظرش رو جواب میداد و تصمیم هایی که باید میگرفت صبحت میکنه.
گیت به عنوان یه distributed version control system (به فارسی: سیستم مدیریت تغییرات توزیع شده) شناخته میشه. برخلاف centralized VCS (به فارسی: سیستم های مدیریت تغییرات متمرکز) VCS های توزیع شده تغییرات ایجاد شده روی سورس کد رو روی یه repository (مخزن نگهداری سورس رو repository میگن) نگهداری نمیکنن، بجاش روی کامپیوتر هر برنامه نویس دقیقا یه کپی از سورس با همه تغییرات و تاریخچه تغییراتش رو روی هارد درایوش نگهداری میکنه.
استفاده از VCS های توزیع شده مزایا و معایب خودش رو داره. مزایایی که برای استفاده از version control system های توزیع شده میشه نام برد خیلی شبیه بقیه سیستم هاییه که از توزیع داده برای نگهداشت اطلاعاتشون استفاده میکنن:
گیت - Git با استفاده از دو محیط این موارد رو برطرف میکنه: محیط Local و محیط Remote.
محیط Local هم خودش به سه بخش تقسیم میشه:
- working directory
- staging area
- local repository
ریپازیتوری - repository (به فارسی: مخزن) چیزی نیست جز یه مسیر (directory) یا به اصطلاح کسایی که از سیستم عامل ویندوز استفاده میکنن پوشه (folder) که Git تمام تغییرات رو در اون نگهداری میکنه.
وقتی که دارید روی کد اتون کار میکنید در حقیقت شما دارید روی working directory کار میکنید. شما معمولا محتوای فایل ها رو با استفاده از IDE (محیط و ابزارهای توسعه نرم افزار) تغییر میدید و اجرا میکنید. زمانی که با تغییراتی که اعمال کردید راضی بودید یعنی کارتون که تموم شد، میتونید تغییرات داده شده روی فایل ها رو add کنید به staging area.
staging area محیطی است که تغییراتی که آماده commit هستن رو نگهداری میکنه. اگه یه فایلی رو به staging area اضافه کرده باشید و دوباره تغییری روش اعمال کنید، اون فایل بصورت اتوماتیک از staging area خارج میشه یا اصطلاحا unstaged میشه.
شما میتونید بارها این کار رو انجام بدید یعنی یه فایل رو تغییر بدید، به staging area اضافه اش کنید و دوباره تغییر بدید و .... و البته که میتونید این کار رو با فایل های زیادی انجام بدید و محدودیتی در تعداد فایلی که تغییر کرده وجود نداره. خلاصه اینقدر تغییرات انجام میدید که به نتیجه دلخواهتون در کدهای پروژه میرسید. تا اینجای کار همه تغییرات فقط در working directory و staging area بوده، حالا که به نتیجه نهایی رسیدید میخواید تغییرات خودتون رو ثبت کنید. برای این کار شما باید تغییراتی که نهایی شده رو از staging area به local repository ارسال کنید. به انتقال فایل هایی که روشون تغییرات داشتید از staging area به local repository اصطلاحا commit کردن گفته میشه.
حالا وقت جواب دادن به این سواله که local repository چیه؟ local repository یه کپی تمام و کمال از remote repository روی سیستم شخصی شما هستش که شما و بقیه اعضای تیم اتون روش کار میکنید. وقتی که از نرم افزارتون یه خروجی گرفتید و اطمینان داشتید که همه چیز مرتبه و همه کارهایی که قرار بود انجام بدید، تموم شده، میتونید تغییرات رو از محیط local خودتون push (ارسال) کنید به remote repository.
نگران هیچ کدوم از این اصطلاحات نباشید همه اون ها رو توی فصل های بعدی با جزئیات توضیح میدیم.
بیاید ببینیم گیت چطوری تاریخچه تغییرات رو نگهداری میکنه. فرض کنید Git یه دوربین عکاسیه، زمانی که شما اطمینان پیدا کردید که پروژه اتون در وضعیت دلخواه است بهش دستور میدید تا یه تصویر کامل از وضعیت فعلی کل پروژه بگیره. پس یادتون باشه که Git صرفا تغییرات رو دنبال نمیکنه. گیت هر بار وضعیت کل فایلها رو (چه تغییر کرده باشن چه تغییری نداشته باشن) نگهداری میکنه.
هر بار که شما یه فایل رو تغییر میدید و اون تغییر رو commit میکنید (ذخیره اش میکنید روی گیت یا ازش یه تصویر میگیرید) وضعیت جدید اون فایل به همراه تمام فایل های دیگه در اون لحظه ذخیره میشه. اگه شما دوباره روی همون فایل دوباره تغییر بدید و تغییرات رو commit کنید در این شرایط شما سه تا نسخه از اون فایل دارید: نسخه اولیه که اصل فایل بوده، نسخه دوم که اولین تغییر رو commit کردید و نسخه سوم که تغییرات دفعه دوم رو اعمال کردید. حالا اگه در کنار این فایلی که تغییر اش میدادید یه فایل دیگه هم بود، توی هر نسخه وضعیت فایل تکرار میشد و اینطوری به ازای هر نسخه دقیقا وضعیت همه فایل ها توسط گیت نگهداری میشه. برای اینکه موضوع یکم شفاف تر بشه به جدول زیر نگاه بندازید:
توی این سناریو، File1 هیچ وقت تغییر نمیکنه. و وضعیت اش توی هر سه نسخه دقیقا یکسان باقی میمونه. File 2 هر بار تغییر مرده و File 3 فقط یک بار تغییر کرده، یعنی از نسخه ۲.
هر کدوم از این فایل ها تاریخچه تغییرات خودشون رو دارن و هر تغییر به ترتیب تغییرات پروژه است (یعنی مشتقی از زمان هستش). هر کدوم از این نسخه ها در یه زمان مشخص گرفته میشن. بنابراین میتونیم یه خط زمانی رو متصور بشیم از تغییرات پروژه در گذر زمان که در هر لحظه که تغییرات رو ذخیره کردید وضعیت تمام فایل پروژه رو در اون لحظه دارید. این موضوع به شما این قابلیت رو میده که بین نسخه ها به راحتی جلو یا عقب برید هر چقدر که لازم باشه و دلاتون بخواد و بر خلاف بقیه ابزار ها مجبور نیستید که برای رسیدن به یه نسخه خاص دونه دونه نسخه ها رو به عقب برگردید تا به تغییراتتون در زمان مناسب مورد نظر برسید. اما این قابلیت به همیجا خلاصه نمیشه، شما میتونید تغییرات یه فایل رو در نسخه ۳ داشته باشید و فقط تغییرات یم فایل رو به نسخه ۱ برگردونید.
اما این ویژگی خالی از اشکال نیست و معایبی هم داره. وقتی که دارید با فایل های بزرگ (حجیم) کار میکنید نگهداری یه نسخه کامل از فایل تغییر داده شده میتونه فضای زیادی رو اشغال کنه. شاید اولش اینطور به نظر نرسه و هر فایل هم اونقدری بزرگ نباشه که نگرانش باشید. اما فکر کنید که فایل هایی با حجم بالا و تعداد اعضای زیاد تیم و میزان تغییرات زیاد رو اگه کنار هم در نظر بگیریم اونوقته که حجم تاریخچه فایلها به چشم بیاد. حتی اگه فایلها اونقدری بزرگ نباشن، میتونه باعث بشه تا مدت زمان دانلود تاریخچه طولانی بشه.
