مقایسه Git و GitHub

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

یکی از مواردی که سعی داریم در این مقاله برای شما روشن کنیم، اهداف هر کدام از این فناوری‌ها است و در پایان به تفاوت‌های اصلی آنها می‌پردازیم.

Git چیست؟

Git یک سیستم کنترل نسخه توزیع‌شده (Distributed Version Control System) است که برای ذخیره نسخه‌های مختلفی از یک فایل یا مجموعه‌ای از فایل‌ها استفاده می‌شود تا بتوانیم در هر زمان که اراده کنیم به نسخه‌ای خاص دسترسی داشته باشیم.

همچنین Git، ذخیره‌سازی و مقایسه نسخه‌های مختلف فایل را آسان می‌کند. این بدان معنی است که جزئیات مربوط به آنچه تغییر کرده، چه کسی تغییر یا یک issue را ایجاد کرده، در هر زمانی قابل بررسی است.

اما اصطلاح DVCS (Distributed Version Control System) دقیقا به چه معناست؟ اول از همه لازم است تا با مفهوم توزیع‌شده آشنا شویم.

توزیع‌شده (Distributed) به چه معناست؟

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

به همین دلیل سیستم توزیع‌شده با سایر سیستم‌های کنترل نسخه متفاوت است زیرا سایر سیستم‌ها فقط آخرین نسخه از فایل‌های پروژه را که کاربر از دیتابیس محلی (local) یا مرکزی (central) به اشتراک گذاشته و یک نسخه واحد به حساب می‌آید را به اشتراک می‌گذارند.

بنابراین در DVCS تمام نسخه‌های یک پروژه توزیع می‌شوند. اما سیستم کنترل نسخه چیست؟

سیستم کنترل نسخه (Version Control System) چیست؟

سیستم کنترل نسخه (VCS)، به روشی که برای ذخیره نسخه‌های یک پروژه برای ارجاع در آینده استفاده می‌شود، اشاره دارد.

بسیاری از افراد وجود دارند که نسخه‌های مختلف پروژه خود را با تغییر نام همان پروژه کنترل می‌کنند، برای مثال:

1. blogScript.js
2. blogScript_v2.js
3. blogScript_v3.js
4. blogScript_final.js
5. blogScript_definite_final.js

اما این روش برای پروژه‌هایی تیمی، مستعد خطا و بی فایده است. همچنین دنبال کردن (track) مواردی که در فایل‌های پروژه تغییر کرده یا چه کسی و چرا آن را تغییر داده، بسیار سخت است و باید با روشی سنتی با آن مقابله کنید. این موارد اهمیت استفاده از یک سیستم کنترل نسخه قابل اعتماد و مشارکتی را روشن می‌کنند. بااین‌حال ضروری است که برای استفاده بهتر از این فناوری، روش مدیریت فایل توسط Git را بدانید.

حالت‌های مختلف یک فایل در Git

سه state برای هر فایل وجود دارد:

1. modified
2. staged
3. committed

modified state

این حالت مخصوص فایل‌هایی است که فقط در پروژه شما به‌وجود آمده‌اند اما هنوز commit نشده‌اند و Git تغییرهای آنها را دنبال نمی‌کند.

staged state

در این مرحله یک فایل modified شده را انتخاب و برای ذخیره‌سازی آماده می‌کنند تا زمانی که commit انجام شد، وارد ریپازیتوری .git شود.

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

committed state

فایل‌های موجود در committed state، فایل‌هایی هستند که با موفقیت در ریپازیتوری .git ذخیره شده‌اند. بنابراین یک فایل commit شده، فایلی است که نسخه stage شده آن را وارد پوشه اصلی Git در پروژه‌تان کرده‌اید. در ادامه مقاله این موضوع را بهتر درک می‌کنید.

بنابراین با توجه به موارد بالا می‌توان گفت که هر state بیانگر جایگاهی است که Git به هر فایل اختصاص می‌دهد.

