احمد رفیعی
احمد رفیعی
خواندن ۱۴ دقیقه·۵ ماه پیش

در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم)

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

خب یه مروری کنیم پست‌های قبلی رو:

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

Version Control System
Version Control System

ورژن کنترل چیه؟

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


Linus Torvalds
Linus Torvalds

یکم در مورد لینوس توروالدز صحبت کنیم:

لینوس توروالدز (Linus Torvalds) یک مهندس نرم‌افزار فنلاندی-آمریکایی است که به عنوان خالق و توسعه‌دهنده اصلی هسته لینوکس (Linux Kernel) شناخته می‌شود. او در تاریخ ۲۸ دسامبر ۱۹۶۹ در هلسینکی، فنلاند، متولد شد. توروالدز وقتی دانشجوی دانشگاه هلسینکی بود، در سال ۱۹۹۱ شروع به کار روی پروژه‌ای کرد که بعدها به نام "لینوکس" شناخته شد.

توروالدز با ایجاد هسته لینوکس و انتشار آن با مجوز (GPL (General Public License، این امکان را فراهم کرد که سیستم‌عامل‌های مبتنی بر لینوکس توسط جوامع توسعه‌دهندگان در سراسر جهان توسعه پیدا کنن و استفاده شوند. او به عنوان یکی از شخصیت‌های برجسته و تأثیرگذار در جهان نرم‌افزار متن‌باز شناخته می‌شود.

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

”Talk is cheap. Show me the code.”

”Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.”

”Software is like sex: it's better when it's free.”

”In real open source, you have the right to control your own destiny.”

”A computer is like air conditioning – it becomes useless when you open Windows.”

”Intelligence is the ability to avoid doing work, yet getting the work done.”

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Avoiding complexity reduces bugs.

Those that can, do. Those that can’t, complain.

All operating systems suck, but Linux just sucks less.

If you think your users are idiots, only idiots will use it.

حالا دیگه اینکه این جمله هارو واقعا گفته یا نه نمیدونم 🙂 بگذریم.

حالا یکی دیگه از کارهایی که کرده گیت هست!

BitKeeper
BitKeeper

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

اما در سال ۲۰۰۵، به دلیل برخی مشکلات از نظر مالکیت و قوانین استفاده از BitKeeper، لینوس تصمیم گرفت تا یک سیستم کنترل نسخه جایگزین را ایجاد کند. این سیستم باید قابلیت‌هایی مشابه BitKeeper را داشته باشد، اما مهم‌تر از همه، باید به کاربران اجازه دهد به طریقی آزادانه و بدون محدودیت در مورد استفاده و توسعه آن اقدام کنند.

git
git

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

خیلی رزومه باحالی داره. کرنل لینوکس رو نوشتم و گیت رو ایجاد کردم🙃. واقعا دمش گرم. قبلاً خیلی اخلاقش تند بود و تو کامینیوتی معروف به این ویژگی بود ولی الان سنی ازش گذشته و اروم‌تر شده.


git
git

یه تاریخچه‌ی کوتاهی از گیت بگیم:

پیش از گیت، سیستم‌های کنترل نسخه مختلفی وجود داشتند که برای مدیریت کدهای منبع استفاده می‌شدند. در طول زمان، بر خی از این سیستم‌ها از جمله CVS (Concurrent Versions System)، SVN (Subversion)، Mercurial و Perforce بودند. هرکدام از این سیستم‌ها ویژگی‌ها و مزایای خاص خود را داشتند، اما هیچ کدام از آنها به اندازه گیت در پذیرش و استفاده گسترده در جوامع توسعه نرم‌افزاری موفق نشدند.

در سال ۲۰۰۵، لینوس توروالدز (Linus Torvalds)، گیت رو ایجاد کرد. او این ابزار را برای مدیریت کد منبع هسته لینوکس به کار گرفت و به سرعت تبدیل به یکی از محبوب‌ترین و استانداردترین سیستم‌های کنترل نسخه در جهان توسعه نرم‌افزار شد. یکی از ویژگی‌های اصلی گیت، توانایی توزیع شده بودن آن است که به توسعه‌دهندگان امکان می‌دهد که به طور موازی در کدهای منبع کار کنند و بدون نیاز به اتصال مستقیم به یک سرور مرکزی کدهای خود را مدیریت کنند.

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

گیت چیه و چرا لازمه:

گیت یه ابزار کنترل ورژن متن باز و توزیع شده هست که طراحی شده تا از پروژه‌های کوچیک تا بزرگ همه رو با سرعت و کارایی بالا هندل کنه. گیت با تِرَک کردن تمام چنج ها بهمون کمک میکنه تا تعاملات راحت تری رو توی پروژه‌ها داشته باشیم. با استفاده از گیت می‌تونیم به صورت تیمی روی یک کد بیس کار کنیم و کمتر نگران این باشیم که اختلالی تو کار دیگران و خودمون ایجاد شود.


How Git Works
How Git Works

گیت چطور کار می‌کنه؟

یه سری از مفاهیمی که تو گیت هستن رو در ادامه میارم و سعی میکنم لابه‌لای توضیح دادن این مفاهیم بهتون بگم که گیت چطور کار میکنه:

Repository:

گیت با چیزی به اسم ریپازیتوری کار میکنه. ریپازیتوری یک دایرکتوری شامل همه‌ی فایل‌های پروژه هست که داخلش یه زیردایرکتوری به اسم git. وجود داره که متا دیتای مرتبط با تمام تغییراتی که گیت ثبت کرده توی اون ذخیره میشه. دیتای مرتبط با کامیت‌ها، برنچ ها و … توی این زیردایرکتوری ذخیره میشه.

Staging Area:

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

Commit:

حالا که یه سری چنج ها توی استیج داریم میتونیم اونها رو کامیت کنیم. یک کامیت یه جورایی یک اسنپ‌شات از ریپازیتوری ما در یک وضعیت خاص و در یک زمان خاص هست که شامل تمام تغییرات استیج شده ریپازیتوری و مسیج همراه کامیت که اون رو شرح میده، هست. به صورت خلاصه هر کامیت مشخص می‌کنه که چه کسی در چه زمانی این تغییرات رو فرستاده و با مسیجی که می‌تونیم پاس بدیم راهنمایی می‌کنیم که چیو تغییر دادیم و بالا فرستادیم.

Branches:

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

Merging:

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

Remote Repository:

گیت بهمون این امکان رو میده که افراد همکاری کنند روی یک پروژه، به این صورت که میتونن ریپازیتوری هاشون رو به شکل ریموت روی یه سری سرور بذارن و با هم به اشتراک بذارنش اطلاعات رو. از ریموت ریپازیتوری های معروف میشه Github , GitLab و Bitbucket رو نام برد. نرمالی استفاده از گیت به همین صورت است البته می تونیم لوکالی هم داشته باشیم اما معمولا به صورت ریموت استفاده می‌شود.

History:

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

git basics
git basics


مزیت های استفاده از گیت چیه؟

میتونیم تغییرات و آپدیت های پروژه رو رهگیری کنیم و بفهمیم که چه کسی این تغییرات رو اعمال کرده، چه زمانی و به چه دلیلی این تغییرات انجام شدن!

git benefits
git benefits

گیت بهمون این امکان رو میده که به صورت تعاملی کار کنیم و از آنجا که پروژه های نرم افزاری اغلب نیاز به چند فرد دارند که باهم کار کنند، گیت یه راه حل سیستمی ساختارمند و منظم برای این مساله ارائه میده.

گیت همکاری بین افراد رو راحت تر میکنه و این امکان رو میده که تغییرات افراد مختلف روی پروژه، با هم ادغام بشن در قالب یک خروجی واحد.

بررسی ابتدایی دستورات گیت:

git commands
git commands

git init:

نصب گیت خیلی آسونه، اگه نمیدونید یه سرچ ریز بزنید. حالا که گیت رو نصب کردید توی هر مسیری که دستور git init رو بزنید، اون دایرکتوری رو تبدیل کردید به یک ریپازیتوری گیت 🙂

git clone:

یا اینکه میتونید با استفاده از دستور git clone یک ریپازیتوری رو از یک Remote Repository دریافت کنید.

حالا که یک ریپازیتوری دارید، میتونید مثلا تغییراتی رو توی فایل ها بدید، فایلی رو اضافه یا کم کنید مثلا، یا اینکه فایلی رو ادیت کنید.

git status:

بعدش با دستور git status میتونید ببینید اوضاع چطوره 🙂 گیت بهتون میگه که متوجه چه تغییراتی شده و همونطور که قبل تر گفتیم برای ثبت یا کامیت کردن این تغییرات باید اول اون هارو به فضای استیج ببریم و بعدش هر کدوم رو که خواستیم یا همش رو کامیت کنیم.

git add:

دستور git add به ما کمک میکنه تا فایل هارو به استیج اضافه کنیم.

git commit:

حالا که تغییراتی رو در استیج داریم و حتما میتونیم اونها رو با git status ببینیم، میتونیم اونها رو با دستور git commit -m کامیت کنیم و در ادامه دستور شرح توضیحی که برای این تغییرمون داریم رو بنویسیم.

git push:

حالا میتونید با دستور git push کامیت هایی رو که به ریپازیتوری اضافه کردید رو به ریپازیتوی ریموت هم ارسال کنید. با این دستور تغییرات ما در ریپازیتوری اصلی قرار می‌گیره.

git pull:

اگه بخواید تغییراتی رو که مثلا دیگران روی فایل های ریپازیتوری ریموت دادن رو دریافت کنید و روی ریپازیتوری لوکالتون داشته باشید میتونید از دستور git pull استفاده کنید. ما با این دستور تغییرات روی کدبیس رو از ریموت دریافت می‌کنیم.

git branch:

با استفاده از دستور git branch میتونید برنچ جدید درست کنید یا لیست برنچ هایی که دارید رو ببینید یا اینکه یک برنچ رو حذف کنید و موارد این چنینی.

git checkout:

با استفاده از دستور git checkout میتونید بین برنچ های مختلف جابجا بشید. البته می‌تونید با این دستور هم برنچ جدید بسازید و روی آن ادامه بدید.

git log:

دستور git log تاریخچه ای از کامیت هایی که تا اینجا زده اید رو به همراه پیام اونها و hash منحصر به هر کامیت نمایش میدهد.

گیت کلی دستور دیگه هم داره که کارهای مختلف انجام میدن، اما برای شروع و استفاده معمولی همین مواردیکه براتون توضیح دادم کافیه. حتما گیت رو نصب کنید و سعی کنید باهاش کار کنید.

git conflict
git conflict

توضیح در مورد Conflict توی گیت:

فرض کنید من توی برنچ خودم فایل مشخصی رو تغییر دادم و توی خط اولش اسم خودم رو نوشتم، شما هم توری برنچ خودتون همون فایل رو تغییر دادید و توی خط اولش اسم خودتون رو نوشتید. حالا وقتی‌که برنچ هامون رو با هم مرج می‌کنیم چه اتفاقی میافته؟ گیت باید چیکار کنه؟ اسم من رو بذاره یا اسم شما رو؟

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

revert and reset
revert and reset

بررسی reset , revert توی گیت:

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

اگه بریم توی کامیت جدید شماره بیست و یک و کامیت بیست و یک وضعیتی مشابه کامیت پانزده داشته باشه، ما git revert انجام دادیم.

اما اگر کامیت های شماره شانزده به بعد رو حذف کنیم و برگردیم به کامیت شماره پانزده، ما git reset انجام دادیم.

pull request
pull request

توضیح Pull Request و حل issue توی گیت هاب:

معمولا توی ریموت ریپازیتوری‌های معروف وارد هر ریپازیتوری که میشید، گزینه ای رو با نام fork میبینید.

با زدن این گزینه میتونیم عینا یک ریپازیتوری کپی اون پروژه رو توی گیت خودمون داشته باشیم و تغییراتی رو روش اعمال کنیم و بعد از اعمال تغییرات میتونیم Pull Request بزنیم، یعنی پیشنهاد بدیم به پروژه اصلی که تغییراتی که ما دادیم رو روی ریپازیتوری اصلی اعمال کند. معمولا روال کار به این شکل هست که مسائلی رو که توی پروژه پیش میاد در قالب issue ها به پروژه اضافه میکنن، اونوقت افراد میان پروژه رو فورک میکنن اون ایشو رو حل میکنن و بعدش پول ریکوئست میزنن. خوبه با این فرآیند آشنا باشید.

pull request
pull request


توضیح readme و مارک‌داون:

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


توی قسمت‌های بعدی مسیر دواپس‌مون رو ادامه میدیم و بیشتر گیت‌لب رو با هم بررسی میکنیم.

مراقب خودتون باشید. 🌹🐳🌹




خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊


ci cdgitgitlabcommit
مشاور زیرساخت. موسس سایت آموزشی DockerMe.ir
شاید از این پست‌ها خوشتان بیاید