مقدمه

چرا گیت؟

چرا کوئرا کالج گیت؟

نگاه کلی به کالج گیت

قالب کوئرا کالج

سیستم دریافت گواهی

مقدمه‌ای بر گیت

درس‌نامه‌های کوئرا کالج

اهداف فصل

نصب گیت

تنظیمات اولیه

راه‌اندازی کلید SSH

آموزش مقدماتی ترمینال

تمرینال

آغاز کار با گیت

آشنایی با ریپازیتوری

دستورات init و clone و remote add

دستورات add و status

نحوه کار با سیستم داوری گیت

مرتب‌سازی کتاب

دستور commit

دستور tag

ریویو کتاب

فایل gitignore.

جنگوگیگنور

دستورات pull و push و fetch

دیباگ ماشین‌حساب

مرور وضعیت فایل‌ها

جمع‌بندی

برنچ و مرج

برنچ چیست؟

آموزش visualizer

دستورات checkout و branch

نحوه نام‌گذاری برنچ‌ها

سنگ‌کاغذ‌قیچی

دستور merge

مرجر

کانفلیکت چیست؟

حل کردن کانفلیکت‌ها

تکمیل پروژه

ریفکتور چلنج

Tracking Branches

دستور rebase

سینگل پراجکت

تشخیص و اصلاح خطا

دستور rm

دستور clean

دستور log

دستور restore

دستور revert

فلگ amend در دستور commit

ریورت کیوچت

دستور reset

ریست کیوچت

دستورات تکمیلی

دستور stash

دستور diff

alias

دستور bisect

دستور cherry-pick

فلپی برد

مباحث عملی

پول ریکوئست

github

gitlab

تمرین خدافظی

workflows

کار با pycharm

کار با vs code

کار با gitkraken

نصب و راه‌اندازی پایتون

گیت در صنعت

فرآیندهای مدیریت توسعه‌ پروژه در کوئرا

ساختار کلی نوشتن کدها در یکتانت

مدیریت اضافه شدن امکانات جدید در تپسی

استراتژی مرج کردن در تپسی

گپ و گفتی با تیم گندم درباره توسعه پروژه‌های اندرویدی

نحوه مدیریت کار‌ها در رمزینکس

فرآیند اضافه شدن امکانات جدید در قرار

**فرض کنید مدیر یک پروژه کامپیوتری هستید. چگونه این پروژه را مدیریت می‌کنید؟ آیا تغییرات کلی را برنامه ریزی و در مدت طولانی اعمال می‌کنید یا با تغییرات کوچک این پروژه را پیش می‌برید؟ به طور کلی دو مورد گفته شده، دو رویکرد متفاوت در مدیریت پروژه‌های کامپیوتری است.**

امروزه یکی از ویژگی‌های مهم پیشبرد پروژه‌های کامپیوتری، بهبود مستمر است. بهبود مستمر یعنی افزودن ویژگی‌ها (*features*) و رفع اشکال‌های (*bugs*) برنامه در بهبود‌های کوچک به کد اصلی اضافه شود. حال به این فکر کنید که چگونه می‌توانید یک پروژه‌ی کامپیوتری را که تعداد زیادی برنامه‌نویس روی آن کار می‌کنند، مدیریت کنید؟

فرض کنید به همراه دوستتان قصد دارید یک پرو‌ژه‌ی ساده بزنید. ابتدا شما فایل‌های اولیه پروژه را روی سیستم‌تان ایجاد می‌کنید. چگونه می‌خواهید این پروژه را به دوستتان بدهید؟ شاید جواب شما انتقال فایل‌ها از طریق یک فلش باشد! ولی پس از این انتقال، شما روی سیستم خودتان و دوستتان روی سیستم خودش یک نسخه متفاوت از پروژه را پیش می‌برید. به وضوح اشکال‌های زیادی در این نحوه‌ پیشبرد پروژه وجود دارد. نه تنها شما نمی‌توانید از بخش‌هایی که فرد دیگر زده استفاده کنید، بلکه فرآیند به هم چسباندن این دو پروژه کاری بسیار سخت خواهد بود. (مخصوصا اگر روی فایل‌های یکسانی کار کنید) 

حال شاید این راه به فکرتان برسد که هرکس روی یک بخش از پروژه کار کند و پس از تمام شدن کارش، کل پروژه روی فلش به فرد دیگر منتقل شود. ولی این کار به شدت سرعت پیشرفت کار را گرفته و معنای کار گروهی را زیر سوال می‌برد!