مسیر‌های فایل

سه مسیر اصلی وجود دارد که نسخه‌‌های مختلف یک فایل ممکن است در آن قرار گرفته باشند:

1. working directory
2. staging area
3. Git directory

working directory

working directory یک پوشه محلی برای ذخیره فایل‌های پروژه است. این بدان معنی است که هر پوشه‌ای در بخشی از سیستم ایجاد شده باشد می‌تواند یک working directory حساب شود.

موارد قابل توجه:

1. فایل‌های modifited state در working directory قرار دارند.
2. working directory با پوشه .git تفاوت دارد. به این صورت که شما working directory را ایجاد می‌کنید اما پوشه .git موجود در پروژه شما توسط Git ایجاد می‌شود.

staging area

staging area یا به صورت فنی‌تر که در Git به آن ایندکس می‌گویند، فایلی است که معمولا در پوشه .git قرار دارد و اطلاعات مربوط به تغییرهای به‌وجود آمده در فایل‌های پروژه را در خود ذخیره دارد تا Git در commit بعدی، بتواند با استفاده از آن اطلاعات فایل‌ها و داده‌های جدید را وارد پوشه .git کند و یا اطلاعات حذف شده را نیز پاک کند. توجه داشته باشید که فایل‌های staged state در staging area قرار می‌گیرند.

Git directory

پوشه .git که آن را ریپازیتوری می‌نامند، همان پوشه‌ای است که Git در working directory می‌سازد و درون آن فایل‌هایی قرار می‌گیرد که شما دستور داده‌اید توسط Git مانیتور و دنبال شوند.

پوشه .git همان جایی است که آبجکت‌های دیتابیس و متادیتاهای فایل‌ها در آن قرار داده شده و Git آنها را مانیتور می‌کند.

موارد قابل توجه:

1. پوشه .git قلب تپنده Git در پروژه‌ها است و این پوشه در هنگام clone کردن هر ریپازیتوری در کامپیوتر شما کپی می‌شود.
2. فایل‌های committed state در Git directory قرار می‌گیرند.

جریان کارها در Git

کار با سیستم کنترل نسخه توزیع‌شده Git، شبیه تصویر زیر است:

1. فایل‌های modify شده در working directory قرار دارند. توجه داشته باشید که با ایجاد هر تغییر در یک فایل، حالت آن به modified state تبدیل می‌شود.
2. هنگامی که فایل‌ها commit می‌شوند، در پوشه .git قرار می‌گیرند. توجه داشته باشید که هر فایلی را که stage کنید در staging area قرار می‌گیرد و حالت آن به staged state تبدیل می‌شود اما در پوشه .git قرار نمی‌گیرد. staging به این معناست که اطلاعات مربوط به فایل‌های stage شده که به فایل‌های ایندکس شده معروف هستند، در ریپازیتوری .git قرار داده می‌شوند.
3. درنهایت فایل‌های commit شده در پوشه .git قرار می‌گیرند که می‌توان آنها را به عنوان یک snapshot ذخیره شده در نظر گرفت که از staged state خارج شده‌اند و در دیتابیس .git اضافه شده‌اند. توجه داشته باشید هنگامی که هر نسخه از فایل را commit می‌کنید، آن فایل به پوشه .git افزوده شده و در حالت commited state قرار می‌گیرد.

چکیده‌ مطالب قبل

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

اما سوالی به‌وجود می‌آید، هنگامی که Git به مدیریت و توزیع موثر نسخه‌های مختلف یک فایل کمک می‌کند، پس هدف از وجود GitHub چه است؟

GitHub چیست؟

GitHub یک پلتفرم تحت وب است که کاربران می‌توانند ریپازیتوری‌های Git خود را در آن میزبانی کنند، به این صورت اشتراک‌گذاری و همکاری در پروژه‌ها آسان می‌شود زیرا هر کسی در هر موقعیت زمانی می‌تواند به پروژه شما دسترسی داشته باشد یا در توسعه آن مشارکت کند.

