|
|
<!--
|
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
|
{
|
|
|
"original_hash": "05666cecb8983a72cf0ce1d18932b5b7",
|
|
|
"translation_date": "2025-08-24T12:49:26+00:00",
|
|
|
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
|
|
|
"language_code": "fa"
|
|
|
}
|
|
|
-->
|
|
|
# مقدمه‌ای بر گیت‌هاب
|
|
|
|
|
|
این درس اصول اولیه گیت‌هاب، یک پلتفرم برای میزبانی و مدیریت تغییرات کد شما را پوشش می‌دهد.
|
|
|
|
|
|
|
|
|
> اسکیچ‌نوت توسط [Tomomi Imura](https://twitter.com/girlie_mac)
|
|
|
|
|
|
## آزمون پیش از درس
|
|
|
[آزمون پیش از درس](https://ff-quizzes.netlify.app/web/quiz/3)
|
|
|
|
|
|
## مقدمه
|
|
|
|
|
|
در این درس، به موارد زیر خواهیم پرداخت:
|
|
|
|
|
|
- پیگیری کارهایی که روی دستگاه خود انجام می‌دهید
|
|
|
- کار کردن روی پروژه‌ها با دیگران
|
|
|
- نحوه مشارکت در نرم‌افزارهای متن‌باز
|
|
|
|
|
|
### پیش‌نیازها
|
|
|
|
|
|
قبل از شروع، باید بررسی کنید که آیا Git نصب شده است یا خیر. در ترمینال تایپ کنید:
|
|
|
`git --version`
|
|
|
|
|
|
اگر Git نصب نشده است، [Git را دانلود کنید](https://git-scm.com/downloads). سپس، پروفایل محلی Git خود را در ترمینال تنظیم کنید:
|
|
|
* `git config --global user.name "your-name"`
|
|
|
* `git config --global user.email "your-email"`
|
|
|
|
|
|
برای بررسی اینکه آیا Git قبلاً تنظیم شده است، می‌توانید تایپ کنید:
|
|
|
`git config --list`
|
|
|
|
|
|
همچنین به یک حساب گیت‌هاب، یک ویرایشگر کد (مانند Visual Studio Code) و باز کردن ترمینال (یا: Command Prompt) نیاز خواهید داشت.
|
|
|
|
|
|
به [github.com](https://github.com/) بروید و اگر هنوز حسابی ندارید، یک حساب ایجاد کنید یا وارد شوید و پروفایل خود را تکمیل کنید.
|
|
|
|
|
|
✅ گیت‌هاب تنها مخزن کد در جهان نیست؛ مخازن دیگری نیز وجود دارند، اما گیت‌هاب شناخته‌شده‌ترین است.
|
|
|
|
|
|
### آماده‌سازی
|
|
|
|
|
|
به یک پوشه با یک پروژه کد روی دستگاه محلی خود (لپ‌تاپ یا کامپیوتر) و یک مخزن عمومی در گیت‌هاب نیاز دارید که به عنوان نمونه‌ای برای نحوه مشارکت در پروژه‌های دیگران عمل کند.
|
|
|
|
|
|
---
|
|
|
|
|
|
## مدیریت کد
|
|
|
|
|
|
فرض کنید یک پوشه محلی با یک پروژه کد دارید و می‌خواهید پیشرفت خود را با استفاده از Git - سیستم کنترل نسخه - پیگیری کنید. برخی افراد استفاده از Git را به نوشتن یک نامه عاشقانه برای خود آینده‌تان تشبیه می‌کنند. با خواندن پیام‌های commit خود پس از روزها، هفته‌ها یا ماه‌ها، می‌توانید به یاد بیاورید چرا تصمیمی گرفته‌اید یا یک تغییر را "بازگردانید" - البته اگر پیام‌های commit خوبی بنویسید.
|
|
|
|
|
|
### وظیفه: ایجاد یک مخزن و commit کردن کد
|
|
|
|
|
|
> مشاهده ویدیو
|
|
|
>
|
|
|
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
|
|
|
|
|
|
1. **ایجاد مخزن در گیت‌هاب**. در GitHub.com، در تب مخازن یا از نوار ناوبری بالا-راست، دکمه **مخزن جدید** را پیدا کنید.
|
|
|
|
|
|
1. به مخزن خود (پوشه) یک نام بدهید.
|
|
|
1. گزینه **ایجاد مخزن** را انتخاب کنید.
|
|
|
|
|
|
1. **به پوشه کاری خود بروید**. در ترمینال، به پوشه (یا همان دایرکتوری) که می‌خواهید شروع به پیگیری کنید، بروید. تایپ کنید:
|
|
|
|
|
|
```bash
|
|
|
cd [name of your folder]
|
|
|
```
|
|
|
|
|
|
1. **مخزن Git را مقداردهی اولیه کنید**. در پروژه خود تایپ کنید:
|
|
|
|
|
|
```bash
|
|
|
git init
|
|
|
```
|
|
|
|
|
|
1. **بررسی وضعیت**. برای بررسی وضعیت مخزن خود تایپ کنید:
|
|
|
|
|
|
```bash
|
|
|
git status
|
|
|
```
|
|
|
|
|
|
خروجی ممکن است چیزی شبیه به این باشد:
|
|
|
|
|
|
```output
|
|
|
Changes not staged for commit:
|
|
|
(use "git add <file>..." to update what will be committed)
|
|
|
(use "git checkout -- <file>..." to discard changes in working directory)
|
|
|
|
|
|
modified: file.txt
|
|
|
modified: file2.txt
|
|
|
```
|
|
|
|
|
|
معمولاً دستور `git status` به شما می‌گوید چه فایل‌هایی آماده _ذخیره_ در مخزن هستند یا تغییراتی دارند که ممکن است بخواهید آن‌ها را ثبت کنید.
|
|
|
|
|
|
1. **اضافه کردن تمام فایل‌ها برای پیگیری**
|
|
|
این کار همچنین به عنوان مرحله‌بندی فایل‌ها/اضافه کردن فایل‌ها به ناحیه مرحله‌بندی شناخته می‌شود.
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
```
|
|
|
|
|
|
آرگومان `git add` به همراه `.` نشان می‌دهد که تمام فایل‌ها و تغییرات برای پیگیری اضافه می‌شوند.
|
|
|
|
|
|
1. **اضافه کردن فایل‌های انتخابی برای پیگیری**
|
|
|
|
|
|
```bash
|
|
|
git add [file or folder name]
|
|
|
```
|
|
|
|
|
|
این دستور به ما کمک می‌کند فقط فایل‌های انتخابی را به ناحیه مرحله‌بندی اضافه کنیم، زمانی که نمی‌خواهیم همه فایل‌ها را یکجا commit کنیم.
|
|
|
|
|
|
1. **لغو مرحله‌بندی تمام فایل‌ها**
|
|
|
|
|
|
```bash
|
|
|
git reset
|
|
|
```
|
|
|
|
|
|
این دستور به ما کمک می‌کند تمام فایل‌ها را یکجا از مرحله‌بندی خارج کنیم.
|
|
|
|
|
|
1. **لغو مرحله‌بندی یک فایل خاص**
|
|
|
|
|
|
```bash
|
|
|
git reset [file or folder name]
|
|
|
```
|
|
|
|
|
|
این دستور به ما کمک می‌کند فقط یک فایل خاص را که نمی‌خواهیم در commit بعدی شامل شود، از مرحله‌بندی خارج کنیم.
|
|
|
|
|
|
1. **ثبت کار خود**. در این مرحله فایل‌ها را به ناحیه‌ای به نام _مرحله‌بندی_ اضافه کرده‌اید. جایی که Git فایل‌های شما را پیگیری می‌کند. برای دائمی کردن تغییر، باید فایل‌ها را _commit_ کنید. برای این کار یک _commit_ با دستور `git commit` ایجاد کنید. یک _commit_ نمایانگر یک نقطه ذخیره در تاریخچه مخزن شما است. برای ایجاد یک _commit_ تایپ کنید:
|
|
|
|
|
|
```bash
|
|
|
git commit -m "first commit"
|
|
|
```
|
|
|
|
|
|
این دستور تمام فایل‌های شما را commit می‌کند و پیام "اولین commit" را اضافه می‌کند. برای پیام‌های commit آینده، بهتر است توضیحات دقیق‌تری ارائه دهید تا نوع تغییری که ایجاد کرده‌اید را منتقل کنید.
|
|
|
|
|
|
1. **اتصال مخزن محلی Git به گیت‌هاب**. یک مخزن Git روی دستگاه شما خوب است، اما در نهایت می‌خواهید از فایل‌های خود نسخه پشتیبان تهیه کنید و همچنین دیگران را دعوت کنید تا روی مخزن شما کار کنند. یکی از مکان‌های عالی برای این کار گیت‌هاب است. به یاد داشته باشید که قبلاً یک مخزن در گیت‌هاب ایجاد کرده‌ایم، بنابراین تنها کاری که باید انجام دهیم اتصال مخزن محلی Git به گیت‌هاب است. دستور `git remote add` این کار را انجام می‌دهد. دستور زیر را تایپ کنید:
|
|
|
|
|
|
> توجه: قبل از تایپ دستور، به صفحه مخزن گیت‌هاب خود بروید تا URL مخزن را پیدا کنید. از آن در دستور زیر استفاده کنید. ```https://github.com/username/repository_name.git``` را با URL گیت‌هاب خود جایگزین کنید.
|
|
|
|
|
|
```bash
|
|
|
git remote add origin https://github.com/username/repository_name.git
|
|
|
```
|
|
|
|
|
|
این دستور یک _remote_ یا اتصال به نام "origin" ایجاد می‌کند که به مخزن گیت‌هاب که قبلاً ایجاد کرده‌اید اشاره دارد.
|
|
|
|
|
|
1. **ارسال فایل‌های محلی به گیت‌هاب**. تاکنون یک _اتصال_ بین مخزن محلی و مخزن گیت‌هاب ایجاد کرده‌اید. بیایید این فایل‌ها را با دستور `git push` به گیت‌هاب ارسال کنیم:
|
|
|
|
|
|
> توجه: نام شاخه شما ممکن است به طور پیش‌فرض با ```main``` متفاوت باشد.
|
|
|
|
|
|
```bash
|
|
|
git push -u origin main
|
|
|
```
|
|
|
|
|
|
این دستور commitهای شما را در شاخه "main" به گیت‌هاب ارسال می‌کند.
|
|
|
|
|
|
2. **اضافه کردن تغییرات بیشتر**. اگر می‌خواهید به ایجاد تغییرات و ارسال آن‌ها به گیت‌هاب ادامه دهید، فقط باید از سه دستور زیر استفاده کنید:
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m "type your commit message here"
|
|
|
git push
|
|
|
```
|
|
|
|
|
|
> نکته: ممکن است بخواهید یک فایل `.gitignore` را برای جلوگیری از نمایش فایل‌هایی که نمی‌خواهید پیگیری شوند، مانند فایل یادداشت‌هایی که در همان پوشه ذخیره می‌کنید اما جایی در یک مخزن عمومی ندارند، اتخاذ کنید. می‌توانید قالب‌هایی برای فایل‌های `.gitignore` را در [.gitignore templates](https://github.com/github/gitignore) پیدا کنید.
|
|
|
|
|
|
#### پیام‌های Commit
|
|
|
|
|
|
یک خط موضوع عالی برای commit گیت جمله زیر را کامل می‌کند:
|
|
|
اگر اعمال شود، این commit <خط موضوع شما در اینجا> خواهد بود.
|
|
|
|
|
|
برای موضوع از زمان حال و حالت امری استفاده کنید: "تغییر" نه "تغییر داده شد" و نه "تغییرات".
|
|
|
همان‌طور که در موضوع، در بدنه (اختیاری) نیز از زمان حال و حالت امری استفاده کنید. بدنه باید انگیزه تغییر را شامل شود و این را با رفتار قبلی مقایسه کند. شما در حال توضیح دادن `چرا` هستید، نه `چگونه`.
|
|
|
|
|
|
✅ چند دقیقه وقت بگذارید و در گیت‌هاب جستجو کنید. آیا می‌توانید یک پیام commit واقعاً عالی پیدا کنید؟ آیا می‌توانید یک پیام بسیار مختصر پیدا کنید؟ به نظر شما چه اطلاعاتی مهم‌ترین و مفیدترین برای انتقال در یک پیام commit هستند؟
|
|
|
|
|
|
### وظیفه: همکاری
|
|
|
|
|
|
دلیل اصلی قرار دادن چیزها در گیت‌هاب، امکان همکاری با سایر توسعه‌دهندگان است.
|
|
|
|
|
|
## کار روی پروژه‌ها با دیگران
|
|
|
|
|
|
> مشاهده ویدیو
|
|
|
>
|
|
|
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
|
|
|
|
|
|
در مخزن خود، به `Insights > Community` بروید تا ببینید پروژه شما چگونه با استانداردهای پیشنهادی جامعه مقایسه می‌شود.
|
|
|
|
|
|
در اینجا چند مورد وجود دارد که می‌تواند مخزن گیت‌هاب شما را بهبود بخشد:
|
|
|
- **توضیحات**. آیا توضیحی برای پروژه خود اضافه کرده‌اید؟
|
|
|
- **README**. آیا یک README اضافه کرده‌اید؟ گیت‌هاب راهنمایی‌هایی برای نوشتن یک [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) ارائه می‌دهد.
|
|
|
- **راهنمای مشارکت**. آیا پروژه شما دارای [راهنمای مشارکت](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) است؟
|
|
|
- **کد اخلاقی**. آیا یک [کد اخلاقی](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/) اضافه کرده‌اید؟
|
|
|
- **مجوز**. شاید مهم‌ترین مورد، یک [مجوز](https://docs.github.com/articles/adding-a-license-to-a-repository/) است.
|
|
|
|
|
|
تمام این منابع به جذب اعضای جدید تیم کمک خواهند کرد. و این‌ها معمولاً مواردی هستند که مشارکت‌کنندگان جدید قبل از حتی نگاه کردن به کد شما بررسی می‌کنند تا بفهمند آیا پروژه شما مکان مناسبی برای صرف وقت آن‌ها است یا خیر.
|
|
|
|
|
|
✅ فایل‌های README، اگرچه زمان‌بر هستند، اغلب توسط نگهدارندگان پرمشغله نادیده گرفته می‌شوند. آیا می‌توانید مثالی از یک README به‌ویژه توصیفی پیدا کنید؟ توجه: ابزارهایی برای کمک به ایجاد READMEهای خوب وجود دارند که ممکن است بخواهید امتحان کنید، مانند [ابزارهای ایجاد README](https://www.makeareadme.com/).
|
|
|
|
|
|
### وظیفه: ادغام کد
|
|
|
|
|
|
مستندات مشارکت به افراد کمک می‌کند تا در پروژه مشارکت کنند. این مستندات توضیح می‌دهند که چه نوع مشارکت‌هایی مورد نظر شما است و فرآیند چگونه کار می‌کند. مشارکت‌کنندگان باید مراحل زیر را برای مشارکت در مخزن شما در گیت‌هاب طی کنند:
|
|
|
|
|
|
1. **فورک کردن مخزن شما**. احتمالاً می‌خواهید افراد پروژه شما را _فورک_ کنند. فورک کردن به معنای ایجاد یک نسخه کپی از مخزن شما در پروفایل گیت‌هاب آن‌ها است.
|
|
|
1. **کلون کردن**. از آنجا، آن‌ها پروژه را به دستگاه محلی خود کلون می‌کنند.
|
|
|
1. **ایجاد یک شاخه**. از آن‌ها بخواهید یک _شاخه_ برای کار خود ایجاد کنند.
|
|
|
1. **تمرکز تغییرات روی یک بخش**. از مشارکت‌کنندگان بخواهید مشارکت‌های خود را روی یک چیز در یک زمان متمرکز کنند - به این ترتیب احتمال اینکه بتوانید کار آن‌ها را _ادغام_ کنید بیشتر است. تصور کنید آن‌ها یک باگ را رفع می‌کنند، یک ویژگی جدید اضافه می‌کنند و چندین تست را به‌روزرسانی می‌کنند - اگر بخواهید یا فقط بتوانید ۲ از ۳ یا ۱ از ۳ تغییر را اعمال کنید چه می‌شود؟
|
|
|
|
|
|
✅ یک موقعیت را تصور کنید که در آن شاخه‌ها برای نوشتن و ارائه کد خوب به‌ویژه حیاتی هستند. چه موارد استفاده‌ای می‌توانید تصور کنید؟
|
|
|
|
|
|
> توجه: تغییری باشید که می‌خواهید در جهان ببینید و برای کار خود نیز شاخه ایجاد کنید. هر commitی که انجام می‌دهید در شاخه‌ای که در حال حاضر "چک‌اوت" شده‌اید انجام خواهد شد. از `git status` استفاده کنید تا ببینید در کدام شاخه هستید.
|
|
|
|
|
|
بیایید یک جریان کاری مشارکت‌کننده را مرور کنیم. فرض کنید مشارکت‌کننده قبلاً مخزن را _فورک_ و _کلون_ کرده است، بنابراین یک مخزن Git آماده برای کار روی دستگاه محلی خود دارد:
|
|
|
|
|
|
1. **ایجاد یک شاخه**. از دستور `git branch` برای ایجاد یک شاخه که شامل تغییراتی است که قصد دارند مشارکت کنند، استفاده کنید:
|
|
|
|
|
|
```bash
|
|
|
git branch [branch-name]
|
|
|
```
|
|
|
|
|
|
1. **تغییر به شاخه کاری**. به شاخه مشخص‌شده تغییر دهید و دایرکتوری کاری را با `git switch` به‌روزرسانی کنید:
|
|
|
|
|
|
```bash
|
|
|
git switch [branch-name]
|
|
|
```
|
|
|
|
|
|
1. **انجام کار**. در این مرحله می‌خواهید تغییرات خود را اضافه کنید. فراموش نکنید که به Git اطلاع دهید با دستورات زیر:
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m "my changes"
|
|
|
```
|
|
|
|
|
|
اطمینان حاصل کنید که به commit خود یک نام خوب بدهید، برای خودتان و همچنین نگهدارنده مخزنی که در آن کمک می‌کنید.
|
|
|
|
|
|
1. **ترکیب کار خود با شاخه `main`**. در یک نقطه، کار شما تمام می‌شود و می‌خواهید کار خود را با شاخه `main` ترکیب کنید. ممکن است شاخه `main` meanwhile تغییر کرده باشد، بنابراین مطمئن شوید که ابتدا آن را با دستورات زیر به‌روزرسانی کنید:
|
|
|
|
|
|
```bash
|
|
|
git switch main
|
|
|
git pull
|
|
|
```
|
|
|
|
|
|
در این مرحله می‌خواهید مطمئن شوید که هرگونه _تضاد_، موقعیت‌هایی که Git نمی‌تواند به‌راحتی تغییرات را _ترکیب_ کند، در شاخه کاری شما اتفاق می‌افتد. بنابراین دستورات زیر را اجرا کنید:
|
|
|
|
|
|
```bash
|
|
|
git switch [branch_name]
|
|
|
git merge main
|
|
|
```
|
|
|
|
|
|
این دستور تمام تغییرات از `main` را به شاخه شما می‌آورد و امیدواریم بتوانید به‌راحتی ادامه دهید. اگر نه، VS Code به شما نشان می‌دهد که Git کجا _گیج_ شده است و شما فقط فایل‌های تحت تأثیر را تغییر می‌دهید تا بگویید کدام محتوا دقیق‌تر است.
|
|
|
|
|
|
1. **ارسال کار خود به گیت‌هاب**. ارسال کار خود به گیت‌هاب به دو چیز نیاز دارد. ارسال شاخه خود به مخزن و سپس باز کردن یک PR (درخواست کشیدن).
|
|
|
|
|
|
```bash
|
|
|
git push --set-upstream origin [branch-name]
|
|
|
```
|
|
|
|
|
|
دستور بالا شاخه را در مخزن فورک‌شده شما ایجاد می‌کند.
|
|
|
|
|
|
1. **باز کردن یک PR**. سپس، می‌خواهید یک PR باز کنید. این کار را با رفتن به مخزن فورک‌شده در گیت‌هاب انجام دهید. در گیت‌هاب یک اعلان خواهید دید که از شما می‌پرسد آیا می‌خواهید یک PR جدید ایجاد کنید، روی آن کلیک کنید و به رابطی هدایت می‌شوید که می‌توانید عنوان پیام commit را تغییر دهید و توضیح مناسب‌تری بدهید. اکنون نگهدارنده مخزنی که فورک کرده‌اید این PR را می‌بیند و _انگشتان‌تان را ضربدری کنید_، آن‌ها قدردانی می‌کنند و PR شما را _ادغام_ می‌کنند. اکنون شما یک مشارکت‌کننده هستید، یای :)
|
|
|
|
|
|
1. **پاک‌سازی**. پاک‌سازی پس از موفقیت در ادغام یک PR به عنوان یک عمل خوب در نظر گرفته می‌شود. می‌خواهید هم شاخه محلی و هم شاخه‌ای که به گیت‌هاب ارسال کرده‌اید را پاک کنید. ابتدا آن را به‌صورت محلی با دستور زیر حذف کنید:
|
|
|
|
|
|
```bash
|
|
|
git branch -d [branch-name]
|
|
|
```
|
|
|
اطمینان حاصل کنید که به صفحه گیت‌هاب مخزن فورک شده بروید و شاخه‌ی ریموتی که به آن پوش کردید را حذف کنید.
|
|
|
|
|
|
اصطلاح `Pull request` ممکن است کمی عجیب به نظر برسد، چون در واقع شما می‌خواهید تغییرات خود را به پروژه ارسال کنید. اما نگهدارنده (مالک پروژه) یا تیم اصلی باید تغییرات شما را قبل از ادغام با شاخه‌ی "اصلی" پروژه بررسی کند، بنابراین در واقع شما درخواست تصمیم‌گیری برای تغییرات را از یک نگهدارنده دارید.
|
|
|
|
|
|
یک pull request جایی است که تفاوت‌های ایجاد شده در یک شاخه با بررسی‌ها، نظرات، تست‌های یکپارچه و موارد دیگر مقایسه و بحث می‌شود. یک pull request خوب تقریباً از همان قوانینی پیروی می‌کند که یک پیام commit. شما می‌توانید به یک issue در ردیاب مشکلات ارجاع دهید، مثلاً وقتی کار شما یک مشکل را حل می‌کند. این کار با استفاده از `#` و سپس شماره‌ی issue انجام می‌شود. برای مثال `#97`.
|
|
|
|
|
|
🤞امیدواریم که همه بررسی‌ها موفقیت‌آمیز باشند و مالک(های) پروژه تغییرات شما را در پروژه ادغام کنند🤞
|
|
|
|
|
|
شاخه‌ی کاری محلی فعلی خود را با تمام commitهای جدید از شاخه‌ی ریموت مربوطه در گیت‌هاب به‌روزرسانی کنید:
|
|
|
|
|
|
`git pull`
|
|
|
|
|
|
## چگونه به پروژه‌های متن‌باز کمک کنیم
|
|
|
|
|
|
ابتدا، یک مخزن (یا **repo**) در گیت‌هاب پیدا کنید که برای شما جالب باشد و بخواهید تغییری در آن ایجاد کنید. شما باید محتوای آن را به دستگاه خود کپی کنید.
|
|
|
|
|
|
✅ یک راه خوب برای پیدا کردن مخازن مناسب برای مبتدیان، [جستجو با برچسب 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/) است.
|
|
|
|
|
|
|
|
|
|
|
|
روش‌های مختلفی برای کپی کردن کد وجود دارد. یکی از روش‌ها "کلون کردن" محتوای مخزن با استفاده از HTTPS، SSH یا GitHub CLI (رابط خط فرمان گیت‌هاب) است.
|
|
|
|
|
|
ترمینال خود را باز کنید و مخزن را به این صورت کلون کنید:
|
|
|
`git clone https://github.com/ProjectURL`
|
|
|
|
|
|
برای کار روی پروژه، به پوشه‌ی مناسب بروید:
|
|
|
`cd ProjectURL`
|
|
|
|
|
|
همچنین می‌توانید کل پروژه را با استفاده از [Codespaces](https://github.com/features/codespaces)، ویرایشگر کد تعبیه‌شده‌ی گیت‌هاب / محیط توسعه ابری، یا [GitHub Desktop](https://desktop.github.com/) باز کنید.
|
|
|
|
|
|
در نهایت، می‌توانید کد را در یک پوشه‌ی زیپ‌شده دانلود کنید.
|
|
|
|
|
|
### چند نکته جالب دیگر درباره گیت‌هاب
|
|
|
|
|
|
شما می‌توانید هر مخزن عمومی در گیت‌هاب را ستاره‌دار کنید، دنبال کنید یا "فورک" کنید. مخازن ستاره‌دار خود را می‌توانید در منوی کشویی بالا سمت راست پیدا کنید. این کار شبیه به بوکمارک کردن است، اما برای کد.
|
|
|
|
|
|
پروژه‌ها یک ردیاب مشکلات دارند، که معمولاً در گیت‌هاب در تب "Issues" قرار دارد مگر اینکه به شکل دیگری مشخص شده باشد، جایی که افراد درباره مشکلات مربوط به پروژه بحث می‌کنند. و تب Pull Requests جایی است که افراد درباره تغییراتی که در حال انجام است بحث و بررسی می‌کنند.
|
|
|
|
|
|
پروژه‌ها ممکن است همچنین بحث‌هایی در انجمن‌ها، لیست‌های ایمیل یا کانال‌های چت مانند Slack، Discord یا IRC داشته باشند.
|
|
|
|
|
|
✅ نگاهی به مخزن جدید گیت‌هاب خود بیندازید و چند کار انجام دهید، مانند ویرایش تنظیمات، افزودن اطلاعات به مخزن خود و ایجاد یک پروژه (مانند یک تخته کانبان). کارهای زیادی می‌توانید انجام دهید!
|
|
|
|
|
|
---
|
|
|
|
|
|
## 🚀 چالش
|
|
|
|
|
|
با یک دوست همکاری کنید و روی کد یکدیگر کار کنید. یک پروژه به صورت مشترک ایجاد کنید، کد را فورک کنید، شاخه ایجاد کنید و تغییرات را ادغام کنید.
|
|
|
|
|
|
## آزمون پس از درس
|
|
|
[آزمون پس از درس](https://ff-quizzes.netlify.app/web/quiz/4)
|
|
|
|
|
|
## مرور و مطالعه شخصی
|
|
|
|
|
|
بیشتر درباره [کمک به نرم‌افزارهای متن‌باز](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution) بخوانید.
|
|
|
|
|
|
[برگه تقلب گیت](https://training.github.com/downloads/github-git-cheat-sheet/).
|
|
|
|
|
|
تمرین، تمرین، تمرین. گیت‌هاب مسیرهای یادگیری عالی از طریق [skills.github.com](https://skills.github.com) ارائه می‌دهد:
|
|
|
|
|
|
- [هفته اول در گیت‌هاب](https://skills.github.com/#first-week-on-github)
|
|
|
|
|
|
همچنین دوره‌های پیشرفته‌تری نیز پیدا خواهید کرد.
|
|
|
|
|
|
## تکلیف
|
|
|
|
|
|
[دوره هفته اول در گیت‌هاب](https://skills.github.com/#first-week-on-github) را کامل کنید.
|
|
|
|
|
|
**سلب مسئولیت**:
|
|
|
این سند با استفاده از سرویس ترجمه هوش مصنوعی [Co-op Translator](https://github.com/Azure/co-op-translator) ترجمه شده است. در حالی که ما تلاش می‌کنیم دقت را حفظ کنیم، لطفاً توجه داشته باشید که ترجمه‌های خودکار ممکن است شامل خطاها یا نادرستی‌ها باشند. سند اصلی به زبان اصلی آن باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حساس، توصیه می‌شود از ترجمه انسانی حرفه‌ای استفاده کنید. ما مسئولیتی در قبال سوء تفاهم‌ها یا تفسیرهای نادرست ناشی از استفاده از این ترجمه نداریم. |