مشکلات فراوان دیگری در این نوع راه‌حل‌ها وجود دارد. مثلا اگر چند روز پیش چند تغییر در فایل‌های پروژه ایجاد کرده باشید و امروز متوجه شده باشید کار شما اشتباه بوده است، هیچ راه ساده‌ای برای جبران این اشتباه وجود ندارد و باید هر فایل را باز کرده و تغییرات را (اگر یادتان باشد!) برگردانید. بهترین راهی که به فکر می‌رسد آن است که پروژه روی یک سرور قرار بگیرد. بدین ترتیب شما و دوستتان می‌توانید پروژه را کم‌کم پیش ببرید. اما باز هم مشکلات بالا تا حد زیادی وجود دارند و باید به دنبال راه حلی برای کنترل پیشرفت پروژه بود.

برای حل این مشکلات سیستم‌های کنترل نسخه (*VCS: Version Control Systems*) پدید آمدند. این سیستم‌ها با نگه‌داری نسخه‌هایی از تاریخچه‌ی پروژه، به مدیریت آن کمک می‌کنند. گیت یکی از بهترین سیستم‌های کنترل نسخه است. 

در گیت هر کسی روی سیستم خود یک نسخه از پروژه را دارد و یک نسخه هم روی یک سرور راه دور (*remote*)‌ گذاشته می‌شود. هر کسی تغییرات مورد نظرش را روی سیستم خودش اعمال کرده و در نهایت آن‌ها را روی سرور اعمال می‌کند. همچنین هرگاه نیاز داشته باشد می‌تواند از سرور نسخه‌ی جدید را دریافت کند تا تغییرات دیگران را روی سیستم خودش داشته باشد. گیت در عین سادگی، امکانات و ویژگی‌های بسیار پیشرفته‌ای دارد که به تدریج در طول این دوره با آن‌ها آشنا خواهید شد. تمام مشکلات مطرح شده در بالا و بسیاری نیازمندی‌های دیگر توسط گیت کاملا برطرف می‌شوند.

گیت نسخه‌های مختلفی از پروژه را ایجاد می‌کند. هر نسخه از پروژه را یک کامیت (*commit*) می‌نامیم. به طور مثال در شکل زیر برنامه در کامیت ۱ دارای اشکال است و در کامیت ۲ این اشکال برطرف شده است. باید بدانیم که کامیت موجودی تغییرناپذیر (*immutable*) است. یعنی هر نسخه‌ای از پروژه که ایجاد می‌شود به هیچ وجه تغییر نمی‌کند و اگر تغییراتی را روی آن ایجاد کنیم، در واقع نسخه‌ای جدید ایجاد کرده‌ایم.

![template](https://quera.ir/qbox/view/y4tyY9ajSh/template.png)

حال ممکن است برایتان سوال شود که گیت چگونه عمل می‌کند؟ آیا گیت برای هر نسخه، از تمام فایل‌های پروژه کپی می‌گیرد؟ برای جواب دادن به این سوالات باید بدانیم که گیت به صورت بهینه طراحی شده است. به طور مثال فرض کنید در شکل بالا فقط یک فایل تغییر کرده باشد و در کامیت ۱ تعداد ۱۰۰ فایل داشته باشیم، گیت در کامیت ۲ تعداد ۱۰۱ فایل نگهداری خواهد کرد. نحوه‌ی دقیق کار کردن گیت بسیار پیشرفته است و نیازی به دانستن آن نیست. صرفا باید بتوانیم به صورت حرفه‌ای از امکانات آن استفاده کنیم. در این دوره تمام موارد مورد نیاز شما برای کار کردن با گیت، در یک شرکت نرم‌افزاری آموزش داده خواهد شد و **نگران نباشید اگر اکنون با این مفاهیم آشنایی ندارید!**

**پس از اتمام این دوره، می‌توانید با کمک گیت به راحتی یک پروژه را به صورت بهبود‌های مستمر پیش ببرید. می‌توانید در صورت نیاز نسخه‌های قبلی پروژه را ببینید و تغییرات قبلی را حذف کنید.**

بعد از خواندن هر درس‌نامه و بخش گفت‌و‌گوی مربوطه، دکمه «خواندم» را بزنید تا درصد پیشرفتتان افزایش باید و به مباحث عملی‌تر دوره نزدیک‌تر شوید!

آموزش عملی کار با گیت