همچنین GitHub با ارائه روشی امن برای ویرایش فایل‌های ریپازیتوری یک کاربر دیگر، مشارکت گسترده‌‌تری را در پروژه‌های متن‌باز به‌وجود آورده است.

اما شما چگونه می‌توانید از GitHub برای میزبانی ریپازیتوری Git استفاده کنید؟

آموزش کار با GitHub

۱) ایجاد حساب در GitHub

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

۲) ساخت یک ریپازیتوری ریموت در GitHub

پس از ثبت نام، یک ریپازیتوری که می‌خواهید آن را به اشتراک بگذارید در GitHub بسازید.

۳) پروژه خود را به ریپازیتوری ریموت متصل کنید

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

git remote add origin https://github.com/yourusername/yourreponame.git

1. در دستور بالا، yourusername را با نام کاربری GitHubتان و yourreponame را با نام ریپازیتوری ریموت خود جایگزین کنید.
2. دستور بالا به این معنی است که شما یک URL را به عنوان ریپازیتوری ریموت به پوشه .git پروژه‌تان اضافه می‌کنید تا Git با آن تعامل داشته باشد.
3. origin یک نام پیش‌فرض است که Git به‌طور خودکار آن را به URL میزبانی ریپازیتوری ریموت اختصاص می‌دهد. یعنی Git به‌جای URL سرور، یک نام کوتاه در اختیار شما قرار می‌دهد و این‌گونه اجرای دستورات ساده‌تر می‌شود.
4. رعایت استفاده از نام پیش‌فرض origin اجباری نیست. اگر نام دیگری را به جای آن ترجیح می‌دهید، به سادگی می‌توانید آن را در دستور بالا تغییر دهید.
5. همیشه به یاد داشته باشید که نام کوتاه سرور چیز خاصی نیست. این نام فقط به‌صورت محلی وجود دارد تا به راحتی کار شما کمک کند. بنابراین یک نام کوتاه برای آن در نظر بگیرید.
6. برای تغییر نام URL ریموت می‌توانید از دستور زیر استفاده کنید.

git remote rename theCurrentURLName yourNewURLName

7. هرزمان که شما یک ریپازیتوری ریموت را clone می‌کنید، Git به طور خودکار URL ریپازیتوری را برابر با origin قرار می‌دهد. با این حال می‌توانید با دستور git clone -o yourPreferredName آن را تغییر دهید.
8. برای دیدن URL ذخیره شده مانند origin می‌توانید دستور git remote -v را اجرا کنید.

۴) از صحت اتصال خود اطمینان حاصل کنید

هنگامی که Git directory خود را به یک ریپازیتوری ریموت متصل کردید، می‌توانید با اجرای دستور git remote -v و مشاهده خروجی این دستور بررسی کنید که آیا اتصال موفقیت‌آمیز بوده یا خیر.

۵) ریپازیتوری محلی خود را به ریپازیتوری ریموت Push کنید

پس از اتصال موفقیت‌آمیز پروژه محلی خود به ریپازیتوری ریموت موجود در GitHub می‌توانید پروژه خود را با استفاده از دستور push در آن بارگذاری (upload) کنید. هر زمان که آماده به اشتراک‌گذاری پروژه خود در جای دیگری مانند ریپازیتوری ریموت بودید به سادگی می‌توانید با استفاده از Git، دستور دهید تا تمام commitها، branchها و فایل‌های موجود در پوشه .git به ریپازیتوری ریموت هدایت شوند.

با استفاده از سینتکس زیر می‌توانید Git directory خود را در یک ریپازیتوری ریموت بارگذاری کنید.

git push -u remoteName branchName

برای push کردن پوشه .git خود به ریپازیتوری ریموت می‌توانید از نام کوتاه origin استفاده کنید تا لازم نباشد تمام URL را دستی وارد کنید.

git push -u origin master

