پست‌های انتشارات آموزش گیت

آشنایی با Git: مدیریت Branching، Pull Request و Code Review

سید احمد — Wed, 02 Apr 2025 10:28:08 +0330

آشنایی با Branching در GitBranch چیست و چرا به آن نیاز داریم؟در Git، یک Branch (شاخه) به معنی یک خط توسعه مستقل از کد اصلی است که به شما امکان می‌دهد تغییرات را بدون تأثیرگذاری روی نسخه اصلی (مثلاً main یا master) انجام دهید. این قابلیت یکی از مهم‌ترین ویژگی‌های Git برای توسعه نرم‌افزار به صورت تیمی یا حتی فردی است.دلایل نیاز به Branching:- جداسازی تغییرات: هر توسعه‌دهنده می‌تواند روی یک ویژگی (Feature) یا رفع باگ (Bugfix) به صورت مجزا کار کند بدون اینکه کد اصلی را خراب کند.- مدیریت موازی پروژه: امکان کار همزمان روی چندین قابلیت یا نسخه متفاوت (مثلاً توسعه نسخه جدید و پشتیبانی از نسخه قدیمی).- کاهش خطرات: ادغام (Merge) تغییرات پس از تست و بررسی انجام می‌شود، نه به صورت مستقیم روی کد اصلی.- همکاری آسان‌تر: در پروژه‌های تیمی، هر عضو می‌تواند روی Branch خود کار کند و پس از اطمینان از صحت کد، آن را با دیگران به اشتراک بگذارد.انواع Branch (Main/Feature/Release/Hotfix)در مدل‌های مختلف مدیریت Branch (مثل Git Flow)، شاخه‌ها معمولاً به چند دسته کلی تقسیم می‌شوند:1. Main/Master:- شاخه اصلی و پایدار پروژه که همیشه باید قابل اجرا باشد.- تغییرات فقط از طریق ادغام شاخه‌های دیگر (مثل Release یا Hotfix) به آن اضافه می‌شوند.2. Feature Branch:- برای توسعه قابلیت‌های جدید استفاده می‌شود (مثلاً feature/login-page).- پس از تکمیل و تست، به شاخه develop یا main ادغام می‌شود.3. Release Branch:- زمانی ایجاد می‌شود که پروژه برای انتشار یک نسخه جدید آماده است (مثلاً release/v1.0).- در این مرحله، باگ‌های جزئی رفع و مستندات نهایی می‌شود.4. Hotfix Branch:- برای رفع مشکلات فوری در نسخه Production استفاده می‌شود (مثلاً hotfix/login-bug).- پس از رفع مشکل، به هر دو شاخه main و develop منتقل می‌شود.دستورات کاربردی برای مدیریت Branchهابرای کار با Branchها در Git، این دستورات کلیدی را به خاطر بسپارید:- ایجاد Branch جدید:git branch ایجاد Branch git checkout -b ایجاد و سوئیچ به Branch جدید- لیست Branchهای موجود:git branch نمایش لیست Branchها git branch -a نمایش تمام Branchها (شامل Remoteها)- سوئیچ بین Branchها:git checkout رفتن به یک Branch خاص git switch روش جدیدتر (Git 2.23+)- ادغام Branchها:git merge ادغام Branch فعلی با Branch دیگر- حذف Branch:git branch -d حذف Branch (اگر تغییراتش ادغام شده) git branch -D حذف Branch (اجباری، حتی اگر ادغام نشده)- ارسال Branch به Remote (مثل GitHub):git push origin ارسال Branch به Remoteنکته: برای جلوگیری از تداخل کدها، همیشه قبل از ایجاد Branch جدید، از به‌روز بودن شاخه main با دستور git pull origin main مطمئن شوید.این مفاهیم پایه Branching به شما کمک می‌کنند تا درک بهتری از کار تیمی با Git داشته باشید. در بخش‌های بعدی، Pull Request و روش‌های ادغام ایمن کد را بررسی خواهیم کرد.ادغام کد با Pull Request (PR)Pull Request چیست و چه کاربردی دارد؟Pull Request یا درخواست ادغام، یکی از مکانیزم‌های کلیدی در سیستم‌های کنترل نسخه مانند Git است که به توسعه‌دهندگان امکان می‌دهد تغییرات انجام شده در یک شاخه را برای بررسی و ادغام با شاخه اصلی ارائه دهند. این فرآیند نقش حیاتی در توسعه نرم‌افزار به صورت مشارکتی ایفا می‌کند.کاربرد اصلی Pull Request شامل موارد زیر است:- بررسی کد توسط سایر اعضای تیم قبل از ادغام- بحث و تبادل نظر درباره تغییرات پیشنهادی- اجرای تست‌های خودکار روی کد پیش از ادغام- مستندسازی تغییرات و دلایل آن‌هامراحل ایجاد و ارسال یک PR در GitHub/GitLabفرآیند ایجاد Pull Request معمولاً شامل مراحل زیر است:1. ابتدا باید شاخه‌ای جدید از شاخه اصلی ایجاد کنید:git checkout -b feature/new-login2. پس از اعمال تغییرات و کامیت‌ها، شاخه را به مخزن راه دور ارسال کنید:git push origin feature/new-login3. در پلتفرم میزبان کد (مثل GitHub یا GitLab):- به بخش Pull Requests مراجعه کنید- گزینه "New Pull Request" را انتخاب نمایید- شاخه مبدأ (تغییرات شما) و شاخه مقصد (معمولاً main) را مشخص کنید- عنوان و توضیحات واضحی برای تغییرات خود بنویسید4. پس از ایجاد PR، منتظر بررسی سایر اعضا بمانید و به نظرات آن‌ها پاسخ دهید.بررسی تغییرات (Diff) قبل از ادغامیکی از مهم‌ترین بخش‌های Pull Request، امکان مشاهده تفاوت‌های کد (Diff) است:- می‌توانید تمام تغییرات خط به خط را مشاهده کنید- کامنت‌گذاری روی خطوط خاص کد امکان‌پذیر است- می‌توانید پیش‌نمایشی از نتیجه ادغام را ببینید- برخی پلتفرم‌ها امکان مشاهده تغییرات فایل‌های باینری را نیز فراهم می‌کننداین ابزارها به اعضای تیم کمک می‌کند تا:- کیفیت کد را ارزیابی کنند- خطاهای احتمالی را شناسایی نمایند- استانداردهای کدنویسی را بررسی کنند- راهکارهای بهتری پیشنهاد دهندپس از تأیید تغییرات توسط بازبین‌ها و گذراندن تست‌های خودکار، تغییرات می‌توانند با شاخه اصلی ادغام شوند. این فرآیند تضمین می‌کند که کد اصلی همیشه از کیفیت بالایی برخوردار باشد.اهمیت Code Review در توسعه نرم افزارچرا Code Review ضروری است؟Code Review یا بازبینی کد فرآیندی است که در آن توسعه دهندگان دیگر کد نوشته شده توسط یک برنامه نویس را بررسی می کنند. این کار مزایای متعددی برای تیم های توسعه نرم افزار دارد:اولین و مهمترین مزیت Code Review، بهبود کیفیت کد است. وقتی چندین نفر کد را بررسی می کنند، احتمال شناسایی و رفع خطاها قبل از رسیدن به محیط تولید افزایش می یابد. این کار از بروز مشکلات احتمالی در آینده جلوگیری می کند.دومین مزیت مهم، اشتراک دانش بین اعضای تیم است. Code Review به اعضای جدید تیم کمک می کند سریعتر با کدبیس آشنا شوند و از طرفی دانش تخصصی بین همه اعضا به اشتراک گذاشته می شود.اصول یک Review مؤثربرای انجام یک بازبینی کد مؤثر، رعایت چند اصل اساسی ضروری است:1. تمرکز بر کیفیت کد: بررسی باید بر روی خوانایی، کارایی، امنیت و تطابق با استانداردهای تیم متمرکز باشد.2. احترام متقابل: بازبینی نباید به صورت شخصی انجام شود. نظرات باید سازنده و مبتنی بر واقعیت ها باشد.3. زمانبندی مناسب: بازبینی باید در زمان معقولی پس از ارسال کد انجام شود تا روند توسعه را کند نکند.4. دقت کافی: بازبین باید زمان کافی برای بررسی دقیق تغییرات اختصاص دهد.ابزارهای کمکی برای تسهیل فرآیند Reviewامروزه ابزارهای متعددی برای تسهیل فرآیند Code Review وجود دارد:1. ابزارهای اختصاصی Code Review مانند Crucible یا Review Board که امکانات پیشرفته ای برای بازبینی ارائه می دهند.2. سیستم های کنترل نسخه مدرن مانند GitHub و GitLab که قابلیت های بازبینی کد را به صورت یکپارچه ارائه می کنند.3. ابزارهای تحلیل کد استاتیک مانند SonarQube که می توانند به صورت خودکار مشکلات بالقوه را شناسایی کنند.4. افزونه های IDE که امکان بازبینی کد را مستقیماً در محیط توسعه فراهم می کنند.استفاده از این ابزارها می تواند فرآیند بازبینی را کارآمدتر کند و کیفیت نهایی محصول را بهبود بخشد. با این حال، هیچ ابزاری نمی تواند جایگزین بررسی انسانی و تخصص توسعه دهندگان با تجربه شود.نکته پایانی اینکه Code Review زمانی بیشترین تأثیر را دارد که به عنوان بخشی از فرهنگ تیم نهادینه شود و همه اعضا به اهمیت و ارزش آن اعتقاد داشته باشند.بهترین روش‌های کار با Git در تیماستانداردهای نامگذاری Branchهااستانداردسازی نام Branchها یکی از اصول مهم در کار تیمی با Git است. یک سیستم نامگذاری مناسب به همه اعضای تیم کمک می‌کند به سرعت هدف و ماهیت هر Branch را درک کنند. برخی از الگوهای رایج عبارتند از:- feature/نام-ویژگی (برای توسعه قابلیت‌های جدید)- bugfix/توضیح-باگ (برای رفع مشکلات)- hotfix/توضیح-مشکل (برای رفع فوری مشکلات در محیط تولید)- release/شماره-نسخه (برای آماده‌سازی نسخه‌های جدید)استفاده از حروف کوچک و جداکننده خط تیره (-) به جای فاصله، خوانایی را افزایش می‌دهد. همچنین بهتر است نام‌ها توصیفی و مختصر باشند.مدیریت Conflictها در ادغام کدبروز Conflict هنگام ادغام Branchها امری طبیعی است، اما مدیریت صحیح آن حیاتی است:1. پیشگیری: ادغام مکرر شاخه اصلی (main) به شاخه feature خود می‌تواند از بسیاری Conflictها جلوگیری کند.2. تشخیص: هنگام بروز Conflict، Git فایل‌های مشکل‌دار را مشخص می‌کند.3. حل: با استفاده از ابزارهای merge (مثل kdiff3 یا merge tool خود Git) می‌توان Conflictها را بررسی و رفع کرد.4. تأیید: پس از رفع همه Conflictها، تغییرات باید کامیت شوند.به خاطر داشته باشید که حل Conflict نیاز به درک عمیق از تغییرات هر دو طرف دارد و بهتر است با توسعه‌دهندگان مربوطه مشورت شود.Git Flow و روش‌های جایگزینGit Flow یک مدل شعبه‌بندی محبوب برای پروژه‌های نرم‌افزاری است که شامل شاخه‌های اصلی زیر می‌شود:1. main (نسخه‌های پایدار)2. develop (توسعه جاری)3. feature/* (ویژگی‌های جدید)4. release/* (آماده‌سازی انتشار)5. hotfix/* (رفع مشکلات فوری)با این حال، روش‌های جایگزین دیگری نیز وجود دارند:1. GitHub Flow: مدلی ساده‌تر که بر اساس Pull Requestها کار می‌کند.2. GitLab Flow: ترکیبی از Git Flow و Continuous Delivery.3. Trunk-Based Development: تمرکز بر ادغام مکرر با شاخه اصلی.انتخاب روش مناسب به عوامل مختلفی مانند اندازه تیم، فرآیند انتشار و پیچیدگی پروژه بستگی دارد. مهم این است که همه اعضای تیم از یک روش واحد پیروی کنند و درک مشترکی از فرآیندها داشته باشند. هماهنگی و مستندسازی این فرآیندها نقش کلیدی در موفقیت پروژه دارد.تمرین عملی: از Branching تا Mergeمثال واقعی از ایجاد Branch و ارسال PRبیایید یک سناریوی واقعی را برای درک بهتر فرآیند کار با Git بررسی کنیم. فرض کنید شما در حال توسعه یک سیستم مدیریت کاربر هستید و می‌خواهید ویژگی احراز هویت دو مرحله‌ای را اضافه کنید:1. ابتدا از شاخه اصلی یک Branch جدید ایجاد می‌کنیم:git checkout main git pull origin main git checkout -b feature/two-factor-auth2. پس از پیاده‌سازی تغییرات، آن‌ها را کامیت می‌کنیم:git add . git commit -m "اضافه کردن قابلیت احراز هویت دو مرحله‌ای" git push origin feature/two-factor-auth3. در پلتفرم میزبان کد (مثلاً GitHub):- به بخش Pull Requests می‌رویم- گزینه "New Pull Request" را انتخاب می‌کنیم- شاخه مقصد را main و شاخه مبدأ را feature/two-factor-auth انتخاب می‌کنیم- توضیحات کاملی درباره تغییرات ارائه می‌دهیمشبیه‌سازی فرآیند Code Reviewپس از ایجاد PR، فرآیند بازبینی کد آغاز می‌شود:1. هم‌تیمی‌ها تغییرات را بررسی می‌کنند:- کد را از نظر خوانایی و استانداردهای تیم بررسی می‌کنند- عملکرد را از طریق تست‌های محلی تأیید می‌کنند- نظرات خود را به صورت کامنت ثبت می‌کنند2. توسعه‌دهنده اصلی به نظرات پاسخ می‌دهد:- کامنت‌ها را بررسی می‌کند- در صورت نیاز تغییرات را اعمال می‌کند- تغییرات جدید را به همان Branch اضافه می‌کند3. پس از تأیید نهایی:- مدیر پروژه PR را تأیید می‌کند- تغییرات با شاخه main ادغام می‌شوند- Branch feature حذف می‌شوداین فرآیند تضمین می‌کند که:- همه تغییرات قبل از ادغام بررسی شده‌اند- کیفیت کد در سطح بالایی حفظ می‌شود- دانش بین اعضای تیم به اشتراک گذاشته می‌شود- خطاهای احتمالی قبل از رسیدن به محیط تولید شناسایی می‌شوندجمع‌بندی و نکات کلیدیخطاهای رایج و راه‌حل‌های آنهادر کار با Git، برخی خطاها میان توسعه‌دهندگان تازه‌کار و حتی باتجربه‌ترها مشترک هستند:1. ادغام ناقص تغییرات: زمانی رخ می‌دهد که شاخه اصلی را قبل از ایجاد Branch جدید به‌روز نکرده‌اید.- راه‌حل: همیشه قبل از ایجاد Branch جدید دستور `git pull origin main` را اجرا کنید.2. کامیت‌های پیچیده و بزرگ: کامیت‌هایی با تغییرات زیاد که توضیح مناسبی ندارند.- راه‌حل: تغییرات را به کامیت‌های کوچک و معنادار تقسیم کنید و برای هرکدام توضیحات واضح بنویسید.3. فراموش کردن Push کردن تغییرات: کار کردن طولانی‌مدت روی یک Branch بدون Push منظم.- راه‌حل: تغییرات را به‌طور منظم Push کنید تا از دست نروند.4. بازبینی سطحی کد: تأیید PRها بدون بررسی دقیق تغییرات.- راه‌حل: زمان کافی برای بازبینی اختصاص دهید و از ابزارهای تحلیل کد استفاده کنید.منابع یادگیری پیشرفته Gitبرای توسعه مهارت‌های خود در Git، این منابع ارزشمند را بررسی کنید:1. مستندات رسمی Git: کاملترین مرجع برای یادگیری تمام جنبه‌های Git2. کتاب Pro Git: کتابی رایگان که مفاهیم Git را از پایه تا پیشرفته پوشش می‌دهد3. دوره‌های آموزشی آنلاین:- GitHub Learning Lab: آموزش‌های تعاملی Git و GitHub- Udemy و Coursera: دوره‌های تخصصی مدیریت نسخه‌بندی4. ابزارهای تمرینی:- Learn Git Branching: ابزار تعاملی برای یادگیری Branching- GitKat: بازی برای یادگیری دستورات Git5. کامیونیتی‌ها و انجمن‌ها:- Stack Overflow برای پرسش و پاسخ- فوروم‌های تخصصی Gitبه یاد داشته باشید که تسلط بر Git نیاز به تمرین مداوم دارد. سعی کنید در پروژه‌های واقعی از این ابزار استفاده کنید و به‌تدریج کار با ویژگی‌های پیشرفته‌تر را یاد بگیرید. مشارکت در پروژه‌های متن‌باز می‌تواند تجربه ارزشمندی در کار تیمی با Git برای شما ایجاد کند.با رعایت اصول و بهترین‌روش‌هایی که در این آموزش بررسی کردیم، می‌توانید به عضوی مؤثر در تیم‌های توسعه نرم‌افزار تبدیل شوید و از قدرت واقعی Git در مدیریت پروژه‌ها بهره ببرید.

کار با گیت را شروع کنیم

سید احمد — Thu, 26 Sep 2024 15:03:33 +0330

این فصل درباره شروع به کار با Git است. ابتدا مقداری پیش‌زمینه درباره ابزارهای کنترل نسخه ارائه خواهیم داد، سپس به نحوه راه‌اندازی Git بر روی سیستم شما و در نهایت چگونگی تنظیم آن برای شروع کار خواهیم پرداخت. در پایان این فصل، شما باید بدانید چرا Git وجود دارد، چرا باید از آن استفاده کنید و آماده‌ی کار با آن خواهید بود.درباره کنترل نسخه کنترل نسخه چیست و چرا باید به آن اهمیت دهید؟ کنترل نسخه سیستمی است که تغییرات یک فایل یا مجموعه‌ای از فایل‌ها را در طول زمان ثبت می‌کند تا بتوانید نسخه‌های خاصی از آن‌ها را بازیابی کنید. در مثال‌های این کتاب، شما از کد منبع نرم‌افزار به عنوان فایل‌های تحت کنترل نسخه استفاده خواهید کرد، هرچند در واقعیت می‌توانید این کار را با تقریباً هر نوع فایلی در یک کامپیوتر انجام دهید. اگر شما یک طراح گرافیک یا وب هستید و می‌خواهید همه نسخه‌های یک تصویر یا طرح‌بندی را نگه دارید (که احتمالاً چنین خواسته‌ای دارید)، استفاده از سیستم کنترل نسخه (VCS) انتخابی بسیار عاقلانه است. این سیستم به شما امکان می‌دهد فایل‌های انتخابی را به حالت قبلی برگردانید، کل پروژه را به حالت قبلی بازگردانید، تغییرات را در طول زمان مقایسه کنید، ببینید چه کسی آخرین بار چیزی را تغییر داده که ممکن است مشکلی ایجاد کرده باشد، چه کسی مشکل را وارد کرده و چه زمانی، و بسیاری موارد دیگر. استفاده از یک سیستم کنترل نسخه به طور کلی به این معناست که اگر چیزی را خراب کنید یا فایل‌ها را از دست بدهید، به راحتی می‌توانید آن را بازیابی کنید. علاوه بر این، شما همه این امکانات را با کمترین هزینه اضافی به دست می‌آورید.سیستم‌های کنترل نسخه محلی روش انتخابی بسیاری از افراد برای کنترل نسخه، کپی کردن فایل‌ها در دایرکتوری دیگری (شاید یک دایرکتوری با مهر زمانی، اگر باهوش باشند) است. این روش به دلیل سادگی آن بسیار رایج است، اما همچنین بسیار مستعد خطاست. فراموش کردن اینکه در کدام دایرکتوری هستید و به اشتباه نوشتن در فایل اشتباه یا رونویسی از فایل‌هایی که قصد ندارید، بسیار آسان است. برای حل این مشکل، برنامه‌نویسان سال‌ها پیش سیستم‌های کنترل نسخه محلی را توسعه دادند که دارای یک پایگاه داده ساده بود که تمام تغییرات فایل‌ها را تحت کنترل نسخه ثبت می‌کرد. Local version control diagramیکی از محبوب‌ترین ابزارهای کنترل نسخه، سیستمی به نام RCS بود که هنوز با بسیاری از کامپیوترها توزیع می‌شود. RCS با ذخیره مجموعه‌های تغییرات (یعنی تفاوت‌های بین فایل‌ها) در قالبی خاص بر روی دیسک کار می‌کرد؛ سپس می‌توانست با جمع‌بندی تمام تغییرات، هر فایل را در هر لحظه‌ای بازسازی کند.لینک RCS در گنو:https://www.gnu.org/software/rcs/سیستم‌های کنترل نسخه متمرکز مسئله مهم بعدی که افراد با آن مواجه می‌شوند این است که نیاز دارند با توسعه‌دهندگان دیگر در سیستم‌های دیگر همکاری کنند. برای حل این مشکل، سیستم‌های کنترل نسخه متمرکز (CVCS) توسعه یافتند. این سیستم‌ها (مانند CVS، Subversion و Perforce) دارای یک سرور مرکزی هستند که تمام فایل‌های نسخه‌بندی‌شده را در خود دارد و تعدادی از کلاینت‌ها که فایل‌ها را از آنجا دریافت می‌کنند. این سیستم‌ها برای سال‌ها استاندارد کنترل نسخه بوده‌اند.Centralized version control diagramاین روش مزایای زیادی دارد، به‌ویژه در مقایسه با سیستم‌های محلی کنترل نسخه. برای مثال، همه افراد تا حدودی می‌دانند که دیگران در پروژه چه می‌کنند. مدیران کنترل دقیقی بر روی اینکه چه کسی چه کاری می‌تواند انجام دهد دارند و مدیریت یک سیستم متمرکز بسیار ساده‌تر از کار با پایگاه‌های داده محلی در هر کلاینت است.با این حال، این روش دارای معایب جدی است. واضح‌ترین آن نقطه ضعف مرکزی است که سرور متمرکز نمایانگر آن است. اگر سرور به مدت یک ساعت از دسترس خارج شود، در آن ساعت هیچ کس نمی‌تواند همکاری کند یا تغییرات نسخه‌بندی‌شده خود را ذخیره کند. اگر دیسک سختی که پایگاه داده مرکزی روی آن است خراب شود و پشتیبان‌گیری مناسب انجام نشده باشد، شما همه چیز را از دست خواهید داد — کل تاریخچه پروژه به جز عکس‌های فوری جداگانه‌ای که افراد ممکن است در ماشین‌های محلی خود داشته باشند. سیستم‌های محلی کنترل نسخه نیز از همین مشکل رنج می‌برند — هر زمان که تاریخچه کل پروژه در یک مکان باشد، ریسک از دست دادن همه چیز وجود دارد.سیستم‌های کنترل نسخه توزیع‌شده در اینجا سیستم‌های کنترل نسخه توزیع‌شده (DVCS) وارد می‌شوند. در DVCS (مانند Git، Mercurial یا Darcs)، کلاینت‌ها فقط آخرین نسخه فایل‌ها را بررسی نمی‌کنند؛ بلکه کل مخزن را با تمام تاریخچه آن بازتاب می‌دهند. بنابراین، اگر هر سروری از بین برود و این سیستم‌ها از طریق آن سرور همکاری می‌کردند، هر یک از مخازن کلاینت می‌تواند برای بازگردانی سرور استفاده شود. هر کلون واقعاً یک نسخه پشتیبان کامل از تمام داده‌هاست.Distributed version control diagramعلاوه بر این، بسیاری از این سیستم‌ها به خوبی با داشتن چندین مخزن راه دور که می‌توانند با آن‌ها کار کنند، سازگار هستند، بنابراین شما می‌توانید به طور همزمان با گروه‌های مختلفی از افراد در پروژه‌ای واحد همکاری کنید. این به شما امکان می‌دهد چندین نوع گردش کار را که در سیستم‌های متمرکز ممکن نیست، پیاده‌سازی کنید، مانند مدل‌های سلسله‌مراتبی.تاریخچه کوتاه Git مانند بسیاری از چیزهای بزرگ در زندگی، Git با کمی تخریب خلاقانه و جنجال آتشین آغاز شد. هسته لینوکس یک پروژه نرم‌افزار متن‌باز با مقیاس نسبتاً بزرگ است. در سال‌های ابتدایی نگهداری از هسته لینوکس (1991-2002)، تغییرات به صورت تکه‌ها و فایل‌های آرشیوی جابه‌جا می‌شدند. در سال 2002، پروژه هسته لینوکس از یک DVCS اختصاصی به نام BitKeeper استفاده کرد. در سال 2005، رابطه بین جامعه توسعه‌دهندگان هسته لینوکس و شرکت تجاری که BitKeeper را توسعه می‌داد، به هم خورد و وضعیت رایگان آن ابزار لغو شد. این موضوع جامعه توسعه‌دهندگان لینوکس (و به‌ویژه لینوس توروالدز، خالق لینوکس) را وادار کرد که ابزار خودشان را با توجه به درس‌هایی که در حین استفاده از BitKeeper آموخته بودند، توسعه دهند. برخی از اهداف سیستم جدید به شرح زیر بودند:سرعتطراحی سادهپشتیبانی قوی از توسعه غیرخطی (هزاران شاخه موازی)به طور کامل توزیع‌شدهتوانایی مدیریت پروژه‌های بزرگ مانند هسته لینوکس به طور کارآمد (از نظر سرعت و اندازه داده) از زمان تولد Git در سال 2005، این ابزار تکامل یافته و بالغ شده است تا به راحتی قابل استفاده باشد و در عین حال این ویژگی‌های اولیه را حفظ کند. Git باورنکردنی سریع است، با پروژه‌های بزرگ به طور کارآمد کار می‌کند و دارای سیستم شاخه‌بندی بی‌نظیری برای توسعه غیرخطی است.گیت Git چیست؟پس Git چیست؟ این بخش بسیار مهم است، زیرا اگر بفهمید Git چیست و اصول عملکرد آن را درک کنید، احتمالاً استفاده مؤثر از Git برای شما بسیار آسان‌تر خواهد شد. در حین یادگیری Git، سعی کنید ذهن خود را از چیزهایی که ممکن است درباره سایر سیستم‌های کنترل نسخه بدانید (مانند CVS، Subversion یا Perforce) پاک کنید — این کار به شما کمک می‌کند از سردرگمی‌های پنهانی هنگام استفاده از این ابزار جلوگیری کنید. حتی با وجود اینکه رابط کاربری Git تا حدی شبیه به این سیستم‌های دیگر است، Git اطلاعات را به شکل بسیار متفاوتی ذخیره و مدیریت می‌کند و درک این تفاوت‌ها به شما کمک می‌کند تا از سردرگمی در استفاده از آن جلوگیری کنید.تصاویر فوری، نه تفاوت‌هاتفاوت اصلی بین Git و هر سیستم کنترل نسخه دیگری (شامل Subversion و دوستانش) در نحوه تفکر Git درباره داده‌هاست. در سطح مفهومی، بیشتر سیستم‌های دیگر اطلاعات را به‌عنوان لیستی از تغییرات فایل‌ها ذخیره می‌کنند. این سیستم‌های دیگر (مانند CVS، Subversion، Perforce و غیره) اطلاعاتی را که ذخیره می‌کنند به‌عنوان مجموعه‌ای از فایل‌ها و تغییراتی که در طول زمان روی هر فایل اعمال شده می‌بینند (که به‌طور رایج به آن کنترل نسخه مبتنی بر دلتا گفته می‌شود).Storing data as changes to a base version of each fileگیت Git داده‌های خود را این‌گونه در نظر نمی‌گیرد یا ذخیره نمی‌کند. در عوض، Git داده‌های خود را بیشتر شبیه به یک سری از تصاویر کوچک سیستم فایل می‌بیند. هر زمان که شما commit می‌کنید یا وضعیت پروژه خود را ذخیره می‌کنید، Git در واقع تصویری از تمام فایل‌های شما در آن لحظه می‌گیرد و یک مرجع به آن اسنپ شات snapshot ذخیره می‌کند. برای بهره‌وری، اگر فایل‌ها تغییر نکرده باشند، Git فایل را دوباره ذخیره نمی‌کند؛ بلکه تنها یک لینک به فایل قبلی که مشابه است ذخیره می‌کند. Git به داده‌های خود مانند جریانی از تصاویر نگاه می‌کند.این تفاوت مهمی بین Git و تقریباً تمام سیستم‌های مدیریت نسخه دیگر است. این ویژگی باعث می‌شود که Git دوباره تقریباً به هر جنبه‌ای از کنترل نسخه که سیستم‌های دیگر از نسل قبلی کپی کرده‌اند، فکر کند. در واقع Git بیشتر شبیه به یک سیستم فایل کوچک با ابزارهای بسیار قدرتمند است که روی آن ساخته شده است، تا یک سیستم کنترل نسخه ساده.تقریباً تمام عملیات‌ها محلی هستندبیشتر عملیات‌های Git تنها به فایل‌ها و منابع محلی نیاز دارند — عموماً هیچ اطلاعاتی از کامپیوتر دیگری در شبکه شما لازم نیست. اگر شما به یک سیستم کنترل نسخه متمرکز (CVCS) عادت دارید که اکثر عملیات‌ها آن دارای تأخیر ناشی از شبکه هستند، این ویژگی Git باعث می‌شود حس کنید که قدرت‌های ماورایی سرعت در اختیار آن قرار داده شده‌اند. زیرا شما تمام تاریخچه پروژه را روی دیسک محلی خود دارید و بیشتر عملیات‌ها تقریباً به‌صورت لحظه‌ای انجام می‌شوند.به عنوان مثال، برای مرور تاریخچه پروژه، Git نیازی به سرور برای گرفتن تاریخچه و نمایش آن به شما ندارد — بلکه به‌صورت مستقیم آن را از پایگاه داده محلی شما می‌خواند. این بدان معناست که شما تاریخچه پروژه را تقریباً فوراً مشاهده خواهید کرد. اگر بخواهید تغییرات بین نسخه کنونی یک فایل و فایل یک ماه پیش را ببینید، Git می‌تواند فایل یک ماه پیش را پیدا کند و یک مقایسه محلی انجام دهد، به جای اینکه از یک سرور دور درخواست کنید یا نسخه قدیمی فایل را از سرور بگیرید.این همچنین به این معناست که تقریباً هیچ کاری وجود ندارد که نتوانید زمانی که آفلاین هستید انجام دهید. اگر در یک هواپیما یا قطار باشید و بخواهید کار کنید، می‌توانید به‌راحتی commit کنید (به کپی محلی خود، به یاد داشته باشید؟) تا زمانی که به شبکه دسترسی پیدا کنید و آن را آپلود کنید. اگر به خانه بروید و نتوانید VPN خود را درست راه‌اندازی کنید، هنوز هم می‌توانید کار کنید. در بسیاری از سیستم‌های دیگر، این کار یا غیرممکن است یا بسیار دشوار.گیت Git دارای یکپارچگی استهر چیزی در Git قبل از ذخیره‌سازی چک‌سام checksummed می‌شود و سپس توسط همان چک‌سام مرجع قرار می‌گیرد. این بدان معناست که تغییر محتوای هر فایل یا دایرکتوری بدون اطلاع Git غیرممکن است. این ویژگی در پایین‌ترین سطوح Git ساخته شده و بخش جدایی‌ناپذیری از فلسفه آن است. شما نمی‌توانید اطلاعات را در حین انتقال از دست بدهید یا فایل‌های خراب داشته باشید، بدون اینکه Git بتواند آن را تشخیص دهد.مکانیزمی که Git برای این چک‌سام استفاده می‌کند به نام SHA-1 hash است. این یک رشته ۴۰ کاراکتری است که از اعداد هگزا دسیمال (0–9 و a–f) تشکیل شده و بر اساس محتوای یک فایل یا ساختار دایرکتوری در Git محاسبه می‌شود. یک SHA-1 hash چیزی شبیه به این است:24b9da6552252987aa493b52f8696cd6d3b00373این هش‌ها در Git به وفور دیده می‌شوند زیرا گیت به‌قدری از آن‌ها استفاده می‌کند. در واقع، گیت همه‌چیز را در پایگاه داده خود نه با نام فایل، بلکه با مقدار هش محتوای آن ذخیره می‌کند.گیت Git تقریباً فقط داده‌ها را اضافه می‌کندزمانی که شما عملیاتی را در Git انجام می‌دهید، تقریباً همه آن‌ها فقط داده‌ها را به پایگاه داده گیت اضافه می‌کنند. از دست دادن اطلاعات یا پاک کردن داده‌ها به شکلی که غیرقابل بازگشت باشد در گیت بسیار دشوار است. این ویژگی باعث می‌شود که گیت بسیار لذت‌بخش باشد، زیرا می‌دانید که می‌توانید بدون نگرانی از خراب شدن شدید، آزمایش کنید.سه وضعیت در Gitگیت Git سه وضعیت اصلی دارد که فایل‌های شما می‌توانند در آن‌ها باشند: تغییر داده‌شده (modified)، آماده‌شده (staged)، و ثبت‌شده (committed):تغییر داده‌شده به این معنی است که شما فایل را تغییر داده‌اید اما هنوز آن را به پایگاه داده خود اضافه نکرده‌اید.آماده‌شده به این معنی است که شما یک فایل تغییر داده‌شده را برای اضافه شدن به snapshot بعدی آماده کرده‌اید.ثبت‌شده به این معنی است که داده به‌طور امن در پایگاه داده محلی شما ذخیره شده است.این موضوع ما را به سه بخش اصلی یک پروژه گیت می‌رساند: پوشه کاری (working tree)، منطقه آماده‌سازی (staging area) و دایرکتوری گیت (Git directory). Working tree, staging area, Git directoryپوشه کاری یک چک‌اوت checkout از یک نسخه پروژه است. این فایل‌ها از پایگاه داده فشرده Git بیرون کشیده و روی دیسک برای استفاده یا تغییر قرار داده می‌شوند.منطقه آماده‌سازی فایلی است که اطلاعاتی در مورد آنچه در snapshot بعدی وارد خواهد شد، ذخیره می‌کند.دایرکتوری Git جایی است که گیت، متاداده‌ها و پایگاه داده اشیاء پروژه شما را ذخیره می‌کند.جریان کاری پایه در Git به این شکل است:1. فایل‌ها را در پوشه کاری (working tree) خود تغییر می‌دهید.2. به‌صورت انتخابی، فقط تغییراتی که می‌خواهید در commit بعدی شامل شوند را stage می‌کنید، که این تغییرات به منطقه آماده‌سازی (staging area) اضافه می‌شوند.3. سپس commit می‌کنید که فایل‌ها را به همان شکلی که در منطقه آماده‌سازی هستند، به‌طور دائمی در دایرکتوری Git ذخیره می‌کند.اگر یک نسخه خاص از یک فایل در دایرکتوری Git باشد، آن را "commit شده" در نظر می‌گیریم. اگر فایل تغییر داده شده و به منطقه آماده‌سازی اضافه شده باشد، در حالت "staged" است. و اگر از زمانی که فایل را بررسی کرده‌اید تغییر کرده ولی هنوز به مرحله آماده‌سازی اضافه نشده باشد، در حالت "modified" است. در بخش اصول Git، با این حالت‌ها بیشتر آشنا خواهید شد و یاد می‌گیرید چگونه از آن‌ها استفاده کنید یا به‌طور کامل از مرحله آماده‌سازی صرف‌نظر کنید.خط فرمانروش‌های زیادی برای استفاده از Git وجود دارد. ابزارهای اصلی خط فرمان و همچنین رابط‌های گرافیکی متنوعی با قابلیت‌های متفاوت در دسترس هستند. در این کتاب، ما از گیت در خط فرمان استفاده خواهیم کرد. دلیل این انتخاب این است که فقط در خط فرمان می‌توانید از تمامی دستورات گیت استفاده کنید — اکثر رابط‌های گرافیکی تنها بخشی از عملکرد گیت را به خاطر سادگی پیاده‌سازی کرده‌اند. اگر کار با نسخه خط فرمان را بلد باشید، به احتمال زیاد می‌توانید نحوه استفاده از نسخه گرافیکی را نیز بیاموزید، اما عکس آن همیشه صادق نیست.همچنین، در حالی که انتخاب رابط گرافیکی شما به سلیقه شخصی بستگی دارد، همه کاربران ابزارهای خط فرمان را نصب و در دسترس خواهند داشت. بنابراین، ما از شما انتظار داریم بدانید چگونه Terminal را در macOS یا Command Prompt یا PowerShell را در Windows باز کنید. اگر نمی‌دانید این‌ها چیست، ممکن است لازم باشد سریعاً در این مورد تحقیق کنید تا بتوانید ادامه مثال‌ها و توضیحات این کتاب را دنبال کنید.نصب Gitپیش از شروع به استفاده از Git، باید آن را روی رایانه خود نصب کنید. حتی اگر از قبل نصب شده باشد، بهتر است آن را به آخرین نسخه به‌روزرسانی کنید. می‌توانید Git را به‌صورت بسته (package) نصب کنید یا با استفاده از یک نصب‌کننده دیگر (installer) آن را نصب کنید. همچنین می‌توانید کد منبع را دانلود و آن را خودتان کامپایل کنید.توجه این کتاب با استفاده از نسخه 2 Git نوشته شده است. از آنجا که گیت به خوبی از سازگاری با نسخه‌های قبلی پشتیبانی می‌کند، هر نسخه‌ای از گیت که اخیراً منتشر شده باشد، به‌خوبی کار خواهد کرد. با این حال، بیشتر دستورات مورد استفاده در این کتاب در نسخه‌های قدیمی‌تر گیت نیز کار می‌کنند، اما ممکن است برخی از آن‌ها به‌درستی کار نکنند یا رفتار متفاوتی داشته باشند.نصب در لینوکسبرای نصب ابزارهای اصلی Git در لینوکس از طریق یک نصب‌کننده باینری، معمولاً می‌توانید از ابزار مدیریت بسته (package management) که همراه با توزیع شما است، استفاده کنید. اگر از Fedora یا هر توزیع دیگر مبتنی بر RPM، مانند RHEL یا CentOS استفاده می‌کنید، می‌توانید از دستور `dnf` استفاده کنید:sudo dnf install git-allاگر از یک توزیع مبتنی بر دبیان مانند Ubuntu استفاده می‌کنید، می‌توانید از دستور `apt` استفاده کنید:sudo apt install git-allبرای گزینه‌های بیشتر، دستورالعمل‌های نصب بر روی توزیع‌های مختلف یونیکس در وب‌سایت Git در دسترس است: [https://git-scm.com/download/linux].نصب در macOSروش‌های مختلفی برای نصب Git در macOS وجود دارد. ساده‌ترین روش احتمالاً نصب Xcode Command Line Tools است. در نسخه Mavericks (10.9) یا بالاتر، می‌توانید با اجرای دستور `git` در Terminal برای اولین بار، به‌سادگی این ابزارها را نصب کنید:git --versionاگر هنوز Git نصب نشده باشد، سیستم از شما می‌خواهد آن را نصب کنید.اگر به نسخه به‌روزتری نیاز دارید، می‌توانید Git را از طریق یک نصب‌کننده باینری نصب کنید. نصب‌کننده Git برای macOS توسط وب‌سایت Git نگهداری و در دسترس است: [https://git-scm.com/download/mac].نصب Git در ویندوزچند روش مختلف برای نصب Git در ویندوز وجود دارد. رسمی‌ترین نسخه برای دانلود در وب‌سایت Git در دسترس است. کافی است به آدرس [https://git-scm.com/download/win] بروید و دانلود به صورت خودکار شروع می‌شود. توجه داشته باشید که این پروژه به نام Git for Windows شناخته می‌شود که از Git اصلی جدا است. برای اطلاعات بیشتر به [https://gitforwindows.org] مراجعه کنید.برای نصب خودکار، می‌توانید از پکیج Git Chocolatey استفاده کنید. توجه داشته باشید که این پکیج توسط جامعه توسعه‌دهندگان نگهداری می‌شود.برای نصب ویندوز انجام توضیحات تا همینجا کافیست و توضیحات زیر برای افراد حرفه ای تر است. پس نیازی به خواندن توضیحات زیر برای نصب در ویندوز ندارید.نصب از منبع (Source)برخی از کاربران ممکن است بخواهند Git را از منبع (source) نصب کنند، زیرا این روش به شما امکان می‌دهد آخرین نسخه را دریافت کنید. نصب‌کننده‌های باینری معمولاً کمی عقب‌تر هستند، اگرچه با توجه به بلوغ Git در سال‌های اخیر، این موضوع کمتر اهمیت پیدا کرده است.اگر قصد دارید Git را از منبع نصب کنید، نیاز به نصب کتابخانه‌هایی دارید که Git به آن‌ها وابسته است: autotools، curl، zlib، openssl، expat و libiconv. به عنوان مثال، اگر از سیستمی با dnf (مثل فدورا) یا apt-get (مثل اوبونتو) استفاده می‌کنید، می‌توانید با استفاده از دستورات زیر وابستگی‌های مورد نیاز را نصب کنید:sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \ openssl-devel perl-devel zlib-devel sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-devبرای اضافه کردن مستندات (doc, html, info)، این وابستگی‌های اضافی مورد نیاز است:sudo dnf install asciidoc xmlto docbook2X sudo apt-get install asciidoc xmlto docbook2xکاربران RHEL و توزیع‌های مشتق شده از RHEL مانند CentOS و Scientific Linux باید مخزن EPEL را برای دانلود بسته docbook2X فعال کنند.اگر از توزیع‌های مبتنی بر دبیان (Debian/Ubuntu/مشتقات اوبونتو) استفاده می‌کنید، باید بسته install-info را نیز نصب کنید:sudo apt-get install install-infoاگر از توزیع‌های مبتنی بر RPM (Fedora/RHEL/مشتقات RHEL) استفاده می‌کنید، باید بسته getopt را نصب کنید:sudo dnf install getoptعلاوه بر این، اگر از Fedora/RHEL استفاده می‌کنید، لازم است این لینک سمبلیک را به دلیل تفاوت در نام‌های باینری ایجاد کنید:sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texiپس از نصب تمام وابستگی‌های لازم، می‌توانید آخرین نسخه انتشار یافته از Git را دانلود کنید. می‌توانید این کار را از سایت kernel.org [https://www.kernel.org/pub/software/scm/git] یا از لینک جایگزین موجود در GitHub [https://github.com/git/git/tags] انجام دهید.سپس، Git را کامپایل و نصب کنید:tar -zxf git-2.8.0.tar.gz cd git-2.8.0 make configure ./configure --prefix=/usr make all doc info sudo make install install-doc install-html install-infoپس از اتمام نصب، می‌توانید Git را از طریق خود Git نیز به‌روزرسانی کنید:$ git clone https://git.kernel.org/pub/scm/git/git.gitتنظیمات اولیه گیت Gitاکنون که گیت را روی سیستم خود نصب کرده‌اید، لازم است چند تغییر برای شخصی‌سازی محیط گیت خود انجام دهید. این تنظیمات فقط یک‌بار روی هر رایانه نیاز به انجام دارند و بعد از به‌روزرسانی‌ها نیز باقی می‌مانند. همچنین، می‌توانید هر زمان که خواستید این تنظیمات را با اجرای دوباره دستورات تغییر دهید.گیت Git ابزاری به نام git config دارد که به شما اجازه می‌دهد متغیرهای تنظیمات را تنظیم و مشاهده کنید که کنترل‌کننده تمام جنبه‌های گیت هستند. این متغیرها می‌توانند در سه مکان مختلف ذخیره شوند:1. فایل `[path]/etc/gitconfig` که مقادیر را برای تمامی کاربران سیستم و مخازن آن‌ها اعمال می‌کند. برای نوشتن در این فایل باید از گزینه `--system` استفاده کنید. برای تغییر این فایل نیاز به دسترسی مدیر یا superuser دارید. 2. فایل `~/.gitconfig` یا `~/.config/git/config` که مقادیر خاص کاربر شما را ذخیره می‌کند. برای نوشتن در این فایل از گزینه `--global` استفاده کنید تا تمامی مخازن شما تحت تأثیر قرار گیرند.3. فایل `config` در دایرکتوری Git (یعنی `.git/config`) مربوط به مخزنی که هم‌اکنون در حال استفاده از آن هستید.هر سطح از تنظیمات در Git تنظیمات سطوح قبلی را نادیده می‌گیرد، بنابراین مقادیر موجود در فایل `.git/config` از تنظیمات موجود در `[path]/etc/gitconfig` پیشی می‌گیرد. در سیستم‌های ویندوزی، Git به دنبال فایل `.gitconfig` در دایرکتوری $HOME (معمولاً C:\Users\$USER برای بیشتر کاربران) است. همچنین Git به دنبال فایل `[path]/etc/gitconfig` نیز خواهد بود، اما به ریشه MSys وابسته است که بستگی به مکانی دارد که شما Git را در سیستم ویندوز خود نصب کرده‌اید. اگر از نسخه 2.x یا بالاتر Git برای ویندوز استفاده می‌کنید، یک فایل پیکربندی سیستم در آدرس `C:\Documents and Settings\All Users\Application Data\Git\config` برای ویندوز XP و در آدرس `C:\ProgramData\Git\config` برای ویندوز ویستا و نسخه‌های جدیدتر نیز وجود دارد. این فایل پیکربندی فقط توسط دستور `git config -f ` با دسترسی مدیر قابل تغییر است.برای مشاهده تمام تنظیمات خود و مبدا آن‌ها می‌توانید از دستور زیر استفاده کنید:git config --list --show-originهویت Identity شمااولین کاری که پس از نصب Git باید انجام دهید، تنظیم نام کاربری و آدرس ایمیل شماست. این موضوع اهمیت زیادی دارد زیرا هر commit در گیت از این اطلاعات استفاده می‌کند و آن‌ها به صورت دائمی در commit‌های شما ذخیره می‌شوند:git config --global user.name "John Doe"git config --global user.email johndoe@example.comشما فقط یک‌بار نیاز به انجام این کار دارید اگر از گزینه `--global` استفاده کنید، زیرا Git همیشه از این اطلاعات برای هر کاری که در آن سیستم انجام می‌دهید استفاده می‌کند. اگر می‌خواهید برای پروژه‌های خاص نام یا ایمیل متفاوتی استفاده کنید، می‌توانید بدون استفاده از گزینه `--global` در آن پروژه خاص این دستور را اجرا کنید.بسیاری از ابزارهای گرافیکی (GUI) نیز به شما در انجام این کار کمک می‌کنند.ویرایشگر Editor متنی شماپس از تنظیم هویت، می‌توانید ویرایشگر متنی پیش‌فرضی که Git از آن برای نوشتن پیام‌ها استفاده می‌کند، پیکربندی کنید. اگر پیکربندی نشده باشد، Git از ویرایشگر پیش‌فرض سیستم شما استفاده می‌کند.اگر می‌خواهید از ویرایشگر دیگری مثل Emacs استفاده کنید، می‌توانید دستور زیر را اجرا کنید:git config --global core.editor emacsدر سیستم‌های ویندوز، اگر بخواهید از ویرایشگر متنی دیگری استفاده کنید، باید مسیر کامل فایل اجرایی آن را مشخص کنید. این مسیر بسته به نحوه بسته‌بندی ویرایشگر شما متفاوت است.برای مثال، اگر از Notepad++ که یک ویرایشگر محبوب برنامه‌نویسی است استفاده می‌کنید، احتمالاً از نسخه 32 بیتی استفاده خواهید کرد، زیرا در زمان نگارش این متن نسخه 64 بیتی از همه پلاگین‌ها پشتیبانی نمی‌کند. در سیستم‌های 32 بیتی یا ویرایشگرهای 64 بیتی روی سیستم‌های 64 بیتی، شما باید چیزی شبیه به این بنویسید:git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"نام شاخه پیش‌فرض default branch شمابه طور پیش‌فرض، Git هنگام ایجاد مخزن جدید با دستور `git init`، یک شاخه به نام `master` ایجاد می‌کند. از نسخه 2.28 به بعد، می‌توانید نام دیگری برای شاخه ابتدایی تنظیم کنید. برای تنظیم شاخه `main` به عنوان نام شاخه پیش‌فرض، از این دستور استفاده کنید:git config --global init.defaultBranch mainبررسی تنظیماتاگر می‌خواهید تنظیمات پیکربندی خود را بررسی کنید، می‌توانید از دستور `git config --list` استفاده کنید تا تمام تنظیمات موجود را لیست کنید:git config --list user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=autoممکن است کلیدهایی را بیشتر از یک‌بار ببینید، زیرا Git ممکن است همان کلید را از فایل‌های مختلف (مانند `[path]/etc/gitconfig` و `~/.gitconfig`) بخواند. در این حالت، Git آخرین مقدار هر کلید منحصر به فرد را استفاده می‌کند.همچنین می‌توانید بررسی کنید که Git برای یک کلید خاص چه مقداری را در نظر می‌گیرد، با تایپ کردن دستور:git config user.name John Doeدریافت کمکاگر نیاز به کمک داشتید، می‌توانید با استفاده از سه روش زیر راهنمای جامع هر یک از دستورات Git را دریافت کنید:git help git --help man git-برای مثال، می‌توانید با اجرای دستور زیر راهنمای `git config` را دریافت کنید:git help configهمچنین اگر نیاز به کمک بیشتری داشتید، می‌توانید از کانال‌های IRC مانند `#git`، `#github` یا `#gitlab` در سرور Libera Chat که در آدرس [libera.chat](https://libera.chat) قابل دسترسی است، استفاده کنید. این کانال‌ها معمولاً با صدها فرد آشنا به Git پر هستند و غالباً تمایل به کمک دارند.خلاصه فصلدر اینجا باید درک پایه‌ای از Git و نحوه تفاوت آن با سیستم‌های کنترل نسخه متمرکز به دست آورده باشید. همچنین باید نسخه‌ای از Git را روی سیستم خود نصب کرده باشید که با هویت شخصی شما پیکربندی شده است. حالا زمان آن است که برخی اصول Git را یاد بگیرید.

ساب ورژن (زیرنسخه) Subversion (SVN) چیست

سید احمد — Wed, 25 Sep 2024 00:14:20 +0330

دنیای ساب‌ورژن (Subversion یا SVN) به یک سیستم کنترل نسخه (Version Control System) اشاره دارد که برای مدیریت و نگهداری تغییرات در پروژه‌های نرم‌افزاری استفاده می‌شود. کنترل نسخه به فرآیندی گفته می‌شود که در آن تغییرات کد منبع، اسناد یا هر نوع فایل دیگری در طول زمان ذخیره و مدیریت می‌شوند، به طوری که می‌توان به راحتی به نسخه‌های قبلی برگردد یا تغییرات را پیگیری کرد.ساب ورژن Subversion (SVN) یکی از این سیستم‌هاست که قبل از محبوبیت گسترده Git به‌طور گسترده‌ای استفاده می‌شد. در SVN، پروژه‌ها در یک مخزن (repository) مرکزی ذخیره می‌شوند. کاربران می‌توانند فایل‌ها را از مخزن دریافت کرده، تغییرات خود را اعمال کنند و سپس آن‌ها را به مخزن اصلی ارسال کنند. ویژگی‌های اصلی دنیای ساب‌ورژن:1. مخزن مرکزی: SVN از یک مخزن مرکزی استفاده می‌کند که همه تغییرات در آن ثبت می‌شوند. کاربران باید فایل‌ها را از مخزن مرکزی دریافت کنند و سپس تغییرات خود را به آن برگردانند.2. تاریخچه تغییرات: تمامی تغییرات فایل‌ها در مخزن مرکزی ثبت و ذخیره می‌شوند. این امکان به شما می‌دهد تا به نسخه‌های قدیمی‌تر فایل‌ها برگردید.3. قفل کردن فایل‌ها: در SVN، کاربران می‌توانند فایل‌ها را قفل کنند تا دیگران نتوانند به‌طور همزمان تغییراتی بر روی همان فایل اعمال کنند. این ویژگی در محیط‌های کاری که چندین نفر بر روی یک پروژه کار می‌کنند، مفید است.4. کار با شاخه‌ها و نسخه‌های مختلف: SVN اجازه می‌دهد تا شاخه‌های مختلفی از پروژه ایجاد شوند که در آن‌ها می‌توان به‌طور همزمان بر روی نسخه‌های مختلف پروژه کار کرد.در کل، دنیای ساب‌ورژن به نوعی به محیط یا نحوه کار با سیستم SVN اشاره دارد که کاربران و توسعه‌دهندگان برای مدیریت تغییرات و همکاری در پروژه‌ها از آن استفاده می‌کنند.تفاوت ساب ورژن و گیت در چیستتفاوت‌های کلیدی بین دنیای ساب‌ورژن (SVN) و گیت (Git) در معماری، نحوه مدیریت نسخه‌ها و کار با مخازن است. این تفاوت‌ها بر اساس نیازها و ساختار هر دو سیستم کنترل نسخه شکل گرفته‌اند. در اینجا به برخی از مهم‌ترین تفاوت‌ها اشاره می‌کنیم: 1. مخزن مرکزی در مقابل مخزن توزیع‌شده -ساب ورژن SVN (Subversion): یک سیستم کنترل نسخه متمرکز است. در این سیستم، یک مخزن مرکزی وجود دارد که تمام کاربران به آن متصل می‌شوند و تغییرات خود را به آن ارسال می‌کنند. اگر مخزن مرکزی در دسترس نباشد، کاربران نمی‌توانند نسخه‌های جدیدی از کد را ثبت (commit) کنند یا تاریخچه پروژه را بررسی کنند. -گیت Git: یک سیستم کنترل نسخه توزیع‌شده است. هر کاربر نسخه‌ای کامل از مخزن را روی سیستم خود دارد. بنابراین حتی بدون اتصال به مخزن اصلی، کاربران می‌توانند تغییرات را ثبت کرده و تاریخچه پروژه را بررسی کنند. هنگامی که کاربران آماده باشند، می‌توانند تغییرات خود را با مخزن اصلی همگام‌سازی (push) کنند. 2. مدیریت شاخه‌ها (Branches) -ساب ورژن SVN: ایجاد و مدیریت شاخه‌ها در SVN سنگین‌تر و کندتر است زیرا شاخه‌ها به عنوان پوشه‌های جداگانه در مخزن مرکزی ذخیره می‌شوند. این فرآیند می‌تواند منابع بیشتری را مصرف کند و کار با شاخه‌ها کمی پیچیده‌تر باشد. -گیت Git: در گیت، شاخه‌ها بسیار سبک و کارآمد هستند. ایجاد یک شاخه جدید و جابجایی بین شاخه‌ها سریع و بدون نیاز به منابع زیاد است. این ویژگی باعث شده است که توسعه‌دهندگان بیشتر از گیت برای مدیریت چندین نسخه از یک پروژه استفاده کنند. 3. تاریخچه تغییرات و ثبت نسخه‌ها -ساب ورژن SVN: تاریخچه تغییرات در SVN به صورت یک خطی و مرتب در مخزن مرکزی ذخیره می‌شود. تغییرات از کاربران مختلف به ترتیب زمانی ثبت می‌شوند. ثبت تغییرات باید به مخزن مرکزی ارسال شود و کاربران نیاز به اتصال به مخزن دارند. -گیت Git: در گیت، هر کاربر می‌تواند به صورت محلی تغییرات خود را ثبت کند. گیت با استفاده از یک گراف غیرخطی از تغییرات کار می‌کند که به کاربران اجازه می‌دهد به راحتی شاخه‌های مختلف را ادغام کنند و تاریخچه‌های موازی را مدیریت کنند. 4. کار بدون اتصال به اینترنت -ساب ورژن SVN: برای اکثر فعالیت‌ها مثل ثبت تغییرات یا دریافت آخرین نسخه از پروژه، نیاز به اتصال به مخزن مرکزی وجود دارد. -گیت Git: چون گیت به صورت توزیع‌شده عمل می‌کند، کاربران می‌توانند تغییرات را به صورت محلی ثبت کنند و تاریخچه پروژه را بدون نیاز به اتصال به اینترنت یا مخزن مرکزی بررسی کنند. 5. مدیریت فایل‌های بزرگ -ساب ورژن SVN: به طور معمول با فایل‌های بزرگ بهتر کنار می‌آید و برای پروژه‌هایی که فایل‌های بزرگتری دارند، بهینه‌تر عمل می‌کند. -گیت Git: گیت به طور پیش‌فرض برای مدیریت فایل‌های بزرگ طراحی نشده است و ممکن است برای پروژه‌هایی با فایل‌های بزرگ مشکلاتی ایجاد کند، مگر اینکه از ابزارهایی مثل Git LFS (Large File Storage) استفاده شود. 6. ادغام (Merge) -ساب ورژن SVN: ادغام در SVN می‌تواند پیچیده‌تر باشد و به دلیل ساختار متمرکز و شاخه‌های سنگین، مدیریت تعارضات و ادغام شاخه‌ها زمان‌برتر است. -گیت Git: ادغام شاخه‌ها در گیت سریع‌تر و ساده‌تر است. گیت به طور خودکار از ابزارهای قدرتمندی برای تشخیص و حل تعارضات استفاده می‌کند، که این فرآیند را برای توسعه‌دهندگان ساده‌تر می‌سازد. 7. کارایی (Performance) -ساب ورژن SVN: به دلیل ساختار متمرکز و نیاز به ارتباط مداوم با مخزن مرکزی، عملکرد SVN در مقایسه با گیت کندتر است، به ویژه در پروژه‌های بزرگ یا هنگام کار با شبکه‌های ضعیف. -گیت Git: با داشتن مخازن محلی، گیت عملکرد بسیار بهتری دارد. بسیاری از عملیات‌ها مانند ثبت تغییرات، ادغام، و بررسی تاریخچه به صورت محلی انجام می‌شود و سریع‌تر از SVN عمل می‌کند. 8. قفل کردن فایل‌ها -ساب ورژن SVN: یک ویژگی قفل کردن فایل دارد که به کاربران اجازه می‌دهد فایل‌هایی را قفل کنند تا دیگران نتوانند آن‌ها را هم‌زمان ویرایش کنند. این ویژگی در مواقعی که فایل‌ها نمی‌توانند به راحتی ادغام شوند (مثل فایل‌های باینری)، مفید است. -گیت Git: به طور پیش‌فرض از قفل کردن فایل‌ها استفاده نمی‌کند و بیشتر به کارهای موازی و ادغام نسخه‌ها متکی است. برای مدیریت فایل‌های باینری از ابزارهایی مثل Git LFS استفاده می‌شود. جمع‌بندی:- گیتGit بیشتر مناسب پروژه‌های بزرگ و تیم‌های توزیع‌شده است که نیاز به کار آفلاین، شاخه‌سازی سریع، و ادغام ساده دارند.-ساب ورژن SVN بیشتر در محیط‌های متمرکز و پروژه‌هایی با ساختار ساده‌تر و کمتر نیاز به شاخه‌های پیچیده به کار می‌رود.هر دو سیستم بسته به نیاز پروژه و تیم می‌توانند مزایای خاص خود را داشته باشند.ایا میتوانم برخی از پروژه هایی که از ساب ورژن استفاده میکنند را بشناسم؟برخی از پروژه‌ها و سازمان‌ها همچنان از Subversion (SVN) استفاده می‌کنند یا در گذشته به صورت گسترده از آن بهره برده‌اند. در اینجا چند مثال از کاربردهای SVN آورده شده است:1. Apache Software Foundation (ASF) - Apache، یکی از بزرگترین بنیادهای نرم‌افزاری جهان که پروژه‌های متن‌باز متعددی را مدیریت می‌کند، سال‌ها از SVN برای کنترل نسخه پروژه‌های خود استفاده کرده است. پروژه‌هایی مانند Apache HTTP Server و Apache Tomcat در ابتدا روی SVN مدیریت می‌شدند. 2. Google Code (گذشته) - Google Code، یک سرویس میزبانی پروژه‌های متن‌باز بود که از SVN به عنوان یکی از سیستم‌های کنترل نسخه پشتیبانی می‌کرد. توسعه‌دهندگان می‌توانستند پروژه‌های خود را با استفاده از SVN در این پلتفرم مدیریت کنند. البته، این سرویس اکنون دیگر فعال نیست و پروژه‌های بسیاری به GitHub یا Git منتقل شده‌اند.3. TortoiseSVN - TortoiseSVN یک ابزار گرافیکی محبوب برای ویندوز است که به کاربران اجازه می‌دهد با رابط کاربری ساده‌تری از Subversion استفاده کنند. این ابزار بیشتر توسط شرکت‌ها و تیم‌هایی استفاده می‌شود که پروژه‌های متمرکز دارند و می‌خواهند به سادگی از ویژگی‌های SVN بهره‌مند شوند.4. بازی‌های ویدیویی و توسعه نرم‌افزارهای بزرگ - در صنعت بازی‌های ویدیویی، برخی تیم‌های توسعه همچنان از SVN برای مدیریت نسخه پروژه‌های بزرگ استفاده می‌کنند. به دلیل حجم زیاد فایل‌های گرافیکی و ویدئویی، SVN گاهی اوقات انتخاب بهتری برای مدیریت فایل‌های بزرگ و باینری نسبت به Git است.5. CollabNet - CollabNet، یکی از توسعه‌دهندگان اصلی Subversion، از SVN به عنوان ابزار اصلی خود برای کنترل نسخه پروژه‌های نرم‌افزاری استفاده کرده است. این شرکت به توسعه و بهبود Subversion در سال‌های اولیه آن کمک زیادی کرده و همچنان به ارائه راهکارهای مبتنی بر SVN ادامه می‌دهد.6. شرکت‌های نرم‌افزاری قدیمی‌تر - بسیاری از شرکت‌های نرم‌افزاری بزرگ و قدیمی‌تر که سیستم‌های کنترل نسخه را از دهه ۲۰۰۰ آغاز کرده‌اند، به دلیل شروع کار خود با SVN، ممکن است همچنان از این سیستم استفاده کنند یا حداقل پروژه‌های قدیمی خود را روی آن مدیریت کنند. شرکت‌هایی که پروژه‌های زیادی دارند که به دلیل پیچیدگی و حجم بالای داده‌ها به سادگی به گیت منتقل نمی‌شوند، ممکن است همچنان از SVN استفاده کنند.7. پروژه‌های دانشگاهی و تحقیقاتی - برخی از پروژه‌های دانشگاهی یا تحقیقاتی که در دهه ۲۰۰۰ شروع شده‌اند، از SVN برای مدیریت نسخه‌های مقالات، کدها و داده‌های تحقیقاتی خود استفاده کرده‌اند. این پروژه‌ها ممکن است به دلیل شروع کار با SVN یا نیاز به سازگاری با ابزارهای قدیمی‌تر همچنان از این سیستم بهره ببرند.جمع‌بندی:اگرچه بسیاری از پروژه‌ها به سمت استفاده از Git و سرویس‌هایی مثل GitHub یا GitLab مهاجرت کرده‌اند، اما SVN همچنان در برخی از صنایع، شرکت‌ها و پروژه‌ها به عنوان یک راهکار متمرکز و مناسب برای مدیریت نسخه استفاده می‌شود، به خصوص در پروژه‌هایی که نیاز به کنترل دقیق‌تر یا مدیریت فایل‌های بزرگ دارند.

آموزش کار با گیت - به همراه معرفی و ترجمه کتاب پرو گیت pro git

سید احمد — Wed, 25 Sep 2024 00:12:55 +0330

ابتدا با معرفی کتاب پرو گیت شروع میکنمبرای معرفی این کتاب با یک سوال شروع میکنم و سپس مقدمه کتاب و معرفی فصل ها را برایتان می آورم. توجه داشته باشید. میتوانید از خواندن این نوشتار صرف نظر کنید و به خواندن جزیره ای یعنی مطابق نیاز خودتان روی بیاورید. اگر برای بار اول است که میخواهید کتاب را بخوانید توصیه میکنم معرفی فصل ها را بخوانید تا در ذهنتان ساختاری از کتاب شکل بگیرد تا بهتر بتوانید در اینده آن را به یاد بیاورید. ابتدا به تصویر زیر نگاه کنید و سپس به خوانش هر انچه تمایل دارید و صد البته خواندن معرفی فصل ها بپردازید.چرا کتاب Pro Git را بخوانیم؟پروگیت Pro Git یکی از جامع‌ترین و محبوب‌ترین منابع برای یادگیری Git است. این کتاب به شما کمک می‌کند تا درک عمیقی از این ابزار قدرتمند کنترل نسخه پیدا کنید و به طور موثر از آن در پروژه‌های خود استفاده کنید. در ادامه دلایلی که چرا باید این کتاب را بخوانید آورده شده است:آموزش گام به گام: کتاب Pro Git با زبانی ساده و روشی گام به گام، مفاهیم پیچیده Git را به شما آموزش می‌دهد. حتی اگر هیچ تجربه قبلی در زمینه کنترل نسخه نداشته باشید، با دنبال کردن این کتاب می‌توانید به راحتی Git را یاد بگیرید.پوشش جامع: این کتاب تمامی جنبه‌های Git را پوشش می‌دهد، از اصول اولیه تا مفاهیم پیشرفته‌تر. شما می‌توانید در مورد شاخه‌ها، ادغام، تگ‌ها، مخازن از راه دور، همکاری تیمی و بسیاری از موضوعات دیگر اطلاعات کسب کنید.مثال‌های عملی: کتاب Pro Git مملو از مثال‌های عملی است که به شما کمک می‌کنند مفاهیم را بهتر درک کنید. با انجام این مثال‌ها، می‌توانید مهارت‌های خود را در استفاده از Git تقویت کنید.بروزرسانی مداوم: نویسندگان کتاب Pro Git همواره تلاش می‌کنند تا کتاب را با آخرین تغییرات و ویژگی‌های Git به‌روز نگه دارند. بنابراین، با خواندن این کتاب، مطمئن هستید که از آخرین اطلاعات در مورد Git برخوردار هستید.منبع باز: کتاب Pro Git به صورت منبع باز منتشر شده است. این بدان معناست که شما می‌توانید به صورت رایگان به متن کامل کتاب دسترسی داشته باشید و حتی در بهبود آن مشارکت کنید.جامعه بزرگ: کتاب Pro Git یک جامعه بزرگ از کاربران و توسعه‌دهندگان دارد. شما می‌توانید در انجمن‌های آنلاین مربوط به این کتاب شرکت کنید و سوالات خود را بپرسید و از تجربیات دیگران بهره‌مند شوید.به طور خلاصه، اگر می‌خواهید به یک کاربر حرفه‌ای Git تبدیل شوید، خواندن کتاب Pro Git یکی از بهترین تصمیم‌هایی است که می‌توانید بگیرید.در ادامه مقدمه اسکات چکون و بن استراب را میخوانیم.مقدمه اسکات چکونبه نسخه دوم کتاب Pro Git خوش آمدید. نسخه اول بیش از چهار سال پیش منتشر شد. از آن زمان، تغییرات زیادی رخ داده است، اما بسیاری از موارد مهم تغییر نکرده‌اند. در حالی که اکثر دستورات و مفاهیم اصلی امروزه همچنان معتبر هستند، زیرا تیم اصلی Git در حفظ سازگاری رو به عقب بسیار خوب عمل می‌کند، برخی تغییرات و افزوده‌های قابل توجهی در جامعه اطراف Git رخ داده است. نسخه دوم این کتاب با هدف رسیدگی به این تغییرات و به‌روزرسانی کتاب برای کمک بیشتر به کاربران جدید نوشته شده است.هنگامی که نسخه اول را نوشتم، Git هنوز یک ابزار نسبتاً دشوار برای استفاده و به‌سختی پذیرفته شده برای هکرهای هسته‌ای سخت‌گیر بود. این ابزار در برخی جوامع شروع به محبوبیت کرد، اما هنوز به همه جا نفوذ نکرده بود. از آن زمان، تقریباً هر جامعه منبع باز آن را پذیرفته است. Git پیشرفت چشمگیری در ویندوز، در انفجار رابط‌های کاربری گرافیکی برای همه پلتفرم‌ها، در پشتیبانی IDE و در استفاده تجاری داشته است. Pro Git چهار سال پیش هیچ یک از این موارد را می‌دانست. یکی از اهداف اصلی این نسخه جدید، لمس کردن این مرزهای جدید در جامعه Git است.جامعه منبع باز نیز در استفاده از Git انفجار بزرگی داشته است. زمانی که تقریباً پنج سال پیش برای نوشتن کتاب نشستم (مدت زیادی طول کشید تا نسخه اول را منتشر کنم)، تازه شروع به کار در یک شرکت بسیار ناشناخته کرده بودم که یک وب‌سایت میزبانی Git به نام GitHub را توسعه می‌داد. در زمان انتشار، شاید چند هزار نفر از این سایت استفاده می‌کردند و تنها چهار نفر روی آن کار می‌کردند. در حالی که من این مقدمه را می‌نویسم، GitHub در حال اعلام پروژه میزبان دهم میلیون خود است، با نزدیک به ۵ میلیون حساب توسعه‌دهنده ثبت شده و بیش از ۲۳۰ کارمند. چه آن را دوست داشته باشید یا نه، GitHub بخش‌های بزرگی از جامعه منبع باز را به روشی تغییر داده است که در زمان نوشتن نسخه اول قابل تصور نبود.در نسخه اصلی Pro Git، بخش کوچکی درباره GitHub به عنوان یک مثال از میزبانی Git نوشتم که هرگز احساس راحتی با آن نداشتم. من زیاد دوست نداشتم که چیزی را می‌نوشتم که احساس می‌کردم اساساً یک منبع جامعه است و همچنین در مورد شرکت خودم در آن صحبت می‌کردم. اگرچه هنوز هم این تضاد منافع را دوست ندارم، اهمیت GitHub در جامعه Git غیرقابل انکار است. به جای یک مثال از میزبانی Git، تصمیم گرفتم آن بخش از کتاب را به توصیف دقیق‌تر آنچه GitHub است و نحوه استفاده مؤثر از آن تبدیل کنم. اگر می‌خواهید یاد بگیرید که چگونه از Git استفاده کنید، دانستن نحوه استفاده از GitHub به شما کمک می‌کند تا در یک جامعه بزرگ شرکت کنید، که این موضوع ارزشمند است، صرف نظر از اینکه کدام میزبان Git را برای کد خود انتخاب می‌کنید.تغییر بزرگ دیگر در زمان انتشار آخرین نسخه، توسعه و ظهور پروتکل HTTP برای تراکنش‌های شبکه Git بوده است. اکثر مثال‌ها در کتاب از SSH به HTTP تغییر کرده‌اند، زیرا بسیار ساده‌تر است.تماشای رشد Git در چند سال گذشته از یک سیستم کنترل نسخه نسبتاً نامشخص تا تسلط بر کنترل نسخه تجاری و منبع باز شگفت‌انگیز بوده است. خوشحالم که Pro Git نیز موفق بوده است و یکی از معدود کتاب‌های فنی موجود در بازار است که هم بسیار موفق و هم کاملاً منبع باز است.امیدوارم از این نسخه به‌روز شده Pro Git لذت ببرید.مقدمه نوشته بن استراوبنسخه اول این کتاب همان چیزی بود که مرا به Git معتاد کرد. این کتاب معرفی من به سبکی از ساخت نرم‌افزار بود که طبیعی‌تر از هر چیزی که قبلاً دیده بودم احساس می‌شد. تا آن زمان، چندین سال توسعه‌دهنده بودم، اما این بود که من را به مسیر بسیار جالب‌تری نسبت به مسیری که در آن بودم هدایت کرد.اکنون، سال‌ها بعد، من یک مشارکت‌کننده در یک پیاده‌سازی اصلی Git هستم، برای بزرگ‌ترین شرکت میزبانی Git کار کرده‌ام و در سراسر جهان به مردم در مورد Git آموزش داده‌ام. زمانی که اسکات از من پرسید آیا علاقه‌مند به کار روی نسخه دوم هستم، حتی نیازی به فکر کردن نداشتم.کار روی این کتاب لذت و افتخار بزرگی بوده است. امیدوارم این کتاب به شما همان اندازه که به من کمک کرد، کمک کند.تقدیم‌نامه بن استراوب:"به همسرم، بکی، بدون او این ماجرا هرگز آغاز نمی‌شد."تقدیم‌نامه اسکات چاکون:"این نسخه به دخترانم تقدیم می‌شود. به همسرم جسیکا که در طول این سال‌ها از من حمایت کرده است و به دخترم جوزفین، که از من حمایت خواهد کرد وقتی خیلی پیر شده باشم و ندانم چه اتفاقی در حال رخ دادن است."نسخه کنونی کتاب پرو گیت:Pro GitScott Chacon, Ben StraubVersion 2.1.434, 2024-09-04معرفی فصل های کتابدر این کتاب، در طول چند ساعت، به دنیای Git قدم خواهید گذاشت. بیایید ابتدا یک خلاصه از ده فصل و سه ضمیمه این کتاب ارائه دهیم.در فصل اول، به معرفی سیستم‌های کنترل نسخه (VCS) و اصول اولیه Git می‌پردازیم. بدون پیچیدگی‌های فنی، توضیح می‌دهیم که Git چیست، چرا در دنیایی پر از VCSها به وجود آمد، چه ویژگی‌هایی آن را متمایز می‌کند و چرا بسیاری از افراد از آن استفاده می‌کنند. سپس، نحوه دانلود و تنظیم Git را برای اولین بار توضیح می‌دهیم، در صورتی که هنوز آن را بر روی سیستم خود نصب نکرده باشید.در فصل دوم، به استفاده‌های پایه Git خواهیم پرداخت – نحوه استفاده از Git در 80% از مواردی که بیشترین مواجهه را خواهید داشت. پس از خواندن این فصل، باید بتوانید یک مخزن را کپی کنید، تاریخچه پروژه را مشاهده کنید، فایل‌ها را اصلاح کنید و تغییرات خود را ارسال کنید. اگر در این مرحله کتاب خودبه خود بسوزد، باید در مدت زمانی که برای برداشتن یک نسخه دیگر نیاز دارید، به اندازه کافی در استفاده از Git مهارت کسب کرده باشید. منظور طنزگونه این است که مثلا اگر کتاب به‌طور ناگهانی آتش بگیرد و از بین برود، شما تا این مرحله از یادگیری باید آن‌قدر در استفاده از Git مهارت پیدا کرده باشید که حتی در زمانی که به دنبال تهیه یک نسخه جدید از کتاب هستید، بتوانید به‌خوبی از Git استفاده کنید.فصل سوم به مدل شاخه‌بندی branching در Git می‌پردازد، که اغلب به عنوان ویژگی برتر Git توصیف می‌شود. در اینجا، یاد خواهید گرفت که چه چیزی Git را از سایر سیستم‌های کنترل نسخه متمایز می‌کند. پس از پایان این فصل، ممکن است احساس کنید که نیاز به یک لحظه سکوت برای تأمل در مورد اینکه چگونه پیش از حضور شاخه‌بندی Git زندگی می‌کردید، دارید.فصل چهارم به Git روی سرور می‌پردازد. این فصل برای کسانی است که می‌خواهند Git را در داخل سازمان خود یا بر روی سرور شخصی خود برای همکاری تنظیم کنند. همچنین، گزینه‌های مختلف میزبانی را بررسی خواهیم کرد اگر ترجیح می‌دهید این کار را به شخص دیگری بسپارید.فصل پنجم به طور کامل به جریان های کاری توزیع شده distributed workflows و نحوه انجام آن‌ها با Git می‌پردازد. پس از پایان این فصل، باید بتوانید به طور ماهرانه با چندین مخزن از راه دور کار کنید، از Git از طریق ایمیل استفاده کنید و به طور ماهرانه شاخه‌های متعدد از راه دور و وصله‌های ارسالی را مدیریت کنید.فصل ششم به سرویس میزبانی و ابزارهای GitHub می‌پردازد. ما در مورد ثبت نام و مدیریت یک حساب کاربری، ایجاد و استفاده از مخازن Git، روش‌های کار مشترک در پروژه‌ها و دریافت مشارکت‌ها، رابط برنامه‌نویسی GitHub و بسیاری از نکات کوچک دیگر برای آسان‌تر کردن زندگی شما صحبت خواهیم کرد.فصل هفتم به دستورات پیشرفته Git می‌پردازد. در اینجا، در مورد موضوعاتی مانند تسلط بر دستور ترسناک 'reset'، استفاده از جستجوی باینری برای شناسایی باگ‌ها، ویرایش تاریخچه، انتخاب دقیق نسخه‌ها و موارد دیگر یاد خواهید گرفت. این فصل دانش شما را تکمیل می‌کند تا واقعاً یک استاد Git شوید.فصل هشتم به پیکربندی محیط سفارشی Git شما می‌پردازد. این شامل تنظیم اسکریپت‌های هوک برای اعمال یا تشویق سیاست‌های سفارشی و استفاده از تنظیمات پیکربندی محیط برای کار به روش دلخواه شما است. همچنین، ما در مورد ساخت مجموعه اسکریپت‌های خود برای اعمال یک سیاست تعهد سفارشی صحبت خواهیم کرد.فصل نهم به Git و سایر VCSها می‌پردازد. این شامل استفاده از Git در دنیای ساب ورژن (زیرنسخه) Subversion (SVN) و تبدیل پروژه‌ها از سایر VCSها به Git است. بسیاری از سازمان‌ها هنوز از SVN استفاده می‌کنند و قصد تغییر ندارند، اما در این مرحله، شما قدرت خارق‌العاده Git را یاد خواهید گرفت – و این فصل نشان می‌دهد که چگونه در صورت نیاز به استفاده از یک سرور SVN کنار بیایید. همچنین، نحوه وارد کردن پروژه‌ها از چندین سیستم مختلف را در صورت متقاعد کردن همه برای تغییر به Git پوشش می‌دهیم. برای مطالعه درباره ساب ورژن به اینجا مراجعه کنید: فصل دهم به اعماق تاریک اما زیبای داخلی Git می‌پردازد. اکنون که همه چیز را در مورد Git می‌دانید و می‌توانید با قدرت و زیبایی از آن استفاده کنید، می‌توانید به بحث در مورد نحوه ذخیره اشیاء توسط Git، مدل شیء آن، جزئیات فایل‌های بسته، پروتکل‌های سرور و موارد دیگر بپردازید. در طول کتاب، به بخش‌هایی از این فصل اشاره خواهیم کرد، در صورتی که احساس کردید در آن زمان می‌خواهید عمیق‌تر شوید؛ اما اگر مانند ما به جزئیات فنی علاقه دارید، ممکن است بخواهید ابتدا فصل دهم را بخوانید. این انتخاب به عهده شماست.در ضمیمه A، به چندین مثال از استفاده از Git در محیط‌های مختلف خاص نگاه می‌کنیم. ما چندین GUI و محیط‌های برنامه‌نویسی IDE را که ممکن است بخواهید Git را در آن‌ها استفاده کنید و آنچه در دسترس شما است را پوشش می‌دهیم. اگر به دنبال یک مرور کلی در مورد استفاده از Git در پوسته، IDE یا ویرایشگر متن خود هستید، به اینجا نگاه کنید.در ضمیمه B، ما اسکریپت‌نویسی و گسترش Git را از طریق ابزارهایی مانند libgit2 و JGit بررسی می‌کنیم. اگر به نوشتن ابزارهای سفارشی پیچیده و سریع و نیاز به دسترسی سطح پایین به Git علاقه دارید، اینجاست که می‌توانید ببینید این چشم‌انداز چگونه است.سرانجام، در ضمیمه C، ما به بررسی تک تک دستورات اصلی Git می‌پردازیم و مرور می‌کنیم که در کدام بخش از کتاب آن‌ها را پوشش دادیم و چه کاری با آن‌ها انجام دادیم. اگر می‌خواهید بدانید که در کدام بخش از کتاب از هر دستور خاص Git استفاده کردیم، می‌توانید در اینجا آن را جستجو کنید.بیایید شروع کنیم.

راهنمای جامع سیستم‌های کنترل نسخه (Git) برای برنامه‌نویسان

سید احمد — Mon, 16 Sep 2024 02:34:31 +0330

سیستم‌های کنترل نسخه (Version Control Systems یا VCS) ابزارهایی قدرتمند هستند که به توسعه‌دهندگان نرم‌افزار کمک می‌کنند تا تغییرات ایجاد شده در کد منبع را مدیریت کنند. این سیستم‌ها به شما امکان می‌دهند تا نسخه‌های مختلف از کد خود را ذخیره کنید، تغییرات را پیگیری کنید، همکاری بهتری با سایر توسعه‌دهندگان داشته باشید و در صورت بروز مشکل، به نسخه‌های قبلی بازگردید. یکی از محبوب‌ترین سیستم‌های کنترل نسخه، Git است. در ادامه به بررسی سوالات در مورد Git میپردازم.1. در مورد سیستم‌های کنترل نسخه چه می‌دانید؟سیستم‌های کنترل نسخه (VCS) ابزارهایی هستند که به توسعه‌دهندگان اجازه می‌دهند تا تغییرات ایجاد شده در فایل‌ها (معمولاً کد منبع) را در طول زمان ردیابی کنند. این سیستم‌ها با ایجاد یک تاریخچه از تغییرات، به شما امکان می‌دهند تا به نسخه‌های قبلی بازگردید، تغییرات را مقایسه کنید و همکاری بهتری با سایر توسعه‌دهندگان داشته باشید.2. تفاوت بین سیستم‌های کنترل نسخه متمرکز و توزیع شده چیست؟سیستم‌های کنترل نسخه متمرکز (Centralized VCS): در این سیستم‌ها، یک مخزن مرکزی وجود دارد که تمام تغییرات در آن ذخیره می‌شود. توسعه‌دهندگان باید از این مخزن مرکزی برای دریافت آخرین تغییرات و ارسال تغییرات خود استفاده کنند.سیستم‌های کنترل نسخه توزیع شده (Distributed VCS): در این سیستم‌ها، هر توسعه‌دهنده یک کپی کامل از مخزن مرکزی را در دستگاه خود دارد. این به معنای آن است که هر توسعه‌دهنده می‌تواند به صورت آفلاین کار کند و تغییرات خود را به صورت محلی ذخیره کند. سپس، این تغییرات می‌توانند با مخزن مرکزی همگام‌سازی شوند. Git یک نمونه از سیستم‌های کنترل نسخه توزیع شده است.3. عبارت git push به چه معناست؟دستورgit push دستوری است که برای ارسال تغییرات محلی شما از مخزن محلی به یک مخزن از راه دور استفاده می‌شود. به عبارت دیگر، با استفاده از این دستور، تغییرات شما به اشتراک گذاشته می‌شود تا سایر توسعه‌دهندگان بتوانند به آن‌ها دسترسی داشته باشند.4. عبارت git pull به چه معناست؟دستور git pull دستوری است که برای دریافت آخرین تغییرات از یک مخزن از راه دور و ادغام آن‌ها با مخزن محلی شما استفاده می‌شود. به عبارت دیگر، با استفاده از این دستور، شما می‌توانید مخزن محلی خود را با آخرین تغییرات ایجاد شده توسط سایر توسعه‌دهندگان به روز کنید.5. دستور git config چه کاری انجام می دهد؟دستور git config دستوری است که برای تنظیم پیکربندی‌های مختلف در Git استفاده می‌شود. این تنظیمات می‌تواند شامل نام کاربری، ایمیل، ویرایشگر پیش‌فرض و بسیاری از تنظیمات دیگر باشد.6. دستور git init چه کاری انجام می دهد؟دستور git init دستوری است که برای ایجاد یک مخزن Git جدید در یک دایرکتوری استفاده می‌شود. این دستور یک دایرکتوری مخفی به نام .git ایجاد می‌کند که تمام اطلاعات مربوط به مخزن را در خود ذخیره می‌کند.7. دستور git add چه می کند؟دستور git add دستوری است که برای اضافه کردن تغییرات جدید به ناحیه‌ی staging استفاده می‌شود. ناحیه‌ی staging جایی است که تغییرات قبل از commit شدن در آن نگهداری می‌شوند.8. دستور git diff چه کاری انجام می دهد؟دستور git diff دستوری است که برای نمایش تفاوت بین دو نسخه از یک فایل یا بین فایل‌های stage شده و فایل‌های کاری استفاده می‌شود.9. دستور git commit چه کاری انجام می دهد؟دستور git commit دستوری است که برای ایجاد یک عکس فوری از تغییرات فعلی در ناحیه‌ی staging استفاده می‌شود. هر commit یک نقطه بازیابی ایجاد می‌کند که در آینده می‌توانید به آن بازگردید.10. دستور git reset چه کاری انجام می دهد؟دستور git reset دستوری است که برای بازگرداندن تغییرات به یک commit قبلی یا برای حذف فایل‌ها از ناحیه‌ی staging استفاده می‌شود.11. دستور git status چه کاری انجام می دهد؟دستور git status دستوری است که برای نمایش وضعیت فعلی مخزن شما استفاده می‌شود. این دستور به شما نشان می‌دهد که کدام فایل‌ها تغییر کرده‌اند، کدام فایل‌ها به ناحیه‌ی staging اضافه شده‌اند و کدام commit‌ها هنوز به مخزن از راه دور ارسال نشده‌اند.12. دستور git merge چه کاری انجام می دهد؟دستور git merge دستوری است که برای ادغام دو شاخه در Git استفاده می‌شود.13. دستور git pull چه کار می کند؟همانطور که قبلاً توضیح داده شد، git pull دستوری است که برای دریافت آخرین تغییرات از یک مخزن از راه دور و ادغام آن‌ها با مخزن محلی شما استفاده می‌شود.14. دستور git fetch چه کاری انجام می دهد؟دستور git fetch دستوری است که برای دریافت آخرین تغییرات از یک مخزن از راه دور به مخزن محلی شما استفاده می‌شود، اما این تغییرات را بلافاصله ادغام نمی‌کند. ابتدا باید با استفاده از دستور git merge این تغییرات را ادغام کنید.15. عبارت git pull چه تفاوتی با git fetch دارد؟دستور git pull ترکیبی از دو دستور git fetch و git merge است. یعنی ابتدا تغییرات را از مخزن از راه دور دریافت می‌کند و سپس آن‌ها را با شاخه فعلی شما ادغام می‌کند. در حالی که git fetch فقط تغییرات را دریافت می‌کند و ادغام را به عهده‌ی شما می‌گذارد.16. توضیح دهید که تضاد ادغام در Git چیست؟تضاد ادغام زمانی رخ می‌دهد که دو شاخه به طور مستقل از هم تغییراتی را در همان بخش از یک فایل ایجاد کنند. در این صورت، Git نمی‌تواند به طور خودکار این تغییرات را ادغام کند و از شما می‌خواهد که به صورت دستی تضاد را حل کنید.17. چگونه یک تضاد ادغام را در Git حل می کنید؟برای حل تضاد ادغام، باید فایل‌های دارای تضاد را به صورت دستی ویرایش کنید و تغییرات مورد نظر خود را حفظ کنید. سپس، می‌توانید تغییرات را مجدداً به ناحیه‌ی staging اضافه کرده و commit کنید.18. به من بگویید درباره git stash چه می دانید؟دستور git stash دستوری است که برای موقتاً پنهان کردن تغییرات نشده در ناحیه‌ی staging استفاده می‌شود. این کار زمانی مفید است که می‌خواهید به یک شاخه دیگر بروید یا یک کار جدید را شروع کنید، اما می‌خواهید تغییرات فعلی خود را از دست ندهید.19. عبارت git merge چه تفاوتی با git rebase دارد؟دستور git merge: برای ادغام دو شاخه به صورت خطی استفاده می‌شود. در این روش، یک commit جدید ایجاد می‌شود که نشان‌دهنده‌ی ادغام دو شاخه است.دستور git rebase: برای ادغام دو شاخه به صورت غیرخطی استفاده می‌شود. در این روش، commit‌های یک شاخه روی شاخه‌ی دیگر پیوند زده می‌شوند.مفاهیم پیشرفته‌تر Gitشاخه‌ها (Branches) در Gitشاخه چیست؟ یک شاخه در Git، یک خط زمانی مستقل از تغییرات است. به عبارت دیگر، هر شاخه یک نسخه جداگانه از مخزن شما را نشان می‌دهد.چرا از شاخه استفاده می‌کنیم؟کار بر روی ویژگی‌های جدید به صورت موازی: می‌توانید برای هر ویژگی جدید یک شاخه ایجاد کنید و بدون اینکه روی کد اصلی تأثیر بگذارید، روی آن کار کنید.رفع باگ‌ها: می‌توانید یک شاخه جداگانه برای رفع باگ‌ها ایجاد کنید.** آزمایش تغییرات:** می‌توانید تغییرات آزمایشی را در یک شاخه جداگانه اعمال کنید و اگر نتیجه دلخواه را نگرفتید، آن شاخه را حذف کنید.دستورات مهم مربوط به شاخه‌ها:دستور git branch: لیست تمام شاخه‌ها را نشان می‌دهد.دستور git branch <نام_شاخه>: یک شاخه جدید ایجاد می‌کند.دستور git checkout <نام_شاخه>: به شاخه مشخص شده تغییر می‌کند.دستور git merge <نام_شاخه>: شاخه مشخص شده را با شاخه فعلی ادغام می‌کند.دستور git branch -d <نام_شاخه>: شاخه مشخص شده را حذف می‌کند.تگ‌ها (Tags) در Gitتگ چیست؟ یک تگ، یک نشانگر ثابت به یک commit خاص است. از تگ‌ها برای مشخص کردن نسخه‌های مهم نرم‌افزار، مانند نسخه‌های منتشر شده، استفاده می‌شود.چرا از تگ استفاده می‌کنیم؟نشانه‌گذاری نسخه‌های مهم: با استفاده از تگ، می‌توانید به راحتی به یک نسخه خاص از نرم‌افزار بازگردید.ایجاد نقاط مرجع: تگ‌ها به عنوان نقاط مرجع برای انتشار نرم‌افزار عمل می‌کنند.دستورات مهم مربوط به تگ‌ها:git tag: لیست تمام تگ‌ها را نشان می‌دهد.git tag <نام_تگ> : یک تگ جدید ایجاد می‌کند.git checkout <نام_تگ>: به commit مشخص شده توسط تگ تغییر می‌کند.راهکارهای پیشرفته برای حل تضادهای ادغامویرایش دستی فایل‌ها: این روش معمول‌ترین روش برای حل تضاد است. شما باید به صورت دستی فایل‌های دارای تضاد را ویرایش کرده و تغییرات مورد نظر خود را حفظ کنید.استفاده از ابزارهای ادغام بصری: برخی از ابزارهای Git مانند GitHub Desktop و GitKraken دارای رابط کاربری گرافیکی هستند که به شما کمک می‌کنند تا تضادهای ادغام را به صورت بصری حل کنید.استفاده از ابزارهای خط فرمان: ابزارهایی مانند diff3 می‌توانند به شما در مقایسه‌ی تفاوت‌های بین نسخه‌های مختلف یک فایل کمک کنند.کار با مخازن از راه دورمخزن از راه دور چیست؟ یک مخزن از راه دور، یک کپی از مخزن محلی شما است که در یک سرور قرار دارد.دستورات مهم مربوط به مخازن از راه دور:git remote add <نام_مخزن> <آدرس_مخزن>: یک مخزن از راه دور جدید اضافه می‌کند.git push <نام_مخزن> <شاخه>: تغییرات را به مخزن از راه دور ارسال می‌کند.git pull <نام_مخزن> <شاخه>: تغییرات را از مخزن از راه دور دریافت می‌کند و با شاخه محلی ادغام می‌کند.همکاری با سایر توسعه‌دهندگان در Gitمعنای Fork کردن یک مخزن: ایجاد یک کپی از یک مخزن موجود در حساب کاربری خود.معنای Pull Request: ارسال درخواست برای ادغام تغییرات شما در مخزن اصلی.معنای Code Review: بررسی کد شما توسط سایر توسعه‌دهندگان قبل از ادغام.مفاهیم پیشرفته‌تر دیگرمعنای Git Hooks: اسکریپت‌هایی که در رویدادهای مختلف Git اجرا می‌شوند.معنای Submodules: اضافه کردن یک مخزن Git به عنوان زیرمجموعه‌ای از مخزن اصلی.معنای Rebasing: بازنویسی تاریخچه‌ی commit‌ها.معنای Cherry-picking: انتخاب و اعمال commit‌های خاص از یک شاخه به شاخه دیگر.منابع آموزشی بیشتر برای یادگیری Gitعالی است که به دنبال یادگیری بیشتر در مورد Git هستید. این ابزار قدرتمند، ابزاری ضروری برای هر برنامه‌نویس است. در ادامه به شما منابع مختلفی را معرفی می‌کنم که می‌توانید برای یادگیری بیشتر از آن‌ها استفاده کنید:کتاب‌های آنلاین و الکترونیکیکتاب Pro Git: این کتاب به صورت آنلاین به صورت رایگان در دسترس است و یکی از جامع‌ترین منابع برای یادگیری Git است. این کتاب به زبان ساده و با مثال‌های عملی، مفاهیم Git را توضیح می‌دهد.کتاب گیت برا یتیم ها Git for Teams: این کتاب بر روی استفاده از Git در محیط‌های تیمی تمرکز دارد و بهترین روش‌ها برای کار گروهی با Git را ارائه می‌دهد.کتاب گیت در عمل Git in Practice: این کتاب به شما کمک می‌کند تا Git را در دنیای واقعی و در پروژه‌های خود پیاده‌سازی کنید.دوره‌های آنلاینیادگیری انلاین: پلتفرمی است که به صورت تعاملی و گام به گام به شما آموزش می‌دهد که چگونه از Git و GitHub استفاده کنید.https://learngitbranching.js.org/سایت های آموزشی Coursera, Udemy, edX: این پلتفرم‌های آموزشی آنلاین، دوره‌های مختلفی در مورد Git ارائه می‌دهند که توسط اساتید و متخصصان این حوزه تدریس می‌شوند.پلتفرم YouTube: بسیاری از آموزش‌های رایگان و باکیفیت در مورد Git در یوتیوب وجود دارد. کانال‌های مختلفی مانند Traversy Media، freeCodeCamp و The Coding Train ویدیوهای آموزشی بسیار خوبی در این زمینه ارائه می‌دهند.دانلود کتاب Pro Git https://git-scm.com/book/en/v2