1. دستور بالا به این معناست که Git می‌بایست branch اصلی شما که master نام دارد را به branch اصلی ریپازیتوری ریموت که origin نام کوتاه شده آن است push کند.
2. اگر بخواهیم فنی‌تر به مسئله نگاه کنیم، شما می‌توانید origin را با آدرس ریپازیتوری ریموت جایگزین کنید. فقط به‌خاطر بسپارید که origin یک نام کوتاه شده است که آن را در پوشه .git ثبت کرده‌اید.
3. با استفاده از سوییچ -u به طور خودکار branchهای پروژه شما به ریپازیتوری ریمورت متصل می‌شود و درنهایت می‌توانید از دستور git pull، بدون هیچ آرگومان اضافی استفاده کنید.

۶) از صحت بارگذاری اطمینان حاصل کنید

شما می‌توانید برای اطمینان از صحت بارگذاری پروژه خود در ریپازیتوری ریموت، وارد صفحه ریپازیتوری GitHub شده و نتیجه را مشاهده کنید.

1. ممکن است برای مشاهده تغییرهای اعمال شده نیاز شود صفحه را به‌روز کنید.
2. GitHub یک قابلیت رایگان در اختیار شما قرار می‌دهد تا بتوانید ریپازیتوری خود را به یک وبسایت کاربردی تبدیل کنید.

ایجاد وبسایت با استفاده از GitHub Page

پس از push کردن پروژه به ریپازیتوری ریموت، می‌توانید به راحتی آن را در قالب یک وبسایت مشاهده کنید:

1. مطمئن شوید که نام فایل HTML اصلی پروژه‌تان index.html باشد.
2. وارد حساب GitHub خود شده و به بخش تنظیمات ریپازیتوری پروژه بروید.
3. سپس می‌توانید به بخش GitHub Pages اسکرول کرده و Source branch را بر روی master قرار دهید.
4. سپس یک اعلان دریافت خواهید کرد که نوشته شده وبسایت شما در آدرس https://your-username.github.io/your-github-repo-name قابل مشاهده است.
5. اکنون می‌توانید پروژه خود را در یک URL مشخص، مشاهده و آن را تبلیغ کنید.

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

هنوز شک شما برطرف نشده است؟

آیا هنوز نتوانسته‌اید تفاوت‌های Git و GitHub را به‌خوبی درک کنید؟ نگران نباشید، در ادامه این مقاله بیشتر به تفاوت‌های اساسی آنها خواهیم پرداخت.

تفاوت‌های Git و GitHub

عملکرد‌های اصلی

Git

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

GitHub

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

سکوی عملیاتی

Git

کاربران می‌توانند git را بر روی سیستم خود نصب و با آن کار کنند. این بدان معناست که انجام بیشتر فعالیت‌های Git بدون اینترنت امکان پذیر است.

GitHub

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

بنیان‌گذاران

Git

Linus torvalds توسعه Git را در آوریل ۲۰۰۵ شروع کرد.

GitHub

Chris Wanstrath, P. J. Hyett, Tom Preston-Werner و Scott Chacon در فوریه سال ۲۰۰۸ پلتفرم GitHub را با آدرس GitHub.com تاسیس کردند.

مسئولیت نگهداری و ارتقا

Git

Linus Torvalds در جولای سال ۲۰۰۵ نگهداری از Git را به Junio C. Hamano که از اوایل نگهدارنده ارشد Git بوده، سپرده است.

GitHub

این پلتفرم توسط شرکت Microsoft در سال ۲۰۱۸ خریداری شده است.

رقبا

Git

گزینه‌های محبوبی که درمقابل Git قرار دارند، Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion و IBM Rational ClearCase هستند.

GitHub

نزدیک‌‌ترین رقبای GitHub را می‌توان GitLab, Bitbucket, SourceForge, Cloud Source Repositories و AWS CodeCommit دانست.

در مجموع

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

منبع: https://www.freecodecamp.org/news/git-and-github-overview