قبل أن تبدأ، ستحتاج إلى التحقق مما إذا كان Git مثبتًا. في الطرفية، اكتب:
قبل أن تبدأ، تحتاج إلى التحقق مما إذا كان Git مثبتًا. في الطرفية، اكتب:
`git --version`
إذا لم يكن Git مثبتًا، [قم بتنزيل Git](https://git-scm.com/downloads). ثم قم بإعداد ملف تعريف Git المحلي الخاص بك في الطرفية:
@ -39,29 +39,29 @@ CO_OP_TRANSLATOR_METADATA:
ستحتاج أيضًا إلى حساب GitHub، ومحرر كود (مثل Visual Studio Code)، وستحتاج إلى فتح الطرفية (أو: موجه الأوامر).
انتقل إلى [github.com](https://github.com/) وأنشئ حسابًا إذا لم تكن قد فعلت ذلك بالفعل، أو قم بتسجيل الدخول واملأ ملفك الشخصي.
انتقل إلى [github.com](https://github.com/) وقم بإنشاء حساب إذا لم تكن قد فعلت ذلك بالفعل، أو قم بتسجيل الدخول واملأ ملفك الشخصي.
✅ GitHub ليس مستودع الكود الوحيد في العالم؛ هناك مستودعات أخرى، ولكن GitHub هو الأكثر شهرة.
✅ GitHub ليس مستودع الكود الوحيد في العالم؛ هناك مستودعات أخرى، لكن GitHub هو الأكثر شهرة.
### التحضير
ستحتاج إلى مجلد يحتوي على مشروع كود على جهازك المحلي (اللابتوب أو الكمبيوتر الشخصي)، ومستودع عام على GitHub، والذي سيعمل كمثال على كيفية المساهمة في مشاريع الآخرين.
ستحتاج إلى مجلد يحتوي على مشروع كود على جهازك المحلي (الكمبيوتر المحمول أو الكمبيوتر الشخصي)، ومستودع عام على GitHub، والذي سيعمل كمثال على كيفية المساهمة في مشاريع الآخرين.
---
## إدارة الكود
لنفترض أن لديك مجلدًا محليًا يحتوي على مشروع كود وترغب في البدء بتتبع تقدمك باستخدام Git - نظام التحكم في الإصدارات. يشبه بعض الأشخاص استخدام Git بكتابة رسالة حب لنفسك المستقبلية. عند قراءة رسائل الالتزام الخاصة بك بعد أيام أو أسابيع أو أشهر، ستتمكن من تذكر سبب اتخاذك لقرار معين، أو "التراجع" عن تغيير - وهذا عندما تكتب رسائل "التزام" جيدة.
لنفترض أن لديك مجلدًا محليًا يحتوي على مشروع كود وترغب في البدء بتتبع تقدمك باستخدام Git - نظام التحكم في الإصدارات. يقارن بعض الأشخاص استخدام Git بكتابة رسالة حب لنفسك المستقبلية. عند قراءة رسائل الالتزام الخاصة بك بعد أيام أو أسابيع أو أشهر، ستتمكن من تذكر سبب اتخاذك قرارًا معينًا أو "التراجع" عن تغيير - وهذا عندما تكتب رسائل "التزام" جيدة.
1. **إنشاء مستودع على GitHub**. على GitHub.com، في علامة التبويب الخاصة بالمستودعات، أو من شريط التنقل العلوي الأيمن، ابحث عن زر **مستودع جديد**.
1. **إنشاء مستودع على GitHub**. على GitHub.com، في علامة تبويب المستودعات، أو من شريط التنقل في الأعلى على اليمين، ابحث عن زر **مستودع جديد**.
1. أعطِ مستودعك (المجلد) اسمًا.
1. امنح مستودعك (المجلد) اسمًا.
1. اختر **إنشاء مستودع**.
1. **انتقل إلى مجلد العمل الخاص بك**. في الطرفية، انتقل إلى المجلد (المعروف أيضًا بالدليل) الذي تريد البدء بتتبعه. اكتب:
@ -76,13 +76,13 @@ CO_OP_TRANSLATOR_METADATA:
git init
```
1. **التحقق من الحالة**. للتحقق من حالة مستودعك، اكتب:
1. **التحقق من الحالة**. للتحقق من حالة المستودع الخاص بك، اكتب:
```bash
git status
```
قد يبدو الإخراج كالتالي:
قد يبدو الإخراج شيئًا مثل هذا:
```output
Changes not staged for commit:
@ -95,14 +95,14 @@ CO_OP_TRANSLATOR_METADATA:
عادةً ما يخبرك أمر `git status` بأشياء مثل الملفات الجاهزة ليتم _حفظها_ في المستودع أو التي تحتوي على تغييرات قد ترغب في الاحتفاظ بها.
1. **إضافة جميع الملفات للتتبع**
يُعرف هذا أيضًا بمرحلة الملفات/إضافتها إلى منطقة التهيئة.
1. **إضافة جميع الملفات للتتبع**
يُطلق على هذا أيضًا اسم وضع الملفات في منطقة التهيئة.
```bash
git add .
```
يشير الأمر `git add` مع الحجة `.` إلى أن جميع ملفاتك وتغييراتك جاهزة للتتبع.
يشير الأمر `git add` مع الحجة `.` إلى أن جميع ملفاتك وتغييراتك سيتم تتبعها.
1. **إضافة ملفات محددة للتتبع**
@ -110,7 +110,7 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
يساعدنا هذا الأمر في إضافة ملفات محددة فقط إلى منطقة التهيئة عندما لا نرغب في الالتزام بجميع الملفات دفعة واحدة.
يساعدنا هذا في إضافة ملفات محددة فقط إلى منطقة التهيئة عندما لا نريد الالتزام بجميع الملفات دفعة واحدة.
1. **إلغاء تهيئة جميع الملفات**
@ -126,37 +126,37 @@ CO_OP_TRANSLATOR_METADATA:
git reset [file or folder name]
```
يساعدنا هذا الأمر في إلغاء تهيئة ملف معين فقط دفعة واحدة عندما لا نرغب في تضمينه في الالتزام التالي.
يساعدنا هذا الأمر في إلغاء تهيئة ملف معين فقط دفعة واحدة عندما لا نريد تضمينه في الالتزام التالي.
1. **حفظ عملك**. في هذه المرحلة، قمت بإضافة الملفات إلى ما يسمى _منطقة التهيئة_. وهي مكان يتتبع فيه Git ملفاتك. لجعل التغيير دائمًا، تحتاج إلى _الالتزام_ بالملفات. للقيام بذلك، أنشئ _التزامًا_ باستخدام أمر `git commit`. يمثل _الالتزام_ نقطة حفظ في تاريخ مستودعك. اكتب ما يلي لإنشاء _التزام_:
1. **الاحتفاظ بعملك**. في هذه المرحلة، قمت بإضافة الملفات إلى ما يسمى _منطقة التهيئة_. وهي مكان حيث يقوم Git بتتبع ملفاتك. لجعل التغيير دائمًا، تحتاج إلى _الالتزام_ بالملفات. للقيام بذلك، قم بإنشاء _التزام_ باستخدام أمر `git commit`. يمثل _التزام_ نقطة حفظ في تاريخ المستودع الخاص بك. اكتب التالي لإنشاء _التزام_:
```bash
git commit -m "first commit"
```
هذا يلتزم بجميع ملفاتك، مع إضافة الرسالة "الالتزام الأول". بالنسبة لرسائل الالتزام المستقبلية، سترغب في أن تكون أكثر وصفًا لتوضيح نوع التغيير الذي قمت به.
يقوم هذا الالتزام بجميع ملفاتك، مع إضافة الرسالة "الالتزام الأول". بالنسبة لرسائل الالتزام المستقبلية، سترغب في أن تكون أكثر وصفية في وصفك لتوضيح نوع التغيير الذي قمت به.
1. **ربط مستودع Git المحلي الخاص بك بـ GitHub**. مستودع Git مفيد على جهازك، ولكن في مرحلة ما، سترغب في الحصول على نسخة احتياطية من ملفاتك في مكان ما ودعوة أشخاص آخرين للعمل معك على مستودعك. مكان رائع للقيام بذلك هو GitHub. تذكر أننا أنشأنا بالفعل مستودعًا على GitHub، لذا الشيء الوحيد الذي نحتاج إلى القيام به هو ربط مستودع Git المحلي الخاص بنا بـ GitHub. سيقوم الأمر `git remote add` بذلك. اكتب الأمر التالي:
1. **ربط مستودع Git المحلي الخاص بك بـ GitHub**. مستودع Git جيد على جهازك، ولكن في مرحلة ما، سترغب في الحصول على نسخة احتياطية من ملفاتك في مكان ما وأيضًا دعوة الآخرين للعمل معك على مستودعك. أحد الأماكن الرائعة للقيام بذلك هو GitHub. تذكر أننا قمنا بالفعل بإنشاء مستودع على GitHub، لذا فإن الشيء الوحيد الذي نحتاج إلى القيام به هو ربط مستودع Git المحلي الخاص بنا بـ GitHub. سيقوم الأمر `git remote add` بذلك. اكتب الأمر التالي:
> ملاحظة، قبل كتابة الأمر، انتقل إلى صفحة مستودع GitHub الخاص بك للعثور على عنوان URL الخاص بالمستودع. ستستخدمه في الأمر أدناه. استبدل ```https://github.com/username/repository_name.git``` بعنوان URL الخاص بـ GitHub.
> ملاحظة، قبل كتابة الأمر، انتقل إلى صفحة مستودع GitHub الخاص بك للعثور على عنوان URL للمستودع. ستستخدمه في الأمر أدناه. استبدل ```https://github.com/username/repository_name.git``` بعنوان URL الخاص بـ GitHub.
هذا ينشئ _اتصالًا_، أو ارتباطًا، يسمى "origin" يشير إلى مستودع GitHub الذي أنشأته سابقًا.
1. **إرسال الملفات المحلية إلى GitHub**. حتى الآن، قمت بإنشاء _اتصال_ بين المستودع المحلي ومستودع GitHub. لنرسل هذه الملفات إلى GitHub باستخدام الأمر `git push`، كما يلي:
يقوم هذا بإنشاء _اتصال_، يسمى "origin"، يشير إلى مستودع GitHub الذي أنشأته سابقًا.
1. **إرسال الملفات المحلية إلى GitHub**. حتى الآن، قمت بإنشاء _اتصال_ بين المستودع المحلي ومستودع GitHub. دعنا نرسل هذه الملفات إلى GitHub باستخدام الأمر التالي `git push`، كما يلي:
> ملاحظة، قد يكون اسم الفرع الخاص بك مختلفًا افتراضيًا عن ```main```.
```bash
git push -u origin main
```
هذا يرسل التزاماتك في فرع "main" الخاص بك إلى GitHub.
يقوم هذا بإرسال الالتزامات في فرع "main" الخاص بك إلى GitHub. إعداد فرع `upstream` بما في ذلك `-u` في الأمر ينشئ رابطًا بين الفرع المحلي والفرع البعيد، بحيث يمكنك ببساطة استخدام git push أو git pull دون تحديد اسم الفرع في المستقبل. سيستخدم Git تلقائيًا الفرع الرئيسي ولن تحتاج إلى تحديد اسم الفرع صراحةً في الأوامر المستقبلية.
2. **لإضافة تغييرات إضافية**. إذا كنت ترغب في الاستمرار في إجراء تغييرات ودفعها إلى GitHub، ستحتاج فقط إلى استخدام الأوامر الثلاثة التالية:
2. **لإضافة المزيد من التغييرات**. إذا كنت ترغب في متابعة إجراء تغييرات وإرسالها إلى GitHub، فستحتاج فقط إلى استخدام الأوامر الثلاثة التالية:
```bash
git add .
@ -168,13 +168,13 @@ CO_OP_TRANSLATOR_METADATA:
#### رسائل الالتزام
يجب أن تكمل سطر موضوع الالتزام الجيد في Git الجملة التالية:
سطر موضوع رائع لالتزام Git يكمل الجملة التالية:
إذا تم تطبيقه، فإن هذا الالتزام سيقوم بـ <سطر الموضوع الخاص بك هنا>
بالنسبة للموضوع، استخدم صيغة الأمر، الزمن الحاضر: "تغيير" وليس "تم التغيير" ولا "تغييرات".
كما هو الحال في الموضوع، في النص (اختياري) أيضًا استخدم صيغة الأمر، الزمن الحاضر. يجب أن يتضمن النص الدافع للتغيير ومقارنة ذلك بالسلوك السابق. أنت تشرح `لماذا`، وليس `كيف`.
بالنسبة للموضوع، استخدم صيغة الأمر، الزمن الحاضر: "تغيير" وليس "تم التغيير" ولا "تغييرات".
كما هو الحال في الموضوع، في النص (اختياري) أيضًا استخدم صيغة الأمر، الزمن الحاضر. يجب أن يتضمن النص الدافع للتغيير ويقارن ذلك بالسلوك السابق. أنت تشرح `لماذا`، وليس `كيف`.
✅ خذ بضع دقائق لتصفح GitHub. هل يمكنك العثور على رسالة التزام رائعة حقًا؟ هل يمكنك العثور على واحدة بسيطة جدًا؟ ما المعلومات التي تعتقد أنها الأكثر أهمية وفائدة لنقلها في رسالة الالتزام؟
✅ خذ بضع دقائق لتصفح GitHub. هل يمكنك العثور على رسالة التزام رائعة حقًا؟ هل يمكنك العثور على واحدة بسيطة جدًا؟ ما المعلومات التي تعتقد أنها الأكثر أهمية وفائدة لتوصيلها في رسالة الالتزام؟
- **إرشادات المساهمة**. هل يحتوي مشروعك على [إرشادات المساهمة](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/)؟
- **إرشادات المساهمة**. هل يحتوي مشروعك على [إرشادات المساهمة](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)،
- **الرخصة**. ربما الأهم من ذلك، [الرخصة](https://docs.github.com/articles/adding-a-license-to-a-repository/)؟
كل هذه الموارد ستفيد في استيعاب أعضاء الفريق الجدد. وعادةً ما تكون هذه هي الأشياء التي ينظر إليها المساهمون الجدد قبل حتى النظر إلى الكود الخاص بك، لمعرفة ما إذا كان مشروعك هو المكان المناسب لهم لقضاء وقتهم.
كل هذه الموارد ستفيد في استيعاب أعضاء الفريق الجدد. وهذه هي عادةً الأشياء التي ينظر إليها المساهمون الجدد قبل حتى النظر إلى الكود الخاص بك، لمعرفة ما إذا كان مشروعك هو المكان المناسب لهم لقضاء وقتهم.
✅ ملفات README، على الرغم من أنها تستغرق وقتًا لإعدادها، غالبًا ما يتم إهمالها من قبل المشرفين المشغولين. هل يمكنك العثور على مثال لملف README وصفي بشكل خاص؟ ملاحظة: هناك بعض [الأدوات التي تساعد في إنشاء ملفات README جيدة](https://www.makeareadme.com/) قد ترغب في تجربتها.
✅ ملفات README، على الرغم من أنها تستغرق وقتًا لإعدادها، غالبًا ما يتم إهمالها من قبل المشرفين المشغولين. هل يمكنك العثور على مثال لواحد وصفي بشكل خاص؟ ملاحظة: هناك بعض [الأدوات التي تساعد في إنشاء ملفات README جيدة](https://www.makeareadme.com/) قد ترغب في تجربتها.
### المهمة: دمج بعض الكود
تساعد وثائق المساهمة الأشخاص على المساهمة في المشروع. تشرح الوثائق أنواع المساهمات التي تبحث عنها وكيفية عمل العملية. سيحتاج المساهمون إلى المرور بسلسلة من الخطوات ليتمكنوا من المساهمة في مستودعك على GitHub:
تساعد وثائق المساهمة الأشخاص على المساهمة في المشروع. تشرح أنواع المساهمات التي تبحث عنها وكيفية عمل العملية. سيحتاج المساهمون إلى المرور بسلسلة من الخطوات ليكونوا قادرين على المساهمة في مستودعك على GitHub:
1. **استنساخ مستودعك**. ربما سترغب في أن يقوم الأشخاص بـ _استنساخ_ مشروعك. الاستنساخ يعني إنشاء نسخة من مستودعك على ملفهم الشخصي في GitHub.
1. **الاستنساخ المحلي**. من هناك، سيقومون باستنساخ المشروع إلى جهازهم المحلي.
1. **إنشاء فرع**. سترغب في أن تطلب منهم إنشاء _فرع_ لعملهم.
1. **التركيز على تغيير واحد**. اطلب من المساهمين التركيز على مساهماتهم في شيء واحد في كل مرة - بهذه الطريقة تكون فرصتك في_دمج_ عملهم أعلى. تخيل أنهم كتبوا إصلاحًا لخلل، وأضافوا ميزة جديدة، وقاموا بتحديث عدة اختبارات - ماذا لو كنت تريد، أو يمكنك فقط تنفيذ 2 من 3، أو 1 من 3 تغييرات؟
1. **استنساخ مستودعك**. ربما سترغب في أن يقوم الناس بـ _استنساخ_ مشروعك. يعني الاستنساخ إنشاء نسخة طبق الأصل من مستودعك على ملف تعريف GitHub الخاص بهم.
1. **النسخ المحلي**. من هناك، سيقومون بنسخ المشروع إلى جهازهم المحلي.
1. **إنشاء فرع**. سترغب في أن تطلب منهم إنشاء _فرع_ لعملهم.
1. **تركيز التغيير على منطقة واحدة**. اطلب من المساهمين التركيز على مساهماتهم في شيء واحد في كل مرة - بهذه الطريقة تكون فرص أن تتمكن من_دمج_ عملهم أعلى. تخيل أنهم كتبوا إصلاحًا لخلل، وأضافوا ميزة جديدة، وقاموا بتحديث عدة اختبارات - ماذا لو كنت تريد، أو يمكنك فقط تنفيذ 2 من 3، أو 1 من 3 تغييرات؟
✅ تخيل موقفًا تكون فيه الفروع ضرورية بشكل خاص لكتابة الكود الجيد وإصداره. ما هي حالات الاستخدام التي يمكنك التفكير فيها؟
✅ تخيل موقفًا تكون فيه الفروع ضرورية بشكل خاص لكتابة وشحن كود جيد. ما هي حالات الاستخدام التي يمكنك التفكير فيها؟
> ملاحظة، كن التغيير الذي تريد رؤيته في العالم، وأنشئ فروعًا لعملك الخاص أيضًا. أي التزامات تقوم بها سيتم إجراؤها على الفرع الذي تم "التحقق منه" حاليًا. استخدم `git status` لمعرفة الفرع الذي تعمل عليه.
> ملاحظة، كن التغيير الذي تريد رؤيته في العالم، وقم بإنشاء فروع لعملك الخاص أيضًا. أي التزامات تقوم بها سيتم إجراؤها على الفرع الذي "تم التحقق منه" حاليًا. استخدم `git status` لمعرفة الفرع الذي تعمل عليه.
لنمر عبر سير عمل المساهم. افترض أن المساهم قد قام بالفعل بـ _استنساخ_ و_استنساخ محلي_ للمستودع بحيث يكون لديهم مستودع Git جاهز للعمل عليه على جهازهم المحلي:
لنمر عبر سير عمل المساهم. افترض أن المساهم قد قام بالفعل بـ _استنساخ_ و_نسخ_ المستودع بحيث يكون لديه مستودع Git جاهز للعمل عليه، على جهازه المحلي:
1. **إنشاء فرع**. استخدم الأمر `git branch` لإنشاء فرع يحتوي على التغييرات التي ينوون المساهمة بها:
1. **إنشاء فرع**. استخدم الأمر `git branch` لإنشاء فرع يحتوي على التغييرات التي يعتزم المساهمة بها:
```bash
git branch [branch-name]
@ -226,53 +226,58 @@ CO_OP_TRANSLATOR_METADATA:
git switch [branch-name]
```
1. **العمل**. في هذه المرحلة، تريد إضافة تغييراتك. لا تنسَ إخبار Git بذلك باستخدام الأوامر التالية:
1. **القيام بالعمل**. في هذه المرحلة، تريد إضافة تغييراتك. لا تنس إخبار Git بذلك باستخدام الأوامر التالية:
```bash
git add .
git commit -m "my changes"
```
تأكد من إعطاء التزامك اسمًا جيدًا، من أجلك ومن أجل مشرف المستودع الذي تساعده.
تأكد من إعطاء الالتزام اسمًا جيدًا، من أجلك وكذلك من أجل مشرف المستودع الذي تساعده.
1. **دمج عملك مع فرع `main`**. في مرحلة ما، تكون قد انتهيت من العمل وترغب في دمج عملك مع عمل فرع `main`. قد يكون فرع `main` قد تغير في هذه الأثناء، لذا تأكد من تحديثه إلى أحدث إصدار باستخدام الأوامر التالية:
1. **دمج عملك مع فرع `main`**. في مرحلة ما، تكون قد انتهيت من العمل وترغب في دمج عملك مع عمل فرع `main`. قد يكون فرع `main` قد تغير في هذه الأثناء، لذا تأكد من تحديثه أولاً إلى أحدث إصدار باستخدام الأوامر التالية:
```bash
git switch main
git pull
```
في هذه المرحلة، تريد التأكد من أن أي _تعارضات_، وهي الحالات التي لا يستطيع Git فيها بسهولة _دمج_ التغييرات، تحدث في فرع العمل الخاص بك. لذلك، قم بتشغيل الأوامر التالية:
في هذه المرحلة، تريد التأكد من أن أي _تعارضات_، وهي حالات لا يستطيع Git بسهولة _دمج_ التغييرات، تحدث في فرع العمل الخاص بك. لذلك قم بتشغيل الأوامر التالية:
```bash
git switch [branch_name]
git merge main
```
سيؤدي هذا إلى جلب جميع التغييرات من `main` إلى فرعك، ونأمل أن تتمكن من المتابعة. إذا لم يكن الأمر كذلك، فسيخبرك VS Code بالمكان الذي يكون فيه Git _مرتبكًا_، وستقوم فقط بتعديل الملفات المتأثرة لتحديد المحتوى الأكثر دقة.
سيقوم أمر `git merge main` بجلب جميع التغييرات من `main` إلى فرعك. نأمل أن تتمكن من المتابعة بسهولة. إذا لم يكن الأمر كذلك، سيخبرك VS Code بالمكان الذي يكون فيه Git _مرتبكًا_، وستقوم بتعديل الملفات المتأثرة لتحديد المحتوى الأكثر دقة.
للتبديل إلى فرع مختلف، استخدم الأمر الحديث `git switch`:
```bash
git switch [branch_name]
1. **إرسال عملك إلى GitHub**. إرسال عملك إلى GitHub يعني شيئين: دفع فرعك إلى مستودعك وفتح طلب سحب (PR).
1. **إرسال عملك إلى GitHub**. إرسال عملك إلى GitHub يعني شيئين. دفع فرعك إلى مستودعك ثم فتح طلب سحب (Pull Request).
```bash
git push --set-upstream origin [branch-name]
```
ينشئ الأمر أعلاه الفرع على مستودعك المستنسخ.
1. **فتح طلب سحب (PR)**. بعد ذلك، تريد فتح طلب سحب. يمكنك القيام بذلك عن طريق الانتقال إلى المستودع المستنسخ على GitHub. سترى مؤشرًا على GitHub يسألك عما إذا كنت تريد إنشاء طلب سحب جديد، انقر على ذلك وستنتقل إلى واجهة حيث يمكنك تغيير عنوان رسالة الالتزام، وإعطائها وصفًا أكثر ملاءمة. الآن سيرى مشرف المستودع الذي استنسخته هذا الطلب و_بإذن الله_ سيقدر ذلك و_يدمج_ طلبك. أنت الآن مساهم، تهانينا :)
يقوم الأمر أعلاه بإنشاء الفرع على مستودعك المستنسخ.
1. **افتح طلب سحب (PR)**. بعد ذلك، عليك فتح طلب سحب. يمكنك القيام بذلك من خلال الانتقال إلى المستودع الذي قمت بتفريعه على GitHub. ستجد إشارة على GitHub تسألك ما إذا كنت ترغب في إنشاء طلب سحب جديد، اضغط عليها وستنتقل إلى واجهة حيث يمكنك تعديل عنوان رسالة الالتزام وإضافة وصف أكثر ملاءمة. الآن، سيرى المسؤول عن المستودع الذي قمت بتفريعه هذا الطلب، و_نأمل_ أن يقدر جهودك و_يدمج_ طلبك. تهانينا، لقد أصبحت مساهمًا، رائع! :)
1. **تنظيف العمل**. يُعتبر تنظيف العمل بعد دمج طلب السحب بنجاح ممارسة جيدة. تريد تنظيف الفرع المحلي الخاص بك والفرع الذي دفعته إلى GitHub. أولاً، احذف الفرع محليًا باستخدام الأمر التالي:
1. **تنظيف**. من الجيد أن تقوم بـ_تنظيف_ بعد دمج طلب السحب بنجاح. يجب عليك تنظيف الفرع المحلي الخاص بك والفرع الذي قمت بدفعه إلى GitHub. أولاً، احذف الفرع محليًا باستخدام الأمر التالي:
```bash
git branch -d [branch-name]
```
تأكد من الانتقال إلى صفحة GitHub الخاصة بالمستودع الذي قمت بتفريعه وحذف الفرع البعيد الذي قمت بدفعه إليه.
تأكد من الانتقال إلى صفحة GitHub الخاصة بالمستودع المستنسخ بعد ذلك وإزالة الفرع البعيد الذي دفعته إليه.
`Pull request` يبدو كأنه مصطلح غريب لأنه في الواقع تريد دفع تغييراتك إلى المشروع. ولكن يحتاج المسؤول (مالك المشروع) أو الفريق الأساسي إلى مراجعة تغييراتك قبل دمجها مع الفرع "الرئيسي" للمشروع، لذا فأنت في الحقيقة تطلب قرارًا بشأن التغيير من المسؤول.
مصطلح `Pull request` قد يبدو غريبًا بعض الشيء لأنه في الواقع تريد دفع تغييراتك إلى المشروع. ولكن المسؤول (مالك المشروع) أو الفريق الأساسي يحتاج إلى مراجعة تغييراتك قبل دمجها مع الفرع "الرئيسي" للمشروع، لذا فأنت تطلب قرارًا بشأن التغيير من المسؤول.
`Pull request` هو المكان الذي يتم فيه مقارنة ومناقشة الفروقات التي تم إدخالها على فرع معين مع المراجعات، التعليقات، الاختبارات المدمجة، والمزيد. `Pull request` الجيد يتبع تقريبًا نفس القواعد التي يتبعها رسالة الالتزام (commit message). يمكنك إضافة إشارة إلى مشكلة في متتبع المشاكل، على سبيل المثال عندما تقوم بحل مشكلة معينة. يتم ذلك باستخدام `#` متبوعًا برقم المشكلة. على سبيل المثال:`#97`.
طلب السحب هو المكان الذي يتم فيه مقارنة ومناقشة الفروقات التي تم إدخالها على فرع معين مع المراجعات، التعليقات، الاختبارات المدمجة، والمزيد. طلب السحب الجيد يتبع تقريبًا نفس قواعد رسالة الالتزام. يمكنك إضافة مرجع إلى مشكلة في متتبع المشاكل، على سبيل المثال عندما تحل عملك مشكلة معينة. يتم ذلك باستخدام `#` متبوعًا برقم المشكلة، مثل`#97`.
🤞نتمنى أن تجتاز جميع الفحوصات وأن يقوم مالك المشروع بدمج تغييراتك في المشروع🤞
🤞نأمل أن تمر جميع الفحوصات بنجاح وأن يقوم مالك المشروع بدمج تغييراتك في المشروع🤞
قم بتحديث الفرع المحلي الحالي الخاص بك بجميع الالتزامات الجديدة من الفرع البعيد المقابل على GitHub:
@ -282,16 +287,16 @@ CO_OP_TRANSLATOR_METADATA:
أولاً، دعنا نجد مستودعًا (**repo**) على GitHub يثير اهتمامك وترغب في المساهمة فيه. ستحتاج إلى نسخ محتوياته إلى جهازك.
✅ طريقة جيدة للعثور على مستودعات مناسبة للمبتدئين هي [البحث باستخدام الوسم 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ طريقة جيدة للعثور على مستودعات مناسبة للمبتدئين هي [البحث باستخدام العلامة 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
هناك عدة طرق لنسخ الكود. إحدى الطرق هي "استنساخ" محتويات المستودع باستخدام HTTPS، SSH، أو باستخدام GitHub CLI (واجهة سطر الأوامر).
هناك عدة طرق لنسخ الكود. إحدى الطرق هي "استنساخ" محتويات المستودع باستخدام HTTPS أو SSH أو باستخدام GitHub CLI (واجهة سطر الأوامر).
افتح الطرفية الخاصة بك واستنسخ المستودع كالتالي:
افتح الطرفية الخاصة بك واستنسخ المستودع كالتالي:
`git clone https://github.com/ProjectURL`
للعمل على المشروع، انتقل إلى المجلد الصحيح:
للعمل على المشروع، انتقل إلى المجلد الصحيح:
`cd ProjectURL`
يمكنك أيضًا فتح المشروع بالكامل باستخدام [Codespaces](https://github.com/features/codespaces)، محرر الكود المدمج / بيئة التطوير السحابية من GitHub، أو [GitHub Desktop](https://desktop.github.com/).
@ -300,9 +305,9 @@ CO_OP_TRANSLATOR_METADATA:
### بعض الأمور المثيرة للاهتمام حول GitHub
يمكنك وضع نجمة، متابعة، أو "تفرع" أي مستودع عام على GitHub. يمكنك العثور على المستودعات التي وضعت لها نجمة في القائمة المنسدلة في الزاوية العلوية اليمنى. يشبه ذلك الإشارات المرجعية، ولكن للكود.
يمكنك وضع نجمة، متابعة، أو "تفريع" أي مستودع عام على GitHub. يمكنك العثور على المستودعات التي وضعت لها نجمة في القائمة المنسدلة في الزاوية العلوية اليمنى. إنها مثل الإشارات المرجعية، ولكن للكود.
تحتوي المشاريع على متتبع مشاكل، غالبًا على GitHub في علامة التبويب "Issues" ما لم يُذكر خلاف ذلك، حيث يناقش الأشخاص المشاكل المتعلقة بالمشروع. وعلامة التبويب Pull Requests هي المكان الذي يناقش فيه الأشخاص ويقومون بمراجعة التغييرات التي قيد التنفيذ.
المشاريع تحتوي على متتبع مشاكل، غالبًا على GitHub في علامة التبويب "Issues" ما لم يُذكر خلاف ذلك، حيث يناقش الأشخاص المشاكل المتعلقة بالمشروع. وعلامة التبويب Pull Requests هي المكان الذي يناقش فيه الأشخاص ويستعرضون التغييرات التي قيد التنفيذ.
قد تحتوي المشاريع أيضًا على مناقشات في المنتديات، قوائم بريدية، أو قنوات دردشة مثل Slack، Discord، أو IRC.
@ -310,30 +315,30 @@ CO_OP_TRANSLATOR_METADATA:
---
## 🚀 التحدي
## 🚀 التحدي
تعاون مع صديق للعمل على كود بعضكما البعض. أنشئ مشروعًا بشكل تعاوني، قم بتفرع الكود، أنشئ فروعًا، وادمج التغييرات.
تعاون مع صديق للعمل على كود بعضكما البعض. قم بإنشاء مشروع بشكل تعاوني، تفريع الكود، إنشاء فروع، ودمج التغييرات.
## اختبار ما بعد المحاضرة
## اختبار ما بعد المحاضرة
[اختبار ما بعد المحاضرة](https://ff-quizzes.netlify.app/web/en/)
## المراجعة والدراسة الذاتية
اقرأ المزيد عن [المساهمة في برمجيات المصادر المفتوحة](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
اقرأ المزيد عن [المساهمة في البرمجيات مفتوحة المصدر](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
مارس، مارس، مارس. GitHub يقدم مسارات تعليمية رائعة عبر [skills.github.com](https://skills.github.com):
مارس، مارس، مارس. GitHub يوفر مسارات تعليمية رائعة عبر [skills.github.com](https://skills.github.com):
- [الأسبوع الأول على GitHub](https://skills.github.com/#first-week-on-github)
ستجد أيضًا دورات أكثر تقدمًا.
## الواجب
## الواجب
أكمل [دورة الأسبوع الأول على GitHub](https://skills.github.com/#first-week-on-github)
---
**إخلاء المسؤولية**:
تم ترجمة هذا المستند باستخدام خدمة الترجمة الآلية [Co-op Translator](https://github.com/Azure/co-op-translator). بينما نسعى لتحقيق الدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية هو المصدر الموثوق. للحصول على معلومات حساسة، يُوصى بالاستعانة بترجمة بشرية احترافية. نحن غير مسؤولين عن أي سوء فهم أو تفسيرات خاطئة ناتجة عن استخدام هذه الترجمة.
تم ترجمة هذا المستند باستخدام خدمة الترجمة بالذكاء الاصطناعي [Co-op Translator](https://github.com/Azure/co-op-translator). بينما نسعى لتحقيق الدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية المصدر الرسمي. للحصول على معلومات حاسمة، يُوصى بالاستعانة بترجمة بشرية احترافية. نحن غير مسؤولين عن أي سوء فهم أو تفسيرات خاطئة ناتجة عن استخدام هذه الترجمة.
- проследяване на работата, която вършите на вашата машина
- проследяване на работата, която вършите на вашия компютър
- работа по проекти с други хора
- как да допринасяте за софтуер с отворен код
### Предварителни изисквания
Преди да започнете, трябва да проверите дали Git е инсталиран. В терминала въведете:
Преди да започнете, трябва да проверите дали Git е инсталиран. В терминала напишете:
`git --version`
Ако Git не е инсталиран, [изтеглете Git](https://git-scm.com/downloads). След това настройте вашия локален Git профил в терминала:
* `git config --global user.name "вашето-име"`
* `git config --global user.email "вашият-имейл"`
За да проверите дали Git вече е конфигуриран, можете да въведете:
За да проверите дали Git вече е конфигуриран, можете да напишете:
`git config --list`
Ще ви е необходим и акаунт в GitHub, текстов редактор за код (като Visual Studio Code) и ще трябва да отворите вашия терминал (или команден прозорец).
Ще ви е необходим и акаунт в GitHub, редактор за код (като Visual Studio Code) и трябва да отворите вашия терминал (или команден ред).
Посетете [github.com](https://github.com/) и създайте акаунт, ако все още нямате такъв, или влезте и попълнете вашия профил.
Отидете на [github.com](https://github.com/) и създайте акаунт, ако все още нямате такъв, или влезте и попълнете вашия профил.
✅ GitHub не е единственото хранилище за код в света; има и други, но GitHub е най-известното.
### Подготовка
Ще ви е необходима папка с проект на код на вашата локална машина (лаптоп или компютър) и публично хранилище в GitHub, което ще служи като пример за това как да допринасяте за проекти на други хора.
Ще ви е необходима папка с проект на код на вашия локален компютър (лаптоп или PC) и публично хранилище в GitHub, което ще служи като пример за това как да допринасяте за проектите на други хора.
---
## Управление на кода
## Управление на код
Да кажем, че имате папка локално с някакъв проект на код и искате да започнете да проследявате вашия напредък, използвайки git - системата за контрол на версиите. Някои хора сравняват използването на git с писане на любовно писмо до бъдещото ви аз. Четейки вашите съобщения за комити дни, седмици или месеци по-късно, ще можете да си припомните защо сте взели дадено решение или да "върнете" промяна - стига да пишете добри "съобщения за комити".
Да кажем, че имате локална папка с проект на код и искате да започнете да проследявате вашия напредъкс помощта на git - системата за контрол на версиите. Някои хора сравняват използването на git с писане на любовно писмо до вашето бъдещо аз. Четейки вашите съобщения за комит дни, седмици или месеци по-късно, ще можете да си припомните защо сте взели дадено решение или да "върнете" промяна - стига да пишете добри "съобщения за комит".
### Задача: Създайте хранилище и комитнете код
@ -59,30 +59,30 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Създайте хранилище в GitHub**. В GitHub.com, в раздела с хранилища или от навигационната лента горе вдясно, намерете бутона **new repo**.
1. **Създайте хранилище в GitHub**. На GitHub.com, в раздела за хранилища или от навигационната лента горе вдясно, намерете бутона **new repo**.
1. Дайте име на вашето хранилище (папка).
1. Изберете **create repository**.
1. **Навигирайте до вашата работна папка**. В терминала преминете към папката (известна също като директория), която искате да започнете да проследявате. Въведете:
1. **Навигирайте до вашата работна папка**. В терминала преминете към папката (известна още като директория), която искате да започнете да проследявате. Напишете:
```bash
cd [name of your folder]
```
1. **Инициализирайте git хранилище**. Във вашия проект въведете:
1. **Инициализирайте git хранилище**. Във вашия проект напишете:
```bash
git init
```
1. **Проверете статуса**. За да проверите статуса на вашето хранилище, въведете:
1. **Проверете статуса**. За да проверите статуса на вашето хранилище, напишете:
```bash
git status
```
Резултатът може да изглежда така:
резултатът може да изглежда така:
```output
Changes not staged for commit:
@ -93,16 +93,16 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
Обикновено командата `git status` ви казва неща като кои файлове са готови за _записване_ в хранилището или имат промени, които може да искате да запазите.
Обикновено командата `git status` ви казва неща като кои файлове са готови за _запазване_ в хранилището или имат промени, които може да искате да запазите.
1. **Добавете всички файлове за проследяване**
Това също се нарича поставяне на файлове в зоната за подготовка.
1. **Добавете всички файлове за проследяване**
Това също се нарича поставяне на файлове/ добавяне на файлове в зоната за поставяне.
```bash
git add .
```
Аргументът `git add` плюс `.` означава, че всички ваши файлове и промени ще бъдат проследявани.
Аргументът `git add` плюс `.`показва, че всички ваши файлове и промени са готови за проследяване.
1. **Добавете избрани файлове за проследяване**
@ -110,53 +110,53 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
Това ни помага да добавим само избрани файлове в зоната за подготовка, когато не искаме да комитнем всички файлове наведнъж.
Това ни помага да добавим само избрани файлове в зоната за поставяне, когато не искаме да комитнем всички файлове наведнъж.
1. **Премахнете всички файлове от зоната за подготовка**
1. **Премахнете всички файлове от зоната за поставяне**
```bash
git reset
```
Тази команда ни помага да премахнем всички файлове от зоната за подготовка наведнъж.
Тази команда ни помага да премахнем всички файлове от зоната за поставяне наведнъж.
1. **Премахнете конкретен файл от зоната за подготовка**
1. **Премахнете конкретен файл от зоната за поставяне**
```bash
git reset [file or folder name]
```
Тази команда ни помага да премахнем само конкретен файл от зоната за подготовка, който не искаме да включим в следващия комит.
Тази команда ни помага да премахнем само конкретен файл от зоната за поставяне, който не искаме да включим в следващия комит.
1. **Запазване на вашата работа**. На този етап сте добавили файловете в така наречената _зона за подготовка_. Това е място, където Git проследява вашите файлове. За да направите промяната постоянна, трябва да _комитнете_ файловете. За да създадете _комит_, въведете следното:
1. **Запазване на вашата работа**. На този етап сте добавили файловете в така наречената _зона за поставяне_. Място, където Git проследява вашите файлове. За да направите промяната постоянна, трябва да _комитнете_ файловете. За да направите това, създавате _комит_с командата `git commit`. _Комит_ представлява точка за запазване в историята на вашето хранилище. Напишете следното, за да създадете _комит_:
```bash
git commit -m "first commit"
```
Това комитва всички ваши файлове, добавяйки съобщението "first commit". За бъдещи съобщения за комити ще искате да бъдете по-описателни, за да предадете какъв тип промяна сте направили.
Това комитва всички ваши файлове, добавяйки съобщението "first commit". За бъдещи съобщения за комит ще искате да бъдете по-описателни, за да предадете какъв тип промяна сте направили.
1. **Свържете вашето локално Git хранилище с GitHub**. Git хранилище е полезно на вашата машина, но в даден момент ще искате да имате резервно копие на вашите файлове някъде и също така да поканите други хора да работят с вас върху вашето хранилище. Едно такова чудесно място е GitHub. Помните, че вече създадохме хранилище в GitHub, така че единственото, което трябва да направим, е да свържем нашето локално Git хранилище с GitHub. Командата `git remote add` ще направи точно това. Въведете следната команда:
1. **Свържете вашето локално Git хранилище с GitHub**. Git хранилище е полезно на вашия компютър, но в даден момент ще искате да имате резервно копие на вашите файлове някъде и също така да поканите други хора да работят с вас върху вашето хранилище. Едно такова чудесно място за това е GitHub. Помнете, че вече сме създали хранилище в GitHub, така че единственото, което трябва да направим, е да свържем нашето локално Git хранилище с GitHub. Командата `git remote add` ще направи точно това. Напишете следната команда:
> Забележка: преди да въведете командата, отидете на страницата на вашето GitHub хранилище, за да намерите URL адреса на хранилището. Ще го използвате в командата по-долу. Заменете ```https://github.com/username/repository_name.git``` с вашия GitHub URL.
> Забележка: преди да напишете командата, отидете на страницата на вашето GitHub хранилище, за да намерите URL адреса на хранилището. Ще го използвате в командата по-долу. Заменете ```https://github.com/username/repository_name.git``` с вашия GitHub URL.
Това създава _remote_ или връзка, наречена "origin", сочеща към GitHub хранилището, което създадохте по-рано.
1. **Изпратете локалните файлове в GitHub**. Досега сте създали _връзка_ между локалното хранилище и GitHub хранилището. Нека изпратим тези файлове в GitHub със следната команда `git push`, както следва:
Това създава _remote_, или връзка, наречена "origin", сочеща към GitHub хранилището, което създадохте по-рано.
1. **Изпратете локалните файлове в GitHub**. Досега сте създали _връзка_ между локалното хранилище и GitHub хранилището. Нека изпратим тези файлове в GitHub със следната команда `git push`, както следва:
> Забележка: името на вашия клон може да е различно по подразбиране от ```main```.
```bash
git push -u origin main
```
Това изпраща вашите комити в клона "main" в GitHub.
Това изпраща вашите комити в клона "main" в GitHub. Задаването на `upstream` клон, включително `-u` в командата, установява връзка между вашия локален клон и отдалечения клон, така че можете просто да използвате git push или git pull, без да посочвате името на клона в бъдеще. Git автоматично ще използва upstream клона и няма да е необходимо да посочвате името на клона изрично в бъдещи команди.
2. **Добавяне на още промени**. Ако искате да продължите да правите промени и да ги изпращате в GitHub, ще трябва да използвате следните три команди:
2. **Добавяне на още промени**. Ако искате да продължите да правите промени и да ги изпращате в GitHub, просто ще трябва да използвате следните три команди:
```bash
git add .
@ -164,21 +164,21 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> Съвет: Може също да искате да използвате файл `.gitignore`, за да предотвратите появата на файлове, които не искате да проследявате, в GitHub - например файл с бележки, който съхранявате в същата папка, но няма място в публично хранилище. Можете да намерите шаблони за файлове `.gitignore` на [.gitignore templates](https://github.com/github/gitignore).
> Съвет: Може също да искате да използвате файл `.gitignore`, за да предотвратите появата на файлове, които не искате да проследявате, в GitHub - като например файл с бележки, който съхранявате в същата папка, но няма място в публично хранилище. Можете да намерите шаблони за файлове `.gitignore` на [.gitignore templates](https://github.com/github/gitignore).
#### Съобщения за комити
#### Съобщения за комит
Чудесно заглавие на съобщение за Git комит завършва следното изречение:
Ако бъде приложено, този комит ще <вашето заглавие тук>.
Добро заглавие на съобщение за Git комит завършва следното изречение:
Ако бъде приложено, този комит ще <вашето заглавие тук>
За заглавието използвайте повелително наклонение в сегашно време: "променя" вместо "променено" или "променя се".
Както в заглавието, така и в тялото (по избор) използвайте повелително наклонение в сегашно време. Тялото трябва да включва мотивацията за промяната и да я сравнявас предишното поведение. Обяснявате `защо`, а не `как`.
За заглавието използвайте императивно настояще време: "промени" вместо "променено" или "промени".
Както в заглавието, така и в тялото (по избор) използвайте императивно настояще време. Тялото трябва да включва мотивацията за промяната и да я сравнис предишното поведение. Обяснявате `защо`, а не `как`.
✅ Отделете няколко минути, за да разгледате GitHub. Можете ли да намерите наистина страхотно съобщение за комит? А минимално такова? Каква информация според вас е най-важна и полезна за предаване в съобщение за комит?
✅ Отделете няколко минути, за да разгледате GitHub. Можете ли да намерите наистина добро съобщение за комит? Можете ли да намерите наистина минимално? Каква информация според вас е най-важна и полезна за предаване в съобщение за комит?
### Задача: Сътрудничество
Основната причина за качването на неща в GitHub е да се направи възможно сътрудничеството с други разработчици.
Основната причина за качването на неща в GitHub беше да се направи възможно сътрудничеството с други разработчици.
## Работа по проекти с други хора
@ -186,33 +186,34 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Във вашето хранилище навигирайте до `Insights > Community`, за да видите как вашият проект се сравнява с препоръчаните стандарти на общността.
Във вашето хранилище навигирайте до `Insights > Community`, за да видите как вашият проект се сравнява с препоръчаните стандарти за общността.
Ето някои неща, които могат да подобрят вашето GitHub хранилище:
- **Описание**. Добавихте ли описание за вашия проект?
- **README**. Добавихте ли README? GitHub предоставя насоки за писане на [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/)?
Ето някои неща, които могат да подобрят вашето GitHub хранилище:
- **Описание**. Добавихте ли описание на вашия проект?
- **README**. Добавихте ли README? GitHub предоставя насоки за писане на [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 файлове](https://www.makeareadme.com/), които може да искате да опитате.
✅ README файловете, въпреки че отнемат време за подготовка, често се пренебрегват от заети поддържатели. Можете ли да намерите пример за особено описателен README? Забележка: има някои [инструменти за създаване на добри README файлове](https://www.makeareadme.com/), които може да искате да опитате.
### Задача: Сливане на код
### Задача: Слейте код
Документите за принос помагат на хората да допринасят за проекта. Те обясняват какви видове приноси търсите и как работи процесът. Сътрудниците ще трябва да преминат през серия от стъпки, за да могат да допринесат за вашето хранилище в GitHub:
Документите за допринасяне помагат на хората да допринасят за проекта. Те обясняват какви типове допринасяния търсите и как работи процесът. Сътрудниците ще трябва да преминат през серия от стъпки, за да могат да допринасят за вашето хранилище в GitHub:
1. **Форкване на вашето хранилище**. Вероятно ще искате хората да _форкнат_ вашия проект. Форкването означава създаване на копие на вашето хранилище в техния GitHub профил.
1. **Клониране**. Оттам те ще клонират проекта на своята локална машина.
1. **Форкване на вашето хранилище**. Вероятно ще искате хората да _форкнат_ вашия проект. Форкването означава създаване на реплика на вашето хранилище в техния GitHub профил.
1. **Клониране**. Оттам те ще клонират проекта на своя локален компютър.
1. **Създаване на клон**. Ще искате да ги помолите да създадат _клон_ за своята работа.
1. **Фокусиране върху една област**. Помолете сътрудниците да концентрират своите приноси върху едно нещо наведнъж - така шансовете да можете да _слеете_ тяхната работа са по-големи. Представете си, че те пишат поправка на грешка, добавят нова функция и актуализират няколко теста - какво ако искате или можете да приложите само 2 от 3, или 1 от 3 промени?
1. **Фокусиране на промяната върху една област**. Помолете сътрудниците да концентрират своите допринасяния върху едно нещо наведнъж - така шансовете да можете да _слеете_ тяхната работа са по-високи. Представете си, че те пишат поправка на бъг, добавят нова функция и актуализират няколко теста - какво ако искате или можете да приложите само 2 от 3, или 1 от 3 промени?
✅ Представете си ситуация, в която клоновете са особено критични за писането и доставянето на добър код. Какви случаи на употреба можете да си представите?
> Забележка: бъдете промяната, която искате да видите в света, и създавайте клонове и за вашата собствена работа. Всички комити, които правите, ще бъдат направени в клона, в който в момента сте "чекнати". Използвайте `git status`, за да видите в кой клон се намирате.
> Забележка: бъдете промяната, която искате да видите в света, и създавайте клонове за вашата собствена работа също. Всички комити, които правите, ще бъдат направени в клона, в който сте "преминали". Използвайте `git status`, за да видите кой клон е това.
Нека преминем през работния процес на сътрудник. Да предположим, че сътрудникът вече е_форкнал_ и _клонирал_ хранилището, така че има готово Git хранилище на своята локална машина:
Нека преминем през работния процес на сътрудник. Да предположим, че сътрудникът вече е_форкнал_ и _клонирал_ хранилището, така че има готово Git хранилище за работа на своя локален компютър:
1. **Създаване на клон**. Използвайте командата `git branch`, за да създадете клон, който ще съдържа промените, които възнамеряват да допринесат:
@ -233,88 +234,93 @@ CO_OP_TRANSLATOR_METADATA:
git commit -m "my changes"
```
Уверете се, че давате добро име на вашия комит, както за вас, така и за поддържащия на хранилището, на което помагате.
Уверете се, че давате на вашия комит добро име, за ваше удобство, както и за поддържателя на хранилището, на което помагате.
1. **Комбиниране на вашата работа с клона `main`**. В даден момент сте готови с работата си и искате да я комбинирате с тази на клона `main`. Клонът `main` може да сее променил междувременно, така че се уверете, че първо го актуализирате до последната версия със следните команди:
1. **Сливане на вашата работа с клона `main`**. В даден момент сте готови с работата си и искате да я слеете с тази на клона `main`. Междувременно клонът `main` може да сее променил, така че се уверете, че първо го актуализирате до последната версия със следните команди:
```bash
git switch main
git pull
```
На този етап искате да се уверите, че всички _конфликти_, ситуации, в които Git не може лесно да _комбинира_ промените, се случват във вашия работен клон. Затова изпълнете следните команди:
На този етап искате да се уверите, че всички _конфликти_, ситуации, в които Git не може лесно да _слее_ промените, се случват във вашия работен клон. Затова изпълнете следните команди:
```bash
git switch [branch_name]
git merge main
```
Това ще внесе всички промени от `main` във вашия клон и, надяваме се, ще можете просто да продължите. Ако не, VS Code ще ви покаже къде Git е_объркан_ и просто ще промените засегнатите файлове, за да посочите кое съдържание е най-точно.
Командата `git merge main` ще внесе всички промени от `main` във вашия клон. Надяваме се, че можете просто да продължите. Ако не, VS Code ще ви покаже къде Git е_объркан_ и просто променяте засегнатите файлове, за да посочите кое съдържание е най-точно.
1. **Изпращане на вашата работа в GitHub**. Изпращането на вашата работа в GitHub означава две неща. Пушване на вашия клон във вашето хранилище и след това отваряне на PR (Pull Request).
За да превключите към различен клон, използвайте модерната команда `git switch`:
```bash
git switch [branch_name]
1. **Изпратете вашата работа в GitHub**. Изпращането на вашата работа в GitHub означава две неща. Пушване на вашия клон във вашето хранилище и след това отваряне на PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Горната команда създава клона във вашето форкнато хранилище.
1. **Отворете PR**. Следващата стъпка е да отворите PR. Това става, като отидете в клонираното хранилище в GitHub. Ще видите индикация в GitHub, която пита дали искате да създадете нов PR. Кликнете върху това и ще бъдете пренасочени към интерфейс, където можете да промените заглавието на съобщението за комит и да добавите по-подходящо описание. Сега поддържащият на хранилището, което сте клонирали, ще види този PR и _дасе надяваме_ ще го оцени и _обедини_ вашия PR. Вече сте сътрудник, ура :)
1. **Отваряне на PR**. След това искате да отворите PR. Това става, като навигирате до форкнатото хранилище в GitHub. Ще видите индикация в GitHub, където се пита дали искате да създадете нов PR, кликнете върху това и ще бъдете отведени до интерфейс, където можете да промените заглавието на съобщението за комит, да му дадете по-подходящо описание. Сега поддържащият на хранилището, което сте форкнали, ще види този PR и _с кръстени пръсти_ ще оцени и _слее_ вашия PR. Вече сте сътрудник, ура :)
1. **Почистване**. Счита се за добра практика да _почистите_ след успешно сливане на PR. Искате да изчистите както вашия локален клон, така и клона, който сте пушнали в GitHub. Първо, нека го изтрием локално със следната команда:
1. **Почистване**. Счита се за добра практика да _почистите_, след като успешно обедините PR. Трябва да почистите както локалния си клон, така и клона, който сте качили в GitHub. Първо, нека го изтрием локално със следната команда:
```bash
git branch -d [branch-name]
```
Уверете се, че сте отишли на страницата на клонираното хранилище в GitHub и сте премахнали отдалечения клон, който току-що сте качили.
Уверете се, че отивате на страницата на GitHub за форкнатото хранилище и премахнете отдалечения клон, който току-
`Pull request` изглежда като странен термин, защото всъщност искате да "пушнете" вашите промени към проекта. Но поддръжникът (собственикът на проекта) или основният екип трябва да разгледат вашите промени, преди да ги обединят с "главния" клон на проекта, така че всъщност искате решение за промяна от поддръжника.
`Pull request` може да изглежда като странен термин, защото всъщност искате да качите промените си в проекта. Но поддържащият (собственикът на проекта) или основният екип трябва да разгледа вашите промени, преди да ги обедини с "главния" клон на проекта, така че всъщност искате решение за промяна от поддържащия.
`Pull request`е мястото, където се сравняват и обсъждат разликите, въведени в даден клон, с ревюта, коментари, интегрирани тестове и други. Един добър `pull request` следва приблизително същите правила като съобщение за commit. Можете да добавите препратка към проблем в тракера за проблеми, например когато вашата работа решава даден проблем. Това се прави с помощта на`#`, последвано от номера на проблема. Например `#97`.
Pull request е мястото, където можете да сравнявате и обсъждате разликите, въведени в клона, с ревюта, коментари, интегрирани тестове и други. Един добър pull request следва приблизително същите правила като съобщението за комит. Можете да добавите препратка към проблем в тракера за проблеми, например когато вашата работа решава даден проблем. Това се прави с`#`, последвано от номера на проблема. Например `#97`.
🤞Стискайте палци всички проверки да преминат успешно и собствениците на проекта да обединят вашите промени в проекта🤞
🤞Да се надяваме, че всички проверки ще преминат успешно и собственикът(ите) на проекта ще обединят вашите промени в проекта🤞
Актуализирайте текущия локален работен клон с всички нови commit-и от съответния отдалечен клон в GitHub:
Актуализирайте текущия локален работен клон с всички нови комити от съответния отдалечен клон в GitHub:
`git pull`
## Как да допринесете за отворен код
## Как да допринасяте към отворен код
Първо, намерете хранилище (или **repo**) в GitHub, което ви интересува и към което искате да допринесете с промяна. Ще искате да копирате съдържанието му на вашата машина.
Първо, нека намерим хранилище (или **repo**) в GitHub, което ви интересува и към което искате да допринесете с промяна. Ще трябва да копирате съдържанието му на вашата машина.
✅ Добър начин да намерите хранилища, подходящи за начинаещи, екато [търсите по етикета 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Добър начин да намерите хранилища, подходящи за начинаещи, еда [търсите по етикета 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Има няколко начина за копиране на код. Един от тях е да "клонирате" съдържанието на хранилището, използвайки HTTPS, SSH или GitHub CLI (Command Line Interface).
Отворете вашия терминал и клонирайте хранилището по следния начин:
Отворете терминала си и клонирайте хранилището по следния начин:
`git clone https://github.com/ProjectURL`
За да работите по проекта, преминете към правилната папка:
За да работите по проекта, преминете към правилната папка:
`cd ProjectURL`
Можете също така да отворите целия проект, използвайки [Codespaces](https://github.com/features/codespaces), вградения редактор на код / облачна среда за разработка на GitHub, или [GitHub Desktop](https://desktop.github.com/).
Накрая, можете да изтеглите кода в компресиран файл.
Накрая, можете да изтеглите кода в компресиран папка.
### Още няколко интересни неща за GitHub
### Няколко интересни неща за GitHub
Можете да добавите звезда, да следите или да "форкнете" всяко публично хранилище в GitHub. Можете да намерите вашите хранилища със звезди в падащото меню горе вдясно. Това е като да запазите отметка, но за код.
Можете да добавите звезда, да следите и/или да "клонирате" всяко публично хранилище в GitHub. Можете да намерите вашите хранилища със звезда в падащото меню в горния десен ъгъл. Това е като отметка, но за код.
Проектите имат тракер за проблеми, обикновено в раздела "Issues" в GitHub, освен ако не е посочено друго, където хората обсъждат проблеми, свързани с проекта. А разделът "Pull Requests"е мястото, където хората обсъждат и преглеждат промени, които са в процес на работа.
Проектите имат тракер за проблеми, най-често в GitHub в раздела "Issues", освен ако не е посочено друго, където хората обсъждат проблеми, свързани с проекта. А разделът Pull Requests е мястото, където хората обсъждат и преглеждат промени, които са в процес на работа.
Проектите може също да имат дискусии във форуми, пощенски списъци или чат канали като Slack, Discord или IRC.
✅ Разгледайте вашето ново хранилище в GitHub и опитайте няколко неща, като редактиране на настройки, добавяне на информация към вашето хранилище и създаване на проект (като Канбан дъска). Има много неща, които можете да направите!
✅ Разгледайте новото си хранилище в GitHub и опитайте няколко неща, като редактиране на настройки, добавяне на информация към хранилището и създаване на проект (като Канбан дъска). Има много неща, които можете да направите!
---
## 🚀 Предизвикателство
Работете в екип с приятел върху кода на другия. Създайте проект съвместно, форкнете код, създайте клонове и обединете промените.
Работете в екип с приятел върху кода на другия. Създайте проект съвместно, клонирайте код, създайте клонове и обединете промени.
## Тест след лекцията
## Тест след лекцията
[Тест след лекцията](https://ff-quizzes.netlify.app/web/en/)
Практика, практика, практика. GitHub предлага страхотни учебни пътеки чрез [skills.github.com](https://skills.github.com):
Практикувайте, практикувайте, практикувайте. GitHub предлага страхотни учебни пътеки чрез [skills.github.com](https://skills.github.com):
- [Първата седмица в GitHub](https://skills.github.com/#first-week-on-github)
Ще намерите и по-напреднали курсове.
## Задание
## Задача
Завършете [курса "Първата седмица в GitHub"](https://skills.github.com/#first-week-on-github)
---
**Отказ от отговорност**:
Този документ е преведен с помощта на AI услуга за превод [Co-op Translator](https://github.com/Azure/co-op-translator). Въпреки че се стремим към точност, моля, имайте предвид, че автоматизираните преводи може да съдържат грешки или неточности. Оригиналният документ на неговия изходен език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален превод от човек. Ние не носим отговорност за каквито и да е недоразумения или погрешни интерпретации, произтичащи от използването на този превод.
Този документ е преведен с помощта на AI услуга за превод [Co-op Translator](https://github.com/Azure/co-op-translator). Въпреки че се стремим към точност, моля, имайте предвид, че автоматизираните преводи може да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за недоразумения или погрешни интерпретации, произтичащи от използването на този превод.
শুরু করার আগে, আপনাকে দেখতে হবে Git ইনস্টল করা আছে কিনা। টার্মিনালে টাইপ করুন:
`git --version`
যদি Git ইনস্টল না থাকে, [Git ডাউনলোড করুন](https://git-scm.com/downloads)। এরপর, আপনার লোকাল Git প্রোফাইল সেটআপ করুন টার্মিনালে:
যদি Git ইনস্টল না থাকে, [Git ডাউনলোড করুন](https://git-scm.com/downloads)। তারপর, আপনার লোকাল Git প্রোফাইল সেটআপ করুন টার্মিনালে:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
@ -39,9 +39,9 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
আপনার একটি GitHub অ্যাকাউন্ট, একটি কোড এডিটর (যেমন Visual Studio Code), এবং টার্মিনাল (বা: কমান্ড প্রম্পট) খুলতে হবে।
[github.com](https://github.com/) এ যান এবং যদি আপনার অ্যাকাউন্ট না থাকে তবে একটি তৈরি করুন, অথবা লগইন করে আপনার প্রোফাইল পূরণ করুন।
[github.com](https://github.com/) এ যান এবং যদি এখনও অ্যাকাউন্ট না থাকে তবে একটি অ্যাকাউন্ট তৈরি করুন, অথবা লগ ইন করুন এবং আপনার প্রোফাইল পূরণ করুন।
✅ GitHub একমাত্র কোড রিপোজিটরি নয়; আরও অনেক আছে, তবে GitHub সবচেয়ে পরিচিত।
✅ GitHub বিশ্বের একমাত্র কোড রিপোজিটরি নয়; আরও অনেক আছে, তবে GitHub সবচেয়ে পরিচিত।
### প্রস্তুতি
@ -51,17 +51,18 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
## কোড ব্যবস্থাপনা
ধরুন আপনার লোকাল মেশিনে একটি কোড প্রকল্পের ফোল্ডার আছে এবং আপনি Git ব্যবহার করে আপনার অগ্রগতি ট্র্যাক করতে চান - এটি একটি ভার্সন কন্ট্রোল সিস্টেম। কিছু লোক Git ব্যবহারকে ভবিষ্যতের নিজের জন্য একটি প্রেমপত্র লেখার সাথে তুলনা করে। আপনার কমিট মেসেজগুলো কয়েক দিন, সপ্তাহ বা মাস পরে পড়লে আপনি বুঝতে পারবেন কেন আপনি একটি সিদ্ধান্ত নিয়েছিলেন, অথবা একটি পরিবর্তন "রোলব্যাক" করতে পারবেন - যদি আপনি ভালো "কমিট মেসেজ" লিখেন।
ধরুন আপনার লোকাল মেশিনে একটি কোড প্রকল্পের ফোল্ডার আছে এবং আপনি Git ব্যবহার করে আপনার অগ্রগতি ট্র্যাক করতে চান - এটি একটি ভার্সন কন্ট্রোল সিস্টেম। কিছু লোক Git ব্যবহারকে ভবিষ্যতের নিজের জন্য একটি প্রেমপত্র লেখার সাথে তুলনা করে। আপনার কমিট মেসেজগুলি পড়লে আপনি কেন একটি সিদ্ধান্ত নিয়েছিলেন তা মনে করতে পারবেন, অথবা একটি পরিবর্তন "রোলব্যাক" করতে পারবেন - যদি আপনি ভালো "কমিট মেসেজ" লিখেন।
### কাজ: একটি রিপোজিটরি তৈরি করুন এবং কোড কমিট করুন
> ভিডিও দেখুন
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub-এ রিপোজিটরি তৈরি করুন**। GitHub.com-এ, রিপোজিটরি ট্যাবে বা নেভিগেশন বার টপ-রাইট থেকে **নতুন রিপো** বোতামটি খুঁজুন।
1. আপনার রিপোজিটরিকে (ফোল্ডার) একটি নাম দিন।
1. **GitHub-এ রিপোজিটরি তৈরি করুন**। GitHub.com-এ, রিপোজিটরি ট্যাবে, অথবা নেভিগেশন বার টপ-রাইট থেকে, **নতুন রিপো** বোতামটি খুঁজুন।
1. আপনার রিপোজিটরিকে একটি নাম দিন
1. **রিপোজিটরি তৈরি করুন** নির্বাচন করুন।
1. **আপনার কাজের ফোল্ডারে যান**। আপনার টার্মিনালে, সেই ফোল্ডারে (ডিরেক্টরি) যান যা আপনি ট্র্যাক করতে চান। টাইপ করুন:
@ -82,7 +83,7 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git status
```
আউটপুট দেখতে এমন হতে পারে:
আউটপুট দেখতে এমন কিছু হতে পারে:
```output
Changes not staged for commit:
@ -93,7 +94,7 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
modified: file2.txt
```
সাধারণত `git status` কমান্ড আপনাকে জানায় কোন ফাইলগুলো_সেভ_ করার জন্য প্রস্তুত বা কোন ফাইলগুলোতে পরিবর্তন আছে যা আপনি সংরক্ষণ করতে চান।
সাধারণত `git status` কমান্ড আপনাকে জানায় কোন ফাইলগুলি_সেভ_ করার জন্য প্রস্তুত বা কোন ফাইলগুলিতে পরিবর্তন আছে যা আপনি সংরক্ষণ করতে চান।
1. **সব ফাইল ট্র্যাকিংয়ে যোগ করুন**
এটিকে স্টেজিং ফাইল/স্টেজিং এরিয়াতে ফাইল যোগ করাও বলা হয়।
@ -110,7 +111,7 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git add [file or folder name]
```
এটি আমাদের নির্দিষ্ট ফাইলগুলোকে স্টেজিং এরিয়াতে যোগ করতে সাহায্য করে যখন আমরা সব ফাইল একসাথে কমিট করতে চাই না।
এটি আমাদের নির্দিষ্ট ফাইলগুলি স্টেজিং এরিয়াতে যোগ করতে সাহায্য করে যখন আমরা সব ফাইল একবারে কমিট করতে চাই না।
1. **সব ফাইল আনস্টেজ করুন**
@ -118,7 +119,7 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git reset
```
এই কমান্ড আমাদের একসাথে সব ফাইল আনস্টেজ করতে সাহায্য করে।
এই কমান্ড আমাদের একবারে সব ফাইল আনস্টেজ করতে সাহায্য করে।
1. **নির্দিষ্ট ফাইল আনস্টেজ করুন**
@ -126,27 +127,27 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git reset [file or folder name]
```
এই কমান্ড আমাদের নির্দিষ্ট ফাইলটি একসাথে আনস্টেজ করতে সাহায্য করে যা আমরা পরবর্তী কমিটে অন্তর্ভুক্ত করতে চাই না।
এই কমান্ড আমাদের একবারে নির্দিষ্ট একটি ফাইল আনস্টেজ করতে সাহায্য করে যা আমরা পরবর্তী কমিটে অন্তর্ভুক্ত করতে চাই না।
1. **আপনার কাজ সংরক্ষণ করুন**। এই পর্যায়ে আপনি ফাইলগুলোকে তথাকথিত _স্টেজিং এরিয়া_ তে যোগ করেছেন। এটি এমন একটি জায়গা যেখানে Git আপনার ফাইলগুলো ট্র্যাক করছে। পরিবর্তন স্থায়ী করতে আপনাকে ফাইলগুলো_কমিট_ করতে হবে। এটি করতে `git commit` কমান্ড ব্যবহার করে একটি _কমিট_ তৈরি করুন। একটি _কমিট_ আপনার রিপোর ইতিহাসে একটি সেভিং পয়েন্টকে উপস্থাপন করে। টাইপ করুন:
1. **আপনার কাজ সংরক্ষণ করুন**। এই পর্যায়ে আপনি ফাইলগুলি একটি তথাকথিত _স্টেজিং এরিয়াতে_ যোগ করেছেন। এটি এমন একটি জায়গা যেখানে Git আপনার ফাইলগুলি ট্র্যাক করছে। পরিবর্তন স্থায়ী করতে আপনাকে ফাইলগুলি_কমিট_ করতে হবে। এটি করতে `git commit` কমান্ড ব্যবহার করে একটি _কমিট_ তৈরি করুন। একটি _কমিট_ আপনার রিপোজিটরির ইতিহাসে একটি সেভিং পয়েন্টকে প্রতিনিধিত্ব করে। টাইপ করুন:
```bash
git commit -m "first commit"
```
এটি আপনার সব ফাইল কমিট করে এবং "first commit" মেসেজ যোগ করে। ভবিষ্যতের কমিট মেসেজগুলোর জন্য আপনি আরও বর্ণনামূলক হতে চাইবেন যাতে আপনি কী ধরনের পরিবর্তন করেছেন তা বোঝানো যায়।
এটি আপনার সব ফাইল কমিট করে, "প্রথম কমিট" বার্তা যোগ করে। ভবিষ্যতের কমিট বার্তাগুলির জন্য আপনি আরও বর্ণনামূলক বার্তা ব্যবহার করতে চাইবেন যাতে আপনি কী ধরনের পরিবর্তন করেছেন তা বোঝানো যায়।
1. **আপনার লোকাল Git রিপোকে GitHub-এর সাথে সংযুক্ত করুন**। একটি Git রিপো আপনার মেশিনে ভালো, তবে এক পর্যায়ে আপনি আপনার ফাইলগুলোর ব্যাকআপ কোথাও রাখতে চাইবেন এবং অন্যদের আপনার রিপোতে কাজ করার জন্য আমন্ত্রণ জানাতে চাইবেন। GitHub এমন একটি জায়গা যেখানে এটি করা যায়। মনে রাখুন আমরা ইতিমধ্যে GitHub-এ একটি রিপো তৈরি করেছি, তাই আমাদের যা করতে হবে তা হলো আমাদের লোকাল Git রিপোকে GitHub-এর সাথে সংযুক্ত করা। `git remote add` কমান্ড এটি করবে। টাইপ করুন:
1. **আপনার লোকাল Git রিপোকে GitHub-এর সাথে সংযুক্ত করুন**। একটি Git রিপো আপনার মেশিনে ভালো, তবে এক পর্যায়ে আপনি আপনার ফাইলগুলির ব্যাকআপ কোথাও রাখতে চাইবেন এবং অন্যদের আপনার রিপোতে কাজ করার জন্য আমন্ত্রণ জানাতে চাইবেন। GitHub এমন একটি চমৎকার জায়গা। মনে রাখুন আমরা ইতিমধ্যে GitHub-এ একটি রিপো তৈরি করেছি, তাই আমাদের যা করতে হবে তা হল আমাদের লোকাল Git রিপোকে GitHub-এর সাথে সংযুক্ত করা। `git remote add` কমান্ড এটি করবে। টাইপ করুন:
> নোট, কমান্ড টাইপ করার আগে আপনার GitHub রিপো পেজে যান এবং রিপোজিটরি URL খুঁজুন। আপনি এটি নিচের কমান্ডে ব্যবহার করবেন। ```https://github.com/username/repository_name.git``` কে আপনার GitHub URL দিয়ে প্রতিস্থাপন করুন।
> নোট, কমান্ড টাইপ করার আগে আপনার GitHub রিপো পেজে যান এবং রিপোজিটরি URL খুঁজুন। আপনি এটি নিচের কমান্ডে ব্যবহার করবেন। ```https://github.com/username/repository_name.git``` আপনার GitHub URL দিয়ে প্রতিস্থাপন করুন।
এটি একটি _রিমোট_, বা সংযোগ তৈরি করে, যার নাম "origin" এবং এটি আপনার আগে তৈরি করা GitHub রিপোজিটরির দিকে নির্দেশ করে।
এটি একটি _রিমোট_, বা সংযোগ তৈরি করে, যার নাম "origin" যা আপনি আগে তৈরি করা GitHub রিপোজিটরির দিকে নির্দেশ করে।
1. **লোকাল ফাইলগুলো GitHub-এ পাঠান**। এখন পর্যন্ত আপনি লোকাল রিপো এবং GitHub রিপোর মধ্যে একটি _সংযোগ_ তৈরি করেছেন। এই ফাইলগুলো GitHub-এ পাঠাতে `git push` কমান্ড ব্যবহার করুন:
1. **লোকাল ফাইলগুলি GitHub-এ পাঠান**। এখন পর্যন্ত আপনি লোকাল রিপো এবং GitHub রিপোর মধ্যে একটি _সংযোগ_ তৈরি করেছেন। এই ফাইলগুলি GitHub-এ পাঠাতে `git push` কমান্ড ব্যবহার করুন, যেমন:
> নোট, আপনার ব্রাঞ্চের নাম ```main``` থেকে আলাদা হতে পারে।
@ -154,9 +155,9 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git push -u origin main
```
এটি আপনার "main" ব্রাঞ্চের কমিটগুলো GitHub-এ পাঠায়।
এটি আপনার "main" ব্রাঞ্চের কমিটগুলি GitHub-এ পাঠায়। `upstream` ব্রাঞ্চ সেট করা এবং কমান্ডে `-u` অন্তর্ভুক্ত করা আপনার লোকাল ব্রাঞ্চ এবং রিমোট ব্রাঞ্চের মধ্যে একটি লিঙ্ক স্থাপন করে, যাতে আপনি ভবিষ্যতে ব্রাঞ্চের নাম উল্লেখ না করেই সহজে git push বা git pull ব্যবহার করতে পারেন। Git স্বয়ংক্রিয়ভাবে upstream ব্রাঞ্চ ব্যবহার করবে এবং ভবিষ্যতের কমান্ডে আপনাকে ব্রাঞ্চের নাম স্পষ্টভাবে উল্লেখ করতে হবে না।
2. **আরও পরিবর্তন যোগ করুন**। যদি আপনি আরও পরিবর্তন করতে চান এবং সেগুলো GitHub-এ পাঠাতে চান, তাহলে আপনাকে শুধুমাত্র এই তিনটি কমান্ড ব্যবহার করতে হবে:
2. **আরও পরিবর্তন যোগ করতে**। যদি আপনি পরিবর্তন করতে এবং সেগুলি GitHub-এ পাঠাতে চান, তাহলে আপনাকে শুধুমাত্র তিনটি কমান্ড ব্যবহার করতে হবে:
```bash
git add .
@ -164,176 +165,180 @@ Git ইতিমধ্যে কনফিগার করা আছে কিন
git push
```
> টিপ, আপনি `.gitignore` ফাইল গ্রহণ করতে চাইতে পারেন যাতে আপনি GitHub-এ ট্র্যাক করতে না চাওয়া ফাইলগুলো দেখানো থেকে আটকাতে পারেন - যেমন সেই নোট ফাইলটি যা আপনি একই ফোল্ডারে সংরক্ষণ করেন কিন্তু একটি পাবলিক রিপোজিটরিতে থাকার কোনো জায়গা নেই। আপনি [.gitignore টেমপ্লেট](https://github.com/github/gitignore) এ `.gitignore` ফাইলের টেমপ্লেট খুঁজে পেতে পারেন।
> টিপ, আপনি `.gitignore` ফাইল গ্রহণ করতে চাইতে পারেন যাতে আপনি GitHub-এ ট্র্যাক করতে না চাওয়া ফাইলগুলি দেখানো থেকে আটকাতে পারেন - যেমন সেই নোটস ফাইল যা আপনি একই ফোল্ডারে সংরক্ষণ করেন কিন্তু পাবলিক রিপোজিটরিতে এর কোনো স্থান নেই। `.gitignore` ফাইলের টেমপ্লেটগুলি [.gitignore templates](https://github.com/github/gitignore) এ পাওয়া যাবে।
#### কমিট মেসেজ
#### কমিট বার্তা
একটি চমৎকার Git কমিট সাবজেক্ট লাইন নিম্নলিখিত বাক্যটি সম্পূর্ণ করে:
যদি প্রয়োগ করা হয়, এই কমিটটি <আপনার সাবজেক্ট লাইন এখানে>
সাবজেক্টে ব্যবহার করুন ইম্পেরেটিভ, বর্তমান কাল: "change" নয় "changed" বা "changes"।
যেমন সাবজেক্টে, বডিতেও (ঐচ্ছিক) ইম্পেরেটিভ, বর্তমান কাল ব্যবহার করুন। বডিতে পরিবর্তনের প্রেরণা এবং পূর্ববর্তী আচরণের সাথে এর পার্থক্য অন্তর্ভুক্ত করুন। আপনি `কেন`, `কীভাবে` নয়, ব্যাখ্যা করছেন।
সাবজেক্টের জন্য আদেশমূলক, বর্তমান কাল ব্যবহার করুন: "change" নয় "changed" বা "changes"।
সাবজেক্টের মতো, বডিতেও (ঐচ্ছিক) আদেশমূলক, বর্তমান কাল ব্যবহার করুন। বডিতে পরিবর্তনের প্রেরণা এবং পূর্ববর্তী আচরণের সাথে এর পার্থক্য অন্তর্ভুক্ত করা উচিত। আপনি `কেন` ব্যাখ্যা করছেন, `কীভাবে` নয়।
✅ GitHub-এ কিছুক্ষণ ঘুরে দেখুন। আপনি কি একটি সত্যিই চমৎকার কমিট মেসেজ খুঁজে পেতে পারেন? আপনি কি একটি খুব সংক্ষিপ্ত মেসেজ খুঁজে পেতে পারেন? আপনার মতে কমিট মেসেজে কোন তথ্য সবচেয়ে গুরুত্বপূর্ণ এবং উপকারী?
✅ GitHub-এ কিছুক্ষণ ঘুরে দেখুন। আপনি কি একটি সত্যিই চমৎকার কমিট বার্তা খুঁজে পেতে পারেন? আপনি কি একটি খুব সংক্ষিপ্ত বার্তা খুঁজে পেতে পারেন? আপনার মতে কমিট বার্তায় কোন তথ্য সবচেয়ে গুরুত্বপূর্ণ এবং উপযোগী?
### কাজ: সহযোগিতা করুন
GitHub-এ জিনিসগুলো রাখার প্রধান কারণ ছিল অন্য ডেভেলপারদের সাথে সহযোগিতা করা সম্ভব করা।
GitHub-এ জিনিসগুলি রাখার প্রধান কারণ হল অন্য ডেভেলপারদের সাথে সহযোগিতা করা সম্ভব করা।
## অন্যদের সাথে প্রকল্পে কাজ করা
> ভিডিও দেখুন
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
আপনার রিপোজিটরিতে, `Insights > Community`-এ যান এবং দেখুন আপনার প্রকল্পটি প্রস্তাবিত কমিউনিটি স্ট্যান্ডার্ডগুলোর সাথে কেমন তুলনা করে।
আপনার রিপোজিটরিতে, `Insights > Community`-এ যান এবং দেখুন আপনার প্রকল্পটি প্রস্তাবিত কমিউনিটি স্ট্যান্ডার্ডগুলির সাথে কেমন তুলনা করে।
এখানে কিছু বিষয় রয়েছে যা আপনার GitHub রিপো উন্নত করতে পারে:
আপনার GitHub রিপো উন্নত করতে পারে এমন কিছু বিষয় এখানে দেওয়া হলো:
- **বর্ণনা**। আপনি কি আপনার প্রকল্পের জন্য একটি বর্ণনা যোগ করেছেন?
- **README**। আপনি কি একটি README যোগ করেছেন? GitHub একটি [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-code-of-conduct-to-your-project/) আছে?
- **লাইসেন্স**। সম্ভবত সবচেয়ে গুরুত্বপূর্ণ, একটি [লাইসেন্স](https://docs.github.com/articles/adding-a-license-to-a-repository/) আছে?
এই সমস্ত রিসোর্স নতুন টিম সদস্যদের অনবোর্ডিংয়ে উপকার করবে। এবং এগুলো সাধারণত নতুন অবদানকারীরা আপনার কোড দেখার আগে দেখে, যাতে তারা বুঝতে পারে আপনার প্রকল্প তাদের সময় ব্যয় করার জন্য সঠিক জায়গা কিনা।
এই সমস্ত রিসোর্স নতুন টিম সদস্যদের অনবোর্ডিংয়ে উপকার করবে। এবং এগুলি সাধারণত নতুন অবদানকারীরা আপনার কোড দেখার আগে দেখে, এটি খুঁজে বের করতে যে আপনার প্রকল্পটি তাদের সময় ব্যয় করার জন্য সঠিক জায়গা কিনা।
✅ README ফাইলগুলো, যদিও প্রস্তুত করতে সময় লাগে, ব্যস্ত মেইনটেইনাররা প্রায়ই এগুলো উপেক্ষা করেন। আপনি কি একটি বিশেষভাবে বর্ণনামূলক README-এর উদাহরণ খুঁজে পেতে পারেন? নোট: কিছু [টুল](https://www.makeareadme.com/) রয়েছে যা ভালো README তৈরি করতে সাহায্য করে, যা আপনি চেষ্টা করতে পারেন।
✅ README ফাইলগুলি, যদিও প্রস্তুত করতে সময় লাগে, ব্যস্ত মেইনটেইনাররা প্রায়ই অবহেলা করেন। আপনি কি একটি বিশেষভাবে বর্ণনামূলক উদাহরণ খুঁজে পেতে পারেন? নোট: কিছু [ভালো README তৈরি করার টুল](https://www.makeareadme.com/) আছে যা আপনি চেষ্টা করতে পারেন।
### কাজ: কিছু কোড মার্জ করুন
অবদান রাখার ডকুমেন্টগুলো মানুষকে প্রকল্পে অবদান রাখতে সাহায্য করে। এটি ব্যাখ্যা করে আপনি কী ধরনের অবদান খুঁজছেন এবং প্রক্রিয়াটি কীভাবে কাজ করে। অবদানকারীদের আপনার GitHub রিপোতে অবদান রাখতে একটি সিরিজ ধাপ অনুসরণ করতে হবে:
অবদান রাখার ডকুমেন্টগুলি মানুষকে প্রকল্পে অবদান রাখতে সাহায্য করে। এটি ব্যাখ্যা করে আপনি কী ধরনের অবদান খুঁজছেন এবং প্রক্রিয়াটি কীভাবে কাজ করে। অবদানকারীদের GitHub-এ আপনার রিপোতে অবদান রাখতে একটি সিরিজ ধাপ অনুসরণ করতে হবে:
1. **আপনার রিপো ফর্ক করা**। আপনি সম্ভবত চাইবেন মানুষ আপনার প্রকল্পটি _ফর্ক_ করুক। ফর্ক করা মানে তাদের GitHub প্রোফাইলে আপনার রিপোজিটরির একটি প্রতিলিপি তৈরি করা।
1. **ক্লোন**। এরপর তারা প্রকল্পটি তাদের লোকাল মেশিনে ক্লোন করবে।
1. **একটি ব্রাঞ্চ তৈরি করুন**। আপনি চাইবেন তারা তাদের কাজের জন্য একটি _ব্রাঞ্চ_ তৈরি করুক।
1. **তাদের পরিবর্তন একটি এলাকায় কেন্দ্রীভূত করুন**। অবদানকারীদের একবারে একটি জিনিসে তাদের অবদান কেন্দ্রীভূত করতে বলুন - এভাবে তাদের কাজ _মার্জ_ করার সম্ভাবনা বেশি। ধরুন তারা একটি বাগ ঠিক করে, একটি নতুন ফিচার যোগ করে, এবং কয়েকটি টেস্ট আপডেট করে - যদি আপনি ৩টির মধ্যে ২টি বা ১টি পরিবর্তন বাস্তবায়ন করতে চান বা পারেন?
1. **আপনার রিপো ফর্ক করা**। আপনি সম্ভবত মানুষকে আপনার প্রকল্প _ফর্ক_ করতে চাইবেন। ফর্ক করা মানে তাদের GitHub প্রোফাইলে আপনার রিপোজিটরির একটি প্রতিলিপি তৈরি করা।
1. **ক্লোন**। সেখান থেকে তারা প্রকল্পটি তাদের লোকাল মেশিনে ক্লোন করবে।
1. **একটি ব্রাঞ্চ তৈরি করুন**। আপনি তাদের কাজের জন্য একটি _ব্রাঞ্চ_ তৈরি করতে বলতে চাইবেন।
1. **পরিবর্তন একটি এলাকায় কেন্দ্রীভূত করুন**। অবদানকারীদের একবারে একটি জিনিসে তাদের অবদান কেন্দ্রীভূত করতে বলুন - এভাবে তাদের কাজ _মার্জ_ করার সম্ভাবনা বেশি। কল্পনা করুন তারা একটি বাগ ফিক্স লিখেছে, একটি নতুন ফিচার যোগ করেছে, এবং কয়েকটি টেস্ট আপডেট করেছে - যদি আপনি ৩টির মধ্যে ২টি বা ১টি পরিবর্তন বাস্তবায়ন করতে চান বা পারেন?
✅ এমন একটি পরিস্থিতি কল্পনা করুন যেখানে ব্রাঞ্চগুলো ভালো কোড লিখতে এবং শিপ করতে বিশেষভাবে গুরুত্বপূর্ণ। আপনি কী ধরনের ব্যবহার কেস কল্পনা করতে পারেন?
✅ এমন একটি পরিস্থিতি কল্পনা করুন যেখানে ব্রাঞ্চগুলি ভালো কোড লেখার এবং শিপ করার জন্য বিশেষভাবে গুরুত্বপূর্ণ। আপনি কী ব্যবহারিক ক্ষেত্রগুলি ভাবতে পারেন?
> নোট, আপনি নিজেও আপনার কাজের জন্য ব্রাঞ্চ তৈরি করুন। আপনি যে কোনো কমিট করবেন তা আপনি বর্তমানে যে ব্রাঞ্চে "চেক আউট" করেছেন তাতে করা হবে। `git status` ব্যবহার করে দেখুন আপনি কোন ব্রাঞ্চে আছেন।
> নোট, আপনি যা পরিবর্তন দেখতে চান তা নিজেও করুন এবং আপনার নিজের কাজের জন্য ব্রাঞ্চ তৈরি করুন। আপনি যে কোনো কমিট করবেন তা আপনি বর্তমানে "চেক আউট" করা ব্রাঞ্চে করা হবে। `git status` ব্যবহার করে দেখুন কোন ব্রাঞ্চে আছেন।
চলুন একটি অবদানকারীর ওয়ার্কফ্লো নিয়ে আলোচনা করি। ধরে নিন অবদানকারী ইতিমধ্যে রিপোটি_ফর্ক_ এবং _ক্লোন_ করেছেন, তাই তাদের লোকাল মেশিনে কাজ করার জন্য একটি Git রিপো প্রস্তুত আছে:
চলুন একটি অবদানকারীর ওয়ার্কফ্লো দেখে নিই। ধরে নিন অবদানকারী ইতিমধ্যে রিপো _ফর্ক_ এবং _ক্লোন_ করেছেন, তাই তাদের লোকাল মেশিনে কাজ করার জন্য একটি Git রিপো প্রস্তুত আছে:
1. **একটি ব্রাঞ্চ তৈরি করুন**। `git branch` কমান্ড ব্যবহার করে একটি ব্রাঞ্চ তৈরি করুন যা তারা অবদান রাখতে চায় এমন পরিবর্তনগুলো ধারণ করবে:
1. **একটি ব্রাঞ্চ তৈরি করুন**। `git branch` কমান্ড ব্যবহার করে একটি ব্রাঞ্চ তৈরি করুন যা তারা অবদান রাখতে চায় এমন পরিবর্তনগুলি ধারণ করবে:
```bash
git branch [branch-name]
```
1. **কাজের ব্রাঞ্চে সুইচ করুন**। নির্দিষ্ট ব্রাঞ্চে সুইচ করুন এবং `git switch` ব্যবহার করে কাজের ডিরেক্টরি আপডেট করুন:
1. **কাজের ব্রাঞ্চে যান**। নির্দিষ্ট ব্রাঞ্চে যান এবং `git switch` ব্যবহার করে কাজের ডিরেক্টরি আপডেট করুন:
```bash
git switch [branch-name]
```
1. **কাজ করুন**। এই পর্যায়ে আপনি আপনার পরিবর্তন যোগ করতে চান। Git-কে এটি সম্পর্কে জানাতে ভুলবেন না নিম্নলিখিত কমান্ডগুলো ব্যবহার করে:
1. **কাজ করুন**। এই পর্যায়ে আপনি আপনার পরিবর্তন যোগ করতে চান। নিচের কমান্ডগুলি ব্যবহার করে Git-কে এটি সম্পর্কে জানাতে ভুলবেন না:
```bash
git add .
git commit -m "my changes"
```
নিশ্চিত করুন আপনি আপনার কমিটকে একটি ভালো নাম দিয়েছেন, আপনার জন্য এবং সেই রিপোর মেইনটেইনারের জন্যও।
নিশ্চিত করুন যে আপনি আপনার কমিটকে একটি ভালো নাম দিয়েছেন, আপনার জন্য এবং আপনি যে রিপোতে সাহায্য করছেন তার মেইনটেইনারের জন্য।
1. **আপনার কাজ `main` ব্রাঞ্চের সাথে একত্রিত করুন**। এক পর্যায়ে আপনি কাজ শেষ করেছেন এবং আপনি আপনার কাজ `main` ব্রাঞ্চের সাথে একত্রিত করতে চান। `main` ব্রাঞ্চ ইতিমধ্যে পরিবর্তিত হতে পারে, তাই নিশ্চিত করুন আপনি প্রথমে এটি সর্বশেষে আপডেট করেছেন নিম্নলিখিত কমান্ডগুলো ব্যবহার করে:
1. **আপনার কাজকে`main` ব্রাঞ্চের সাথে একত্রিত করুন**। এক পর্যায়ে আপনি কাজ শেষ করেছেন এবং আপনি আপনার কাজকে`main` ব্রাঞ্চের সাথে একত্রিত করতে চান। এদিকে `main` ব্রাঞ্চ পরিবর্তিত হতে পারে, তাই নিশ্চিত করুন যে আপনি প্রথমে এটি সর্বশেষে আপডেট করেছেন নিম্নলিখিত কমান্ডগুলি ব্যবহার করে:
```bash
git switch main
git pull
```
এই পর্যায়ে আপনি নিশ্চিত করতে চান যে কোনো _কনফ্লিক্ট_, এমন পরিস্থিতি যেখানে Git সহজে পরিবর্তনগুলো_একত্রিত_ করতে পারে না, আপনার কাজের ব্রাঞ্চে ঘটে। তাই নিম্নলিখিত কমান্ডগুলো চালান:
এই পর্যায়ে আপনি নিশ্চিত করতে চান যে কোনো _কনফ্লিক্ট_, এমন পরিস্থিতি যেখানে Git সহজে পরিবর্তনগুলি_একত্রিত_ করতে পারে না, আপনার কাজের ব্রাঞ্চে ঘটে। তাই নিম্নলিখিত কমান্ডগুলি চালান:
```bash
git switch [branch_name]
git merge main
```
এটি `main` থেকে সব পরিবর্তন আপনার ব্রাঞ্চে নিয়ে আসবে এবং আশা করি আপনি সহজেই চালিয়ে যেতে পারবেন। যদি না পারেন, VS Code আপনাকে জানাবে কোথায় Git _বিভ্রান্ত_ এবং আপনি প্রভাবিত ফাইলগুলো পরিবর্তন করে সঠিক বিষয়বস্তু নির্ধারণ করবেন।
`git merge main` কমান্ডটি `main` থেকে আপনার ব্রাঞ্চে সব পরিবর্তন নিয়ে আসবে। আশা করি আপনি সহজেই চালিয়ে যেতে পারবেন। যদি না পারেন, VS Code আপনাকে জানাবে কোথায় Git _বিভ্রান্ত_ এবং আপনি প্রভাবিত ফাইলগুলি পরিবর্তন করবেন যাতে সঠিক বিষয়বস্তু থাকে।
1. **আপনার কাজ GitHub-এ পাঠান**। আপনার কাজ GitHub-এ পাঠানো মানে দুটি জিনিস। আপনার ব্রাঞ্চকে আপনার রিপোতে পুশ করা এবং একটি PR, Pull Request খুলুন।
একটি ভিন্ন ব্রাঞ্চে যেতে, আধুনিক `git switch` কমান্ড ব্যবহার করুন:
```bash
git switch [branch_name]
1. **আপনার কাজ GitHub-এ পাঠান**। আপনার কাজ GitHub-এ পাঠানো মানে দুটি জিনিস। আপনার ব্রাঞ্চকে আপনার রিপোতে পুশ করা এবং তারপর একটি PR, Pull Request খুলুন।
```bash
git push --set-upstream origin [branch-name]
```
উপরের কমান্ডটি আপনার ফর্ক করা রিপোতে ব্রাঞ্চ তৈরি করে।
1. **PR খুলুন**। এরপর, আপনাকে একটি PR (Pull Request) খুলতে হবে। এটি করতে GitHub-এ আপনার fork করা রিপোজিটরিতে যান। GitHub-এ একটি নির্দেশনা থাকবে যেখানে জিজ্ঞাসা করা হবে আপনি নতুন PR তৈরি করতে চান কিনা। সেখানে ক্লিক করুন এবং আপনি এমন একটি ইন্টারফেসে পৌঁছাবেন যেখানে আপনি কমিট মেসেজের শিরোনাম পরিবর্তন করতে পারবেন এবং আরও উপযুক্ত বিবরণ যোগ করতে পারবেন। এখন আপনি যে রিপোজিটরি fork করেছেন তার maintainer এই PR দেখবেন এবং _আশা করি_ তারা এটি পছন্দ করবেন এবং _merge_ করবেন। আপনি এখন একজন contributor, বাহ! :)
1. **একটি PR খুলুন**। এরপর, আপনি একটি PR খুলতে চান। আপনি এটি করতে পারেন ফর্ক করা রিপোতে GitHub-এ গিয়ে। আপনি GitHub-এ একটি ইঙ্গিত দেখতে পাবেন যেখানে এটি জিজ্ঞাসা করে আপনি একটি নতুন PR তৈরি করতে চান কিনা, আপনি এটি ক্লিক করবেন এবং আপনাকে একটি ইন্টারফেসে নিয়ে যাওয়া হবে যেখানে আপনি কমিট মেসেজের শিরোনাম পরিবর্তন করতে পারেন, এটি আরও উপযুক্ত বর্ণনা দিতে পারেন। এখন আপনি যে রিপোটি ফর্ক করেছেন তার মেইনটেইনার এই PR দেখবেন এবং _আশা করি_ তারা এটি প্রশংসা করবেন এবং আপনার PR _মার্জ_ করবেন। আপনি এখন একজন অবদানকারী, বাহ :)
1. **পরিষ্কার করুন**। একটি PR সফলভাবে মার্জ করার পর _পরিষ্কার করা_ ভালো অভ্যাস হিসেবে বিবেচিত হয়। আপনি আপনার লোকাল ব্রাঞ্চ এবং আপনি GitHub-এ পুশ করা ব্রাঞ্চ উভয়ই পরিষ্কার করতে চান। প্রথমে এটি লোকাল থেকে মুছুন নিম্নলিখিত কমান্ড ব্যবহার করে:
1. **পরিষ্কার করুন**। একটি PR সফলভাবে merge করার পর আপনার কাজ পরিষ্কার করা ভালো অভ্যাস হিসেবে বিবেচিত হয়। আপনাকে আপনার লোকাল ব্রাঞ্চ এবং GitHub-এ যে ব্রাঞ্চটি push করেছেন সেটি পরিষ্কার করতে হবে। প্রথমে নিচের কমান্ডটি ব্যবহার করে লোকাল ব্রাঞ্চটি মুছে ফেলুন:
```bash
git branch -d [branch-name]
```
এরপর GitHub-এ fork করা রিপোজিটরির পেজে যান এবং আপনি যে রিমোট ব্রাঞ্চটি push করেছেন সেটি সরিয়ে ফেলুন।
নিশ্চিত করুন আপনি ফর্ক করা রিপোর GitHub পেজে যান এবং আপনি যে রিমোট ব্রাঞ্চটি পুশ করেছেন সেটি সরিয়ে ফেলুন।
`Pull request` শব্দটি একটু অদ্ভুত শোনায়, কারণ প্রকৃতপক্ষে আপনি আপনার পরিবর্তনগুলো প্রকল্পে `push` করতে চান। কিন্তু প্রকল্পের মালিক বা মূল দলকে আপনার পরিবর্তনগুলো বিবেচনা করতে হয়, যাতে এটি প্রকল্পের "main" শাখার সাথে একীভূত করা যায়। তাই আপনি মূলত প্রকল্পের মালিকের কাছে একটি পরিবর্তনের সিদ্ধান্তের অনুরোধ করছেন।
`Pull request` শব্দটি একটু অদ্ভুত শোনাতে পারে কারণ আপনি প্রকল্পে আপনার পরিবর্তনগুলি push করতে চান। কিন্তু maintainer (প্রকল্পের মালিক) বা core টিমকে আপনার পরিবর্তনগুলি merge করার আগে বিবেচনা করতে হয়, তাই আপনি মূলত maintainer-এর কাছে একটি পরিবর্তনের সিদ্ধান্তের অনুরোধ করছেন।
একটি pull request হলো এমন একটি জায়গা যেখানে শাখায় আনা পরিবর্তনগুলো তুলনা এবং আলোচনা করা হয়, রিভিউ, মন্তব্য, ইন্টিগ্রেটেড টেস্ট এবং আরও অনেক কিছু সহ। একটি ভালো pull request প্রায় একই নিয়ম অনুসরণ করে যা একটি commit message করে। আপনি issue tracker-এ একটি issue-এর রেফারেন্স যোগ করতে পারেন, উদাহরণস্বরূপ যখন আপনার কাজ কোনো issue সমাধান করে। এটি `#` এবং issue নম্বর ব্যবহার করে করা হয়। যেমন`#97`।
Pull request হলো এমন একটি জায়গা যেখানে একটি ব্রাঞ্চে আনা পরিবর্তনগুলি তুলনা এবং আলোচনা করা হয়, রিভিউ, মন্তব্য, ইন্টিগ্রেটেড টেস্ট এবং আরও অনেক কিছু সহ। একটি ভালো pull request সাধারণত কমিট মেসেজের মতো একই নিয়ম অনুসরণ করে। আপনি issue tracker-এ একটি issue-এর রেফারেন্স যোগ করতে পারেন, যেমন আপনার কাজ যদি কোনো issue সমাধান করে। এটি `#` এবং issue নম্বর ব্যবহার করে করা হয়। উদাহরণস্বরূপ,`#97`।
🤞আশা করি সব চেক পাস করবে এবং প্রকল্পের মালিক আপনার পরিবর্তনগুলো প্রকল্পে merge করবেন🤞
🤞আশা করি সব চেক পাস করবে এবং প্রকল্পের মালিক আপনার পরিবর্তনগুলি প্রকল্পে merge করবেন🤞
আপনার বর্তমান লোকাল কাজের শাখাকে GitHub-এর সংশ্লিষ্ট রিমোট শাখার নতুন commit দিয়ে আপডেট করুন:
আপনার লোকাল কাজের ব্রাঞ্চটি GitHub-এর সংশ্লিষ্ট রিমোট ব্রাঞ্চ থেকে সমস্ত নতুন কমিট দিয়ে আপডেট করুন:
`git pull`
## ওপেন সোর্সে কীভাবে অবদান রাখবেন
প্রথমে, GitHub-এ আপনার আগ্রহের একটি রিপোজিটরি (বা **repo**) খুঁজুন, যেখানে আপনি পরিবর্তন করতে চান। আপনি এর কন্টেন্ট আপনার মেশিনে কপি করতে চাইবেন।
প্রথমে, GitHub-এ একটি রিপোজিটরি (বা **repo**) খুঁজুন যা আপনার আগ্রহের এবং যেখানে আপনি একটি পরিবর্তন যোগ করতে চান। আপনি এর কন্টেন্ট আপনার মেশিনে কপি করতে চাইবেন।
কোড কপি করার বিভিন্ন উপায় আছে। একটি উপায় হলো রিপোজিটরির কন্টেন্ট "clone" করা, HTTPS, SSH, বা GitHub CLI (Command Line Interface) ব্যবহার করে।
কোড কপি করার কয়েকটি উপায় রয়েছে। একটি উপায় হলো রিপোজিটরির কন্টেন্ট "ক্লোন" করা, HTTPS, SSH, বা GitHub CLI (Command Line Interface) ব্যবহার করে।
আপনার টার্মিনাল খুলুন এবং রিপোজিটরি ক্লোন করুন:
আপনার টার্মিনাল খুলুন এবং রিপোজিটরি ক্লোন করুন এভাবে:
`git clone https://github.com/ProjectURL`
প্রকল্পে কাজ করতে সঠিক ফোল্ডারে যান:
প্রকল্পে কাজ করতে সঠিক ফোল্ডারে যান:
`cd ProjectURL`
আপনি পুরো প্রকল্পটি [Codespaces](https://github.com/features/codespaces), GitHub-এর এম্বেডেড কোড এডিটর / ক্লাউড ডেভেলপমেন্ট এনভায়রনমেন্ট, অথবা [GitHub Desktop](https://desktop.github.com/) ব্যবহার করে খুলতে পারেন।
আপনি পুরো প্রকল্পটি [Codespaces](https://github.com/features/codespaces), GitHub-এর এম্বেডেড কোড এডিটর / ক্লাউড ডেভেলপমেন্ট এনভায়রনমেন্ট, বা [GitHub Desktop](https://desktop.github.com/) ব্যবহার করে খুলতে পারেন।
অবশেষে, আপনি কোডটি একটি জিপ করা ফোল্ডারে ডাউনলোড করতে পারেন।
### GitHub সম্পর্কে আরও কিছু আকর্ষণীয় বিষয়
আপনি GitHub-এ যেকোনো পাবলিক রিপোজিটরিকে স্টার, ওয়াচ এবং/অথবা "fork" করতে পারেন। আপনার স্টার করা রিপোজিটরি আপনি উপরের ডানদিকে ড্রপ-ডাউন মেনুতে খুঁজে পাবেন। এটি কোডের জন্য বুকমার্ক করার মতো।
আপনি GitHub-এ যেকোনো পাবলিক রিপোজিটরি "star", "watch" এবং/অথবা "fork" করতে পারেন। আপনার starred রিপোজিটরি আপনি উপরের ডানদিকে ড্রপ-ডাউন মেনুতে খুঁজে পাবেন। এটি কোডের জন্য বুকমার্ক করার মতো।
প্রকল্পগুলোতে একটি issue tracker থাকে, সাধারণত GitHub-এর "Issues" ট্যাবে, যেখানে প্রকল্প সম্পর্কিত বিষয়গুলো নিয়ে আলোচনা করা হয়। এবং Pull Requests ট্যাবে চলমান পরিবর্তনগুলো নিয়ে আলোচনা এবং রিভিউ করা হয়।
প্রকল্পগুলির একটি issue tracker থাকে, সাধারণত GitHub-এর "Issues" ট্যাবে যদি অন্যথা উল্লেখ না করা হয়, যেখানে প্রকল্প সম্পর্কিত বিষয়গুলি নিয়ে আলোচনা করা হয়। এবং Pull Requests ট্যাবে মানুষ চলমান পরিবর্তনগুলি নিয়ে আলোচনা এবং রিভিউ করে।
প্রকল্পগুলোতে ফোরাম, মেইলিং লিস্ট, বা Slack, Discord বা IRC-এর মতো চ্যাট চ্যানেলে আলোচনা হতে পারে।
প্রকল্পগুলিতে ফোরাম, মেইলিং লিস্ট, বা Slack, Discord বা IRC-এর মতো চ্যাট চ্যানেলে আলোচনা থাকতে পারে।
✅ আপনার নতুন GitHub রিপোজিটরির চারপাশে ঘুরে দেখুন এবং কিছু জিনিস চেষ্টা করুন, যেমন সেটিংস সম্পাদনা করা, আপনার রিপোতে তথ্য যোগ করা, এবং একটি প্রকল্প তৈরি করা (যেমন একটি Kanban বোর্ড)। এখানে অনেক কিছু করার আছে!
✅ আপনার নতুন GitHub রিপোজিটরিটি ঘুরে দেখুন এবং কিছু জিনিস চেষ্টা করুন, যেমন সেটিংস সম্পাদনা করা, আপনার রিপোজিটরিতে তথ্য যোগ করা, এবং একটি প্রকল্প তৈরি করা (যেমন একটি Kanban বোর্ড)। এখানে অনেক কিছু করার আছে!
---
## 🚀 চ্যালেঞ্জ
## 🚀 চ্যালেঞ্জ
একজন বন্ধুর সাথে জুটি বাঁধুন এবং একে অপরের কোডে কাজ করুন। একটি প্রকল্প যৌথভাবে তৈরি করুন, কোড fork করুন, শাখা তৈরি করুন, এবং পরিবর্তন merge করুন।
একজন বন্ধুর সাথে জুটি বাঁধুন এবং একে অপরের কোডে কাজ করুন। একটি প্রকল্প যৌথভাবে তৈরি করুন, কোড fork করুন, ব্রাঞ্চ তৈরি করুন এবং পরিবর্তন merge করুন।
অনুশীলন, অনুশীলন, অনুশীলন। GitHub-এ [skills.github.com](https://skills.github.com)-এর মাধ্যমে চমৎকার লার্নিং পাথ রয়েছে:
অনুশীলন, অনুশীলন, অনুশীলন। GitHub-এ [skills.github.com](https://skills.github.com)এর মাধ্যমে চমৎকার লার্নিং পাথ রয়েছে:
- [GitHub-এ প্রথম সপ্তাহ](https://skills.github.com/#first-week-on-github)
আপনি আরও উন্নত কোর্সও খুঁজে পাবেন।
## অ্যাসাইনমেন্ট
## অ্যাসাইনমেন্ট
[GitHub-এ প্রথম সপ্তাহ কোর্স](https://skills.github.com/#first-week-on-github) সম্পন্ন করুন।
---
**অস্বীকৃতি**:
এই নথিটি AI অনুবাদ পরিষেবা [Co-op Translator](https://github.com/Azure/co-op-translator) ব্যবহার করে অনুবাদ করা হয়েছে। আমরা যথাসাধ্য সঠিকতার জন্য চেষ্টা করি, তবে অনুগ্রহ করে মনে রাখবেন যে স্বয়ংক্রিয় অনুবাদে ত্রুটি বা অসঙ্গতি থাকতে পারে। মূল ভাষায় থাকা নথিটিকে প্রামাণিক উৎস হিসেবে বিবেচনা করা উচিত। গুরুত্বপূর্ণ তথ্যের জন্য, পেশাদার মানব অনুবাদ সুপারিশ করা হয়। এই অনুবাদ ব্যবহারের ফলে কোনো ভুল বোঝাবুঝি বা ভুল ব্যাখ্যা হলে আমরা দায়বদ্ধ থাকব না।
এই নথিটি AI অনুবাদ পরিষেবা [Co-op Translator](https://github.com/Azure/co-op-translator) ব্যবহার করে অনুবাদ করা হয়েছে। আমরা যথাসাধ্য সঠিকতা নিশ্চিত করার চেষ্টা করি, তবে অনুগ্রহ করে মনে রাখবেন যে স্বয়ংক্রিয় অনুবাদে ত্রুটি বা অসঙ্গতি থাকতে পারে। মূল ভাষায় থাকা নথিটিকে প্রামাণিক উৎস হিসেবে বিবেচনা করা উচিত। গুরুত্বপূর্ণ তথ্যের জন্য, পেশাদার মানব অনুবাদ সুপারিশ করা হয়। এই অনুবাদ ব্যবহারের ফলে কোনো ভুল বোঝাবুঝি বা ভুল ব্যাখ্যা হলে আমরা দায়বদ্ধ থাকব না।
- como rastrear o trabalho que você faz na sua máquina
- como trabalhar em projetos com outras pessoas
@ -27,7 +27,7 @@ Nesta lição, vamos abordar:
### Pré-requisitos
Antes de começar, você precisa verificar se o Git está instalado. No terminal, digite:
Antes de começar, você precisará verificar se o Git está instalado. No terminal, digite:
`git --version`
Se o Git não estiver instalado, [baixe o Git](https://git-scm.com/downloads). Em seguida, configure seu perfil local do Git no terminal:
@ -37,9 +37,9 @@ Se o Git não estiver instalado, [baixe o Git](https://git-scm.com/downloads). E
Para verificar se o Git já está configurado, você pode digitar:
`git config --list`
Você também precisará de uma conta no GitHub, um editor de código (como o Visual Studio Code) e deverá abrir seu terminal (ou prompt de comando).
Você também precisará de uma conta no GitHub, um editor de código (como o Visual Studio Code) e precisará abrir seu terminal (ou prompt de comando).
Acesse [github.com](https://github.com/) e crie uma conta, caso ainda não tenha uma, ou faça login e preencha seu perfil.
Acesse [github.com](https://github.com/) e crie uma conta, se ainda não tiver uma, ou faça login e preencha seu perfil.
✅ O GitHub não é o único repositório de código no mundo; existem outros, mas o GitHub é o mais conhecido.
@ -51,11 +51,11 @@ Você precisará de uma pasta com um projeto de código na sua máquina local (l
## Gerenciamento de código
Vamos supor que você tenha uma pasta localmente com algum projeto de código e queira começar a rastrear seu progresso usando o Git - o sistema de controle de versão. Algumas pessoas comparam usar o Git a escrever uma carta de amor para seu futuro eu. Ao ler suas mensagens de commit dias, semanas ou meses depois, você será capaz de lembrar por que tomou uma decisão ou "reverter" uma alteração - isso, claro, quando você escreve boas mensagens de commit.
Digamos que você tenha uma pasta localmente com algum projeto de código e queira começar a rastrear seu progresso usando o Git - o sistema de controle de versão. Algumas pessoas comparam usar o Git a escrever uma carta de amor para o seu "eu" do futuro. Ao ler suas mensagens de commit dias, semanas ou meses depois, você será capaz de lembrar por que tomou uma decisão ou "reverter" uma alteração - isso, claro, se você escrever boas "mensagens de commit".
### Tarefa: Criar um repositório e fazer commit de código
### Tarefa: Criar um repositório e fazer commit do código
> Confira o vídeo
> Assista ao vídeo
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
@ -82,7 +82,7 @@ Vamos supor que você tenha uma pasta localmente com algum projeto de código e
git status
```
A saída pode ser algo como:
A saída pode ser algo assim:
```output
Changes not staged for commit:
@ -96,13 +96,13 @@ Vamos supor que você tenha uma pasta localmente com algum projeto de código e
Normalmente, o comando `git status` informa coisas como quais arquivos estão prontos para serem _salvos_ no repositório ou têm alterações que você pode querer persistir.
1. **Adicionar todos os arquivos para rastreamento**
Isso também é chamado de "estágio de arquivos" ou "adicionar arquivos à área de preparação".
Isso também é chamado de preparar arquivos/adicionar arquivos à área de preparação.
```bash
git add .
```
O argumento `git add` seguido de`.` indica que todos os seus arquivos e alterações serão rastreados.
O comando `git add` com o argumento`.` indica que todos os seus arquivos e alterações serão rastreados.
1. **Adicionar arquivos selecionados para rastreamento**
@ -128,17 +128,17 @@ Vamos supor que você tenha uma pasta localmente com algum projeto de código e
Este comando nos ajuda a remover apenas um arquivo específico da área de preparação que não queremos incluir no próximo commit.
1. **Persistir seu trabalho**. Neste ponto, você adicionou os arquivos a uma chamada _área de preparação_. Um lugar onde o Git está rastreando seus arquivos. Para tornar a alteração permanente, você precisa _fazer commit_ dos arquivos. Para isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto de salvamento na história do seu repositório. Digite o seguinte para criar um _commit_:
1. **Persistir seu trabalho**. Neste ponto, você adicionou os arquivos a uma chamada _área de preparação_. Um lugar onde o Git está rastreando seus arquivos. Para tornar a alteração permanente, você precisa _fazer commit_ dos arquivos. Para isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto de salvamento no histórico do seu repositório. Digite o seguinte para criar um _commit_:
```bash
git commit -m "first commit"
```
Isso faz commit de todos os seus arquivos, adicionando a mensagem "primeiro commit". Para mensagens de commit futuras, você vai querer ser mais descritivo na sua descrição para transmitir o tipo de alteração que você fez.
Isso faz o commit de todos os seus arquivos, adicionando a mensagem "primeiro commit". Para mensagens de commit futuras, você vai querer ser mais descritivo na sua descrição para transmitir que tipo de alteração você fez.
1. **Conectar seu repositório Git local ao GitHub**. Um repositório Git é útil na sua máquina, mas em algum momento você vai querer ter um backup dos seus arquivos em algum lugar e também convidar outras pessoas para trabalhar com você no repositório. Um ótimo lugar para isso é o GitHub. Lembre-se de que já criamos um repositório no GitHub, então só precisamos conectar nosso repositório Git local ao GitHub. O comando `git remote add` fará isso. Digite o seguinte comando:
1. **Conectar seu repositório Git local ao GitHub**. Um repositório Git é útil na sua máquina, mas em algum momento você vai querer ter um backup dos seus arquivos em algum lugar e também convidar outras pessoas para trabalhar com você no seu repositório. Um ótimo lugar para fazer isso é o GitHub. Lembre-se de que já criamos um repositório no GitHub, então a única coisa que precisamos fazer é conectar nosso repositório Git local ao GitHub. O comando `git remote add` fará exatamente isso. Digite o seguinte comando:
> Nota: antes de digitar o comando, vá até a página do repositório no GitHub para encontrar a URL do repositório. Você usará essa URL no comando abaixo. Substitua ```https://github.com/username/repository_name.git``` pela URL do GitHub.
> Nota: antes de digitar o comando, vá até a página do seu repositório no GitHub para encontrar a URL do repositório. Você usará essa URL no comando abaixo. Substitua ```https://github.com/username/repository_name.git``` pela URL do seu repositório no GitHub.
@ -148,15 +148,15 @@ Vamos supor que você tenha uma pasta localmente com algum projeto de código e
1. **Enviar arquivos locais para o GitHub**. Até agora, você criou uma _conexão_ entre o repositório local e o repositório do GitHub. Vamos enviar esses arquivos para o GitHub com o seguinte comando `git push`, assim:
> Nota: o nome da sua branch pode ser diferente por padrão de ```main```.
> Nota: o nome do seu branch pode ser diferente do padrão ```main```.
```bash
git push -u origin main
```
Isso envia seus commits na branch "main" para o GitHub.
Isso envia seus commits no branch "main" para o GitHub. Configurar o branch `upstream`, incluindo `-u` no comando, estabelece um link entre seu branch local e o branch remoto, para que você possa simplesmente usar `git push` ou `git pull` sem especificar o nome do branch no futuro. O Git usará automaticamente o branch upstream e você não precisará especificar o nome do branch explicitamente em comandos futuros.
2. **Adicionar mais alterações**. Se você quiser continuar fazendo alterações e enviá-las para o GitHub, só precisará usar os seguintes três comandos:
2. **Para adicionar mais alterações**. Se você quiser continuar fazendo alterações e enviando-as para o GitHub, só precisará usar os três comandos a seguir:
```bash
git add .
@ -164,25 +164,25 @@ Vamos supor que você tenha uma pasta localmente com algum projeto de código e
git push
```
> Dica: você também pode adotar um arquivo `.gitignore` para evitar que arquivos que você não deseja rastrear apareçam no GitHub - como aquele arquivo de notas que você armazena na mesma pasta, mas que não tem lugar em um repositório público. Você pode encontrar modelos para arquivos `.gitignore` em [.gitignore templates](https://github.com/github/gitignore).
> Dica: você também pode querer adotar um arquivo `.gitignore` para evitar que arquivos que você não deseja rastrear apareçam no GitHub - como aquele arquivo de anotações que você armazena na mesma pasta, mas que não tem lugar em um repositório público. Você pode encontrar modelos para arquivos `.gitignore` em [.gitignore templates](https://github.com/github/gitignore).
#### Mensagens de commit
Uma ótima linha de assunto para um commit no Git completa a seguinte frase:
Se aplicado, este commit irá <sualinhadeassuntoaqui>
Para o assunto, use o imperativo no presente: "alterar" e não "alterado" nem "altera".
Assim como no assunto, no corpo (opcional) também use o imperativo no presente. O corpo deve incluir a motivação para a alteração e contrastá-la com o comportamento anterior. Você está explicando o `porquê`, não o `como`.
Para o assunto, use o imperativo no presente: "alterar" em vez de "alterado" ou "altera".
Assim como no assunto, no corpo (opcional) também use o imperativo no presente. O corpo deve incluir a motivação para a alteração e contrastar isso com o comportamento anterior. Você está explicando o `porquê`, não o `como`.
✅ Reserve alguns minutos para navegar pelo GitHub. Você consegue encontrar uma mensagem de commit realmente boa? Consegue encontrar uma bem minimalista? Quais informações você acha que são mais importantes e úteis para transmitir em uma mensagem de commit?
✅ Reserve alguns minutos para explorar o GitHub. Você consegue encontrar uma mensagem de commit realmente boa? E uma bem minimalista? Quais informações você acha que são mais importantes e úteis para transmitir em uma mensagem de commit?
### Tarefa: Colaborar
O principal motivo para colocar coisas no GitHub foi tornar possível colaborar com outros desenvolvedores.
O principal motivo para colocar coisas no GitHub foi possibilitar a colaboração com outros desenvolvedores.
## Trabalhando em projetos com outras pessoas
> Confira o vídeo
> Assista ao vídeo
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
@ -195,32 +195,33 @@ No seu repositório, navegue até `Insights > Community` para ver como seu proje
- **Código de Conduta**. Um [Código de Conduta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licença**. Talvez o mais importante, uma [licença](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Todos esses recursos beneficiarão a integração de novos membros da equipe. E essas são, geralmente, as coisas que novos contribuidores olham antes mesmo de olhar para o seu código, para descobrir se seu projeto é o lugar certo para eles investirem seu tempo.
✅ Arquivos README, embora levem tempo para serem preparados, são frequentemente negligenciados por mantenedores ocupados. Você consegue encontrar um exemplo de um README particularmente descritivo? Nota: existem alguns [ferramentas para ajudar a criar bons READMEs](https://www.makeareadme.com/) que você pode querer experimentar.
Todos esses recursos beneficiarão a integração de novos membros da equipe. E essas são, geralmente, as coisas que novos contribuidores olham antes mesmo de olhar para o seu código, para descobrir se o seu projeto é o lugar certo para eles investirem seu tempo.
### Tarefa: Fazer merge de código
✅ Arquivos README, embora levem tempo para serem preparados, são frequentemente negligenciados por mantenedores ocupados. Você consegue encontrar um exemplo de um particularmente descritivo? Nota: existem algumas [ferramentas para ajudar a criar bons READMEs](https://www.makeareadme.com/) que você pode querer experimentar.
Documentos de contribuição ajudam as pessoas a contribuir para o projeto. Eles explicam quais tipos de contribuições você está procurando e como o processo funciona. Os contribuidores precisarão passar por uma série de etapas para poder contribuir para seu repositório no GitHub:
### Tarefa: Fazer merge de algum código
1. **Fazer fork do seu repositório**. Você provavelmente vai querer que as pessoas _façam fork_ do seu projeto. Fazer fork significa criar uma réplica do seu repositório no perfil delas no GitHub.
1. **Clonar**. A partir daí, elas irão clonar o projeto para sua máquina local.
1. **Criar uma branch**. Você vai querer pedir que elas criem uma _branch_ para o trabalho delas.
1. **Focar a alteração em uma área**. Peça aos contribuidores para concentrarem suas contribuições em uma coisa de cada vez - assim, as chances de você conseguir _fazer merge_ do trabalho deles são maiores. Imagine que eles escrevam uma correção de bug, adicionem um novo recurso e atualizem vários testes - e se você quiser ou puder implementar apenas 2 de 3 ou 1 de 3 alterações?
Documentos de contribuição ajudam as pessoas a contribuir para o projeto. Eles explicam quais tipos de contribuições você está procurando e como o processo funciona. Os contribuidores precisarão passar por uma série de etapas para poder contribuir para o seu repositório no GitHub:
✅ Imagine uma situação onde branches são particularmente críticas para escrever e entregar um bom código. Quais casos de uso você consegue pensar?
1. **Fazer fork do seu repositório**. Você provavelmente vai querer que as pessoas _façam fork_ do seu projeto. Fazer fork significa criar uma réplica do seu repositório no perfil do GitHub delas.
1. **Clonar**. A partir daí, elas irão clonar o projeto para suas máquinas locais.
1. **Criar um branch**. Você vai querer pedir que elas criem um _branch_ para o trabalho delas.
1. **Focar a alteração em uma área**. Peça aos contribuidores que concentrem suas contribuições em uma coisa de cada vez - assim, as chances de você conseguir _fazer merge_ do trabalho deles são maiores. Imagine que eles escrevam uma correção de bug, adicionem um novo recurso e atualizem vários testes - e se você quiser, ou puder, implementar apenas 2 de 3, ou 1 de 3 alterações?
> Nota: seja a mudança que você quer ver no mundo e crie branches para seu próprio trabalho também. Qualquer commit que você fizer será feito na branch que você está atualmente "checado". Use `git status` para ver em qual branch você está.
✅ Imagine uma situação em que branches são particularmente críticos para escrever e entregar um bom código. Quais casos de uso você consegue pensar?
Vamos passar por um fluxo de trabalho de contribuidores. Assuma que o contribuidor já _fez fork_ e _clonou_ o repositório, então ele tem um repositório Git pronto para ser trabalhado na máquina local:
> Nota: seja a mudança que você quer ver no mundo e crie branches para o seu próprio trabalho também. Qualquer commit que você fizer será feito no branch em que você está atualmente "checado". Use `git status` para ver em qual branch você está.
1. **Criar uma branch**. Use o comando `git branch` para criar uma branch que conterá as alterações que ele pretende contribuir:
Vamos passar por um fluxo de trabalho de contribuidor. Suponha que o contribuidor já tenha feito _fork_ e _clonado_ o repositório, então ele tem um repositório Git pronto para ser trabalhado em sua máquina local:
1. **Criar um branch**. Use o comando `git branch` para criar um branch que conterá as alterações que ele pretende contribuir:
```bash
git branch [branch-name]
```
1. **Trocar para a branch de trabalho**. Troque para a branch especificada e atualize o diretório de trabalho com `git switch`:
1. **Mudar para o branch de trabalho**. Mude para o branch especificado e atualize o diretório de trabalho com `git switch`:
```bash
git switch [branch-name]
@ -233,95 +234,99 @@ Vamos passar por um fluxo de trabalho de contribuidores. Assuma que o contribuid
git commit -m "my changes"
```
Certifique-se de dar um bom nome ao seu commit, para seu próprio benefício e para o mantenedor do repositório que você está ajudando.
Certifique-se de dar um bom nome ao seu commit, para o seu bem e para o mantenedor do repositório que você está ajudando.
1. **Combinar seu trabalho com a branch `main`**. Em algum momento, você termina o trabalho e quer combinar seu trabalho com o da branch `main`. A branch `main` pode ter mudado enquanto isso, então certifique-se de primeiro atualizá-la para a versão mais recente com os seguintes comandos:
1. **Combinar seu trabalho com o branch `main`**. Em algum momento, você termina o trabalho e quer combinar seu trabalho com o do branch `main`. O branch `main` pode ter mudado nesse meio tempo, então certifique-se de primeiro atualizá-lo para a versão mais recente com os seguintes comandos:
```bash
git switch main
git pull
```
Neste ponto, você quer garantir que quaisquer _conflitos_, situações onde o Git não consegue facilmente _combinar_ as alterações, aconteçam na sua branch de trabalho. Portanto, execute os seguintes comandos:
Neste ponto, você quer garantir que quaisquer _conflitos_, situações em que o Git não consegue facilmente _combinar_ as alterações, ocorram no seu branch de trabalho. Portanto, execute os seguintes comandos:
```bash
git switch [branch_name]
git merge main
```
Isso trará todas as alterações da branch `main` para sua branch e, com sorte, você poderá continuar. Se não, o VS Code mostrará onde o Git está _confuso_ e você apenas alterará os arquivos afetados para indicar qual conteúdo é o mais preciso.
O comando `git merge main` trará todas as alterações do `main` para o seu branch. Esperançosamente, você pode simplesmente continuar. Caso contrário, o VS Code informará onde o Git está _confuso_ e você apenas altera os arquivos afetados para indicar qual conteúdo é o mais preciso.
1. **Enviar seu trabalho para o GitHub**. Enviar seu trabalho para o GitHub significa duas coisas: enviar sua branch para seu repositório e, em seguida, abrir um PR (Pull Request).
Para mudar para um branch diferente, use o comando moderno `git switch`:
```bash
git switch [branch_name]
1. **Enviar seu trabalho para o GitHub**. Enviar seu trabalho para o GitHub significa duas coisas: enviar seu branch para o seu repositório e, em seguida, abrir um PR (Pull Request).
```bash
git push --set-upstream origin [branch-name]
```
O comando acima cria a branch no seu repositório de fork.
1. **Abrir um PR**. Em seguida, você quer abrir um PR. Você faz isso navegando até o repositório de fork no GitHub. Você verá uma indicação no GitHub perguntando se deseja criar um novo PR, clique nisso e você será levado a uma interface onde pode alterar o título da mensagem de commit, dar uma descrição mais adequada. Agora o mantenedor do repositório que você fez fork verá este PR e _dedos cruzados_ ele apreciará e _fará merge_ do seu PR. Você agora é um contribuidor, yay :)
O comando acima cria o branch no seu repositório que foi feito fork.
1. **Abra um PR**. Agora você vai querer abrir um PR. Para isso, navegue até o repositório que você fez o fork no GitHub. Você verá uma indicação no GitHub perguntando se deseja criar um novo PR. Clique nela e você será levado a uma interface onde pode alterar o título da mensagem de commit e dar uma descrição mais adequada. Agora, o mantenedor do repositório que você fez o fork verá este PR e, _dedos cruzados_, ele irá apreciar e _mesclar_ seu PR. Parabéns, você agora é um colaborador, yay :)
1. **Limpar**. É considerado uma boa prática _limpar_após você ter feito merge com sucesso de um PR. Você quer limpar tanto sua branch local quanto a branch que você enviou para o GitHub. Primeiro, vamos deletá-la localmente com o seguinte comando:
1. **Limpeza**. É considerado uma boa prática _limpar_depois de mesclar com sucesso um PR. Você deve limpar tanto sua branch local quanto a branch que você enviou para o GitHub. Primeiro, vamos deletá-la localmente com o seguinte comando:
```bash
git branch -d [branch-name]
```
Certifique-se de ir à página do GitHub do repositório que você fez o fork e remover a branch remota que você acabou de enviar.
Certifique-se de ir à página do repositório de fork no GitHub e remover a branch remota que você acabou de enviar.
`Pull request` pode parecer um termo estranho, porque na verdade você quer enviar suas alterações para o projeto. Mas o mantenedor (dono do projeto) ou a equipe principal precisa avaliar suas alterações antes de integrá-las ao branch "main" do projeto. Então, você está realmente solicitando uma decisão de mudança ao mantenedor.
`Pull request` parece um termo estranho porque, na verdade, você quer enviar suas alterações para o projeto. Mas o mantenedor (dono do projeto) ou a equipe principal precisa considerar suas alterações antes de mesclá-las com a branch "main" do projeto. Então, você está realmente solicitando uma decisão de alteração de um mantenedor.
Um pull request é o lugar para comparar e discutir as diferenças introduzidas em um branch, com revisões, comentários, testes integrados e mais. Um bom pull request segue aproximadamente as mesmas regras de uma mensagem de commit. Você pode adicionar uma referência a um problema no rastreador de problemas, por exemplo, quando seu trabalho resolve um problema. Isso é feito usando um `#` seguido pelo número do problema. Por exemplo, `#97`.
Um pull request é o lugar para comparar e discutir as diferenças introduzidas em uma branch com revisões, comentários, testes integrados e mais. Um bom pull request segue aproximadamente as mesmas regras de uma mensagem de commit. Você pode adicionar uma referência a um problema no rastreador de problemas, por exemplo, quando seu trabalho resolve um problema. Isso é feito usando um `#` seguido pelo número do problema. Por exemplo, `#97`.
🤞Dedos cruzados para que todos os testes passem e o(s) dono(s) do projeto integrem suas alterações ao projeto🤞
🤞Dedos cruzados para que todos os testes passem e o(s) dono(s) do projeto mesclem suas alterações no projeto🤞
Atualize seu branch local atual com todos os novos commits do branch remoto correspondente no GitHub:
Atualize sua branch local de trabalho atual com todos os novos commits da branch remota correspondente no GitHub:
`git pull`
## Como contribuir para código aberto
## Como contribuir para open source
Primeiro, vamos encontrar um repositório (ou **repo**) no GitHub que seja do seu interesse e para o qual você gostaria de contribuir com uma alteração. Você vai querer copiar o conteúdo dele para sua máquina.
Primeiro, vamos encontrar um repositório (ou **repo**) no GitHub que seja do seu interesse e para o qual você gostaria de contribuir com uma alteração. Você vai querer copiar seu conteúdo para sua máquina.
✅ Uma boa maneira de encontrar repositórios 'amigáveis para iniciantes' é [buscar pela tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Existem várias maneiras de copiar código. Uma delas é "clonar" o conteúdo do repositório, usando HTTPS, SSH ou a CLI (Interface de Linha de Comando) do GitHub.
Existem várias maneiras de copiar código. Uma delas é "clonar" o conteúdo do repositório, usando HTTPS, SSH ou o GitHub CLI (Interface de Linha de Comando).
Abra seu terminal e clone o repositório assim:
Abra seu terminal e clone o repositório assim:
`git clone https://github.com/ProjectURL`
Para trabalhar no projeto, mude para a pasta correta:
Para trabalhar no projeto, mude para a pasta correta:
`cd ProjectURL`
Você também pode abrir o projeto inteiro usando [Codespaces](https://github.com/features/codespaces), o editor de código integrado/ambiente de desenvolvimento em nuvem do GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Você também pode abrir o projeto inteiro usando [Codespaces](https://github.com/features/codespaces), o editor de código integrado/ambiente de desenvolvimento em nuvem do GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Por fim, você pode baixar o código em uma pasta compactada.
### Algumas coisas interessantes sobre o GitHub
Você pode dar estrela, seguir ou "forkar" qualquer repositório público no GitHub. Você encontra seus repositórios com estrela no menu suspenso no canto superior direito. É como salvar nos favoritos, mas para código.
Você pode dar estrela, seguir e/ou "fazer fork" de qualquer repositório público no GitHub. Você pode encontrar seus repositórios com estrela no menu suspenso no canto superior direito. É como adicionar aos favoritos, mas para código.
Os projetos têm um rastreador de problemas, geralmente no GitHub na aba "Issues", a menos que indicado de outra forma, onde as pessoas discutem problemas relacionados ao projeto. E a aba Pull Requests é onde as pessoas discutem e revisam alterações que estão em andamento.
Os projetos também podem ter discussões em fóruns, listas de e-mails ou canais de chat como Slack, Discord ou IRC.
✅ Explore seu novo repositório no GitHub e experimente algumas coisas, como editar configurações, adicionar informações ao repositório e criar um projeto (como um quadro Kanban). Há muito o que fazer!
✅ Dê uma olhada no seu novo repositório no GitHub e experimente algumas coisas, como editar configurações, adicionar informações ao seu repositório e criar um projeto (como um quadro Kanban). Há muito o que explorar!
---
## 🚀 Desafio
Trabalhe em parceria com um amigo para trabalhar no código um do outro. Crie um projeto colaborativo, faça fork do código, crie branches e integre alterações.
Trabalhe em parceria com um amigo no código um do outro. Crie um projeto colaborativo, faça fork do código, crie branches e mescle alterações.
Leia mais sobre [como contribuir para software de código aberto](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Leia mais sobre [como contribuir para software open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Guia rápido de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
[Cheatsheet do Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Pratique, pratique, pratique. O GitHub tem ótimos caminhos de aprendizado disponíveis via [skills.github.com](https://skills.github.com):
@ -336,4 +341,4 @@ Complete [o curso Primeira Semana no GitHub](https://skills.github.com/#first-we
---
**Aviso Legal**:
Este documento foi traduzido utilizando o serviço de tradução por IA [Co-op Translator](https://github.com/Azure/co-op-translator). Embora nos esforcemos para garantir a precisão, esteja ciente de que traduções automáticas podem conter erros ou imprecisões. O documento original em seu idioma nativo deve ser considerado a fonte oficial. Para informações críticas, recomenda-se a tradução profissional realizada por humanos. Não nos responsabilizamos por quaisquer mal-entendidos ou interpretações equivocadas decorrentes do uso desta tradução.
Este documento foi traduzido utilizando o serviço de tradução por IA [Co-op Translator](https://github.com/Azure/co-op-translator). Embora nos esforcemos para garantir a precisão, é importante estar ciente de que traduções automatizadas podem conter erros ou imprecisões. O documento original em seu idioma nativo deve ser considerado a fonte oficial. Para informações críticas, recomenda-se a tradução profissional realizada por humanos. Não nos responsabilizamos por quaisquer mal-entendidos ou interpretações equivocadas decorrentes do uso desta tradução.
Než začnete, zkontrolujte, zda máte nainstalovaný Git. V terminálu zadejte:
Než začnete, zkontrolujte, zda máte nainstalovaný Git. V terminálu napište:
`git --version`
Pokud Git není nainstalován, [stáhněte Git](https://git-scm.com/downloads). Poté nastavte svůj lokální Git profil v terminálu:
* `git config --global user.name "vaše-jméno"`
* `git config --global user.email "váš-email"`
Pro kontrolu, zda je Git již nakonfigurován, můžete zadat:
Pro kontrolu, zda je Git již nakonfigurován, napište:
`git config --list`
Budete také potřebovat účet na GitHubu, editor kódu (například Visual Studio Code) a otevřít svůj terminál (nebo příkazový řádek).
Přejděte na [github.com](https://github.com/) a vytvořte si účet, pokud ho ještě nemáte, nebo se přihlaste a vyplňte svůj profil.
Přejděte na [github.com](https://github.com/) a vytvořte si účet, pokud ho ještě nemáte, nebo se přihlaste a vyplňte svůj profil.
✅ GitHub není jediným úložištěm kódu na světě; existují i další, ale GitHub je nejznámější.
✅ GitHub není jediným úložištěm kódu na světě; existují i jiné, ale GitHub je nejznámější.
### Příprava
Budete potřebovat složku s projektem kódu na svém lokálním počítači (notebooku nebo PC) a veřejné úložiště na GitHubu, které poslouží jako příklad, jak přispívat do projektů ostatních.
Budete potřebovat složku s projektem kódu na svém lokálním počítači (notebooku nebo PC) a veřejné úložiště na GitHubu, které poslouží jako příklad, jak přispívat do projektů ostatních.
---
## Správa kódu
Představte si, že máte lokální složku s nějakým projektem kódu a chcete začít sledovat svůj pokrok pomocí gitu - systému pro správu verzí. Někteří lidé přirovnávají používání gitu k psaní milostného dopisu svému budoucímu já. Čtením vašich zpráv o commitech po dnech, týdnech nebo měsících si budete schopni vybavit, proč jste udělali určité rozhodnutí, nebo "vrátit zpět" změnu - to vše za předpokladu, že píšete dobré zprávy o commitech.
Představte si, že máte lokální složku s nějakým projektem kódu a chcete začít sledovat svůj pokrok pomocí gitu – systému pro správu verzí. Někteří lidé přirovnávají používání gitu k psaní milostného dopisu svému budoucímu já. Čtením vašich zpráv o commitech po dnech, týdnech nebo měsících si budete schopni vybavit, proč jste udělali určité rozhodnutí, nebo "vrátit" změnu – to vše za předpokladu, že píšete dobré zprávy o commitech.
### Úkol: Vytvořte úložiště a commitujte kód
@ -61,28 +61,28 @@ Představte si, že máte lokální složku s nějakým projektem kódu a chcete
1. **Vytvořte úložiště na GitHubu**. Na GitHub.com, na záložce úložiště nebo z navigačního panelu vpravo nahoře, najděte tlačítko **new repo**.
1. Dejte svému úložišti (složce) název.
1. Pojmenujte své úložiště (složku).
1. Vyberte **create repository**.
1. **Přejděte do své pracovní složky**. V terminálu přepněte do složky (také známé jako adresář), kterou chcete začít sledovat. Zadejte:
1. **Přejděte do své pracovní složky**. V terminálu přepněte do složky (také známé jako adresář), kterou chcete začít sledovat. Napište:
```bash
cd [name of your folder]
```
1. **Inicializujte git úložiště**. Ve svém projektu zadejte:
1. **Inicializujte git úložiště**. Ve svém projektu napište:
```bash
git init
```
1. **Zkontrolujte stav**. Pro kontrolu stavu svého úložiště zadejte:
1. **Zkontrolujte stav**. Pro kontrolu stavu svého úložiště napište:
```bash
git status
```
Výstup může vypadat nějak takto:
výstup může vypadat nějak takto:
```output
Changes not staged for commit:
@ -93,16 +93,16 @@ Představte si, že máte lokální složku s nějakým projektem kódu a chcete
modified: file2.txt
```
Typicky příkaz `git status`vám řekne například, které soubory jsou připraveny k _uložení_ do úložiště nebo mají změny, které byste mohli chtít zachovat.
Typicky příkaz `git status`říká věci jako, které soubory jsou připraveny k _uložení_ do úložiště nebo mají změny, které byste mohli chtít zachovat.
1. **Přidejte všechny soubory ke sledování**
Toto se také nazývá staging souborů/přidávání souborů do staging oblasti.
Toto se také nazývá jako staging souborů/přidávání souborů do staging oblasti.
```bash
git add .
```
Argument `git add` plus `.`označuje, že všechny vaše soubory a změny jsou připraveny ke sledování.
Argument `git add` plus `.`znamená, že všechny vaše soubory a změny jsou připraveny ke sledování.
1. **Přidejte vybrané soubory ke sledování**
@ -128,7 +128,7 @@ Představte si, že máte lokální složku s nějakým projektem kódu a chcete
Tento příkaz nám pomáhá zrušit staging pouze konkrétního souboru najednou, který nechceme zahrnout do dalšího commitu.
1. **Uložení vaší práce**. V tomto bodě jste přidali soubory do tzv. _staging oblasti_. Místa, kde Git sleduje vaše soubory. Aby byla změna trvalá, musíte _commitnout_ soubory. K tomu vytvoříte _commit_ pomocí příkazu `git commit`. _Commit_ představuje bod uložení v historii vašeho úložiště. Zadejte následující pro vytvoření _commitu_:
1. **Uložte svou práci**. V tomto bodě jste přidali soubory do tzv. _staging oblasti_. Místo, kde Git sleduje vaše soubory. Aby byla změna trvalá, musíte _commitovat_ soubory. K tomu vytvoříte _commit_ pomocí příkazu `git commit`. _Commit_ představuje bod uložení v historii vašeho úložiště. Napište následující pro vytvoření _commitu_:
```bash
git commit -m "first commit"
@ -136,27 +136,27 @@ Představte si, že máte lokální složku s nějakým projektem kódu a chcete
Tento příkaz commitne všechny vaše soubory a přidá zprávu "first commit". Pro budoucí zprávy o commitech budete chtít být více popisní, abyste sdělili, jaký typ změny jste provedli.
1. **Propojte své lokální Git úložiště s GitHubem**. Git úložiště je dobré na vašem počítači, ale v určitém bodě budete chtít mít zálohu svých souborů někde jinde a také pozvat ostatní, aby s vámi pracovali na vašem úložišti. Jedním z takových skvělých míst je GitHub. Pamatujte, že jsme již vytvořili úložiště na GitHubu, takže jediná věc, kterou musíme udělat, je propojit naše lokální Git úložiště s GitHubem. Příkaz `git remote add` to udělá. Zadejte následující příkaz:
1. **Propojte své lokální Git úložiště s GitHubem**. Git úložiště je dobré na vašem počítači, ale v určitém bodě budete chtít mít zálohu svých souborů někde jinde a také pozvat ostatní, aby s vámi pracovali na vašem úložišti. Jedním z takových skvělých míst je GitHub. Pamatujte, že jsme již vytvořili úložiště na GitHubu, takže jediná věc, kterou musíme udělat, je propojit naše lokální Git úložiště s GitHubem. Příkaz `git remote add` to udělá. Napište následující příkaz:
> Poznámka: Než zadáte příkaz, přejděte na stránku svého GitHub úložiště a najděte URL úložiště. Použijete ho v níže uvedeném příkazu. Nahraďte ```https://github.com/username/repository_name.git``` svým GitHub URL.
> Poznámka: Před zadáním příkazu přejděte na stránku svého GitHub úložiště a najděte URL úložiště. Použijete ho v níže uvedeném příkazu. Nahraďte ```https://github.com/username/repository_name.git``` svým GitHub URL.
Tento příkaz vytvoří _remote_, nebo spojení, nazvané "origin", které ukazuje na GitHub úložiště, které jste vytvořili dříve.
Tento příkaz vytvoří _remote_, nebo spojení, pojmenované "origin", které ukazuje na GitHub úložiště, které jste vytvořili dříve.
1. **Odešlete lokální soubory na GitHub**. Doposud jste vytvořili _spojení_ mezi lokálním úložištěm a GitHub úložištěm. Pošlete tyto soubory na GitHub pomocí následujícího příkazu `git push`, takto:
1. **Pošlete lokální soubory na GitHub**. Doposud jste vytvořili _spojení_ mezi lokálním úložištěm a GitHub úložištěm. Pošlete tyto soubory na GitHub pomocí následujícího příkazu `git push`, takto:
> Poznámka: Název vaší větve může být ve výchozím nastavení odlišný od ```main```.
> Poznámka: Název vaší větve může být ve výchozím nastavení jiný než ```main```.
```bash
git push -u origin main
```
Tento příkaz odešle vaše commity ve větvi "main" na GitHub.
Tento příkaz pošle vaše commity ve vaší větvi "main" na GitHub. Nastavení větve `upstream` včetně `-u` v příkazu vytvoří propojení mezi vaší lokální větví a vzdálenou větví, takže můžete jednoduše používat git push nebo git pull bez specifikace názvu větve v budoucnu. Git automaticky použije upstream větev a nebudete muset explicitně uvádět název větve v budoucích příkazech.
2. **Přidání dalších změn**. Pokud chcete pokračovat v provádění změn a jejich odesílání na GitHub, budete potřebovat použít následující tři příkazy:
2. **Přidávejte další změny**. Pokud chcete pokračovat v provádění změn a jejich posílání na GitHub, budete potřebovat pouze následující tři příkazy:
```bash
git add .
@ -164,15 +164,15 @@ Představte si, že máte lokální složku s nějakým projektem kódu a chcete
git push
```
> Tip: Možná budete chtít přijmout soubor `.gitignore`, abyste zabránili tomu, aby se soubory, které nechcete sledovat, objevily na GitHubu - například ten soubor s poznámkami, který ukládáte ve stejné složce, ale nemá místo ve veřejném úložišti. Šablony pro soubory `.gitignore` najdete na [.gitignore templates](https://github.com/github/gitignore).
> Tip: Možná budete chtít použít soubor `.gitignore`, abyste zabránili tomu, aby se soubory, které nechcete sledovat, objevily na GitHubu – například ten soubor s poznámkami, který ukládáte ve stejné složce, ale nemá místo ve veřejném úložišti. Šablony pro soubory `.gitignore` najdete na [.gitignore templates](https://github.com/github/gitignore).
#### Zprávy o commitech
Skvělý předmět zprávy o commitu dokončuje následující větu:
Pokud bude aplikováno, tento commit <vášpředmětzde>
Pro předmět použijte rozkazovací způsob v přítomném čase: "změnit" místo "změněno" nebo "změny".
Stejně jako v předmětu, i v těle (volitelném) použijte rozkazovací způsob v přítomném čase. Tělo by mělo zahrnovat motivaci pro změnu a kontrastovat to s předchozím chováním. Vysvětlujete `proč`, ne `jak`.
Pro předmět použijte imperativní přítomný čas: "změnit" místo "změněno" nebo "změny".
Stejně jako v předmětu, i v těle (volitelném) použijte imperativní přítomný čas. Tělo by mělo zahrnovat motivaci ke změně a kontrastovat to s předchozím chováním. Vysvětlujete `proč`, ne `jak`.
✅ Věnujte pár minut prohlížení GitHubu. Najdete opravdu skvělou zprávu o commitu? Najdete opravdu minimalistickou? Jaké informace si myslíte, že jsou nejdůležitější a nejužitečnější pro sdělení ve zprávě o commitu?
@ -193,49 +193,49 @@ Ve svém úložišti přejděte na `Insights > Community`, abyste viděli, jak v
- **README**. Přidali jste README? GitHub poskytuje pokyny pro psaní [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Pokyny pro přispívání**. Má váš projekt [pokyny pro přispívání](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kodex chování**. Má váš projekt [Kodex chování](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licence**. A možná nejdůležitější, má váš projekt [licenci](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Licence**. A možná nejdůležitější, [licenci](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Všechny tyto zdroje budou přínosem pro onboarding nových členů týmu. A to jsou typicky věci, na které se noví přispěvatelé dívají, než se vůbec podívají na váš kód, aby zjistili, zda je váš projekt tím správným místem, kde by měli trávit svůj čas.
Všechny tyto zdroje budou přínosem pro onboarding nových členů týmu. A to jsou typicky věci, na které se noví přispěvatelé dívají, než se podívají na váš kód, aby zjistili, zda je váš projekt tím správným místem, kde by měli trávit svůj čas.
✅ README soubory, i když jejich příprava zabere čas, jsou často opomíjeny zaneprázdněnými správci. Najdete příklad obzvláště popisného README? Poznámka: existují některé [nástroje pro vytvoření dobrých README](https://www.makeareadme.com/), které byste mohli vyzkoušet.
✅ README soubory, i když jejich příprava zabere čas, jsou často opomíjeny zaneprázdněnými správci. Najdete příklad obzvláště popisného README? Poznámka: existují některé [nástroje pro tvorbu dobrých README](https://www.makeareadme.com/), které byste mohli vyzkoušet.
### Úkol: Sloučte nějaký kód
Dokumenty pro přispívání pomáhají lidem přispívat do projektu. Vysvětlují, jaké typy příspěvků hledáte a jak proces funguje. Přispěvatelé budou muset projít sérií kroků, aby mohli přispět do vašeho úložiště na GitHubu:
1. **Forkování vašeho úložiště**. Pravděpodobně budete chtít, aby lidé _forkovali_ váš projekt. Forkování znamená vytvoření repliky vašeho úložiště na jejich GitHub profilu.
1. **Klonování**. Odtud si projekt naklonují na svůj lokální počítač.
1. **Vytvoření větve**. Budete chtít požádat je, aby vytvořili _větev_ pro svou práci.
1. **Zaměření změny na jednu oblast**. Požádejte přispěvatele, aby se soustředili na jednu věc najednou - tím se zvýší šance, že budete moci _sloučit_ jejich práci. Představte si, že opraví chybu, přidají novou funkci a aktualizují několik testů - co když chcete, nebo můžete implementovat pouze 2 ze 3, nebo 1 ze 3 změn?
1. **Klonování**. Odtud si projekt naklonují na svůj lokální počítač.
1. **Vytvoření větve**. Budete chtít požádat je, aby vytvořili _větev_ pro svou práci.
1. **Zaměření změny na jednu oblast**. Požádejte přispěvatele, aby se soustředili na jednu věc najednou – tím se zvýší šance, že budete schopni _sloučit_ jejich práci. Představte si, že opraví chybu, přidají novou funkci a aktualizují několik testů – co když chcete, nebo můžete implementovat pouze 2 ze 3, nebo 1 ze 3 změn?
✅ Představte si situaci, kdy jsou větve obzvláště důležité pro psaní a doručování dobrého kódu. Jaké případy použití vás napadají?
✅ Představte si situaci, kdy jsou větve obzvláště důležité pro psaní a dodávání kvalitního kódu. Jaké případy použití vás napadají?
> Poznámka: Buďte změnou, kterou chcete vidět ve světě, a vytvářejte větve i pro svou vlastní práci. Jakékoliv commity, které provedete, budou provedeny na větvi, na kterou jste aktuálně "přepnuti". Použijte `git status`, abyste viděli, na které větvi se nacházíte.
> Poznámka: Buďte změnou, kterou chcete vidět ve světě, a vytvářejte větve i pro svou vlastní práci. Jakékoliv commity, které provedete, budou provedeny na větvi, na kterou jste aktuálně "přepnuti". Použijte `git status`, abyste viděli, na které větvi právě jste.
Pojďme projít workflow přispěvatele. Předpokládejme, že přispěvatel již _forkoval_ a _klonoval_ úložiště, takže má Git úložiště připravené k práci na svém lokálním počítači:
Pojďme projít workflow přispěvatele. Předpokládejme, že přispěvatel již _forkoval_ a _naklonoval_ úložiště, takže má Git úložiště připravené k práci na svém lokálním počítači:
1. **Vytvoření větve**. Použijte příkaz `git branch` k vytvoření větve, která bude obsahovat změny, které chtějí přispět:
1. **Vytvořte větev**. Použijte příkaz `git branch` k vytvoření větve, která bude obsahovat změny, které chtějí přispět:
```bash
git branch [branch-name]
```
1. **Přepnutí na pracovní větev**. Přepněte na specifikovanou větev a aktualizujte pracovní adresář pomocí `git switch`:
1. **Přepněte na pracovní větev**. Přepněte na specifikovanou větev a aktualizujte pracovní adresář pomocí `git switch`:
```bash
git switch [branch-name]
```
1. **Práce**. V tomto bodě chcete přidat své změny. Nezapomeňte o tom informovat Git pomocí následujících příkazů:
1. **Pracujte**. V tomto bodě chcete přidat své změny. Nezapomeňte o tom informovat Git pomocí následujících příkazů:
```bash
git add .
git commit -m "my changes"
```
Ujistěte se, že dáváte svému commitu dobrý název, pro vaše dobro i pro správce úložiště, na kterém pomáháte.
Ujistěte se, že dáváte svému commitu dobrý název, pro svůj prospěch i pro správce úložiště, na kterém pomáháte.
1. **Sloučení vaší práce s větví `main`**. V určitém bodě jste hotovi s prací a chcete sloučit svou práci s větví `main`. Větev `main` se mezitím mohla změnit, takže se ujistěte, že ji nejprve aktualizujete na nejnovější pomocí následujících příkazů:
1. **Sloučte svou práci s větví `main`**. V určitém bodě jste hotovi s prací a chcete sloučit svou práci s větví `main`. Větev `main` se mezitím mohla změnit, takže se ujistěte, že ji nejprve aktualizujete na nejnovější verzi pomocí následujících příkazů:
```bash
git switch main
@ -249,70 +249,75 @@ Pojďme projít workflow přispěvatele. Předpokládejme, že přispěvatel ji
git merge main
```
Tento příkaz přinese všechny změny z `main` do vaší větve a doufejme, že můžete pokračovat. Pokud ne, VS Code vám ukáže, kde je Git _zmatený_, a vy jen upravíte dotčené soubory, abyste určili, který obsah je nejpřesnější.
Příkaz `git merge main` přinese všechny změny z `main` do vaší větve. Doufejme, že můžete pokračovat. Pokud ne, VS Code vám řekne, kde je Git _zmatený_, a vy jednoduše upravíte dotčené soubory tak, aby obsahovaly nejpřesnější obsah.
Pro přepnutí na jinou větev použijte moderní příkaz `git switch`:
```bash
git switch [branch_name]
1. **Odeslání vaší práce na GitHub**. Odeslání vaší práce na GitHub znamená dvě věci. Pushnutí vaší větve do vašeho úložiště a poté otevření PR, Pull Request.
1. **Pošlete svou práci na GitHub**. Poslání vaší práce na GitHub znamená dvě věci. Pushnutí vaší větve do vašeho úložiště a poté otevření PR, Pull Requestu.
```bash
git push --set-upstream origin [branch-name]
```
Výše uvedený příkaz vytvoří větev na vašem forkovaném úložišti.
1. **Otevřete PR**. Dalším krokem je otevření PR. To uděláte tak, že přejdete na forknuté repo na GitHubu. Na GitHubu uvidíte indikaci, která se vás zeptá, zda chcete vytvořit nový PR. Kliknete na to a dostanete se do rozhraní, kde můžete změnit název zprávy o commitu a přidat vhodnější popis. Nyní uvidí správce repozitáře, který jste forknuli, tento PR a _držte palce_, že ho ocení a _sloučí_ váš PR. Gratulujeme, jste nyní přispěvatelem, hurá :)
1. **Otevření PR**. Dále chcete otevřít PR. Uděláte to tak, že přejdete na forkované úložiště na GitHubu. Na GitHubu uvidíte indikaci, kde se vás ptá, zda chcete vytvořit nový PR, kliknete na to a budete přesměrováni na rozhraní, kde můžete změnit název zprávy o commitu, dát jí vhodnější popis. Nyní správce úložiště, které jste forkovali, uvidí tento PR a _držte palce_, že ho ocení a _sloučí_ váš PR. Nyní jste přispěvatel, hurá :)
1. **Úklid**. Je považováno za dobrý zvyk _uklidit_ po úspěšném sloučení PR. Chcete uklidit jak svou lokální větev, tak větev, kterou jste pushnuli na GitHub. Nejprve ji smažte lokálně pomocí následujícího příkazu:
1. **Úklid**. Je považováno za dobrý zvyk _uklidit_ po úspěšném sloučení PR. Chcete uklidit jak svou lokální větev, tak větev, kterou jste nahráli na GitHub. Nejprve ji smažte lokálně pomocí následujícího příkazu:
```bash
git branch -d [branch-name]
```
Ujistěte se, že přejdete na stránku GitHubu pro forkované úložiště a odstraníte vzdálenou větev, kterou jste právě pushnuli.
`Pull request` se může zdát jako zvláštní termín, protože ve skutečnosti chcete své změny "pushnout" do projektu. Ale správce (vlastník projektu) nebo hlavní tým musí vaše změny zvážit, než je sloučí s "hlavní" větví projektu, takže ve skutečnosti žádáte správce o rozhodnutí ohledně změny.
Poté přejděte na stránku GitHubu pro forknuté repo a odstraňte vzdálenou větev, kterou jste právě nahráli.
`Pull request` se může zdát jako zvláštní termín, protože ve skutečnosti chcete své změny _pushnout_ do projektu. Ale správce (vlastník projektu) nebo hlavní tým musí vaše změny zvážit, než je sloučí s "hlavní" větví projektu, takže ve skutečnosti žádáte správce o rozhodnutí o změně.
Pull request je místo, kde můžete porovnávat a diskutovat o rozdílech zavedených na větvi pomocí recenzí, komentářů, integrovaných testů a dalších nástrojů. Dobrý pull request se řídí přibližně stejnými pravidly jako zpráva o commitu. Můžete přidat odkaz na problém v issue trackeru, například když vaše práce řeší nějaký problém. To se provádí pomocí `#` následovaného číslem problému. Například `#97`.
Pull request je místo, kde můžete porovnávat a diskutovat rozdíly zavedené ve větvi pomocí recenzí, komentářů, integrovaných testů a dalších nástrojů. Dobrý pull request se řídí zhruba stejnými pravidly jako zpráva o commitu. Můžete přidat odkaz na problém v trackeru problémů, například když vaše práce opravuje nějaký problém. To se provádí pomocí `#` následovaného číslem vašeho problému. Například `#97`.
🤞Držte palce, aby všechny kontroly prošly a vlastník(y) projektu vaše změny sloučili do projektu🤞
🤞Držte palce, aby všechny kontroly prošly a vlastník(y) projektu sloučili vaše změny do projektu🤞
Aktualizujte svou aktuální lokální pracovní větev o všechny nové commity z odpovídající vzdálené větve na GitHubu:
Aktualizujte svou aktuální lokální pracovní větev všemi novými commity z odpovídající vzdálené větve na GitHubu:
`git pull`
## Jak přispět do open source
## Jak přispívat do open source
Nejprve si najděte na GitHubu repozitář (nebo **repo**), který vás zajímá a do kterého byste chtěli přispět změnou. Budete chtít zkopírovat jeho obsah na svůj počítač.
Nejprve najděte na GitHubu repozitář (nebo **repo**), který vás zajímá a do kterého byste chtěli přispět změnou. Budete chtít zkopírovat jeho obsah na svůj počítač.
✅ Dobrým způsobem, jak najít repozitáře vhodné pro začátečníky, je [vyhledávání podle tagu 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Existuje několik způsobů, jak zkopírovat kód. Jedním z nich je "klonování" obsahu repozitáře pomocí HTTPS, SSH nebo GitHub CLI (Command Line Interface).
Otevřete terminál a klonujte repozitář takto:
`git clone https://github.com/ProjectURL`
Pro práci na projektu přepněte do správné složky:
Pro práci na projektu přejděte do správné složky:
`cd ProjectURL`
Celý projekt můžete také otevřít pomocí [Codespaces](https://github.com/features/codespaces), integrovaného editoru kódu / cloudového vývojového prostředí GitHubu, nebo [GitHub Desktop](https://desktop.github.com/).
Nakonec si můžete kód stáhnout v zazipované složce.
Nakonec můžete kód stáhnout ve formě zipovaného souboru.
### Několik dalších zajímavostí o GitHubu
Na GitHubu můžete "označit hvězdičkou", sledovat nebo "forknout" jakýkoli veřejný repozitář. Své označené repozitáře najdete v rozbalovací nabídce v pravém horním rohu. Je to jako záložky, ale pro kód.
Na GitHubu můžete označit hvězdičkou, sledovat nebo "forknout" jakýkoli veřejný repozitář. Své označené repozitáře najdete v rozbalovací nabídce v pravém horním rohu. Je to jako záložky, ale pro kód.
Projekty mají issue tracker, většinou na GitHubu v záložce "Issues", pokud není uvedeno jinak, kde lidé diskutují o problémech souvisejících s projektem. A záložka Pull Requests je místem, kde lidé diskutují a recenzují změny, které jsou v procesu.
Projekty mají tracker problémů, většinou na GitHubu v záložce "Issues", pokud není uvedeno jinak, kde lidé diskutují o problémech souvisejících s projektem. A záložka Pull Requests je místem, kde lidé diskutují a recenzují změny, které jsou v procesu.
Projekty mohou mít také diskuse ve fórech, mailing listech nebo chatovacích kanálech jako Slack, Discord nebo IRC.
✅ Prozkoumejte svůj nový GitHub repozitář a vyzkoušejte si pár věcí, jako je úprava nastavení, přidání informací do repozitáře a vytvoření projektu (například Kanban boardu). Možností je spousta!
✅ Prozkoumejte svůj nový repozitář na GitHubu a vyzkoušejte několik věcí, jako je úprava nastavení, přidání informací do repozitáře a vytvoření projektu (například Kanban board). Je toho hodně, co můžete dělat!
---
## 🚀 Výzva
## 🚀 Výzva
Spárujte se s kamarádem a pracujte na kódu toho druhého. Vytvořte projekt společně, forkněte kód, vytvořte větve a sloučte změny.
Spojte se s kamarádem a pracujte na kódu toho druhého. Vytvořte projekt společně, forkněte kód, vytvořte větve a sloučte změny.
## Kvíz po přednášce
[Kvíz po přednášce](https://ff-quizzes.netlify.app/web/en/)
@ -321,19 +326,19 @@ Spárujte se s kamarádem a pracujte na kódu toho druhého. Vytvořte projekt s
Přečtěte si více o [přispívání do open source softwaru](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Cvičte, cvičte, cvičte. GitHub nabízí skvělé vzdělávací cesty prostřednictvím [skills.github.com](https://skills.github.com):
Procvičujte, procvičujte, procvičujte. GitHub má skvělé vzdělávací cesty dostupné na [skills.github.com](https://skills.github.com):
- [První týden na GitHubu](https://skills.github.com/#first-week-on-github)
Najdete tam i pokročilejší kurzy.
Najdete zde také pokročilejší kurzy.
## Zadání
## Úkol
Dokončete [kurz První týden na GitHubu](https://skills.github.com/#first-week-on-github)
---
**Upozornění**:
Tento dokument byl přeložen pomocí služby pro automatický překlad [Co-op Translator](https://github.com/Azure/co-op-translator). I když se snažíme o co největší přesnost, mějte prosím na paměti, že automatické překlady mohou obsahovat chyby nebo nepřesnosti. Původní dokument v jeho původním jazyce by měl být považován za závazný zdroj. Pro důležité informace doporučujeme profesionální lidský překlad. Neodpovídáme za žádná nedorozumění nebo nesprávné výklady vyplývající z použití tohoto překladu.
**Prohlášení**:
Tento dokument byl přeložen pomocí služby AI pro překlad [Co-op Translator](https://github.com/Azure/co-op-translator). I když se snažíme o přesnost, mějte prosím na paměti, že automatické překlady mohou obsahovat chyby nebo nepřesnosti. Původní dokument v jeho rodném jazyce by měl být považován za autoritativní zdroj. Pro důležité informace se doporučuje profesionální lidský překlad. Nejsme zodpovědní za jakékoli nedorozumění nebo nesprávné interpretace vyplývající z použití tohoto překladu.
@ -19,22 +19,22 @@ Denne lektion dækker det grundlæggende i GitHub, en platform til at hoste og a
## Introduktion
I denne lektion vil vi gennemgå:
I denne lektion vil vi dække:
- hvordan du sporer det arbejde, du laver på din maskine
- hvordan du arbejder på projekter sammen med andre
- hvordan du arbejder på projekter med andre
- hvordan du bidrager til open source-software
### Forudsætninger
Før du begynder, skal du tjekke, om Git er installeret. Skriv i terminalen:
Før du begynder, skal du tjekke, om Git er installeret. I terminalen skal du skrive:
`git --version`
Hvis Git ikke er installeret, [download Git](https://git-scm.com/downloads). Opsæt derefter din lokale Git-profil i terminalen:
Hvis Git ikke er installeret, [download Git](https://git-scm.com/downloads). Derefter skal du opsætte din lokale Git-profil i terminalen:
* `git config --global user.name "dit-navn"`
* `git config --global user.email "din-email"`
For at tjekke, om Git allerede er konfigureret, kan du skrive:
For at tjekke, om Git allerede er konfigureret, kan du skrive:
`git config --list`
Du skal også bruge en GitHub-konto, en kodeeditor (som Visual Studio Code), og du skal åbne din terminal (eller: kommandoprompt).
@ -45,13 +45,13 @@ Gå til [github.com](https://github.com/) og opret en konto, hvis du ikke allere
### Forberedelse
Du skal bruge både en mappe med et kodeprojekt på din lokale maskine (laptop eller PC) og et offentligt repository på GitHub, som vil tjene som et eksempel på, hvordan man bidrager til andres projekter.
Du skal bruge både en mappe med et kodeprojekt på din lokale maskine (laptop eller PC) og et offentligt repository på GitHub, som vil fungere som et eksempel på, hvordan man bidrager til andres projekter.
---
## Kodehåndtering
## Kodestyring
Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at spore din fremgang ved hjælp af git - versionskontrolsystemet. Nogle sammenligner brugen af git med at skrive et kærlighedsbrev til dit fremtidige jeg. Når du læser dine commit-beskeder dage, uger eller måneder senere, vil du kunne huske, hvorfor du tog en beslutning, eller "rulle tilbage" en ændring - det vil sige, når du skriver gode "commit-beskeder".
Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at spore din fremgang ved hjælp af git - versionskontrolsystemet. Nogle mennesker sammenligner brugen af git med at skrive et kærlighedsbrev til dit fremtidige jeg. Når du læser dine commit-beskeder dage, uger eller måneder senere, vil du kunne huske, hvorfor du tog en beslutning, eller "rulle tilbage" en ændring - det vil sige, når du skriver gode "commit-beskeder".
### Opgave: Opret et repository og commit kode
@ -82,7 +82,7 @@ Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at
git status
```
Outputtet kan se sådan ud:
outputtet kan se sådan ud:
```output
Changes not staged for commit:
@ -93,7 +93,7 @@ Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at
modified: file2.txt
```
Typisk fortæller en `git status`-kommando dig ting som hvilke filer, der er klar til at blive _gemt_ i repoet, eller som har ændringer, du måske vil gemme.
Typisk fortæller en `git status`-kommando dig ting som hvilke filer der er klar til at blive _gemt_ i repoet, eller som har ændringer, du måske vil gemme.
1. **Tilføj alle filer til sporing**
Dette kaldes også at stage filer/tilføje filer til staging-området.
@ -102,7 +102,7 @@ Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at
git add .
```
Argumentet `git add` plus `.` angiver, at alle dine filer og ændringer skal spores.
`git add` plus `.` argumentet angiver, at alle dine filer og ændringer skal spores.
1. **Tilføj udvalgte filer til sporing**
@ -128,33 +128,33 @@ Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at
Denne kommando hjælper os med kun at fjerne en bestemt fil fra staging-området, som vi ikke ønsker at inkludere i den næste commit.
1. **Gem dit arbejde**. På dette tidspunkt har du tilføjet filerne til et såkaldt _staging-område_. Et sted, hvor Git sporer dine filer. For at gøre ændringen permanent skal du _commit_ filerne. For at gøre dette opretter du en _commit_ med kommandoen `git commit`. En _commit_ repræsenterer et gemmepunkt i historien for dit repo. Skriv følgende for at oprette en _commit_:
1. **Gem dit arbejde**. På dette tidspunkt har du tilføjet filerne til et såkaldt _staging-område_. Et sted, hvor Git sporer dine filer. For at gøre ændringen permanent skal du _committe_ filerne. For at gøre dette opretter du en _commit_ med kommandoen `git commit`. En _commit_ repræsenterer et gemmepunkt i historien for dit repo. Skriv følgende for at oprette en _commit_:
```bash
git commit -m "first commit"
```
Dette committer alle dine filer og tilføjer beskeden "first commit". For fremtidige commit-beskeder vil du gerne være mere beskrivende for at formidle, hvilken type ændring du har lavet.
Dette commit'er alle dine filer og tilføjer beskeden "first commit". For fremtidige commit-beskeder vil du gerne være mere beskrivende i din beskrivelse for at formidle, hvilken type ændring du har lavet.
1. **Forbind dit lokale Git-repo med GitHub**. Et Git-repo er godt på din maskine, men på et tidspunkt vil du gerne have en backup af dine filer et sted og også invitere andre til at arbejde med dig på dit repo. Et godt sted at gøre dette er GitHub. Husk, at vi allerede har oprettet et repo på GitHub, så det eneste, vi skal gøre, er at forbinde vores lokale Git-repo med GitHub. Kommandoen `git remote add` gør netop dette. Skriv følgende kommando:
1. **Forbind dit lokale Git-repo med GitHub**. Et Git-repo er godt på din maskine, men på et tidspunkt vil du gerne have en backup af dine filer et sted og også invitere andre til at arbejde med dig på dit repo. Et godt sted at gøre dette er GitHub. Husk, vi har allerede oprettet et repo på GitHub, så det eneste, vi skal gøre, er at forbinde vores lokale Git-repo med GitHub. Kommandoen `git remote add`vil gøre netop dette. Skriv følgende kommando:
> Bemærk, før du skriver kommandoen, skal du gå til din GitHub-repo-side for at finde repository-URL'en. Du vil bruge den i nedenstående kommando. Erstat ```https://github.com/username/repository_name.git``` med din GitHub-URL.
> Bemærk, før du skriver kommandoen, gå til din GitHub repo-side for at finde repository-URL'en. Du vil bruge den i nedenstående kommando. Erstat ```https://github.com/username/repository_name.git``` med din GitHubURL.
Dette opretter en _remote_, eller forbindelse, kaldet "origin", der peger på det GitHub-repository, du oprettede tidligere.
Dette opretter en _remote_, eller forbindelse, kaldet "origin", der peger på det GitHubrepository, du oprettede tidligere.
1. **Send lokale filer til GitHub**. Indtil videre har du oprettet en _forbindelse_ mellem det lokale repo og GitHub-repoet. Lad os sende disse filer til GitHub med følgende kommando `git push`, som følger:
1. **Send lokale filer til GitHub**. Indtil videre har du oprettet en _forbindelse_ mellem det lokale repo og GitHub repoet. Lad os sende disse filer til GitHub med følgende kommando `git push`, som så:
> Bemærk, dit branch-navn kan være forskelligt som standard fra ```main```.
> Bemærk, dit branch-navn kan være anderledes som standard end ```main```.
```bash
git push -u origin main
```
Dette sender dine commits i din "main"-branch til GitHub.
Dette sender dine commits i din "main"-branch til GitHub. Ved at inkludere `-u` i kommandoen etableres en forbindelse mellem din lokale branch og den eksterne branch, så du fremover kan bruge git push eller git pull uden at specificere branch-navnet.
2. **Tilføj flere ændringer**. Hvis du vil fortsætte med at lave ændringer og sende dem til GitHub, skal du blot bruge følgende tre kommandoer:
@ -164,17 +164,17 @@ Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at
git push
```
> Tip: Du vil måske også adoptere en `.gitignore`-fil for at forhindre filer, du ikke ønsker at spore, i at dukke op på GitHub - som den notesfil, du gemmer i samme mappe, men som ikke hører hjemme i et offentligt repository. Du kan finde skabeloner til `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
> Tip, du vil måske også adoptere en `.gitignore`-fil for at forhindre filer, du ikke ønsker at spore, i at dukke op på GitHub - som den notesfil, du gemmer i samme mappe, men som ikke har nogen plads i et offentligt repository. Du kan finde skabeloner til `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
#### Commit-beskeder
En god Git commit-emnelinje fuldender følgende sætning:
Hvis anvendt, vil denne commit <dinemnelinjeher>
For emnet skal du bruge den bydeform, nutid: "ændrer" i stedet for "ændrede" eller "ændringer".
Som i emnet skal du også i brødteksten (valgfrit) bruge den bydeform, nutid. Brødteksten bør inkludere motivationen for ændringen og kontrastere dette med tidligere adfærd. Du forklarer `hvorfor`, ikke `hvordan`.
For emnet skal du bruge den imperativ, nutid: "ændre" i stedet for "ændrede" eller "ændringer".
Som i emnet skal du også i kroppen (valgfri) bruge den imperativ, nutid. Kroppen bør inkludere motivationen for ændringen og kontrastere dette med tidligere adfærd. Du forklarer `hvorfor`, ikke `hvordan`.
✅ Brug et par minutter på at surfe rundt på GitHub. Kan du finde en virkelig god commit-besked? Kan du finde en meget minimal én? Hvilken information synes du er den vigtigste og mest nyttige at formidle i en commit-besked?
✅ Tag et par minutter til at surfe rundt på GitHub. Kan du finde en virkelig god commit-besked? Kan du finde en virkelig minimal en? Hvilke oplysninger synes du er de vigtigste og mest nyttige at formidle i en commit-besked?
### Opgave: Samarbejd
@ -197,36 +197,36 @@ I dit repository skal du navigere til `Insights > Community` for at se, hvordan
Alle disse ressourcer vil gavne onboarding af nye teammedlemmer. Og det er typisk den slags ting, nye bidragydere kigger på, før de overhovedet ser på din kode, for at finde ud af, om dit projekt er det rette sted for dem at bruge deres tid.
✅ README-filer, selvom de tager tid at forberede, bliver ofte forsømt af travle vedligeholdere. Kan du finde et eksempel på en særlig beskrivende én? Bemærk: Der findes nogle [værktøjer til at hjælpe med at lave gode READMEs](https://www.makeareadme.com/), som du måske vil prøve.
✅ README-filer, selvom de tager tid at forberede, bliver ofte overset af travle vedligeholdere. Kan du finde et eksempel på en særlig beskrivende README? Bemærk: der findes nogle [værktøjer til at hjælpe med at lave gode READMEs](https://www.makeareadme.com/), som du måske vil prøve.
### Opgave: Flet noget kode
Bidragsdokumenter hjælper folk med at bidrage til projektet. De forklarer, hvilke typer bidrag du leder efter, og hvordan processen fungerer. Bidragydere skal gennemgå en række trin for at kunne bidrage til dit repo på GitHub:
Bidragsdokumenter hjælper folk med at bidrage til projektet. De forklarer, hvilke typer bidrag du leder efter, og hvordan processen fungerer. Bidragydere skal gennem en række trin for at kunne bidrage til dit repo på GitHub:
1. **Fork dit repo**. Du vil sandsynligvis have, at folk _forker_ dit projekt. At forke betyder at oprette en kopi af dit repository på deres GitHub-profil.
1. **Klon**. Derefter vil de klone projektet til deres lokale maskine.
1. **Fork dit repo**. Du vil sandsynligvis have, at folk _forker_ dit projekt. Forking betyder at oprette en kopi af dit repository på deres GitHub-profil.
1. **Clone**. Derfra vil de clone projektet til deres lokale maskine.
1. **Opret en branch**. Du vil bede dem om at oprette en _branch_ til deres arbejde.
1. **Fokuser deres ændring på ét område**. Bed bidragydere om at koncentrere deres bidrag om én ting ad gangen - på den måde er chancerne for, at du kan _flette_ deres arbejde, højere. Forestil dig, at de skriver en fejlrettelse, tilføjer en ny funktion og opdaterer flere tests - hvad nu hvis du kun vil eller kan implementere 2 ud af 3 eller 1 ud af 3 ændringer?
1. **Fokuser deres ændring på ét område**. Bed bidragydere om at koncentrere deres bidrag om én ting ad gangen - på den måde er chancerne for, at du kan _flette_ deres arbejde, højere. Forestil dig, at de skriver en fejlrettelse, tilføjer en ny funktion og opdaterer flere tests - hvad hvis du kun vil eller kan implementere 2 ud af 3 eller 1 ud af 3 ændringer?
✅ Forestil dig en situation, hvor branches er særligt kritiske for at skrive og levere god kode. Hvilke brugsscenarier kan du komme i tanke om?
✅ Forestil dig en situation, hvor branches er særligt kritiske for at skrive og levere god kode. Hvilke anvendelsesscenarier kan du komme i tanke om?
> Bemærk, vær den forandring, du ønsker at se i verden, og opret branches til dit eget arbejde også. Enhver commit, du laver, vil blive lavet på den branch, du i øjeblikket er "checket ud" til. Brug `git status` for at se, hvilken branch det er.
Lad os gennemgå en bidragyder-arbejdsgang. Antag, at bidragyderen allerede har _forket_ og _klonet_ repoet, så de har et Git-repo klar til at blive arbejdet på, på deres lokale maskine:
Lad os gennemgå en bidragsarbejdsgang. Antag, at bidragsyderen allerede har _forket_ og _clonet_ repoet, så de har et Git-repo klar til at blive arbejdet på, på deres lokale maskine:
1. **Opret en branch**. Brug kommandoen `git branch` til at oprette en branch, der vil indeholde de ændringer, de ønsker at bidrage med:
1. **Opret en branch**. Brug kommandoen `git branch` til at oprette en branch, der vil indeholde de ændringer, de har til hensigt at bidrage med:
```bash
git branch [branch-name]
```
1. **Skift til arbejdsbranch**. Skift til den specificerede branch og opdater arbejdsbiblioteket med `git switch`:
1. **Skift til arbejdsbranch**. Skift til den specificerede branch og opdater arbejdsmappen med `git switch`:
```bash
git switch [branch-name]
```
1. **Arbejd**. På dette tidspunkt vil du tilføje dine ændringer. Glem ikke at fortælle Git om det med følgende kommandoer:
1. **Arbejd på projektet**. På dette tidspunkt vil du tilføje dine ændringer. Glem ikke at fortælle Git om det med følgende kommandoer:
```bash
git add .
@ -235,7 +235,7 @@ Lad os gennemgå en bidragyder-arbejdsgang. Antag, at bidragyderen allerede har
Sørg for at give din commit et godt navn, for din egen skyld såvel som for vedligeholderen af det repo, du hjælper med.
1. **Kombiner dit arbejde med `main`-branchen**. På et tidspunkt er du færdig med at arbejde, og du vil kombinere dit arbejde med det i `main`-branchen. `Main`-branchen kan have ændret sig i mellemtiden, så sørg for først at opdatere den til den nyeste version med følgende kommandoer:
1. **Kombiner dit arbejde med `main`-branchen**. På et tidspunkt er du færdig med at arbejde, og du vil kombinere dit arbejde med det i `main`-branchen. `main`-branchen kan have ændret sig i mellemtiden, så sørg for først at opdatere den til det nyeste med følgende kommandoer:
```bash
git switch main
@ -249,38 +249,43 @@ Lad os gennemgå en bidragyder-arbejdsgang. Antag, at bidragyderen allerede har
git merge main
```
Dette vil bringe alle ændringer fra `main` ind i din branch, og forhåbentlig kan du bare fortsætte. Hvis ikke, vil VS Code fortælle dig, hvor Git er _forvirret_, og du ændrer blot de berørte filer for at angive, hvilket indhold der er mest korrekt.
Kommandoen `git merge main` vil bringe alle ændringer fra `main` ind i din branch. Forhåbentlig kan du bare fortsætte. Hvis ikke, vil VS Code fortælle dig, hvor Git er _forvirret_, og du skal blot ændre de berørte filer for at angive, hvilket indhold der er mest korrekt.
For at skifte til en anden branch skal du bruge den moderne `git switch`-kommando:
```bash
git switch [branch_name]
1. **Send dit arbejde til GitHub**. At sende dit arbejde til GitHub betyder to ting. At pushe din branch til dit repo og derefter åbne en PR, Pull Request.
1. **Send dit arbejde til GitHub**. At sende dit arbejde til GitHub betyder to ting: at pushe din branch til dit repo og derefter åbne en PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Kommandoen ovenfor opretter branchen på dit forkede repo.
1. **Åbn en PR**. Dernæst vil du åbne en PR. Det gør du ved at navigere til det forkede repo på GitHub. Du vil se en indikation på GitHub, hvor det spørger, om du vil oprette en ny PR. Klik på det, og du bliver ført til en grænseflade, hvor du kan ændre commit-beskedens titel og give den en mere passende beskrivelse. Nu vil vedligeholderen af det repo, du forkede, se denne PR, og _fingrene krydsede_, de vil sætte pris på og _flette_ din PR. Du er nu en bidragyder, yay :)
Den ovenstående kommando opretter branchen på dit forkede repo.
1. **Åbn en PR**. Næste skridt er at åbne en PR. Det gør du ved at navigere til den forkede repo på GitHub. Du vil se en indikation på GitHub, hvor der spørges, om du vil oprette en ny PR. Klik på det, og du bliver ført til en grænseflade, hvor du kan ændre commit-beskedens titel og give en mere passende beskrivelse. Nu vil vedligeholderen af det repo, du har forket, se denne PR, og _krydser fingre_ de vil sætte pris på og _merge_ din PR. Du er nu en bidragyder, yay :)
1. **Ryd op**. Det anses for god praksis at _rydde op_, efter du har fået succes med at flette en PR. Du vil rydde op i både din lokale branch og den branch, du pushede til GitHub. Først skal du slette den lokalt med følgende kommando:
1. **Ryd op**. Det anses som god praksis at _rydde op_, efter du har fået en PR succesfuldt merged. Du vil gerne rydde op både i din lokale branch og den branch, du har skubbet til GitHub. Først skal vi slette den lokalt med følgende kommando:
```bash
git branch -d [branch-name]
```
Sørg for at gå til GitHub-siden for det forkede repo og fjerne den remote branch, du lige har pushet til.
`Pull request` virker som et fjollet udtryk, fordi du egentlig ønsker at skubbe dine ændringer til projektet. Men vedligeholderen (projektets ejer) eller kerneholdet skal overveje dine ændringer, før de bliver flettet med projektets "main"-gren, så du anmoder faktisk om en beslutning om ændringen fra en vedligeholder.
Sørg for at gå til GitHub-siden for det forkede repo og fjerne den fjernbranch, du lige har skubbet til.
`Pull request` virker som et fjollet udtryk, fordi du egentlig vil skubbe dine ændringer til projektet. Men vedligeholderen (projektets ejer) eller kerneholdet skal overveje dine ændringer, før de merges med projektets "main"-branch, så du anmoder faktisk om en beslutning om ændringer fra en vedligeholder.
En pull request er stedet, hvor man sammenligner og diskuterer forskellene, der er introduceret på en gren, med anmeldelser, kommentarer, integrerede tests og mere. En god pull request følger nogenlunde de samme regler som en commit-besked. Du kan tilføje en reference til et issue i issue tracker, når dit arbejde for eksempel løser et problem. Dette gøres ved at bruge et `#` efterfulgt af nummeret på dit issue. For eksempel `#97`.
En pull request er stedet, hvor man kan sammenligne og diskutere forskellene, der er introduceret på en branch, med anmeldelser, kommentarer, integrerede tests og mere. En god pull request følger nogenlunde de samme regler som en commit-besked. Du kan tilføje en reference til et issue i issue tracker, når dit arbejde for eksempel løser et problem. Dette gøres ved at bruge et `#` efterfulgt af nummeret på dit issue. For eksempel `#97`.
🤞Kryds fingre for, at alle checks går igennem, og projektets ejer(e) fletter dine ændringer ind i projektet🤞
🤞Krydser fingre for, at alle checks går igennem, og projektets ejer(e) merger dine ændringer ind i projektet🤞
Opdater din nuværende lokale arbejdsgren med alle nye commits fra den tilsvarende fjern-gren på GitHub:
Opdater din nuværende lokale arbejdsbranch med alle nye commits fra den tilsvarende fjernbranch på GitHub:
`git pull`
## Sådan bidrager du til open source
## Hvordan bidrager man til open source
Lad os først finde et repository (eller **repo**) på GitHub, som interesserer dig, og som du gerne vil bidrage med en ændring til. Du vil gerne kopiere dets indhold til din maskine.
Først skal vi finde et repository (eller **repo**) på GitHub, som interesserer dig, og som du gerne vil bidrage med en ændring til. Du vil gerne kopiere dets indhold til din maskine.
✅ En god måde at finde 'begynder-venlige' repos er at [søge efter tagget 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
@ -300,9 +305,9 @@ Til sidst kan du downloade koden i en zippet mappe.
### Et par flere interessante ting om GitHub
Du kan stjerne, overvåge og/eller "forke" ethvert offentligt repository på GitHub. Du kan finde dine stjernemarkerede repositories i drop-down-menuen øverst til højre. Det er som bogmærker, men for kode.
Du kan stjerne, følge og/eller "forke" ethvert offentligt repository på GitHub. Du kan finde dine stjernemarkerede repositories i drop-down-menuen øverst til højre. Det er som at bogmærke, men for kode.
Projekter har en issue tracker, som oftest findes på GitHub under fanen "Issues", medmindre andet er angivet, hvor folk diskuterer problemer relateret til projektet. Og fanen Pull Requests er, hvor folk diskuterer og gennemgår ændringer, der er undervejs.
Projekter har en issue tracker, som oftest på GitHub under fanen "Issues", medmindre andet er angivet, hvor folk diskuterer problemer relateret til projektet. Og fanen Pull Requests er, hvor folk diskuterer og gennemgår ændringer, der er undervejs.
Projekter kan også have diskussioner i fora, mailinglister eller chatkanaler som Slack, Discord eller IRC.
@ -312,7 +317,7 @@ Projekter kan også have diskussioner i fora, mailinglister eller chatkanaler so
## 🚀 Udfordring
Samarbejd med en ven om hinandens kode. Opret et projekt sammen, fork kode, opret grene og flet ændringer.
Samarbejd med en ven om at arbejde på hinandens kode. Opret et projekt sammen, fork kode, opret branches og merge ændringer.
## Quiz efter forelæsning
[Quiz efter forelæsning](https://ff-quizzes.netlify.app/web/en/)
@ -323,7 +328,7 @@ Læs mere om [at bidrage til open source software](https://opensource.guide/how-
Øv dig, øv dig, øv dig. GitHub har fantastiske læringsforløb tilgængelige via [skills.github.com](https://skills.github.com):
Øv, øv, øv. GitHub har fantastiske læringsforløb tilgængelige via [skills.github.com](https://skills.github.com):
- [Første uge på GitHub](https://skills.github.com/#first-week-on-github)
@ -336,4 +341,4 @@ Gennemfør [kurset Første uge på GitHub](https://skills.github.com/#first-week
---
**Ansvarsfraskrivelse**:
Dette dokument er blevet oversat ved hjælp af AI-oversættelsestjenesten [Co-op Translator](https://github.com/Azure/co-op-translator). Selvom vi bestræber os på at sikre nøjagtighed, skal du være opmærksom på, at automatiserede oversættelser kan indeholde fejl eller unøjagtigheder. Det originale dokument på dets oprindelige sprog bør betragtes som den autoritative kilde. For kritisk information anbefales professionel menneskelig oversættelse. Vi påtager os intet ansvar for misforståelser eller fejltolkninger, der måtte opstå som følge af brugen af denne oversættelse.
Dette dokument er blevet oversat ved hjælp af AI-oversættelsestjenesten [Co-op Translator](https://github.com/Azure/co-op-translator). Selvom vi bestræber os på at opnå nøjagtighed, skal det bemærkes, at automatiserede oversættelser kan indeholde fejl eller unøjagtigheder. Det originale dokument på dets oprindelige sprog bør betragtes som den autoritative kilde. For kritisk information anbefales professionel menneskelig oversættelse. Vi påtager os ikke ansvar for eventuelle misforståelser eller fejltolkninger, der måtte opstå som følge af brugen af denne oversættelse.
@ -21,7 +21,7 @@ Diese Lektion behandelt die Grundlagen von GitHub, einer Plattform zum Hosten un
In dieser Lektion behandeln wir:
- das Nachverfolgen der Arbeit, die du auf deinem Rechner erledigst
- das Nachverfolgen der Arbeit, die du auf deinem Rechner machst
- das Arbeiten an Projekten mit anderen
- wie man zu Open-Source-Software beiträgt
@ -37,34 +37,34 @@ Falls Git nicht installiert ist, [lade Git herunter](https://git-scm.com/downloa
Um zu überprüfen, ob Git bereits konfiguriert ist, kannst du eingeben:
`git config --list`
Du benötigst außerdem ein GitHub-Konto, einen Code-Editor (wie Visual Studio Code) und musst dein Terminal (oder die Eingabeaufforderung) öffnen.
Du benötigst außerdem ein GitHub-Konto, einen Code-Editor (wie Visual Studio Code) und musst dein Terminal (oder: Eingabeaufforderung) öffnen.
Gehe zu [github.com](https://github.com/) und erstelle ein Konto, falls du noch keines hast, oder melde dich an und vervollständige dein Profil.
Navigiere zu [github.com](https://github.com/) und erstelle ein Konto, falls du noch keines hast, oder melde dich an und fülle dein Profil aus.
✅ GitHub ist nicht das einzige Code-Repository der Welt; es gibt auch andere, aber GitHub ist das bekannteste.
✅ GitHub ist nicht das einzige Code-Repository der Welt; es gibt andere, aber GitHub ist das bekannteste.
### Vorbereitung
Du benötigst sowohl einen Ordner mit einem Code-Projekt auf deinem lokalen Rechner (Laptop oder PC) als auch ein öffentliches Repository auf GitHub, das als Beispiel dafür dient, wie man zu den Projekten anderer beiträgt.
Du benötigst sowohl einen Ordner mit einem Codeprojekt auf deinem lokalen Rechner (Laptop oder PC) als auch ein öffentliches Repository auf GitHub, das als Beispiel dafür dient, wie man zu den Projekten anderer beiträgt.
---
## Code-Verwaltung
## Codeverwaltung
Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest deinen Fortschritt mit Git, dem Versionskontrollsystem, nachverfolgen. Manche Leute vergleichen die Nutzung von Git mit dem Schreiben eines Liebesbriefs an dein zukünftiges Ich. Wenn du deine Commit-Nachrichten Tage, Wochen oder Monate später liest, kannst du dich daran erinnern, warum du eine Entscheidung getroffen hast, oder eine Änderung "rückgängig machen" – vorausgesetzt, du schreibst gute "Commit-Nachrichten".
Angenommen, du hast einen Ordner lokal mit einem Codeprojekt und möchtest deinen Fortschritt mit Git, dem Versionskontrollsystem, nachverfolgen. Manche Leute vergleichen die Nutzung von Git mit dem Schreiben eines Liebesbriefs an dein zukünftiges Ich. Wenn du deine Commit-Nachrichten Tage, Wochen oder Monate später liest, kannst du dich daran erinnern, warum du eine Entscheidung getroffen hast, oder eine Änderung "rückgängig machen" – vorausgesetzt, du schreibst gute "Commit-Nachrichten".
### Aufgabe: Ein Repository erstellen und Code committen
> Schau dir das Video an
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Repository auf GitHub erstellen**. Auf GitHub.com findest du im Reiter "Repositories" oder in der oberen Navigationsleiste die Schaltfläche **new repo**.
1. **Repository auf GitHub erstellen**. Auf GitHub.com, im Reiter "Repositories" oder in der Navigationsleiste oben rechts, finde den Button **neues Repository**.
1. Gib deinem Repository (Ordner) einen Namen.
1. Wähle **create repository**.
1. Wähle **Repository erstellen**.
1. **Zu deinem Arbeitsordner navigieren**. Wechsle im Terminal zu dem Ordner (auch Verzeichnis genannt), den du nachverfolgen möchtest. Gib ein:
1. **Zu deinem Arbeitsordner navigieren**. Wechsle in deinem Terminal zu dem Ordner (auch als Verzeichnis bekannt), den du nachverfolgen möchtest. Gib ein:
```bash
cd [name of your folder]
@ -76,7 +76,7 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
git init
```
1. **Status überprüfen**. Um den Status deines Repositories zu überprüfen, gib ein:
1. **Status überprüfen**. Um den Status deines Repositorys zu überprüfen, gib ein:
```bash
git status
@ -93,16 +93,16 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
modified: file2.txt
```
Normalerweise zeigt der Befehl `git status` Dinge wie Dateien, die bereit sind, im Repository _gespeichert_ zu werden, oder Änderungen, die du möglicherweise beibehalten möchtest.
Normalerweise zeigt dir der Befehl `git status` Dinge wie, welche Dateien bereit sind, im Repository _gespeichert_ zu werden, oder welche Änderungen darauf vorgenommen wurden, die du möglicherweise beibehalten möchtest.
1. **Alle Dateien zum Nachverfolgen hinzufügen**
Dies wird auch als Staging von Dateien oder Hinzufügen von Dateien zum Staging-Bereich bezeichnet.
Dies wird auch als "Staging" von Dateien oder das Hinzufügen von Dateien zum Staging-Bereich bezeichnet.
```bash
git add .
```
Das `git add` mit dem Argument `.` bedeutet, dass alle deine Dateien und Änderungen nachverfolgt werden.
Das Argument `git add` plus `.` zeigt an, dass alle deine Dateien und Änderungen nachverfolgt werden sollen.
1. **Ausgewählte Dateien zum Nachverfolgen hinzufügen**
@ -110,7 +110,7 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
git add [file or folder name]
```
Dies ermöglicht es uns, nur ausgewählte Dateien zum Staging-Bereich hinzuzufügen, wenn wir nicht alle Dateien auf einmal committen möchten.
Dies hilft uns, nur ausgewählte Dateien zum Staging-Bereich hinzuzufügen, wenn wir nicht alle Dateien auf einmal committen möchten.
1. **Alle Dateien aus dem Staging-Bereich entfernen**
@ -128,15 +128,15 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
Dieser Befehl hilft uns, nur eine bestimmte Datei aus dem Staging-Bereich zu entfernen, die wir nicht für den nächsten Commit einbeziehen möchten.
1. **Deine Arbeit speichern**. An diesem Punkt hast du die Dateien in einen sogenannten _Staging-Bereich_ hinzugefügt, einen Ort, an dem Git deine Dateien nachverfolgt. Um die Änderung dauerhaft zu machen, musst du die Dateien _committen_. Dazu erstellst du einen _Commit_ mit dem Befehl `git commit`. Ein _Commit_ stellt einen Speicherpunkt in der Historie deines Repositories dar. Gib Folgendes ein, um einen _Commit_ zu erstellen:
1. **Deine Arbeit speichern**. An diesem Punkt hast du die Dateien in einen sogenannten _Staging-Bereich_ hinzugefügt, einen Ort, an dem Git deine Dateien nachverfolgt. Um die Änderung dauerhaft zu machen, musst du die Dateien _committen_. Dazu erstellst du einen _Commit_ mit dem Befehl `git commit`. Ein _Commit_ stellt einen Speicherpunkt in der Historie deines Repositorys dar. Gib Folgendes ein, um einen _Commit_ zu erstellen:
```bash
git commit -m "first commit"
```
Dies commitet alle deine Dateien und fügt die Nachricht "first commit" hinzu. Für zukünftige Commit-Nachrichten solltest du eine genauere Beschreibung verwenden, um zu vermitteln, welche Art von Änderung du vorgenommen hast.
Dies commitet alle deine Dateien und fügt die Nachricht "erster Commit" hinzu. Für zukünftige Commit-Nachrichten solltest du eine detailliertere Beschreibung verwenden, um zu vermitteln, welche Art von Änderung du vorgenommen hast.
1. **Dein lokales Git-Repository mit GitHub verbinden**. Ein Git-Repository ist auf deinem Rechner nützlich, aber irgendwann möchtest du ein Backup deiner Dateien an einem anderen Ort haben und auch andere Leute einladen, mit dir an deinem Repository zu arbeiten. Ein großartiger Ort dafür ist GitHub. Wir haben bereits ein Repository auf GitHub erstellt, daher müssen wir nur noch unser lokales Git-Repository mit GitHub verbinden. Der Befehl `git remote add` erledigt genau das. Gib den folgenden Befehl ein:
1. **Dein lokales Git-Repository mit GitHub verbinden**. Ein Git-Repository ist auf deinem Rechner nützlich, aber irgendwann möchtest du ein Backup deiner Dateien irgendwo haben und andere Leute einladen, mit dir an deinem Repository zu arbeiten. Ein großartiger Ort dafür ist GitHub. Wir haben bereits ein Repository auf GitHub erstellt, daher müssen wir nur unser lokales Git-Repository mit GitHub verbinden. Der Befehl `git remote add` erledigt genau das. Gib den folgenden Befehl ein:
> Hinweis: Bevor du den Befehl eingibst, gehe zu deiner GitHub-Repository-Seite, um die Repository-URL zu finden. Du wirst sie im folgenden Befehl verwenden. Ersetze ```https://github.com/username/repository_name.git``` durch deine GitHub-URL.
@ -144,19 +144,19 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
Dies erstellt eine _Remote-Verbindung_ namens "origin", die auf das zuvor erstellte GitHub-Repository zeigt.
Dies erstellt eine _Remote-Verbindung_, genannt "origin", die auf das GitHub-Repository zeigt, das du zuvor erstellt hast.
1. **Lokale Dateien zu GitHub senden**. Bisher hast du eine _Verbindung_ zwischen dem lokalen Repository und dem GitHub-Repository erstellt. Lass uns diese Dateien mit dem folgenden Befehl `git push` zu GitHub senden:
> Hinweis: Dein Branch-Name könnte standardmäßig anders sein als ```main```.
1. **Lokale Dateien an GitHub senden**. Bisher hast du eine _Verbindung_ zwischen dem lokalen Repository und dem GitHub-Repository hergestellt. Senden wir diese Dateien an GitHub mit dem folgenden Befehl `git push`, wie folgt:
> Hinweis: Dein Branch-Name könnte standardmäßig anders als ```main``` sein.
```bash
git push -u origin main
```
Dies sendet deine Commits im "main"-Branch zu GitHub.
Dies sendet deine Commits in deinem "main"-Branch an GitHub. Das Festlegen des `upstream`-Branches einschließlich `-u` im Befehl stellt eine Verbindung zwischen deinem lokalen Branch und dem Remote-Branch her, sodass du in Zukunft einfach `git push` oder `git pull` verwenden kannst, ohne den Branch-Namen anzugeben. Git wird automatisch den `upstream`-Branch verwenden, und du musst den Branch-Namen in zukünftigen Befehlen nicht explizit angeben.
2. **Weitere Änderungen hinzufügen**. Wenn du weiterhin Änderungen vornehmen und sie zu GitHub pushen möchtest, musst du nur die folgenden drei Befehle verwenden:
2. **Weitere Änderungen hinzufügen**. Wenn du weiterhin Änderungen vornehmen und diese an GitHub senden möchtest, musst du nur die folgenden drei Befehle verwenden:
```bash
git add .
@ -164,55 +164,55 @@ Angenommen, du hast lokal einen Ordner mit einem Code-Projekt und möchtest dein
git push
```
> Tipp: Du möchtest vielleicht auch eine `.gitignore`-Datei verwenden, um zu verhindern, dass Dateien, die du nicht nachverfolgen möchtest, auf GitHub erscheinen – wie z. B. eine Notizdatei, die du im selben Ordner speicherst, die aber nichts in einem öffentlichen Repository zu suchen hat. Vorlagen für `.gitignore`-Dateien findest du unter [.gitignore templates](https://github.com/github/gitignore).
> Tipp: Du möchtest möglicherweise auch eine `.gitignore`-Datei verwenden, um zu verhindern, dass Dateien, die du nicht nachverfolgen möchtest, auf GitHub angezeigt werden – wie die Notizdatei, die du im selben Ordner speicherst, die aber keinen Platz in einem öffentlichen Repository hat. Du kannst Vorlagen für `.gitignore`-Dateien unter [.gitignore templates](https://github.com/github/gitignore) finden.
#### Commit-Nachrichten
Eine großartige Git-Commit-Betreffzeile vervollständigt den folgenden Satz:
Wenn angewendet, wird dieser Commit <deineBetreffzeilehier>.
Wenn angewendet, wird dieser Commit <deineBetreffzeilehier>
Für den Betreff verwende die Befehlsform im Präsens: "ändern" statt "geändert" oder "ändert".
Wie im Betreff sollte auch im optionalen Textkörper die Befehlsform im Präsens verwendet werden. Der Textkörper sollte die Motivation für die Änderung enthalten und diese mit dem vorherigen Verhalten kontrastieren. Du erklärst das `Warum`, nicht das `Wie`.
Für den Betreff verwende die imperative Gegenwartsform: "ändern" statt "geändert" oder "ändert".
Wie im Betreff, verwende auch im optionalen Textkörper die imperative Gegenwartsform. Der Textkörper sollte die Motivation für die Änderung enthalten und diese mit dem vorherigen Verhalten kontrastieren. Du erklärst das `Warum`, nicht das `Wie`.
✅ Nimm dir ein paar Minuten Zeit, um auf GitHub zu stöbern. Kannst du eine wirklich großartige Commit-Nachricht finden? Kannst du eine sehr minimale finden? Welche Informationen hältst du für die wichtigsten und nützlichsten, die in einer Commit-Nachricht vermittelt werden sollten?
✅ Nimm dir ein paar Minuten Zeit, um auf GitHub zu surfen. Kannst du eine wirklich großartige Commit-Nachricht finden? Kannst du eine sehr minimalistische finden? Welche Informationen denkst du, sind am wichtigsten und nützlich, um in einer Commit-Nachricht vermittelt zu werden?
### Aufgabe: Zusammenarbeit
Der Hauptgrund, Dinge auf GitHub zu stellen, ist die Möglichkeit, mit anderen Entwicklern zusammenzuarbeiten.
Der Hauptgrund, Dinge auf GitHub zu stellen, war, die Zusammenarbeit mit anderen Entwicklern zu ermöglichen.
## Zusammenarbeit an Projekten mit anderen
## Arbeiten an Projekten mit anderen
> Schau dir das Video an
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
In deinem Repository navigiere zu `Insights > Community`, um zu sehen, wie dein Projekt im Vergleich zu den empfohlenen Community-Standards abschneidet.
Hier sind einige Dinge, die dein GitHub-Repository verbessern können:
- **Beschreibung**. Hast du eine Beschreibung für dein Projekt hinzugefügt?
- **README**. Hast du ein README hinzugefügt? GitHub bietet Anleitungen zum Schreiben eines [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Beitragsrichtlinien**. Hat dein Projekt [Beitragsrichtlinien](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Verhaltenskodex**. Einen [Verhaltenskodex](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Lizenz**. Vielleicht am wichtigsten: eine [Lizenz](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Richtlinien für Beiträge**. Hat dein Projekt [Richtlinien für Beiträge](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Verhaltenskodex**. Einen [Verhaltenskodex](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Lizenz**. Vielleicht am wichtigsten, eine [Lizenz](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
All diese Ressourcen helfen dabei, neue Teammitglieder einzuarbeiten. Und das sind typischerweise die Dinge, die neue Mitwirkende sich ansehen, bevor sie überhaupt deinen Code betrachten, um herauszufinden, ob dein Projekt der richtige Ort für sie ist, um ihre Zeit zu investieren.
All diese Ressourcen werden neuen Teammitgliedern beim Einstieg helfen. Und das sind typischerweise die Dinge, die neue Mitwirkende sich ansehen, bevor sie überhaupt deinen Code betrachten, um herauszufinden, ob dein Projekt der richtige Ort für sie ist, um ihre Zeit zu investieren.
✅ README-Dateien werden oft von beschäftigten Maintainer:innen vernachlässigt, obwohl sie Zeit in Anspruch nehmen, um sie vorzubereiten. Kannst du ein Beispiel für ein besonders aussagekräftiges README finden? Hinweis: Es gibt einige [Tools, um gute READMEs zu erstellen](https://www.makeareadme.com/), die du ausprobieren könntest.
✅ README-Dateien, obwohl sie Zeit in Anspruch nehmen, werden oft von beschäftigten Maintainer vernachlässigt. Kannst du ein Beispiel für eine besonders beschreibende README-Datei finden? Hinweis: Es gibt einige [Tools, um gute READMEs zu erstellen](https://www.makeareadme.com/), die du ausprobieren könntest.
### Aufgabe: Code zusammenführen
Beitragsdokumente helfen Menschen, zum Projekt beizutragen. Sie erklären, welche Arten von Beiträgen du suchst und wie der Prozess funktioniert. Mitwirkende müssen eine Reihe von Schritten durchlaufen, um zu deinem Repository auf GitHub beitragen zu können:
1. **Dein Repository forken**. Du wirst wahrscheinlich möchten, dass Leute dein Projekt _forken_. Forken bedeutet, eine Kopie deines Repositories in ihrem GitHub-Profil zu erstellen.
1. **Klonen**. Von dort aus klonen sie das Projekt auf ihren lokalen Rechner.
1. **Dein Repository forken**. Du wirst wahrscheinlich möchten, dass Leute dein Projekt _forken_. Forken bedeutet, eine Kopie deines Repositorys auf ihrem GitHub-Profil zu erstellen.
1. **Klonen**. Von dort aus werden sie das Projekt auf ihren lokalen Rechner klonen.
1. **Einen Branch erstellen**. Du wirst sie bitten, einen _Branch_ für ihre Arbeit zu erstellen.
1. **Änderungen auf einen Bereich konzentrieren**. Bitte Mitwirkende, ihre Beiträge auf eine Sache gleichzeitig zu konzentrieren – so ist die Wahrscheinlichkeit höher, dass du ihre Arbeit _zusammenführen_ kannst. Stell dir vor, sie schreiben einen Bugfix, fügen ein neues Feature hinzu und aktualisieren mehrere Tests – was, wenn du nur 2 von 3 oder 1 von 3 Änderungen implementieren möchtest oder kannst?
1. **Änderungen auf einen Bereich konzentrieren**. Bitte Mitwirkende, ihre Beiträge auf eine Sache gleichzeitig zu konzentrieren – so ist die Wahrscheinlichkeit höher, dass du ihre Arbeit _zusammenführen_ kannst. Stell dir vor, sie schreiben einen Bugfix, fügen eine neue Funktion hinzu und aktualisieren mehrere Tests – was, wenn du nur 2 von 3 oder 1 von 3 Änderungen implementieren möchtest oder kannst?
✅ Überlege dir eine Situation, in der Branches besonders wichtig sind, um guten Code zu schreiben und zu veröffentlichen. Welche Anwendungsfälle fallen dir ein?
✅ Stell dir eine Situation vor, in der Branches besonders wichtig sind, um guten Code zu schreiben und zu veröffentlichen. Welche Anwendungsfälle fallen dir ein?
> Hinweis: Sei die Veränderung, die du in der Welt sehen möchtest, und erstelle auch für deine eigene Arbeit Branches. Alle Commits, die du machst, werden auf dem Branch gemacht, auf dem du dich gerade befindest. Verwende `git status`, um zu sehen, auf welchem Branch du dich befindest.
> Hinweis: Sei die Veränderung, die du in der Welt sehen möchtest, und erstelle auch Branches für deine eigene Arbeit. Alle Commits, die du machst, werden auf dem Branch gemacht, auf dem du gerade "ausgecheckt" bist. Verwende `git status`, um zu sehen, welcher Branch das ist.
Gehen wir den Workflow eines Mitwirkenden durch. Angenommen, der Mitwirkende hat das Repository bereits _geforkt_ und _geklont_, sodass er ein Git-Repository hat, das auf seinem lokalen Rechner bereit ist:
Gehen wir einen Workflow für Mitwirkende durch. Angenommen, der Mitwirkende hat das Repository bereits _geforkt_ und _geklont_, sodass er ein Git-Repository hat, das auf seinem lokalen Rechner bereit ist, bearbeitet zu werden:
1. **Einen Branch erstellen**. Verwende den Befehl `git branch`, um einen Branch zu erstellen, der die Änderungen enthält, die sie beitragen möchten:
@ -220,7 +220,7 @@ Gehen wir den Workflow eines Mitwirkenden durch. Angenommen, der Mitwirkende hat
git branch [branch-name]
```
1. **Zum Arbeits-Branch wechseln**. Wechsle zum angegebenen Branch und aktualisiere das Arbeitsverzeichnis mit `git switch`:
1. **Zum Arbeitsbranch wechseln**. Wechsle zum angegebenen Branch und aktualisiere das Arbeitsverzeichnis mit `git switch`:
```bash
git switch [branch-name]
@ -233,60 +233,65 @@ Gehen wir den Workflow eines Mitwirkenden durch. Angenommen, der Mitwirkende hat
git commit -m "my changes"
```
Stelle sicher, dass du deinem Commit einen guten Namen gibst– für dich selbst und für den Maintainer des Repositories, zu dem du beiträgst.
Stelle sicher, dass du deinem Commit einen guten Namen gibst, sowohl für dich als auch für den Maintainer des Repositorys, dem du hilfst.
1. **Deine Arbeit mit dem `main`-Branch kombinieren**. Irgendwann bist du mit deiner Arbeit fertig und möchtest sie mit der des `main`-Branches kombinieren. Der `main`-Branch könnte sich inzwischen geändert haben, also stelle sicher, dass du ihn zuerst mit den neuesten Änderungen aktualisierst, indem du die folgenden Befehle verwendest:
1. **Deine Arbeit mit dem `main`-Branch kombinieren**. Irgendwann bist du mit deiner Arbeit fertig und möchtest deine Arbeit mit der des `main`-Branches kombinieren. Der `main`-Branch könnte sich inzwischen geändert haben, also stelle sicher, dass du ihn zuerst auf den neuesten Stand bringst, mit den folgenden Befehlen:
```bash
git switch main
git pull
```
An diesem Punkt möchtest du sicherstellen, dass alle _Konflikte_, Situationen, in denen Git die Änderungen nicht einfach _kombinieren_ kann, in deinem Arbeits-Branch auftreten. Führe daher die folgenden Befehle aus:
An diesem Punkt möchtest du sicherstellen, dass alle _Konflikte_, Situationen, in denen Git die Änderungen nicht einfach _kombinieren_ kann, in deinem Arbeitsbranch auftreten. Führe daher die folgenden Befehle aus:
```bash
git switch [branch_name]
git merge main
```
Dies bringt alle Änderungen von `main` in deinen Branch, und hoffentlich kannst du einfach weitermachen. Falls nicht, zeigt dir VS Code, wo Git _verwirrt_ ist, und du änderst die betroffenen Dateien, um anzugeben, welcher Inhalt am genauesten ist.
Der Befehl `git merge main` bringt alle Änderungen von `main` in deinen Branch. Hoffentlich kannst du einfach weitermachen. Falls nicht, wird dir VS Code zeigen, wo Git _verwirrt_ ist, und du änderst die betroffenen Dateien, um anzugeben, welcher Inhalt am genauesten ist.
Um zu einem anderen Branch zu wechseln, verwende den modernen Befehl `git switch`:
```bash
git switch [branch_name]
1. **Deine Arbeit zu GitHub senden**. Deine Arbeit zu GitHub zu senden bedeutet zwei Dinge: Deinen Branch in dein Repository pushen und dann einen PR (Pull Request) öffnen.
1. **Deine Arbeit an GitHub senden**. Deine Arbeit an GitHub zu senden bedeutet zwei Dinge: Deinen Branch an dein Repository zu pushen und dann einen PR (Pull Request) zu öffnen.
```bash
git push --set-upstream origin [branch-name]
```
Der obige Befehl erstellt den Branch in deinem geforkten Repository.
1. **Einen PR öffnen**. Als Nächstes möchtest du einen PR öffnen. Dazu navigierst du zum geforkten Repository auf GitHub. Dort siehst du eine Anzeige, die dich fragt, ob du einen neuen PR erstellen möchtest. Du klickst darauf und gelangst zu einer Oberfläche, in der du den Titel der Commit-Nachricht ändern und eine passendere Beschreibung hinzufügen kannst. Nun sieht der Maintainer des Repos, das du geforkt hast, diesen PR und _Daumen drücken_, dass er deinen PR schätzt und _merged_. Du bist jetzt ein Contributor, yay :)
1. **Einen PR öffnen**. Als Nächstes möchtest du einen PR öffnen. Das machst du, indem du zu deinem geforkten Repository auf GitHub navigierst. Du wirst auf GitHub eine Anzeige sehen, die fragt, ob du einen neuen PR erstellen möchtest. Klicke darauf, und du wirst zu einer Oberfläche weitergeleitet, in der du den Commit-Nachrichtentitel ändern und eine passendere Beschreibung hinzufügen kannst. Nun sieht der Maintainer des Repositories, das du geforkt hast, diesen PR, und _Daumen drücken_, sie werden ihn schätzen und _zusammenführen_. Du bist jetzt ein Mitwirkender, yay :)
1. **Aufräumen**. Es gilt als gute Praxis, nach einem erfolgreich zusammengeführten PR aufzuräumen. Du möchtest sowohl deinen lokalen Branch als auch den Branch, den du zu GitHub gepusht hast, bereinigen. Lösche ihn zuerst lokal mit dem folgenden Befehl:
1. **Aufräumen**. Es gilt als gute Praxis, nach dem erfolgreichen Mergen eines PRs _aufzuräumen_. Du solltest sowohl deinen lokalen Branch als auch den Branch, den du zu GitHub gepusht hast, bereinigen. Lösche ihn zunächst lokal mit folgendem Befehl:
```bash
git branch -d [branch-name]
```
Stelle sicher, dass du als Nächstes zur GitHub-Seite des geforkten Repositories gehst und den Remote-Branch entfernst, den du gerade dorthin gepusht hast.
`Pull request` scheint ein seltsamer Begriff zu sein, da man eigentlich seine Änderungen in das Projekt "pushen" möchte. Aber der Maintainer (Projektbesitzer) oder das Kernteam muss deine Änderungen prüfen, bevor sie mit dem "main"-Branch des Projekts zusammengeführt werden. Du bittest also eigentlich um eine Entscheidungsfindung des Maintainers bezüglich deiner Änderungen.
Gehe anschließend zur GitHub-Seite des geforkten Repos und entferne den Remote-Branch, den du gerade gepusht hast.
`Pull request` scheint ein seltsamer Begriff zu sein, da du eigentlich deine Änderungen in das Projekt pushen möchtest. Aber der Maintainer (Projektbesitzer) oder das Kernteam muss deine Änderungen prüfen, bevor sie mit dem "main"-Branch des Projekts zusammengeführt werden. Du bittest also tatsächlich um eine Entscheidung über die Änderung von einem Maintainer.
Ein Pull Request ist der Ort, an dem man die Unterschiede, die auf einem Branch eingeführt wurden, vergleichen und diskutieren kann – mit Reviews, Kommentaren, integrierten Tests und mehr. Ein guter Pull Request folgt ungefähr den gleichen Regeln wie eine Commit-Nachricht. Du kannst einen Verweis auf ein Issue im Issue-Tracker hinzufügen, wenn deine Arbeit beispielsweise ein Problem löst. Dies geschieht mit einem `#`, gefolgt von der Nummer des Issues. Zum Beispiel `#97`.
Ein Pull Request ist der Ort, an dem die Unterschiede, die auf einem Branch eingeführt wurden, verglichen und diskutiert werden können – mit Reviews, Kommentaren, integrierten Tests und mehr. Ein guter Pull Request folgt ungefähr denselben Regeln wie eine Commit-Nachricht. Du kannst auf ein Issue im Issue-Tracker verweisen, wenn deine Arbeit beispielsweise ein Problem löst. Dies geschieht mit einem `#`, gefolgt von der Nummer des Issues. Zum Beispiel `#97`.
🤞Daumen drücken, dass alle Checks erfolgreich sind und die Projektbesitzer deine Änderungen ins Projekt übernehmen🤞
🤞Daumen drücken, dass alle Checks erfolgreich sind und die Projektbesitzer deine Änderungen ins Projekt mergen🤞
Aktualisiere deinen aktuellen lokalen Arbeits-Branch mit allen neuen Commits vom entsprechenden Remote-Branch auf GitHub:
Aktualisiere deinen aktuellen lokalen Arbeitsbranch mit allen neuen Commits vom entsprechenden Remote-Branch auf GitHub:
`git pull`
## Wie man zu Open Source beiträgt
Zuerst suchen wir ein Repository (oder **Repo**) auf GitHub, das dich interessiert und zu dem du eine Änderung beitragen möchtest. Du wirst den Inhalt auf deinen Rechner kopieren wollen.
Zunächst suchen wir ein Repository (oder **Repo**) auf GitHub, das dich interessiert und zu dem du eine Änderung beitragen möchtest. Du solltest dessen Inhalte auf deinen Rechner kopieren.
✅ Eine gute Möglichkeit, 'anfängerfreundliche' Repos zu finden, ist [die Suche nach dem Tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Es gibt mehrere Möglichkeiten, Code zu kopieren. Eine Möglichkeit ist, die Inhalte des Repositories zu "klonen", entweder über HTTPS, SSH oder mit der GitHub CLI (Command Line Interface).
Es gibt mehrere Möglichkeiten, Code zu kopieren. Eine davon ist, die Inhalte des Repositories zu "klonen", entweder über HTTPS, SSH oder mit der GitHub CLI (Command Line Interface).
Öffne dein Terminal und klone das Repository wie folgt:
`git clone https://github.com/ProjectURL`
@ -300,9 +305,9 @@ Alternativ kannst du den Code in einem gezippten Ordner herunterladen.
### Ein paar weitere interessante Dinge über GitHub
Du kannst jedes öffentliche Repository auf GitHub mit einem Stern markieren, beobachten und/oder "forken". Deine markierten Repositories findest du im Dropdown-Menü oben rechts. Es ist wie ein Lesezeichen, aber für Code.
Du kannst jedes öffentliche Repository auf GitHub mit einem Stern markieren, beobachten und/oder "forken". Deine mit Stern markierten Repositories findest du im Dropdown-Menü oben rechts. Es ist wie ein Lesezeichen, aber für Code.
Projekte haben einen Issue-Tracker, meistens auf GitHub im Tab "Issues", es sei denn, es wird anders angegeben. Dort diskutieren Menschen über Probleme, die das Projekt betreffen. Im Tab "Pull Requests" werden Änderungen, die in Bearbeitung sind, diskutiert und überprüft.
Projekte haben einen Issue-Tracker, meistens auf GitHub im Tab "Issues", es sei denn, es wird anders angegeben. Dort diskutieren Menschen über Probleme, die mit dem Projekt zusammenhängen. Im Tab "Pull Requests" diskutieren und überprüfen Menschen Änderungen, die gerade in Arbeit sind.
Projekte können auch Diskussionen in Foren, Mailinglisten oder Chat-Kanälen wie Slack, Discord oder IRC haben.
@ -310,9 +315,9 @@ Projekte können auch Diskussionen in Foren, Mailinglisten oder Chat-Kanälen wi
---
## 🚀 Herausforderung
## 🚀 Herausforderung
Arbeite mit einem Freund zusammen an eurem Code. Erstellt ein gemeinsames Projekt, forkt Code, erstellt Branches und führt Änderungen zusammen.
Arbeite mit einem Freund zusammen an euren jeweiligen Codes. Erstellt gemeinsam ein Projekt, forkt Code, erstellt Branches und merged Änderungen.
## Quiz nach der Vorlesung
[Quiz nach der Vorlesung](https://ff-quizzes.netlify.app/web/en/)
@ -329,11 +334,11 @@ Lies mehr über [das Beitragen zu Open-Source-Software](https://opensource.guide
Dort findest du auch fortgeschrittene Kurse.
## Aufgabe
## Aufgabe
Absolviere [den Kurs "Erste Woche auf GitHub"](https://skills.github.com/#first-week-on-github).
Absolviere [den Kurs "Erste Woche auf GitHub"](https://skills.github.com/#first-week-on-github)
---
**Haftungsausschluss**:
Dieses Dokument wurde mit dem KI-Übersetzungsdienst [Co-op Translator](https://github.com/Azure/co-op-translator) übersetzt. Obwohl wir uns um Genauigkeit bemühen, weisen wir darauf hin, dass automatisierte Übersetzungen Fehler oder Ungenauigkeiten enthalten können. Das Originaldokument in seiner ursprünglichen Sprache sollte als maßgebliche Quelle betrachtet werden. Für kritische Informationen wird eine professionelle menschliche Übersetzung empfohlen. Wir haften nicht für Missverständnisse oder Fehlinterpretationen, die sich aus der Nutzung dieser Übersetzung ergeben.
Dieses Dokument wurde mit dem KI-Übersetzungsdienst [Co-op Translator](https://github.com/Azure/co-op-translator) übersetzt. Obwohl wir uns um Genauigkeit bemühen, beachten Sie bitte, dass automatisierte Übersetzungen Fehler oder Ungenauigkeiten enthalten können. Das Originaldokument in seiner ursprünglichen Sprache sollte als maßgebliche Quelle betrachtet werden. Für kritische Informationen wird eine professionelle menschliche Übersetzung empfohlen. Wir übernehmen keine Haftung für Missverständnisse oder Fehlinterpretationen, die sich aus der Nutzung dieser Übersetzung ergeben.
Αυτό το μάθημα καλύπτει τα βασικά του GitHub, μιας πλατφόρμας για φιλοξενία και διαχείριση αλλαγών στον κώδικά σας.
> Σημειώσεις από [Tomomi Imura](https://twitter.com/girlie_mac)
> Σκίτσο από την [Tomomi Imura](https://twitter.com/girlie_mac)
## Ερωτηματολόγιο πριν το μάθημα
[Ερωτηματολόγιο πριν το μάθημα](https://ff-quizzes.netlify.app)
@ -31,8 +31,8 @@ CO_OP_TRANSLATOR_METADATA:
`git --version`
Αν το Git δεν είναι εγκατεστημένο, [κατεβάστε το Git](https://git-scm.com/downloads). Στη συνέχεια, ρυθμίστε το τοπικό προφίλ Git στο τερματικό:
* `git config --global user.name "το-όνομά-σας"`
* `git config --global user.email "το-email-σας"`
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
Για να ελέγξετε αν το Git είναι ήδη ρυθμισμένο, μπορείτε να πληκτρολογήσετε:
`git config --list`
@ -59,10 +59,10 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Δημιουργία αποθετηρίου στο GitHub**. Στο GitHub.com, στην καρτέλα αποθετηρίων ή από τη γραμμή πλοήγησης πάνω δεξιά, βρείτε το κουμπί **νέο αποθετήριο**.
1. **Δημιουργία αποθετηρίου στο GitHub**. Στο GitHub.com, στην καρτέλα αποθετηρίων ή από τη γραμμή πλοήγησης πάνω δεξιά, βρείτε το κουμπί **new repo**.
1. Δώστε στο αποθετήριο (φάκελο) σας ένα όνομα.
1. Επιλέξτε **δημιουργία αποθετηρίου**.
1. Δώστε στο αποθετήριο σας (φάκελο) ένα όνομα.
1. Επιλέξτε **create repository**.
1. **Μεταβείτε στον φάκελο εργασίας σας**. Στο τερματικό σας, μεταβείτε στον φάκελο (γνωστό και ως directory) που θέλετε να αρχίσετε να παρακολουθείτε. Πληκτρολογήστε:
@ -82,7 +82,7 @@ CO_OP_TRANSLATOR_METADATA:
git status
```
Η έξοδος μπορεί να μοιάζει κάπως έτσι:
η έξοδος μπορεί να μοιάζει κάπως έτσι:
```output
Changes not staged for commit:
@ -96,7 +96,7 @@ CO_OP_TRANSLATOR_METADATA:
Συνήθως η εντολή `git status` σας λέει πράγματα όπως ποια αρχεία είναι έτοιμα να_αποθηκευτούν_ στο αποθετήριο ή έχουν αλλαγές που ίσως θέλετε να διατηρήσετε.
1. **Προσθήκη όλων των αρχείων για παρακολούθηση**
Αυτό ονομάζεται επίσης στάδιο αρχείων/προσθήκη αρχείων στην περιοχή σταδιοποίησης.
Αυτό ονομάζεται επίσης σταδιοποίηση αρχείων/προσθήκη αρχείων στην περιοχή σταδιοποίησης.
```bash
git add .
@ -128,17 +128,17 @@ CO_OP_TRANSLATOR_METADATA:
Αυτή η εντολή μας βοηθά να αφαιρέσουμε μόνο ένα συγκεκριμένο αρχείο από τη σταδιοποίηση που δεν θέλουμε να συμπεριλάβουμε στο επόμενο commit.
1. **Διατήρηση της δουλειάς σας**. Σε αυτό το σημείο έχετε προσθέσει τα αρχεία σε μια λεγόμενη _περιοχή σταδιοποίησης_. Ένα μέρος όπου το Git παρακολουθεί τα αρχεία σας. Για να κάνετε την αλλαγή μόνιμη, πρέπει να_κάνετε commit_ τα αρχεία. Για να το κάνετε αυτό, δημιουργείτε ένα _commit_ με την εντολή `git commit`. Ένα _commit_ αντιπροσωπεύει ένα σημείο αποθήκευσης στην ιστορία του αποθετηρίου σας. Πληκτρολογήστε το εξήςγιανα δημιουργήσετε ένα _commit_:
1. **Διατήρηση της δουλειάς σας**. Σε αυτό το σημείο έχετε προσθέσει τα αρχεία σε μια λεγόμενη _περιοχή σταδιοποίησης_. Ένα μέρος όπου το Git παρακολουθεί τα αρχεία σας. Για να κάνετε την αλλαγή μόνιμη, πρέπει να_δεσμεύσετε_ τα αρχεία. Για να το κάνετε αυτό, δημιουργείτε ένα _commit_ με την εντολή `git commit`. Ένα _commit_ αντιπροσωπεύει ένα σημείο αποθήκευσης στην ιστορία του αποθετηρίου σας. Πληκτρολογήστε την παρακάτω εντολήγιανα δημιουργήσετε ένα _commit_:
```bash
git commit -m "first commit"
```
Αυτό κάνει commit όλα τα αρχεία σας, προσθέτοντας το μήνυμα "πρώτο commit". Για μελλοντικά μηνύματα commit, θα θέλετε να είστε πιο περιγραφικοί στην περιγραφή σας γιανα μεταφέρετε τι είδους αλλαγή κάνατε.
Αυτό δεσμεύει όλα τα αρχεία σας, προσθέτοντας το μήνυμα "first commit". Για μελλοντικά μηνύματα commit, θα θέλετε να είστε πιο περιγραφικοί στην περιγραφή σας γιανα μεταφέρετε τι είδους αλλαγή έχετε κάνει.
1. **Σύνδεση του τοπικού αποθετηρίου Git με το GitHub**. Ένα αποθετήριο Git είναι καλό στον υπολογιστή σας, αλλά κάποια στιγμή θα θέλετε να έχετε αντίγραφο ασφαλείας των αρχείων σας κάπου και επίσης να προσκαλέσετε άλλους να συνεργαστούν μαζί σας στο αποθετήριο σας. Ένα εξαιρετικό μέρος γιανα το κάνετε αυτό είναι το GitHub. Θυμηθείτε ότι έχουμε ήδη δημιουργήσει ένα αποθετήριο στο GitHub, οπότε το μόνο που χρειάζεται να κάνουμε είναι να συνδέσουμε το τοπικό αποθετήριο Git με το GitHub. Η εντολή `git remote add` θα το κάνει αυτό. Πληκτρολογήστε την παρακάτω εντολή:
1. **Σύνδεση του τοπικού αποθετηρίου Git με το GitHub**. Ένα αποθετήριο Git είναι καλό στον υπολογιστή σας, αλλά κάποια στιγμή θέλετε να έχετε αντίγραφο ασφαλείας των αρχείων σας κάπου και επίσης να προσκαλέσετε άλλους να συνεργαστούν μαζί σας στο αποθετήριο σας. Ένα τέτοιο εξαιρετικό μέρος γιανα το κάνετε αυτό είναι το GitHub. Θυμηθείτε ότι έχουμε ήδη δημιουργήσει ένα αποθετήριο στο GitHub, οπότε το μόνο που χρειάζεται να κάνουμε είναι να συνδέσουμε το τοπικό αποθετήριο Git με το GitHub. Η εντολή `git remote add` θα το κάνει αυτό. Πληκτρολογήστε την παρακάτω εντολή:
> Σημείωση, πριν πληκτρολογήσετε την εντολή, μεταβείτε στη σελίδα του αποθετηρίου σας στο GitHub γιανα βρείτε το URL του αποθετηρίου. Θα το χρησιμοποιήσετε στην παρακάτω εντολή. Αντικαταστήστε το ```https://github.com/username/repository_name.git``` με το URL του GitHub σας.
> Σημείωση, πριν πληκτρολογήσετε την εντολή, μεταβείτε στη σελίδα του αποθετηρίου σας στο GitHub γιανα βρείτε το URL του αποθετηρίου. Θα το χρησιμοποιήσετε στην παρακάτω εντολή. Αντικαταστήστε ```https://github.com/username/repository_name.git``` με το URL του GitHub σας.
Αυτό δημιουργεί μια _απομακρυσμένη σύνδεση_, που ονομάζεται "origin", η οποία δείχνει στο αποθετήριο GitHub που δημιουργήσατε νωρίτερα.
1. **Αποστολή τοπικών αρχείων στο GitHub**. Μέχρι στιγμής έχετε δημιουργήσει μια _σύνδεση_ μεταξύ του τοπικού αποθετηρίου και του αποθετηρίου GitHub. Ας στείλουμε αυτά τα αρχεία στο GitHub με την παρακάτω εντολή `git push`, όπως εξής:
1. **Αποστολή τοπικών αρχείων στο GitHub**. Μέχρι στιγμής έχετε δημιουργήσει μια _σύνδεση_ μεταξύ του τοπικού αποθετηρίου και του αποθετηρίου GitHub. Ας στείλουμε αυτά τα αρχεία στο GitHub με την παρακάτω εντολή `git push`, όπως φαίνεται:
> Σημείωση, το όνομα του branch σας μπορεί να είναι διαφορετικό από το ```main```.
```bash
git push -u origin main
```
Αυτό στέλνει τα commits σας στο branch "main" στο GitHub.
Αυτό στέλνει τα commits σας στο branch "main" στο GitHub.Η ρύθμιση του branch `upstream` συμπεριλαμβανομένου του `-u` στην εντολή δημιουργεί έναν σύνδεσμο μεταξύ του τοπικού branch και του απομακρυσμένου branch, ώστε να μπορείτε απλά να χρησιμοποιείτε git push ή git pull χωρίς να καθορίζετε το όνομα του branch στο μέλλον. Το Git θα χρησιμοποιεί αυτόματα το upstream branch και δεν θα χρειάζεται να καθορίζετε το όνομα του branch ρητά σε μελλοντικές εντολές.
2. **Προσθήκη περισσότερων αλλαγών**. Αν θέλετε να συνεχίσετε να κάνετε αλλαγές και να τις στέλνετε στο GitHub, θα χρειαστεί να χρησιμοποιήσετε τις παρακάτω τρεις εντολές:
@ -168,34 +168,34 @@ CO_OP_TRANSLATOR_METADATA:
#### Μηνύματα commit
Ένα εξαιρετικό θέμα γραμμής μηνύματος commit ολοκληρώνει την παρακάτω πρόταση:
Αν εφαρμοστεί, αυτό το commit θα <το θέμα της γραμμής σας εδώ>
Ένα εξαιρετικό θέμα γραμμής μηνύματος commit στο Git ολοκληρώνει την παρακάτω πρόταση:
Αν εφαρμοστεί, αυτό το commit θα <το θέμα σας εδώ>
Για το θέμα, χρησιμοποιήστε την προστακτική, ενεστώτα: "αλλάξτε" αντί για "αλλαγμένο" ή "αλλαγές".
Για το θέμα χρησιμοποιήστε την προστακτική, ενεστώτα: "αλλάζω" αντί για "άλλαξα" ή "αλλαγές".
Όπως στο θέμα, στο σώμα (προαιρετικό) χρησιμοποιήστε επίσης την προστακτική, ενεστώτα. Το σώμα θα πρέπει να περιλαμβάνει το κίνητρο για την αλλαγή και να το συγκρίνει με την προηγούμενη συμπεριφορά. Εξηγείτε το `γιατί`, όχι το `πώς`.
✅ Αφιερώστε λίγα λεπτά γιανα περιηγηθείτε στο GitHub. Μπορείτε να βρείτε ένα πραγματικά εξαιρετικό μήνυμα commit; Μπορείτε να βρείτε ένα πραγματικά ελάχιστο; Ποιες πληροφορίες πιστεύετε ότι είναι οι πιο σημαντικές και χρήσιμες γιανα μεταδοθούν σε ένα μήνυμα commit;
✅ Αφιερώστε λίγα λεπτά γιανα περιηγηθείτε στο GitHub. Μπορείτε να βρείτε ένα πραγματικά εξαιρετικό μήνυμα commit; Μπορείτε να βρείτε ένα πραγματικά ελάχιστο; Ποια πληροφορία πιστεύετε ότι είναι η πιο σημαντική και χρήσιμη να μεταφέρετε σε ένα μήνυμα commit;
### Εργασία: Συνεργασία
Ο κύριος λόγος γιανα βάλετε πράγματα στο GitHub ήταν να κάνετε δυνατή τη συνεργασία με άλλους προγραμματιστές.
## Συνεργασία σε έργα με άλλους
## Εργασία σε έργα με άλλους
> Δείτε το βίντεο
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Στο αποθετήριό σας, μεταβείτε στο `Insights > Community`γιανα δείτε πώς συγκρίνεται το έργο σας με τα προτεινόμενα πρότυπα κοινότητας.
Στο αποθετήριο σας, μεταβείτε στο `Insights > Community`γιανα δείτε πώς συγκρίνεται το έργο σας με τα προτεινόμενα πρότυπα κοινότητας.
Εδώ είναι μερικά πράγματα που μπορούν να βελτιώσουν το αποθετήριο σας στο GitHub:
- **Περιγραφή**. Προσθέσατε περιγραφή για το έργο σας;
- **Περιγραφή**. Προσθέσατε μια περιγραφή για το έργο σας;
- **README**. Προσθέσατε ένα README; Το GitHub παρέχει καθοδήγηση για τη συγγραφή ενός [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/).
- **Οδηγίες συνεισφοράς**. Έχει το έργο σας [οδηγίες συνεισφοράς](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](https://www.makeareadme.com/) που ίσως θέλετε να δοκιμάσετε.
@ -203,16 +203,16 @@ CO_OP_TRANSLATOR_METADATA:
Τα έγγραφα συνεισφοράς βοηθούν τους ανθρώπους να συνεισφέρουν στο έργο. Εξηγούν τι είδους συνεισφορές αναζητάτε και πώς λειτουργεί η διαδικασία. Οι συνεισφέροντες θα χρειαστεί να περάσουν από μια σειρά βημάτων γιανα μπορέσουν να συνεισφέρουν στο αποθετήριο σας στο GitHub:
1. **Δημιουργία αντιγράφου του αποθετηρίου σας**. Πιθανότατα θα θέλετε οι άνθρωποι να_δημιουργήσουναντίγραφο_ του έργου σας. Η δημιουργία αντιγράφου σημαίνει τη δημιουργία ενός αντιγράφου του αποθετηρίου σας στο προφίλ τους στο GitHub.
1. **Forking του αποθετηρίου σας**. Πιθανότατα θα θέλετε οι άνθρωποι να κάνουν _fork_ στο έργο σας. Το Forking σημαίνει τη δημιουργία ενός αντιγράφου του αποθετηρίου σας στο προφίλ τους στο GitHub.
1. **Κλωνοποίηση**. Από εκεί θα κλωνοποιήσουν το έργο στον τοπικό τους υπολογιστή.
1. **Δημιουργία branch**. Θα θέλετε να τους ζητήσετε να δημιουργήσουν ένα _branch_για τη δουλειά τους.
1. **Εστίαση της αλλαγής σε μία περιοχή**. Ζητήστε από τους συνεισφέροντες να επικεντρώσουν τις συνεισφορές τους σε ένα πράγμα τη φορά - έτσι οι πιθανότητες να_συγχωνεύσετε_ τη δουλειά τους είναι μεγαλύτερες. Φανταστείτε ότι γράφουν μια διόρθωση σφάλματος, προσθέτουν μια νέα λειτουργία και ενημερώνουν αρκετές δοκιμές - τι γίνεται αν θέλετε ή μπορείτε να εφαρμόσετε μόνο 2 από τις 3 ή 1 από τις 3 αλλαγές;
1. **Εστίαση της αλλαγής σε μία περιοχή**. Ζητήστε από τους συνεισφέροντες να επικεντρώσουν τις συνεισφορές τους σε ένα πράγμα τη φορά - έτσι οι πιθανότητες ναμπορέσετε να_συγχωνεύσετε_ τη δουλειά τους είναι μεγαλύτερες. Φανταστείτε ότι γράφουν μια διόρθωση σφάλματος, προσθέτουν μια νέα λειτουργία και ενημερώνουν αρκετές δοκιμές - τι γίνεται αν θέλετε ή μπορείτε να εφαρμόσετε μόνο 2 από τις 3 ή 1 από τις 3 αλλαγές;
✅ Φανταστείτε μια κατάσταση όπου τα branches είναι ιδιαίτερα κρίσιμα για τη συγγραφή και την αποστολή καλού κώδικα. Ποιες περιπτώσεις χρήσης μπορείτε να σκεφτείτε;
> Σημείωση, γίνετε η αλλαγή που θέλετε να δείτε στον κόσμο και δημιουργήστε branches για τη δική σας δουλειά επίσης. Οποιαδήποτε commits κάνετε θα γίνουν στο branch που έχετε "επιλέξει". Χρησιμοποιήστε `git status`γιανα δείτε ποιο branch είναι αυτό.
> Σημείωση, γίνετε η αλλαγή που θέλετε να δείτε στον κόσμο και δημιουργήστε branches για τη δική σας δουλειά επίσης. Οποιαδήποτε commits κάνετε θα γίνονται στο branch που έχετε "επιλέξει". Χρησιμοποιήστε `git status`γιανα δείτε ποιο branch είναι αυτό.
Ας περάσουμε από τη ροή εργασίας ενός συνεισφέροντα. Υποθέστε ότι ο συνεισφέρων έχει ήδη _δημιουργήσειαντίγραφο_ και _κλωνοποιήσει_ το αποθετήριο, ώστε να έχει ένα αποθετήριο Git έτοιμο για εργασία στον τοπικό του υπολογιστή:
Ας περάσουμε από τη ροή εργασίας ενός συνεισφέροντα. Υποθέστε ότι ο συνεισφέρων έχει ήδη κάνει _fork_ και _clone_ το αποθετήριο, ώστε να έχει ένα αποθετήριο Git έτοιμο για εργασία στον τοπικό του υπολογιστή:
1. **Δημιουργία branch**. Χρησιμοποιήστε την εντολή `git branch`γιανα δημιουργήσετε ένα branch που θα περιέχει τις αλλαγές που σκοπεύουν να συνεισφέρουν:
@ -220,13 +220,13 @@ CO_OP_TRANSLATOR_METADATA:
git branch [branch-name]
```
1. **Μετάβαση στο branch εργασίας**. Μεταβείτε στο συγκεκριμένο branch και ενημερώστε τον φάκελο εργασίας με `git switch`:
1. **Μετάβαση στο branch εργασίας**. Μεταβείτε στο συγκεκριμένο branch και ενημερώστε τον φάκελο εργασίας με την εντολή `git switch`:
```bash
git switch [branch-name]
```
1. **Εργασία**. Σε αυτό το σημείο θέλετε να προσθέσετε τις αλλαγές σας. Μην ξεχάσετε να ενημερώσετε το Git γι' αυτές με τις παρακάτω εντολές:
1. **Εργασία**. Σε αυτό το σημείο θέλετε να προσθέσετε τις αλλαγές σας. Μην ξεχάσετε να ενημερώσετε το Git γι' αυτό με τις παρακάτω εντολές:
```bash
git add .
@ -235,80 +235,83 @@ CO_OP_TRANSLATOR_METADATA:
Βεβαιωθείτε ότι δίνετε στο commit σας ένα καλό όνομα, για το δικό σας καλό καθώς και για τον συντηρητή του αποθετηρίου που βοηθάτε.
1. **Συνδυασμός της δουλειάς σας με το branch `main`**. Κάποια στιγμή τελειώνετε τη δουλειά σας και θέλετε να τη συνδυάσετε με αυτή του branch `main`. Το branch `main` μπορεί να έχει αλλάξει εν τω μεταξύ, οπότε βεβαιωθείτε ότι πρώτα το ενημερώνετε με τις παρακάτω εντολές:
1. **Συνδυασμός της δουλειάς σας με το branch `main`**. Σε κάποιο σημείο τελειώνετε τη δουλειά σας και θέλετε να τη συνδυάσετε με αυτή του branch `main`. Το branch `main` μπορεί να
1. **Άνοιγμα PR**. Στη συνέχεια, θέλετε να ανοίξετε ένα PR. Αυτό γίνεται πηγαίνοντας στο forked repo στο GitHub. Θα δείτε μια ένδειξη στο GitHub που σας ρωτά αν θέλετε να δημιουργήσετε ένα νέο PR. Κάνετε κλικ εκεί και μεταφέρεστε σε μια διεπαφή όπου μπορείτε να αλλάξετε τον τίτλο του μηνύματος commit και να δώσετε μια πιο κατάλληλη περιγραφή. Τώρα ο maintainer του repo που κάνατε fork θα δει αυτό το PR και _με λίγη τύχη_ θα το εκτιμήσει και θα το _ενσωματώσει_. Είστε πλέον συνεισφέρων, μπράβο! :)
1. **Καθαρισμός**. Θεωρείται καλή πρακτική να_καθαρίζετε_ μετά την επιτυχή ενσωμάτωση ενός PR. Θέλετε να καθαρίσετε τόσο το τοπικό branch σας όσο και το branch που ανεβάσατε στο GitHub. Πρώτα, ας το διαγράψουμε τοπικά με την εξής εντολή:
```bash
git switch main
git pull
git branch -d [branch-name]
```
Στη συνέχεια, πηγαίνετε στη σελίδα του GitHub για το forked repo και αφαιρέστε το απομακρυσμένο branch που μόλις ανεβάσατε.
Σε αυτό το σημείο θέλετε να βεβαιωθείτε ότι τυχόν _συγκρούσεις_, καταστάσεις όπου το Git
`Pull request` φαίνεται σαν ένας αστείος όρος, γιατί στην πραγματικότητα θέλεις να σπρώξεις (push) τις αλλαγές σου στο έργο. Ωστόσο, ο συντηρητής (ιδιοκτήτης του έργου) ή η βασική ομάδα πρέπει να εξετάσουν τις αλλαγές σου πριν τις συγχωνεύσουν με τον "κύριο" κλάδο του έργου, οπότε ουσιαστικά ζητάς απόφαση αλλαγής από έναν συντηρητή.
Ο όρος `Pull request` μπορεί να φαίνεται λίγο περίεργος, γιατί στην πραγματικότητα θέλετε να σπρώξετε τις αλλαγές σας στο project. Αλλά ο maintainer (ιδιοκτήτης του project) ή η βασική ομάδα πρέπει να εξετάσει τις αλλαγές σας πριν τις ενσωματώσει στο "main" branch του project, οπότε στην ουσία ζητάτε μια απόφαση αλλαγής από τον maintainer.
Ένα pull request είναι ο χώρος όπου συγκρίνεις και συζητάς τις διαφορές που εισάγονται σε έναν κλάδο, με κριτικές, σχόλια, ενσωματωμένα τεστ και άλλα. Ένα καλό pull request ακολουθεί περίπου τους ίδιους κανόνες με ένα μήνυμα commit. Μπορείς να προσθέσεις μια αναφορά σε ένα ζήτημα στον ιχνηλάτη ζητημάτων, όταν για παράδειγμα η δουλειά σου διορθώνει ένα ζήτημα. Αυτό γίνεται χρησιμοποιώντας το `#` ακολουθούμενο από τον αριθμό του ζητήματος. Για παράδειγμα,`#97`.
Ένα pull request είναι ο χώρος όπου συγκρίνετε και συζητάτε τις διαφορές που εισάγονται σε ένα branch, με κριτικές, σχόλια, ενσωματωμένα τεστ και άλλα. Ένα καλό pull request ακολουθεί περίπου τους ίδιους κανόνες με ένα commit message. Μπορείτε να προσθέσετε μια αναφορά σε ένα issue στο issue tracker, όταν η δουλειά σας, για παράδειγμα, διορθώνει ένα πρόβλημα. Αυτό γίνεται χρησιμοποιώντας ένα `#` ακολουθούμενο από τον αριθμό του issue σας. Για παράδειγμα`#97`.
🤞Ελπίζουμε να περάσουν όλοι οι έλεγχοι και οι ιδιοκτήτες του έργου να συγχωνεύσουν τις αλλαγές σου στο έργο🤞
🤞Με λίγη τύχη, όλα τα checks θα περάσουν και ο ιδιοκτήτης του project θα ενσωματώσει τις αλλαγές σας στο project🤞
Ενημέρωσε τον τρέχοντα τοπικό κλάδο εργασίας σου με όλα τα νέα commits από τον αντίστοιχο απομακρυσμένο κλάδο στο GitHub:
Ενημερώστε το τρέχον τοπικό branch εργασίας σας με όλα τα νέα commits από το αντίστοιχο απομακρυσμένο branch στο GitHub:
`git pull`
## Πώς να συνεισφέρεις σε ανοιχτό κώδικα
## Πώς να συνεισφέρετε σε open source
Αρχικά, ας βρούμε ένα αποθετήριο (ή **repo**) στο GitHub που σε ενδιαφέρει και στο οποίο θέλεις να συνεισφέρεις μια αλλαγή. Θα χρειαστεί να αντιγράψεις το περιεχόμενό του στον υπολογιστή σου.
Πρώτα, ας βρούμε ένα repository (ή **repo**) στο GitHub που σας ενδιαφέρει και στο οποίο θέλετε να συνεισφέρετε μια αλλαγή. Θα θέλετε να αντιγράψετε το περιεχόμενό του στον υπολογιστή σας.
✅ Ένας καλός τρόπος να βρεις αποθετήρια φιλικά για αρχάριους είναι να [αναζητήσεις με την ετικέτα 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Ένας καλός τρόπος να βρείτε repos φιλικά προς αρχάριους είναι να [αναζητήσετε με την ετικέτα 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Υπάρχουν διάφοροι τρόποι αντιγραφής κώδικα. Ένας τρόπος είναι να "κλωνοποιήσεις" το περιεχόμενο του αποθετηρίου, χρησιμοποιώντας HTTPS, SSH ή το GitHub CLI (Command Line Interface).
Υπάρχουν διάφοροι τρόποι αντιγραφής κώδικα. Ένας τρόπος είναι να "κλωνοποιήσετε" το περιεχόμενο του repository, χρησιμοποιώντας HTTPS, SSH ή το GitHub CLI (Command Line Interface).
Άνοιξε το τερματικό σου και κλωνοποίησε το αποθετήριο ως εξής:
Ανοίξτε το τερματικό σας και κλωνοποιήστε το repository όπως παρακάτω:
`git clone https://github.com/ProjectURL`
Για ναδουλέψεις στο έργο, άλλαξε στον σωστό φάκελο:
Για ναεργαστείτε στο project, μεταβείτε στον σωστό φάκελο:
`cd ProjectURL`
Μπορείς επίσης να ανοίξεις ολόκληρο το έργο χρησιμοποιώντας το [Codespaces](https://github.com/features/codespaces), τον ενσωματωμένο επεξεργαστή κώδικα / περιβάλλον ανάπτυξης στο cloud του GitHub, ή το [GitHub Desktop](https://desktop.github.com/).
Μπορείτε επίσης να ανοίξετε ολόκληρο το project χρησιμοποιώντας [Codespaces](https://github.com/features/codespaces), τον ενσωματωμένο επεξεργαστή κώδικα / περιβάλλον ανάπτυξης cloud του GitHub, ή το [GitHub Desktop](https://desktop.github.com/).
Τέλος, μπορείς να κατεβάσεις τον κώδικα σε έναν συμπιεσμένο φάκελο.
Τέλος, μπορείτε να κατεβάσετε τον κώδικα σε έναν συμπιεσμένο φάκελο.
### Μερικά ακόμα ενδιαφέροντα πράγματα για το GitHub
Μπορείς να κάνεις star, watch και/ή "fork" οποιοδήποτε δημόσιο αποθετήριο στο GitHub. Μπορείς να βρεις τα αποθετήρια που έχεις κάνει star στο αναδυόμενο μενού πάνω δεξιά. Είναι σαννα κάνεις σελιδοδείκτη, αλλά για κώδικα.
Μπορείτε να κάνετε star, watch και/ή "fork" οποιοδήποτε δημόσιο repository στο GitHub. Μπορείτε να βρείτε τα repos που έχετε κάνει star στο drop-down μενού πάνω δεξιά. Είναι σαννα κάνετε bookmarking, αλλά για κώδικα.
Ταέργα έχουν έναν ιχνηλάτη ζητημάτων, συνήθως στο GitHub στην καρτέλα "Issues", εκτός αν αναφέρεται διαφορετικά, όπου οι άνθρωποι συζητούν ζητήματα που σχετίζονται με το έργο. Και η καρτέλα Pull Requests είναι εκεί όπου οι άνθρωποι συζητούν και αξιολογούν αλλαγές που βρίσκονται σε εξέλιξη.
Ταprojects έχουν ένα issue tracker, συνήθως στο GitHub στην καρτέλα "Issues", εκτός αν αναφέρεται διαφορετικά, όπου οι άνθρωποι συζητούν θέματα που σχετίζονται με το project. Και η καρτέλα Pull Requests είναι εκεί όπου οι άνθρωποι συζητούν και αξιολογούν αλλαγές που βρίσκονται σε εξέλιξη.
Ταέργα μπορεί επίσης να έχουν συζητήσεις σε φόρουμ, λίστες αλληλογραφίας ή κανάλια συνομιλίας όπως Slack, Discord ή IRC.
Ταprojects μπορεί επίσης να έχουν συζητήσεις σε φόρουμ, λίστες αλληλογραφίας ή κανάλια συνομιλίας όπως Slack, Discord ή IRC.
✅ Ρίξε μια ματιά στο νέο σου αποθετήριο GitHub και δοκίμασε μερικά πράγματα, όπως να επεξεργαστείς ρυθμίσεις, να προσθέσεις πληροφορίες στο αποθετήριο σου και να δημιουργήσεις ένα έργο (όπως έναν πίνακα Kanban). Υπάρχουν πολλά που μπορείς να κάνεις!
✅ Ρίξτε μια ματιά στο νέο σας GitHub repo και δοκιμάστε μερικά πράγματα, όπως να επεξεργαστείτε ρυθμίσεις, να προσθέσετε πληροφορίες στο repo σας και να δημιουργήσετε ένα project (όπως έναν πίνακα Kanban). Υπάρχουν πολλά που μπορείτε να κάνετε!
---
## 🚀 Πρόκληση
Συνεργάσου με έναν φίλο γιανα δουλέψετε στον κώδικα του άλλου. Δημιουργήστε ένα έργο συνεργατικά, κάντε fork κώδικα, δημιουργήστε κλάδους και συγχωνεύστε αλλαγές.
Συνεργαστείτε με έναν φίλο γιανα δουλέψετε στον κώδικα του άλλου. Δημιουργήστε ένα project συνεργατικά, κάντε fork τον κώδικα, δημιουργήστε branches και ενσωματώστε αλλαγές.
## Κουίζ μετά το μάθημα
## Κουίζ μετά το μάθημα
[Κουίζ μετά το μάθημα](https://ff-quizzes.netlify.app/web/en/)
## Ανασκόπηση & Αυτομελέτη
Διάβασε περισσότερα για το [πώς να συνεισφέρεις σε λογισμικό ανοιχτού κώδικα](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Διαβάστε περισσότερα για [τη συνεισφορά σε λογισμικό ανοιχτού κώδικα](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Εξάσκηση, εξάσκηση, εξάσκηση. Το GitHub έχει εξαιρετικά μονοπάτια μάθησης διαθέσιμα μέσω του [skills.github.com](https://skills.github.com):
Εξασκηθείτε, εξασκηθείτε, εξασκηθείτε. Το GitHub διαθέτει εξαιρετικά μονοπάτια μάθησης μέσω του [skills.github.com](https://skills.github.com):
- [Πρώτη Εβδομάδα στο GitHub](https://skills.github.com/#first-week-on-github)
Θα βρεις επίσης πιο προχωρημένα μαθήματα.
Θα βρείτε επίσης πιο προχωρημένα μαθήματα.
## Εργασία
Ολοκλήρωσε το μάθημα [Πρώτη Εβδομάδα στο GitHub](https://skills.github.com/#first-week-on-github)
Ολοκληρώστε [το μάθημα Πρώτη Εβδομάδα στο GitHub](https://skills.github.com/#first-week-on-github)
---
**Αποποίηση Ευθύνης**:
Αυτό το έγγραφο έχει μεταφραστεί χρησιμοποιώντας την υπηρεσία αυτόματης μετάφρασης [Co-op Translator](https://github.com/Azure/co-op-translator). Παρόλο που καταβάλλουμε προσπάθειες για ακρίβεια, παρακαλούμε να έχετε υπόψη ότι οι αυτόματες μεταφράσεις ενδέχεται να περιέχουν λάθη ή ανακρίβειες. Το πρωτότυπο έγγραφο στη μητρική του γλώσσα θα πρέπει να θεωρείται η αυθεντική πηγή. Για κρίσιμες πληροφορίες, συνιστάται επαγγελματική ανθρώπινη μετάφραση. Δεν φέρουμε ευθύνη για τυχόν παρεξηγήσεις ή εσφαλμένες ερμηνείες που προκύπτουν από τη χρήση αυτής της μετάφρασης.
**Αποποίηση ευθύνης**:
Αυτό το έγγραφο έχει μεταφραστεί χρησιμοποιώντας την υπηρεσία αυτόματης μετάφρασης [Co-op Translator](https://github.com/Azure/co-op-translator). Παρόλο που καταβάλλουμε προσπάθειες για ακρίβεια, παρακαλούμε να έχετε υπόψη ότι οι αυτοματοποιημένες μεταφράσεις ενδέχεται να περιέχουν λάθη ή ανακρίβειες. Το πρωτότυπο έγγραφο στη μητρική του γλώσσα θα πρέπει να θεωρείται η αυθεντική πηγή. Για κρίσιμες πληροφορίες, συνιστάται επαγγελματική ανθρώπινη μετάφραση. Δεν φέρουμε ευθύνη για τυχόν παρεξηγήσεις ή εσφαλμένες ερμηνείες που προκύπτουν από τη χρήση αυτής της μετάφρασης.
@ -19,39 +19,39 @@ This lesson introduces the basics of GitHub, a platform for hosting and managing
## Introduction
In this lesson, we’ll cover:
In this lesson, we'll explore:
- Tracking the work you do on your computer
- Tracking your work on your computer
- Collaborating on projects with others
- How to contribute to open-source software
- Contributing to open-source software
### Prerequisites
Before starting, check if Git is installed. In the terminal, type:
`git --version`
If Git is not installed, [download Git](https://git-scm.com/downloads). Then, set up your local Git profile in the terminal:
If Git isn't installed, [download Git](https://git-scm.com/downloads). Then, set up your local Git profile in the terminal:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
To verify if Git is already configured, type:
`git config --list`
You’ll also need a GitHub account, a code editor (like Visual Studio Code), and access to your terminal (or command prompt).
You'll also need a GitHub account, a code editor (like Visual Studio Code), and access to your terminal (or command prompt).
Go to [github.com](https://github.com/), create an account if you don’t have one, or log in and complete your profile.
Visit [github.com](https://github.com/) to create an account if you don't have one, or log in and complete your profile.
✅ GitHub isn’t the only code repository platform out there, but it’s the most well-known.
✅ GitHub isn't the only code repository platform out there, but it's the most widely known.
### Preparation
You’ll need a folder with a code project on your local machine (laptop or PC) and a public repository on GitHub. This will serve as an example for contributing to others’ projects.
You'll need a folder containing a code project on your local machine (laptop or PC) and a public repository on GitHub to practice contributing to others' projects.
---
## Code Management
Let’s say you have a folder on your computer with a code project, and you want to start tracking your progress using Git, the version control system. Some people compare using Git to writing a love letter to your future self. By reading your commit messages days, weeks, or months later, you’ll remember why you made certain decisions or be able to "roll back" changes—if you write good commit messages.
Imagine you have a folder on your computer with a code project, and you want to start tracking your progress using Git, a version control system. Some people liken using Git to writing a love letter to your future self. By reading your commit messages days, weeks, or months later, you'll recall why you made certain decisions or "roll back" changes—provided you write good commit messages.
### Task: Create a Repository and Commit Code
@ -61,16 +61,16 @@ Let’s say you have a folder on your computer with a code project, and you want
1. **Create a repository on GitHub**. On GitHub.com, go to the repositories tab or use the navigation bar in the top-right corner to find the **new repo** button.
1. Give your repository (folder) a name.
1. Select**create repository**.
1. Name your repository (folder).
1. Click**create repository**.
1. **Navigate to your working folder**. In your terminal, switch to the folder (also called a directory) you want to start tracking. Type:
1. **Navigate to your working folder**. In your terminal, switch to the folder (directory) you want to start tracking. Type:
```bash
cd [name of your folder]
```
1. **Initialize a Git repository**. In your project, type:
1. **Initialize a Git repository**. In your project folder, type:
```bash
git init
@ -82,7 +82,7 @@ Let’s say you have a folder on your computer with a code project, and you want
git status
```
The output might look something like this:
The output might look like this:
```output
Changes not staged for commit:
@ -93,26 +93,26 @@ Let’s say you have a folder on your computer with a code project, and you want
modified: file2.txt
```
The `git status` command typically tells you things like which files are ready to be _saved_ to the repository or have changes you might want to keep.
The `git status` command typically shows information like which files are ready to be saved to the repository or have changes you might want to preserve.
1. **Add all files for tracking**.
This is also called staging files or adding files to the staging area.
1. **Add all files for tracking**
This is also known as staging files or adding files to the staging area.
```bash
git add .
```
The `git add` command with the `.` argument indicates that all your files and changes are being tracked.
The `git add` command with the `.` argument stages all your files and changes for tracking.
1. **Add selected files for tracking**.
1. **Add selected files for tracking**
```bash
git add [file or folder name]
```
This allows you to add only specific files to the staging area when you don’t want to commit all files at once.
This allows you to stage only specific files when you don't want to commit everything at once.
1. **Unstage all files**.
1. **Unstage all files**
```bash
git reset
@ -120,43 +120,43 @@ Let’s say you have a folder on your computer with a code project, and you want
This command unstages all files at once.
1. **Unstage a specific file**.
1. **Unstage a specific file**
```bash
git reset [file or folder name]
```
This command unstages only a specific file that you don’t want to include in the next commit.
This command unstages only a particular file that you don't want to include in the next commit.
1. **Save your work**. At this point, you’ve added the files to a _staging area_, where Git is tracking your files. To make the changes permanent, you need to _commit_ the files. A _commit_ represents a save point in your repository’s history. Type the following to create a _commit_:
1. **Save your work**. At this point, you've added files to the staging area, where Git tracks your files. To make the changes permanent, you need to commit the files. A commit represents a save point in your repository's history. Type the following to create a commit:
```bash
git commit -m "first commit"
```
This commits all your files with the message "first commit." For future commit messages, be more descriptive to explain the type of change you’ve made.
This commits all your files with the message "first commit." For future commit messages, aim to be more descriptive to convey the type of change you've made.
1. **Connect your local Git repository with GitHub**. While a Git repository is useful on your computer, you’ll eventually want to back up your files and collaborate with others. GitHub is a great place for this. Since we’ve already created a repository on GitHub, we just need to connect it to our local Git repository. Use the `git remote add` command. Type:
1. **Connect your local Git repository to GitHub**. While a Git repository is useful on your computer, you'll eventually want to back up your files and collaborate with others. GitHub is a great platform for this. Since we've already created a repository on GitHub, we just need to connect it to our local Git repository. Use the `git remote add` command. Type:
> Note: Before typing the command, go to your GitHub repository page to find the repository URL. Replace ```https://github.com/username/repository_name.git``` with your GitHub URL.
> Before typing the command, go to your GitHub repository page to find the repository URL. Replace ```https://github.com/username/repository_name.git``` with your GitHub URL.
This creates a _remote_ connection named "origin" pointing to the GitHub repository you created earlier.
This creates a remote connection named "origin" pointing to the GitHub repository you created earlier.
1. **Push local files to GitHub**. Now that you’ve created a connection between your local repository and GitHub, send the files to GitHub using the `git push` command:
1. **Push local files to GitHub**. Now that you've established a connection between your local repository and the GitHub repository, send your files to GitHub using the `git push` command:
> Note: Your branch name may differ from ```main```.
> Note: Your branch name might differ from ```main```.
```bash
git push -u origin main
```
This sends your commits in the "main" branch to GitHub.
This pushes your commits from the "main" branch to GitHub. Including `-u` in the command sets the upstream branch, allowing you to use `git push` or `git pull` without specifying the branch name in future commands.
2. **Add more changes**. If you want to continue making changes and pushing them to GitHub, use the following three commands:
2. **Add more changes**. To continue making changes and pushing them to GitHub, use the following three commands:
```bash
git add .
@ -164,21 +164,21 @@ Let’s say you have a folder on your computer with a code project, and you want
git push
```
> Tip: Consider using a `.gitignore` file to prevent certain files from being tracked on GitHub, such as personal notes or sensitive data. You can find templates for `.gitignore` files at [.gitignore templates](https://github.com/github/gitignore).
> Tip: Consider adopting a `.gitignore` file to exclude files you don't want to track, such as personal notes stored in the same folder. You can find templates for `.gitignore` files at [.gitignore templates](https://github.com/github/gitignore).
#### Commit Messages
A great Git commit subject line completes the sentence:
If applied, this commit will <yoursubjectlinehere>.
"If applied, this commit will <yoursubjectlinehere>."
For the subject, use the imperative, present tense: "change" instead of "changed" or "changes."
In the optional body, also use the imperative, present tense. The body should explain the motivation for the change and contrast it with previous behavior. Focus on the `why`, not the `how`.
Similarly, in the optional body, use the imperative, present tense. The body should explain the motivation for the change and contrast it with previous behavior. Focus on the `why`, not the `how`.
✅ Take a few minutes to explore GitHub. Can you find an excellent commit message? How about a very minimal one? What information do you think is most important to include in a commit message?
✅ Spend a few minutes exploring GitHub. Can you find an excellent commit message? How about a very minimal one? What information do you think is most important to include in a commit message?
### Task: Collaborate
The main reason for using GitHub is to collaborate with other developers.
The primary reason for uploading projects to GitHub is to enable collaboration with other developers.
## Working on Projects with Others
@ -186,107 +186,112 @@ The main reason for using GitHub is to collaborate with other developers.
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
In your repository, go to `Insights > Community` to see how your project compares to recommended community standards.
In your repository, navigate to `Insights > Community` to see how your project aligns with recommended community standards.
Here are some ways to improve your GitHub repository:
- **Description**: Did you add a description for your project?
- **README**: Did you include a README? GitHub provides guidance for writing a [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Description**: Have you added a description for your project?
- **README**: Have you included a README? GitHub offers guidance for writing a [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Contributing Guidelines**: Does your project have [contributing guidelines](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Code of Conduct**: Does it include a [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **License**: Perhaps most importantly, does it have a [license](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Code of Conduct**: Have you added a [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **License**: Perhaps most importantly, have you added a [license](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
These resources help onboard new team members. They’re often the first things new contributors look at before even reviewing your code to decide if your project is worth their time.
These resources help onboard new team members. They're often the first things new contributors review before even looking at your code to determine if your project is worth their time.
✅ README files, though time-consuming to prepare, are often overlooked by busy maintainers. Can you find an example of a particularly detailed one? Note: There are [tools to help create good READMEs](https://www.makeareadme.com/) that you might want to try.
✅ README files, while time-consuming to prepare, are often overlooked by busy maintainers. Can you find an example of a particularly detailed README? Note: There are [tools to help create good READMEs](https://www.makeareadme.com/) that you might want to try.
### Task: Merge Some Code
### Task: Merge Code
Contributing documentation helps people contribute to your project. It explains what types of contributions you’re looking for and how the process works. Contributors will need to follow these steps to contribute to your GitHub repository:
Contributing documentation helps people contribute to your project. It explains the types of contributions you're looking for and outlines the process. Contributors will need to follow several steps to contribute to your GitHub repository:
1. **Fork your repository**. Contributors will likely_fork_ your project, creating a copy of your repository on their GitHub profile.
1. **Clone**. They’ll then clone the project to their local machine.
1. **Create a branch**. Ask them to create a _branch_ for their work.
1. **Focus on one area**. Encourage contributors to focus on one change at a time. This increases the likelihood of successfully merging their work. For example, if they fix a bug, add a feature, and update tests all at once, it might be harder to merge only part of their work.
1. **Fork your repository**: Contributors will likely need to_fork_ your project, creating a copy of your repository on their GitHub profile.
1. **Clone**: From there, they will clone the project to their local machine.
1. **Create a branch**: Ask contributors to create a _branch_ for their work.
1. **Focus on one area**: Encourage contributors to focus their changes on one specific area at a time. This increases the likelihood of successfully merging their work. For example, if they fix a bug, add a new feature, and update tests, you might only want to implement 1 or 2 of those changes.
✅ Think of situations where branches are essential for writing and shipping good code. What use cases come to mind?
✅ Think of situations where branches are particularly important for writing and shipping good code. What use cases come to mind?
> Note: Be the change you want to see in the world—create branches for your own work too. Any commits you make will be on the branch you’re currently “checked out” to. Use `git status` to see which branch you’re on.
> Note: Be the change you want to see in the world—create branches for your own work too. Any commits you make will apply to the branch you're currently "checked out" to. Use `git status` to see which branch you're on.
Let’s go through a contributor workflow. Assume the contributor has already _forked_ and _cloned_ the repository, so they have a Git repository ready to work on locally:
Let's walk through a contributor workflow. Assume the contributor has already _forked_ and _cloned_ the repository, so they have a Git repository ready to work on locally:
1. **Create a branch**. Use the `git branch` command to create a branch for the changes they want to contribute:
1. **Create a branch**: Use the `git branch` command to create a branch for the changes they plan to contribute:
```bash
git branch [branch-name]
```
1. **Switch to the working branch**. Switch to the specified branch and update the working directory with`git switch`:
1. **Switch to the working branch**: Switch to the specified branch and update the working directory using`git switch`:
```bash
git switch [branch-name]
```
1. **Do the work**. Add your changes. Don’t forget to tell Git about them using the following commands:
1. **Make changes**: Add your changes and inform Git using the following commands:
```bash
git add .
git commit -m "my changes"
```
Make sure to give your commit a meaningful name for your benefit and the repository maintainer.
Ensure your commit message is clear and descriptive for both yourself and the repository maintainer.
1. **Merge your work with the `main` branch**. When you’re done working, you’ll want to merge your changes with the `main` branch. Since the `main` branch might have changed in the meantime, update it first with the following commands:
1. **Merge your work with the `main` branch**: Once you're done working, you'll want to merge your changes with the `main` branch. Since the `main` branch might have changed in the meantime, update it first using the following commands:
```bash
git switch main
git pull
```
To ensure any _conflicts_ (situations where Git can’t easily combine changes) are resolved in your working branch, run the following commands:
To ensure any conflicts (situations where Git can't automatically merge changes) occur in your working branch, run the following commands:
```bash
git switch [branch_name]
git merge main
```
This brings all changes from `main` into your branch. If there are conflicts, VS Code will highlight them so you can resolve them.
The `git merge main` command incorporates all changes from `main` into your branch. Ideally, you can proceed without issues. If conflicts arise, VS Code will highlight where Git is "confused," allowing you to resolve the affected files.
To switch to a different branch, use the modern `git switch` command:
```bash
git switch [branch_name]
1. **Push your work to GitHub**. Pushing your work to GitHub involves two steps: pushing your branch to your repository and opening a Pull Request (PR).
1. **Push your work to GitHub**: Sending your work to GitHub involves two steps: pushing your branch to your repository and opening a Pull Request (PR).
```bash
git push --set-upstream origin [branch-name]
```
The above command creates the branch on your forked repository.
1. **Open a PR**. Next, you’ll want to open a PR. To do this, navigate to the forked repository on GitHub. GitHub will show an option asking if you want to create a new PR. Click on it, and you’ll be taken to an interface where you can edit the commit message title and provide a more suitable description. Now, the maintainer of the repository you forked will see this PR and, _fingers crossed_, they’ll appreciate it and _merge_ your PR. Congratulations, you’re now a contributor, yay! :)
1. **Open a PR**. Navigate to your forked repository on GitHub. You’ll see an option to create a new PR. Click it, and you’ll be taken to an interface where you can edit the commit message title and add a description. The maintainer of the original repository will review your PR and, hopefully, merge it. Congratulations, you’re now a contributor!
1. **Clean up**. After successfully merging a PR, it’s good practice to clean up. Delete the local branch with the following command:
1. **Clean up**. It’s considered good practice to _clean up_ after successfully merging a PR. You should clean up both your local branch and the branch you pushed to GitHub. First, delete it locally using the following command:
```bash
git branch -d [branch-name]
```
Then, go to the GitHub page for your forked repository and delete the remote branch you pushed.
`Pull request` might sound like a strange term since what you're actually doing is pushing your changes to the project. However, the maintainer (project owner) or core team needs to review your changes before merging them into the project's "main" branch. Essentially, you're requesting the maintainer's approval for your changes.
Next, go to the GitHub page for the forked repository and remove the remote branch you just pushed.
The term `Pull request` might sound a bit odd because you’re essentially pushing your changes to the project. However, the maintainer (project owner) or core team needs to review your changes before merging them into the project’s "main" branch. So, in reality, you’re requesting a decision from the maintainer to accept your changes.
A pull request is where you can compare and discuss the differences introduced in a branch, with reviews, comments, integrated tests, and more. A good pull request follows similar principles to a well-written commit message. You can also reference an issue in the issue tracker, for example, if your work resolves a specific issue. To do this, use a `#` followed by the issue number, like `#97`.
A pull request is a space where you can compare and discuss the differences introduced in a branch, with reviews, comments, integrated tests, and more. A good pull request follows similar rules to a commit message. You can also reference an issue in the issue tracker, especially if your work fixes a specific issue. To do this, use a `#` followed by the issue number, for example,`#97`.
🤞Here’s hoping all checks pass and the project owner(s) merge your changes into the project!🤞
🤞Fingers crossed that all checks pass and the project owner(s) merge your changes into the project 🤞
Update your current local working branch with all the latest commits from the corresponding remote branch on GitHub:
Update your current local working branch with all new commits from the corresponding remote branch on GitHub:
`git pull`
## How to contribute to open source
First, find a repository (or **repo**) on GitHub that interests you and to which you'd like to contribute. You'll need to copy its contents to your local machine.
First, find a repository (or **repo**) on GitHub that interests you and to which you’d like to contribute. You’ll need to copy its contents to your machine.
✅ A great way to find 'beginner-friendly' repositories is to [search for the tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ A great way to find 'beginner-friendly' repositories is to [search by the tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
There are several ways to copy code. One common method is to "clone" the repository using HTTPS, SSH, or the GitHub CLI (Command Line Interface).
There are several ways to copy code. One way is to "clone" the repository’s contents using HTTPS, SSH, or the GitHub CLI (Command Line Interface).
Open your terminal and clone the repository like this:
`git clone https://github.com/ProjectURL`
@ -294,25 +299,25 @@ Open your terminal and clone the repository like this:
To start working on the project, navigate to the correct folder:
`cd ProjectURL`
You can also open the entire project using [Codespaces](https://github.com/features/codespaces), GitHub's built-in code editor and cloud development environment, or [GitHub Desktop](https://desktop.github.com/).
You can also open the entire project using [Codespaces](https://github.com/features/codespaces), GitHub’s built-in code editor/cloud development environment, or [GitHub Desktop](https://desktop.github.com/).
Alternatively, you can download the code as a zipped folder.
### A few more interesting things about GitHub
You can star, watch, and/or "fork" any public repository on GitHub. Your starred repositories can be found in the drop-down menu in the top-right corner. Think of it as bookmarking, but for code.
You can star, watch, and/or "fork" any public repository on GitHub. Your starred repositories can be found in the drop-down menu at the top-right corner. It’s like bookmarking, but for code.
Projects typically have an issue tracker, usually found in the "Issues" tab on GitHub unless stated otherwise. This is where people discuss problems or ideas related to the project. The Pull Requests tab is where discussions and reviews of ongoing changes take place.
Projects typically have an issue tracker, usually found in the "Issues" tab on GitHub unless stated otherwise. This is where people discuss project-related issues. The Pull Requests tab is where people discuss and review ongoing changes.
Some projects may also have forums, mailing lists, or chat channels like Slack, Discord, or IRC for discussions.
Projects may also have discussions in forums, mailing lists, or chat channels like Slack, Discord, or IRC.
✅ Explore your new GitHub repository and try out a few features, like editing settings, adding information to your repo, or creating a project (such as a Kanban board). There's a lot to discover!
✅ Explore your new GitHub repository and try out a few features, like editing settings, adding information to your repo, and creating a project (like a Kanban board). There’s a lot to discover!
---
## 🚀 Challenge
Team up with a friend to work on each other's code. Create a project together, fork code, create branches, and merge changes.
Pair up with a friend to work on each other’s code. Collaboratively create a project, fork code, create branches, and merge changes.
Practice makes perfect! GitHub offers excellent learning paths at [skills.github.com](https://skills.github.com):
Practice, practice, practice. GitHub offers excellent learning paths via [skills.github.com](https://skills.github.com):
- [First Week on GitHub](https://skills.github.com/#first-week-on-github)
You can also find more advanced courses there.
You’ll also find more advanced courses.
## Assignment
@ -336,4 +341,4 @@ Complete [the First Week on GitHub course](https://skills.github.com/#first-week
---
**Disclaimer**:
This document has been translated using the AI translation service [Co-op Translator](https://github.com/Azure/co-op-translator). While we strive for accuracy, please note that automated translations may contain errors or inaccuracies. The original document in its native language should be regarded as the authoritative source. For critical information, professional human translation is recommended. We are not responsible for any misunderstandings or misinterpretations resulting from the use of this translation.
This document has been translated using the AI translation service [Co-op Translator](https://github.com/Azure/co-op-translator). While we aim for accuracy, please note that automated translations may contain errors or inaccuracies. The original document in its native language should be regarded as the authoritative source. For critical information, professional human translation is recommended. We are not responsible for any misunderstandings or misinterpretations resulting from the use of this translation.
@ -37,7 +37,7 @@ Si Git no está instalado, [descarga Git](https://git-scm.com/downloads). Luego,
Para verificar si Git ya está configurado, puedes escribir:
`git config --list`
También necesitarás una cuenta de GitHub, un editor de código (como Visual Studio Code) y abrir tu terminal (o símbolo del sistema).
También necesitarás una cuenta de GitHub, un editor de código (como Visual Studio Code) y abrir tu terminal (o: símbolo del sistema).
Navega a [github.com](https://github.com/) y crea una cuenta si aún no lo has hecho, o inicia sesión y completa tu perfil.
@ -45,7 +45,7 @@ Navega a [github.com](https://github.com/) y crea una cuenta si aún no lo has h
### Preparación
Necesitarás una carpeta con un proyecto de código en tu máquina local (laptop o PC) y un repositorio público en GitHub, que servirá como ejemplo de cómo contribuir a los proyectos de otros.
Necesitarás tanto una carpeta con un proyecto de código en tu máquina local (laptop o PC) como un repositorio público en GitHub, que servirá como ejemplo de cómo contribuir a los proyectos de otros.
---
@ -70,7 +70,7 @@ Supongamos que tienes una carpeta localmente con algún proyecto de código y qu
cd [name of your folder]
```
1. **Inicializa un repositorio de git**. En tu proyecto escribe:
1. **Inicializa un repositorio git**. En tu proyecto escribe:
```bash
git init
@ -104,31 +104,31 @@ Supongamos que tienes una carpeta localmente con algún proyecto de código y qu
El argumento `git add` más `.` indica que todos tus archivos y cambios serán rastreados.
1. **Agrega archivos seleccionados para rastrear**
1. **Agregar archivos seleccionados para rastrear**
```bash
git add [file or folder name]
```
Esto nos ayuda a agregar solo archivos seleccionados al área de preparación cuando no queremos confirmar todos los archivos a la vez.
Esto nos ayuda a agregar solo archivos seleccionados al área de preparación cuando no queremos confirmar todos los archivos de una vez.
1. **Quitar la preparación de todos los archivos**
1. **Quitar todos los archivos de la preparación**
```bash
git reset
```
Este comando nos ayuda a quitar la preparación de todos los archivos a la vez.
Este comando nos ayuda a quitar todos los archivos de la preparación de una vez.
1. **Quitar la preparación de un archivo en particular**
1. **Quitar un archivo en particular de la preparación**
```bash
git reset [file or folder name]
```
Este comando nos ayuda a quitar la preparación de solo un archivo en particular que no queremos incluir en la próxima confirmación.
Este comando nos ayuda a quitar solo un archivo en particular de la preparación que no queremos incluir en la próxima confirmación.
1. **Persistir tu trabajo**. En este punto, has agregado los archivos a un área llamada _área de preparación_. Un lugar donde Git está rastreando tus archivos. Para hacer el cambio permanente necesitas _confirmar_ los archivos. Para hacerlo, crea una _confirmación_ con el comando `git commit`. Una _confirmación_ representa un punto de guardado en la historia de tu repositorio. Escribe lo siguiente para crear una _confirmación_:
1. **Persistir tu trabajo**. En este punto has agregado los archivos a un área llamada _área de preparación_. Un lugar donde Git está rastreando tus archivos. Para hacer el cambio permanente necesitas _confirmar_ los archivos. Para hacerlo, crea una _confirmación_ con el comando `git commit`. Una _confirmación_ representa un punto de guardado en la historia de tu repositorio. Escribe lo siguiente para crear una _confirmación_:
```bash
git commit -m "first commit"
@ -154,7 +154,7 @@ Supongamos que tienes una carpeta localmente con algún proyecto de código y qu
git push -u origin main
```
Esto envía tus confirmaciones en tu rama "main" a GitHub.
Esto envía tus confirmaciones en tu rama "main" a GitHub. Configurar la rama `upstream` incluyendo `-u` en el comando establece un enlace entre tu rama local y la rama remota, para que puedas simplemente usar git push o git pull sin especificar el nombre de la rama en el futuro. Git usará automáticamente la rama upstream y no necesitarás especificar el nombre de la rama explícitamente en futuros comandos.
2. **Para agregar más cambios**. Si deseas continuar haciendo cambios y enviándolos a GitHub, solo necesitarás usar los siguientes tres comandos:
@ -192,13 +192,13 @@ En tu repositorio, navega a `Insights > Community` para ver cómo tu proyecto se
- **Descripción**. ¿Agregaste una descripción para tu proyecto?
- **README**. ¿Agregaste un README? GitHub proporciona orientación para escribir un [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Guía de contribución**. ¿Tu proyecto tiene [guías de contribución](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Código de conducta**. ¿Tiene un [Código de Conducta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Código de conducta**. ¿Tiene un [Código de Conducta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licencia**. Quizás lo más importante, ¿tiene una [licencia](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Todos estos recursos beneficiarán la incorporación de nuevos miembros al equipo. Y típicamente son el tipo de cosas que los nuevos contribuyentes miran antes de siquiera mirar tu código, para averiguar si tu proyecto es el lugar adecuado para que inviertan su tiempo.
Todos estos recursos beneficiarán la incorporación de nuevos miembros al equipo. Y típicamente son el tipo de cosas que los nuevos contribuyentes miran antes de siquiera mirar tu código, para averiguar si tu proyecto es el lugar adecuado para que dediquen su tiempo.
✅ Los archivos README, aunque toman tiempo para prepararse, a menudo son descuidados por los mantenedores ocupados. ¿Puedes encontrar un ejemplo de uno particularmente descriptivo? Nota: hay algunos [herramientas para ayudar a crear buenos READMEs](https://www.makeareadme.com/) que podrías querer probar.
✅ Los archivos README, aunque llevan tiempo prepararlos, a menudo son descuidados por los mantenedores ocupados. ¿Puedes encontrar un ejemplo de uno particularmente descriptivo? Nota: hay algunos [herramientas para ayudar a crear buenos READMEs](https://www.makeareadme.com/) que podrías querer probar.
### Tarea: Fusionar código
@ -207,15 +207,15 @@ Los documentos de contribución ayudan a las personas a contribuir al proyecto.
1. **Hacer un fork de tu repositorio**. Probablemente querrás que las personas _hagan un fork_ de tu proyecto. Hacer un fork significa crear una réplica de tu repositorio en su perfil de GitHub.
1. **Clonar**. Desde allí, clonarán el proyecto a su máquina local.
1. **Crear una rama**. Querrás pedirles que creen una _rama_ para su trabajo.
1. **Enfocar su cambio en un área**. Pide a los contribuyentes que concentren sus contribuciones en una sola cosa a la vez; de esa manera, las posibilidades de que puedas _fusionar_ su trabajo son mayores. Imagina que escriben una corrección de errores, agregan una nueva característica y actualizan varias pruebas; ¿qué pasa si quieres, o solo puedes implementar 2 de 3, o 1 de 3 cambios?
1. **Enfocar su cambio en un área**. Pide a los contribuyentes que concentren sus contribuciones en una sola cosa a la vez; de esa manera, las posibilidades de que puedas _fusionar_ su trabajo son mayores. Imagina que escriben una corrección de errores, agregan una nueva funcionalidad y actualizan varias pruebas; ¿qué pasa si quieres, o solo puedes implementar 2 de 3, o 1 de 3 cambios?
✅ Imagina una situación donde las ramas son particularmente críticas para escribir y enviar buen código. ¿Qué casos de uso se te ocurren?
✅ Imagina una situación donde las ramas son particularmente críticas para escribir y enviar buen código. ¿Qué casos de uso puedes pensar?
> Nota: sé el cambio que quieres ver en el mundo y crea ramas para tu propio trabajo también. Cualquier confirmación que hagas se realizará en la rama en la que estés "revisado". Usa `git status` para ver en qué rama estás.
> Nota: sé el cambio que quieres ver en el mundo y crea ramas para tu propio trabajo también. Cualquier confirmación que hagas se realizará en la rama en la que estés "ubicado". Usa `git status` para ver en qué rama estás.
Pasemos por un flujo de trabajo de contribuyente. Supongamos que el contribuyente ya ha _hecho un fork_ y _clonado_ el repositorio, por lo que tiene un repositorio de Git listo para trabajar en su máquina local:
Vamos a recorrer un flujo de trabajo de contribuyente. Supongamos que el contribuyente ya ha hecho un _fork_ y _clonado_ el repositorio, por lo que tiene un repositorio Git listo para trabajar en su máquina local:
1. **Crear una rama**. Usa el comando `git branch` para crear una rama que contendrá los cambios que planean contribuir:
1. **Crear una rama**. Usa el comando `git branch` para crear una rama que contendrá los cambios que planea contribuir:
```bash
git branch [branch-name]
@ -236,21 +236,26 @@ Pasemos por un flujo de trabajo de contribuyente. Supongamos que el contribuyent
Asegúrate de darle a tu confirmación un buen nombre, tanto para ti como para el mantenedor del repositorio al que estás ayudando.
1. **Combinar tu trabajo con la rama `main`**. En algún momento terminas de trabajar y quieres combinar tu trabajo con el de la rama `main`. La rama `main` podría haber cambiado mientras tanto, así que asegúrate de actualizarla primero con los siguientes comandos:
1. **Combinar tu trabajo con la rama `main`**. En algún momento habrás terminado de trabajar y querrás combinar tu trabajo con el de la rama `main`. La rama `main` podría haber cambiado mientras tanto, así que asegúrate de actualizarla primero con los siguientes comandos:
```bash
git switch main
git pull
```
En este punto, quieres asegurarte de que cualquier _conflicto_, situaciones donde Git no puede fácilmente _combinar_ los cambios, ocurra en tu rama de trabajo. Por lo tanto, ejecuta los siguientes comandos:
En este punto, querrás asegurarte de que cualquier _conflicto_, situaciones donde Git no puede fácilmente _combinar_ los cambios, ocurra en tu rama de trabajo. Por lo tanto, ejecuta los siguientes comandos:
```bash
git switch [branch_name]
git merge main
```
Esto traerá todos los cambios de `main` a tu rama y, con suerte, podrás continuar. Si no, VS Code te indicará dónde Git está _confundido_ y solo alteras los archivos afectados para decir qué contenido es el más preciso.
El comando `git merge main` traerá todos los cambios de `main` a tu rama. Con suerte, podrás continuar sin problemas. Si no, VS Code te indicará dónde Git está _confundido_ y solo tendrás que modificar los archivos afectados para indicar qué contenido es el más preciso.
Para cambiar a una rama diferente, usa el comando moderno `git switch`:
```bash
git switch [branch_name]
1. **Enviar tu trabajo a GitHub**. Enviar tu trabajo a GitHub significa dos cosas: empujar tu rama a tu repositorio y luego abrir un PR (Pull Request).
@ -259,27 +264,27 @@ Pasemos por un flujo de trabajo de contribuyente. Supongamos que el contribuyent
```
El comando anterior crea la rama en tu repositorio bifurcado.
1. **Abre un PR**. Ahora, quieres abrir un PR. Para hacerlo, navega al repositorio bifurcado en GitHub. Verás una indicación en GitHub que te pregunta si deseas crear un nuevo PR; haz clic en eso y serás llevado a una interfaz donde puedes cambiar el título del mensaje de confirmación y darle una descripción más adecuada. Ahora el mantenedor del repositorio que bifurcaste verá este PR y, _crucemos los dedos_, apreciará y _fusionará_ tu PR. ¡Ahora eres un colaborador, yay! :)
1. **Abrir un PR**. A continuación, quieres abrir un PR. Hazlo navegando al repositorio bifurcado en GitHub. Verás una indicación en GitHub donde pregunta si deseas crear un nuevo PR, haz clic en eso y serás llevado a una interfaz donde puedes cambiar el título del mensaje de confirmación, darle una descripción más adecuada. Ahora el mantenedor del repositorio que bifurcaste verá este PR y _crucemos los dedos_ apreciará y _fusionará_ tu PR. Ahora eres un contribuyente, ¡yay! :)
1. **Limpiar**. Se considera una buena práctica _limpiar_ después de fusionar exitosamente un PR. Quieres limpiar tanto tu rama local como la rama que empujaste a GitHub. Primero, eliminémosla localmente con el siguiente comando:
1. **Limpieza**. Se considera una buena práctica _limpiar_ después de fusionar exitosamente un PR. Quieres limpiar tanto tu rama local como la rama que empujaste a GitHub. Primero, eliminémosla localmente con el siguiente comando:
```bash
git branch -d [branch-name]
```
Asegúrate de ir a la página de GitHub del repositorio bifurcado y eliminar la rama remota que acabas de empujar.
Asegúrate de ir a la página de GitHub para el repositorio bifurcado y eliminar la rama remota que acabas de empujar.
`Pull request` parece un término extraño porque, en realidad, lo que quieres es enviar tus cambios al proyecto. Pero el mantenedor (propietario del proyecto) o el equipo principal necesita considerar tus cambios antes de fusionarlos con la rama "main" del proyecto, así que realmente estás solicitando una decisión de cambio al mantenedor.
`Pull request` parece un término extraño porque realmente quieres empujar tus cambios al proyecto. Pero el mantenedor (propietario del proyecto) o el equipo principal necesita considerar tus cambios antes de fusionarlos con la rama "principal" del proyecto, así que realmente estás solicitando una decisión de cambio a un mantenedor.
Un pull request es el lugar para comparar y discutir las diferencias introducidas en una rama con revisiones, comentarios, pruebas integradas y más. Un buen pull request sigue aproximadamente las mismas reglas que un mensaje de commit. Puedes agregar una referencia a un problema en el rastreador de problemas, por ejemplo, cuando tu trabajo soluciona un problema. Esto se hace usando un `#` seguido del número de tu problema. Por ejemplo, `#97`.
Un pull request es el lugar para comparar y discutir las diferencias introducidas en una rama con revisiones, comentarios, pruebas integradas y más. Un buen pull request sigue aproximadamente las mismas reglas que un mensaje de confirmación. Puedes agregar una referencia a un problema en el rastreador de problemas, por ejemplo, cuando tu trabajo soluciona un problema. Esto se hace usando un `#` seguido del número de tu problema. Por ejemplo, `#97`.
🤞Crucemos los dedos para que todas las verificaciones pasen y el/los propietario(s) del proyecto fusionen tus cambios en el proyecto🤞
🤞Crucemos los dedos para que todas las verificaciones pasen y el propietario(s) del proyecto fusionen tus cambios en el proyecto🤞
Actualiza tu rama de trabajo local actual con todos los nuevos commits de la rama remota correspondiente en GitHub:
`git pull`
## Cómo contribuir al código abierto
## Cómo contribuir a código abierto
Primero, busquemos un repositorio (o **repo**) en GitHub que te interese y al que te gustaría contribuir con un cambio. Querrás copiar su contenido a tu máquina.
@ -287,12 +292,12 @@ Primero, busquemos un repositorio (o **repo**) en GitHub que te interese y al qu
Hay varias formas de copiar código. Una forma es "clonar" el contenido del repositorio, usando HTTPS, SSH o la CLI (Interfaz de Línea de Comandos) de GitHub.
Hay varias formas de copiar código. Una forma es "clonar" el contenido del repositorio, usando HTTPS, SSH o utilizando la CLI (Interfaz de Línea de Comandos) de GitHub.
Abre tu terminal y clona el repositorio de esta manera:
Abre tu terminal y clona el repositorio de esta manera:
`git clone https://github.com/ProjectURL`
Para trabajar en el proyecto, cambia a la carpeta correcta:
Para trabajar en el proyecto, cambia a la carpeta correcta:
`cd ProjectURL`
También puedes abrir el proyecto completo usando [Codespaces](https://github.com/features/codespaces), el editor de código integrado / entorno de desarrollo en la nube de GitHub, o [GitHub Desktop](https://desktop.github.com/).
@ -301,9 +306,9 @@ Por último, puedes descargar el código en una carpeta comprimida.
### Algunas cosas interesantes sobre GitHub
Puedes marcar con estrella, seguir y/o "forkear" cualquier repositorio público en GitHub. Puedes encontrar tus repositorios marcados con estrella en el menú desplegable de la esquina superior derecha. Es como guardar favoritos, pero para código.
Puedes marcar con estrella, seguir y/o "bifurcar" cualquier repositorio público en GitHub. Puedes encontrar tus repositorios marcados con estrella en el menú desplegable de la esquina superior derecha. Es como guardar en favoritos, pero para código.
Los proyectos tienen un rastreador de problemas, generalmente en GitHub en la pestaña "Issues", a menos que se indique lo contrario, donde las personas discuten problemas relacionados con el proyecto. Y la pestaña de Pull Requests es donde las personas discuten y revisan los cambios que están en progreso.
Los proyectos tienen un rastreador de problemas, generalmente en GitHub en la pestaña "Issues" a menos que se indique lo contrario, donde las personas discuten problemas relacionados con el proyecto. Y la pestaña de Pull Requests es donde las personas discuten y revisan los cambios que están en progreso.
Los proyectos también pueden tener discusiones en foros, listas de correo o canales de chat como Slack, Discord o IRC.
@ -313,16 +318,16 @@ Los proyectos también pueden tener discusiones en foros, listas de correo o can
## 🚀 Desafío
Trabaja en pareja con un amigo para colaborar en el código del otro. Crea un proyecto de manera colaborativa, haz un fork del código, crea ramas y fusiona cambios.
Trabaja en pareja con un amigo para colaborar en el código de cada uno. Crea un proyecto de manera colaborativa, bifurca código, crea ramas y fusiona cambios.
Lee más sobre [cómo contribuir al software de código abierto](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Lee más sobre [cómo contribuir a software de código abierto](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Hoja de trucos de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
[Hoja de referencia de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Practica, practica, practica. GitHub tiene excelentes rutas de aprendizaje disponibles en [skills.github.com](https://skills.github.com):
@ -332,9 +337,9 @@ También encontrarás cursos más avanzados.
## Tarea
Completa [el curso de la Primera Semana en GitHub](https://skills.github.com/#first-week-on-github)
Completa [el curso Primera semana en GitHub](https://skills.github.com/#first-week-on-github)
---
**Descargo de responsabilidad**:
Este documento ha sido traducido utilizando el servicio de traducción automática [Co-op Translator](https://github.com/Azure/co-op-translator). Si bien nos esforzamos por lograr precisión, tenga en cuenta que las traducciones automáticas pueden contener errores o imprecisiones. El documento original en su idioma nativo debe considerarse como la fuente autorizada. Para información crítica, se recomienda una traducción profesional realizada por humanos. No nos hacemos responsables de malentendidos o interpretaciones erróneas que puedan surgir del uso de esta traducción.
Este documento ha sido traducido utilizando el servicio de traducción automática [Co-op Translator](https://github.com/Azure/co-op-translator). Aunque nos esforzamos por garantizar la precisión, tenga en cuenta que las traducciones automatizadas pueden contener errores o imprecisiones. El documento original en su idioma nativo debe considerarse como la fuente autorizada. Para información crítica, se recomienda una traducción profesional realizada por humanos. No nos hacemos responsables de malentendidos o interpretaciones erróneas que puedan surgir del uso de esta traducción.
> طراحی توسط [Tomomi Imura](https://twitter.com/girlie_mac)
## آزمون پیش از درس
[آزمون پیش از درس](https://ff-quizzes.netlify.app)
## مقدمه
در این درس، به موارد زیر خواهیم پرداخت:
در این درس، موارد زیر را پوشش خواهیم داد:
- پیگیری کارهایی که روی دستگاه خود انجام میدهید
- کار روی پروژهها به صورت گروهی
- کار کردن روی پروژهها با دیگران
- نحوه مشارکت در نرمافزارهای متنباز
### پیشنیازها
قبل از شروع، باید بررسی کنید که آیا Git روی سیستم شما نصب شده است یا خیر. در ترمینال تایپ کنید:
قبل از شروع، باید بررسی کنید که آیا Git نصب شده است یا خیر. در ترمینال تایپ کنید:
`git --version`
اگر Git نصب نشده است، [Git را دانلود کنید](https://git-scm.com/downloads). سپس پروفایل محلی Git خود را در ترمینال تنظیم کنید:
اگر Git نصب نشده است، [Git را دانلود کنید](https://git-scm.com/downloads). سپس، پروفایل محلی Git خود را در ترمینال تنظیم کنید:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
برای بررسی اینکه آیا Git قبلاً تنظیم شده است یا خیر، میتوانید تایپ کنید:
برای بررسی اینکه آیا Git قبلاً تنظیم شده است، میتوانید تایپ کنید:
`git config --list`
همچنین به یک حساب کاربری گیتهاب، یک ویرایشگر کد (مانند Visual Studio Code) و باز کردن ترمینال (یا: Command Prompt) نیاز دارید.
همچنین به یک حساب کاربری GitHub، یک ویرایشگر کد (مانند Visual Studio Code)، و دسترسی به ترمینال (یا: command prompt) نیاز دارید.
به [github.com](https://github.com/) بروید و اگر هنوز حساب کاربری ندارید، یک حساب ایجاد کنید یا وارد شوید و پروفایل خود را تکمیل کنید.
✅ گیتهاب تنها مخزن کد در جهان نیست؛ مخازن دیگری نیز وجود دارند، اما گیتهاب شناختهشدهترین است.
✅ GitHub تنها مخزن کد موجود در جهان نیست؛ مخازن دیگری نیز وجود دارند، اما GitHub شناختهشدهترین است.
### آمادهسازی
به یک پوشه حاوی یک پروژه کد روی دستگاه محلی خود (لپتاپ یا کامپیوتر شخصی) و یک مخزن عمومی در گیتهاب نیاز دارید که به عنوان نمونهای برای نحوه مشارکت در پروژههای دیگران عمل کند.
شما به یک پوشه با یک پروژه کد روی دستگاه محلی خود (لپتاپ یا کامپیوتر) و یک مخزن عمومی در GitHub نیاز دارید که به عنوان نمونهای برای نحوه مشارکت در پروژههای دیگران عمل کند.
---
## مدیریت کد
فرض کنید یک پوشه محلی با یک پروژه کد دارید و میخواهید پیشرفت خود را با استفاده از Git - سیستم کنترل نسخه - پیگیری کنید. برخی افراد استفاده از Git را به نوشتن یک نامه عاشقانه برای خود آیندهتان تشبیه میکنند. با خواندن پیامهای کامیت خود پس از روزها، هفتهها یا ماهها، میتوانید به یاد بیاورید که چرا تصمیمی گرفتهاید یا یک تغییر را "بازگردانید" - البته اگر پیامهای کامیت خوبی بنویسید.
فرض کنید یک پوشه محلی با یک پروژه کد دارید و میخواهید پیشرفت خود را با استفاده از Git - سیستم کنترل نسخه - پیگیری کنید. برخی افراد استفاده از Git را به نوشتن یک نامه عاشقانه برای خود آیندهتان تشبیه میکنند. با خواندن پیامهای commit خود پس از روزها، هفتهها یا ماهها، میتوانید به یاد بیاورید چرا تصمیمی گرفتهاید یا یک تغییر را "بازگردانی" کنید - البته اگر پیامهای commit خوبی بنویسید.
### وظیفه: ایجاد یک مخزن و کامیت کردن کد
### وظیفه: ایجاد یک مخزن و commit کردن کد
> ویدیو را بررسی کنید
> مشاهده ویدیو
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **ایجاد مخزن در گیتهاب**. در GitHub.com، در تب مخازن یا از نوار ناوبری بالا-راست، دکمه **مخزن جدید** را پیدا کنید.
1. **ایجاد مخزن در GitHub**. در GitHub.com، در تب مخازن یا از نوار ناوبری بالا سمت راست، دکمه **مخزن جدید** را پیدا کنید.
1. به مخزن خود (پوشه) یک نام بدهید.
1. گزینه **ایجاد مخزن** را انتخاب کنید.
1. **به پوشه کاری خود بروید**. در ترمینال، به پوشهای که میخواهید شروع به پیگیری آن کنید بروید. تایپ کنید:
1. **به پوشه کاری خود بروید**. در ترمینال، به پوشه (که به عنوان دایرکتوری نیز شناخته میشود) که میخواهید شروع به پیگیری کنید، بروید. تایپ کنید:
```bash
cd [name of your folder]
```
1. **یک مخزن Git را مقداردهی اولیه کنید**. در پروژه خود تایپ کنید:
1. **مخزن Git را مقداردهی اولیه کنید**. در پروژه خود تایپ کنید:
```bash
git init
```
1. **وضعیت را بررسی کنید**. برای بررسی وضعیت مخزن خود تایپ کنید:
1. **بررسی وضعیت**. برای بررسی وضعیت مخزن خود تایپ کنید:
```bash
git status
@ -93,70 +93,70 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
معمولاً دستور `git status` به شما میگوید که چه فایلهایی آماده _ذخیرهسازی_ در مخزن هستند یا تغییراتی روی آنها اعمال شده که ممکن است بخواهید آنها را ثبت کنید.
معمولاً دستور `git status` به شما اطلاعاتی مانند اینکه چه فایلهایی آماده _ذخیره_ در مخزن هستند یا تغییراتی دارند که ممکن است بخواهید حفظ کنید، میدهد.
1. **اضافه کردن تمام فایلها برای پیگیری**
این کار همچنین به عنوان مرحلهبندی فایلها/اضافه کردن فایلها به ناحیه مرحلهبندی شناخته میشود.
1. **اضافه کردن همه فایلها برای پیگیری**
این مرحله همچنین به عنوان مرحلهبندی فایلها/اضافه کردن فایلها به منطقه مرحلهبندی شناخته میشود.
```bash
git add .
```
دستور `git add` به همراه آرگومان `.` نشان میدهد که تمام فایلها و تغییرات برای پیگیری اضافه شوند.
آرگومان `git add` به همراه `.` نشان میدهد که همه فایلها و تغییرات برای پیگیری اضافه شدهاند.
1. **اضافه کردن فایلهای انتخابی برای پیگیری**
1. **اضافه کردن فایلهای انتخابشده برای پیگیری**
```bash
git add [file or folder name]
```
این دستور به ما کمک میکند فقط فایلهای انتخابی را به ناحیه مرحلهبندی اضافه کنیم، زمانی که نمیخواهیم همه فایلها را به یکباره کامیت کنیم.
این دستور به ما کمک میکند فقط فایلهای انتخابشده را به منطقه مرحلهبندی اضافه کنیم، زمانی که نمیخواهیم همه فایلها را به یکباره commit کنیم.
1. **خارج کردن تمام فایلها از مرحلهبندی**
1. **لغو مرحلهبندی همه فایلها**
```bash
git reset
```
این دستور به ما کمک میکند تمام فایلها را به یکباره از مرحلهبندی خارج کنیم.
این دستور به ما کمک میکند همه فایلها را به یکباره از مرحلهبندی خارج کنیم.
1. **خارج کردن یک فایل خاص از مرحلهبندی**
1. **لغو مرحلهبندی یک فایل خاص**
```bash
git reset [file or folder name]
```
این دستور به ما کمک میکند فقط یک فایل خاص را به یکباره از مرحلهبندی خارج کنیم که نمیخواهیم در کامیت بعدی شامل شود.
این دستور به ما کمک میکند فقط یک فایل خاص را به یکباره از مرحلهبندی خارج کنیم که نمیخواهیم برای commit بعدی شامل شود.
1. **ثبت کار خود**. در این مرحله فایلها را به اصطلاح به _ناحیه مرحلهبندی_ اضافه کردهاید. جایی که Git فایلهای شما را پیگیری میکند. برای دائمی کردن تغییرات، باید فایلها را _کامیت_ کنید. برای این کار یک _کامیت_ با دستور `git 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` این کار را انجام میدهد. دستور زیر را تایپ کنید:
1. **اتصال مخزن محلی Git خود به GitHub**. یک مخزن Git روی دستگاه شما خوب است، اما در نهایت میخواهید یک نسخه پشتیبان از فایلهای خود در جایی داشته باشید و همچنین دیگران را دعوت کنید تا با شما روی مخزن کار کنند. یکی از مکانهای عالی برای این کار GitHub است. به یاد داشته باشید که قبلاً یک مخزن در GitHub ایجاد کردهایم، بنابراین تنها کاری که باید انجام دهیم اتصال مخزن محلی Git به GitHub است. دستور `git remote add` این کار را انجام میدهد. دستور زیر را تایپ کنید:
> توجه داشته باشید، قبل از تایپ دستور به صفحه مخزن گیتهاب خود بروید تا URL مخزن را پیدا کنید. از آن در دستور زیر استفاده کنید. ```https://github.com/username/repository_name.git``` را با URL گیتهاب خود جایگزین کنید.
> توجه داشته باشید، قبل از تایپ دستور به صفحه مخزن GitHub خود بروید تا URL مخزن را پیدا کنید. شما از آن در دستور زیر استفاده خواهید کرد. ```https://github.com/username/repository_name.git``` را با URL GitHub خود جایگزین کنید.
این دستور یک _remote_ یا اتصال به نام "origin" ایجاد میکند که به مخزن گیتهاب که قبلاً ایجاد کردهاید اشاره میکند.
این دستور یک _remote_ یا اتصال به نام "origin" ایجاد میکند که به مخزن GitHub که قبلاً ایجاد کردهاید اشاره دارد.
1. **ارسال فایلهای محلی به گیتهاب**. تا اینجا یک _اتصال_ بین مخزن محلی و مخزن گیتهاب ایجاد کردهاید. حالا این فایلها را با دستور `git push` به گیتهاب ارسال کنید، به این صورت:
> توجه داشته باشید، نام شاخه شما ممکن است به طور پیشفرض با ```main``` متفاوت باشد.
1. **ارسال فایلهای محلی به GitHub**. تا اینجا یک _اتصال_ بین مخزن محلی و مخزن GitHub ایجاد کردهاید. بیایید این فایلها را با دستور `git push` به GitHub ارسال کنیم، به این صورت:
> توجه داشته باشید، نام شاخه شما ممکن است به طور پیشفرض متفاوت از ```main``` باشد.
```bash
git push -u origin main
```
این دستور کامیتهای شما را در شاخه "main" به گیتهاب ارسال میکند.
این دستور commitهای شما را در شاخه "main" به GitHub ارسال میکند. تنظیم شاخه `upstream` شامل `-u` در دستور، یک لینک بین شاخه محلی و شاخه remote ایجاد میکند، بنابراین میتوانید به سادگی از git push یا git pull بدون مشخص کردن نام شاخه در آینده استفاده کنید. Git به طور خودکار از شاخه upstream استفاده میکند و نیازی به مشخص کردن نام شاخه به طور صریح در دستورات آینده نخواهید داشت.
2. **اضافه کردن تغییرات بیشتر**. اگر میخواهید به ایجاد تغییرات و ارسال آنها به گیتهاب ادامه دهید، فقط باید از سه دستور زیر استفاده کنید:
2. **اضافه کردن تغییرات بیشتر**. اگر میخواهید به ایجاد تغییرات و ارسال آنها به GitHub ادامه دهید، فقط باید از سه دستور زیر استفاده کنید:
```bash
git add .
@ -164,57 +164,57 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> نکته: ممکن است بخواهید از یک فایل `.gitignore` استفاده کنید تا فایلهایی که نمیخواهید پیگیری شوند در گیتهاب ظاهر نشوند - مانند فایل یادداشتی که در همان پوشه ذخیره میکنید اما جایی در یک مخزن عمومی ندارد. میتوانید قالبهای فایل `.gitignore` را در [.gitignore templates](https://github.com/github/gitignore) پیدا کنید.
> نکته، ممکن است بخواهید یک فایل `.gitignore` را اتخاذ کنید تا فایلهایی که نمیخواهید پیگیری شوند در GitHub ظاهر نشوند - مانند فایل یادداشتهایی که در همان پوشه ذخیره میکنید اما جایی در یک مخزن عمومی ندارند. میتوانید قالبهای فایل `.gitignore` را در [.gitignore templates](https://github.com/github/gitignore) پیدا کنید.
#### پیامهای کامیت
#### پیامهای commit
یک خط موضوعی عالی برای کامیت Git جمله زیر را کامل میکند:
اگر اعمال شود، این کامیت <خط موضوعی شما اینجا> را انجام خواهد داد.
یک خط موضوع عالی برای commit در Git جمله زیر را کامل میکند:
اگر اعمال شود، این commit <خط موضوع شما در اینجا> خواهد بود.
برای موضوع از زمان حال و حالت امری استفاده کنید: "تغییر" نه "تغییر داده شد" و نه "تغییرات".
همانطور که در موضوع، در بدنه (اختیاری) نیز از زمان حال و حالت امری استفاده کنید. بدنه باید انگیزه تغییر را شامل شود و این را با رفتار قبلی مقایسه کند. شما در حال توضیح دادن `چرا` هستید، نه `چگونه`.
برای موضوع از زمان حال و حالت امری استفاده کنید: "تغییر" نه "تغییر داده شده" و نه "تغییرات".
همانطور که در موضوع، در متن (اختیاری) نیز از زمان حال و حالت امری استفاده کنید. متن باید انگیزه تغییر را شامل شود و این را با رفتار قبلی مقایسه کند. شما در حال توضیح دادن `چرا` هستید، نه `چگونه`.
✅ چند دقیقه وقت بگذارید و در گیتهاب جستجو کنید. آیا میتوانید یک پیام کامیت واقعاً عالی پیدا کنید؟ آیا میتوانید یک پیام کامیت بسیار مختصر پیدا کنید؟ به نظر شما چه اطلاعاتی مهمترین و مفیدترین برای انتقال در یک پیام کامیت است؟
✅ چند دقیقه وقت بگذارید و در GitHub جستجو کنید. آیا میتوانید یک پیام commit واقعاً عالی پیدا کنید؟ آیا میتوانید یک پیام بسیار مختصر پیدا کنید؟ به نظر شما چه اطلاعاتی مهمترین و مفیدترین برای انتقال در یک پیام commit هستند؟
### وظیفه: همکاری
دلیل اصلی قرار دادن چیزها در گیتهاب این بود که امکان همکاری با دیگر توسعهدهندگان فراهم شود.
دلیل اصلی قرار دادن چیزها در GitHub این بود که امکان همکاری با سایر توسعهدهندگان فراهم شود.
## کار روی پروژهها با دیگران
## کار کردن روی پروژهها با دیگران
> ویدیو را بررسی کنید
> مشاهده ویدیو
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
در مخزن خود، به `Insights > Community` بروید تا ببینید پروژه شما چگونه با استانداردهای پیشنهادی جامعه مقایسه میشود.
در مخزن خود، به `Insights > Community` بروید تا ببینید پروژه شما چگونه با استانداردهای جامعه توصیهشده مقایسه میشود.
در اینجا چند مورد وجود دارد که میتواند مخزن گیتهاب شما را بهبود بخشد:
در اینجا چند مورد وجود دارد که میتواند مخزن GitHub شما را بهبود بخشد:
- **توضیحات**. آیا توضیحی برای پروژه خود اضافه کردهاید؟
- **README**. آیا یک README اضافه کردهاید؟ گیتهاب راهنماییهایی برای نوشتن یک [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) ارائه میدهد.
- **README**. آیا یک README اضافه کردهاید؟ GitHub راهنماییهایی برای نوشتن یک [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/) اضافه کردهاید؟
- **کد رفتار**. آیا پروژه شما دارای [کد رفتار](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/).
✅ فایلهای README، اگرچه زمانبر هستند، اغلب توسط نگهدارندگان مشغول نادیده گرفته میشوند. آیا میتوانید نمونهای از یک README بسیار توصیفی پیدا کنید؟ توجه: برخی [ابزارها برای کمک به ایجاد READMEهای خوب](https://www.makeareadme.com/) وجود دارند که ممکن است بخواهید امتحان کنید.
### وظیفه: ادغام کد
مستندات مشارکت به افراد کمک میکند تا در پروژه مشارکت کنند. این مستندات توضیح میدهد که چه نوع مشارکتهایی مورد نظر است و فرآیند چگونه کار میکند. مشارکتکنندگان باید مراحل مختلفی را برای مشارکت در مخزن شما در گیتهاب طی کنند:
مستندات مشارکت به افراد کمک میکند تا در پروژه مشارکت کنند. این مستندات توضیح میدهد که چه نوع مشارکتهایی مورد نظر است و فرآیند چگونه کار میکند. مشارکتکنندگان باید مراحل مختلفی را طی کنند تا بتوانند در مخزن شما در GitHub مشارکت کنند:
1. **فورک کردن مخزن شما**. احتمالاً میخواهید افراد پروژه شما را _فورک_ کنند. فورک کردن به معنای ایجاد یک نسخه کپی از مخزن شما در پروفایل گیتهاب آنها است.
1. **کلون کردن**. از آنجا، آنها پروژه را به دستگاه محلی خود کلون میکنند.
1. **ایجاد یک شاخه**. شما میخواهید از آنها بخواهید یک _شاخه_ برای کار خود ایجاد کنند.
1. **تمرکز تغییرات روی یک بخش**. از مشارکتکنندگان بخواهید تغییرات خود را روی یک چیز در یک زمان متمرکز کنند - به این ترتیب احتمال اینکه بتوانید کار آنها را _ادغام_ کنید بیشتر است. تصور کنید آنها یک باگ را رفع کنند، یک ویژگی جدید اضافه کنند و چندین تست را بهروزرسانی کنند - اگر بخواهید یا بتوانید فقط ۲ از ۳ یا ۱ از ۳ تغییر را اعمال کنید چه؟
1. **فورک کردن مخزن شما**. احتمالاً میخواهید افراد پروژه شما را _فورک_ کنند. فورک کردن به معنای ایجاد یک نسخه کپی از مخزن شما در پروفایل GitHub آنها است.
1. **کلون کردن**. از آنجا آنها پروژه را به دستگاه محلی خود کلون خواهند کرد.
1. **ایجاد یک شاخه**. شما میخواهید از آنها بخواهید یک _شاخه_ برای کار خود ایجاد کنند.
1. **تمرکز تغییرات روی یک بخش**. از مشارکتکنندگان بخواهید مشارکتهای خود را روی یک چیز در یک زمان متمرکز کنند - به این ترتیب احتمال اینکه بتوانید کار آنها را _ادغام_ کنید بیشتر است. تصور کنید آنها یک رفع اشکال بنویسند، یک ویژگی جدید اضافه کنند، و چندین تست را بهروزرسانی کنند - اگر بخواهید یا بتوانید فقط 2 از 3 یا 1 از 3 تغییر را اجرا کنید چه؟
✅ یک موقعیت را تصور کنید که در آن شاخهها برای نوشتن و ارائه کد خوب به خصوص حیاتی هستند. چه موارد استفادهای میتوانید تصور کنید؟
✅ یک وضعیت را تصور کنید که شاخهها برای نوشتن و ارسال کد خوب بهویژه حیاتی هستند. چه موارد استفادهای میتوانید تصور کنید؟
> توجه: تغییری باشید که میخواهید در جهان ببینید و برای کار خود نیز شاخه ایجاد کنید. هر کامیتی که انجام دهید در شاخهای که در حال حاضر "چکاوت" شدهاید انجام خواهد شد. از `git status` استفاده کنید تا ببینید در کدام شاخه هستید.
> توجه، تغییراتی که میخواهید در جهان ببینید باشید و برای کار خود نیز شاخه ایجاد کنید. هر commitی که انجام دهید روی شاخهای که در حال حاضر "چک شده" هستید انجام خواهد شد. از `git status` استفاده کنید تا ببینید کدام شاخه است.
بیایید یک جریان کاری مشارکتکننده را مرور کنیم. فرض کنید مشارکتکننده قبلاً مخزن را _فورک_ و _کلون_ کرده است، بنابراین یک مخزن Git آماده برای کار روی دستگاه محلی خود دارد:
بیایید یک جریان کاری مشارکتکننده را مرور کنیم. فرض کنید مشارکتکننده قبلاً مخزن را _فورک_ و _کلون_ کرده است، بنابراین آنها یک مخزن Git آماده برای کار روی دستگاه محلی خود دارند:
1. **ایجاد یک شاخه**. از دستور `git branch` برای ایجاد یک شاخه که شامل تغییراتی است که قصد دارند مشارکت کنند استفاده کنید:
1. **ایجاد یک شاخه**. از دستور `git branch` برای ایجاد یک شاخه که شامل تغییراتی است که قصد دارند مشارکت کنند، استفاده کنید:
```bash
git branch [branch-name]
@ -226,16 +226,16 @@ CO_OP_TRANSLATOR_METADATA:
git switch [branch-name]
```
1. **انجام کار**. در این مرحله میخواهید تغییرات خود را اضافه کنید. فراموش نکنید که با دستورات زیر به Git اطلاع دهید:
1. **انجام کار**. در این مرحله میخواهید تغییرات خود را اضافه کنید. فراموش نکنید که به Git اطلاع دهید با دستورات زیر:
```bash
git add .
git commit -m "my changes"
```
اطمینان حاصل کنید که به کامیت خود یک نام خوب بدهید، برای خودتان و همچنین نگهدارنده مخزنی که در آن کمک میکنید.
مطمئن شوید که به commit خود یک نام خوب بدهید، برای خودتان و همچنین نگهدارنده مخزنی که در آن کمک میکنید.
1. **ترکیب کار خود با شاخه `main`**. در یک نقطه، کار شما تمام شده و میخواهید کار خود را با شاخه `main` ترکیب کنید. ممکن است شاخه `main` در این بین تغییر کرده باشد، بنابراین مطمئن شوید که ابتدا آن را با دستورات زیر بهروزرسانی کنید:
1. **ترکیب کار خود با شاخه `main`**. در یک نقطه شما کار خود را تمام کردهاید و میخواهید کار خود را با کار شاخه `main` ترکیب کنید. شاخه `main` ممکن است در این بین تغییر کرده باشد، بنابراین مطمئن شوید که ابتدا آن را با دستورات زیر به آخرین نسخه بهروزرسانی کنید:
```bash
git switch main
@ -249,85 +249,90 @@ CO_OP_TRANSLATOR_METADATA:
git merge main
```
این دستور تمام تغییرات از `main` را به شاخه شما میآورد و امیدواریم بتوانید به کار خود ادامه دهید. اگر نه، VS Code به شما میگوید که Git کجا _گیج_ شده است و شما فقط فایلهای مربوطه را تغییر میدهید تا بگویید کدام محتوا دقیقتر است.
دستور `git merge main` تمام تغییرات از `main` را به شاخه شما میآورد. امیدواریم بتوانید به سادگی ادامه دهید. اگر نه، VS Code به شما میگوید که Git کجا _گیج_ شده است و فقط فایلهای مربوطه را تغییر دهید تا بگویید کدام محتوا دقیقتر است.
برای تغییر به یک شاخه دیگر، از دستور مدرن `git switch` استفاده کنید:
```bash
git switch [branch_name]
1. **ارسال کار خود به گیتهاب**. ارسال کار خود به گیتهاب به دو چیز نیاز دارد. ارسال شاخه خود به مخزن و سپس باز کردن یک PR، درخواست کشیدن.
1. **ارسال کار خود به GitHub**. ارسال کار خود به GitHub به دو چیز نیاز دارد. ارسال شاخه خود به مخزن و سپس باز کردن یک PR، درخواست کشیدن.
```bash
git push --set-upstream origin [branch-name]
```
دستور بالا شاخه را در مخزن فورکشده شما ایجاد میکند.
1. **باز کردن یک PR**. حالا میخواهید یک PR باز کنید. برای این کار به مخزن فورکشده در GitHub بروید. در GitHub یک اعلان خواهید دید که از شما میپرسد آیا میخواهید یک PR جدید ایجاد کنید. روی آن کلیک کنید و به صفحهای هدایت میشوید که میتوانید عنوان پیام کامیت را تغییر دهید و توضیح مناسبتری به آن اضافه کنید. حالا نگهدارنده مخزنی که فورک کردهاید این PR را میبیند و _انگشتان را برای شانس خوب فشار دهید_ امیدواریم که از آن قدردانی کند و PR شما را _ادغام_ کند. حالا شما یک مشارکتکننده هستید، یای :)
1. **باز کردن یک PR**. سپس، میخواهید یک PR باز کنید. این کار را با رفتن به مخزن فورکشده در گیتهاب انجام دهید. در گیتهاب یک اعلان خواهید دید که از شما میپرسد آیا میخواهید یک PR جدید ایجاد کنید، روی آن کلیک کنید و به رابطی هدایت میشوید که میتوانید عنوان پیام کامیت را تغییر دهید و توضیحات مناسبتری بدهید. اکنون نگهدارنده مخزنی که فورک کردهاید این PR را میبیند و _انگشتان را ضربدری کنید_ از آن قدردانی کرده و PR شما را _ادغام_ میکند. اکنون شما یک مشارکتکننده هستید، تبریک :)
1. **پاکسازی**. پاکسازی پس از موفقیت در ادغام یک PR به عنوان یک عمل خوب در نظر گرفته میشود. میخواهید هم شاخه محلی و هم شاخهای که به گیتهاب ارسال کردهاید را پاک کنید. ابتدا اجازه دهید آن را به صورت محلی با دستور زیر حذف کنیم:
1. **پاکسازی**. بعد از اینکه یک PR را با موفقیت ادغام کردید، بهتر است که _پاکسازی_ انجام دهید. باید هم شاخه محلی و هم شاخهای که به GitHub ارسال کردهاید را پاک کنید. ابتدا با دستور زیر آن را به صورت محلی حذف کنید:
```bash
git branch -d [branch-name]
```
سپس به صفحه GitHub مخزن فورکشده بروید و شاخه ریموتی که به آن ارسال کردهاید را حذف کنید.
اطمینان حاصل کنید که به صفحه گیتهاب برای مخزن فورکشده بروید و شاخه ریموتی که به آن ارسال کردهاید را حذف کنید.
اصطلاح «Pull request» ممکن است کمی عجیب به نظر برسد، چون در واقع شما میخواهید تغییرات خود را به پروژه ارسال کنید. اما مالک پروژه یا تیم اصلی باید تغییرات شما را قبل از ادغام با شاخه اصلی پروژه بررسی کند، بنابراین در واقع شما درخواست تصمیمگیری در مورد تغییرات خود را از یک نگهدارنده پروژه دارید.
`Pull request` شاید اصطلاح عجیبی به نظر برسد چون در واقع شما میخواهید تغییرات خود را به پروژه ارسال کنید. اما نگهدارنده (مالک پروژه) یا تیم اصلی باید تغییرات شما را قبل از ادغام با شاخه "اصلی" پروژه بررسی کند، بنابراین در واقع شما درخواست تصمیمگیری برای تغییرات را از نگهدارنده میکنید.
یک Pull request جایی است که میتوانید تفاوتهای ایجاد شده در یک شاخه را با استفاده از بررسیها، نظرات، تستهای یکپارچه و موارد دیگر مقایسه و درباره آنها بحث کنید. یک Pull request خوب تقریباً از همان قوانینی پیروی میکند که برای پیامهای commit وجود دارد. شما میتوانید به یک issue در ردیاب مشکلات ارجاع دهید، مثلاً وقتی کار شما یک مشکل را حل میکند. این کار با استفاده از `#` و شماره issue انجام میشود. برای مثال:`#97`.
یک pull request جایی است که میتوانید تفاوتهای ایجاد شده در یک شاخه را با بررسیها، نظرات، تستهای یکپارچه و موارد دیگر مقایسه و بحث کنید. یک pull request خوب تقریباً از همان قواعد پیام کامیت پیروی میکند. میتوانید به یک مشکل در ردیاب مشکلات اشاره کنید، مثلاً وقتی کار شما یک مشکل را حل میکند. این کار با استفاده از `#` و سپس شماره مشکل انجام میشود. برای مثال`#97`.
🤞 امیدواریم که همه بررسیها موفقیتآمیز باشند و مالک(های) پروژه تغییرات شما را در پروژه ادغام کنند🤞
🤞انگشتان را برای شانس خوب فشار دهید که همه بررسیها موفق باشند و مالک(های) پروژه تغییرات شما را در پروژه ادغام کنند🤞
شاخه کاری محلی خود را با تمام commitهای جدید از شاخه متناظر در GitHub بهروزرسانی کنید:
شاخه کاری محلی فعلی خود را با تمام کامیتهای جدید از شاخه ریموت مربوطه در GitHub بهروزرسانی کنید:
`git pull`
## چگونه به پروژههای متنباز کمک کنیم
## چگونه به منبع باز کمک کنیم
ابتدا، یک مخزن (یا **repo**) در GitHub پیدا کنید که برای شما جالب باشد و بخواهید تغییری در آن ایجاد کنید. شما باید محتوای آن را به دستگاه خود کپی کنید.
✅ یک روش خوب برای پیدا کردن مخازن مناسب برای مبتدیان این است که [با برچسب 'good-first-issue' جستجو کنید](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ یک راه خوب برای پیدا کردن مخازن مناسب برای مبتدیان این است که [با برچسب 'good-first-issue' جستجو کنید](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
روشهای مختلفی برای کپی کردن کد وجود دارد. یکی از روشها "کلون کردن" محتوای مخزن با استفاده از HTTPS، SSH یا GitHub CLI (رابط خط فرمان GitHub) است.
ترمینال خود را باز کنید و مخزن را به این صورت کلون کنید:
ترمینال خود را باز کنید و مخزن را به این صورت کلون کنید:
`git clone https://github.com/ProjectURL`
برای کار روی پروژه، به پوشه مناسب بروید:
برای کار روی پروژه، به پوشه مناسب بروید:
`cd ProjectURL`
همچنین میتوانید کل پروژه را با استفاده از [Codespaces](https://github.com/features/codespaces)، ویرایشگر کد داخلی GitHub / محیط توسعه ابری، یا [GitHub Desktop](https://desktop.github.com/) باز کنید.
در نهایت، میتوانید کد را در یک پوشه فشرده دانلود کنید.
در نهایت، میتوانید کد را در یک پوشه زیپشده دانلود کنید.
### چند نکته جالب دیگر درباره GitHub
شما میتوانید هر مخزن عمومی در GitHub را ستارهدار کنید، دنبال کنید یا "fork" کنید. مخازن ستارهدار خود را میتوانید در منوی کشویی بالا سمت راست پیدا کنید. این کار شبیه به نشانکگذاری است، اما برای کد.
شما میتوانید هر مخزن عمومی در GitHub را ستارهدار کنید، دنبال کنید یا "فورک" کنید. مخازن ستارهدار خود را میتوانید در منوی کشویی بالا سمت راست پیدا کنید. این شبیه به بوکمارک کردن است، اما برای کد.
پروژهها معمولاً یک ردیاب مشکلات دارند، که بیشتر در تب "Issues" در GitHub قرار دارد مگر اینکه به شکل دیگری مشخص شده باشد، جایی که افراد درباره مشکلات مربوط به پروژه بحث میکنند. تب Pull Requests جایی است که افراد درباره تغییرات در حال انجام بحث و بررسی میکنند.
پروژهها یک ردیاب مشکلات دارند، معمولاً در تب "Issues" در GitHub مگر اینکه به شکل دیگری مشخص شده باشد، جایی که افراد درباره مشکلات مربوط به پروژه بحث میکنند. و تب Pull Requests جایی است که افراد درباره تغییراتی که در حال انجام است بحث و بررسی میکنند.
پروژهها ممکن است بحثهایی در انجمنها، لیستهای ایمیل یا کانالهای چت مانند Slack، Discord یا IRC داشته باشند.
پروژهها ممکن است همچنین بحثهایی در انجمنها، لیستهای ایمیل یا کانالهای چت مانند Slack، Discord یا IRC داشته باشند.
✅ نگاهی به مخزن جدید GitHub خود بیندازید و چند کار انجام دهید، مثل ویرایش تنظیمات، افزودن اطلاعات به مخزن خود، و ایجاد یک پروژه (مثل یک تخته Kanban). کارهای زیادی میتوانید انجام دهید!
✅ به مخزن جدید GitHub خود نگاهی بیندازید و چند کار انجام دهید، مانند ویرایش تنظیمات، افزودن اطلاعات به مخزن خود و ایجاد یک پروژه (مانند یک تخته کانبان). کارهای زیادی میتوانید انجام دهید!
---
## 🚀 چالش
با یک دوست همکاری کنید و روی کد یکدیگر کار کنید. یک پروژه به صورت مشترک ایجاد کنید، کد را fork کنید، شاخه ایجاد کنید و تغییرات را ادغام کنید.
با یک دوست همکاری کنید و روی کد یکدیگر کار کنید. یک پروژه به صورت مشترک ایجاد کنید، کد را فورک کنید، شاخه ایجاد کنید و تغییرات را ادغام کنید.
## آزمون پس از درس
## آزمون پس از درس
[آزمون پس از درس](https://ff-quizzes.netlify.app/web/en/)
## مرور و مطالعه شخصی
بیشتر درباره [کمک به نرمافزارهای متنباز](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution) بخوانید.
بیشتر درباره [کمک به نرمافزارهای منبع باز](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution) بخوانید.
تمرین، تمرین، تمرین. GitHub مسیرهای یادگیری عالیای از طریق [skills.github.com](https://skills.github.com) ارائه میدهد:
تمرین، تمرین، تمرین. GitHub مسیرهای یادگیری عالی از طریق [skills.github.com](https://skills.github.com) ارائه میدهد:
- [هفته اول در GitHub](https://skills.github.com/#first-week-on-github)
همچنین دورههای پیشرفتهتری نیز پیدا خواهید کرد.
همچنین دورههای پیشرفتهتری نیز خواهید یافت.
## تکلیف
@ -336,4 +341,4 @@ CO_OP_TRANSLATOR_METADATA:
---
**سلب مسئولیت**:
این سند با استفاده از سرویس ترجمه هوش مصنوعی [Co-op Translator](https://github.com/Azure/co-op-translator) ترجمه شده است. در حالی که ما برای دقت تلاش میکنیم، لطفاً توجه داشته باشید که ترجمههای خودکار ممکن است شامل خطاها یا نادرستیهایی باشند. سند اصلی به زبان اصلی آن باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حساس، ترجمه حرفهای انسانی توصیه میشود. ما هیچ مسئولیتی در قبال سوءتفاهمها یا تفسیرهای نادرست ناشی از استفاده از این ترجمه نداریم.
این سند با استفاده از سرویس ترجمه هوش مصنوعی [Co-op Translator](https://github.com/Azure/co-op-translator) ترجمه شده است. در حالی که ما تلاش میکنیم دقت را حفظ کنیم، لطفاً توجه داشته باشید که ترجمههای خودکار ممکن است شامل خطاها یا نادرستیها باشند. سند اصلی به زبان اصلی آن باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حساس، توصیه میشود از ترجمه حرفهای انسانی استفاده کنید. ما هیچ مسئولیتی در قبال سوءتفاهمها یا تفسیرهای نادرست ناشی از استفاده از این ترجمه نداریم.
@ -23,21 +23,21 @@ Tässä oppitunnissa käsitellään:
- työn seuraamista omalla koneellasi
- projektien tekemistä yhdessä muiden kanssa
- avoimen lähdekoodin ohjelmistojen kehittämiseen osallistumista
- avoimen lähdekoodin ohjelmistojen kehittämistä
### Esivaatimukset
Ennen kuin aloitat, tarkista, onko Git asennettuna. Kirjoita terminaaliin:
Ennen kuin aloitat, tarkista, onko Git asennettu. Kirjoita terminaaliin:
`git --version`
Jos Git ei ole asennettuna, [lataa Git](https://git-scm.com/downloads). Sen jälkeen määritä paikallinen Git-profiilisi terminaalissa:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
Tarkistaaksesi, onko Git jo määritetty, voit kirjoittaa:
Voit tarkistaa, onko Git jo määritetty, kirjoittamalla:
`git config --list`
Tarvitset myös GitHub-tilin, koodieditorin (kuten Visual Studio Code) ja sinun tulee avata terminaali (tai komentokehote).
Tarvitset myös GitHub-tilin, koodieditorin (kuten Visual Studio Code) ja pääsyn terminaaliin (tai komentokehotteeseen).
Siirry osoitteeseen [github.com](https://github.com/) ja luo tili, jos sinulla ei vielä ole sellaista, tai kirjaudu sisään ja täytä profiilisi.
@ -45,13 +45,13 @@ Siirry osoitteeseen [github.com](https://github.com/) ja luo tili, jos sinulla e
### Valmistelu
Tarvitset sekä koodiprojektin sisältävän kansion paikallisella koneellasi (kannettava tai PC) että julkisen GitHub-repositorion, joka toimii esimerkkinä siitä, miten osallistua muiden projekteihin.
Tarvitset sekä koodiprojektin sisältävän kansion paikallisella koneellasi (kannettava tai PC) että julkisen GitHub-repositorion, joka toimii esimerkkinä siitä, miten voit osallistua muiden projekteihin.
---
## Koodin hallinta
Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja haluat alkaa seurata edistymistäsi käyttämällä git-versiohallintajärjestelmää. Jotkut vertaavat gitin käyttöä rakkauskirjeen kirjoittamiseen tulevaisuuden itsellesi. Kun luet commit-viestejäsi päivien, viikkojen tai kuukausien jälkeen, pystyt muistamaan, miksi teit tietyn päätöksen, tai "peruuttaa" muutoksen – kunhan kirjoitat hyviä commit-viestejä.
Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja haluat alkaa seurata edistymistäsi käyttämällä git-versiohallintajärjestelmää. Jotkut vertaavat gitin käyttöä rakkauskirjeen kirjoittamiseen tulevaisuuden itsellesi. Kun luet commit-viestejäsi päivien, viikkojen tai kuukausien kuluttua, pystyt muistamaan, miksi teit tietyn päätöksen, tai "peruuttaa" muutoksen – kunhan kirjoitat hyviä commit-viestejä.
### Tehtävä: Luo repository ja commitoi koodi
@ -61,10 +61,10 @@ Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja halua
1. **Luo repository GitHubissa**. GitHub.com-sivustolla, repositories-välilehdellä tai oikean yläkulman navigointipalkista, etsi **new repo** -painike.
1. Anna repositoryllesi (kansiollesi) nimi.
1. Anna repositorylle (kansiolle) nimi.
1. Valitse **create repository**.
1. **Siirry työskentelykansioon**. Terminaalissasi siirry kansioon (tunnetaan myös nimellä hakemisto), jota haluat alkaa seurata. Kirjoita:
1. **Siirry työskentelykansioon**. Terminaalissa siirry kansioon (tunnetaan myös nimellä hakemisto), jota haluat alkaa seurata. Kirjoita:
```bash
cd [name of your folder]
@ -76,7 +76,7 @@ Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja halua
git init
```
1. **Tarkista tila**. Tarkistaaksesi repositoryn tilan kirjoita:
1. **Tarkista tila**. Tarkista repositoryn tila kirjoittamalla:
```bash
git status
@ -93,10 +93,10 @@ Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja halua
modified: file2.txt
```
Tyypillisesti `git status` -komento kertoo sinulle esimerkiksi, mitkä tiedostot ovat valmiita _tallennettavaksi_ repositoryyn tai sisältävät muutoksia, jotka haluat säilyttää.
Tyypillisesti `git status` -komento kertoo esimerkiksi, mitkä tiedostot ovat valmiita _tallennettavaksi_ repositoryyn tai sisältävät muutoksia, jotka haluat säilyttää.
1. **Lisää kaikki tiedostot seurattavaksi**
Tätä kutsutaan myös tiedostojen "stagingiksi" tai lisäämiseksi staging-alueelle.
Tätä kutsutaan myös tiedostojen "stagingiksi" eli lisäämiseksi staging-alueelle.
```bash
git add .
@ -126,37 +126,37 @@ Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja halua
git reset [file or folder name]
```
Tämä komento auttaa poistamaan vain tietyn tiedoston stagingin, jota et halua sisällyttää seuraavaan commit-viestiin.
Tämä komento auttaa poistamaan vain tietyn tiedoston stagingin, jota et halua sisällyttää seuraavaan commitointiin.
1. **Työn tallentaminen**. Tässä vaiheessa olet lisännyt tiedostot niin sanotulle _staging-alueelle_. Paikkaan, jossa Git seuraa tiedostojasi. Muutoksen tekemiseksi pysyväksi sinun täytyy _commitata_ tiedostot. Commit edustaa tallennuspistettä repositoryn historiassa. Kirjoita seuraava komento luodaksesi commitin:
1. **Työn tallentaminen**. Tässä vaiheessa olet lisännyt tiedostot niin sanotulle _staging-alueelle_. Paikkaan, jossa Git seuraa tiedostojasi. Muutoksen tekeminen pysyväksi vaatii tiedostojen _commitointia_. Commitointi luo _commitin_`git commit` -komennolla. Commit edustaa tallennuspistettä repositoryn historiassa. Kirjoita seuraava komento luodaksesi commitin:
```bash
git commit -m "first commit"
```
Tämä commitoi kaikki tiedostosi ja lisää viestin "first commit". Tulevaisuudessa commit-viestien tulisi olla kuvaavampia, jotta ne välittävät, millaisen muutoksen olet tehnyt.
Tämä commitoi kaikki tiedostosi ja lisää viestin "first commit". Tulevaisuudessa commit-viestien tulisi olla kuvaavampia, jotta ne välittävät, millaisia muutoksia olet tehnyt.
1. **Yhdistä paikallinen Git-repo GitHubiin**. Git-repo on hyvä paikallisella koneellasi, mutta jossain vaiheessa haluat varmuuskopioida tiedostosi jonnekin ja myös kutsua muita ihmisiä työskentelemään kanssasi repositoryssäsi. Yksi loistava paikka tähän on GitHub. Muista, että olemme jo luoneet repositoryn GitHubissa, joten meidän tarvitsee vain yhdistää paikallinen Git-repo GitHubiin. Komento `git remote add` tekee juuri tämän. Kirjoita seuraava komento:
1. **Yhdistä paikallinen Git-repo GitHubiin**. Git-repo toimii hyvin koneellasi, mutta jossain vaiheessa haluat varmuuskopioida tiedostosi jonnekin ja kutsua muita ihmisiä työskentelemään kanssasi repositoryssäsi. Yksi hyvä paikka tähän on GitHub. Muista, että olemme jo luoneet repositoryn GitHubissa, joten meidän tarvitsee vain yhdistää paikallinen Git-repo GitHubiin. Komento `git remote add` tekee juuri tämän. Kirjoita seuraava komento:
> Huomaa, ennen kuin kirjoitat komennon, siirry GitHub-repositoryn sivulle löytääksesi repositoryn URL-osoitteen. Käytä sitä alla olevassa komennossa. Korvaa ```https://github.com/username/repository_name.git``` GitHub-URL-osoitteellasi.
> Huomaa, ennen kuin kirjoitat komennon, siirry GitHub-repositorysi sivulle löytääksesi repositoryn URL-osoitteen. Käytä sitä alla olevassa komennossa. Korvaa ```https://github.com/username/repository_name.git``` GitHub-URL-osoitteellasi.
Tämä luo _remoten_, eli yhteyden, nimeltä "origin", joka osoittaa aiemmin luomaasi GitHub-repositoryyn.
Tämä luo _remoten_ eli yhteyden nimeltä "origin", joka osoittaa aiemmin luomaasi GitHub-repositoryyn.
1. **Lähetä paikalliset tiedostot GitHubiin**. Tähän mennessä olet luonut yhteyden paikallisen repositoryn ja GitHub-repositoryn välille. Lähetetään nämä tiedostot GitHubiin seuraavalla komennolla `git push`, näin:
1. **Lähetä paikalliset tiedostot GitHubiin**. Tähän mennessä olet luonut _yhteyden_ paikallisen repositoryn ja GitHub-repositoryn välille. Lähetetään nämä tiedostot GitHubiin seuraavalla komennolla `git push`, näin:
> Huomaa, haaranimesi voi olla oletuksena eri kuin ```main```.
> Huomaa, että haaran nimi voi olla oletuksena eri kuin ```main```.
```bash
git push -u origin main
```
Tämä lähettää commitisi "main"-haaraan GitHubissa.
Tämä lähettää commitisi "main"-haaraan GitHubiin. Upstream-haaran määrittäminen sisältäen `-u` komennossa luo linkin paikallisen haaran ja etähaaran välille, joten voit käyttää yksinkertaisesti git push- tai git pull -komentoja ilman haaran nimen määrittämistä tulevaisuudessa. Git käyttää automaattisesti upstream-haaraa, eikä sinun tarvitse määrittää haaran nimeä erikseen tulevissa komennoissa.
2. **Lisää lisää muutoksia**. Jos haluat jatkaa muutosten tekemistä ja lähettää niitä GitHubiin, sinun tarvitsee vain käyttää seuraavia kolmea komentoa:
2. **Lisää lisää muutoksia**. Jos haluat jatkaa muutosten tekemistä ja niiden lähettämistä GitHubiin, sinun tarvitsee vain käyttää seuraavia kolmea komentoa:
```bash
git add .
@ -171,14 +171,14 @@ Oletetaan, että sinulla on paikallinen kansio, jossa on koodiprojekti, ja halua
Hyvä Git commit -aiherivi täydentää seuraavan lauseen:
Jos tämä commit toteutetaan, se <aiherivisitähän>
Aiherivissä käytä imperatiivista, nykyhetkeä: "muuta" eikä "muutettu" tai "muuttaa".
Kuten aiherivissä, myös rungossa (valinnainen) käytä imperatiivista, nykyhetkeä. Rungon tulisi sisältää muutoksen motivaatio ja verrata sitä aiempaan käyttäytymiseen. Selität `miksi`, et `miten`.
Käytä aiherivissä imperatiivista, nykyhetken aikamuotoa: "muuta" eikä "muutettu" tai "muuttaa".
Kuten aiherivissä, myös rungossa (valinnainen) käytä imperatiivista, nykyhetken aikamuotoa. Rungon tulisi sisältää muutoksen motivaatio ja verrata sitä aiempaan toimintaan. Selität `miksi`, et `miten`.
✅ Käytä muutama minuutti GitHubissa surffaamiseen. Löydätkö todella hyvän commit-viestin? Löydätkö todella minimaalisen? Mitä tietoa mielestäsi on tärkeintä ja hyödyllisintä välittää commit-viestissä?
✅ Käytä muutama minuutti GitHubissa surffaamiseen. Löydätkö todella hyvän commit-viestin? Löydätkö todella minimaalisen? Mitä tietoja mielestäsi on tärkeintä ja hyödyllisintä välittää commit-viestissä?
### Tehtävä: Tee yhteistyötä
Pääsyy asioiden laittamiseen GitHubiin oli tehdä yhteistyö muiden kehittäjien kanssa mahdolliseksi.
GitHubiin tiedostojen laittamisen pääsyy oli tehdä yhteistyö muiden kehittäjien kanssa mahdolliseksi.
## Työskentely projekteissa muiden kanssa
@ -197,24 +197,24 @@ Repositoryssäsi siirry kohtaan `Insights > Community` nähdäksesi, miten proje
Kaikki nämä resurssit hyödyttävät uusien tiimin jäsenten perehdyttämistä. Ja nämä ovat tyypillisesti asioita, joita uudet osallistujat tarkastelevat ennen kuin edes katsovat koodiasi, selvittääkseen, onko projektisi oikea paikka heidän ajankäytölleen.
✅ README-tiedostot, vaikka niiden valmistelu vie aikaa, jäävät usein kiireisten ylläpitäjien huomiotta. Löydätkö esimerkin erityisen kuvaavasta README-tiedostosta? Huomaa: on olemassa [työkaluja hyvien README-tiedostojen luomiseen](https://www.makeareadme.com/), joita saatat haluta kokeilla.
✅ README-tiedostot, vaikka niiden valmistelu vie aikaa, jäävät usein kiireisten ylläpitäjien huomiotta. Löydätkö esimerkin erityisen kuvaavasta README-tiedostosta? Huomaa: on olemassa joitain [työkaluja hyvien README-tiedostojen luomiseen](https://www.makeareadme.com/), joita saatat haluta kokeilla.
### Tehtävä: Yhdistä koodia
Osallistumisohjeet auttavat ihmisiä osallistumaan projektiin. Ne selittävät, millaisia osallistumisia etsit ja miten prosessi toimii. Osallistujien täytyy käydä läpi sarja vaiheita voidakseen osallistua repositoryysi GitHubissa:
1. **Repositoryn forkaaminen**. Haluat todennäköisesti, että ihmiset _forkkaavat_ projektisi. Forkkaaminen tarkoittaa repositoryn kopion luomista heidän GitHub-profiiliinsa.
1. **Repositoryn haarauttaminen**. Haluat todennäköisesti ihmisten _forkkaavan_ projektisi. Forkkaaminen tarkoittaa repositoryn kopion luomista heidän GitHub-profiiliinsa.
1. **Kloonaus**. Tämän jälkeen he kloonaavat projektin paikalliselle koneelleen.
1. **Haaran luominen**. Pyydä heitä luomaan _haara_ työlleen.
1. **Keskittyminen yhteen alueeseen**. Pyydä osallistujia keskittymään yhteen asiaan kerrallaan – näin mahdollisuudet siihen, että voit _yhdistää_ heidän työnsä, ovat suuremmat. Kuvittele, että he korjaavat virheen, lisäävät uuden ominaisuuden ja päivittävät useita testejä – entä jos haluat tai voit toteuttaa vain 2/3 tai 1/3 muutoksista?
1. **Keskittyminen yhteen alueeseen**. Pyydä osallistujia keskittymään osallistumisessaan yhteen asiaan kerrallaan – näin mahdollisuudet siihen, että voit _yhdistää_ heidän työnsä, ovat suuremmat. Kuvittele, että he korjaavat virheen, lisäävät uuden ominaisuuden ja päivittävät useita testejä – entä jos haluat tai voit toteuttaa vain 2 kolmesta tai 1 kolmesta muutoksesta?
✅ Kuvittele tilanne, jossa haarat ovat erityisen kriittisiä hyvän koodin kirjoittamisessa ja julkaisemisessa. Mitä käyttötapauksia voit keksiä?
> Huomaa, ole muutos, jonka haluat nähdä maailmassa, ja luo haaroja myös omalle työllesi. Kaikki commitit, jotka teet, tehdään haarassa, johon olet tällä hetkellä "checkoutannut". Käytä `git status` nähdäksesi, missä haarassa olet.
> Huomaa, ole se muutos, jonka haluat nähdä maailmassa, ja luo haaroja myös omalle työllesi. Kaikki commitit, jotka teet, tehdään haaralle, johon olet tällä hetkellä "checkoutattu". Käytä `git status` nähdäksesi, millä haaralla olet.
Käydään läpi osallistujan työnkulku. Oletetaan, että osallistuja on jo _forkannut_ ja _kloonannut_ repositoryn, joten heillä on Git-repo valmiina työstettäväksi paikallisella koneellaan:
1. **Luo haara**. Käytä komentoa `git branch` luodaksesi haara, joka sisältää muutokset, joita he aikovat kontribuoida:
1. **Luo haara**. Käytä komentoa `git branch` luodaksesi haaran, joka sisältää muutokset, joita he aikovat osallistua:
```bash
git branch [branch-name]
@ -226,16 +226,16 @@ Käydään läpi osallistujan työnkulku. Oletetaan, että osallistuja on jo _fo
git switch [branch-name]
```
1. **Tee työtä**. Tässä vaiheessa haluat lisätä muutoksesi. Älä unohda kertoa Gitille siitä seuraavilla komennoilla:
1. **Tee työtä**. Tässä vaiheessa haluat lisätä muutoksesi. Älä unohda kertoa Gitille niistä seuraavilla komennoilla:
```bash
git add .
git commit -m "my changes"
```
Varmista, että annat commitille hyvän nimen, omaksi hyödyksesi sekä repositoryn ylläpitäjän hyödyksi.
Varmista, että annat commitillesi hyvän nimen, omaksi hyödyksesi sekä repositoryn ylläpitäjän hyödyksi, jota autat.
1. **Yhdistä työsi `main`-haaraan**. Jossain vaiheessa olet valmis työskentelemään ja haluat yhdistää työsi `main`-haaraan. `Main`-haara on saattanut muuttua sillä välin, joten varmista, että päivität sen ensin uusimpaan seuraavilla komennoilla:
1. **Yhdistä työsi `main`-haaraan**. Jossain vaiheessa olet valmis työskentelemään ja haluat yhdistää työsi `main`-haaraan. `main`-haara on saattanut muuttua sillä välin, joten varmista, että päivität sen ensin uusimpaan seuraavilla komennoilla:
```bash
git switch main
@ -249,60 +249,65 @@ Käydään läpi osallistujan työnkulku. Oletetaan, että osallistuja on jo _fo
git merge main
```
Tämä tuo kaikki muutokset `main`-haarasta haaraasi, ja toivottavasti voit jatkaa. Jos et, VS Code kertoo, missä Git on _epävarma_, ja muokkaat kyseisiä tiedostoja ilmoittaaksesi, mikä sisältö on tarkin.
`git merge main` -komento tuo kaikki muutokset `main`-haarasta haaraasi. Toivottavasti voit jatkaa suoraan. Jos et, VS Code kertoo, missä Git on _epävarma_, ja muokkaat vain kyseisiä tiedostoja ilmoittaaksesi, mikä sisältö on tarkin.
Vaihtaaksesi eri haaraan, käytä modernia `git switch` -komentoa:
```bash
git switch [branch_name]
1. **Lähetä työsi GitHubiin**. Työsi lähettäminen GitHubiin tarkoittaa kahta asiaa: haaran työntämistä repositoryysi ja PR:n (Pull Request) avaamista.
1. **Lähetä työsi GitHubiin**. Työn lähettäminen GitHubiin tarkoittaa kahta asiaa: haaran työntämistä repositoryysi ja PR:n (Pull Request) avaamista.
```bash
git push --set-upstream origin [branch-name]
```
Yllä oleva komento luo haaran forkattuun repositoryyn.
1. **Avaa PR**. Seuraavaksi haluat avata PR:n. Siirry forkattuun repositoryyn GitHubissa. Näet GitHubissa ilmoituksen, jossa kysytään, haluatko luoda uuden PR:n, klikkaa sitä ja sinut ohjataan käyttöliittymään, jossa voit muuttaa commit-viestin otsikkoa, antaa sille sopivamman kuvauksen. Nyt repositoryn ylläpitäjä, jonka forkkasit, näkee tämän PR:n ja _sormet ristissä_ he arvostavat ja _yhdistävät_ PR:si. Olet nyt kontribuoija, jee :)
Yllä oleva komento luo haaran forkattuun repositoryysi.
1. **Avaa PR**. Seuraavaksi haluat avata PR:n. Tämä tapahtuu siirtymällä GitHubissa haarukoituun repoosi. GitHubissa näkyy ilmoitus, jossa kysytään, haluatko luoda uuden PR:n. Klikkaa sitä, ja sinut ohjataan käyttöliittymään, jossa voit muuttaa commit-viestin otsikkoa ja antaa sille sopivamman kuvauksen. Nyt haarukoimasi repositorion ylläpitäjä näkee PR:si ja _peukut pystyyn_, että he arvostavat ja _yhdistävät_ PR:si. Olet nyt kontribuoija, jee :)
1. **Siivoa**. On hyvä tapa _siivota_onnistuneen PR:n yhdistämisen jälkeen. Haluat siivota sekä paikallisen haaran että haaran, jonka työnsit GitHubiin. Poistetaan se ensin paikallisesti seuraavalla komennolla:
1. **Siivoa**. On hyvä tapa _siivota_sen jälkeen, kun PR on onnistuneesti yhdistetty. Haluat siivota sekä paikallisen haaran että GitHubiin työntämäsi haaran. Poistetaan ensin paikallinen haara seuraavalla komennolla:
```bash
git branch -d [branch-name]
```
Varmista, että siirryt seuraavaksi GitHub-sivulle haarukoituun repoosi ja poistat juuri sinne työntämäsi etähaaran.
Varmista, että siirryt GitHub-sivulle forkattuun repositoryyn ja poistat etähaaran, jonka juuri työnsit siihen.
`Pull request` vaikuttaa hieman hassulta termiltä, koska todellisuudessa haluat "puskea" muutoksesi projektiin. Mutta ylläpitäjän (projektin omistajan) tai ydintiimin täytyy harkita muutoksiasi ennen kuin ne yhdistetään projektin "päähaaraan", joten oikeastaan pyydät ylläpitäjältä päätöstä muutoksesta.
`Pull request` voi kuulostaa hassulta termiltä, koska oikeasti haluat työntää muutoksesi projektiin. Mutta ylläpitäjän (projektin omistajan) tai ydintiimin täytyy harkita muutoksiasi ennen kuin ne yhdistetään projektin "päähaaraan", joten oikeastaan pyydät ylläpitäjältä päätöstä muutoksesta.
Pull request on paikka, jossa verrataan ja keskustellaan haarassa tehdyistä eroista arvostelujen, kommenttien, integroitujen testien ja muiden avulla. Hyvä pull request noudattaa suunnilleen samoja sääntöjä kuin commit-viesti. Voit lisätä viittauksen ongelmaan ongelmanseurannassa, esimerkiksi kun työsi korjaa jonkin ongelman. Tämä tehdään käyttämällä `#`-merkkiä, jota seuraa ongelman numero. Esimerkiksi `#97`.
Pull request on paikka, jossa voidaan verrata ja keskustella haaran tuomista eroista arvostelujen, kommenttien, integroitujen testien ja muiden avulla. Hyvä pull request noudattaa suunnilleen samoja sääntöjä kuin commit-viesti. Voit lisätä viittauksen ongelmaan ongelmaseurannassa, esimerkiksi kun työsi korjaa jonkin ongelman. Tämä tehdään käyttämällä `#`-merkkiä, jota seuraa ongelman numero. Esimerkiksi `#97`.
🤞Toivotaan, että kaikki tarkistukset menevät läpi ja projektin omistaja(t) yhdistävät muutoksesi projektiin🤞
🤞Peukut pystyyn, että kaikki tarkistukset menevät läpi ja projektin omistaja(t) yhdistävät muutoksesi projektiin🤞
Päivitä nykyinen paikallinen työhaara kaikilla uusilla commit-viesteillä vastaavasta etähaarasta GitHubissa:
`git pull`
## Kuinka osallistua avoimen lähdekoodin projekteihin
## Kuinka osallistua avoimeen lähdekoodiin
Ensiksi, etsitään GitHubista sinua kiinnostava repository (tai **repo**), johon haluaisit tehdä muutoksen. Haluat kopioida sen sisällön koneellesi.
Aloitetaan etsimällä GitHubista repositorio (**repo**), joka kiinnostaa sinua ja johon haluaisit tehdä muutoksen. Haluat kopioida sen sisällön koneellesi.
✅ Hyvä tapa löytää 'aloittelijaystävällisiä' repoja on [etsiä tagilla 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Koodin kopioimiseen on useita tapoja. Yksi tapa on "klonata" repositoryn sisältö HTTPS:n, SSH:n tai GitHub CLI:n (Command Line Interface) avulla.
Koodin kopioimiseen on useita tapoja. Yksi tapa on "klonata" repositorion sisältö HTTPS:n, SSH:n tai GitHub CLI:n (Command Line Interface) avulla.
Avaa terminaali ja klonaa repository näin:
Avaa terminaali ja klonaa repositorio näin:
`git clone https://github.com/ProjectURL`
Työskentelyä varten siirry oikeaan kansioon:
Työskentelyä varten siirry oikeaan kansioon:
`cd ProjectURL`
Voit myös avata koko projektin käyttämällä [Codespacesia](https://github.com/features/codespaces), GitHubin sisäänrakennettua koodieditoria/pilvikehitysympäristöä, tai [GitHub Desktopia](https://desktop.github.com/).
Voit myös avata koko projektin käyttämällä [Codespaces](https://github.com/features/codespaces), GitHubin sisäänrakennettua koodieditoria/pilvikehitysympäristöä, tai [GitHub Desktop](https://desktop.github.com/).
Lopuksi voit ladata koodin zip-pakattuna kansiona.
### Muutamia mielenkiintoisia asioita GitHubista
Voit tähdittää, seurata ja/tai "forkata" mitä tahansa julkista repositorya GitHubissa. Löydät tähdittämäsi repositoryt oikean yläkulman pudotusvalikosta. Se on kuin kirjanmerkkien lisäämistä, mutta koodille.
Voit tähdittää, seurata ja/tai "haarukoida" mitä tahansa julkista repositoriota GitHubissa. Löydät tähdittämäsi repositoriot oikean yläkulman pudotusvalikosta. Se on kuin kirjanmerkkien lisäämistä, mutta koodille.
Projekteilla on ongelmanseuranta, yleensä GitHubissa "Issues"-välilehdellä, ellei toisin mainita, jossa ihmiset keskustelevat projektin ongelmista. Pull Requests -välilehdellä ihmiset keskustelevat ja arvioivat muutoksia, jotka ovat työn alla.
Projekteilla on ongelmaseuranta, yleensä GitHubissa "Issues"-välilehdellä, ellei toisin mainita, jossa ihmiset keskustelevat projektin ongelmista. Ja Pull Requests -välilehdellä ihmiset keskustelevat ja arvioivat muutoksia, jotka ovat työn alla.
Projekteilla voi myös olla keskusteluja foorumeilla, sähköpostilistoilla tai chat-kanavilla, kuten Slack, Discord tai IRC.
@ -310,30 +315,30 @@ Projekteilla voi myös olla keskusteluja foorumeilla, sähköpostilistoilla tai
---
## 🚀 Haaste
## 🚀 Haaste
Työskentele yhdessä ystävän kanssa toistenne koodin parissa. Luo projekti yhteistyössä, forkkaa koodia, luo haaroja ja yhdistä muutoksia.
Työskentele yhdessä ystävän kanssa toistenne koodin parissa. Luo projekti yhteistyössä, haarukoi koodi, luo haaroja ja yhdistä muutoksia.
Tämä asiakirja on käännetty käyttämällä tekoälypohjaista käännöspalvelua [Co-op Translator](https://github.com/Azure/co-op-translator). Vaikka pyrimme tarkkuuteen, huomioithan, että automaattiset käännökset voivat sisältää virheitä tai epätarkkuuksia. Alkuperäistä asiakirjaa sen alkuperäisellä kielellä tulisi pitää ensisijaisena lähteenä. Kriittisen tiedon osalta suositellaan ammattimaista ihmiskääntämistä. Emme ole vastuussa väärinkäsityksistä tai virhetulkinnoista, jotka johtuvat tämän käännöksen käytöstä.
Tämä asiakirja on käännetty käyttämällä tekoälypohjaista käännöspalvelua [Co-op Translator](https://github.com/Azure/co-op-translator). Vaikka pyrimme tarkkuuteen, huomioithan, että automaattiset käännökset voivat sisältää virheitä tai epätarkkuuksia. Alkuperäistä asiakirjaa sen alkuperäisellä kielellä tulisi pitää ensisijaisena lähteenä. Kriittisen tiedon osalta suositellaan ammattimaista ihmiskäännöstä. Emme ole vastuussa väärinkäsityksistä tai virhetulkinnoista, jotka johtuvat tämän käännöksen käytöstä.
[Quiz avant la leçon](https://ff-quizzes.netlify.app)
## Introduction
@ -51,7 +51,7 @@ Vous aurez besoin d'un dossier contenant un projet de code sur votre machine loc
## Gestion du code
Imaginons que vous avez un dossier local avec un projet de code et que vous souhaitez commencer à suivre vos progrès en utilisant Git - le système de contrôle de version. Certains comparent l'utilisation de Git à l'écriture d'une lettre d'amour à votre futur vous-même. En lisant vos messages de commit des jours, semaines ou mois plus tard, vous pourrez vous rappeler pourquoi vous avez pris une décision ou "revenir en arrière" sur un changement - à condition d'écrire de bons "messages de commit".
Disons que vous avez un dossier localement avec un projet de code et que vous souhaitez commencer à suivre votre progression en utilisant git - le système de contrôle de version. Certains comparent l'utilisation de git à écrire une lettre d'amour à votre futur vous-même. En lisant vos messages de commit des jours, semaines ou mois plus tard, vous pourrez vous rappeler pourquoi vous avez pris une décision ou "revenir en arrière" sur une modification - à condition d'écrire de bons "messages de commit".
### Tâche : Créer un dépôt et enregistrer du code
@ -64,13 +64,13 @@ Imaginons que vous avez un dossier local avec un projet de code et que vous souh
1. Donnez un nom à votre dépôt (dossier).
1. Sélectionnez **créer un dépôt**.
1. **Naviguer vers votre dossier de travail**. Dans votre terminal, accédez au dossier (également appelé répertoire) que vous souhaitez commencer à suivre. Tapez :
1. **Naviguer vers votre dossier de travail**. Dans votre terminal, passez au dossier (également appelé répertoire) que vous souhaitez commencer à suivre. Tapez :
```bash
cd [name of your folder]
```
1. **Initialiser un dépôt Git**. Dans votre projet, tapez :
1. **Initialiser un dépôt git**. Dans votre projet, tapez :
```bash
git init
@ -93,50 +93,50 @@ Imaginons que vous avez un dossier local avec un projet de code et que vous souh
modified: file2.txt
```
Typiquement, une commande `git status` vous indique des informations comme quels fichiers sont prêts à être _enregistrés_ dans le dépôt ou quels fichiers ont des modifications que vous pourriez vouloir conserver.
En général, une commande `git status` vous indique des informations comme les fichiers prêts à être _enregistrés_ dans le dépôt ou ceux qui ont des modifications que vous pourriez vouloir conserver.
1. **Ajouter tous les fichiers pour le suivi**
1. **Ajouter tous les fichiers au suivi**
Cela s'appelle également mettre en scène les fichiers / ajouter des fichiers à la zone de staging.
```bash
git add .
```
L'argument `git add` suivi de `.` indique que tous vos fichiers et modifications sont prêts pour le suivi.
L'argument `git add` suivi de `.` indique que tous vos fichiers et modifications sont prêts à être suivis.
1. **Ajouter des fichiers sélectionnés pour le suivi**
1. **Ajouter des fichiers sélectionnés au suivi**
```bash
git add [file or folder name]
```
Cela permet d'ajouter uniquement des fichiers sélectionnés à la zone de staging lorsque vous ne souhaitez pas tout enregistrer en une seule fois.
Cela permet d'ajouter uniquement des fichiers sélectionnés à la zone de staging lorsque vous ne souhaitez pas enregistrer tous les fichiers en une seule fois.
1. **Désépingler tous les fichiers**
1. **Retirer tous les fichiers de la zone de staging**
```bash
git reset
```
Cette commande permet de désépingler tous les fichiers en une seule fois.
Cette commande permet de retirer tous les fichiers de la zone de staging en une seule fois.
1. **Désépingler un fichier particulier**
1. **Retirer un fichier particulier de la zone de staging**
```bash
git reset [file or folder name]
```
Cette commande permet de désépingler uniquement un fichier particulier que vous ne souhaitez pas inclure dans le prochain commit.
Cette commande permet de retirer uniquement un fichier particulier de la zone de staging que vous ne souhaitez pas inclure dans le prochain commit.
1. **Enregistrer votre travail**. À ce stade, vous avez ajouté les fichiers dans une zone appelée _staging area_. Un endroit où Git suit vos fichiers. Pour rendre le changement permanent, vous devez _committer_ les fichiers. Pour ce faire, créez un _commit_ avec la commande `git commit`. Un _commit_ représente un point de sauvegarde dans l'historique de votre dépôt. Tapez la commande suivante pour créer un _commit_ :
1. **Enregistrer votre travail**. À ce stade, vous avez ajouté les fichiers à une zone appelée _zone de staging_. Un endroit où Git suit vos fichiers. Pour rendre la modification permanente, vous devez _commiter_ les fichiers. Pour ce faire, vous créez un _commit_ avec la commande `git commit`. Un _commit_ représente un point de sauvegarde dans l'historique de votre dépôt. Tapez la commande suivante pour créer un _commit_ :
```bash
git commit -m "first commit"
```
Cela enregistre tous vos fichiers, en ajoutant le message "premier commit". Pour les futurs messages de commit, vous voudrez être plus descriptif pour indiquer clairement le type de changement effectué.
Cela enregistre tous vos fichiers, en ajoutant le message "premier commit". Pour les futurs messages de commit, vous voudrez être plus descriptif dans votre description pour indiquer le type de modification que vous avez apportée.
1. **Connecter votre dépôt Git local à GitHub**. Un dépôt Git est utile sur votre machine, mais à un moment donné, vous voudrez sauvegarder vos fichiers quelque part et inviter d'autres personnes à travailler avec vous sur votre dépôt. Un excellent endroit pour cela est GitHub. Rappelez-vous que nous avons déjà créé un dépôt sur GitHub, donc la seule chose à faire est de connecter notre dépôt Git local à GitHub. La commande `git remote add`permet de le faire. Tapez la commande suivante :
1. **Connecter votre dépôt Git local à GitHub**. Un dépôt Git est utile sur votre machine, mais à un moment donné, vous voudrez sauvegarder vos fichiers quelque part et inviter d'autres personnes à travailler avec vous sur votre dépôt. Un excellent endroit pour cela est GitHub. Rappelez-vous que nous avons déjà créé un dépôt sur GitHub, donc la seule chose à faire est de connecter notre dépôt Git local à GitHub. La commande `git remote add`fera cela. Tapez la commande suivante :
> Remarque : avant de taper la commande, allez sur la page de votre dépôt GitHub pour trouver l'URL du dépôt. Vous l'utiliserez dans la commande ci-dessous. Remplacez ```https://github.com/username/repository_name.git``` par votre URL GitHub.
@ -144,9 +144,9 @@ Imaginons que vous avez un dossier local avec un projet de code et que vous souh
Cela crée une _remote_, ou connexion, nommée "origin" pointant vers le dépôt GitHub que vous avez créé précédemment.
Cela crée une _connexion distante_, appelée "origin", pointant vers le dépôt GitHub que vous avez créé précédemment.
1. **Envoyer les fichiers locaux vers GitHub**. Jusqu'à présent, vous avez créé une _connexion_ entre le dépôt local et le dépôt GitHub. Envoyons ces fichiers vers GitHub avec la commande `git push`, comme suit :
1. **Envoyer les fichiers locaux à GitHub**. Jusqu'à présent, vous avez créé une _connexion_ entre le dépôt local et le dépôt GitHub. Envoyons ces fichiers à GitHub avec la commande suivante `git push`, comme suit :
> Remarque : le nom de votre branche par défaut peut être différent de ```main```.
@ -154,9 +154,9 @@ Imaginons que vous avez un dossier local avec un projet de code et que vous souh
git push -u origin main
```
Cela envoie vos commits dans votre branche "main" vers GitHub.
Cela envoie vos commits dans votre branche "main" à GitHub. L'établissement de la branche `upstream` en incluant `-u` dans la commande crée un lien entre votre branche locale et la branche distante, ce qui vous permet d'utiliser simplement git push ou git pull sans spécifier le nom de la branche à l'avenir. Git utilisera automatiquement la branche upstream et vous n'aurez pas besoin de spécifier le nom de la branche explicitement dans les commandes futures.
2. **Ajouter d'autres modifications**. Si vous souhaitez continuer à apporter des modifications et les envoyer sur GitHub, vous n'aurez besoin que des trois commandes suivantes :
2. **Ajouter d'autres modifications**. Si vous souhaitez continuer à apporter des modifications et les envoyer à GitHub, vous n'aurez besoin que des trois commandes suivantes :
```bash
git add .
@ -164,21 +164,21 @@ Imaginons que vous avez un dossier local avec un projet de code et que vous souh
git push
```
> Astuce : Vous pourriez également vouloir adopter un fichier `.gitignore` pour empêcher les fichiers que vous ne souhaitez pas suivre d'apparaître sur GitHub - comme ce fichier de notes que vous stockez dans le même dossier mais qui n'a pas sa place dans un dépôt public. Vous pouvez trouver des modèles pour les fichiers `.gitignore` sur [.gitignore templates](https://github.com/github/gitignore).
> Conseil : Vous pourriez également adopter un fichier `.gitignore` pour empêcher les fichiers que vous ne souhaitez pas suivre d'apparaître sur GitHub - comme ce fichier de notes que vous stockez dans le même dossier mais qui n'a pas sa place dans un dépôt public. Vous pouvez trouver des modèles de fichiers `.gitignore` sur [.gitignore templates](https://github.com/github/gitignore).
#### Messages de commit
Un excellent message de commit complète la phrase suivante :
Si appliqué, ce commit va <votresujetici>
Un excellent sujet de message de commit complète la phrase suivante :
Si appliqué, ce commit fera <votresujetici>
Pour le sujet, utilisez l'impératif au présent : "modifier" et non "modifié" ni "modifie".
Comme pour le sujet, dans le corps (optionnel), utilisez également l'impératif au présent. Le corps doit inclure la motivation du changement et contraster cela avec le comportement précédent. Vous expliquez le `pourquoi`, pas le `comment`.
Pour le sujet, utilisez l'impératif au présent : "modifier" et non "modifié" ni "modifications".
Comme pour le sujet, dans le corps (optionnel), utilisez également l'impératif au présent. Le corps doit inclure la motivation du changement et la comparer au comportement précédent. Vous expliquez le `pourquoi`, pas le `comment`.
✅ Prenez quelques minutes pour explorer GitHub. Pouvez-vous trouver un message de commit particulièrement bien écrit ? Et un très minimaliste ? Quelles informations pensez-vous être les plus importantes et utiles à transmettre dans un message de commit ?
✅ Prenez quelques minutes pour explorer GitHub. Pouvez-vous trouver un message de commit vraiment génial ? Pouvez-vous en trouver un très minimaliste ? Quelles informations pensez-vous être les plus importantes et utiles à transmettre dans un message de commit ?
### Tâche : Collaborer
La principale raison de mettre des choses sur GitHub est de permettre la collaboration avec d'autres développeurs.
La principale raison de mettre des choses sur GitHub est de rendre possible la collaboration avec d'autres développeurs.
## Travailler sur des projets avec d'autres
@ -186,7 +186,7 @@ La principale raison de mettre des choses sur GitHub est de permettre la collabo
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Dans votre dépôt, accédez à `Insights > Community` pour voir comment votre projet se compare aux standards communautaires recommandés.
Dans votre dépôt, naviguez vers `Insights > Community` pour voir comment votre projet se compare aux normes communautaires recommandées.
Voici quelques éléments qui peuvent améliorer votre dépôt GitHub :
- **Description**. Avez-vous ajouté une description pour votre projet ?
@ -195,24 +195,24 @@ Dans votre dépôt, accédez à `Insights > Community` pour voir comment votre p
- **Code de conduite**. Un [Code de conduite](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/) ?
- **Licence**. Peut-être le plus important, une [licence](https://docs.github.com/articles/adding-a-license-to-a-repository/) ?
Tous ces éléments faciliteront l'intégration de nouveaux membres dans l'équipe. Ce sont généralement les choses que les nouveaux contributeurs examinent avant même de regarder votre code, pour savoir si votre projet est le bon endroit où investir leur temps.
Tous ces éléments seront utiles pour intégrer de nouveaux membres dans l'équipe. Ce sont généralement les choses que les nouveaux contributeurs regardent avant même de consulter votre code, pour savoir si votre projet est le bon endroit où investir leur temps.
✅ Les fichiers README, bien qu'ils prennent du temps à préparer, sont souvent négligés par les mainteneurs occupés. Pouvez-vous trouver un exemple particulièrement descriptif ? Remarque : il existe des [outils pour aider à créer de bons README](https://www.makeareadme.com/) que vous pourriez essayer.
✅ Les fichiers README, bien qu'ils prennent du temps à préparer, sont souvent négligés par les mainteneurs occupés. Pouvez-vous trouver un exemple particulièrement descriptif ? Remarque : il existe des [outils pour créer de bons README](https://www.makeareadme.com/) que vous pourriez essayer.
### Tâche : Fusionner du code
Les documents de contribution aident les gens à contribuer au projet. Ils expliquent quels types de contributions vous recherchez et comment fonctionne le processus. Les contributeurs devront suivre une série d'étapes pour pouvoir contribuer à votre dépôt sur GitHub :
Les documents de contribution aident les gens à contribuer au projet. Ils expliquent quels types de contributions vous recherchez et comment le processus fonctionne. Les contributeurs devront suivre une série d'étapes pour pouvoir contribuer à votre dépôt sur GitHub :
1. **Forker votre dépôt**. Vous voudrez probablement que les gens _forkent_ votre projet. Forker signifie créer une réplique de votre dépôt sur leur profil GitHub.
1. **Cloner**. À partir de là, ils cloneront le projet sur leur machine locale.
1. **Créer une branche**. Vous voudrez leur demander de créer une _branche_ pour leur travail.
1. **Concentrer leur changement sur une seule zone**. Demandez aux contributeurs de se concentrer sur une seule chose à la fois - de cette façon, les chances que vous puissiez _fusionner_ leur travail sont plus élevées. Imaginez qu'ils corrigent un bug, ajoutent une nouvelle fonctionnalité et mettent à jour plusieurs tests - que faire si vous voulez ou pouvez seulement implémenter 2 sur 3, ou 1 sur 3 changements ?
1. **Concentrer leur modification sur une seule zone**. Demandez aux contributeurs de concentrer leurs contributions sur une seule chose à la fois - de cette façon, les chances que vous puissiez _fusionner_ leur travail sont plus élevées. Imaginez qu'ils corrigent un bug, ajoutent une nouvelle fonctionnalité et mettent à jour plusieurs tests - que faire si vous voulez, ou pouvez seulement implémenter 2 sur 3, ou 1 sur 3 modifications ?
✅ Imaginez une situation où les branches sont particulièrement critiques pour écrire et livrer du bon code. Quels cas d'utilisation pouvez-vous imaginer ?
✅ Imaginez une situation où les branches sont particulièrement critiques pour écrire et livrer du bon code. À quels cas d'utilisation pouvez-vous penser ?
> Remarque : soyez le changement que vous voulez voir dans le monde, et créez des branches pour votre propre travail également. Tous les commits que vous effectuez seront réalisés sur la branche sur laquelle vous êtes actuellement "checkout". Utilisez `git status` pour voir sur quelle branche vous êtes.
> Remarque : soyez le changement que vous voulez voir dans le monde, et créez des branches pour votre propre travail également. Tous les commits que vous effectuez seront faits sur la branche sur laquelle vous êtes actuellement "checkout". Utilisez `git status` pour voir sur quelle branche vous êtes.
Passons en revue un flux de travail de contributeur. Supposons que le contributeur ait déjà _forké_ et _cloné_ le dépôt, de sorte qu'il dispose d'un dépôt Git prêt à être utilisé sur sa machine locale :
Passons en revue un workflow de contributeur. Supposons que le contributeur ait déjà _forké_ et _cloné_ le dépôt, de sorte qu'il dispose d'un dépôt Git prêt à être travaillé sur sa machine locale :
1. **Créer une branche**. Utilisez la commande `git branch` pour créer une branche qui contiendra les modifications qu'ils souhaitent contribuer :
@ -220,22 +220,22 @@ Passons en revue un flux de travail de contributeur. Supposons que le contribute
git branch [branch-name]
```
1. **Basculer vers la branche de travail**. Passez à la branche spécifiée et mettez à jour le répertoire de travail avec `git switch` :
1. **Passer à la branche de travail**. Passez à la branche spécifiée et mettez à jour le répertoire de travail avec `git switch` :
```bash
git switch [branch-name]
```
1. **Travailler**. À ce stade, vous voulez ajouter vos modifications. N'oubliez pas d'en informer Git avec les commandes suivantes :
1. **Travailler**. À ce stade, vous voulez ajouter vos modifications. N'oubliez pas de les signaler à Git avec les commandes suivantes :
```bash
git add .
git commit -m "my changes"
```
Assurez-vous de donner un bon nom à votre commit, pour votre propre bien ainsi que pour le mainteneur du dépôt que vous aidez.
Assurez-vous de donner un bon nom à votre commit, pour votre propre intérêt ainsi que pour le mainteneur du dépôt que vous aidez.
1. **Combiner votre travail avec la branche `main`**. À un moment donné, vous avez terminé votre travail et vous souhaitez le combiner avec celui de la branche `main`. La branche `main`a peut-être changé entre-temps, alors assurez-vous de la mettre à jour avec les commandes suivantes :
1. **Combiner votre travail avec la branche `main`**. À un moment donné, vous avez terminé votre travail et vous souhaitez le combiner avec celui de la branche `main`. La branche `main`peut avoir changé entre-temps, alors assurez-vous de la mettre à jour avec les commandes suivantes :
```bash
git switch main
@ -249,28 +249,33 @@ Passons en revue un flux de travail de contributeur. Supposons que le contribute
git merge main
```
Cela intégrera toutes les modifications de `main` dans votre branche et, espérons-le, vous pourrez continuer. Sinon, VS Code vous indiquera où Git est _confus_ et vous modifierez simplement les fichiers concernés pour indiquer quel contenu est le plus précis.
La commande `git merge main` intégrera toutes les modifications de `main` dans votre branche. Espérons que vous pourrez simplement continuer. Sinon, VS Code vous indiquera où Git est _confus_ et vous modifierez les fichiers concernés pour indiquer quel contenu est le plus précis.
Pour passer à une autre branche, utilisez la commande moderne `git switch` :
```bash
git switch [branch_name]
1. **Envoyer votre travail sur GitHub**. Envoyer votre travail sur GitHub signifie deux choses : pousser votre branche sur votre dépôt et ensuite ouvrir une PR (Pull Request).
1. **Envoyer votre travail à GitHub**. Envoyer votre travail à GitHub signifie deux choses : pousser votre branche vers votre dépôt et ensuite ouvrir une PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
La commande ci-dessus crée la branche sur votre dépôt forké.
1. **Ouvrir une PR**. Ensuite, vous devez ouvrir une PR. Pour cela, naviguez vers le dépôt forké sur GitHub. Vous verrez une indication sur GitHub vous demandant si vous souhaitez créer une nouvelle PR. Cliquez dessus et vous serez dirigé vers une interface où vous pourrez modifier le titre du message de commit et fournir une description plus appropriée. Maintenant, le mainteneur du dépôt que vous avez forké verra cette PR et _croisons les doigts_ qu'il l'apprécie et _fusionne_ votre PR. Vous êtes maintenant un contributeur, yay :)
1. **Ouvrir une PR**. Ensuite, vous voulez ouvrir une PR. Pour ce faire, accédez au dépôt forké sur GitHub. Vous verrez une indication sur GitHub vous demandant si vous souhaitez créer une nouvelle PR. Cliquez dessus et vous serez dirigé vers une interface où vous pourrez modifier le titre du message de commit, lui donner une description plus appropriée. Maintenant, le mainteneur du dépôt que vous avez forké verra cette PR et, _croisons les doigts_, il appréciera et _fusionnera_ votre PR. Vous êtes maintenant un contributeur, yay :)
1. **Nettoyer**. Il est considéré comme une bonne pratique de _nettoyer_ après avoir fusionné avec succès une PR. Vous voulez nettoyer à la fois votre branche locale et la branche que vous avez poussée sur GitHub. Tout d'abord, supprimez-la localement avec la commande suivante :
1. **Nettoyer**. Il est considéré comme une bonne pratique de _nettoyer_ après avoir réussi à fusionner une PR. Vous devez nettoyer à la fois votre branche locale et la branche que vous avez poussée sur GitHub. Tout d'abord, supprimons-la localement avec la commande suivante :
```bash
git branch -d [branch-name]
```
Assurez-vous ensuite de vous rendre sur la page GitHub du dépôt forké et de supprimer la branche distante que vous venez de pousser.
Assurez-vous ensuite d'aller sur la page GitHub du dépôt forké et de supprimer la branche distante que vous venez de pousser.
`Pull request` peut sembler être un terme étrange, car en réalité, vous voulez pousser vos modifications vers le projet. Mais le mainteneur (propriétaire du projet) ou l'équipe principale doit examiner vos modifications avant de les fusionner avec la branche "main" du projet. En fait, vous demandez une décision de changement à un mainteneur.
`Pull request` peut sembler être un terme étrange, car en réalité, vous souhaitez pousser vos modifications dans le projet. Mais le mainteneur (propriétaire du projet) ou l'équipe principale doit examiner vos modifications avant de les fusionner avec la branche "principale" du projet. Vous demandez donc réellement une décision de modification à un mainteneur.
Une pull request est l'endroit où l'on compare et discute des différences introduites dans une branche, avec des revues, des commentaires, des tests intégrés, et plus encore. Une bonne pull request suit à peu près les mêmes règles qu'un message de commit. Vous pouvez ajouter une référence à un problème dans le gestionnaire de problèmes, par exemple lorsque votre travail résout un problème. Cela se fait en utilisant un `#` suivi du numéro de votre problème. Par exemple,`#97`.
Une pull request est l'endroit où comparer et discuter des différences introduites sur une branche avec des revues, des commentaires, des tests intégrés, et plus encore. Une bonne pull request suit à peu près les mêmes règles qu'un message de commit. Vous pouvez ajouter une référence à un problème dans le gestionnaire de problèmes, par exemple lorsque votre travail résout un problème. Cela se fait en utilisant un `#` suivi du numéro de votre problème. Par exemple `#97`.
🤞Croisons les doigts pour que tous les contrôles passent et que le(s) propriétaire(s) du projet fusionne(nt) vos modifications dans le projet🤞
@ -280,46 +285,46 @@ Mettez à jour votre branche de travail locale actuelle avec tous les nouveaux c
## Comment contribuer à l'open source
Tout d'abord, trouvons un dépôt (ou **repo**) sur GitHub qui vous intéresse et auquel vous souhaitez contribuer. Vous voudrez copier son contenu sur votre machine.
Tout d'abord, trouvons un dépôt (ou **repo**) sur GitHub qui vous intéresse et auquel vous aimeriez apporter une modification. Vous voudrez copier son contenu sur votre machine.
✅ Une bonne façon de trouver des dépôts adaptés aux débutants est de [rechercher par le tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Une bonne façon de trouver des dépôts 'conviviaux pour les débutants' est de [rechercher par le tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Il existe plusieurs façons de copier du code. Une méthode consiste à "cloner" le contenu du dépôt, en utilisant HTTPS, SSH ou l'interface en ligne de commande GitHub (CLI).
Il existe plusieurs façons de copier du code. Une méthode consiste à "cloner" le contenu du dépôt, en utilisant HTTPS, SSH ou l'interface en ligne de commande GitHub CLI.
Ouvrez votre terminal et clonez le dépôt comme suit :
Ouvrez votre terminal et clonez le dépôt comme suit :
`git clone https://github.com/ProjectURL`
Pour travailler sur le projet, accédez au bon dossier :
Pour travailler sur le projet, passez au bon dossier :
`cd ProjectURL`
Vous pouvez également ouvrir l'ensemble du projet en utilisant [Codespaces](https://github.com/features/codespaces), l'éditeur de code intégré / environnement de développement cloud de GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Vous pouvez également ouvrir l'intégralité du projet en utilisant [Codespaces](https://github.com/features/codespaces), l'éditeur de code intégré / environnement de développement cloud de GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Enfin, vous pouvez télécharger le code dans un dossier compressé.
### Quelques autres choses intéressantes à propos de GitHub
### Quelques informations intéressantes sur GitHub
Vous pouvez ajouter une étoile, suivre et/ou "forker" tout dépôt public sur GitHub. Vous pouvez retrouver vos dépôts étoilés dans le menu déroulant en haut à droite. C'est comme ajouter un favori, mais pour du code.
Vous pouvez étoiler, surveiller et/ou "forker" tout dépôt public sur GitHub. Vous pouvez retrouver vos dépôts étoilés dans le menu déroulant en haut à droite. C'est comme ajouter un marque-page, mais pour du code.
Les projets disposent d'un gestionnaire de problèmes, généralement dans l'onglet "Issues" sur GitHub, sauf indication contraire, où les gens discutent des problèmes liés au projet. Et l'onglet Pull Requests est l'endroit où les gens discutent et examinent les modifications en cours.
Les projets disposent d'un gestionnaire de problèmes, généralement sur GitHub dans l'onglet "Issues", sauf indication contraire, où les gens discutent des problèmes liés au projet. Et l'onglet Pull Requests est l'endroit où les gens discutent et examinent les modifications en cours.
Les projets peuvent également avoir des discussions dans des forums, des listes de diffusion ou des canaux de discussion comme Slack, Discord ou IRC.
Les projets peuvent également avoir des discussions dans des forums, des listes de diffusion ou des canaux de chat comme Slack, Discord ou IRC.
✅ Explorez votre nouveau dépôt GitHub et essayez quelques fonctionnalités, comme modifier les paramètres, ajouter des informations à votre dépôt, et créer un projet (comme un tableau Kanban). Il y a beaucoup à découvrir !
✅ Explorez votre nouveau dépôt GitHub et essayez quelques fonctionnalités, comme modifier les paramètres, ajouter des informations à votre dépôt, et créer un projet (comme un tableau Kanban). Il y a beaucoup de choses à découvrir !
---
## 🚀 Défi
## 🚀 Défi
Associez-vous à un ami pour travailler sur le code de l'autre. Créez un projet collaboratif, forkez du code, créez des branches et fusionnez des modifications.
Associez-vous à un ami pour travailler sur le code de chacun. Créez un projet collaboratif, forkez du code, créez des branches et fusionnez des modifications.
Vous y trouverez également des cours plus avancés.
## Devoir
## Devoir
Complétez [le cours Première semaine sur GitHub](https://skills.github.com/#first-week-on-github)
---
**Avertissement** :
Ce document a été traduit à l'aide du service de traduction automatique [Co-op Translator](https://github.com/Azure/co-op-translator). Bien que nous nous efforcions d'assurer l'exactitude, veuillez noter que les traductions automatisées peuvent contenir des erreurs ou des inexactitudes. Le document original dans sa langue d'origine doit être considéré comme la source faisant autorité. Pour des informations critiques, il est recommandé de faire appel à une traduction humaine professionnelle. Nous déclinons toute responsabilité en cas de malentendus ou d'interprétations erronées résultant de l'utilisation de cette traduction.
Ce document a été traduit à l'aide du service de traduction automatique [Co-op Translator](https://github.com/Azure/co-op-translator). Bien que nous nous efforcions d'assurer l'exactitude, veuillez noter que les traductions automatisées peuvent contenir des erreurs ou des inexactitudes. Le document original dans sa langue d'origine doit être considéré comme la source faisant autorité. Pour des informations critiques, il est recommandé de recourir à une traduction humaine professionnelle. Nous déclinons toute responsabilité en cas de malentendus ou d'interprétations erronées résultant de l'utilisation de cette traduction.
> איור מאת [Tomomi Imura](https://twitter.com/girlie_mac)
## חידון לפני השיעור
[חידון לפני השיעור](https://ff-quizzes.netlify.app)
## שאלון לפני השיעור
[שאלון לפני השיעור](https://ff-quizzes.netlify.app)
## מבוא
## הקדמה
בשיעור הזה נלמד:
- איך לעקוב אחרי העבודה שלך במחשב
- איך לעקוב אחרי העבודה שאתה עושה במחשב שלך
- איך לעבוד על פרויקטים עם אחרים
- איך לתרום לתוכנה בקוד פתוח
### דרישות מוקדמות
### דרישות מקדימות
לפני שמתחילים, יש לבדוק אם Git מותקן. בטרמינל הקלד:
לפני שמתחילים, יש לבדוק אם Git מותקן. בטרמינל הקלד:
`git --version`
אם Git לא מותקן, [הורד Git](https://git-scm.com/downloads). לאחר מכן, הגדר את הפרופיל המקומי שלך ב-Git בטרמינל:
אם Git לא מותקן, [הורד Git](https://git-scm.com/downloads). לאחר מכן, הגדר את הפרופיל המקומי שלך ב-Git דרך הטרמינל:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
@ -41,28 +41,28 @@ CO_OP_TRANSLATOR_METADATA:
גש ל-[github.com](https://github.com/) ופתח חשבון אם עדיין אין לך, או התחבר ומלא את הפרופיל שלך.
✅ GitHub הוא לא מאגר הקוד היחיד בעולם; ישנם אחרים, אבל GitHub הוא המוכר ביותר.
✅ GitHub הוא לא מאגר הקוד היחיד בעולם; יש אחרים, אבל GitHub הוא המוכר ביותר.
### הכנה
תצטרך תיקייה עם פרויקט קוד במחשב המקומי שלך (מחשב נייד או PC), וגם מאגר ציבורי ב-GitHub, שישמש כדוגמה לאיך לתרום לפרויקטים של אחרים.
תצטרך תיקייה עם פרויקט קוד במחשב המקומי שלך (מחשב נייד או PC), ומאגר ציבורי ב-GitHub, שישמש כדוגמה לאיך לתרום לפרויקטים של אחרים.
---
## ניהול קוד
נניח שיש לך תיקייה מקומית עם פרויקט קוד ואתה רוצה להתחיל לעקוב אחרי ההתקדמות שלך באמצעות git - מערכת ניהול גרסאות. יש אנשים שמשווים שימוש ב-git לכתיבת מכתב אהבה לעצמך בעתיד. קריאת הודעות ה-commit שלך ימים, שבועות או חודשים לאחר מכן תאפשר לך להיזכר למה קיבלת החלטה מסוימת, או "לחזור אחורה" בשינוי - זאת כמובן אם כתבת הודעות commit טובות.
נניח שיש לך תיקייה מקומית עם פרויקט קוד ואתה רוצה להתחיל לעקוב אחרי ההתקדמות שלך באמצעות git - מערכת ניהול גרסאות. יש אנשים שמשווים שימוש ב-git לכתיבת מכתב אהבה לעצמך בעתיד. קריאת הודעות ה-commit שלך ימים, שבועות או חודשים לאחר מכן תאפשר לך להיזכר מדוע קיבלת החלטה מסוימת, או "לחזור אחורה" בשינוי - זאת כמובן אם כתבת הודעות commit טובות.
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **צור מאגר ב-GitHub**. ב-GitHub.com, בלשונית המאגרים, או מסרגל הניווט בצד ימין למעלה, מצא את כפתור **new repo**.
1. **צור מאגר ב-GitHub**. ב-GitHub.com, בלשונית המאגרים או מהסרגל העליון, מצא את כפתור **מאגר חדש**.
1. תן למאגר שלך (התיקייה) שם.
1. בחר **create repository**.
1. תן למאגר שלך (תיקייה) שם.
1. בחר **צור מאגר**.
1. **נווט לתיקיית העבודה שלך**. בטרמינל, עבור לתיקייה (המכונה גם ספרייה) שברצונך להתחיל לעקוב אחריה. הקלד:
@ -82,7 +82,7 @@ CO_OP_TRANSLATOR_METADATA:
git status
```
הפלט עשוי להיראות כך:
הפלט יכול להיראות כך:
```output
Changes not staged for commit:
@ -93,10 +93,10 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
בדרך כלל פקודת `git status` תספר לך דברים כמו אילו קבצים מוכנים ל"שמירה" במאגר או אילו קבצים שונו וייתכן שתרצה לשמור את השינויים שלהם.
בדרך כלל פקודת `git status`אומרת לך דברים כמו אילו קבצים מוכנים ל_שמירה_ במאגר או יש בהם שינויים שתרצה לשמר.
1. **הוסף את כל הקבצים למעקב**
זה נקרא גם שלב הקבצים/הוספת קבצים לאזור ההמתנה.
1. **הוסף את כל הקבצים למעקב**
זה נקרא גם שלב קבצים/הוספת קבצים לאזור ההמתנה.
```bash
git add .
@ -110,53 +110,53 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
זה מאפשר להוסיף רק קבצים נבחרים לאזור ההמתנה כאשר אינך רוצה לבצע commit לכל הקבצים בבת אחת.
זה עוזר לנו להוסיף רק קבצים נבחרים לאזור ההמתנה כשאנחנו לא רוצים להתחייב לכל הקבצים בבת אחת.
1. **בטל שלב לכל הקבצים**
1. **בטל שלב שלכל הקבצים**
```bash
git reset
```
פקודה זו מאפשרת לבטל שלב לכל הקבצים בבת אחת.
הפקודה הזו עוזרת לנו לבטל שלב של כל הקבצים בבת אחת.
1. **בטל שלב לקובץ מסוים**
1. **בטל שלב שלקובץ מסוים**
```bash
git reset [file or folder name]
```
פקודה זו מאפשרת לבטל שלב רק לקובץ מסוים בבת אחת שאינך רוצה לכלול ב-commit הבא.
הפקודה הזו עוזרת לנו לבטל שלב של קובץ מסוים בבת אחת שאנחנו לא רוצים לכלול בהתחייבות הבאה.
1. **שמור את העבודה שלך**. בשלב זה הוספת את הקבצים לאזור שנקרא _staging area_. מקום שבו Git עוקב אחרי הקבצים שלך. כדי להפוך את השינוי לקבוע, עליך לבצע _commit_ לקבצים. כדי לעשות זאת, צור _commit_ עם הפקודה `git commit`. ה-commit מייצג נקודת שמירה בהיסטוריה של המאגר שלך. הקלד את הפקודה הבאה כדי ליצור _commit_:
1. **שמור את העבודה שלך**. בשלב הזה הוספת את הקבצים לאזור שנקרא _אזור ההמתנה_. מקום שבו Git עוקב אחרי הקבצים שלך. כדי להפוך את השינוי לקבוע, עליך _להתחייב_ לקבצים. כדי לעשות זאת, צור _commit_ עם הפקודה `git commit`. ה-commit מייצג נקודת שמירה בהיסטוריה של המאגר שלך. הקלד את הפקודה הבאה כדי ליצור commit:
```bash
git commit -m "first commit"
```
זה מבצע commit לכל הקבצים שלך, עם ההודעה "first commit". להודעות commit עתידיות תרצה להיות יותר תיאורי כדי להעביר איזה סוג של שינוי ביצעת.
זה מתחייב לכל הקבצים שלך, עם ההודעה "first commit". להודעות commit עתידיות תרצה להיות יותר תיאורי כדי להעביר איזה סוג שינוי ביצעת.
1. **חבר את מאגר ה-Git המקומי שלך ל-GitHub**. מאגר Git הוא טוב במחשב שלך, אבל בשלב מסוים תרצה שיהיה לך גיבוי של הקבצים שלך במקום כלשהו וגם להזמין אנשים אחרים לעבוד איתך על המאגר. מקום נהדר לעשות זאת הוא GitHub. זכור שכבר יצרנו מאגר ב-GitHub, כך שהדבר היחיד שצריך לעשות הוא לחבר את מאגר ה-Git המקומי שלך ל-GitHub. הפקודה `git remote add` תעשה בדיוק את זה. הקלד את הפקודה הבאה:
1. **חבר את מאגר Git המקומי שלך ל-GitHub**. מאגר Git טוב במחשב שלך, אבל בשלב מסוים תרצה שיהיה לך גיבוי של הקבצים שלך איפשהו וגם להזמין אנשים אחרים לעבוד איתך על המאגר שלך. מקום נהדר לעשות זאת הוא GitHub. זוכר שכבר יצרנו מאגר ב-GitHub? אז הדבר היחיד שצריך לעשות הוא לחבר את מאגר Git המקומי שלך ל-GitHub. הפקודה `git remote add` תעשה בדיוק את זה. הקלד את הפקודה הבאה:
> הערה, לפני שאתה מקליד את הפקודה, עבור לדף המאגר שלך ב-GitHub כדי למצוא את כתובת ה-URL של המאגר. תשתמש בה בפקודה למטה. החלף את ```https://github.com/username/repository_name.git``` בכתובת ה-URL של GitHub שלך.
> שים לב, לפני שאתה מקליד את הפקודה, עבור לדף המאגר שלך ב-GitHub כדי למצוא את כתובת ה-URL של המאגר. תשתמש בה בפקודה למטה. החלף ```https://github.com/username/repository_name.git``` בכתובת ה-URL של GitHub שלך.
זה יוצר _remote_, או חיבור, בשם "origin" שמצביע על מאגר ה-GitHub שיצרת קודם.
זה יוצר _remote_, או חיבור, בשם "origin" שמצביע על המאגר ב-GitHub שיצרת קודם.
1. **שלח קבצים מקומיים ל-GitHub**. עד כה יצרת _חיבור_ בין המאגר המקומי למאגר ה-GitHub. בוא נשלח את הקבצים האלה ל-GitHub עם הפקודה `git push`, כך:
1. **שלח קבצים מקומיים ל-GitHub**. עד כה יצרת _חיבור_ בין המאגר המקומי למאגר ב-GitHub. בוא נשלח את הקבצים האלה ל-GitHub עם הפקודה הבאה `git push`, כך:
> הערה, שם הסניף שלך עשוי להיות שונה כברירת מחדל מ-```main```.
> שים לב, שם הענף שלך עשוי להיות שונה כברירת מחדל מ```main```.
```bash
git push -u origin main
```
זה שולח את ה-commits שלך בסניף "main" ל-GitHub.
זה שולח את ה-commits שלך בענף "main" ל-GitHub. הגדרת הענף `upstream` כולל `-u` בפקודה יוצרת קישור בין הענף המקומי שלך לענף המרוחק, כך שתוכל פשוט להשתמש ב-git push או git pull מבלי לציין את שם הענף בעתיד. Git ישתמש אוטומטית בענף ה-upstream ולא תצטרך לציין את שם הענף במפורש בפקודות עתידיות.
2. **להוסיף שינויים נוספים**. אם תרצה להמשיך לבצע שינויים ולדחוף אותם ל-GitHub, תצטרך להשתמש בשלוש הפקודות הבאות:
2. **להוסיף עוד שינויים**. אם תרצה להמשיך לבצע שינויים ולדחוף אותם ל-GitHub, תצטרך להשתמש בשלוש הפקודות הבאות:
```bash
git add .
@ -164,176 +164,181 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> טיפ, ייתכן שתרצה גם לאמץ קובץ `.gitignore` כדי למנוע מקבצים שאינך רוצה לעקוב אחריהם להופיע ב-GitHub - כמו קובץ הערות שאתה שומר באותה תיקייה אבל אין לו מקום במאגר ציבורי. תוכל למצוא תבניות לקבצי `.gitignore` ב-[.gitignore templates](https://github.com/github/gitignore).
> טיפ, ייתכן שתרצה גם לאמץ קובץ `.gitignore` כדי למנוע מקבצים שאתה לא רוצה לעקוב אחריהם להופיע ב-GitHub - כמו קובץ הערות שאתה שומר באותה תיקייה אבל אין לו מקום במאגר ציבורי. תוכל למצוא תבניות לקבצי `.gitignore` ב-[תבניות .gitignore](https://github.com/github/gitignore).
#### הודעות Commit
שורת נושא מצוינת להודעת commit משלימה את המשפט הבא:
אם ייושם, ה-commit הזה <שורת הנושא שלך כאן>
שורת נושא נהדרת להודעת commit ב-Git משלימה את המשפט הבא:
אם ייושם, commit זה יבצע<שורת הנושא שלך כאן>
לשורת הנושא השתמש בזמן הווה ובצורת ציווי: "שנה" ולא "שינה" או "משנה".
כמו בשורת הנושא, גם בגוף (אופציונלי) השתמש בזמן הווה ובצורת ציווי. הגוף צריך לכלול את המוטיבציה לשינוי ולהשוות זאת להתנהגות הקודמת. אתה מסביר את ה"למה", לא את ה"איך".
לנושא השתמש בזמן הווה, ציווי: "שנה" ולא "שינה" או "משנה".
כמו בנושא, גם בגוף (אופציונלי) השתמש בזמן הווה, ציווי. הגוף צריך לכלול את המוטיבציה לשינוי ולהשוות זאת להתנהגות הקודמת. אתה מסביר את ה`למה`, לא את ה`איך`.
✅ קח כמה דקות לגלוש ב-GitHub. האם תוכל למצוא הודעת commit ממש טובה? האם תוכל למצוא אחת מינימלית במיוחד? איזה מידע לדעתך הוא החשוב והשימושי ביותר להעביר בהודעת commit?
✅ הקדש כמה דקות לגלוש ב-GitHub. האם תוכל למצוא הודעת commit ממש טובה? האם תוכל למצוא אחת מינימלית מאוד? איזה מידע לדעתך הכי חשוב ומועיל להעביר בהודעת commit?
### משימה: שתף פעולה
הסיבה העיקרית להעלאת דברים ל-GitHub הייתה לאפשר שיתוף פעולה עם מפתחים אחרים.
הסיבה העיקרית לשים דברים ב-GitHub הייתה לאפשר שיתוף פעולה עם מפתחים אחרים.
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
במאגר שלך, נווט ל-`Insights > Community` כדי לראות איך הפרויקט שלך עומד ביחס לסטנדרטים קהילתיים מומלצים.
במאגר שלך, נווט ל-`Insights > Community` כדי לראות איך הפרויקט שלך משתווה לסטנדרטים קהילתיים מומלצים.
הנה כמה דברים שיכולים לשפר את מאגר ה-GitHub שלך:
הנה כמה דברים שיכולים לשפר את המאגר שלך ב-GitHub:
- **תיאור**. האם הוספת תיאור לפרויקט שלך?
- **README**. האם הוספת README? GitHub מספק הנחיות לכתיבת [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/)?
- **הנחיות לתרומה**. האם לפרויקט שלך יש [הנחיות לתורמים](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **רישיון**. אולי הכי חשוב, [רישיון](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
כל המשאבים הללו יועילו לקליטת חברי צוות חדשים. ואלו בדרך כלל הדברים הראשונים שתורמים חדשים מסתכלים עליהם לפני שהם בכלל מסתכלים על הקוד שלך, כדי להבין אם הפרויקט שלך הוא המקום הנכון עבורם להשקיע את זמנם.
כל המשאבים האלה יועילו בהכנסת חברי צוות חדשים. ואלו בדרך כלל הדברים שתורמים חדשים מסתכלים עליהם לפני שהם בכלל מסתכלים על הקוד שלך, כדי להבין אם הפרויקט שלך הוא המקום הנכון עבורם להשקיע את זמנם.
✅ קבצי README, למרות שלוקח זמן להכין אותם, לעיתים קרובות מוזנחים על ידי מתחזים עסוקים. האם תוכל למצוא דוגמה לאחד שמתאר בצורה יוצאת דופן? הערה: ישנם [כלים ליצירת README טובים](https://www.makeareadme.com/) שאולי תרצה לנסות.
✅ קבצי README, למרות שהם דורשים זמן להכנה, לעיתים קרובות מוזנחים על ידי מנהלים עסוקים. האם תוכל למצוא דוגמה ל-README תיאורי במיוחד? הערה: ישנם [כלים שיעזרו ליצור README טובים](https://www.makeareadme.com/) שאולי תרצה לנסות.
### משימה: מיזוג קוד
מסמכי תרומה עוזרים לאנשים לתרום לפרויקט. הם מסבירים אילו סוגי תרומות אתה מחפש ואיך התהליך עובד. תורמים יצטרכו לעבור סדרת שלבים כדי להיות מסוגלים לתרום למאגר שלך ב-GitHub:
1. **פיצול המאגר שלך**. סביר להניח שתרצה שאנשים יבצעו _fork_ לפרויקט שלך. פיצול פירושו יצירת עותק של המאגר שלך בפרופיל ה-GitHub שלהם.
1. **פיצול המאגר שלך**. סביר להניח שתרצה שאנשים _יפצלו_ את הפרויקט שלך. פיצול פירושו יצירת עותק של המאגר שלך בפרופיל GitHub שלהם.
1. **שכפול**. משם הם ישכפלו את הפרויקט למחשב המקומי שלהם.
1. **יצירת סניף**. תרצה לבקש מהם ליצור _סניף_ לעבודה שלהם.
1. **מיקוד השינוי לאזור אחד**. בקש מהתורמים להתרכז בתרומות שלהם בדבר אחד בכל פעם - כך הסיכויים שתוכל _למזג_ את העבודה שלהם גבוהים יותר. דמיין שהם כותבים תיקון באג, מוסיפים תכונה חדשה ומעדכנים כמה בדיקות - מה אם תרצה, או תוכל ליישם רק 2 מתוך 3, או 1 מתוך 3 שינויים?
1. **יצירת ענף**. תרצה לבקש מהם ליצור _ענף_ עבור העבודה שלהם.
1. **מיקוד השינוי באזור אחד**. בקש מהתורמים להתרכז בתרומות שלהם בדבר אחד בכל פעם - כך הסיכויים שתוכל _למזג_ את העבודה שלהם גבוהים יותר. דמיין שהם כותבים תיקון באג, מוסיפים תכונה חדשה ומעדכנים כמה בדיקות - מה אם תרצה, או תוכל ליישם רק 2 מתוך 3, או 1 מתוך 3 שינויים?
✅ דמיין מצב שבו סניפים הם קריטיים במיוחד לכתיבה ושחרור של קוד טוב. אילו מקרים אתה יכול לחשוב עליהם?
✅ דמיין מצב שבו ענפים הם קריטיים במיוחד לכתיבה ושחרור קוד טוב. אילו מקרים שימושיים אתה יכול לחשוב עליהם?
> הערה, היה השינוי שאתה רוצה לראות בעולם, וצור סניפים גם לעבודה שלך. כל ה-commits שתבצע ייעשו על הסניף שאתה כרגע "נמצא" עליו. השתמש ב-`git status` כדי לראות באיזה סניף אתה נמצא.
> הערה, היה השינוי שאתה רוצה לראות בעולם, ויצור ענפים גם עבור העבודה שלך. כל ה-commits שתבצע יבוצעו על הענף שאתה כרגע "checked out" אליו. השתמש ב-`git status` כדי לראות באיזה ענף אתה נמצא.
בוא נעבור על תהליך עבודה של תורם. נניח שהתורם כבר ביצע _fork_ו-_clone_ למאגר כך שיש לו מאגר Git מוכן לעבודה במחשב המקומי שלו:
בוא נעבור על תהליך העבודה של תורם. נניח שהתורם כבר _פיצל_ו_שכפל_ את המאגר כך שיש לו מאגר Git מוכן לעבודה במחשב המקומי שלו:
1. **צור סניף**. השתמש בפקודה `git branch` כדי ליצור סניף שיכיל את השינויים שהם מתכוונים לתרום:
1. **צור ענף**. השתמש בפקודה `git branch` כדי ליצור ענף שיכיל את השינויים שהם מתכוונים לתרום:
```bash
git branch [branch-name]
```
1. **עבור לסניף העבודה**. עבור לסניף שציינת ועדכן את ספריית העבודה עם `git switch`:
1. **עבור לענף העבודה**. עבור לענף שצוין ועדכן את ספריית העבודה עם `git switch`:
```bash
git switch [branch-name]
```
1. **בצע עבודה**. בשלב זה תרצה להוסיף את השינויים שלך. אל תשכח להודיע ל-Git על כך עם הפקודות הבאות:
1. **בצע עבודה**. בשלב הזה תרצה להוסיף את השינויים שלך. אל תשכח לספר ל-Git על כך עם הפקודות הבאות:
```bash
git add .
git commit -m "my changes"
```
ודא שאתה נותן ל-commit שלך שם טוב, לטובתך ולטובת מתחזק המאגר שאתה עוזר לו.
ודא שאתה נותן ל-commit שלך שם טוב, למענך וגם למען מנהל המאגר שאתה עוזר לו.
1. **שלב את העבודה שלך עם סניף ה-main**. בשלב מסוים סיימת לעבוד ואתה רוצה לשלב את העבודה שלך עם זו של סניף ה-main. ייתכן שסניף ה-main השתנה בינתיים, אז ודא שאתה מעדכן אותו לגרסה האחרונה עם הפקודות הבאות:
1. **שלב את העבודה שלך עם הענף `main`**. בשלב מסוים סיימת לעבוד ואתה רוצה לשלב את העבודה שלך עם זו של הענף `main`. הענף `main` עשוי להשתנות בינתיים, אז ודא שאתה קודם מעדכן אותו לגרסה האחרונה עם הפקודות הבאות:
```bash
git switch main
git pull
```
בשלב זה תרצה לוודא שכל _קונפליקטים_, מצבים שבהם Git לא יכול _לשלב_ בקלות את השינויים, יקרו בסניף העבודה שלך. לכן הרץ את הפקודות הבאות:
בשלב הזה תרצה לוודא שכל _התנגשויות_, מצבים שבהם Git לא יכול בקלות _לשלב_ את השינויים, יקרו בענף העבודה שלך. לכן, הרץ את הפקודות הבאות:
```bash
git switch [branch_name]
git merge main
```
זה יביא את כל השינויים מ-main לסניף שלך, ובתקווה תוכל פשוט להמשיך. אם לא, VS Code יראה לך היכן Git _מבולבל_ ותוכל לשנות את הקבצים המושפעים כדי לציין איזה תוכן הוא המדויק ביותר.
הפקודה `git merge main` תביא את כל השינויים מ-`main` לענף שלך. בתקווה שתוכל פשוט להמשיך. אם לא, VS Code יגיד לך איפה Git _מבולבל_ ואתה פשוט תשנה את הקבצים המושפעים כדי לומר איזה תוכן הוא המדויק ביותר.
כדי לעבור לענף אחר, השתמש בפקודה המודרנית `git switch`:
```bash
git switch [branch_name]
1. **שלח את העבודה שלך ל-GitHub**. שליחת העבודה שלך ל-GitHub פירושה שני דברים. דחיפת הסניף שלך למאגר שלך ואז פתיחת PR, Pull Request.
1. **שלח את העבודה שלך ל-GitHub**. שליחת העבודה שלך ל-GitHub פירושה שני דברים. דחיפת הענף שלך למאגר שלך ואז פתיחת PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
הפקודה לעיל יוצרת את הסניף במאגר המפוצל שלך.
1. **פתח PR**. לאחר מכן, תרצה לפתוח PR. עשה זאת על ידי ניווט למאגר המפוצל ב-GitHub. תראה אינדיקציה ב-GitHub ששואלת אם ברצונך ליצור PR חדש, לחץ על כך ותועבר לממשק שבו תוכל לשנות את כותרת הודעת ה-commit, לתת לה תיאור מתאים יותר. כעת מתחזק המאגר שממנו פיצלת יראה את ה-PR הזה ו-_בתקווה_ יעריך ו-_ימזג_ את ה-PR שלך. עכשיו אתה תורם, כל הכבוד :)
הפקודה לעיל יוצרת את הענף במאגר המפוצל שלך.
1. **פתח PR**. עכשיו, הגיע הזמן לפתוח PR. כדי לעשות זאת, נווט למאגר המפוצל שלך ב-GitHub. תראה ב-GitHub הודעה שמציעה לך ליצור PR חדש. לחץ עליה ותועבר לממשק שבו תוכל לשנות את כותרת הודעת ה-commit ולתת תיאור מתאים יותר. עכשיו, מנהל המאגר שממנו פיצלת יראה את ה-PR שלך ו_בתקווה_ יעריך אותו ו_ימזג_ אותו. מזל טוב, אתה עכשיו תורם, איזה כיף :)
1. **נקה אחריך**. נחשב כפרקטיקה טובה _לנקות_ לאחר שמיזגת בהצלחה PR. תרצה לנקות גם את הסניף המקומי שלך וגם את הסניף שדחפת ל-GitHub. ראשית, מחק אותו מקומית עם הפקודה הבאה:
1. **ניקוי**. נחשב כפרקטיקה טובה לבצע _ניקוי_ לאחר שמיזגת בהצלחה PR. כדאי לנקות גם את הסניף המקומי שלך וגם את הסניף שדחפת ל-GitHub. קודם כל, נמחק אותו מקומית עם הפקודה הבאה:
```bash
git branch -d [branch-name]
```
לאחר מכן, עבור לדף GitHub של המאגר המפוצל והסר את הסניף המרוחק שדחפת אליו.
ודא שאתה עובר לדף GitHub של המאגר המפוצל הבא ומסיר את הסניף המרוחק שדחפת אליו.
`Pull request` נראה כמו מונח מוזר, כי בעצם אתם רוצים לדחוף את השינויים שלכם לפרויקט. אבל המתחזק (בעל הפרויקט) או צוות הליבה צריכים לשקול את השינויים שלכם לפני שהם ממוזגים לענף ה-"main" של הפרויקט, כך שבעצם אתם מבקשים החלטה על שינוי מהמתחזק.
`Pull request` אולי נשמע כמו מונח מוזר, כי בעצם אתה רוצה לדחוף את השינויים שלך לפרויקט. אבל המנהל (בעל הפרויקט) או הצוות המרכזי צריכים לשקול את השינויים שלך לפני שהם ממזגים אותם עם הסניף "הראשי" של הפרויקט, כך שבעצם אתה מבקש החלטה לשינוי ממנהל הפרויקט.
בקשת משיכה היא המקום להשוות ולדון בהבדלים שהוכנסו לענף, עם ביקורות, הערות, בדיקות משולבות ועוד. בקשת משיכה טובה עוקבת פחות או יותר אחרי אותם כללים כמו הודעת commit. ניתן להוסיף הפניה לבעיה במעקב הבעיות, כאשר העבודה שלכם, למשל, פותרת בעיה. זה נעשה באמצעות `#` ואחריו מספר הבעיה שלכם. לדוגמה `#97`.
Pull request הוא המקום להשוות ולדון בהבדלים שהוכנסו בסניף, עם ביקורות, הערות, בדיקות משולבות ועוד. Pull request טוב עוקב פחות או יותר אחרי אותם כללים כמו הודעת commit. ניתן להוסיף הפניה לבעיה ב-tracker של הבעיות, למשל כאשר העבודה שלך פותרת בעיה. עושים זאת באמצעות `#` ואחריו מספר הבעיה. לדוגמה:`#97`.
🤞נקווה שכל הבדיקות יעברו בהצלחה ובעלי הפרויקט ימזגו את השינויים שלכם לפרויקט🤞
🤞בתקווה שכל הבדיקות יעברו ובעלי הפרויקט ימזגו את השינויים שלך לפרויקט🤞
עדכנו את הענף המקומי הנוכחי שלכם עם כל ה-commits החדשים מהענף המרוחק המתאים ב-GitHub:
עדכן את הסניף המקומי הנוכחי שלך עם כל ה-commits החדשים מהסניף המרוחק המתאים ב-GitHub:
`git pull`
## איך לתרום לקוד פתוח
ראשית, בואו נמצא מאגר (או **repo**) ב-GitHub שמעניין אתכם ושאליו תרצו לתרום שינוי. תרצו להעתיק את התוכן שלו למחשב שלכם.
ראשית, בוא נמצא מאגר (**repo**) ב-GitHub שמעניין אותך ושאליו תרצה לתרום שינוי. תרצה להעתיק את התוכן שלו למחשב שלך.
✅ דרך טובה למצוא מאגרים שמתאימים למתחילים היא [לחפש לפי התגית 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ דרך טובה למצוא מאגרים ידידותיים למתחילים היא [לחפש לפי התג 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
יש כמה דרכים להעתיק קוד. אחת הדרכים היא "לשכפל" את התוכן של המאגר, באמצעות HTTPS, SSH, או שימוש ב-GitHub CLI (ממשק שורת הפקודה).
יש כמה דרכים להעתיק קוד. אחת מהן היא "לשכפל" את התוכן של המאגר, באמצעות HTTPS, SSH, או באמצעות GitHub CLI (ממשק שורת הפקודה).
פתחו את הטרמינל שלכם ושכפלו את המאגר כך:
פתח את הטרמינל שלך ושכפל את המאגר כך:
`git clone https://github.com/ProjectURL`
כדי לעבוד על הפרויקט, עברו לתיקייה הנכונה:
כדי לעבוד על הפרויקט, עבור לתיקייה הנכונה:
`cd ProjectURL`
ניתן גם לפתוח את כל הפרויקט באמצעות [Codespaces](https://github.com/features/codespaces), עורך הקוד המובנה של GitHub /סביבת פיתוח בענן, או [GitHub Desktop](https://desktop.github.com/).
תוכל גם לפתוח את כל הפרויקט באמצעות [Codespaces](https://github.com/features/codespaces), עורך הקוד המובנה/סביבת הפיתוח בענן של GitHub, או [GitHub Desktop](https://desktop.github.com/).
לבסוף, ניתן להוריד את הקוד בתיקייה מכווצת.
לבסוף, תוכל להוריד את הקוד בתיקייה מכווצת.
### עוד כמה דברים מעניינים על GitHub
### כמה דברים מעניינים נוספים על GitHub
ניתן לככב, לעקוב ו/או "למזלג" כל מאגר ציבורי ב-GitHub. תוכלו למצוא את המאגרים שכיכבתם בתפריט הנפתח בפינה הימנית העליונה. זה כמו לשמור סימניה, אבל לקוד.
תוכל לככב, לעקוב ו/או "לפצל" כל מאגר ציבורי ב-GitHub. תוכל למצוא את המאגרים שכיכבת בתפריט הנפתח בפינה הימנית העליונה. זה כמו סימניות, אבל לקוד.
לפרויקטים יש מעקב בעיות, לרוב ב-GitHub בלשונית "Issues" אלא אם צוין אחרת, שם אנשים דנים בבעיות הקשורות לפרויקט. ולשונית Pull Requests היא המקום שבו אנשים דנים ובודקים שינויים שנמצאים בתהליך.
לפרויקטים יש tracker לבעיות, בדרך כלל ב-GitHub בלשונית "Issues" אלא אם צוין אחרת, שבו אנשים דנים בבעיות הקשורות לפרויקט. ולשונית Pull Requests היא המקום שבו אנשים דנים ומבקרים שינויים שנמצאים בתהליך.
ייתכן שלפרויקטים יש גם דיונים בפורומים, רשימות תפוצה, או ערוצי צ'אט כמו Slack, Discord או IRC.
ייתכן שלפרויקטים יש גם דיונים בפורומים, רשימות תפוצה או ערוצי צ'אט כמו Slack, Discord או IRC.
✅ הסתכלו סביב המאגר החדש שלכם ב-GitHub ונסו כמה דברים, כמו עריכת הגדרות, הוספת מידע למאגר שלכם, ויצירת פרויקט (כמו לוח Kanban). יש הרבה מה לעשות!
✅ הסתכל סביב המאגר החדש שלך ב-GitHub ונסה כמה דברים, כמו עריכת הגדרות, הוספת מידע למאגר שלך ויצירת פרויקט (כמו לוח Kanban). יש הרבה מה לעשות!
---
## 🚀 אתגר
## 🚀 אתגר
עבדו בזוגות עם חבר על הקוד אחד של השני. צרו פרויקט בשיתוף פעולה, מזלגו קוד, צרו ענפים, ומזגו שינויים.
שתף פעולה עם חבר כדי לעבוד על הקוד אחד של השני. צרו פרויקט יחד, פצלו קוד, צרו סניפים ומזגו שינויים.
## חידון לאחר ההרצאה
## חידון לאחר ההרצאה
[חידון לאחר ההרצאה](https://ff-quizzes.netlify.app/web/en/)
## סקירה ולימוד עצמי
קראו עוד על [תרומה לתוכנה בקוד פתוח](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
קרא עוד על [תרומה לתוכנה בקוד פתוח](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[דף עזר ל-Git](https://training.github.com/downloads/github-git-cheat-sheet/).
תרגלו, תרגלו, תרגלו. ל-GitHub יש מסלולי למידה מעולים זמינים דרך [skills.github.com](https://skills.github.com):
תרגל, תרגל, תרגל. ל-GitHub יש מסלולי לימוד מצוינים זמינים דרך [skills.github.com](https://skills.github.com):
- [השבוע הראשון ב-GitHub](https://skills.github.com/#first-week-on-github)
תמצאו שם גם קורסים מתקדמים יותר.
תמצא גם קורסים מתקדמים יותר.
## משימה
## משימה
השלימו את [הקורס השבוע הראשון ב-GitHub](https://skills.github.com/#first-week-on-github)
השלם את [הקורס השבוע הראשון ב-GitHub](https://skills.github.com/#first-week-on-github)
---
**כתב ויתור**:
מסמך זה תורגם באמצעות שירות תרגום מבוסס בינה מלאכותית [Co-op Translator](https://github.com/Azure/co-op-translator). למרות שאנו שואפים לדיוק, יש לקחת בחשבון שתרגומים אוטומטיים עשויים להכיל שגיאות או אי-דיוקים. המסמך המקורי בשפתו המקורית נחשב למקור הסמכותי. למידע קריטי, מומלץ להשתמש בתרגום מקצועי על ידי מתרגם אנושי. איננו נושאים באחריות לכל אי-הבנה או פרשנות שגויה הנובעת משימוש בתרגום זה.
**הצהרת אחריות**:
מסמך זה תורגם באמצעות שירות תרגום מבוסס בינה מלאכותית [Co-op Translator](https://github.com/Azure/co-op-translator). למרות שאנו שואפים לדיוק, יש לקחת בחשבון שתרגומים אוטומטיים עשויים להכיל שגיאות או אי דיוקים. המסמך המקורי בשפתו המקורית צריך להיחשב כמקור סמכותי. עבור מידע קריטי, מומלץ להשתמש בתרגום מקצועי על ידי אדם. אנו לא נושאים באחריות לאי הבנות או לפרשנויות שגויות הנובעות משימוש בתרגום זה.
शुरू करने से पहले, आपको यह जांचना होगा कि Git इंस्टॉल है या नहीं। टर्मिनल में टाइप करें:
शुरू करने से पहले, आपको यह जांचना होगा कि 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 पहले से कॉन्फ़िगर है या नहीं, आप टाइप कर सकते हैं:
`git config --list`
आपको एक GitHub खाता, एक कोड एडिटर (जैसे Visual Studio Code), और टर्मिनल (या कमांड प्रॉम्प्ट) खोलने की आवश्यकता होगी।
आपको एक GitHub खाता, एक कोड एडिटर (जैसे Visual Studio Code), और टर्मिनल (या: कमांड प्रॉम्प्ट) खोलने की आवश्यकता होगी।
[github.com](https://github.com/) पर जाएं और यदि आपने पहले से खाता नहीं बनाया है, तो खाता बनाएं या लॉग इन करें और अपनी प्रोफ़ाइल भरें।
[github.com](https://github.com/) पर जाएं और यदि आपने पहले से खाता नहीं बनाया है तो एक खाता बनाएं, या लॉग इन करें और अपनी प्रोफ़ाइल भरें।
✅ GitHub दुनिया में एकमात्र कोड रिपॉजिटरी नहीं है; अन्य भी हैं, लेकिन GitHub सबसे प्रसिद्ध है।
### तैयारी
आपको अपने स्थानीय मशीन (लैपटॉप या पीसी) पर कोड प्रोजेक्ट के साथ एक फ़ोल्डर और GitHub पर एक सार्वजनिक रिपॉजिटरी की आवश्यकता होगी, जो दूसरों के प्रोजेक्ट्स में योगदान करने का उदाहरण प्रदान करेगा।
आपको अपने स्थानीय मशीन (लैपटॉप या पीसी) पर एक कोड प्रोजेक्ट के साथ एक फ़ोल्डर और GitHub पर एक सार्वजनिक रिपॉजिटरी की आवश्यकता होगी, जो दूसरों के प्रोजेक्ट्स में योगदान करने के तरीके के उदाहरण के रूप में काम करेगा।
---
## कोड प्रबंधन
मान लीजिए आपके पास स्थानीय रूप से एक कोड प्रोजेक्ट वाला फ़ोल्डर है और आप Git - वर्ज़न कंट्रोल सिस्टम का उपयोग करके अपनी प्रगति को ट्रैक करना शुरू करना चाहते हैं। कुछ लोग Git का उपयोग करने की तुलना भविष्य के स्वयं को प्रेम पत्र लिखने से करते हैं। जब आप अपने कमिट संदेशों को दिनों, हफ्तों या महीनों बाद पढ़ेंगे, तो आप यह याद कर पाएंगे कि आपने कोई निर्णय क्यों लिया था, या किसी बदलाव को "रोलबैक" कर सकते हैं - बशर्ते आपने अच्छे "कमिट संदेश" लिखे हों।
मान लें कि आपके पास स्थानीय रूप से एक कोड प्रोजेक्ट के साथ एक फ़ोल्डर है और आप git - संस्करण नियंत्रण प्रणाली का उपयोग करके अपनी प्रगति को ट्रैक करना शुरू करना चाहते हैं। कुछ लोग git का उपयोग करने की तुलना भविष्य के लिए खुद को एक प्रेम पत्र लिखने से करते हैं। जब आप अपने कमिट संदेशों को दिनों, हफ्तों या महीनों बाद पढ़ेंगे, तो आप यह याद कर पाएंगे कि आपने कोई निर्णय क्यों लिया था, या किसी बदलाव को "रोलबैक" कर सकते हैं - बशर्ते आपने अच्छे "कमिट संदेश" लिखे हों।
### कार्य: एक रिपॉजिटरी बनाएं और कोड कमिट करें
> वीडियो देखें
> वीडियो देखें
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub पर रिपॉजिटरी बनाएं**। GitHub.com पर, रिपॉजिटरी टैब में, या टॉप-राइट नेविगेशन बार से, **नई रिपो** बटन ढूंढें।
1. अपनी रिपॉजिटरी (फ़ोल्डर) को एक नाम दें।
1. **GitHub पर रिपॉजिटरी बनाएं**। GitHub.com पर, रिपॉजिटरी टैब में, या नेविगेशन बार के शीर्ष-दाईं ओर, **नया रिपो** बटन खोजें।
1. अपनी रिपॉजिटरी (फ़ोल्डर) को एक नाम दें
1. **रिपॉजिटरी बनाएं** चुनें।
1. **अपने कार्य फ़ोल्डर पर जाएं**। अपने टर्मिनल में, उस फ़ोल्डर (जिसे डायरेक्टरी भी कहा जाता है) पर स्विच करें जिसे आप ट्रैक करना शुरू करना चाहते हैं। टाइप करें:
@ -93,16 +94,16 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
आमतौर पर `git status` कमांड आपको यह बताता है कि कौन सी फाइलें _सेव_ करने के लिए तैयार हैं या उनमें बदलाव हैं जिन्हें आप सहेजना चाहते हैं।
आमतौर पर `git status` कमांड आपको यह बताता है कि कौन सी फाइलें _सेव_ करने के लिए तैयार हैं या उनमें बदलाव हैं जिन्हें आप स्थायी बनाना चाहते हैं।
1. **सभी फाइलें ट्रैकिंग के लिए जोड़ें**
1. **सभी फाइलें ट्रैकिंग के लिए जोड़ें**
इसे फाइलों को स्टेजिंग एरिया में जोड़ना भी कहा जाता है।
```bash
git add .
```
`git add` और `.` तर्क इंगित करता है कि आपकी सभी फाइलें और बदलाव ट्रैकिंग के लिए हैं।
`git add` और `.` तर्क इंगित करता है कि आपकी सभी फाइलें और बदलाव ट्रैकिंग के लिए हैं।
1. **चयनित फाइलें ट्रैकिंग के लिए जोड़ें**
@ -112,7 +113,7 @@ CO_OP_TRANSLATOR_METADATA:
यह हमें केवल चयनित फाइलों को स्टेजिंग एरिया में जोड़ने में मदद करता है जब हम सभी फाइलों को एक बार में कमिट नहीं करना चाहते।
1. **सभी फाइलों को अनस्टेज करें**
1. **सभी फाइलें अनस्टेज करें**
```bash
git reset
@ -120,7 +121,7 @@ CO_OP_TRANSLATOR_METADATA:
यह कमांड हमें एक बार में सभी फाइलों को अनस्टेज करने में मदद करता है।
1. **किसी विशेष फाइल को अनस्टेज करें**
1. **एक विशेष फाइल को अनस्टेज करें**
```bash
git reset [file or folder name]
@ -128,33 +129,33 @@ CO_OP_TRANSLATOR_METADATA:
यह कमांड हमें केवल एक विशेष फाइल को अनस्टेज करने में मदद करता है जिसे हम अगले कमिट में शामिल नहीं करना चाहते।
1. **अपने कार्य को स्थायी बनाएं**। इस बिंदु पर आपने फाइलों को तथाकथित _स्टेजिंग एरिया_ में जोड़ा है। यह वह जगह है जहां Git आपकी फाइलों को ट्रैक कर रहा है। बदलाव को स्थायी बनाने के लिए आपको फाइलों को _कमिट_ करना होगा। ऐसा करने के लिए `git commit` कमांड का उपयोग करें। एक _कमिट_ आपके रिपॉजिटरी के इतिहास में एक सेविंग पॉइंट का प्रतिनिधित्व करता है। टाइप करें:
1. **अपने कार्य को स्थायी बनाएं**। इस बिंदु पर आपने फाइलों को तथाकथित _स्टेजिंग एरिया_ में जोड़ दिया है। एक जगह जहां Git आपकी फाइलों को ट्रैक कर रहा है। बदलाव को स्थायी बनाने के लिए आपको फाइलों को _कमिट_ करना होगा। ऐसा करने के लिए आप `git commit` कमांड का उपयोग करके एक _कमिट_ बनाते हैं। एक _कमिट_ आपके रिपॉजिटरी के इतिहास में एक सेविंग पॉइंट का प्रतिनिधित्व करता है। टाइप करें:
```bash
git commit -m "first commit"
```
यह आपकी सभी फाइलों को कमिट करता है, "पहला कमिट" संदेश जोड़ते हुए। भविष्य के कमिट संदेशों के लिए, आप अपने द्वारा किए गए बदलाव के प्रकार को व्यक्त करने के लिए अधिक वर्णनात्मक होना चाहेंगे।
यह आपकी सभी फाइलों को कमिट करता है, और संदेश "पहला कमिट" जोड़ता है। भविष्य के कमिट संदेशों के लिए आप अपने विवरण में अधिक वर्णनात्मक होना चाहेंगे ताकि यह स्पष्ट हो सके कि आपने किस प्रकार का बदलाव किया है।
1. **अपने स्थानीय Git रिपो को GitHub से कनेक्ट करें**। एक Git रिपो आपके मशीन पर अच्छा है, लेकिन किसी बिंदु पर आप अपनी फाइलों का बैकअप कहीं और रखना चाहेंगे और अन्य लोगों को अपने रिपो पर काम करने के लिए आमंत्रित करना चाहेंगे। ऐसा करने के लिए `git remote add` कमांड का उपयोग करें। टाइप करें:
1. **अपने स्थानीय Git रिपो को GitHub से कनेक्ट करें**। एक Git रिपो आपके मशीन पर अच्छा है लेकिन किसी बिंदु पर आप अपनी फाइलों का बैकअप कहीं रखना चाहेंगे और अन्य लोगों को अपने रिपो पर काम करने के लिए आमंत्रित करना चाहेंगे। ऐसा करने के लिए एक शानदार जगह GitHub है। याद रखें कि हमने पहले ही GitHub पर एक रिपो बनाया है, इसलिए हमें केवल अपने स्थानीय Git रिपो को GitHub से कनेक्ट करना है। कमांड `git remote add` यही करेगा। निम्नलिखित कमांड टाइप करें:
> नोट: कमांड टाइप करने से पहले अपने GitHub रिपो पेज पर जाएं और रिपॉजिटरी URL ढूंढें। आप इसे नीचे दिए गए कमांड में उपयोग करेंगे। ```https://github.com/username/repository_name.git``` को अपने GitHub URL से बदलें।
> नोट, कमांड टाइप करने से पहले अपने GitHub रिपो पेज पर जाएं और रिपॉजिटरी URL खोजें। आप इसे नीचे दिए गए कमांड में उपयोग करेंगे। ```https://github.com/username/repository_name.git``` को अपने GitHub URL से बदलें।
यह एक _रिमोट_ या कनेक्शन बनाता है, जिसका नाम "origin" है, जो पहले बनाए गए GitHub रिपॉजिटरी की ओर इशारा करता है।
यह एक _रिमोट_, या कनेक्शन, बनाता है जिसका नाम "origin" है और यह आपके द्वारा पहले बनाए गए GitHub रिपॉजिटरी की ओर इशारा करता है।
1. **स्थानीय फाइलों को GitHub पर भेजें**। अब तक आपने स्थानीय रिपो और GitHub रिपो के बीच एक _कनेक्शन_ बनाया है। आइए इन फाइलों को GitHub पर भेजें `git push` कमांड का उपयोग करके:
1. **स्थानीय फाइलें GitHub पर भेजें**। अब तक आपने स्थानीय रिपो और GitHub रिपो के बीच एक _कनेक्शन_ बनाया है। आइए इन फाइलों को GitHub पर निम्नलिखित कमांड `git push` का उपयोग करके भेजें:
> नोट: आपका ब्रांच नाम डिफ़ॉल्ट रूप से ```main``` से अलग हो सकता है।
> नोट, आपकी ब्रांच का नाम ```main``` से अलग हो सकता है।
```bash
git push -u origin main
```
यह आपके "main" ब्रांच में किए गए कमिट्स को GitHub पर भेजता है।
यह आपके "main" ब्रांच में आपके कमिट्स को GitHub पर भेजता है। कमांड में `-u` सहित `upstream` ब्रांच सेट करना आपके स्थानीय ब्रांच और रिमोट ब्रांच के बीच एक लिंक स्थापित करता है, ताकि आप भविष्य में ब्रांच का नाम निर्दिष्ट किए बिना केवल git push या git pull का उपयोग कर सकें। Git स्वचालित रूप से upstream ब्रांच का उपयोग करेगा और आपको भविष्य के कमांड में ब्रांच का नाम स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं होगी।
2. **अधिक बदलाव जोड़ने के लिए**। यदि आप बदलाव करना जारी रखना चाहते हैं और उन्हें GitHub पर पुश करना चाहते हैं, तो आपको केवल निम्नलिखित तीन कमांड का उपयोग करना होगा:
@ -164,63 +165,63 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> टिप: आप `.gitignore` फाइल को अपनाना चाह सकते हैं ताकि उन फाइलों को GitHub पर दिखने से रोका जा सके जिन्हें आप ट्रैक नहीं करना चाहते - जैसे कि वह नोट्स फाइल जिसे आप उसी फ़ोल्डर में स्टोर करते हैं लेकिन जिसका सार्वजनिक रिपॉजिटरी में कोई स्थान नहीं है। आप `.gitignore` फाइलों के टेम्पलेट्स [यहां](https://github.com/github/gitignore) पा सकते हैं।
> टिप, आप `.gitignore` फाइल अपनाना चाह सकते हैं ताकि वे फाइलें जिन्हें आप ट्रैक नहीं करना चाहते, GitHub पर दिखाई न दें - जैसे कि वह नोट्स फाइल जिसे आप उसी फ़ोल्डर में स्टोर करते हैं लेकिन सार्वजनिक रिपॉजिटरी में उसकी कोई जगह नहीं है। आप `.gitignore` फाइलों के टेम्पलेट्स [.gitignore templates](https://github.com/github/gitignore) पर पा सकते हैं।
#### कमिट संदेश
एक शानदार Git कमिट सब्जेक्ट लाइन निम्नलिखित वाक्य को पूरा करती है:
यदि लागू किया गया, तो यह कमिट <आपकी सब्जेक्ट लाइन यहां> करेगा।
एक शानदार Git कमिट विषय पंक्ति निम्नलिखित वाक्य को पूरा करती है:
यदि लागू किया गया, तो यह कमिट <आपकी विषय पंक्ति यहां>
सब्जेक्ट के लिए, वर्तमान काल और आदेशात्मक स्वर का उपयोग करें: "बदलें" न कि "बदला" या "बदलता है"।
जैसे कि सब्जेक्ट में, बॉडी (वैकल्पिक) में भी वर्तमान काल और आदेशात्मक स्वर का उपयोग करें। बॉडी में बदलाव के लिए प्रेरणा और इसे पिछले व्यवहार से कैसे अलग करता है, यह शामिल होना चाहिए। आप `क्यों` समझा रहे हैं, न कि `कैसे`।
विषय के लिए वर्तमान काल का उपयोग करें: "change" न कि "changed" या "changes"।
जैसे विषय में, शरीर (वैकल्पिक) में भी वर्तमान काल का उपयोग करें। शरीर में बदलाव के लिए प्रेरणा शामिल होनी चाहिए और इसे पिछले व्यवहार के साथ तुलना करनी चाहिए। आप `क्यों` समझा रहे हैं, न कि `कैसे`।
✅ GitHub पर कुछ समय बिताएं। क्या आप एक शानदार कमिट संदेश ढूंढ सकते हैं? क्या आप एक बहुत ही न्यूनतम संदेश ढूंढ सकते हैं? आपके अनुसार कमिट संदेश में कौन सी जानकारी सबसे महत्वपूर्ण और उपयोगी है?
✅ GitHub पर कुछ समय बिताएं। क्या आप एक वास्तव में शानदार कमिट संदेश ढूंढ सकते हैं? क्या आप एक बहुत ही न्यूनतम संदेश ढूंढ सकते हैं? आपके विचार में कमिट संदेश में कौन सी जानकारी सबसे महत्वपूर्ण और उपयोगी है?
### कार्य: सहयोग करें
GitHub पर चीजें डालने का मुख्य कारण अन्य डेवलपर्स के साथ सहयोग करना संभव बनाना था।
## दूसरों के साथ प्रोजेक्ट्स पर काम करना
## अन्य लोगों के साथ प्रोजेक्ट पर काम करना
> वीडियो देखें
> वीडियो देखें
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
अपने रिपॉजिटरी में, `Insights > Community` पर नेविगेट करें यह देखने के लिए कि आपका प्रोजेक्ट अनुशंसित सामुदायिक मानकों की तुलना में कैसा है।
अपने रिपॉजिटरी में, `Insights > Community` पर जाएं यह देखने के लिए कि आपका प्रोजेक्ट अनुशंसित सामुदायिक मानकों की तुलना में कैसा है।
यहां कुछ चीजें हैं जो आपके GitHub रिपो को बेहतर बना सकती हैं:
- **विवरण**। क्या आपने अपने प्रोजेक्ट के लिए विवरण जोड़ा?
- **README**। क्या आपने README जोड़ा? GitHub [README लिखने](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) के लिए मार्गदर्शन प्रदान करता है।
- **विवरण**। क्या आपने अपने प्रोजेक्ट के लिए विवरण जोड़ा है?
- **README**। क्या आपने README जोड़ा है? GitHub [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 फाइलें, हालांकि उन्हें तैयार करने में समय लगता है, अक्सर व्यस्त मेंटेनर्स द्वारा उपेक्षित की जाती हैं। क्या आप एक विशेष रूप से वर्णनात्मक उदाहरण ढूंढ सकते हैं? नोट: कुछ [उपकरण](https://www.makeareadme.com/) हैं जो अच्छे README बनाने में मदद कर सकते हैं, जिन्हें आप आज़माना चाह सकते हैं।
✅ README फाइलें, हालांकि उन्हें तैयार करने में समय लगता है, अक्सर व्यस्त मेंटेनर्स द्वारा उपेक्षित की जाती हैं। क्या आप किसी विशेष रूप से वर्णनात्मक README का उदाहरण ढूंढ सकते हैं? नोट: कुछ [उपकरण अच्छे README बनाने में मदद करते हैं](https://www.makeareadme.com/) जिन्हें आप आज़माना चाह सकते हैं।
### कार्य: कुछ कोड मर्ज करें
योगदान दस्तावेज़ लोगों को प्रोजेक्ट में योगदान करने में मदद करते हैं। यह बताता है कि आप किस प्रकार के योगदान की तलाश कर रहे हैं और प्रक्रिया कैसे काम करती है। योगदानकर्ताओं को GitHub पर आपके रिपो में योगदान करने में सक्षम होने के लिए कई चरणों से गुजरना होगा:
योगदान दस्तावेज़ लोगों को प्रोजेक्ट में योगदान करने में मदद करते हैं। यह बताता है कि आप किस प्रकार के योगदान की तलाश कर रहे हैं और प्रक्रिया कैसे काम करती है। योगदानकर्ताओं को आपके GitHub रिपो में योगदान करने में सक्षम होने के लिए एक श्रृंखला चरणों से गुजरना होगा:
1. **आपके रिपो को फोर्क करना**। आप शायद चाहेंगे कि लोग आपके प्रोजेक्ट को _फोर्क_ करें। फोर्क करने का मतलब है कि आपकी रिपॉजिटरी की एक प्रतिकृति उनके GitHub प्रोफ़ाइल पर बनाना।
1. **आपके रिपो को फोर्क करना**। आप शायद चाहेंगे कि लोग आपके प्रोजेक्ट को _फोर्क_ करें। फोर्क करने का मतलब है कि आपकी रिपॉजिटरी की एक प्रतिकृति उनके GitHub प्रोफ़ाइल पर बनाई जाए।
1. **क्लोन**। वहां से वे प्रोजेक्ट को अपने स्थानीय मशीन पर क्लोन करेंगे।
1. **एक ब्रांच बनाएं**। आप चाहेंगे कि वे अपने काम के लिए एक _ब्रांच_ बनाएं।
1. **अपने बदलाव को एक क्षेत्र पर केंद्रित करें**। योगदानकर्ताओं से एक बार में एक चीज़ पर ध्यान केंद्रित करने के लिए कहें - इस तरह उनके काम को _मर्ज_ करने की संभावना अधिक होती है। कल्पना करें कि वे एक बग फिक्स लिखते हैं, एक नई सुविधा जोड़ते हैं, और कई परीक्षण अपडेट करते हैं - क्या होगा यदि आप 3 में से केवल 2 या 1 को लागू करना चाहते हैं या कर सकते हैं?
1. **अपना बदलाव एक क्षेत्र पर केंद्रित करें**। योगदानकर्ताओं से एक समय में एक चीज़ पर ध्यान केंद्रित करने के लिए कहें - इस तरह उनके काम को _मर्ज_ करने की संभावना अधिक होती है। कल्पना करें कि उन्होंने एक बग फिक्स लिखा, एक नई सुविधा जोड़ी, और कई परीक्षण अपडेट किए - क्या होगा अगर आप 3 में से केवल 2 या 1 बदलाव लागू करना चाहते हैं या कर सकते हैं?
✅ ऐसी स्थिति की कल्पना करें जहां ब्रांच विशेष रूप से अच्छा कोड लिखने और शिप करने के लिए महत्वपूर्ण हों। आप किन उपयोग मामलों के बारे में सोच सकते हैं?
✅ ऐसी स्थिति की कल्पना करें जहां ब्रांच अच्छे कोड लिखने और शिप करने में विशेष रूप से महत्वपूर्ण हों। आप किन उपयोग मामलों के बारे में सोच सकते हैं?
> नोट: दुनिया में वह बदलाव बनें जो आप देखना चाहते हैं, और अपने काम के लिए ब्रांच बनाएं। आपके द्वारा किए गए किसी भी कमिट उस ब्रांच पर किए जाएंगे जिस पर आप वर्तमान में "चेक आउट" हैं। `git status` का उपयोग करें यह देखने के लिए कि वह कौन सी ब्रांच है।
> नोट, वह बदलाव बनें जो आप दुनिया में देखना चाहते हैं, और अपने काम के लिए ब्रांच बनाएं। आपके द्वारा किए गए किसी भी कमिट उस ब्रांच पर किए जाएंगे जिस पर आप वर्तमान में "चेक आउट" हैं। `git status` का उपयोग करें यह देखने के लिए कि वह कौन सी ब्रांच है।
आइए एक योगदानकर्ता वर्कफ़्लो से गुजरें। मान लें कि योगदानकर्ता ने पहले ही रिपो को _फोर्क_ और _क्लोन_ कर लिया है, इसलिए उनके पास एक Git रिपो है जिस पर वे अपने स्थानीय मशीन पर काम कर सकते हैं:
आइए एक योगदानकर्ता वर्कफ़्लो से गुजरें। मान लें कि योगदानकर्ता ने पहले ही रिपो को _फोर्क_ और _क्लोन_ कर लिया है ताकि उनके पास एक Git रिपो हो जिस पर वे अपने स्थानीय मशीन पर काम कर सकें:
1. **एक ब्रांच बनाएं**। `git branch` कमांड का उपयोग करके एक ब्रांच बनाएं जिसमें वे बदलाव शामिल होंगे जिन्हें वे योगदान देना चाहते हैं:
1. **एक ब्रांच बनाएं**। `git branch` कमांड का उपयोग करें एक ब्रांच बनाने के लिए जिसमें वे बदलाव करेंगे:
```bash
git branch [branch-name]
```
1. **वर्किंग ब्रांच पर स्विच करें**। निर्दिष्ट ब्रांच पर स्विच करें और `git switch` का उपयोग करके वर्किंग डायरेक्टरी को अपडेट करें:
1. **कार्य ब्रांच पर स्विच करें**। निर्दिष्ट ब्रांच पर स्विच करें और `git switch` का उपयोग करके कार्य निर्देशिका को अपडेट करें:
```bash
git switch [branch-name]
@ -233,86 +234,91 @@ GitHub पर चीजें डालने का मुख्य कार
git commit -m "my changes"
```
सुनिश्चित करें कि आप अपने कमिट को एक अच्छा नाम दें, आपके लिए और उस रिपो के मेंटेनर के लिए भी जिसकी आप मदद कर रहे हैं।
सुनिश्चित करें कि आप अपने कमिट को एक अच्छा नाम दें, आपके लिए और उस रिपो के मेंटेनर के लिए जिस पर आप मदद कर रहे हैं।
1. **अपने काम को `main` ब्रांच के साथ मिलाएं**। किसी बिंदु पर आप काम पूरा कर लेते हैं और आप अपने काम को `main` ब्रांच के साथ मिलाना चाहते हैं। इस बीच `main` ब्रांच बदल सकती है, इसलिए सुनिश्चित करें कि आप पहले इसे निम्नलिखित कमांड के साथ नवीनतम में अपडेट करें:
1. **अपने काम को `main` ब्रांच के साथ मिलाएं**। किसी बिंदु पर आप काम पूरा कर लेते हैं और आप अपने काम को `main` ब्रांच के साथ मिलाना चाहते हैं। इस बीच `main` ब्रांच बदल सकती है इसलिए सुनिश्चित करें कि आप पहले इसे निम्नलिखित कमांड के साथ नवीनतम में अपडेट करें:
```bash
git switch main
git pull
```
इस बिंदु पर आप यह सुनिश्चित करना चाहते हैं कि कोई भी _संघर्ष_, ऐसी स्थितियां जहां Git आसानी से _मिलाने_ में असमर्थ है, आपके वर्किंग ब्रांच में होती हैं। इसलिए निम्नलिखित कमांड चलाएं:
इस बिंदु पर आप यह सुनिश्चित करना चाहते हैं कि कोई भी _संघर्ष_, ऐसी स्थिति जहां Git आसानी से _मिलाने_ में असमर्थ है, आपके कार्य ब्रांच में होता है। इसलिए निम्नलिखित कमांड चलाएं:
```bash
git switch [branch_name]
git merge main
```
यह `main` से सभी बदलावों को आपकी ब्रांच में लाएगा और उम्मीद है कि आप बस जारी रख सकते हैं। यदि नहीं, तो VS Code आपको बताएगा कि Git कहां _उलझन_ में है और आप प्रभावित फाइलों को बदल सकते हैं ताकि यह स्पष्ट हो सके कि कौन सी सामग्री सबसे सटीक है।
`git merge main` कमांड `main` से सभी बदलावों को आपकी ब्रांच में लाएगा। उम्मीद है कि आप बस जारी रख सकते हैं। यदि नहीं, तो VS Code आपको बताएगा कि Git _कंफ्यूज_ है और आप प्रभावित फाइलों को बदलकर यह बता सकते हैं कि कौन सी सामग्री सबसे सटीक है।
किसी अन्य ब्रांच पर स्विच करने के लिए, आधुनिक `git switch` कमांड का उपयोग करें:
```bash
git switch [branch_name]
1. **अपने काम को GitHub पर भेजें**। अपने काम को GitHub पर भेजने का मतलब दो चीजें हैं। अपनी ब्रांच को अपने रिपो पर पुश करना और फिर एक PR (Pull Request) खोलना।
1. **अपना काम GitHub पर भेजें**। अपना काम GitHub पर भेजने का मतलब दो चीजें हैं। अपनी ब्रांच को अपने रिपो पर पुश करना और फिर एक PR, Pull Request खोलना।
```bash
git push --set-upstream origin [branch-name]
```
उपरोक्त कमांड आपकी फोर्क की गई रिपो पर ब्रांच बनाता है।
1. **PR खोलें**। अगला, आप एक PR खोलना चाहते हैं। आप ऐसा GitHub पर फोर्क की गई रिपो पर नेविगेट करके करते हैं। आप GitHub पर एक संकेत देखेंगे जहां यह पूछता है कि क्या आप एक नया PR बनाना चाहते हैं, आप उस पर क्लिक करते हैं और आपको एक इंटरफ़ेस पर ले जाया जाता है जहां आप कमिट संदेश शीर्षक बदल सकते हैं, इसे एक अधिक उपयुक्त विवरण दे सकते हैं। अब आपने जिस रिपो को फोर्क किया है उसके मेंटेनर इस PR को देखेंगे और _उम्मीद है_ वे आपकी सराहना करेंगे और आपके PR को _मर्ज_ करेंगे। आप अब एक योगदानकर्ता हैं, बधाई हो :)
ऊपर दिया गया कमांड आपकी फोर्क की गई रिपो पर ब्रांच बनाता है।
1. **PR खोलें**। अगला कदम है PR खोलना। इसके लिए GitHub पर फोर्क किए गए रिपॉजिटरी पर जाएं। GitHub पर आपको एक संकेत मिलेगा जहां पूछा जाएगा कि क्या आप नया PR बनाना चाहते हैं। उस पर क्लिक करें और आप एक इंटरफ़ेस पर पहुंचेंगे जहां आप कमिट मैसेज का शीर्षक बदल सकते हैं और उसे एक उपयुक्त विवरण दे सकते हैं। अब जिस रिपॉजिटरी को आपने फोर्क किया है, उसका मेंटेनर इस PR को देखेगा और _उम्मीद है_ कि वे इसे सराहेंगे और _मर्ज_ करेंगे। अब आप एक योगदानकर्ता बन गए हैं, वाह! :)
1. **साफ-सफाई करें**। PR को सफलतापूर्वक मर्ज करने के बाद _साफ-सफाई_ करना अच्छा अभ्यास माना जाता है। आप अपनी स्थानीय ब्रांच और उस ब्रांच को साफ करना चाहते हैं जिसे आपने GitHub पर पुश किया था। पहले इसे निम्नलिखित कमांड के साथ स्थानीय रूप से हटा दें:
1. **सफाई करें**। यह अच्छा अभ्यास माना जाता है कि PR सफलतापूर्वक मर्ज होने के बाद आप _सफाई_ करें। आपको अपने लोकल ब्रांच और GitHub पर पुश किए गए ब्रांच दोनों को साफ करना चाहिए। पहले इसे लोकल से हटाने के लिए निम्नलिखित कमांड का उपयोग करें:
```bash
git branch -d [branch-name]
```
सुनिश्चित करें कि आप फोर्क की गई रिपो के GitHub पेज पर जाएं और उस रिमोट ब्रांच को हटा दें जिसे आपने अभी पुश किया था।
`Pull request` एक अजीब सा शब्द लगता है क्योंकि असल में आप अपनी बदलावों को प्रोजेक्ट में "पुश" करना चाहते हैं। लेकिन प्रोजेक्ट के मालिक (maintainer) या कोर टीम को आपके बदलावों पर विचार करना होता है, इससे पहले कि वे इसे प्रोजेक्ट की "main" ब्रांच में मर्ज करें। इसलिए आप वास्तव में एक बदलाव का निर्णय मांग रहे हैं।
इसके बाद GitHub पर फोर्क किए गए रिपॉजिटरी के पेज पर जाएं और उस रिमोट ब्रांच को हटा दें जिसे आपने अभी पुश किया है।
`Pull request` एक अजीब सा शब्द लगता है क्योंकि वास्तव में आप अपनी परियोजना में बदलाव पुश करना चाहते हैं। लेकिन मेंटेनर (परियोजना मालिक) या कोर टीम को आपके बदलावों पर विचार करना होता है, इससे पहले कि वे इसे परियोजना की "मुख्य" ब्रांच में मर्ज करें। इसलिए आप वास्तव में मेंटेनर से बदलाव का निर्णय मांग रहे हैं।
एक pull request वह जगह है जहां आप ब्रांच पर किए गए बदलावों की तुलना और चर्चा कर सकते हैं, जिसमें रिव्यू, टिप्पणियां, इंटीग्रेटेड टेस्ट और अन्य चीजें शामिल होती हैं। एक अच्छा pull request लगभग उन्हीं नियमों का पालन करता है जो एक commit message के लिए होते हैं। आप अपने काम को किसी issue से जोड़ सकते हैं, जैसे कि जब आपका काम किसी issue को ठीक करता है। इसे `#` के बाद issue नंबर लिखकर किया जाता है। उदाहरण के लिए`#97`।
Pull request वह स्थान है जहां आप ब्रांच पर किए गए बदलावों की तुलना और चर्चा कर सकते हैं, जिसमें रिव्यू, टिप्पणियां, इंटीग्रेटेड टेस्ट और अन्य चीजें शामिल हैं। एक अच्छा Pull request लगभग उन्हीं नियमों का पालन करता है जो एक कमिट मैसेज करता है। आप इश्यू ट्रैकर में किसी इश्यू का संदर्भ जोड़ सकते हैं, उदाहरण के लिए जब आपका काम किसी इश्यू को ठीक करता है। इसे `#` के बाद इश्यू नंबर का उपयोग करके किया जाता है। उदाहरण:`#97`।
🤞उम्मीद है कि सभी चेक पास हो जाएं और प्रोजेक्ट मालिक आपके बदलावों को प्रोजेक्ट में मर्ज कर दें🤞
🤞उम्मीद है कि सभी चेक पास हो जाएं और परियोजना मालिक आपके बदलावों को परियोजना में मर्ज कर दें🤞
अपने वर्तमान लोकल वर्किंग ब्रांच को GitHub पर संबंधित रिमोट ब्रांच से सभी नए commits के साथ अपडेट करें:
अपने वर्तमान लोकल वर्किंग ब्रांच को GitHub पर संबंधित रिमोट ब्रांच से सभी नए कमिट्स के साथ अपडेट करें:
`git pull`
## ओपन सोर्स में योगदान कैसे करें
सबसे पहले, GitHub पर एक ऐसा रिपॉजिटरी (या **repo**) खोजें जो आपके लिए रुचिकर हो और जिसमें आप बदलाव करना चाहते हों। आप इसकी सामग्री को अपनी मशीन पर कॉपी करना चाहेंगे।
पहले, GitHub पर एक रिपॉजिटरी (या **repo**) खोजें जो आपको रुचिकर लगे और जिसमें आप बदलाव करना चाहते हैं। आप इसकी सामग्री को अपनी मशीन पर कॉपी करना चाहेंगे।
✅ 'शुरुआती-अनुकूल' रिपॉजिटरी खोजने का एक अच्छा तरीका है [टैग 'good-first-issue' द्वारा सर्च करना](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)।
✅ 'शुरुआती-अनुकूल' रिपॉजिटरी खोजने का एक अच्छा तरीका है [टैग 'good-first-issue' द्वारा खोज करना](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)।
कोड कॉपी करने के कई तरीके हैं। एक तरीका है रिपॉजिटरी की सामग्री को "क्लोन" करना, HTTPS, SSH, या GitHub CLI (Command Line Interface) का उपयोग करके।
कोड कॉपी करने के कई तरीके हैं। एक तरीका है रिपॉजिटरी की सामग्री को "क्लोन" करना, HTTPS, SSH, या GitHub CLI (कमांड लाइन इंटरफ़ेस) का उपयोग करके।
अपना टर्मिनल खोलें और रिपॉजिटरी को इस तरह क्लोन करें:
`git clone https://github.com/ProjectURL`
प्रोजेक्ट पर काम करने के लिए सही फोल्डर पर स्विच करें:
परियोजना पर काम करने के लिए, सही फ़ोल्डर पर स्विच करें:
`cd ProjectURL`
आप पूरे प्रोजेक्ट को [Codespaces](https://github.com/features/codespaces), GitHub का एम्बेडेड कोड एडिटर / क्लाउड डेवलपमेंट एनवायरनमेंट, या [GitHub Desktop](https://desktop.github.com/) का उपयोग करके भी खोल सकते हैं।
अंत में, आप कोड को ज़िप फोल्डर में डाउनलोड कर सकते हैं।
अंत में, आप कोड को ज़िप फ़ोल्डर में डाउनलोड कर सकते हैं।
### GitHub के बारे में कुछ और रोचक बातें
आप GitHub पर किसी भी सार्वजनिक रिपॉजिटरी को स्टार, वॉच और/या "fork" कर सकते हैं। आप अपने स्टार किए गए रिपॉजिटरी को टॉप-राइट ड्रॉप-डाउन मेनू में देख सकते हैं। यह कोड के लिए बुकमार्किंग जैसा है।
आप GitHub पर किसी भी सार्वजनिक रिपॉजिटरी को स्टार, वॉच और/या "फोर्क" कर सकते हैं। आप अपने स्टार किए गए रिपॉजिटरी को टॉप-राइट ड्रॉप-डाउन मेनू में पा सकते हैं। यह कोड के लिए बुकमार्किंग जैसा है।
प्रोजेक्ट्स में एक issue tracker होता है, जो ज्यादातर GitHub पर "Issues" टैब में होता है जब तक कि अन्यथा न बताया जाए, जहां लोग प्रोजेक्ट से संबंधित मुद्दों पर चर्चा करते हैं। और Pull Requests टैब वह जगह है जहां लोग प्रगति में बदलावों पर चर्चा और समीक्षा करते हैं।
परियोजनाओं में एक इश्यू ट्रैकर होता है, ज्यादातर GitHub पर "Issues" टैब में जब तक अन्यथा संकेत न दिया गया हो, जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। और Pull Requests टैब वह जगह है जहां लोग प्रगति में बदलावों पर चर्चा और समीक्षा करते हैं।
प्रोजेक्ट्स में चर्चा के लिए फोरम, मेलिंग लिस्ट, या चैट चैनल जैसे Slack, Discord या IRC भी हो सकते हैं।
परियोजनाओं में चर्चा फोरम, मेलिंग लिस्ट, या चैट चैनल जैसे Slack, Discord या IRC में भी हो सकती है।
✅ अपने नए GitHub रिपॉजिटरी के चारों ओर देखें और कुछ चीजें आज़माएं, जैसे सेटिंग्स को एडिट करना, अपने रिपॉजिटरी में जानकारी जोड़ना, और एक प्रोजेक्ट बनाना (जैसे Kanban बोर्ड)। आप बहुत कुछ कर सकते हैं!
✅ अपने नए GitHub रिपॉजिटरी के चारों ओर एक नज़र डालें और कुछ चीजें आज़माएं, जैसे सेटिंग्स संपादित करना, अपने रिपॉजिटरी में जानकारी जोड़ना, और एक प्रोजेक्ट बनाना (जैसे कि Kanban बोर्ड)। आप बहुत कुछ कर सकते हैं!
---
## 🚀 चुनौती
एक दोस्त के साथ मिलकर एक-दूसरे के कोड पर काम करें। एक प्रोजेक्ट को सहयोगात्मक रूप से बनाएं, कोड को fork करें, ब्रांच बनाएं, और बदलावों को मर्ज करें।
एक दोस्त के साथ मिलकर एक-दूसरे के कोड पर काम करें। एक प्रोजेक्ट को सहयोगात्मक रूप से बनाएं, कोड फोर्क करें, ब्रांच बनाएं, और बदलाव मर्ज करें।
अभ्यास करें, अभ्यास करें, अभ्यास करें। GitHub के पास [skills.github.com](https://skills.github.com) पर उपलब्ध शानदार लर्निंग पाथ हैं:
अभ्यास करें, अभ्यास करें, अभ्यास करें। GitHub के पास [skills.github.com](https://skills.github.com) के माध्यम से शानदार लर्निंग पाथ उपलब्ध हैं:
- [GitHub पर पहला सप्ताह](https://skills.github.com/#first-week-on-github)
आपको अधिक उन्नत पाठ्यक्रम भी मिलेंगे।
आपको अधिक उन्नत पाठ्यक्रम भी मिलेंगे।
## असाइनमेंट
[GitHub पर पहला सप्ताह का कोर्स](https://skills.github.com/#first-week-on-github) पूरा करें।
[GitHub पर पहला सप्ताह पाठ्यक्रम](https://skills.github.com/#first-week-on-github) पूरा करें।
---
**अस्वीकरण**:
यह दस्तावेज़ AI अनुवाद सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) का उपयोग करके अनुवादित किया गया है। जबकि हम सटीकता सुनिश्चित करने का प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवाद में त्रुटियां या अशुद्धियां हो सकती हैं। मूल भाषा में उपलब्ध मूल दस्तावेज़ को प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम जिम्मेदार नहीं हैं।
यह दस्तावेज़ AI अनुवाद सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) का उपयोग करके अनुवादित किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवाद में त्रुटियां या अशुद्धियां हो सकती हैं। मूल भाषा में उपलब्ध मूल दस्तावेज़ को आधिकारिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं।
> Sketchnote autor [Tomomi Imura](https://twitter.com/girlie_mac)
## Kviz prije predavanja
[Kviz prije predavanja](https://ff-quizzes.netlify.app)
@ -23,11 +23,11 @@ U ovoj lekciji obradit ćemo:
- praćenje rada na vašem računalu
- rad na projektima s drugima
- kako doprinositi open source softveru
- kako doprinijeti softveru otvorenog koda
### Preduvjeti
Prije nego što počnete, provjerite je li Git instaliran. U terminal upišite:
Prije nego što počnete, provjerite je li Git instaliran. U terminalu upišite:
`git --version`
Ako Git nije instaliran, [preuzmite Git](https://git-scm.com/downloads). Zatim postavite svoj lokalni Git profil u terminalu:
@ -37,34 +37,34 @@ Ako Git nije instaliran, [preuzmite Git](https://git-scm.com/downloads). Zatim p
Da biste provjerili je li Git već konfiguriran, možete upisati:
`git config --list`
Također će vam trebati GitHub račun, uređivač koda (poput Visual Studio Code-a) i otvoren terminal (ili: command prompt).
Također će vam trebati GitHub račun, uređivač koda (poput Visual Studio Code), i trebate otvoriti svoj terminal (ili: command prompt).
Idite na [github.com](https://github.com/) i kreirajte račun ako već nemate, ili se prijavite i popunite svoj profil.
Posjetite [github.com](https://github.com/) i kreirajte račun ako ga već nemate, ili se prijavite i popunite svoj profil.
✅ GitHub nije jedini repozitorij za kod na svijetu; postoje i drugi, ali GitHub je najpoznatiji.
✅ GitHub nije jedini repozitorij koda na svijetu; postoje i drugi, ali GitHub je najpoznatiji.
### Priprema
Trebat će vam mapa s projektom koda na vašem lokalnom računalu (laptop ili PC) i javni repozitorij na GitHubu, koji će poslužiti kao primjer kako doprinositi projektima drugih.
Trebat će vam mapa s projektom koda na vašem lokalnom računalu (laptop ili PC) i javni repozitorij na GitHubu, koji će poslužiti kao primjer kako doprinijeti projektima drugih.
---
## Upravljanje kodom
Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti svoj napredak koristeći git - sustav za kontrolu verzija. Neki ljudi uspoređuju korištenje gita s pisanjem ljubavnog pisma svom budućem ja. Čitajući svoje poruke o commitima danima, tjednima ili mjesecima kasnije, moći ćete se prisjetiti zašto ste donijeli neku odluku ili "vratiti" promjenu - pod uvjetom da pišete dobre "commit poruke".
Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti svoj napredak koristeći git - sustav za kontrolu verzija. Neki ljudi uspoređuju korištenje gita s pisanjem ljubavnog pisma svom budućem ja. Čitajući poruke o commitima danima, tjednima ili mjesecima kasnije, moći ćete se prisjetiti zašto ste donijeli određenu odluku ili "vratiti" promjenu - naravno, ako pišete dobre poruke o commitima.
### Zadatak: Napravite repozitorij i commitajte kod
> Pogledajte video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Kreirajte repozitorij na GitHubu**. Na GitHub.com, u kartici repozitorija ili iz navigacijske trake u gornjem desnom kutu, pronađite gumb **new repo**.
1. **Kreirajte repozitorij na GitHubu**. Na GitHub.com, u kartici repozitorija ili iz navigacijske trake gore desno, pronađite gumb **new repo**.
1. Dajte svom repozitoriju (mapi) ime.
1. Dajte svom repozitoriju (mapi) ime
1. Odaberite **create repository**.
1. **Navigirajte do svoje radne mape**. U terminalu se prebacite na mapu (poznatu i kao direktorij) koju želite početi pratiti. Upišite:
1. **Navigirajte do svoje radne mape**. U terminalu, prebacite se na mapu (poznatu i kao direktorij) koju želite početi pratiti. Upišite:
```bash
cd [name of your folder]
@ -82,7 +82,7 @@ Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti sv
git status
```
Izlaz može izgledati otprilike ovako:
izlaz može izgledati ovako:
```output
Changes not staged for commit:
@ -93,52 +93,52 @@ Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti sv
modified: file2.txt
```
Obično naredba `git status` govori stvari poput toga koji su fajlovi spremni za _spremanje_ u repozitorij ili imaju promjene koje biste možda željeli zabilježiti.
Obično naredba `git status` govori stvari poput toga koji su datoteke spremne za _spremanje_ u repozitorij ili imaju promjene koje biste možda željeli zadržati.
1. **Dodajte sve fajlove za praćenje**
Ovo se također naziva stavljanje fajlova u staging područje.
1. **Dodajte sve datoteke za praćenje**
Ovo se također naziva postavljanje datoteka/dodavanje datoteka u staging područje.
```bash
git add .
```
Argument `git add` plus `.` označava da su svi vaši fajlovi i promjene spremni za praćenje.
Argument `git add` plus `.` označava da su sve vaše datoteke i promjene spremne za praćenje.
1. **Dodajte odabrane fajlove za praćenje**
1. **Dodajte odabrane datoteke za praćenje**
```bash
git add [file or folder name]
```
Ovo nam pomaže dodati samo odabrane fajlove u staging područje kada ne želimo commitati sve fajlove odjednom.
Ovo nam pomaže dodati samo odabrane datoteke u staging područje kada ne želimo commitati sve datoteke odjednom.
1. **Uklonite sve fajlove iz staging područja**
1. **Uklonite sve datoteke iz staging područja**
```bash
git reset
```
Ova naredba pomaže ukloniti sve fajlove iz staging područja odjednom.
Ova naredba pomaže ukloniti sve datoteke iz staging područja odjednom.
1. **Uklonite određeni fajl iz staging područja**
1. **Uklonite određenu datoteku iz staging područja**
```bash
git reset [file or folder name]
```
Ova naredba pomaže ukloniti samo određeni fajl iz staging područja koji ne želimo uključiti u sljedeći commit.
Ova naredba pomaže ukloniti samo određenu datoteku iz staging područja koju ne želimo uključiti u sljedeći commit.
1. **Spremanje vašeg rada**. U ovom trenutku ste dodali fajlove u tzv. _staging područje_. Mjesto gdje Git prati vaše fajlove. Da biste promjenu učinili trajnom, trebate _commitati_ fajlove. Da biste to učinili, kreirate _commit_ pomoću naredbe `git commit`. Commit predstavlja točku spremanja u povijesti vašeg repozitorija. Upišite sljedeće za kreiranje commita:
1. **Spremanje vašeg rada**. U ovom trenutku ste dodali datoteke u tzv. _staging područje_. Mjesto gdje Git prati vaše datoteke. Da biste promjenu učinili trajnom, trebate _commitati_ datoteke. Da biste to učinili, kreirate _commit_ s naredbom `git commit`. _Commit_ predstavlja točku spremanja u povijesti vašeg repozitorija. Upišite sljedeće da biste kreirali _commit_:
```bash
git commit -m "first commit"
```
Ovo commitira sve vaše fajlove, dodajući poruku "first commit". Za buduće commit poruke, želite biti detaljniji kako biste opisali kakvu ste promjenu napravili.
Ovo commitira sve vaše datoteke, dodajući poruku "first commit". Za buduće poruke o commitima, želite biti opisniji u svom opisu kako biste prenijeli kakvu ste promjenu napravili.
1. **Povežite svoj lokalni Git repozitorij s GitHubom**. Git repozitorij je koristan na vašem računalu, ali u nekom trenutku želite imati sigurnosnu kopiju svojih fajlova negdje i također pozvati druge ljude da rade s vama na vašem repozitoriju. Jedno od sjajnih mjesta za to je GitHub. Sjetite se da smo već kreirali repozitorij na GitHubu, tako da jedino što trebamo učiniti je povezati naš lokalni Git repozitorij s GitHubom. Naredba `git remote add` će to učiniti. Upišite sljedeću naredbu:
1. **Povežite svoj lokalni Git repozitorij s GitHubom**. Git repozitorij je koristan na vašem računalu, ali u nekom trenutku želite imati sigurnosnu kopiju svojih datoteka negdje i također pozvati druge ljude da rade s vama na vašem repozitoriju. Jedno takvo sjajno mjesto za to je GitHub. Sjetite se da smo već kreirali repozitorij na GitHubu, tako da jedino što trebamo učiniti je povezati naš lokalni Git repozitorij s GitHubom. Naredba `git remote add` će to učiniti. Upišite sljedeću naredbu:
> Napomena: Prije nego što upišete naredbu, idite na stranicu svog GitHub repozitorija kako biste pronašli URL repozitorija. Koristit ćete ga u naredbi ispod. Zamijenite ```https://github.com/username/repository_name.git``` s vašim GitHub URL-om.
> Napomena, prije nego što upišete naredbu, idite na stranicu svog GitHub repozitorija da biste pronašli URL repozitorija. Koristit ćete ga u naredbi ispod. Zamijenite ```https://github.com/username/repository_name.git``` s vašim GitHub URL-om.
@ -146,17 +146,17 @@ Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti sv
Ovo kreira _remote_, ili vezu, nazvanu "origin" koja pokazuje na GitHub repozitorij koji ste ranije kreirali.
1. **Pošaljite lokalne fajlove na GitHub**. Do sada ste kreirali _vezu_ između lokalnog repozitorija i GitHub repozitorija. Pošaljimo ove fajlove na GitHub pomoću naredbe`git push`, ovako:
1. **Pošaljite lokalne datoteke na GitHub**. Do sada ste kreirali _vezu_ između lokalnog repozitorija i GitHub repozitorija. Pošaljimo ove datoteke na GitHub sljedećom naredbom`git push`, ovako:
> Napomena: Vaša grana može imati drugačije ime od ```main```.
> Napomena, naziv vaše grane može biti drugačiji od ```main```.
```bash
git push -u origin main
```
Ovo šalje vaše commitove u vašu "main" granu na GitHub.
Ovo šalje vaše commitove u vašu "main" granu na GitHub. Postavljanje `upstream` grane uključujući `-u` u naredbi uspostavlja vezu između vaše lokalne grane i udaljene grane, tako da ubuduće možete jednostavno koristiti git push ili git pull bez navođenja naziva grane. Git će automatski koristiti upstream granu i nećete morati eksplicitno navoditi naziv grane u budućim naredbama.
2. **Dodavanje dodatnih promjena**. Ako želite nastaviti s promjenama i slati ih na GitHub, samo trebate koristiti sljedeće tri naredbe:
2. **Dodavanje više promjena**. Ako želite nastaviti s promjenama i slati ih na GitHub, samo ćete trebati koristiti sljedeće tri naredbe:
```bash
git add .
@ -164,17 +164,17 @@ Recimo da imate mapu lokalno s nekim projektom koda i želite početi pratiti sv
git push
```
> Savjet: Možda ćete također htjeti usvojiti `.gitignore` fajl kako biste spriječili da se fajlovi koje ne želite pratiti pojavljuju na GitHubu - poput bilješki koje spremate u istoj mapi, ali nemaju mjesto u javnom repozitoriju. Možete pronaći predloške za `.gitignore` fajlove na [.gitignore templates](https://github.com/github/gitignore).
> Savjet, Možda ćete također htjeti usvojiti `.gitignore` datoteku kako biste spriječili da se datoteke koje ne želite pratiti pojavljuju na GitHubu - poput one datoteke s bilješkama koju pohranjujete u istoj mapi, ali nema mjesta u javnom repozitoriju. Možete pronaći predloške za `.gitignore` datoteke na [.gitignore templates](https://github.com/github/gitignore).
#### Poruke commita
#### Poruke o commitima
Odličan naslov Git commita završava sljedeću rečenicu:
Ako se primijeni, ovaj commit će <vašnaslovovdje>
Odličan naslov poruke o Git commitu završava sljedeću rečenicu:
Ako se primijeni, ovaj commit će <ovdje vašnaslov>
Za naslov koristite imperativ, sadašnje vrijeme: "promijeni" umjesto "promijenio" ili "mijenja".
Kao i u naslovu, u tijelu (opcionalno) također koristite imperativ, sadašnje vrijeme. Tijelo bi trebalo uključivati motivaciju za promjenu i usporedbu s prethodnim ponašanjem. Objašnjavate `zašto`, a ne `kako`.
Za naslov koristite imperativ, sadašnje vrijeme: "promijeni" ne "promijenio" niti "mijenja".
Kao i u naslovu, u tijelu (opcionalno) također koristite imperativ, sadašnje vrijeme. Tijelo bi trebalo uključivati motivaciju za promjenu i usporediti je s prethodnim ponašanjem. Objašnjavate `zašto`, ne `kako`.
✅ Odvojite nekoliko minuta za istraživanje GitHuba. Možete li pronaći zaista dobru poruku commita? Možete li pronaći vrlo minimalnu? Koje informacije smatrate najvažnijima i najkorisnijima za prenošenje u poruci commita?
✅ Odvojite nekoliko minuta da pregledate GitHub. Možete li pronaći zaista odličnu poruku o commitu? Možete li pronaći zaista minimalnu? Koje informacije mislite da su najvažnije i najkorisnije za prenijeti u poruci o commitu?
### Zadatak: Suradnja
@ -184,156 +184,160 @@ Glavni razlog za postavljanje stvari na GitHub bio je omogućiti suradnju s drug
> Pogledajte video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
U svom repozitoriju, idite na `Insights > Community` kako biste vidjeli kako se vaš projekt uspoređuje s preporučenim standardima zajednice.
U svom repozitoriju, navigirajte do `Insights > Community` da biste vidjeli kako vaš projekt uspoređuje s preporučenim standardima zajednice.
Evo nekoliko stvari koje mogu poboljšati vaš GitHub repozitorij:
- **Opis**. Jeste li dodali opis za svoj projekt?
- **README**. Jeste li dodali README? GitHub pruža smjernice za pisanje [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Smjernice za doprinos**. Ima li vaš projekt [smjernice za doprinos](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kodeks ponašanja**. Ima li vaš projekt [Kodeks ponašanja](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licenca**. Možda najvažnije, ima li vaš projekt [licencu](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Smjernice za doprinos**. Ima li vaš projekt [smjernice za doprinos](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon),
- **Licenca**. Možda najvažnije, [licenca](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Svi ovi resursi koristit će za onboardanje novih članova tima. To su obično stvari koje novi suradnici prvo pogledaju prije nego što uopće pogledaju vaš kod, kako bi saznali je li vaš projekt pravo mjesto za njihovo ulaganje vremena.
Svi ovi resursi će koristiti novim članovima tima. A to su obično stvari koje novi suradnici pregledavaju prije nego što uopće pogledaju vaš kod, kako bi saznali je li vaš projekt pravo mjesto za njih da troše svoje vrijeme.
✅ README fajlovi, iako zahtijevaju vrijeme za pripremu, često su zanemareni od strane zauzetih održavatelja. Možete li pronaći primjer posebno opisnog README-a? Napomena: postoje neki [alati za pomoć pri kreiranju dobrih README-a](https://www.makeareadme.com/) koje biste mogli isprobati.
✅ README datoteke, iako zahtijevaju vrijeme za pripremu, često se zanemaruju od strane zauzetih održavatelja. Možete li pronaći primjer posebno opisnog README-a? Napomena: postoje neki [alati za pomoć pri izradi dobrih README-a](https://www.makeareadme.com/) koje biste mogli isprobati.
### Zadatak: Spojite kod
Dokumentacija za doprinos pomaže ljudima da doprinesu projektu. Objašnjava koje vrste doprinosa tražite i kako proces funkcionira. Suradnici će morati proći kroz niz koraka kako bi mogli doprinositi vašem repozitoriju na GitHubu:
Dokumenti o doprinosima pomažu ljudima da doprinesu projektu. Objašnjavaju koje vrste doprinosa tražite i kako proces funkcionira. Suradnici će morati proći kroz niz koraka kako bi mogli doprinijeti vašem repozitoriju na GitHubu:
1. **Forkanje vašeg repozitorija**. Vjerojatno ćete htjeti da ljudi _forkaju_ vaš projekt. Forkanje znači kreiranje replike vašeg repozitorija na njihovom GitHub profilu.
1. **Kloniranje**. Nakon toga će klonirati projekt na svoje lokalno računalo.
1. **Kreiranje grane**. Zamolit ćete ih da kreiraju _granu_ za svoj rad.
1. **Fokusiranje promjena na jedno područje**. Zamolite suradnike da se koncentriraju na jednu stvar odjednom - na taj način su veće šanse da možete _spojiti_ njihov rad. Zamislite da napišu ispravak greške, dodaju novu značajku i ažuriraju nekoliko testova - što ako želite ili možete implementirati samo 2 od 3, ili 1 od 3 promjene?
1. **Forkanje vašeg repozitorija**. Vjerojatno ćete htjeti da ljudi _forkaju_ vaš projekt. Forkanje znači stvaranje replike vašeg repozitorija na njihovom GitHub profilu.
1. **Kloniranje**. Odatle će klonirati projekt na svoje lokalno računalo.
1. **Kreiranje grane**. Želite ih zamoliti da kreiraju _granu_ za svoj rad.
1. **Usmjeravanje promjena na jedno područje**. Zamolite suradnike da se koncentriraju na jednu stvar odjednom - na taj način su šanse da možete _spojiti_ njihov rad veće. Zamislite da napišu ispravak greške, dodaju novu funkciju i ažuriraju nekoliko testova - što ako želite, ili možete implementirati samo 2 od 3, ili 1 od 3 promjene?
✅ Zamislite situaciju u kojoj su grane posebno ključne za pisanje i isporuku dobrog koda. Koje slučajeve upotrebe možete zamisliti?
✅ Zamislite situaciju gdje su grane posebno kritične za pisanje i isporuku dobrog koda. Koje slučajeve upotrebe možete zamisliti?
> Napomena: Budite promjena koju želite vidjeti u svijetu i kreirajte grane za svoj rad također. Svi commitovi koje napravite bit će napravljeni na grani na kojoj ste trenutno "prijavljeni". Koristite `git status` da vidite na kojoj ste grani.
> Napomena, budite promjena koju želite vidjeti u svijetu i kreirajte grane za svoj vlastiti rad također. Svaki commit koji napravite bit će napravljen na grani na kojoj ste trenutno "checked out". Koristite `git status` da vidite na kojoj ste grani.
Prođimo kroz tijek rada suradnika. Pretpostavimo da je suradnik već _forkao_ i _klonirao_ repozitorij tako da ima Git repozitorij spreman za rad na svom lokalnom računalu:
1. **Kreiranje grane**. Koristite naredbu `git branch` za kreiranje grane koja će sadržavati promjene koje žele doprinijeti:
1. **Kreiranje grane**. Koristite naredbu `git branch` za kreiranje grane koja će sadržavati promjene koje namjeravaju doprinijeti:
```bash
git branch [branch-name]
```
1. **Prebacivanje na radnu granu**. Prebacite se na određenu granu i ažurirajte radni direktorij pomoću`git switch`:
1. **Prebacivanje na radnu granu**. Prebacite se na određenu granu i ažurirajte radni direktorij s`git switch`:
```bash
git switch [branch-name]
```
1. **Radite na promjenama**. U ovom trenutku želite dodati svoje promjene. Ne zaboravite obavijestiti Git o tome pomoću sljedećih naredbi:
1. **Radite na promjenama**. U ovom trenutku želite dodati svoje promjene. Ne zaboravite reći Gitu o tome sljedećim naredbama:
```bash
git add .
git commit -m "my changes"
```
Osigurajte da svom commitu date dobro ime, za vaše dobro kao i za održavatelja repozitorija kojem pomažete.
Pobrinite se da svom commitu date dobro ime, za vaše dobro kao i za održavatelja repozitorija kojem pomažete.
1. **Spojite svoj rad s `main` granom**. U nekom trenutku završavate s radom i želite spojiti svoj rad s onim na `main` grani. `Main` grana se možda promijenila u međuvremenu, pa se prvo pobrinite da je ažurirate na najnoviju verziju pomoću sljedećih naredbi:
1. **Spojite svoj rad s `main` granom**. U nekom trenutku završavate s radom i želite spojiti svoj rad s onim iz `main` grane. `Main` grana se možda promijenila u međuvremenu, pa se pobrinite da je prvo ažurirate na najnoviju verziju sljedećim naredbama:
```bash
git switch main
git pull
```
U ovom trenutku želite osigurati da se svi _sukobi_, situacije u kojima Git ne može lako _spojiti_ promjene, dogode u vašoj radnoj grani. Stoga pokrenite sljedeće naredbe:
U ovom trenutku želite biti sigurni da se svi _sukobi_, situacije u kojima Git ne može lako _spojiti_ promjene, događaju u vašoj radnoj grani. Stoga pokrenite sljedeće naredbe:
```bash
git switch [branch_name]
git merge main
```
Ovo će donijeti sve promjene iz `main` grane u vašu granu i, nadamo se, možete samo nastaviti. Ako ne, VS Code će vam pokazati gdje je Git _zbunjen_ i samo izmijenite zahvaćene fajlove kako biste rekli koji je sadržaj najtočniji.
Naredba `git merge main` će donijeti sve promjene iz `main` u vašu granu. Nadamo se da možete jednostavno nastaviti. Ako ne, VS Code će vam pokazati gdje je Git _zbunjen_ i samo izmijenite zahvaćene datoteke kako biste odredili koji je sadržaj najtočniji.
1. **Pošaljite svoj rad na GitHub**. Slanje vašeg rada na GitHub znači dvije stvari. Pushing vaše grane na vaš repozitorij i zatim otvaranje PR-a, Pull Requesta.
Za prebacivanje na drugu granu, koristite modernu naredbu `git switch`:
```bash
git switch [branch_name]
1. **Pošaljite svoj rad na GitHub**. Slanje vašeg rada na GitHub znači dvije stvari. Guranje vaše grane na vaš repozitorij i zatim otvaranje PR-a, Pull Requesta.
```bash
git push --set-upstream origin [branch-name]
```
Gornja naredba kreira granu na vašem forkiranom repozitoriju.
1. **Otvorite PR**. Zatim želite otvoriti PR. To radite tako da odete na forkirani repozitorij na GitHubu. Vidjet ćete indikaciju na GitHubu gdje vas pita želite li kreirati novi PR, kliknite na to i bit ćete preusmjereni na sučelje gdje možete promijeniti naslov commit poruke, dati joj prikladniji opis. Sada će održavatelj repozitorija koji ste forkali vidjeti ovaj PR i _držimo fige_ da će ga cijeniti i _spojiti_ vaš PR. Sada ste suradnik, bravo :)
Gornja naredba kreira granu na vašem forkanom repozitoriju.
1. **Otvorite PR**. Sljedeći korak je otvaranje PR-a. To radite tako da odete na forkani repo na GitHubu. Vidjet ćete naznaku na GitHubu gdje vas pita želite li stvoriti novi PR, kliknete na to i bit ćete preusmjereni na sučelje gdje možete promijeniti naslov poruke commita i dodati prikladniji opis. Sada će održavatelj repozitorija koji ste forkali vidjeti ovaj PR i _držimo palčeve_ da će ga cijeniti i _spojiti_ vaš PR. Sada ste suradnik, bravo! :)
1. **Očistite za sobom**. Smatra se dobrom praksom _očistiti_ nakon što uspješno spojite PR. Želite očistiti i svoju lokalnu granu i granu koju ste poslali na GitHub. Prvo je izbrišite lokalno pomoću sljedeće naredbe:
1. **Čišćenje**. Smatra se dobrom praksom _očistiti_ nakon što uspješno spojite PR. Trebate očistiti i lokalnu granu i granu koju ste poslali na GitHub. Prvo je izbrišite lokalno pomoću sljedeće naredbe:
```bash
git branch -d [branch-name]
```
Zatim idite na GitHub stranicu forkiranog repozitorija i uklonite udaljenu granu koju ste upravo poslali.
Osigurajte da odete na GitHub stranicu forkiranog repozitorija i uklonite udaljenu granu koju ste upravo poslali.
`Pull request` možda zvuči kao čudan izraz jer zapravo želite "gurnuti" svoje promjene u projekt. No, održavatelj (vlasnik projekta) ili glavni tim treba razmotriti vaše promjene prije nego ih spoji s "glavnom" granom projekta, pa zapravo tražite odluku o promjeni od održavatelja.
`Pull request` može zvučati kao čudan izraz jer zapravo želite "gurnuti" svoje promjene u projekt. No, održavatelj (vlasnik projekta) ili glavni tim mora razmotriti vaše promjene prije nego što ih spoji s "main" granom projekta, pa zapravo tražite odluku o promjeni od održavatelja.
Pull request je mjesto gdje možete usporediti i raspraviti razlike uvedene na grani uz recenzije, komentare, integrirane testove i još mnogo toga. Dobar pull request slijedi otprilike ista pravila kao i poruka commita. Možete dodati referencu na problem u trackeru problema, na primjer kada vaš rad rješava neki problem. To se radi pomoću `#` praćenog brojem problema. Na primjer, `#97`.
Pull request je mjesto gdje možete usporediti i raspraviti razlike uvedene na grani uz recenzije, komentare, integrirane testove i još mnogo toga. Dobar pull request slijedi otprilike ista pravila kao i poruka commita. Možete dodati referencu na problem u trackeru problema, na primjer kada vaš rad rješava neki problem. To se radi pomoću `#` praćenog brojem vašeg problema. Na primjer, `#97`.
🤞Držimo fige da svi provjeri prođu i da vlasnik(i) projekta spoje vaše promjene u projekt🤞
🤞Držimo palčeve da svi provjeri prođu i da vlasnik(i) projekta spoje vaše promjene u projekt🤞
Ažurirajte svoju trenutnu lokalnu radnu granu sa svim novim commitovima iz odgovarajuće udaljene grane na GitHubu:
`git pull`
## Kako doprinijeti open source projektima
## Kako doprinijeti otvorenom kodu
Prvo, pronađimo repozitorij (ili **repo**) na GitHubu koji vas zanima i kojem želite doprinijeti promjenom. Trebat ćete kopirati njegov sadržaj na svoje računalo.
Prvo, pronađimo repozitorij (ili **repo**) na GitHubu koji vas zanima i kojem želite doprinijeti promjenom. Želite kopirati njegov sadržaj na svoje računalo.
✅ Dobar način za pronalazak repozitorija prilagođenih početnicima je [pretraživanje prema oznaci 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Dobar način za pronalaženje repozitorija prilagođenih početnicima je [pretraživanje po oznaci 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Postoji nekoliko načina za kopiranje koda. Jedan od načina je "kloniranje" sadržaja repozitorija pomoću HTTPS-a, SSH-a ili GitHub CLI-a (Command Line Interface).
Postoji nekoliko načina za kopiranje koda. Jedan od načina je "kloniranje" sadržaja repozitorija, koristeći HTTPS, SSH ili GitHub CLI (Command Line Interface).
Otvorite svoj terminal i klonirajte repozitorij ovako:
Otvorite terminal i klonirajte repozitorij ovako:
`git clone https://github.com/ProjectURL`
Za rad na projektu, prebacite se u odgovarajuću mapu:
Za rad na projektu, prebacite se u odgovarajući folder:
`cd ProjectURL`
Također možete otvoriti cijeli projekt koristeći [Codespaces](https://github.com/features/codespaces), GitHub-ov ugrađeni uređivač koda / razvojno okruženje u oblaku, ili [GitHub Desktop](https://desktop.github.com/).
Također možete otvoriti cijeli projekt koristeći [Codespaces](https://github.com/features/codespaces), GitHubov ugrađeni uređivač koda / razvojno okruženje u oblaku, ili [GitHub Desktop](https://desktop.github.com/).
Na kraju, možete preuzeti kod u zipanoj mapi.
### Još nekoliko zanimljivih stvari o GitHubu
### Nekoliko zanimljivih stvari o GitHubu
Možete označiti zvjezdicom, pratiti i/ili "forkati" bilo koji javni repozitorij na GitHubu. Svoje označene repozitorije možete pronaći u padajućem izborniku u gornjem desnom kutu. To je poput označavanja stranica, ali za kod.
Projekti imaju tracker problema, uglavnom na GitHubu u kartici "Issues", osim ako nije drugačije naznačeno, gdje ljudi raspravljaju o problemima vezanim za projekt. Kartica Pull Requests je mjesto gdje ljudi raspravljaju i pregledavaju promjene koje su u tijeku.
Projekti također mogu imati rasprave na forumima, mailing listama ili kanalima za chat poput Slacka, Discorda ili IRC-a.
Projekti također mogu imati rasprave na forumima, mailing listama ili chat kanalima poput Slacka, Discorda ili IRC-a.
✅ Pogledajte svoj novi GitHub repo i isprobajte nekoliko stvari, poput uređivanja postavki, dodavanja informacija u svoj repo i stvaranja projekta (poput Kanban ploče). Puno toga možete učiniti!
✅ Pogledajte svoj novi GitHub repo i isprobajte nekoliko stvari, poput uređivanja postavki, dodavanja informacija u repo i stvaranja projekta (poput Kanban ploče). Puno toga možete učiniti!
---
## 🚀 Izazov
Udružite se s prijateljem kako biste radili na kodu jedno drugoga. Zajedno stvorite projekt, forkajte kod, kreirajte grane i spojite promjene.
Udružite se s prijateljem i radite na kodu jedno drugoga. Zajedno stvorite projekt, forkajte kod, kreirajte grane i spojite promjene.
## Kviz nakon predavanja
## Kviz nakon predavanja
[Kviz nakon predavanja](https://ff-quizzes.netlify.app/web/en/)
## Pregled i samostalno učenje
## Pregled i samostalno učenje
Pročitajte više o [doprinosu open source softveru](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Pročitajte više o [doprinosu otvorenom softveru](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Vježbajte, vježbajte, vježbajte. GitHub ima odlične staze za učenje dostupne putem [skills.github.com](https://skills.github.com):
Vježbajte, vježbajte, vježbajte. GitHub ima odlične obrazovne putove dostupne putem [skills.github.com](https://skills.github.com):
- [Prvi tjedan na GitHubu](https://skills.github.com/#first-week-on-github)
Također ćete pronaći naprednije tečajeve.
Tamo ćete pronaći i naprednije tečajeve.
## Zadatak
## Zadatak
Završite [tečaj Prvi tjedan na GitHubu](https://skills.github.com/#first-week-on-github)
---
**Odricanje od odgovornosti**:
Ovaj dokument je preveden pomoću AI usluge za prevođenje [Co-op Translator](https://github.com/Azure/co-op-translator). Iako nastojimo osigurati točnost, imajte na umu da automatski prijevodi mogu sadržavati pogreške ili netočnosti. Izvorni dokument na izvornom jeziku treba smatrati autoritativnim izvorom. Za ključne informacije preporučuje se profesionalni prijevod od strane ljudskog prevoditelja. Ne preuzimamo odgovornost za bilo kakve nesporazume ili pogrešne interpretacije koje proizlaze iz korištenja ovog prijevoda.
**Izjava o odricanju odgovornosti**:
Ovaj dokument je preveden pomoću AI usluge za prevođenje [Co-op Translator](https://github.com/Azure/co-op-translator). Iako nastojimo osigurati točnost, imajte na umu da automatski prijevodi mogu sadržavati pogreške ili netočnosti. Izvorni dokument na izvornom jeziku treba smatrati autoritativnim izvorom. Za ključne informacije preporučuje se profesionalni prijevod od strane ljudskog prevoditelja. Ne preuzimamo odgovornost za nesporazume ili pogrešna tumačenja koja mogu proizaći iz korištenja ovog prijevoda.
Ha a Git nincs telepítve, [töltsd le a Gitet](https://git-scm.com/downloads). Ezután állítsd be a helyi Git profilodat a terminálban:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
Ellenőrizheted, hogy a Git már konfigurálva van-e, ha beírod:
`git config --list`
Szükséged lesz egy GitHub-fiókra, egy kódszerkesztőre (például Visual Studio Code), és meg kell nyitnod a terminált (vagy: parancssort).
Látogass el a [github.com](https://github.com/) oldalra, és hozz létre egy fiókot, ha még nincs, vagy jelentkezz be, és töltsd ki a profilodat.
Látogass el a [github.com](https://github.com/) oldalra, és hozz létre egy fiókot, ha még nincs, vagy jelentkezz be, és töltsd ki a profilodat.
✅ A GitHub nem az egyetlen kódtárhely a világon; vannak mások is, de a GitHub a legismertebb.
✅ A GitHub nem az egyetlen kódrepozitórium a világon; vannak mások is, de a GitHub a legismertebb.
### Felkészülés
### Előkészületek
Szükséged lesz egy mappára a helyi gépeden (laptop vagy PC) egy kódprojekttel, valamint egy nyilvános GitHub-tárhelyre, amely példaként szolgál arra, hogyan járulhatsz hozzá mások projektjeihez.
Szükséged lesz egy mappára a helyi gépeden (laptop vagy PC) egy kódprojekttel, valamint egy nyilvános GitHub-repozitóriumra, amely példaként szolgál arra, hogyan járulhatsz hozzá mások projektjeihez.
---
## Kódkezelés
Tegyük fel, hogy van egy helyi mappád egy kódprojekttel, és szeretnéd nyomon követni a haladásodat a git verziókezelő rendszer segítségével. Egyesek a git használatát ahhoz hasonlítják, mintha szerelmes levelet írnál a jövőbeli önmagadnak. Ha napokkal, hetekkel vagy hónapokkal később elolvasod a commit üzeneteidet, emlékezni fogsz arra, hogy miért hoztál egy adott döntést, vagy vissza tudsz vonni egy változtatást – feltéve, hogy jó "commit üzeneteket" írsz.
Tegyük fel, hogy van egy helyi mappád egy kódprojekttel, és szeretnéd elkezdeni nyomon követni a haladásodat a git verziókezelő rendszer segítségével. Néhányan a git használatát úgy hasonlítják, mintha szerelmes levelet írnál a jövőbeli önmagadnak. Ha napokkal, hetekkel vagy hónapokkal később olvasod a commit üzeneteidet, képes leszel felidézni, miért hoztál egy döntést, vagy "visszavonni" egy változtatást - persze csak akkor, ha jó "commit üzeneteket" írsz.
### Feladat: Hozz létre egy tárhelyet és commitold a kódot
### Feladat: Hozz létre egy repozitóriumot és commitold a kódot
> Nézd meg a videót
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Hozz létre egy tárhelyet a GitHub-on**. A GitHub.com-on, a tárhelyek fülön, vagy a jobb felső navigációs sávban keresd meg az **új tárhely** gombot.
1. Adj nevet a tárhelyednek (mappádnak).
1. Válaszd a **tárhely létrehozása** opciót.
1. **Repozitórium létrehozása a GitHubon**. A GitHub.com oldalon, a repozitóriumok fülön, vagy a jobb felső navigációs sávban keresd meg az **új repo** gombot.
1. Adj nevet a repozitóriumodnak (mappának).
1. Válaszd a **repozitórium létrehozása** lehetőséget.
1. **Navigálj a munkamappádhoz**. A terminálban válts arra a mappára (más néven könyvtárra), amelyet nyomon szeretnél követni. Írd be:
@ -70,19 +71,19 @@ Tegyük fel, hogy van egy helyi mappád egy kódprojekttel, és szeretnéd nyomo
cd [name of your folder]
```
1. **Inicializálj egy git tárhelyet**. A projektedben írd be:
1. **Git repozitórium inicializálása**. A projektedben írd be:
```bash
git init
```
1. **Ellenőrizd az állapotot**. A tárhely állapotának ellenőrzéséhez írd be:
1. **Állapot ellenőrzése**. A repozitórium állapotának ellenőrzéséhez írd be:
```bash
git status
```
A kimenet valahogy így nézhet ki:
Az eredmény valahogy így nézhet ki:
```output
Changes not staged for commit:
@ -93,70 +94,70 @@ Tegyük fel, hogy van egy helyi mappád egy kódprojekttel, és szeretnéd nyomo
modified: file2.txt
```
A `git status` parancs általában olyan információkat ad, mint például mely fájlok állnak készen a tárhelyre való _mentésre_, vagy melyeken vannak olyan változások, amelyeket érdemes lehet rögzíteni.
A `git status` parancs általában olyan információkat ad, mint például mely fájlok készek a _mentésre_ a repóba, vagy melyeken vannak olyan változtatások, amelyeket érdemes lehet megőrizni.
1. **Adj hozzá minden fájlt a nyomon követéshez**
Ezt hívják fájlok stagingelésének / a staging területhez való hozzáadásának.
1. **Minden fájl hozzáadása nyomon követéshez**
Ezt nevezik fájlok staging területre helyezésének/hozzáadásának.
```bash
git add .
```
A `git add`és a `.` argumentum azt jelzi, hogy az összes fájlodat és változásodat nyomon követésre jelölöd.
A `git add`plusz `.` argumentum azt jelzi, hogy minden fájl és változtatás nyomon követésre kerül.
Ez lehetővé teszi, hogy csak kiválasztott fájlokat adj hozzá a staging területhez, ha nem akarod egyszerre az összes fájlt commitolni.
Ez lehetővé teszi, hogy csak kiválasztott fájlokat adj hozzá a staging területre, ha nem szeretnéd egyszerre az összes fájlt commitolni.
1. **Távolíts el minden fájlt a staging területről**
1. **Minden fájl unstagingelése**
```bash
git reset
```
Ez a parancs segít egyszerre eltávolítani az összes fájlt a staging területről.
Ez a parancs segít egyszerre unstagingelni az összes fájlt.
1. **Távolíts el egy adott fájlt a staging területről**
1. **Egy adott fájl unstagingelése**
```bash
git reset [file or folder name]
```
Ez a parancs segít egyszerre csak egy adott fájlt eltávolítani, amelyet nem szeretnél a következő commitba belefoglalni.
Ez a parancs segít csak egy adott fájlt unstagingelni, amelyet nem szeretnél a következő commitba belefoglalni.
1. **Rögzítsd a munkádat**. Ezen a ponton hozzáadtad a fájlokat az úgynevezett _staging területhez_. Ez egy hely, ahol a Git nyomon követi a fájljaidat. Ahhoz, hogy a változtatás végleges legyen, _commitot_ kell létrehoznod a `git commit` paranccsal. A _commit_ egy mentési pontot képvisel a tárhelyed történetében. Írd be a következőt egy _commit_ létrehozásához:
1. **Munkád megőrzése**. Ezen a ponton hozzáadtad a fájlokat az úgynevezett _staging területre_. Ez egy hely, ahol a Git nyomon követi a fájljaidat. Ahhoz, hogy a változtatás végleges legyen, _commitolnod_ kell a fájlokat. Ehhez hozz létre egy _commitot_ a `git commit` paranccsal. A _commit_ egy mentési pontot képvisel a repó történetében. Írd be a következőt egy _commit_ létrehozásához:
```bash
git commit -m "first commit"
```
Ez az összes fájlodat commitolja, a "first commit" üzenettel. A jövőbeli commit üzeneteknél érdemes részletesebb leírást adni, hogy pontosan közvetítsd, milyen típusú változtatást végeztél.
Ez commitolja az összes fájlodat, hozzáadva az "első commit" üzenetet. A jövőbeli commit üzeneteknél érdemes lesz részletesebb leírást adni, hogy közvetítsd, milyen típusú változtatást végeztél.
1. **Kapcsold össze a helyi Git tárhelyedet a GitHub-bal**. Egy Git tárhely a gépeden jó dolog, de előbb-utóbb szeretnéd a fájljaid biztonsági mentését máshol is elvégezni, és másokat is meghívni, hogy dolgozzanak veled a tárhelyeden. Egy ilyen nagyszerű hely a GitHub. Emlékezz, hogy már létrehoztunk egy tárhelyet a GitHub-on, így csak össze kell kapcsolnunk a helyi Git tárhelyet a GitHub-bal. A `git remote add` parancs pontosan ezt teszi. Írd be a következő parancsot:
1. **Kapcsold össze a helyi Git repódat a GitHubbal**. Egy Git repó jó a gépeden, de egy ponton szeretnéd a fájljaidat valahol biztonságban tudni, és másokat is meghívni, hogy dolgozzanak veled a repón. Egy ilyen nagyszerű hely erre a GitHub. Ne feledd, már létrehoztunk egy repót a GitHubon, így csak össze kell kapcsolnunk a helyi Git repót a GitHubbal. A `git remote add` parancs pontosan ezt teszi. Írd be a következő parancsot:
> Megjegyzés: Mielőtt beírod a parancsot, menj a GitHub tárhelyed oldalára, hogy megtaláld a tárhely URL-jét. Ezt fogod használni az alábbi parancsban. Cseréld ki az ```https://github.com/username/repository_name.git```-et a GitHub URL-edre.
> Megjegyzés: mielőtt beírod a parancsot, menj a GitHub repó oldalára, hogy megtaláld a repozitórium URL-jét. Ezt fogod használni az alábbi parancsban. Cseréld ki ```https://github.com/username/repository_name.git```-et a GitHub URL-edre.
Ez létrehoz egy _távoli kapcsolatot_, amely az "origin" névre hallgat, és a korábban létrehozott GitHub tárhelyre mutat.
Ez létrehoz egy _távoli kapcsolatot_, vagyis egy "origin" nevű kapcsolatot, amely az általad korábban létrehozott GitHub repozitóriumra mutat.
1. **Küldd el a helyi fájlokat a GitHub-ra**. Eddig létrehoztál egy _kapcsolatot_ a helyi tárhely és a GitHub tárhely között. Küldjük el ezeket a fájlokat a GitHub-ra a következő `git push` paranccsal:
1. **Helyi fájlok küldése a GitHubra**. Eddig létrehoztál egy _kapcsolatot_ a helyi repó és a GitHub repó között. Küldjük el ezeket a fájlokat a GitHubra a következő `git push` parancs segítségével:
> Megjegyzés: Az alapértelmezett branch neve eltérhet az ```main```-től.
> Megjegyzés: az alapértelmezett branch neve eltérhet a ```main```-től.
```bash
git push -u origin main
```
Ez elküldi a "main" branch commitjait a GitHub-ra.
Ez elküldi a commitjaidat a "main" branchben a GitHubra. Az `upstream` branch beállítása, beleértve a `-u` opciót a parancsban, kapcsolatot hoz létre a helyi branch és a távoli branch között, így a jövőben egyszerűen használhatod a git push vagy git pull parancsokat anélkül, hogy meg kellene adnod a branch nevét. A Git automatikusan az upstream branch-et fogja használni, és nem kell explicit módon megadnod a branch nevet a jövőbeli parancsokban.
2. **További változtatások hozzáadása**. Ha folytatni szeretnéd a változtatások végrehajtását és azok GitHub-ra küldését, csak a következő három parancsot kell használnod:
2. **További változtatások hozzáadása**. Ha folytatni szeretnéd a változtatások végrehajtását és azok GitHubra történő feltöltését, csak a következő három parancsot kell használnod:
```bash
git add .
@ -164,154 +165,154 @@ Tegyük fel, hogy van egy helyi mappád egy kódprojekttel, és szeretnéd nyomo
git push
```
> Tipp: Érdemes lehet egy `.gitignore` fájlt is használni, hogy megakadályozd, hogy olyan fájlok jelenjenek meg a GitHub-on, amelyeket nem szeretnél nyomon követni – például egy jegyzetfájl, amelyet ugyanabban a mappában tárolsz, de nincs helye egy nyilvános tárhelyen. `.gitignore` fájl sablonokat találhatsz itt: [.gitignore templates](https://github.com/github/gitignore).
> Tipp: Érdemes lehet egy `.gitignore` fájlt is alkalmazni, hogy megakadályozd, hogy olyan fájlok, amelyeket nem szeretnél nyomon követni, megjelenjenek a GitHubon - például az a jegyzetfájl, amelyet ugyanabban a mappában tárolsz, de nincs helye egy nyilvános repozitóriumban. `.gitignore` fájl sablonokat találhatsz itt: [.gitignore templates](https://github.com/github/gitignore).
#### Commit üzenetek
Egy nagyszerű Git commit tárgysor a következő mondatot egészíti ki:
Ha alkalmazzuk, ez a commit <a tetárgysoroditt>.
Ha alkalmazzuk, ez a commit <ide jönatárgysorod>
A tárgysorban használj felszólító, jelen idejű formát: "változtat" ne "változtatott" vagy "változtatások".
Ahogy a tárgysorban, a törzsben (opcionális) is használj felszólító, jelen idejű formát. A törzsnek tartalmaznia kell a változtatás motivációját, és össze kell hasonlítania ezt az előző viselkedéssel. A `miért`-et magyarázod, nem a `hogyan`-t.
A tárgyban használj felszólító, jelen idejű igét: "változtat" nem "változtatott" vagy "változtatások".
Ahogy a tárgyban, a törzsben (opcionális) is használj felszólító, jelen idejű igét. A törzsnek tartalmaznia kell a változtatás motivációját, és kontrasztot kell állítania a korábbi viselkedéssel. A `miértet` magyarázod, nem a `hogyan`.
✅ Szánj néhány percet a GitHub böngészésére. Találsz egy igazán nagyszerű commit üzenetet? Találsz egy igazán minimálisat? Szerinted milyen információ a legfontosabb és leghasznosabb egy commit üzenetben?
✅ Szánj néhány percet arra, hogy böngéssz a GitHubon. Találsz egy igazán nagyszerű commit üzenetet? Találsz egy igazán minimálisat? Szerinted milyen információk a legfontosabbak és leghasznosabbak egy commit üzenetben?
### Feladat: Együttműködés
A fő ok, amiért a dolgokat a GitHub-ra helyeztük, az volt, hogy lehetővé tegyük az együttműködést más fejlesztőkkel.
A fő ok, amiért dolgokat feltöltünk a GitHubra, az az, hogy lehetővé tegyük más fejlesztőkkel való együttműködést.
## Együttműködés másokkal projekteken
## Projektek közös munkája másokkal
> Nézd meg a videót
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
A tárhelyeden navigálj az `Insights > Community` menüponthoz, hogy lásd, hogyan viszonyul a projekted az ajánlott közösségi szabványokhoz.
A repozitóriumodban navigálj az `Insights > Community` menüpontra, hogy megnézd, hogyan viszonyul a projekted az ajánlott közösségi szabványokhoz.
Íme néhány dolog, ami javíthatja a GitHub tárhelyedet:
Íme néhány dolog, ami javíthatja a GitHub repódat:
- **Leírás**. Adtál leírást a projektedhez?
- **README**. Hozzáadtál egy README-t? A GitHub útmutatást nyújt a [README írásához](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Hozzájárulási irányelvek**. Van a projektednek [hozzájárulási irányelve](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Magatartási kódex**. Van [magatartási kódex](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **README**. Készítettél README-t? A GitHub útmutatást nyújt a [README írásához](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Hozzájárulási irányelvek**. Van a projektednek [hozzájárulási irányelve](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Magatartási kódex**. Van [magatartási kódex](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licenc**. Talán a legfontosabb, van [licenc](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Ezek az erőforrások mind hasznosak az új csapattagok beilleszkedéséhez. Ezek azok a dolgok, amelyeket az új hozzájárulók általában megnéznek, mielőtt még a kódodat átnéznék, hogy eldöntsék, a projekted megfelelő hely-e számukra.
Ezek az erőforrások elősegítik az új csapattagok beilleszkedését. Ezek azok a dolgok, amelyeket az új hozzájárulók általában megnéznek, mielőtt a kódodat megvizsgálnák, hogy eldöntsék, a projekted megfelelő hely-e számukra, hogy idejükből áldozzanak rá.
✅ A README fájlok, bár időt igényelnek az elkészítésük, gyakran elhanyagoltak a túlterhelt karbantartók által. Találsz példát egy különösen részletesre? Megjegyzés: vannak [eszközök, amelyek segítenek jó README-ket készíteni](https://www.makeareadme.com/), amelyeket érdemes kipróbálni.
✅ A README fájlok, bár időt igényelnek az elkészítésük, gyakran elhanyagoltak az elfoglalt karbantartók által. Találsz példát egy különösen leíró jellegű README-re? Megjegyzés: vannak [eszközök, amelyek segítenek jó README-ket készíteni](https://www.makeareadme.com/), amelyeket érdemes kipróbálni.
### Feladat: Kód egyesítése
### Feladat: Kód összevonása
A hozzájárulási dokumentumok segítenek az embereknek hozzájárulni a projekthez. Elmagyarázza, hogy milyen típusú hozzájárulásokat keresel, és hogyan működik a folyamat. A hozzájárulóknak egy sor lépést kell követniük, hogy hozzájárulhassanak a GitHub tárhelyedhez:
A hozzájárulási dokumentumok segítenek az embereknek hozzájárulni a projekthez. Elmagyarázzák, milyen típusú hozzájárulásokat keresel, és hogyan működik a folyamat. A hozzájárulóknak egy sor lépést kell követniük, hogy hozzájárulhassanak a GitHub repódhoz:
1. **Tárhely forkolása**. Valószínűleg azt szeretnéd, hogy az emberek _forkolják_ a projektedet. A forkolás azt jelenti, hogy létrehoznak egy másolatot a tárhelyedről a saját GitHub profiljukon.
1. **Klónozás**. Ezután klónozzák a projektet a helyi gépükre.
1. **Branch létrehozása**. Kérd meg őket, hogy hozzanak létre egy _brancht_ a munkájukhoz.
1. **Változtatások egy területre koncentrálása**. Kérd meg a hozzájárulókat, hogy egyszerre csak egy dologra koncentráljanak – így nagyobb az esélye, hogy a munkájukat _egyesíteni_ tudod. Képzeld el, hogy írnak egy hibajavítást, hozzáadnak egy új funkciót, és frissítenek néhány tesztet – mi van, ha csak 2-ből 3-at, vagy 1-ből 3-at szeretnél megvalósítani?
1. **A repód forkja**. Valószínűleg azt szeretnéd, hogy az emberek _forkolják_ a projektedet. A forkolás azt jelenti, hogy létrehoznak egy másolatot a repozitóriumodról a GitHub profiljukon.
1. **Klónozás**. Innen klónozzák a projektet a helyi gépükre.
1. **Branch létrehozása**. Kérd meg őket, hogy hozzanak létre egy _branch_-et a munkájukhoz.
1. **Változtatás egy területre koncentrálása**. Kérd meg a hozzájárulókat, hogy egyszerre egy dologra koncentrálják a hozzájárulásaikat - így nagyobb az esélye, hogy _össze tudod vonni_ a munkájukat. Képzeld el, hogy írnak egy hibajavítást, hozzáadnak egy új funkciót, és frissítenek több tesztet - mi van, ha csak 2-ből 3-at, vagy 1-ből 3 változtatást tudsz vagy akarsz megvalósítani?
✅ Képzelj el egy helyzetet, ahol a branchek különösen kritikusak a jó kód írásához és szállításához. Milyen felhasználási esetek jutnak eszedbe?
✅ Képzelj el egy helyzetet, ahol a branch-ek különösen kritikusak a jó kód írásához és szállításához. Milyen felhasználási esetek jutnak eszedbe?
> Megjegyzés: Légy te a változás, amit látni szeretnél a világban, és hozz létre brancheket a saját munkádhoz is. Bármilyen commitot készítesz, az azon a branchen lesz, amelyre éppen "ki vagy választva". Használd a `git status` parancsot, hogy lásd, melyik branch az.
> Megjegyzés: légy te magad a változás, amit látni szeretnél a világban, és hozz létre branch-eket a saját munkádhoz is. Bármilyen commitot készítesz, az azon a branch-en lesz, amelyen éppen "ki vagy jelentkezve". Használd a `git status` parancsot, hogy lásd, melyik branch az.
Nézzük meg egy hozzájáruló munkafolyamatát. Tegyük fel, hogy a hozzájáruló már _forkolta_ és _klónozta_ a tárhelyet, így van egy Git tárhelye, amelyen dolgozhat a helyi gépén:
Nézzük meg egy hozzájáruló munkafolyamatát. Tegyük fel, hogy a hozzájáruló már _forkolta_ és _klónozta_ a repót, így van egy Git repója, amely készen áll a munkára a helyi gépén:
1. **Branch létrehozása**. Használd a `git branch` parancsot egy branch létrehozásához, amely tartalmazza a hozzájárulni kívánt változtatásokat:
1. **Branch létrehozása**. Használd a `git branch` parancsot egy branch létrehozásához, amely tartalmazza azokat a változtatásokat, amelyeket hozzájárulni szeretnél:
```bash
git branch [branch-name]
```
1. **Váltás a munkabranchre**. Válts az adott branchre, és frissítsd a munkakönyvtárat a `git switch` paranccsal:
1. **Váltás a munkabranch-re**. Válts az adott branch-re, és frissítsd a munkakönyvtárat a `git switch` paranccsal:
```bash
git switch [branch-name]
```
1. **Munka elvégzése**. Ezen a ponton hozzáadhatod a változtatásaidat. Ne felejtsd el a Gitnek jelezni a következő parancsokkal:
1. **Munka elvégzése**. Ezen a ponton hozzáadhatod a változtatásaidat. Ne felejtsd el tájékoztatni a Gitet a következő parancsokkal:
```bash
git add .
git commit -m "my changes"
```
Ügyelj arra, hogy jó nevet adj a commitodnak, a saját érdekedben, valamint a tárhely karbantartójának érdekében, akinek segítesz.
Ügyelj arra, hogy jó nevet adj a commitodnak, a saját érdekedben, valamint annak a repó karbantartójának érdekében, akinek segítesz.
1. **A munkád egyesítése a `main` branch-csel**. Egy bizonyos ponton befejezed a munkát, és szeretnéd egyesíteni a munkádat a `main` branch-csel. A `main` branch időközben változhatott, ezért győződj meg róla, hogy először frissíted a legújabb verzióra a következő parancsokkal:
1. **Munkád összevonása a `main` branch-csel**. Egy ponton befejezed a munkát, és szeretnéd összevonni a munkádat a `main` branch-csel. A `main` branch időközben változhatott, ezért győződj meg róla, hogy először frissíted a legújabb verzióra a következő parancsokkal:
```bash
git switch main
git pull
```
Ezen a ponton győződj meg arról, hogy bármilyen _konfliktus_, olyan helyzet, ahol a Git nem tudja könnyen _egyesíteni_ a változtatásokat, a munkabranchben történik. Ezért futtasd a következő parancsokat:
Ezen a ponton győződj meg róla, hogy minden _konfliktus_, olyan helyzetek, ahol a Git nem tudja könnyen _összevonni_ a változtatásokat, a munkabranch-edben történik. Ezért futtasd a következő parancsokat:
```bash
git switch [branch_name]
git merge main
```
Ez behozza az összes változtatást a `main` branchből a te branchedbe, és remélhetőleg folytathatod a munkát. Ha nem, a VS Code megmutatja, hol van a Git _zavarban_, és egyszerűen módosíthatod az érintett fájlokat, hogy megmondd, melyik tartalom a legpontosabb.
A `git merge main` parancs behozza az összes változtatást a `main` branch-ből a branch-edbe. Remélhetőleg folytathatod a munkát. Ha nem, a VS Code megmutatja, hol van a Git _z
1. **Nyiss egy PR-t**. Következő lépésként nyiss egy PR-t. Ezt úgy teheted meg, hogy navigálsz a GitHubon a forkolt repóhoz. A GitHubon látni fogsz egy jelzést, amely megkérdezi, hogy szeretnél-e új PR-t létrehozni. Kattints rá, és egy felületre kerülsz, ahol módosíthatod a commit üzenet címét, és adhatsz neki egy megfelelőbb leírást. Most a forkolt repó karbantartója látni fogja ezt a PR-t, és _remélhetőleg_ értékelni fogja, majd _összevonja_ a PR-t. Mostantól te is hozzájáruló vagy, hurrá! :)
1. **Küldd el a munkádat a GitHub-ra**. A munkád GitHub-ra küldése két dolgot jelent. A branched feltöltését a tárhelyedre, majd egy PR (Pull Request) megnyitását.
1. **Takarítás**. Jó gyakorlatnak számít, ha _kitakarítasz_ miután sikeresen összevonták a PR-t. Takarítsd ki mind a helyi branch-edet, mind azt a branch-et, amit GitHubra feltöltöttél. Először töröld helyben a következő parancs segítségével:
```bash
git push --set-upstream origin [branch-name]
git branch -d [branch-name]
```
Ezután menj a GitHub oldalára a forkolt repóhoz, és távolítsd el a távoli branch-et, amit éppen feltöltöttél.
A fenti parancs létrehozza a branched a forkolt tárhelyeden.
1. **
A `Pull request` kifejezés elsőre furcsának tűnhet, hiszen valójában a változtatásaidat szeretnéd "feltolni" a projektbe. Azonban a karbantartónak (projekt tulajdonosa) vagy a magcsapatnak meg kell vizsgálnia a változtatásaidat, mielőtt azokat összevonják a projekt "main" ágával, így valójában egy döntést kérsz a karbantartótól a változtatásról.
A `Pull request` kifejezés elsőre furcsának tűnhet, hiszen valójában a változtatásaidat szeretnéd feltölteni a projekthez. Azonban a karbantartónak (projekt tulajdonosának) vagy a core csapatnak meg kell fontolnia a változtatásaidat, mielőtt összevonják a projekt "main" branch-ével, tehát valójában egy döntést kérsz a karbantartótól a változtatásról.
A pull request egy hely, ahol összehasonlíthatod és megvitathatod az adott ágon bevezetett különbségeket véleményekkel, megjegyzésekkel, integrált tesztekkel és egyebekkel. Egy jó pull request nagyjából ugyanazokat a szabályokat követi, mint egy commit üzenet. Hivatkozhatsz egy problémára az issue trackerben, például ha a munkád megold egy problémát. Ezt úgy teheted meg, hogy `#` jelet írsz, majd a probléma számát, például `#97`.
A pull request egy hely, ahol összehasonlíthatod és megvitathatod az adott branch által bevezetett különbségeket, véleményekkel, megjegyzésekkel, integrált tesztekkel és egyebekkel. Egy jó pull request nagyjából ugyanazokat a szabályokat követi, mint egy commit üzenet. Hivatkozhatsz egy problémára az issue trackerben, például ha a munkád megold egy problémát. Ezt úgy teheted meg, hogy egy `#` jelet írsz, amit a probléma száma követ. Például `#97`.
🤞Reméljük, hogy minden ellenőrzés sikeresen lefut, és a projekt tulajdonosai beolvasszák a változtatásaidat a projektbe🤞
🤞Reméljük, hogy minden ellenőrzés sikeresen lezajlik, és a projekt tulajdonosa(i) összevonják a változtatásaidat a projektbe🤞
Frissítsd a jelenlegi helyi munkafiókodat az összes új commit-tal, amely a GitHub megfelelő távoli ágán található:
Frissítsd a jelenlegi helyi munkabranch-edet az összes új commit-tal, amely a GitHubon lévő megfelelő távoli branch-en található:
`git pull`
## Hogyan járulj hozzá nyílt forráskódú projektekhez
Először találj egy GitHub repót, amely érdekel, és amelyhez szeretnél hozzájárulni. A repó tartalmát le kell másolnod a gépedre.
Először keress egy GitHub repót, amely érdekel, és amelyhez szeretnél hozzájárulni. A repó tartalmát le kell másolnod a gépedre.
✅ Egy jó módja annak, hogy "kezdőbarát" repókat találj, ha [a 'good-first-issue' címkére keresel](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Jó módja annak, hogy 'kezdőbarát' repókat találj, ha [a 'good-first-issue' címkére keresel](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
A kód másolásának több módja van. Az egyik módja, hogy "klónozod" a repó tartalmát HTTPS, SSH vagy a GitHub CLI (Command Line Interface) használatával.
Számos módja van a kód másolásának. Az egyik módja, hogy "klónozod" a repó tartalmát HTTPS, SSH vagy a GitHub CLI (Command Line Interface) segítségével.
Nyisd meg a terminált, és klónozd a repót így:
Nyisd meg a terminált, és klónozd a repót így:
`git clone https://github.com/ProjectURL`
A projekten való munkához válts a megfelelő mappára:
A projekten való munka érdekében lépj be a megfelelő mappába:
`cd ProjectURL`
A teljes projektet megnyithatod [Codespaces](https://github.com/features/codespaces), a GitHub beépített kódszerkesztőjével / felhőalapú fejlesztési környezetével, vagy [GitHub Desktop](https://desktop.github.com/) használatával is.
A teljes projektet megnyithatod [Codespaces](https://github.com/features/codespaces), a GitHub beépített kódszerkesztőjével / felhőalapú fejlesztési környezetével, vagy [GitHub Desktop](https://desktop.github.com/) segítségével is.
Végül letöltheted a kódot egy tömörített mappában.
### Néhány további érdekesség a GitHubról
Bármely nyilvános repót csillagozhatsz, követhetsz, vagy "forkolhatsz" a GitHubon. A csillagozott repóidat a jobb felső legördülő menüben találod. Ez olyan, mint a könyvjelzőzés, csak kódhoz.
Bármely nyilvános repót a GitHubon csillagozhatsz, követhetsz és/vagy "forkolhatsz". A csillagozott repóidat a jobb felső legördülő menüben találod. Ez olyan, mint a könyvjelzőzés, csak kódhoz.
A projekteknek van egy issue trackere, általában a GitHubon az "Issues" fül alatt, hacsak másképp nincs jelezve, ahol az emberek a projekttel kapcsolatos problémákat vitatják meg. A Pull Requests fül pedig az a hely, ahol az emberek a folyamatban lévő változtatásokat vitatják meg és ellenőrzik.
A projekteknek van egy issue trackerük, többnyire a GitHubon az "Issues" fül alatt, hacsak másképp nincs jelezve, ahol az emberek a projekttel kapcsolatos problémákat vitatják meg. Az"Pull Requests" fül pedig az a hely, ahol az emberek a folyamatban lévő változtatásokat vitatják meg és véleményezik.
A projekteknek lehetnek fórumai, levelezőlistái vagy csevegőcsatornái, például Slack, Discord vagy IRC.
A projekteknek lehetnek fórumai, levelezőlistái vagy csevegőcsatornái, mint például Slack, Discord vagy IRC.
✅ Nézz körül az új GitHub repódban, és próbálj ki néhány dolgot, például a beállítások szerkesztését, információk hozzáadását a repóhoz, és egy projekt létrehozását (például egy Kanban táblát). Rengeteg dolgot kipróbálhatsz!
✅ Nézz körül az új GitHub repódban, és próbálj ki néhány dolgot, például a beállítások szerkesztését, információk hozzáadását a repóhoz, és egy projekt létrehozását (például egy Kanban táblát). Rengeteg dolgot tehetsz!
---
## 🚀 Kihívás
Dolgozz együtt egy barátoddal egymás kódján. Hozzatok létre közösen egy projektet, forkoljatok kódot, hozzatok létre ágakat, és vonjátok össze a változtatásokat.
Dolgozz együtt egy barátoddal egymás kódján. Hozzatok létre közösen egy projektet, forkoljatok kódot, hozzatok létre branch-eket, és vonjátok össze a változtatásokat.
## Előadás utáni kvíz
## Előadás utáni kvíz
[Előadás utáni kvíz](https://ff-quizzes.netlify.app/web/en/)
## Áttekintés és önálló tanulás
Olvass többet arról, hogyan járulhatsz hozzá [nyílt forráskódú szoftverekhez](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Olvass többet a [nyílt forráskódú szoftverekhez való hozzájárulásról](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
@ -319,13 +320,13 @@ Gyakorolj, gyakorolj, gyakorolj. A GitHub remek tanulási útvonalakat kínál a
- [Első hét a GitHubon](https://skills.github.com/#first-week-on-github)
Itt találhatsz haladóbb kurzusokat is.
Itt további haladó kurzusokat is találsz.
## Feladat
Teljesítsd [az Első hét a GitHubon kurzust](https://skills.github.com/#first-week-on-github).
Teljesítsd az [Első hét a GitHubon kurzust](https://skills.github.com/#first-week-on-github)
---
**Felelősségkizárás**:
Ez a dokumentum az [Co-op Translator](https://github.com/Azure/co-op-translator) AI fordítási szolgáltatás segítségével készült. Bár törekszünk a pontosságra, kérjük, vegye figyelembe, hogy az automatikus fordítások hibákat vagy pontatlanságokat tartalmazhatnak. Az eredeti dokumentum az eredeti nyelvén tekintendő hiteles forrásnak. Kritikus információk esetén javasolt a professzionális, emberi fordítás igénybevétele. Nem vállalunk felelősséget a fordítás használatából eredő félreértésekért vagy téves értelmezésekért.
**Felelősségkizárása**:
Ez a dokumentum az [Co-op Translator](https://github.com/Azure/co-op-translator) AI fordítási szolgáltatás segítségével lett lefordítva. Bár törekszünk a pontosságra, kérjük, vegye figyelembe, hogy az automatikus fordítások hibákat vagy pontatlanságokat tartalmazhatnak. Az eredeti dokumentum az eredeti nyelvén tekintendő hiteles forrásnak. Fontos információk esetén javasolt professzionális emberi fordítást igénybe venni. Nem vállalunk felelősséget semmilyen félreértésért vagy téves értelmezésért, amely a fordítás használatából eredhet.
Pelajaran ini mencakup dasar-dasar GitHub, sebuah platform untuk menyimpan dan mengelola perubahan pada kode Anda.
Pelajaran ini membahas dasar-dasar GitHub, sebuah platform untuk menyimpan dan mengelola perubahan pada kode Anda.
> Sketchnote oleh [Tomomi Imura](https://twitter.com/girlie_mac)
@ -39,19 +39,19 @@ Untuk memeriksa apakah Git sudah dikonfigurasi, Anda dapat mengetik:
Anda juga memerlukan akun GitHub, editor kode (seperti Visual Studio Code), dan Anda perlu membuka terminal Anda (atau: command prompt).
Kunjungi [github.com](https://github.com/) dan buat akun jika Anda belum memilikinya, atau masuk dan lengkapi profil Anda.
Navigasikan ke [github.com](https://github.com/) dan buat akun jika Anda belum memilikinya, atau masuk dan lengkapi profil Anda.
✅ GitHub bukan satu-satunya repositori kode di dunia; ada yang lain, tetapi GitHub adalah yang paling dikenal.
### Persiapan
Anda memerlukan folder dengan proyek kode di komputer lokal Anda (laptop atau PC), dan repositori publik di GitHub, yang akan digunakan sebagai contoh cara berkontribusi pada proyek orang lain.
Anda memerlukan folder dengan proyek kode di komputer lokal Anda (laptop atau PC), dan repositori publik di GitHub, yang akan menjadi contoh bagaimana berkontribusi pada proyek orang lain.
---
## Manajemen Kode
Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai melacak kemajuan Anda menggunakan git - sistem kontrol versi. Beberapa orang membandingkan penggunaan git dengan menulis surat cinta untuk diri Anda di masa depan. Membaca pesan commit Anda beberapa hari, minggu, atau bulan kemudian, Anda akan dapat mengingat mengapa Anda membuat keputusan tertentu, atau "mengembalikan" perubahan - yaitu, jika Anda menulis "pesan commit" yang baik.
Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai melacak kemajuan Anda menggunakan git - sistem kontrol versi. Beberapa orang membandingkan menggunakan git dengan menulis surat cinta untuk diri Anda di masa depan. Membaca pesan commit Anda beberapa hari, minggu, atau bulan kemudian, Anda akan dapat mengingat mengapa Anda membuat keputusan, atau "mengembalikan" perubahan - yaitu, ketika Anda menulis pesan commit yang baik.
### Tugas: Membuat repositori dan commit kode
@ -64,7 +64,7 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
1. Beri nama repositori (folder) Anda
1. Pilih **create repository**.
1. **Navigasikan ke folder kerja Anda**. Di terminal Anda, pindah ke folder (juga dikenal sebagai direktori) yang ingin Anda mulai lacak. Ketik:
1. **Navigasikan ke folder kerja Anda**. Di terminal Anda, beralih ke folder (juga dikenal sebagai direktori) yang ingin Anda mulai lacak. Ketik:
```bash
cd [name of your folder]
@ -82,7 +82,7 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
git status
```
Outputnya bisa terlihat seperti ini:
outputnya bisa terlihat seperti ini:
```output
Changes not staged for commit:
@ -93,16 +93,16 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
modified: file2.txt
```
Biasanya perintah `git status` memberi tahu Anda hal-hal seperti file apa yang siap untuk _disimpan_ ke repo atau memiliki perubahan yang mungkin ingin Anda simpan.
Biasanya perintah `git status` memberi tahu Anda hal-hal seperti file apa yang siap untuk _disimpan_ ke repo atau memiliki perubahan yang mungkin ingin Anda pertahankan.
1. **Tambahkan semua file untuk dilacak**
Ini juga disebut sebagai menambahkan file ke area staging.
Ini juga disebut sebagai staging file/menambahkan file ke area staging.
```bash
git add .
```
Argumen `git add` ditambah `.` menunjukkan bahwa semua file & perubahan Anda akan dilacak.
Argumen `git add` ditambah `.` menunjukkan bahwa semua file & perubahan Anda untuk dilacak.
1. **Tambahkan file tertentu untuk dilacak**
@ -126,19 +126,19 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
git reset [file or folder name]
```
Perintah ini membantu kita membatalkan staging hanya file tertentu yang tidak ingin kita sertakan untuk commit berikutnya.
Perintah ini membantu kita membatalkan staging hanya file tertentu sekaligus yang tidak ingin kita sertakan untuk commit berikutnya.
1. **Menyimpan pekerjaan Anda**. Pada titik ini Anda telah menambahkan file ke area yang disebut _staging area_. Tempat di mana Git melacak file Anda. Untuk membuat perubahan permanen, Anda perlu _commit_ file tersebut. Untuk melakukannya, buat _commit_ dengan perintah `git commit`. Sebuah _commit_ mewakili titik penyimpanan dalam sejarah repo Anda. Ketik perintah berikut untuk membuat _commit_:
1. **Menyimpan pekerjaan Anda**. Pada titik ini Anda telah menambahkan file ke area yang disebut _staging area_. Tempat di mana Git melacak file Anda. Untuk membuat perubahan permanen, Anda perlu _commit_ file tersebut. Untuk melakukannya, Anda membuat _commit_ dengan perintah `git commit`. Sebuah _commit_ mewakili titik penyimpanan dalam sejarah repo Anda. Ketik berikut ini untuk membuat _commit_:
```bash
git commit -m "first commit"
```
Ini melakukan commit semua file Anda, dengan menambahkan pesan "first commit". Untuk pesan commit di masa depan, Anda akan ingin lebih deskriptif untuk menyampaikan jenis perubahan yang telah Anda buat.
Ini melakukan commit semua file Anda, menambahkan pesan "first commit". Untuk pesan commit di masa depan, Anda akan ingin lebih deskriptif dalam deskripsi Anda untuk menyampaikan jenis perubahan yang telah Anda buat.
1. **Hubungkan repo Git lokal Anda dengan GitHub**. Sebuah repo Git bagus di komputer Anda, tetapi pada suatu saat Anda ingin memiliki cadangan file Anda di suatu tempat dan juga mengundang orang lain untuk bekerja dengan Anda di repo Anda. Salah satu tempat yang bagus untuk melakukannya adalah GitHub. Ingat kita sudah membuat repo di GitHub, jadi satu-satunya hal yang perlu kita lakukan adalah menghubungkan repo Git lokal kita dengan GitHub. Perintah `git remote add` akan melakukannya. Ketik perintah berikut:
1. **Hubungkan repo Git lokal Anda dengan GitHub**. Repo Git bagus di komputer Anda, tetapi pada suatu saat Anda ingin memiliki cadangan file Anda di suatu tempat dan juga mengundang orang lain untuk bekerja dengan Anda di repo Anda. Salah satu tempat yang bagus untuk melakukannya adalah GitHub. Ingat kita sudah membuat repo di GitHub, jadi satu-satunya hal yang perlu kita lakukan adalah menghubungkan repo Git lokal kita dengan GitHub. Perintah `git remote add` akan melakukan hal itu. Ketik perintah berikut:
> Catatan, sebelum Anda mengetik perintah, buka halaman repo GitHub Anda untuk menemukan URL repositori. Anda akan menggunakannya dalam perintah di bawah ini. Ganti ```https://github.com/username/repository_name.git``` dengan URL GitHub Anda.
> Catatan, sebelum Anda mengetik perintah, pergi ke halaman repo GitHub Anda untuk menemukan URL repositori. Anda akan menggunakannya dalam perintah di bawah ini. Ganti ```https://github.com/username/repository_name.git``` dengan URL GitHub Anda.
@ -146,7 +146,7 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
Ini membuat _remote_, atau koneksi, bernama "origin" yang menunjuk ke repositori GitHub yang Anda buat sebelumnya.
1. **Kirim file lokal ke GitHub**. Sejauh ini Anda telah membuat _connection_ antara repo lokal dan repo GitHub. Mari kita kirim file-file ini ke GitHub dengan perintah berikut `git push`, seperti ini:
1. **Kirim file lokal ke GitHub**. Sejauh ini Anda telah membuat _connection_ antara repo lokal dan repo GitHub. Mari kirim file ini ke GitHub dengan perintah berikut `git push`, seperti ini:
> Catatan, nama branch Anda mungkin berbeda secara default dari ```main```.
@ -154,7 +154,7 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
git push -u origin main
```
Ini mengirimkan commit Anda di branch "main" ke GitHub.
Ini mengirimkan commit Anda di branch "main" ke GitHub. Menetapkan branch `upstream` termasuk `-u` dalam perintah membangun tautan antara branch lokal Anda dan branch remote, sehingga Anda dapat menggunakan git push atau git pull tanpa menentukan nama branch di masa depan. Git akan secara otomatis menggunakan branch upstream dan Anda tidak perlu menentukan nama branch secara eksplisit dalam perintah di masa depan.
2. **Untuk menambahkan lebih banyak perubahan**. Jika Anda ingin terus membuat perubahan dan mengirimkannya ke GitHub, Anda hanya perlu menggunakan tiga perintah berikut:
@ -168,17 +168,17 @@ Misalkan Anda memiliki folder lokal dengan proyek kode dan Anda ingin mulai mela
#### Pesan Commit
Baris subjek commit Git yang bagus melengkapi kalimat berikut:
Baris subjek commit Git yang hebat melengkapi kalimat berikut:
Jika diterapkan, commit ini akan <barissubjekAndadisini>
Untuk subjek, gunakan bentuk imperatif, waktu sekarang: "ubah" bukan "diubah" atau "mengubah".
Seperti pada subjek, di badan (opsional) juga gunakan bentuk imperatif, waktu sekarang. Badan harus mencakup motivasi untuk perubahan dan membandingkannya dengan perilaku sebelumnya. Anda menjelaskan `mengapa`, bukan `bagaimana`.
Seperti dalam subjek, di badan (opsional) juga gunakan bentuk imperatif, waktu sekarang. Badan harus mencakup motivasi untuk perubahan dan membandingkan ini dengan perilaku sebelumnya. Anda menjelaskan `mengapa`, bukan `bagaimana`.
✅ Luangkan beberapa menit untuk menjelajahi GitHub. Bisakah Anda menemukan pesan commit yang sangat bagus? Bisakah Anda menemukan yang sangat minimal? Informasi apa yang menurut Anda paling penting dan berguna untuk disampaikan dalam pesan commit?
✅ Luangkan beberapa menit untuk menjelajahi GitHub. Bisakah Anda menemukan pesan commit yang benar-benar bagus? Bisakah Anda menemukan yang sangat minimal? Informasi apa yang menurut Anda paling penting dan berguna untuk disampaikan dalam pesan commit?
### Tugas: Berkolaborasi
Alasan utama untuk menempatkan sesuatu di GitHub adalah untuk memungkinkan kolaborasi dengan pengembang lain.
Alasan utama untuk meletakkan sesuatu di GitHub adalah untuk memungkinkan kolaborasi dengan pengembang lain.
## Bekerja pada proyek bersama orang lain
@ -191,30 +191,31 @@ Di repositori Anda, navigasikan ke `Insights > Community` untuk melihat bagaiman
Berikut adalah beberapa hal yang dapat meningkatkan repo GitHub Anda:
- **Deskripsi**. Apakah Anda menambahkan deskripsi untuk proyek Anda?
- **README**. Apakah Anda menambahkan README? GitHub menyediakan panduan untuk menulis [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Panduan kontribusi**. Apakah proyek Anda memiliki [panduan kontribusi](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kode Etik**. Apakah Anda memiliki [Kode Etik](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Lisensi**. Mungkin yang paling penting, apakah Anda memiliki [lisensi](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Panduan kontribusi**. Apakah proyek Anda memiliki [panduan kontribusi](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon),
- **Kode Etik**. sebuah [Kode Etik](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Lisensi**. Mungkin yang paling penting, sebuah [lisensi](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Semua sumber daya ini akan bermanfaat untuk membantu anggota tim baru bergabung. Dan ini biasanya adalah hal-hal yang dilihat oleh kontributor baru sebelum bahkan melihat kode Anda, untuk mengetahui apakah proyek Anda adalah tempat yang tepat bagi mereka untuk menghabiskan waktu mereka.
✅ File README, meskipun memerlukan waktu untuk disiapkan, sering diabaikan oleh pemelihara yang sibuk. Bisakah Anda menemukan contoh README yang sangat deskriptif? Catatan: ada beberapa [alat untuk membantu membuat README yang baik](https://www.makeareadme.com/) yang mungkin ingin Anda coba.
Semua sumber daya ini akan bermanfaat untuk onboarding anggota tim baru. Dan hal-hal tersebut biasanya adalah hal yang dilihat oleh kontributor baru sebelum bahkan melihat kode Anda, untuk mengetahui apakah proyek Anda adalah tempat yang tepat bagi mereka untuk menghabiskan waktu mereka.
### Tugas: Gabungkan beberapa kode
✅ File README, meskipun membutuhkan waktu untuk disiapkan, sering diabaikan oleh pemelihara yang sibuk. Bisakah Anda menemukan contoh yang sangat deskriptif? Catatan: ada beberapa [alat untuk membantu membuat README yang baik](https://www.makeareadme.com/) yang mungkin ingin Anda coba.
Dokumen kontribusi membantu orang berkontribusi pada proyek. Dokumen ini menjelaskan jenis kontribusi apa yang Anda cari dan bagaimana prosesnya bekerja. Kontributor perlu melalui serangkaian langkah untuk dapat berkontribusi pada repo Anda di GitHub:
### Tugas: Gabungkan kode
1. **Fork repo Anda**. Anda mungkin ingin orang-orang _fork_ proyek Anda. Forking berarti membuat replika repositori Anda di profil GitHub mereka.
1. **Clone**. Dari sana, mereka akan meng-clone proyek ke komputer lokal mereka.
1. **Buat branch**. Anda akan ingin meminta mereka membuat _branch_ untuk pekerjaan mereka.
1. **Fokuskan perubahan mereka pada satu area**. Minta kontributor untuk memusatkan kontribusi mereka pada satu hal dalam satu waktu - dengan cara itu peluang Anda untuk _merge_ pekerjaan mereka lebih tinggi. Bayangkan mereka menulis perbaikan bug, menambahkan fitur baru, dan memperbarui beberapa tes - bagaimana jika Anda ingin, atau hanya dapat mengimplementasikan 2 dari 3, atau 1 dari 3 perubahan?
Dokumen kontribusi membantu orang berkontribusi pada proyek. Ini menjelaskan jenis kontribusi apa yang Anda cari dan bagaimana prosesnya bekerja. Kontributor perlu melalui serangkaian langkah untuk dapat berkontribusi pada repo Anda di GitHub:
1. **Forking repo Anda** Anda mungkin ingin orang-orang _fork_ proyek Anda. Forking berarti membuat replika repositori Anda di profil GitHub mereka.
1. **Clone**. Dari sana mereka akan meng-clone proyek ke komputer lokal mereka.
1. **Buat branch**. Anda akan ingin meminta mereka untuk membuat _branch_ untuk pekerjaan mereka.
1. **Fokuskan perubahan mereka pada satu area**. Minta kontributor untuk memusatkan kontribusi mereka pada satu hal pada satu waktu - dengan cara itu peluang bahwa Anda dapat _merge_ pekerjaan mereka lebih tinggi. Bayangkan mereka menulis perbaikan bug, menambahkan fitur baru, dan memperbarui beberapa tes - bagaimana jika Anda ingin, atau hanya dapat mengimplementasikan 2 dari 3, atau 1 dari 3 perubahan?
✅ Bayangkan situasi di mana branch sangat penting untuk menulis dan mengirimkan kode yang baik. Kasus penggunaan apa yang dapat Anda pikirkan?
> Catatan, jadilah perubahan yang ingin Anda lihat di dunia, dan buat branch untuk pekerjaan Anda sendiri juga. Setiap commit yang Anda buat akan dibuat di branch tempat Anda saat ini "checked out". Gunakan `git status` untuk melihat branch mana itu.
> Catatan, jadilah perubahan yang ingin Anda lihat di dunia, dan buat branch untuk pekerjaan Anda sendiri juga. Setiap commit yang Anda buat akan dibuat di branch yang saat ini Anda "checkout". Gunakan `git status` untuk melihat branch mana itu.
Mari kita melalui alur kerja kontributor. Anggaplah kontributor telah _forked_ dan _cloned_ repo sehingga mereka memiliki repo Git yang siap untuk dikerjakan di komputer lokal mereka:
Mari kita melalui alur kerja kontributor. Anggaplah kontributor sudah _forked_ dan _cloned_ repo sehingga mereka memiliki repo Git yang siap untuk dikerjakan, di komputer lokal mereka:
1. **Buat branch**. Gunakan perintah `git branch` untuk membuat branch yang akan berisi perubahan yang ingin mereka kontribusikan:
1. **Buat branch**. Gunakan perintah `git branch` untuk membuat branch yang akan berisi perubahan yang mereka maksudkan untuk berkontribusi:
```bash
git branch [branch-name]
@ -233,23 +234,27 @@ Mari kita melalui alur kerja kontributor. Anggaplah kontributor telah _forked_ d
git commit -m "my changes"
```
Pastikan Anda memberikan nama commit yang baik, untuk kepentingan Anda sendiri maupun pemelihara repo yang Anda bantu.
Pastikan Anda memberikan nama commit yang baik, untuk kepentingan Anda serta pemelihara repo yang Anda bantu.
1. **Gabungkan pekerjaan Anda dengan branch `main`**. Pada suatu saat Anda selesai bekerja dan ingin menggabungkan pekerjaan Anda dengan branch `main`. Branch `main` mungkin telah berubah sementara itu, jadi pastikan Anda memperbaruinya terlebih dahulu dengan perintah berikut:
1. **Gabungkan pekerjaan Anda dengan branch `main`**. Pada suatu saat Anda selesai bekerja dan Anda ingin menggabungkan pekerjaan Anda dengan branch `main`. Branch `main` mungkin telah berubah sementara itu, jadi pastikan Anda terlebih dahulu memperbaruinya ke yang terbaru dengan perintah berikut:
```bash
git switch main
git pull
```
Pada titik ini Anda ingin memastikan bahwa setiap _conflict_, situasi di mana Git tidak dapat dengan mudah _combine_ perubahan, terjadi di branch kerja Anda. Oleh karena itu, jalankan perintah berikut:
Pada titik ini Anda ingin memastikan bahwa setiap _conflicts_, situasi di mana Git tidak dapat dengan mudah _menggabungkan_ perubahan terjadi di branch kerja Anda. Oleh karena itu jalankan perintah berikut:
```bash
git switch [branch_name]
git merge main
```
Ini akan membawa semua perubahan dari `main` ke branch Anda dan semoga Anda dapat melanjutkan. Jika tidak, VS Code akan memberi tahu Anda di mana Git _bingung_ dan Anda hanya perlu mengubah file yang terpengaruh untuk menentukan konten mana yang paling akurat.
Perintah `git merge main` akan membawa semua perubahan dari `main` ke branch Anda. Semoga Anda bisa langsung melanjutkan. Jika tidak, VS Code akan memberi tahu Anda di mana Git _bingung_ dan Anda hanya perlu mengubah file yang terpengaruh untuk mengatakan konten mana yang paling akurat.
Untuk beralih ke branch yang berbeda, gunakan perintah modern `git switch`:
```bash
git switch [branch_name]
1. **Kirim pekerjaan Anda ke GitHub**. Mengirim pekerjaan Anda ke GitHub berarti dua hal. Mendorong branch Anda ke repo Anda dan kemudian membuka PR, Pull Request.
@ -257,22 +262,22 @@ Mari kita melalui alur kerja kontributor. Anggaplah kontributor telah _forked_ d
git push --set-upstream origin [branch-name]
```
Perintah di atas membuat branch di repo forked Anda.
1. **Buka PR**. Selanjutnya, Anda ingin membuka PR. Anda melakukannya dengan menavigasi ke repo forked di GitHub. Anda akan melihat indikasi di GitHub di mana ia bertanya apakah Anda ingin membuat PR baru, Anda klik itu dan Anda dibawa ke antarmuka di mana Anda dapat mengubah judul pesan commit, memberikan deskripsi yang lebih sesuai. Sekarang pemelihara repo yang Anda forked akan melihat PR ini dan _semoga_ mereka akan menghargai dan _merge_ PR Anda. Anda sekarang adalah kontributor, yay :)
Perintah di atas membuat branch di repo yang telah Anda fork.
1. **Buka PR**. Selanjutnya, Anda ingin membuka PR. Caranya adalah dengan membuka repo forked di GitHub. Anda akan melihat indikasi di GitHub yang menanyakan apakah Anda ingin membuat PR baru, klik itu dan Anda akan diarahkan ke antarmuka di mana Anda dapat mengubah judul pesan commit, memberikan deskripsi yang lebih sesuai. Sekarang, pemilik repo yang Anda fork akan melihat PR ini dan _semoga_ mereka menghargai dan _menggabungkan_ PR Anda. Selamat, Anda sekarang menjadi kontributor, yay :)
1. **Bersihkan**. Dianggap sebagai praktik yang baik untuk _membersihkan_ setelah Anda berhasil menggabungkan PR. Anda ingin membersihkan branch lokal Anda dan branch yang Anda dorong ke GitHub. Pertama, hapus branch tersebut secara lokal dengan perintah berikut:
1. **Bersihkan**. Merupakan praktik yang baik untuk _membersihkan_ setelah Anda berhasil menggabungkan PR. Anda perlu membersihkan cabang lokal Anda dan cabang yang Anda dorong ke GitHub. Pertama, hapus cabang lokal dengan perintah berikut:
```bash
git branch -d [branch-name]
```
Pastikan Anda pergi ke halaman GitHub untuk repo forked dan hapus branch remote yang baru saja Anda dorong ke sana.
`Pull request` mungkin terdengar seperti istilah yang aneh karena sebenarnya Anda ingin mendorong perubahan Anda ke proyek. Namun, pemilik proyek (maintainer) atau tim inti perlu mempertimbangkan perubahan Anda sebelum menggabungkannya ke dalam cabang "main" proyek, jadi sebenarnya Anda meminta keputusan perubahan dari seorang maintainer.
Pastikan Anda pergi ke halaman GitHub untuk repo forked dan hapus cabang remote yang baru saja Anda dorong ke sana.
`Pull request` mungkin terdengar seperti istilah yang aneh karena sebenarnya Anda ingin mendorong perubahan Anda ke proyek. Namun, pemilik proyek atau tim inti perlu mempertimbangkan perubahan Anda sebelum menggabungkannya dengan cabang "utama" proyek, jadi Anda sebenarnya meminta keputusan perubahan dari pemilik proyek.
Pull request adalah tempat untuk membandingkan dan mendiskusikan perbedaan yang diperkenalkan pada sebuah cabang dengan ulasan, komentar, pengujian terintegrasi, dan lainnya. Pull request yang baik mengikuti aturan yang kurang lebih sama seperti pesan commit. Anda dapat menambahkan referensi ke sebuah issue di pelacak issue, misalnya ketika pekerjaan Anda memperbaiki sebuah issue. Ini dilakukan dengan menggunakan `#` diikuti oleh nomor issue Anda. Contohnya `#97`.
Pull request adalah tempat untuk membandingkan dan mendiskusikan perbedaan yang diperkenalkan pada cabang dengan ulasan, komentar, pengujian terintegrasi, dan lainnya. Pull request yang baik mengikuti aturan yang kurang lebih sama seperti pesan commit. Anda dapat menambahkan referensi ke sebuah isu di pelacak isu, misalnya ketika pekerjaan Anda memperbaiki sebuah isu. Ini dilakukan dengan menggunakan `#` diikuti oleh nomor isu Anda. Contohnya `#97`.
🤞Semoga semua pemeriksaan lulus dan pemilik proyek menggabungkan perubahan Anda ke dalam proyek🤞
🤞Semoga semua pemeriksaan berhasil dan pemilik proyek menggabungkan perubahan Anda ke dalam proyek🤞
Perbarui cabang kerja lokal Anda saat ini dengan semua commit baru dari cabang remote yang sesuai di GitHub:
@ -280,13 +285,13 @@ Perbarui cabang kerja lokal Anda saat ini dengan semua commit baru dari cabang r
## Cara berkontribusi ke open source
Pertama, mari temukan sebuah repositori (atau **repo**) di GitHub yang menarik bagi Anda dan ingin Anda kontribusikan perubahan. Anda perlu menyalin isinya ke komputer Anda.
Pertama, mari kita cari repositori (atau **repo**) di GitHub yang menarik bagi Anda dan ingin Anda kontribusikan perubahan. Anda perlu menyalin kontennya ke komputer Anda.
✅ Cara yang baik untuk menemukan repo yang 'ramah pemula' adalah dengan [mencari menggunakan tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Ada beberapa cara untuk menyalin kode. Salah satu caranya adalah dengan "mengkloning" isi repositori, menggunakan HTTPS, SSH, atau menggunakan GitHub CLI (Command Line Interface).
Ada beberapa cara untuk menyalin kode. Salah satu caranya adalah dengan "mengkloning" konten repositori, menggunakan HTTPS, SSH, atau menggunakan GitHub CLI (Command Line Interface).
Buka terminal Anda dan kloning repositori seperti ini:
`git clone https://github.com/ProjectURL`
@ -298,11 +303,11 @@ Anda juga dapat membuka seluruh proyek menggunakan [Codespaces](https://github.c
Terakhir, Anda dapat mengunduh kode dalam folder yang dikompresi (zip).
### Beberapa hal menarik lainnya tentang GitHub
### Beberapa hal menarik tentang GitHub
Anda dapat memberi bintang, mengikuti, dan/atau "fork" repositori publik apa pun di GitHub. Anda dapat menemukan repositori yang Anda beri bintang di menu drop-down kanan atas. Ini seperti menandai halaman, tetapi untuk kode.
Anda dapat memberi bintang, mengikuti, dan/atau "fork" repositori publik mana pun di GitHub. Anda dapat menemukan repositori yang Anda beri bintang di menu drop-down kanan atas. Ini seperti menandai halaman, tetapi untuk kode.
Proyek memiliki pelacak issue, biasanya di GitHub pada tab "Issues" kecuali dinyatakan lain, tempat orang-orang mendiskusikan masalah terkait proyek. Tab Pull Requests adalah tempat orang-orang mendiskusikan dan meninjau perubahan yang sedang berlangsung.
Proyek memiliki pelacak isu, biasanya di GitHub pada tab "Issues" kecuali dinyatakan lain, tempat orang-orang mendiskusikan masalah terkait proyek. Dan tab Pull Requests adalah tempat orang-orang mendiskusikan dan meninjau perubahan yang sedang berlangsung.
Proyek juga mungkin memiliki diskusi di forum, milis, atau saluran obrolan seperti Slack, Discord, atau IRC.
@ -310,16 +315,16 @@ Proyek juga mungkin memiliki diskusi di forum, milis, atau saluran obrolan seper
---
## 🚀 Tantangan
## 🚀 Tantangan
Bekerja sama dengan seorang teman untuk mengerjakan kode satu sama lain. Buat proyek secara kolaboratif, fork kode, buat cabang, dan gabungkan perubahan.
Bekerja sama dengan teman untuk mengerjakan kode satu sama lain. Buat proyek secara kolaboratif, fork kode, buat cabang, dan gabungkan perubahan.
## Kuis Setelah Kuliah
[Kuis setelah kuliah](https://ff-quizzes.netlify.app/web/en/)
@ -329,11 +334,11 @@ Latihan, latihan, latihan. GitHub memiliki jalur pembelajaran yang hebat yang te
Anda juga akan menemukan kursus yang lebih lanjut.
## Tugas
## Tugas
Selesaikan [kursus Minggu Pertama di GitHub](https://skills.github.com/#first-week-on-github)
---
**Penafian**:
Dokumen ini telah diterjemahkan menggunakan layanan penerjemahan AI [Co-op Translator](https://github.com/Azure/co-op-translator). Meskipun kami berusaha untuk memberikan hasil yang akurat, harap diingat bahwa terjemahan otomatis mungkin mengandung kesalahan atau ketidakakuratan. Dokumen asli dalam bahasa aslinya harus dianggap sebagai sumber yang otoritatif. Untuk informasi yang bersifat kritis, disarankan menggunakan jasa penerjemahan profesional oleh manusia. Kami tidak bertanggung jawab atas kesalahpahaman atau penafsiran yang keliru yang timbul dari penggunaan terjemahan ini.
Dokumen ini telah diterjemahkan menggunakan layanan penerjemahan AI [Co-op Translator](https://github.com/Azure/co-op-translator). Meskipun kami berupaya untuk memberikan hasil yang akurat, harap diketahui bahwa terjemahan otomatis mungkin mengandung kesalahan atau ketidakakuratan. Dokumen asli dalam bahasa aslinya harus dianggap sebagai sumber yang otoritatif. Untuk informasi yang bersifat kritis, disarankan menggunakan jasa penerjemahan manusia profesional. Kami tidak bertanggung jawab atas kesalahpahaman atau penafsiran yang keliru yang timbul dari penggunaan terjemahan ini.
@ -21,13 +21,13 @@ Questa lezione copre le basi di GitHub, una piattaforma per ospitare e gestire l
In questa lezione, tratteremo:
- come tracciare il lavoro che fai sul tuo computer
- il tracciamento del lavoro che fai sul tuo computer
- lavorare su progetti con altri
- come contribuire al software open source
### Prerequisiti
Prima di iniziare, devi verificare se Git è installato. Nel terminale digita:
Prima di iniziare, verifica se Git è installato. Nel terminale digita:
`git --version`
Se Git non è installato, [scarica Git](https://git-scm.com/downloads). Poi, configura il tuo profilo Git locale nel terminale:
@ -51,7 +51,7 @@ Avrai bisogno di una cartella con un progetto di codice sul tuo computer locale
## Gestione del codice
Supponiamo che tu abbia una cartella localmente con un progetto di codice e voglia iniziare a tracciare i tuoi progressi usando git, il sistema di controllo delle versioni. Alcuni paragonano l'uso di git a scrivere una lettera d'amore al tuo futuro io. Leggendo i tuoi messaggi di commit giorni, settimane o mesi dopo, sarai in grado di ricordare perché hai preso una decisione o "annullare" una modifica, ovviamente se scrivi buoni "messaggi di commit".
Supponiamo che tu abbia una cartella localmente con un progetto di codice e voglia iniziare a tracciare i tuoi progressi usando git, il sistema di controllo delle versioni. Alcuni paragonano l'uso di git a scrivere una lettera d'amore al tuo futuro io. Leggendo i tuoi messaggi di commit giorni, settimane o mesi dopo, sarai in grado di ricordare perché hai preso una decisione o "annullare" una modifica, ovvero quando scrivi buoni "messaggi di commit".
### Compito: Crea un repository e fai il commit del codice
@ -61,7 +61,7 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
1. **Crea un repository su GitHub**. Su GitHub.com, nella scheda dei repository o dalla barra di navigazione in alto a destra, trova il pulsante **new repo**.
1. Dai un nome al tuo repository (cartella).
1. Dai un nome al tuo repository (cartella)
1. Seleziona **create repository**.
1. **Naviga nella tua cartella di lavoro**. Nel terminale, passa alla cartella (nota anche come directory) che vuoi iniziare a tracciare. Digita:
@ -82,7 +82,7 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
git status
```
l'output potrebbe essere simile a questo:
l'output potrebbe apparire simile a questo:
```output
Changes not staged for commit:
@ -93,10 +93,10 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
modified: file2.txt
```
Tipicamente, il comando `git status` ti dice cose come quali file sono pronti per essere _salvati_ nel repository o hanno modifiche che potresti voler rendere permanenti.
Tipicamente, il comando `git status` ti dice cose come quali file sono pronti per essere _salvati_ nel repository o hanno modifiche che potresti voler rendere persistenti.
1. **Aggiungi tutti i file per il tracciamento**
Questo è anche chiamato "staging" dei file o aggiunta dei file all'area di staging.
Questo è anche chiamato staging dei file/aggiunta dei file all'area di staging.
```bash
git add .
@ -118,7 +118,7 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
git reset
```
Questo comando ci aiuta a rimuovere tutti i file dall'area di staging in una volta sola.
Questo comando ci aiuta a rimuovere tutti i file dall'area di staging contemporaneamente.
1. **Rimuovi un file specifico dall'area di staging**
@ -128,13 +128,13 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
Questo comando ci aiuta a rimuovere solo un file specifico dall'area di staging che non vogliamo includere nel prossimo commit.
1. **Rendi permanente il tuo lavoro**. A questo punto hai aggiunto i file a una cosiddetta _area di staging_. Un luogo dove Git sta tracciando i tuoi file. Per rendere la modifica permanente, devi fare il _commit_ dei file. Per farlo, crei un _commit_ con il comando `git commit`. Un _commit_ rappresenta un punto di salvataggio nella storia del tuo repository. Digita il seguente comando per creare un _commit_:
1. **Rendi persistente il tuo lavoro**. A questo punto hai aggiunto i file a una cosiddetta _area di staging_. Un luogo dove Git sta tracciando i tuoi file. Per rendere la modifica permanente, devi _committare_ i file. Per farlo, crei un _commit_ con il comando `git commit`. Un _commit_ rappresenta un punto di salvataggio nella storia del tuo repository. Digita il seguente comando per creare un _commit_:
```bash
git commit -m "first commit"
```
Questo fa il commit di tutti i tuoi file, aggiungendo il messaggio "first commit". Per i futuri messaggi di commit, vorrai essere più descrittivo per trasmettere il tipo di modifica che hai fatto.
Questo committa tutti i tuoi file, aggiungendo il messaggio "first commit". Per i futuri messaggi di commit, vorrai essere più descrittivo nella tua descrizione per trasmettere il tipo di modifica che hai fatto.
1. **Collega il tuo repository Git locale con GitHub**. Un repository Git è utile sul tuo computer, ma a un certo punto vorrai avere un backup dei tuoi file da qualche parte e anche invitare altre persone a lavorare con te sul tuo repository. Un ottimo posto per farlo è GitHub. Ricorda che abbiamo già creato un repository su GitHub, quindi l'unica cosa che dobbiamo fare è collegare il nostro repository Git locale con GitHub. Il comando `git remote add` farà proprio questo. Digita il seguente comando:
@ -144,19 +144,19 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
Questo crea una _connessione remota_, chiamata "origin", che punta al repository GitHub che hai creato in precedenza.
Questo crea un_remote_, o connessione, chiamato "origin" che punta al repository GitHub che hai creato in precedenza.
1. **Invia i file locali a GitHub**. Finora hai creato una _connessione_ tra il repository locale e il repository GitHub. Inviamo questi file a GitHub con il seguente comando `git push`, come segue:
> Nota, il nome del tuo branch potrebbe essere diverso di default da ```main```.
> Nota, il nome del tuo branch potrebbe essere diverso da ```main```.
```bash
git push -u origin main
```
Questo invia i tuoi commit nel branch "main" a GitHub.
Questo invia i tuoi commit nel branch "main" a GitHub. Impostare il branch `upstream` includendo `-u` nel comando stabilisce un collegamento tra il tuo branch locale e il branch remoto, così puoi semplicemente usare git push o git pull senza specificare il nome del branch in futuro. Git utilizzerà automaticamente il branch upstream e non dovrai specificare esplicitamente il nome del branch nei comandi futuri.
2. **Aggiungi altre modifiche**. Se vuoi continuare a fare modifiche e inviarle a GitHub, dovrai solo usare i seguenti tre comandi:
2. **Per aggiungere altre modifiche**. Se vuoi continuare a fare modifiche e inviarle a GitHub, dovrai solo usare i seguenti tre comandi:
```bash
git add .
@ -164,19 +164,19 @@ Supponiamo che tu abbia una cartella localmente con un progetto di codice e vogl
git push
```
> Suggerimento, potresti anche voler adottare un file `.gitignore` per evitare che file che non vuoi tracciare appaiano su GitHub - come quel file di appunti che conservi nella stessa cartella ma che non ha posto in un repository pubblico. Puoi trovare modelli per file `.gitignore` su [.gitignore templates](https://github.com/github/gitignore).
> Suggerimento, potresti anche voler adottare un file `.gitignore` per evitare che i file che non vuoi tracciare compaiano su GitHub, come quel file di note che conservi nella stessa cartella ma che non ha posto in un repository pubblico. Puoi trovare modelli per i file `.gitignore` su [.gitignore templates](https://github.com/github/gitignore).
#### Messaggi di commit
Un ottimo messaggio di commit completa la seguente frase:
Se applicato, questo commit farà <il tuo messaggioqui>
Se applicato, questo commit <tuo messaggioqui>
Per il soggetto usa il tempo presente imperativo: "modifica" non "modificato" né "modifiche".
Come nel soggetto, anche nel corpo (opzionale) usa il tempo presente imperativo. Il corpo dovrebbe includere la motivazione per la modifica e confrontarla con il comportamento precedente. Stai spiegando il `perché`, non il `come`.
✅ Prenditi qualche minuto per navigare su GitHub. Riesci a trovare un messaggio di commit davvero ottimo? Riesci a trovarne uno davvero minimale? Quali informazioni pensi siano le più importanti e utili da trasmettere in un messaggio di commit?
### Compito: Collabora
### Compito: Collaborare
Il motivo principale per mettere le cose su GitHub è rendere possibile collaborare con altri sviluppatori.
@ -192,21 +192,21 @@ Nel tuo repository, vai su `Insights > Community` per vedere come il tuo progett
- **Descrizione**. Hai aggiunto una descrizione per il tuo progetto?
- **README**. Hai aggiunto un README? GitHub fornisce indicazioni per scrivere un [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Linee guida per i contributi**. Il tuo progetto ha [linee guida per i contributi](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Codice di condotta**. Un [Codice di Condotta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licenza**. Forse più importante, una [licenza](https://docs.github.com/articles/adding-a-license-to-a-repository/).
- **Codice di condotta**. Un [Codice di Condotta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Licenza**. Forse più importante, una [licenza](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Tutte queste risorse saranno utili per integrare nuovi membri del team. E sono tipicamente il tipo di cose che i nuovi contributori guardano prima ancora di guardare il tuo codice, per capire se il tuo progetto è il posto giusto per loro.
Tutte queste risorse saranno utili per integrare nuovi membri del team. E sono tipicamente il tipo di cose che i nuovi contributori guardano prima ancora di esaminare il tuo codice, per capire se il tuo progetto è il posto giusto dove spendere il loro tempo.
✅ I file README, anche se richiedono tempo per essere preparati, sono spesso trascurati dai manutentori impegnati. Riesci a trovare un esempio di uno particolarmente descrittivo? Nota: ci sono alcuni [strumenti per aiutare a creare buoni README](https://www.makeareadme.com/) che potresti voler provare.
### Compito: Unisci del codice
### Compito: Unire del codice
I documenti sui contributi aiutano le persone a contribuire al progetto. Spiegano quali tipi di contributi stai cercando e come funziona il processo. I contributori dovranno seguire una serie di passaggi per poter contribuire al tuo repository su GitHub:
I documenti di contributo aiutano le persone a contribuire al progetto. Spiegano quali tipi di contributi stai cercando e come funziona il processo. I contributori dovranno seguire una serie di passaggi per poter contribuire al tuo repository su GitHub:
1. **Fork del tuo repository**. Probabilmente vorrai che le persone _forkino_ il tuo progetto. Forkare significa creare una replica del tuo repository sul loro profilo GitHub.
1. **Clona**. Da lì cloneranno il progetto sul loro computer locale.
1. **Crea un branch**. Vorrai chiedere loro di creare un _branch_ per il loro lavoro.
1. **Concentrati su un'area specifica**. Chiedi ai contributori di concentrarsi su un'area alla volta - in questo modo le possibilità che tu possa _unire_ il loro lavoro sono più alte. Immagina che scrivano una correzione di bug, aggiungano una nuova funzionalità e aggiornino diversi test - cosa succede se vuoi, o puoi implementare solo 2 su 3, o 1 su 3 modifiche?
1. **Clonare**. Da lì cloneranno il progetto sul loro computer locale.
1. **Creare un branch**. Vorrai chiedere loro di creare un _branch_ per il loro lavoro.
1. **Concentrarsi su un'area**. Chiedi ai contributori di concentrarsi su un contributo alla volta: in questo modo le possibilità che tu possa _unire_ il loro lavoro sono più alte. Immagina che scrivano una correzione di bug, aggiungano una nuova funzionalità e aggiornino diversi test: cosa succede se vuoi, o puoi implementare solo 2 su 3, o 1 su 3 modifiche?
✅ Immagina una situazione in cui i branch sono particolarmente critici per scrivere e distribuire buon codice. Quali casi d'uso ti vengono in mente?
@ -214,28 +214,28 @@ I documenti sui contributi aiutano le persone a contribuire al progetto. Spiegan
Passiamo attraverso un flusso di lavoro per i contributori. Supponiamo che il contributore abbia già _forkato_ e _clonato_ il repository, quindi ha un repository Git pronto per essere lavorato sul suo computer locale:
1. **Crea un branch**. Usa il comando `git branch` per creare un branch che conterrà le modifiche che intende contribuire:
1. **Creare un branch**. Usa il comando `git branch` per creare un branch che conterrà le modifiche che intende contribuire:
```bash
git branch [branch-name]
```
1. **Passa al branch di lavoro**. Passa al branch specificato e aggiorna la directory di lavoro con `git switch`:
1. **Passare al branch di lavoro**. Passa al branch specificato e aggiorna la directory di lavoro con `git switch`:
```bash
git switch [branch-name]
```
1. **Lavora**. A questo punto vuoi aggiungere le tue modifiche. Non dimenticare di dirlo a Git con i seguenti comandi:
1. **Lavorare**. A questo punto vuoi aggiungere le tue modifiche. Non dimenticare di comunicarlo a Git con i seguenti comandi:
```bash
git add .
git commit -m "my changes"
```
Assicurati di dare al tuo commit un buon nome, per il tuo bene e per il manutentore del repository che stai aiutando.
Assicurati di dare al tuo commit un buon nome, per il tuo bene e per quello del manutentore del repository a cui stai contribuendo.
1. **Combina il tuo lavoro con il branch `main`**. A un certo punto hai finito di lavorare e vuoi combinare il tuo lavoro con quello del branch `main`. Il branch `main` potrebbe essere cambiato nel frattempo, quindi assicurati di aggiornarlo prima con i seguenti comandi:
1. **Combinare il tuo lavoro con il branch `main`**. A un certo punto hai finito di lavorare e vuoi combinare il tuo lavoro con quello del branch `main`. Il branch `main` potrebbe essere cambiato nel frattempo, quindi assicurati prima di aggiornarlo con i seguenti comandi:
```bash
git switch main
@ -249,32 +249,37 @@ Passiamo attraverso un flusso di lavoro per i contributori. Supponiamo che il co
git merge main
```
Questo porterà tutte le modifiche da `main` nel tuo branch e, si spera, potrai semplicemente continuare. Se no, VS Code ti dirà dove Git è _confuso_ e tu altererai i file interessati per indicare quale contenuto è il più accurato.
Il comando `git merge main` porterà tutte le modifiche da `main` nel tuo branch. Si spera che tu possa semplicemente continuare. In caso contrario, VS Code ti dirà dove Git è _confuso_ e tu altererai i file interessati per indicare quale contenuto è il più accurato.
Per passare a un branch diverso, usa il moderno comando `git switch`:
```bash
git switch [branch_name]
1. **Invia il tuo lavoro a GitHub**. Inviare il tuo lavoro a GitHub significa due cose. Pushing del tuo branch al tuo repository e poi aprire una PR, Pull Request.
1. **Inviare il tuo lavoro a GitHub**. Inviare il tuo lavoro a GitHub significa due cose: spingere il tuo branch al tuo repository e poi aprire una PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Il comando sopra crea il branch sul tuo repository forkato.
1. **Apri una PR**. Successivamente, vuoi aprire una PR. Lo fai navigando nel repository forkato su GitHub. Vedrai un'indicazione su GitHub che ti chiede se vuoi creare una nuova PR, clicca su di essa e sarai portato a un'interfaccia dove puoi modificare il titolo del messaggio di commit, dare una descrizione più adatta. Ora il manutentore del repository che hai forkato vedrà questa PR e _incrociamo le dita_ apprezzerà e _unirà_ la tua PR. Ora sei un contributore, yay :)
Il comando sopra crea il branch nel tuo repository forkato.
1. **Apri una PR**. Successivamente, vuoi aprire una PR. Per farlo, vai al repository forkato su GitHub. Vedrai un'indicazione su GitHub che ti chiede se vuoi creare una nuova PR; clicca su quella e verrai portato a un'interfaccia dove puoi modificare il titolo del messaggio di commit e fornire una descrizione più adatta. Ora il manutentore del repository che hai forkato vedrà questa PR e _incrociamo le dita_ apprezzerà e _unirà_ la tua PR. Ora sei un collaboratore, evviva :)
1. **Pulisci**. È considerata una buona pratica _pulire_ dopo aver unito con successo una PR. Vuoi pulire sia il tuo branch locale che il branch che hai inviato a GitHub. Per prima cosa, eliminiamolo localmente con il seguente comando:
1. **Pulizia**. È considerata una buona pratica _fare pulizia_ dopo aver unito con successo una PR. Vuoi pulire sia il tuo branch locale che il branch che hai caricato su GitHub. Per prima cosa, eliminiamolo localmente con il seguente comando:
```bash
git branch -d [branch-name]
```
Assicurati di andare alla pagina GitHub del repository forkato e rimuovere il branch remoto che hai appena caricato.
Assicurati di andare alla pagina GitHub del repository forkato e rimuovere il branch remoto che hai appena inviato.
`Pull request` sembra un termine strano perché in realtà vuoi "spingere" le tue modifiche nel progetto. Ma il manutentore (proprietario del progetto) o il team principale deve valutare le tue modifiche prima di unirle al branch "main" del progetto, quindi stai davvero richiedendo una decisione di modifica da parte di un manutentore.
`Pull request` sembra un termine strano perché in realtà vuoi spingere le tue modifiche nel progetto. Ma il manutentore (proprietario del progetto) o il team principale deve considerare le tue modifiche prima di unirle al branch "main" del progetto, quindi stai davvero richiedendo una decisione di modifica da parte di un manutentore.
Una pull request è il luogo in cui confrontare e discutere le differenze introdotte in un branch con revisioni, commenti, test integrati e altro. Una buona pull request segue più o meno le stesse regole di un messaggio di commit. Puoi aggiungere un riferimento a un problema nel tracker dei problemi, ad esempio quando il tuo lavoro risolve un problema. Questo si fa utilizzando un `#` seguito dal numero del problema. Ad esempio `#97`.
Una pull request è il luogo in cui confrontare e discutere le differenze introdotte in un branch con revisioni, commenti, test integrati e altro. Una buona pull request segue più o meno le stesse regole di un messaggio di commit. Puoi aggiungere un riferimento a un problema nel tracker degli issue, ad esempio quando il tuo lavoro risolve un problema. Questo si fa usando un `#` seguito dal numero del problema. Ad esempio `#97`.
🤞Incrociamo le dita che tutti i controlli passino e che il/i proprietario/i del progetto uniscano le tue modifiche nel progetto🤞
Aggiorna il tuo branch locale di lavoro con tutti i nuovi commit dal branch remoto corrispondente su GitHub:
Aggiorna il tuo branch di lavoro locale corrente con tutti i nuovi commit dal branch remoto corrispondente su GitHub:
`git pull`
@ -282,16 +287,16 @@ Aggiorna il tuo branch locale di lavoro con tutti i nuovi commit dal branch remo
Per prima cosa, troviamo un repository (o **repo**) su GitHub che ti interessa e al quale vorresti contribuire con una modifica. Vorrai copiarne il contenuto sulla tua macchina.
✅ Un buon modo per trovare repository "adatti ai principianti" è [cercare con il tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Un buon modo per trovare repository 'adatti ai principianti' è [cercare con il tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Ci sono diversi modi per copiare il codice. Un modo è "clonare" il contenuto del repository, utilizzando HTTPS, SSH o la GitHub CLI (Command Line Interface).
Ci sono diversi modi per copiare il codice. Un modo è "clonare" il contenuto del repository, utilizzando HTTPS, SSH o il GitHub CLI (Command Line Interface).
Apri il terminale e clona il repository in questo modo:
Apri il terminale e clona il repository in questo modo:
`git clone https://github.com/ProjectURL`
Per lavorare sul progetto, passa alla cartella corretta:
Per lavorare sul progetto, passa alla cartella corretta:
`cd ProjectURL`
Puoi anche aprire l'intero progetto utilizzando [Codespaces](https://github.com/features/codespaces), l'editor di codice integrato / ambiente di sviluppo cloud di GitHub, o [GitHub Desktop](https://desktop.github.com/).
@ -300,28 +305,28 @@ Infine, puoi scaricare il codice in una cartella compressa.
### Alcune cose interessanti su GitHub
Puoi aggiungere una stella, seguire e/o "forkare" qualsiasi repository pubblico su GitHub. Puoi trovare i tuoi repository con stella nel menu a tendina in alto a destra. È come salvare nei segnalibri, ma per il codice.
Puoi mettere una stella, seguire e/o "forkare" qualsiasi repository pubblico su GitHub. Puoi trovare i tuoi repository con stella nel menu a tendina in alto a destra. È come salvare nei segnalibri, ma per il codice.
I progetti hanno un tracker dei problemi, per lo più su GitHub nella scheda "Issues" a meno che non sia indicato diversamente, dove le persone discutono dei problemi relativi al progetto. E la scheda Pull Requests è dove le persone discutono e revisionano le modifiche in corso.
I progetti hanno un tracker degli issue, per lo più su GitHub nella scheda "Issues" a meno che non sia indicato diversamente, dove le persone discutono dei problemi relativi al progetto. E la scheda Pull Requests è dove le persone discutono e revisionano le modifiche in corso.
I progetti potrebbero anche avere discussioni in forum, mailing list o canali di chat come Slack, Discord o IRC.
✅ Dai un'occhiata al tuo nuovo repository GitHub e prova alcune cose, come modificare le impostazioni, aggiungere informazioni al tuo repo e creare un progetto (come una bacheca Kanban). C'è molto che puoi fare!
✅ Dai un'occhiata al tuo nuovo repository GitHub e prova alcune cose, come modificare le impostazioni, aggiungere informazioni al tuo repository e creare un progetto (come una bacheca Kanban). C'è molto che puoi fare!
---
## 🚀 Sfida
Lavora in coppia con un amico sul codice di ciascuno. Crea un progetto collaborativo, fork del codice, crea branch e unisci modifiche.
Lavora in coppia con un amico sul codice di ciascuno. Create un progetto collaborativo, forkate il codice, create branch e unite le modifiche.
Completa [il corso Prima settimana su GitHub](https://skills.github.com/#first-week-on-github)
---
**Disclaimer**:
Questo documento è stato tradotto utilizzando il servizio di traduzione automatica [Co-op Translator](https://github.com/Azure/co-op-translator). Sebbene ci impegniamo per garantire l'accuratezza, si prega di notare che le traduzioni automatiche possono contenere errori o imprecisioni. Il documento originale nella sua lingua nativa dovrebbe essere considerato la fonte autorevole. Per informazioni critiche, si raccomanda una traduzione professionale effettuata da un traduttore umano. Non siamo responsabili per eventuali incomprensioni o interpretazioni errate derivanti dall'uso di questa traduzione.
**Disclaimer (Avvertenza)**:
Questo documento è stato tradotto utilizzando il servizio di traduzione automatica [Co-op Translator](https://github.com/Azure/co-op-translator). Sebbene ci impegniamo per garantire l'accuratezza, si prega di notare che le traduzioni automatiche possono contenere errori o imprecisioni. Il documento originale nella sua lingua nativa dovrebbe essere considerato la fonte autorevole. Per informazioni critiche, si raccomanda una traduzione professionale effettuata da un esperto umano. Non siamo responsabili per eventuali incomprensioni o interpretazioni errate derivanti dall'uso di questa traduzione.
Git이 설치되어 있지 않다면, [Git 다운로드](https://git-scm.com/downloads) 페이지에서 설치하세요. 그런 다음 터미널에서 로컬 Git 프로필을 설정하세요:
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`
또한 GitHub 계정, 코드 편집기(예: Visual Studio Code), 터미널(또는 명령 프롬프트)이 필요합니다.
또한 GitHub 계정, 코드 편집기(예: Visual Studio Code), 그리고 터미널(또는 명령 프롬프트)을 열어야 합니다.
[github.com](https://github.com/)으로 이동하여 계정을 생성하거나 로그인한 후 프로필을 작성하세요.
[github.com](https://github.com/)으로 이동하여 계정을 생성하거나 로그인하고 프로필을 작성하세요.
✅ GitHub는 세상에 존재하는 유일한 코드 저장소가 아닙니다. 다른 저장소도 있지만, GitHub가 가장 잘 알려져 있습니다.
✅ GitHub는 세계에서 유일한 코드 저장소가 아닙니다. 다른 저장소도 있지만 GitHub가 가장 잘 알려져 있습니다.
### 준비
로컬 컴퓨터(노트북 또는 PC)에 코드 프로젝트가 포함된 폴더와 GitHub에 있는 공개 저장소가 필요합니다. 이 저장소는 다른 사람들의 프로젝트에 기여하는 방법을 배우는 예제로 사용됩니다.
로컬 컴퓨터(노트북 또는 PC)에 코드 프로젝트가 있는 폴더와 GitHub의 공개 저장소가 필요합니다. 이는 다른 사람들의 프로젝트에 기여하는 방법을 보여주는 예제로 사용됩니다.
---
## 코드 관리
로컬에 코드 프로젝트가 포함된 폴더가 있다고 가정해 봅시다. 이 폴더에서 Git(버전 관리 시스템)을 사용하여 작업 진행 상황을 추적하고 싶습니다. Git을 사용하는 것은 미래의 자신에게 사랑의 편지를 쓰는 것과 같다고 비유되곤 합니다. 며칠, 몇 주, 몇 달 후에 커밋 메시지를 읽으면 왜 특정 결정을 내렸는지 기억하거나 변경 사항을 "롤백"할 수 있습니다. 단, 좋은 "커밋 메시지"를 작성했을 때만 가능합니다.
로컬에 코드 프로젝트가 있는 폴더가 있다고 가정하고, Git이라는 버전 관리 시스템을 사용하여 진행 상황을 추적하고 싶다고 해봅시다. 일부 사람들은 Git을 사용하는 것을 미래의 자신에게 사랑의 편지를 쓰는 것에 비유합니다. 커밋 메시지를 읽으면 며칠, 몇 주, 몇 달 후에도 왜 특정 결정을 내렸는지 기억할 수 있으며, 변경 사항을 "롤백"할 수도 있습니다. 단, 좋은 "커밋 메시지"를 작성했을 경우에만 가능합니다.
### 작업: 저장소 생성 및 코드 커밋
> 동영상 확인하기
> 비디오 확인하기
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub에서 저장소 생성**. GitHub.com에서 저장소 탭 또는 오른쪽 상단의 탐색 바에서 **새 저장소** 버튼을 찾으세요.
1. 저장소(폴더)에 이름을 지정하세요.
1. **저장소 생성**을 선택하세요.
@ -82,7 +81,7 @@ Git이 이미 설정되어 있는지 확인하려면 다음을 입력하세요:
git status
```
출력은 다음과 비슷할 수 있습니다:
출력은 다음과 같을 수 있습니다:
```output
Changes not staged for commit:
@ -95,16 +94,16 @@ Git이 이미 설정되어 있는지 확인하려면 다음을 입력하세요:
일반적으로 `git status` 명령은 저장소에 _저장_할 준비가 된 파일이나 변경 사항이 있는 파일을 알려줍니다.
1. **추적할 모든 파일 추가**
이는 파일을 스테이징 영역에 추가하는 작업으로도 불립니다.
1. **추적할 모든 파일 추가**
이는 파일을 스테이징 영역에 추가하는 것으로도 불립니다.
```bash
git add .
```
`git add`와 `.` 인수는 모든 파일 및 변경 사항을 추적하도록 지정합니다.
`git add`와 `.` 인수는 추적할 모든 파일과 변경 사항을 나타냅니다.
1. **선택한 파일만 추가**
1. **선택한 파일만 추가**
```bash
git add [file or folder name]
@ -112,51 +111,51 @@ Git이 이미 설정되어 있는지 확인하려면 다음을 입력하세요:
이는 모든 파일을 한 번에 커밋하지 않고 선택한 파일만 스테이징 영역에 추가할 때 유용합니다.
1. **모든 파일 스테이징 해제**
1. **모든 파일 스테이징 취소**
```bash
git reset
```
이 명령은 한 번에 모든 파일의 스테이징을 해제하는 데 유용합니다.
이 명령은 한 번에 모든 파일의 스테이징을 취소하는 데 도움이 됩니다.
1. **특정 파일 스테이징 해제**
1. **특정 파일 스테이징 취소**
```bash
git reset [file or folder name]
```
이 명령은 특정 파일만 스테이징 해제하려는 경우에 유용합니다.
이 명령은 특정 파일만 스테이징에서 제외하는 데 도움이 됩니다.
1. **작업 저장**. 이 시점에서 파일을 _스테이징 영역_에 추가했습니다. Git이 파일을 추적하고 있는 상태입니다. 변경 사항을 영구적으로 저장하려면 파일을 _커밋_해야 합니다. `git commit` 명령을 사용하여 _커밋_을 생성하세요. 커밋은 저장소의 기록에서 저장 지점을 나타냅니다. 다음을 입력하여 _커밋_을 생성하세요:
1. **작업 저장**. 이 시점에서 파일을 _스테이징 영역_에 추가했습니다. Git이 파일을 추적하는 장소입니다. 변경 사항을 영구적으로 저장하려면 파일을 _커밋_해야 합니다. 이를 위해 `git commit` 명령을 사용하여 _커밋_을 생성합니다. _커밋_은 저장소의 히스토리에서 저장 지점을 나타냅니다. 다음을 입력하여 _커밋_을 생성하세요:
```bash
git commit -m "first commit"
```
이는 "첫 번째 커밋"이라는 메시지와 함께 모든 파일을 커밋합니다. 이후 커밋 메시지에서는 변경 사항의 유형을 전달할 수 있도록 더 구체적인 설명을 작성하는 것이 좋습니다.
이는 모든 파일을 커밋하며, 메시지 "first commit"을 추가합니다. 이후 커밋 메시지에서는 변경 유형을 전달하기 위해 더 구체적인 설명을 작성하는 것이 좋습니다.
1. **로컬 Git 저장소를 GitHub와 연결**. 로컬 Git 저장소는 유용하지만, 파일을 백업하거나 다른 사람들과 협업하려면 GitHub와 연결해야 합니다. `git remote add` 명령을 사용하여 이를 수행할 수 있습니다. 다음 명령을 입력하세요:
1. **로컬 Git 저장소를 GitHub와 연결**. Git 저장소는 로컬 컴퓨터에서 유용하지만, 파일 백업을 원하거나 다른 사람들을 초대하여 저장소에서 작업하도록 하려면 GitHub와 연결해야 합니다. 이미 GitHub에서 저장소를 생성했으므로 로컬 Git 저장소를 GitHub와 연결하기만 하면 됩니다. `git remote add` 명령이 이를 수행합니다. 다음 명령을 입력하세요:
> 명령을 입력하기 전에 GitHub 저장소 페이지로 이동하여 저장소 URL을 찾으세요. 아래 명령에서 ```https://github.com/username/repository_name.git```를 GitHub URL로 바꾸세요.
> 명령을 입력하기 전에 GitHub 저장소 페이지로 이동하여 저장소 URL을 찾으세요. 아래 명령에서 ```https://github.com/username/repository_name.git```을 GitHub URL로 바꾸세요.
이는 "origin"이라는 이름의 _원격_ 연결을 생성하며, 이는 이전에 생성한 GitHub 저장소를 가리킵니다.
이는 "origin"이라는 이름의 _원격_ 연결을 생성하며, 이전에 생성한 GitHub 저장소를 가리킵니다.
1. **로컬 파일을 GitHub로 전송**. 지금까지 로컬 저장소와 GitHub 저장소 간의 _연결_을 생성했습니다. 이제 다음 명령 `git push`를 사용하여 파일을 GitHub로 전송하세요:
> 기본 브랜치 이름이 ```main```와 다를 수 있습니다.
> 기본 브랜치 이름이 ```main```과 다를 수 있습니다.
```bash
git push -u origin main
```
이는 "main" 브랜치의 커밋을 GitHub로 전송합니다.
이는 "main" 브랜치의 커밋을 GitHub로 전송합니다.`-u`를 포함한 `upstream` 브랜치를 설정하면 로컬 브랜치와 원격 브랜치 간의 링크가 설정되어 이후에는 브랜치 이름을 명시하지 않고도 git push 또는 git pull을 사용할 수 있습니다. Git은 자동으로 upstream 브랜치를 사용하며, 이후 명령에서 브랜치 이름을 명시할 필요가 없습니다.
2. **추가 변경 사항 추가**. 계속해서 변경 사항을 만들고 이를 GitHub로 푸시하려면 다음 세 가지 명령만 사용하면 됩니다:
2. **추가 변경 사항 추가**. 변경 사항을 계속 추가하고 GitHub로 푸시하려면 다음 세 가지 명령을 사용하면 됩니다:
```bash
git add .
@ -164,129 +163,134 @@ Git이 이미 설정되어 있는지 확인하려면 다음을 입력하세요:
git push
```
> 팁: `.gitignore` 파일을 사용하여 GitHub에 추적되지 않도록 하고 싶은 파일(예: 공개 저장소에 포함되지 않아야 하는 메모 파일)을 제외할 수도 있습니다. `.gitignore` 파일 템플릿은 [.gitignore templates](https://github.com/github/gitignore)에서 찾을 수 있습니다.
> 팁, `.gitignore` 파일을 사용하여 추적하지 않으려는 파일이 GitHub에 표시되지 않도록 할 수도 있습니다. 예를 들어, 같은 폴더에 저장된 메모 파일이 있지만 공개 저장소에는 적합하지 않은 경우입니다. `.gitignore` 파일 템플릿은 [.gitignore templates](https://github.com/github/gitignore)에서 찾을 수 있습니다.
#### 커밋 메시지
훌륭한 Git 커밋 제목은 다음 문장을 완성합니다:
"적용된다면, 이 커밋은 <여기에 제목 입력>을 수행합니다."
"이 커밋이 적용되면 <여기에 제목 입력>"
제목에서는 명령형 현재 시제를 사용하세요: "변경" (changed나 changes가 아님).
본문(선택 사항)에서도 명령형 현재 시제를 사용하세요. 본문에는 변경 사항의 동기를 포함하고 이전 동작과의 차이를 설명하세요. `어떻게`가 아니라 `왜`를 설명하는 것입니다.
제목에서는 명령형 현재 시제를 사용하세요: "변경"이 아니라 "변경됨" 또는 "변경 중"이 아닙니다.
제목과 마찬가지로 본문(선택 사항)에서도 명령형 현재 시제를 사용하세요. 본문에는 변경 이유를 포함하고 이전 동작과 대조하여 설명하세요. `왜`를 설명하는 것이지, `어떻게`를 설명하는 것이 아닙니다.
✅ GitHub를 몇 분 동안 둘러보세요. 정말 훌륭한 커밋 메시지를 찾을 수 있나요? 정말 간단한 메시지는요? 커밋 메시지에서 가장 중요하고 유용한 정보는 무엇이라고 생각하나요?
✅ GitHub를 잠시 둘러보세요. 정말 훌륭한 커밋 메시지를 찾을 수 있나요? 정말 간단한 메시지를 찾을 수 있나요? 커밋 메시지에서 가장 중요하고 유용한 정보는 무엇이라고 생각하나요?
### 작업: 협업하기
GitHub에 파일을 올리는 주된 이유는 다른 개발자들과 협업할 수 있도록 하기 위함입니다.
GitHub에 파일을 올리는 주요 이유는 다른 개발자들과 협업할 수 있도록 하기 위함입니다.
## 다른 사람들과 프로젝트 작업하기
> 동영상 확인하기
> 비디오 확인하기
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
저장소에서 `Insights > Community`로 이동하여 프로젝트가 권장 커뮤니티 표준과 어떻게 비교되는지 확인하세요.
- **라이선스**. 아마도 가장 중요한 [라이선스](https://docs.github.com/articles/adding-a-license-to-a-repository/)가 있나요?
이 모든 리소스는 새로운 팀원을 온보딩하는 데 유용합니다. 새로운 기여자들은 일반적으로 코드를 보기 전에 이러한 리소스를 확인하여 프로젝트가 자신이 시간을 투자할 가치가 있는 곳인지 판단합니다.
이 모든 리소스는 새로운 팀원을 온보딩하는 데 도움이 됩니다. 이는 일반적으로 새로운 기여자가 코드를 보기 전에 프로젝트가 자신이 시간을 투자할 가치가 있는 곳인지 확인하기 위해 살펴보는 것들입니다.
✅ README 파일은 준비하는 데 시간이 걸리지만, 바쁜 유지 관리자가 종종 간과합니다. 특히 설명이 잘 된 README의 예를 찾을 수 있나요? 참고로, [좋은 README를 작성하는 데 도움이 되는 도구](https://www.makeareadme.com/)도 있습니다.
✅ README 파일은 준비하는 데 시간이 걸리지만 바쁜 유지 관리자가 종종 간과합니다. 특히 설명이 잘 된 README의 예를 찾을 수 있나요? 참고: [좋은 README를 만드는 데 도움이 되는 도구](https://www.makeareadme.com/)가 있으니 사용해보세요.
### 작업: 코드 병합하기
기여 문서는 사람들이 프로젝트에 기여할 수 있도록 돕습니다. 기여 문서에는 어떤 유형의 기여를 원하는지, 프로세스가 어떻게 진행되는지 설명합니다. 기여자는 GitHub 저장소에 기여하기 위해 일련의 단계를 거쳐야 합니다:
기여 문서는 사람들이 프로젝트에 기여하는 데 도움을 줍니다. 어떤 유형의 기여를 원하는지와 프로세스가 어떻게 작동하는지 설명합니다. 기여자는 GitHub에서 저장소에 기여하기 위해 일련의 단계를 거쳐야 합니다:
1. **저장소 포크**. 기여자는 프로젝트를 _포크_해야 합니다. 포크는 자신의 GitHub 프로필에 저장소 복제본을 만드는 것을 의미합니다.
1. **저장소 포크**. 사람들에게 프로젝트를 _포크_하도록 요청할 가능성이 높습니다. 포크는 자신의 GitHub 프로필에 저장소 복제본을 만드는 것을 의미합니다.
1. **클론**. 그런 다음 프로젝트를 로컬 컴퓨터로 클론합니다.
1. **브랜치 생성**. 작업을 위한 _브랜치_를 생성해야 합니다.
1. **변경 사항을 한 영역에 집중**. 기여자에게 한 번에 한 가지에 집중하도록 요청하세요. 이렇게 하면 작업을 _병합_할 가능성이 높아집니다. 예를 들어, 버그 수정, 새로운 기능 추가, 여러 테스트 업데이트를 한 번에 수행하면, 3가지 중 2가지만 구현하거나 1가지만 구현할 수 있는 상황이 발생할 수 있습니다.
1. **브랜치 생성**. 작업을 위한 _브랜치_를 생성하도록 요청합니다.
1. **변경 사항을 한 영역에 집중**. 기여자가 한 번에 한 가지에 집중하도록 요청하세요. 이렇게 하면 작업을 _병합_할 가능성이 높아집니다. 예를 들어, 버그 수정, 새로운 기능 추가, 여러 테스트 업데이트를 작성했다고 가정해보세요. 3가지 중 2개 또는 1개만 구현할 수 있다면 어떻게 하겠습니까?
✅ 브랜치가 좋은 코드 작성 및 배포에 특히 중요한 상황을 상상해 보세요. 어떤 사용 사례가 떠오르나요?
✅ 브랜치가 좋은 코드 작성 및 배포에 특히 중요한 상황을 상상해보세요. 어떤 사용 사례를 생각할 수 있나요?
> 참고: 세상에 변화를 만들고 싶다면, 자신의 작업에도 브랜치를 생성하세요. 현재 "체크아웃"된 브랜치에서 모든 커밋이 이루어집니다. `git status`를 사용하여 현재 브랜치를 확인하세요.
> 참고, 세상에 변화를 원한다면 자신의 작업을 위해 브랜치를 생성하세요. 현재 "체크아웃"된 브랜치에서 커밋이 이루어집니다. `git status`를 사용하여 현재 브랜치를 확인하세요.
기여자 워크플로를 살펴보겠습니다. 기여자가 이미 저장소를 _포크_하고 _클론_하여 로컬 컴퓨터에서 작업할 준비가 된 Git 저장소를 가지고 있다고 가정합니다:
1. **브랜치 생성**. `git branch` 명령을 사용하여 기여하려는 변경 사항을 포함할 브랜치를 생성하세요:
1. **브랜치 생성**. `git branch` 명령을 사용하여 기여하려는 변경 사항을 포함할 브랜치를 생성합니다:
```bash
git branch [branch-name]
```
1. **작업 브랜치로 전환**. 지정된 브랜치로 전환하고 `git switch`를 사용하여 작업 디렉토리를 업데이트하세요:
1. **작업 브랜치로 전환**. 지정된 브랜치로 전환하고 `git switch`를 사용하여 작업 디렉토리를 업데이트합니다:
```bash
git switch [branch-name]
```
1. **작업 수행**. 이 시점에서 변경 사항을 추가하세요. Git에 이를 알리는 것을 잊지 마세요. 다음 명령을 사용하세요:
1. **작업 수행**. 이 시점에서 변경 사항을 추가합니다. 다음 명령을 사용하여 Git에 변경 사항을 알리는 것을 잊지 마세요:
```bash
git add .
git commit -m "my changes"
```
커밋에 좋은 이름을 지정하세요. 이는 기여자 자신과 저장소 유지 관리자를 위해 중요합니다.
커밋에 좋은 이름을 지정하세요. 이는 기여자 자신뿐만 아니라 저장소 유지 관리자에게도 중요합니다.
1. **`main` 브랜치와 작업 병합**. 작업이 완료되면 `main` 브랜치와 작업을 병합하고 싶을 것입니다. `main` 브랜치는 그동안 변경되었을 수 있으므로 다음 명령을 사용하여 먼저 최신 상태로 업데이트하세요:
1. **작업을 `main` 브랜치와 병합**. 작업이 완료되면 `main` 브랜치와 작업을 병합하고 싶을 것입니다. `main` 브랜치는 그동안 변경되었을 수 있으므로 먼저 최신 상태로 업데이트하세요:
```bash
git switch main
git pull
```
이 시점에서 Git이 변경 사항을 쉽게 _병합_할 수 없는 _충돌_이 발생하지 않도록 하세요. 이를 위해 다음 명령을 실행하세요:
이 시점에서 Git이 변경 사항을 _병합_할 수 없는 경우, 즉 _충돌_이 발생하는 상황이 작업 브랜치에서 발생하도록 해야 합니다. 따라서 다음 명령을 실행하세요:
```bash
git switch [branch_name]
git merge main
```
이는 `main` 브랜치의 모든 변경 사항을 작업 브랜치로 가져오며, 문제가 없기를 바랍니다. 문제가 발생하면 VS Code가 Git이 _혼란스러워하는_ 부분을 알려주며, 영향을 받는 파일을 수정하여 가장 정확한 내용을 반영하도록 변경하면 됩니다.
`git merge main` 명령은 `main`에서 모든 변경 사항을 브랜치로 가져옵니다. 운이 좋다면 계속 진행할 수 있습니다. 그렇지 않다면 VS Code가 Git이 _혼란스러워하는_ 위치를 알려줄 것이며, 영향을 받는 파일을 수정하여 가장 정확한 내용을 지정하면 됩니다.
다른 브랜치로 전환하려면 최신 `git switch` 명령을 사용하세요:
```bash
git switch [branch_name]
1. **작업을 GitHub로 전송**. 작업을 GitHub로 전송한다는 것은 두 가지를 의미합니다. 브랜치를 자신의 저장소로 푸시하고 PR(Pull Request)을 여는 것입니다.
1. **작업을 GitHub로 전송**. 작업을 GitHub로 전송한다는 것은 두 가지를 의미합니다. 브랜치를 저장소로 푸시하고 PR(Pull Request)을 여는 것입니다.
```bash
git push --set-upstream origin [branch-name]
```
위 명령은 포크된 저장소에 브랜치를 생성합니다.
1. **PR 열기**. 다음 단계는 PR을 여는 것입니다. GitHub에서 포크한 저장소로 이동하면 새 PR을 생성할지 묻는 표시가 나타납니다. 이를 클릭하면 커밋 메시지 제목을 변경하거나 더 적합한 설명을 추가할 수 있는 인터페이스로 이동합니다. 이제 포크한 저장소의 관리자가 이 PR을 확인하고, _운이 좋다면_ 이를 승인하고 _병합_할 것입니다. 축하합니다! 이제 당신은 기여자가 되었습니다, 야호 :)
1. **PR 열기**. 다음으로 PR을 열고 싶습니다. GitHub에서 포크된 저장소로 이동하면 새 PR을 생성할지 묻는 표시가 나타납니다. 이를 클릭하면 커밋 메시지 제목을 변경하거나 더 적합한 설명을 추가할 수 있는 인터페이스로 이동합니다. 이제 포크된 저장소의 유지 관리자가 이 PR을 확인하고, _운이 좋다면_ PR을 _병합_할 것입니다. 이제 기여자가 된 것입니다. 축하합니다 :)
1. **정리**. PR을 성공적으로 병합한 후에는 정리하는 것이 좋은 관행으로 간주됩니다. 로컬 브랜치와 GitHub에 푸시한 브랜치를 정리하세요. 먼저 다음 명령을 사용하여 로컬에서 삭제하세요:
1. **정리하기**. PR을 성공적으로 병합한 후에는 _정리_하는 것이 좋은 관행으로 여겨집니다. 로컬 브랜치와 GitHub에 푸시한 브랜치를 모두 정리해야 합니다. 먼저 아래 명령어를 사용하여 로컬에서 삭제해 봅시다:
```bash
git branch -d [branch-name]
```
그런 다음 포크된 저장소의 GitHub 페이지로 이동하여 방금 푸시한 원격 브랜치를 삭제하세요.
`Pull request`라는 용어는 다소 이상하게 들릴 수 있습니다. 왜냐하면 실제로는 프로젝트에 변경 사항을 "푸시"하고 싶어 하기 때문이죠. 하지만 프로젝트 소유자나 핵심 팀이 변경 사항을 검토한 후 프로젝트의 "main" 브랜치에 병합할지 결정해야 하므로, 사실상 유지 관리자에게 변경 사항에 대한 결정을 요청하는 것입니다.
그런 다음 포크한 저장소의 GitHub 페이지로 이동하여 방금 푸시한 원격 브랜치를 제거하세요.
`Pull request`라는 용어는 다소 이상하게 들릴 수 있습니다. 왜냐하면 실제로는 프로젝트에 변경 사항을 푸시하고 싶기 때문입니다. 하지만 관리자(프로젝트 소유자)나 핵심 팀이 변경 사항을 검토한 후 프로젝트의 "main" 브랜치에 병합해야 하므로, 사실상 관리자로부터 변경 결정을 요청하는 것입니다.
Pull request는 브랜치에서 도입된 차이점을 리뷰, 댓글, 통합 테스트 등을 통해 비교하고 논의하는 공간입니다. 좋은 pull request는 커밋 메시지와 대체로 비슷한 규칙을 따릅니다. 예를 들어, 작업이 특정 문제를 해결하는 경우, 이슈 트래커에서 해당 문제를 참조할 수 있습니다. 이는 `#` 뒤에 이슈 번호를 붙여서 수행합니다. 예:`#97`.
Pull request는 브랜치에서 도입된 차이를 비교하고 리뷰, 댓글, 통합 테스트 등을 통해 논의하는 공간입니다. 좋은 Pull request는 커밋 메시지와 거의 동일한 규칙을 따릅니다. 작업이 특정 문제를 해결하는 경우, 이슈 트래커에서 이슈에 대한 참조를 추가할 수 있습니다. 이는 `#` 뒤에 이슈 번호를 붙여서 수행됩니다. 예를 들어`#97`.
🤞모든 검사가 통과되고 프로젝트 소유자가 변경 사항을 프로젝트에 병합해 주기를 기원합니다🤞
🤞모든 검사가 통과하고 프로젝트 소유자가 변경 사항을 프로젝트에 병합하기를 기원합니다🤞
현재 로컬 작업 브랜치를 GitHub의 해당 원격 브랜치에서 새 커밋으로 업데이트하려면 다음 명령어를 사용하세요:
GitHub의 해당 원격 브랜치에서 모든 새로운 커밋을 가져와 현재 로컬 작업 브랜치를 업데이트하세요:
`git pull`
## 오픈 소스에 기여하는 방법
먼저, GitHub에서 관심 있는 저장소(**repo**)를 찾아 변경 사항을 기여하고 싶다면 해당 내용을 자신의 컴퓨터로 복사해야 합니다.
먼저, GitHub에서 관심 있는 저장소(또는 **repo**)를 찾아 변경 사항을 기여하고 싶다면 해당 내용을 자신의 컴퓨터로 복사해야 합니다.
✅ '초보자 친화적'인 저장소를 찾는 좋은 방법은 [‘good-first-issue’ 태그로 검색](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)하는 것입니다.
✅ '초보자 친화적'인 저장소를 찾는 좋은 방법은 [태그 'good-first-issue'로 검색](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)하는 것입니다.
코드를 복사하는 방법은 여러 가지가 있습니다. 한 가지 방법은 HTTPS, SSH, 또는 GitHub CLI(명령줄 인터페이스)를 사용하여 저장소의 내용을 "클론"하는 것입니다.
코드를 복사하는 방법은 여러 가지가 있습니다. 한 가지 방법은 HTTPS, SSH 또는 GitHub CLI(명령줄 인터페이스)를 사용하여 저장소의 내용을 "클론"하는 것입니다.
터미널을 열고 다음과 같이 저장소를 클론하세요:
`git clone https://github.com/ProjectURL`
@ -294,36 +298,36 @@ Pull request는 브랜치에서 도입된 차이점을 리뷰, 댓글, 통합
프로젝트 작업을 위해 올바른 폴더로 이동하세요:
`cd ProjectURL`
또한 [Codespaces](https://github.com/features/codespaces)(GitHub의 내장 코드 편집기/클라우드 개발 환경)나 [GitHub Desktop](https://desktop.github.com/)을 사용하여 전체 프로젝트를 열 수도 있습니다.
또한 [Codespaces](https://github.com/features/codespaces)라는 GitHub의 내장 코드 편집기/클라우드 개발 환경이나 [GitHub Desktop](https://desktop.github.com/)을 사용하여 전체 프로젝트를 열 수도 있습니다.
마지막으로, 코드를 압축된 폴더로 다운로드할 수도 있습니다.
### GitHub에 대한 몇 가지 흥미로운 점
### GitHub에 대한 몇 가지 흥미로운 사실
GitHub에서 모든 공개 저장소를 별표 표시(star), 구독(watch), 또는 "포크(fork)"할 수 있습니다. 별표 표시한 저장소는 오른쪽 상단 드롭다운 메뉴에서 찾을 수 있습니다. 이는 코드 북마크와 비슷합니다.
GitHub에서 모든 공개 저장소를 별표 표시(star), 구독(watch) 및 "포크"할 수 있습니다. 별표 표시한 저장소는 오른쪽 상단 드롭다운 메뉴에서 찾을 수 있습니다. 코드 북마크와 비슷한 기능입니다.
프로젝트에는 주로 GitHub의 "Issues" 탭에 있는 이슈 트래커(별도 표시가 없는 한)가 있으며, 여기서 프로젝트와 관련된 문제를 논의합니다. Pull Requests 탭에서는 진행 중인 변경 사항을 논의하고 검토합니다.
프로젝트에는 주로 GitHub의 "Issues" 탭에 있는 이슈 트래커가 있으며, 여기서 프로젝트와 관련된 문제를 논의합니다. 그리고 Pull Requests 탭에서는 진행 중인 변경 사항을 논의하고 리뷰합니다.
프로젝트는 또한 포럼, 메일링 리스트, Slack, Discord, IRC와 같은 채팅 채널에서 논의가 이루어질 수도 있습니다.
프로젝트는 또한 포럼, 메일링 리스트 또는 Slack, Discord, IRC와 같은 채팅 채널에서 논의가 이루어질 수 있습니다.
✅ 새 GitHub 저장소를 둘러보고 설정을 편집하거나, 저장소에 정보를 추가하거나, 프로젝트(예: 칸반 보드)를 생성하는 등 몇 가지를 시도해 보세요. 할 수 있는 일이 많습니다!
✅ 새 GitHub 저장소를 둘러보고 설정을 편집하거나 정보를 추가하거나 프로젝트(예: 칸반 보드)를 생성하는 등 몇 가지를 시도해 보세요. 할 수 있는 일이 많습니다!
---
## 🚀 도전 과제
친구와 짝을 이루어 서로의 코드를 작업해 보세요. 협업 프로젝트를 만들고, 코드를 포크하고, 브랜치를 생성하고, 변경 사항을 병합해 보세요.
친구와 짝을 이루어 서로의 코드를 작업해 보세요. 협력적으로 프로젝트를 생성하고, 코드를 포크하고, 브랜치를 생성하고, 변경 사항을 병합하세요.
## 강의 후 퀴즈
[강의 후 퀴즈](https://ff-quizzes.netlify.app/web/en/)
## 복습 및 자기 학습
[오픈 소스 소프트웨어에 기여하기](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)에 대해 더 읽어보세요.
[오픈 소스 소프트웨어에 기여하는 방법](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)에 대해 더 읽어보세요.
연습, 연습, 연습. GitHub는 [skills.github.com](https://skills.github.com)를 통해 훌륭한 학습 경로를 제공합니다:
연습, 연습, 연습하세요. GitHub는 [skills.github.com](https://skills.github.com)를 통해 훌륭한 학습 경로를 제공합니다:
- [GitHub 첫 주](https://skills.github.com/#first-week-on-github)
@ -336,4 +340,4 @@ GitHub에서 모든 공개 저장소를 별표 표시(star), 구독(watch), 또
---
**면책 조항**:
이 문서는 AI 번역 서비스 [Co-op Translator](https://github.com/Azure/co-op-translator)를 사용하여 번역되었습니다. 정확성을 위해 최선을 다하고 있으나, 자동 번역에는 오류나 부정확성이 포함될 수 있습니다. 원본 문서의 원어 버전이 권위 있는 출처로 간주되어야 합니다. 중요한 정보의 경우, 전문적인 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생하는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다.
이 문서는 AI 번역 서비스 [Co-op Translator](https://github.com/Azure/co-op-translator)를 사용하여 번역되었습니다. 정확성을 위해 최선을 다하고 있으나, 자동 번역에는 오류나 부정확성이 포함될 수 있습니다. 원본 문서의 원어 버전을 신뢰할 수 있는 권위 있는 자료로 간주해야 합니다. 중요한 정보의 경우, 전문적인 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생하는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다.
Norėdami patikrinti, ar Git jau sukonfigūruotas, galite įvesti:
`git config --list`
Taip pat jums reikės GitHub paskyros, kodo redaktoriaus (pvz., Visual Studio Code) ir terminalo (arba komandų eilutės).
Jums taip pat reikės GitHub paskyros, kodo redaktoriaus (pvz., Visual Studio Code) ir terminalo (arba komandų eilutės).
Eikite į [github.com](https://github.com/) ir susikurkite paskyrą, jei dar neturite, arba prisijunkite ir užpildykite savo profilį.
@ -45,13 +45,13 @@ Eikite į [github.com](https://github.com/) ir susikurkite paskyrą, jei dar net
### Pasiruošimas
Jums reikės aplanko su kodo projektu jūsų vietiniame kompiuteryje (nešiojamame ar stacionariame) ir viešos saugyklos GitHub, kuri bus naudojama kaip pavyzdys, kaip prisidėti prie kitų projektų.
Jums reikės aplanko su kodo projektu jūsų vietiniame kompiuteryje (nešiojamame ar stacionariame) ir viešos saugyklos GitHub, kuri bus pavyzdys, kaip prisidėti prie kitų projektų.
---
## Kodo valdymas
Tarkime, turite aplanką su kodo projektu savo kompiuteryje ir norite pradėti sekti savo progresą naudodami git – versijų valdymo sistemą. Kai kurie žmonės lygina git naudojimą su meilės laiško rašymu sau ateityje. Skaitydami savo commit žinutes po dienų, savaičių ar mėnesių galėsite prisiminti, kodėl priėmėte tam tikrą sprendimą, arba „atsukti“ pakeitimą – žinoma, jei rašote geras commit žinutes.
Tarkime, turite aplanką su kodo projektu vietiniame kompiuteryje ir norite pradėti sekti savo progresą naudodami git – versijų valdymo sistemą. Kai kurie žmonės lygina git naudojimą su meilės laiško rašymu sau ateityje. Skaitydami savo commit žinutes po dienų, savaičių ar mėnesių, galėsite prisiminti, kodėl priėmėte tam tikrą sprendimą, arba „atsukti“ pakeitimą – žinoma, jei rašote geras commit žinutes.
### Užduotis: Sukurkite saugyklą ir commit'inkite kodą
@ -59,9 +59,10 @@ Tarkime, turite aplanką su kodo projektu savo kompiuteryje ir norite pradėti s
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Sukurkite saugyklą GitHub**. GitHub.com, skirtuke „Repositories“ arba viršutiniame dešiniajame navigacijos juostoje, raskite mygtuką **new repo**.
1. Suteikite savo saugyklai (aplankui) pavadinimą.
1. Suteikite savo saugyklai (aplankui) pavadinimą
1. Pasirinkite **create repository**.
1. **Eikite į savo darbo aplanką**. Terminale pereikite į aplanką (dar vadinamą direktorija), kurį norite pradėti sekti. Įveskite:
@ -82,7 +83,7 @@ Tarkime, turite aplanką su kodo projektu savo kompiuteryje ir norite pradėti s
git status
```
Rezultatas gali atrodyti maždaug taip:
rezultatas gali atrodyti maždaug taip:
```output
Changes not staged for commit:
@ -110,53 +111,53 @@ Tarkime, turite aplanką su kodo projektu savo kompiuteryje ir norite pradėti s
git add [file or folder name]
```
Tai leidžia pridėti tik pasirinktus failus į „staging area“, kai nenorite commit'inti visų failų iš karto.
Tai leidžia pridėti tik pasirinktus failus į „staging area“, kai nenorite commit'inti visų failų vienu metu.
1. **Atšaukite visų failų sekimą**
1. **Atšaukite visų failų „staging“**
```bash
git reset
```
Ši komanda leidžia atšaukti visų failų sekimą iš karto.
Ši komanda leidžia atšaukti visų failų „staging“ vienu metu.
1. **Atšaukite konkretaus failo sekimą**
1. **Atšaukite konkretaus failo „staging“**
```bash
git reset [file or folder name]
```
Ši komanda leidžia atšaukti tik konkretaus failo sekimą, kurio nenorite įtraukti į kitą commit'ą.
Ši komanda leidžia atšaukti tik konkretaus failo „staging“, kurio nenorite įtraukti į kitą commit'ą.
1. **Išsaugokite savo darbą**. Šiuo metu pridėjote failus į vadinamąją _staging area_. Tai vieta, kur Git seka jūsų failus. Norėdami pakeitimą padaryti nuolatiniu, turite _commit'inti_ failus. Tai padaryti galite su `git commit` komanda. Commit'as reprezentuoja išsaugojimo tašką jūsų saugyklos istorijoje. Įveskite šią komandą, kad sukurtumėte commit'ą:
1. **Išsaugokite savo darbą**. Šiuo metu pridėjote failus į vadinamąją _staging area_. Tai vieta, kur Git seka jūsų failus. Norėdami pakeitimą padaryti nuolatiniu, turite _commit'inti_ failus. Tai atliekama sukuriant _commit_ su `git commit` komanda. _Commit_ atspindi išsaugojimo tašką jūsų saugyklos istorijoje. Įveskite šią komandą, kad sukurtumėte _commit_:
```bash
git commit -m "first commit"
```
Tai commit'ina visus jūsų failus, pridedant žinutę „first commit“. Ateities commit žinutėse norėsite būti detalesni, kad aiškiai perteiktumėte, kokį pakeitimą atlikote.
Tai commit'ina visus jūsų failus, pridedant žinutę „first commit“. Ateities commit žinutėse norėsite būti labiau aprašomi, kad perteiktumėte, kokio tipo pakeitimą atlikote.
1. **Susiekite savo vietinę Git saugyklą su GitHub**. Git saugykla yra naudinga jūsų kompiuteryje, tačiau tam tikru momentu norėsite turėti failų atsarginę kopiją kažkur kitur ir taip pat pakviesti kitus žmones dirbti su jūsų saugykla. Viena puiki vieta tai padaryti yra GitHub. Prisiminkite, kad jau sukūrėme saugyklą GitHub, todėl vienintelis dalykas, kurį reikia padaryti, yra susieti vietinę Git saugyklą su GitHub. Komanda `git remote add` tai padarys. Įveskite šią komandą:
1. **Susiekite savo vietinę Git saugyklą su GitHub**. Git saugykla yra naudinga jūsų kompiuteryje, tačiau tam tikru momentu norėsite turėti failų atsarginę kopiją kažkur kitur ir taip pat pakviesti kitus žmones dirbti su jūsų saugykla. Viena puiki vieta tai padaryti yra GitHub. Prisiminkite, kad jau sukūrėme saugyklą GitHub, todėl vienintelis dalykas, kurį reikia padaryti, yra susieti vietinę Git saugyklą su GitHub. Komanda `git remote add` tai atliks. Įveskite šią komandą:
> Pastaba: prieš įvesdami komandą, eikite į savo GitHub saugyklos puslapį, kad rastumėte saugyklos URL. Jį naudosite žemiau esančioje komandoje. Pakeiskite ```https://github.com/username/repository_name.git``` savo GitHub URL.
> Pastaba: prieš įvedant komandą eikite į savo GitHub saugyklos puslapį, kad rastumėte saugyklos URL. Jį naudosite žemiau esančioje komandoje. Pakeiskite ```https://github.com/username/repository_name.git``` savo GitHub URL.
Tai sukuria _remote_ ryšį, pavadintą „origin“, nukreiptą į anksčiau sukurtą GitHub saugyklą.
1. **Siųskite vietinius failus į GitHub**. Iki šiol sukūrėte _ryšį_ tarp vietinės saugyklos ir GitHub saugyklos. Siųskime šiuos failus į GitHub naudodami komandą `git push`, taip:
Tai sukuria _remote_, arba ryšį, pavadintą „origin“, nukreiptą į anksčiau sukurtą GitHub saugyklą.
1. **Siųskite vietinius failus į GitHub**. Iki šiol sukūrėte _ryšį_ tarp vietinės saugyklos ir GitHub saugyklos. Siųskime šiuos failus į GitHub naudodami šią komandą `git push`, kaip parodyta:
> Pastaba: jūsų šakos pavadinimas pagal numatymą gali skirtis nuo ```main```.
```bash
git push -u origin main
```
Tai siunčia jūsų commit'us iš „main“ šakos į GitHub.
Tai siunčia jūsų commit'us iš „main“ šakos į GitHub. Nustatant `upstream` šaką, įskaitant `-u` komandoje, sukuriamas ryšys tarp jūsų vietinės šakos ir nuotolinės šakos, todėl ateityje galėsite naudoti git push arba git pull nenurodydami šakos pavadinimo. Git automatiškai naudos „upstream“ šaką, ir ateityje nereikės aiškiai nurodyti šakos pavadinimo komandose.
2. **Pridėkite daugiau pakeitimų**. Jei norite tęsti pakeitimų darymą ir siuntimą į GitHub, jums tereikės naudoti šias tris komandas:
2. **Pridėkite daugiau pakeitimų**. Jei norite toliau daryti pakeitimus ir siųsti juos į GitHub, jums tereikės naudoti šias tris komandas:
```bash
git add .
@ -164,23 +165,23 @@ Tarkime, turite aplanką su kodo projektu savo kompiuteryje ir norite pradėti s
git push
```
> Patarimas: galbūt norėsite naudoti `.gitignore` failą, kad išvengtumėte failų, kurių nenorite sekti, rodymo GitHub – pvz., užrašų failo, kurį saugote tame pačiame aplanke, bet kuris neturi vietos viešoje saugykloje. `.gitignore` failų šablonus galite rasti [`.gitignore templates`](https://github.com/github/gitignore).
> Patarimas: galbūt norėsite naudoti `.gitignore` failą, kad išvengtumėte failų, kurių nenorite sekti, rodymo GitHub – pavyzdžiui, tą užrašų failą, kurį saugote tame pačiame aplanke, bet kuris neturi vietos viešoje saugykloje. `.gitignore` failų šablonus galite rasti [.gitignore templates](https://github.com/github/gitignore).
#### Commit žinutės
Puiki Git commit žinutės antraštė užbaigia šį sakinį:
Jei pritaikyta, šis commit'as <jūsųantraštėčia>
Jei pritaikyta, šis commit atliks <jūsųantraštėčia>
Antraštėje naudokite imperatyvą, esamą laiką: „keisti“, o ne „pakeista“ ar „keičiasi“.
Kaip ir antraštėje, kūne (neprivaloma) taip pat naudokite imperatyvą, esamą laiką. Kūnas turėtų apimti motyvaciją pakeitimui ir palyginti tai su ankstesniu elgesiu. Jūs aiškinate `kodėl`, o ne `kaip`.
Antraštėje naudokite imperatyvą, esamą laiką: „keisti“, o ne „pakeista“ ar „keičia“.
Kaip ir antraštėje, kūne (neprivaloma) taip pat naudokite imperatyvą, esamą laiką. Kūnas turėtų apimti pakeitimo motyvaciją ir palyginti tai su ankstesniu elgesiu. Jūs aiškinate `kodėl`, o ne `kaip`.
✅ Skirkite kelias minutes naršymui GitHub. Ar galite rasti tikrai puikią commit žinutę? Ar galite rasti labai minimalią? Kokią informaciją, jūsų manymu, svarbiausia ir naudinga perteikti commit žinutėje?
✅ Skirkite kelias minutes naršymui GitHub. Ar galite rasti tikrai puikią commit žinutę? Ar galite rasti labai minimalų commit'ą? Kokią informaciją, jūsų manymu, svarbiausia ir naudingiausia perteikti commit žinutėje?
### Užduotis: Bendradarbiaukite
Pagrindinė priežastis, kodėl dalinatės projektais GitHub, yra galimybė bendradarbiauti su kitais kūrėjais.
Pagrindinė priežastis, kodėl dalinatės dalykais GitHub, yra galimybė bendradarbiauti su kitais kūrėjais.
## Darbas su kitais projektais
## Darbas su kitais projektuose
> Peržiūrėkite vaizdo įrašą
>
@ -192,25 +193,27 @@ Savo saugykloje eikite į `Insights > Community`, kad pamatytumėte, kaip jūsų
- **Aprašymas**. Ar pridėjote projekto aprašymą?
- **README**. Ar pridėjote README? GitHub pateikia rekomendacijas, kaip rašyti [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Gairės prisidėjimui**. Ar jūsų projektas turi [prisidėjimo gaires](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Elgesio kodeksas**. Ar pridėjote [elgesio kodeksą](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licencija**. Galbūt svarbiausia – [licencija](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Licencija**. Galbūt svarbiausia – [licenciją](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Visi šie ištekliai padės naujiems komandos nariams greičiau prisijungti. Tai paprastai yra dalykai, kuriuos nauji prisidėtojai peržiūri prieš net žiūrėdami į jūsų kodą, kad sužinotų, ar jūsų projektas yra tinkama vieta jų laikui skirti.
Visi šie ištekliai bus naudingi naujų komandos narių įtraukimui. Tai paprastai yra dalykai, kuriuos nauji prisidėtojai peržiūri prieš net žiūrėdami į jūsų kodą, kad sužinotų, ar jūsų projektas yra tinkama vieta jų laikui skirti.
✅ README failai, nors jų paruošimas užtrunka, dažnai yra ignoruojami užimtų prižiūrėtojų. Ar galite rasti ypač išsamų pavyzdį? Pastaba: yra keletas [įrankių, kurie padeda kurti gerus README](https://www.makeareadme.com/), kuriuos galbūt norėsite išbandyti.
✅ README failai, nors jų paruošimas užtrunka, dažnai yra ignoruojami užimtų prižiūrėtojų. Ar galite rasti ypač aprašomą README pavyzdį? Pastaba: yra keletas [įrankių, kurie padeda kurti gerus README](https://www.makeareadme.com/), kuriuos galbūt norėsite išbandyti.
### Užduotis: Sujunkite kodą
Prisidėjimo dokumentai padeda žmonėms prisidėti prie projekto. Jie paaiškina, kokių prisidėjimų ieškote ir kaip veikia procesas. Prisidėtojai turės atlikti kelis veiksmus, kad galėtų prisidėti prie jūsų saugyklos GitHub:
Prisidėjimo dokumentai padeda žmonėms prisidėti prie projekto. Jie paaiškina, kokio tipo prisidėjimų ieškote ir kaip veikia procesas. Prisidėtojai turės atlikti kelis veiksmus, kad galėtų prisidėti prie jūsų saugyklos GitHub:
1. **Fork'inkite jūsų saugyklą**. Tikriausiai norėsite, kad žmonės _fork'intų_ jūsų projektą. Fork'inimas reiškia jūsų saugyklos kopijos sukūrimą jų GitHub profilyje.
1. **Fork'inkite savo saugyklą**. Tikriausiai norėsite, kad žmonės _fork'intų_ jūsų projektą. Fork'inimas reiškia jūsų saugyklos kopijos sukūrimą jų GitHub profilyje.
1. **Klonuokite**. Iš ten jie klonuos projektą į savo vietinį kompiuterį.
1. **Sukurkite šaką**. Norėsite paprašyti jų sukurti _šaką_ savo darbui.
1. **Sutelkti dėmesį į vieną sritį**. Paprašykite prisidėtojų sutelkti savo prisidėjimus į vieną dalyką vienu metu – taip padidėja tikimybė, kad galėsite _sujungti_ jų darbą. Įsivaizduokite, kad jie pataiso klaidą, prideda naują funkciją ir atnaujina kelis testus – o kas, jei norite arba galite įgyvendinti tik 2 iš 3 ar 1 iš 3 pakeitimų?
1. **Sutelkti pakeitimą į vieną sritį**. Paprašykite prisidėtojų sutelkti savo prisidėjimus į vieną dalyką vienu metu – taip padidėja tikimybė, kad galėsite _sujungti_ jų darbą. Įsivaizduokite, kad jie pataiso klaidą, prideda naują funkciją ir atnaujina kelis testus – o kas, jei norite arba galite įgyvendinti tik 2 iš 3 arba 1 iš 3 pakeitimų?
✅ Įsivaizduokite situaciją, kurioje šakos yra ypač svarbios rašant ir išleidžiant gerą kodą. Kokius naudojimo atvejus galite sugalvoti?
✅ Įsivaizduokite situaciją, kurioje šakos yra ypač svarbios rašant ir pateikiant gerą kodą. Kokius naudojimo atvejus galite sugalvoti?
> Pastaba: būkite pokytis, kurį norite matyti pasaulyje, ir kurkite šakas savo darbui. Visi commit'ai, kuriuos atliksite, bus atlikti šakoje, kurioje šiuo metu esate „prisijungę“. Naudokite `git status`, kad pamatytumėte, kurioje šakoje esate.
> Pastaba: būkite pokytis, kurį norite matyti pasaulyje, ir kurkite šakas savo darbui. Bet kokie commit'ai, kuriuos atliksite, bus atlikti šakoje, kurioje šiuo metu esate „patikrintas“. Naudokite `git status`, kad pamatytumėte, kurioje šakoje esate.
Eikime per prisidėtojo darbo eigą. Tarkime, prisidėtojas jau _fork'ino_ ir _klonavo_ saugyklą, todėl jie turi Git saugyklą, paruoštą darbui, savo vietiniame kompiuteryje:
@ -220,7 +223,7 @@ Eikime per prisidėtojo darbo eigą. Tarkime, prisidėtojas jau _fork'ino_ ir _k
git branch [branch-name]
```
1. **Pereikite į darbo šaką**. Pereikite į nurodytą šaką ir atnaujinkite darbo direktoriją su`git switch`:
1. **Pereikite į darbo šaką**. Pereikite į nurodytą šaką ir atnaujinkite darbo direktoriją naudodami`git switch`:
```bash
git switch [branch-name]
@ -233,23 +236,27 @@ Eikime per prisidėtojo darbo eigą. Tarkime, prisidėtojas jau _fork'ino_ ir _k
git commit -m "my changes"
```
Įsitikinkite, kad suteikėte commit'ui gerą pavadinimą – tiek savo, tiek saugyklos prižiūrėtojo labui.
Įsitikinkite, kad suteikėte savo commit'ui gerą pavadinimą – tiek dėl savęs, tiek dėl saugyklos prižiūrėtojo, kuriam padedate.
1. **Sujunkite savo darbą su „main“ šaka**. Tam tikru momentu baigiate darbą ir norite sujungti savo darbą su „main“ šaka. „Main“ šaka tuo metu galėjo pasikeisti, todėl įsitikinkite, kad pirmiausia ją atnaujinate iki naujausios versijos naudodami šias komandas:
1. **Sujunkite savo darbą su `main` šaka**. Tam tikru momentu baigiate darbą ir norite sujungti savo darbą su `main` šaka. `Main` šaka tuo metu galėjo pasikeisti, todėl įsitikinkite, kad pirmiausia ją atnaujinate iki naujausios versijos naudodami šias komandas:
```bash
git switch main
git pull
```
Šiuo metu norite įsitikinti, kad visi _konfliktai_, situacijos, kai Git negali lengvai _sujungti_ pakeitimų, atsiranda jūsų darbo šakoje. Todėl vykdykite šias komandas:
Šiuo metu norite įsitikinti, kad bet kokie _konfliktai_, situacijos, kai Git negali lengvai _sujungti_ pakeitimų, įvyksta jūsų darbo šakoje. Todėl vykdykite šias komandas:
```bash
git switch [branch_name]
git merge main
```
Tai įtrauks visus pakeitimus iš „main“ į jūsų šaką, ir tikimės, kad galėsite tiesiog tęsti. Jei ne, VS Code parodys, kur Git yra _pasimetęs_, ir jūs tiesiog pakeisite paveiktus failus, kad nurodytumėte, kuris turinys yra tiksliausias.
Komanda `git merge main` įtrauks visus pakeitimus iš `main` į jūsų šaką. Tikimės, kad galėsite tiesiog tęsti. Jei ne, VS Code parodys, kur Git yra _sutriktas_, ir jūs tiesiog pakeisite paveiktus failus, kad nurodytumėte, kuris turinys yra tiksliausias.
Norėdami pereiti į kitą šaką, naudokite modernią komandą `git switch`:
```bash
git switch [branch_name]
1. **Siųskite savo darbą į GitHub**. Siųsti savo darbą į GitHub reiškia du dalykus: stumti savo šaką į savo saugyklą ir tada atidaryti PR (Pull Request).
@ -257,36 +264,36 @@ Eikime per prisidėtojo darbo eigą. Tarkime, prisidėtojas jau _fork'ino_ ir _k
git push --set-upstream origin [branch-name]
```
Aukščiau esanti komanda sukuria šaką jūsų fork'intoje saugykloje.
Aukščiau pateikta komanda sukuria šaką jūsų fork'intoje saugykloje.
1. **Atidarykite PR**. Toliau norite atidaryti PR. Tai padarysite naršydami į „forked“ repo GitHub platformoje. GitHub'e pamatysite pranešimą, kuriame klausiama, ar norite sukurti naują PR, spustelėkite jį ir būsite nukreipti į sąsają, kurioje galite pakeisti commit žinutės pavadinimą, pridėti tinkamesnį aprašymą. Dabar repo, kurį „forkinote“, palaikytojas pamatys šį PR ir _tikėkimės_ jis įvertins ir _sujungs_ jūsų PR. Dabar esate prisidėjęs prie projekto, valio :)
1. **Atidarykite PR**. Toliau norite atidaryti PR. Tai darote naršydami į fork'intą saugyklą GitHub. GitHub parodys indikaciją, kurioje klausia, ar norite sukurti naują PR, spustelėkite tai ir būsite nukreipti į sąsają, kurioje galite pakeisti commit žinutės pavadinimą, suteikti tinkamesnį aprašymą. Dabar saugyklos, kurią fork'inote, prižiūrėtojas matys šį PR ir _tikėkimės_, jie įvertins ir _sujungs_ jūsų PR. Dabar esate prisidėtojas, valio :)
1. **Išvalykite**. Laikoma gera praktika _išvalyti_ po to, kai sėkmingai sujungiate PR. Norite išvalyti tiek vietinę šaką, tiek šaką, kurią stumėte į GitHub. Pirmiausia ištrinkite ją vietoje naudodami šią komandą:
1. **Išvalymas**. Laikoma gera praktika _išvalyti_ po to, kai sėkmingai sujungiate PR. Norite išvalyti tiek savo vietinę šaką, tiek šaką, kurią įkėlėte į GitHub. Pirmiausia ištrinkite ją vietoje naudodami šią komandą:
```bash
git branch -d [branch-name]
```
Įsitikinkite, kad einate į GitHub puslapį fork'intos saugyklos ir pašalinate nuotolinę šaką, kurią ką tik stumėte į ją.
„Pull request“ atrodo kaip keistas terminas, nes iš tikrųjų jūs norite „push“ savo pakeitimus į projektą. Tačiau projekto prižiūrėtojas (projekto savininkas) arba pagrindinė komanda turi apsvarstyti jūsų pakeitimus prieš juos sujungiant su projekto „main“ šaka, todėl iš esmės jūs prašote prižiūrėtojo priimti sprendimą dėl pakeitimo.
Įsitikinkite, kad nuėjote į GitHub puslapį „forked“ repo ir pašalinote nuotolinę šaką, kurią ką tik įkėlėte.
`Pull request` gali atrodyti kaip keistas terminas, nes iš tikrųjų norite įkelti savo pakeitimus į projektą. Tačiau palaikytojas (projekto savininkas) arba pagrindinė komanda turi apsvarstyti jūsų pakeitimus prieš juos sujungiant su projekto „main“ šaka, todėl iš esmės jūs prašote palaikytojo priimti sprendimą dėl pakeitimo.
„Pull request“ yra vieta, kur galima palyginti ir aptarti skirtumus, įvestus šakoje, su apžvalgomis, komentarais, integruotais testais ir daugiau. Geras „pull request“ laikosi maždaug tų pačių taisyklių kaip ir „commit“ žinutė. Galite pridėti nuorodą į problemą problemų sekimo sistemoje, pavyzdžiui, kai jūsų darbas išsprendžia problemą. Tai daroma naudojant „#“, po kurio seka jūsų problemos numeris. Pavyzdžiui, „#97“.
Pull request yra vieta, kur galima palyginti ir aptarti šakos įvestus skirtumus, atlikti peržiūras, palikti komentarus, integruoti testus ir dar daugiau. Geras pull request laikosi maždaug tų pačių taisyklių kaip commit žinutė. Galite pridėti nuorodą į problemą „issue tracker“, kai jūsų darbas, pavyzdžiui, išsprendžia problemą. Tai daroma naudojant `#`, po kurio seka jūsų problemos numeris. Pavyzdžiui, `#97`.
🤞Tikimės, kad visi patikrinimai praeis ir projekto savininkas(-ai) sujungs jūsų pakeitimus į projektą🤞
🤞Tikėkimės, kad visi patikrinimai praeis ir projekto savininkas(-ai) sujungs jūsų pakeitimus į projektą🤞
Atnaujinkite savo dabartinę vietinę darbo šaką su visais naujais „commit'ais“ iš atitinkamos nuotolinės šakos GitHub'e:
Atnaujinkite savo dabartinę vietinę darbo šaką su visais naujais commit'ais iš atitinkamos nuotolinės šakos GitHub'e:
`git pull`
## Kaip prisidėti prie atvirojo kodo
Pirmiausia, raskite GitHub'e jus dominančią saugyklą (arba **repo**), prie kurios norėtumėte prisidėti pakeitimais. Jums reikės nukopijuoti jos turinį į savo kompiuterį.
Pirmiausia, suraskime GitHub'e jus dominančią saugyklą (arba **repo**), prie kurios norėtumėte prisidėti pakeitimu. Norėsite nukopijuoti jos turinį į savo kompiuterį.
✅ Geras būdas rasti „pradedantiesiems draugiškas“ saugyklas yra [ieškoti pagal žymą „good-first-issue“](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Geras būdas rasti „pradedantiesiems draugiškas“ saugyklas yra [ieškoti pagal žymą 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Yra keli būdai nukopijuoti kodą. Vienas iš būdų yra „klonuoti“ saugyklos turinį naudojant HTTPS, SSH arba GitHub CLI (komandinės eilutės sąsają).
Yra keli būdai kopijuoti kodą. Vienas iš būdų yra „klonuoti“ saugyklos turinį naudojant HTTPS, SSH arba GitHub CLI (komandinės eilutės sąsają).
Atidarykite terminalą ir klonuokite saugyklą taip:
`git clone https://github.com/ProjectURL`
@ -296,21 +303,21 @@ Norėdami dirbti su projektu, pereikite į tinkamą aplanką:
Taip pat galite atidaryti visą projektą naudodami [Codespaces](https://github.com/features/codespaces), GitHub integruotą kodo redaktorių / debesų kūrimo aplinką, arba [GitHub Desktop](https://desktop.github.com/).
Galiausiai, galite atsisiųsti kodą į suspaustą aplanką.
GitHub'e galite „užžvaigždinti“, stebėti ir/arba „forkinti“ bet kurią viešą saugyklą. Savo „užžvaigždintas“ saugyklas galite rasti viršutiniame dešiniajame išskleidžiamajame meniu. Tai tarsi žymėjimas, bet skirta kodui.
GitHub'e galite pažymėti žvaigždute, stebėti ir/arba „forkinti“ bet kurią viešą saugyklą. Savo pažymėtas saugyklas galite rasti viršutiniame dešiniajame išskleidžiamajame meniu. Tai tarsi žymėjimas, bet skirta kodui.
Projektai turi problemų sekimo sistemą, dažniausiai GitHub'e, „Issues“ skiltyje, nebent nurodyta kitaip, kur žmonės aptaria su projektu susijusias problemas. O „Pull Requests“ skiltyje žmonės aptaria ir peržiūri pakeitimus, kurie yra vykdomi.
Projektai turi problemų sekimo įrankį, dažniausiai GitHub'e, „Issues“ skirtuke, nebent nurodyta kitaip, kur žmonės aptaria su projektu susijusias problemas. O „Pull Requests“ skirtukas yra vieta, kur žmonės aptaria ir peržiūri vykstančius pakeitimus.
Projektai taip pat gali turėti diskusijas forumuose, el. pašto sąrašuose arba pokalbių kanaluose, tokiuose kaip Slack, Discord ar IRC.
✅ Apžiūrėkite savo naują GitHub saugyklą ir išbandykite keletą dalykų, pavyzdžiui, redaguoti nustatymus, pridėti informaciją į savo saugyklą ir sukurti projektą (pvz., Kanban lentą). Galite daug ką nuveikti!
✅ Apžiūrėkite savo naują GitHub repo ir išbandykite keletą dalykų, pvz., nustatymų redagavimą, informacijos pridėjimą prie repo ir projekto sukūrimą (pvz., Kanban lentą). Galite daug ką nuveikti!
---
## 🚀 Iššūkis
## 🚀 Iššūkis
Dirbkite poroje su draugu prie vienas kito kodo. Sukurkite projektą kartu, „forkinkite“ kodą, sukurkite šakas ir sujunkite pakeitimus.
@ -323,17 +330,17 @@ Skaitykite daugiau apie [prisidėjimą prie atvirojo kodo programinės įrangos]
Šis dokumentas buvo išverstas naudojant AI vertimo paslaugą [Co-op Translator](https://github.com/Azure/co-op-translator). Nors siekiame tikslumo, prašome atkreipti dėmesį, kad automatiniai vertimai gali turėti klaidų ar netikslumų. Originalus dokumentas jo gimtąja kalba turėtų būti laikomas autoritetingu šaltiniu. Kritinei informacijai rekomenduojama naudoti profesionalų žmogaus vertimą. Mes neprisiimame atsakomybės už nesusipratimus ar klaidingus aiškinimus, atsiradusius dėl šio vertimo naudojimo.
Šis dokumentas buvo išverstas naudojant AI vertimo paslaugą [Co-op Translator](https://github.com/Azure/co-op-translator). Nors siekiame tikslumo, prašome atkreipti dėmesį, kad automatiniai vertimai gali turėti klaidų ar netikslumų. Originalus dokumentas jo gimtąja kalba turėtų būti laikomas autoritetingu šaltiniu. Kritinei informacijai rekomenduojama naudoti profesionalų žmogaus vertimą. Mes neprisiimame atsakomybės už nesusipratimus ar neteisingą interpretaciją, atsiradusią dėl šio vertimo naudojimo.
- तुमच्या मशीनवर केलेल्या कामाचा मागोवा कसा ठेवायचा
- इतरांसोबत प्रकल्पांवर काम कसे करायचे
- ओपन सोर्स सॉफ्टवेअरमध्ये योगदान कसे द्यायचे
- तुमच्या मशीनवर केलेल्या कामाचा मागोवा घेणे
- इतरांसोबत प्रकल्पांवर काम करणे
- ओपन सोर्स सॉफ्टवेअरमध्ये योगदान कसे द्यावे
### पूर्वतयारी
सुरुवात करण्यापूर्वी, Git स्थापित आहे का ते तपासा. टर्मिनलमध्ये टाइप करा:
सुरुवात करण्यापूर्वी, Git स्थापित आहे का ते तपासणे आवश्यक आहे. टर्मिनलमध्ये टाइप करा:
`git --version`
जर Git स्थापित नसेल, तर [Git डाउनलोड करा](https://git-scm.com/downloads). त्यानंतर, तुमच्या स्थानिक Git प्रोफाइलची टर्मिनलमध्ये सेटअप करा:
जर Git स्थापित नसेल, तर [Git डाउनलोड करा](https://git-scm.com/downloads). त्यानंतर, तुमचा स्थानिक Git प्रोफाइल टर्मिनलमध्ये सेटअप करा:
* `git config --global user.name "तुमचे-नाव"`
* `git config --global user.email "तुमचा-ईमेल"`
Git आधीच कॉन्फिगर केले आहे का ते तपासण्यासाठी तुम्ही टाइप करू शकता:
`git config --list`
तुमच्याकडे GitHub खाते, कोड एडिटर (उदा. Visual Studio Code), आणि टर्मिनल (किंवा: कमांड प्रॉम्प्ट) उघडलेले असणे आवश्यक आहे.
तुमच्याकडे GitHub खाते, कोड एडिटर (उदा. Visual Studio Code) असणे आवश्यक आहे आणि तुम्हाला तुमचे टर्मिनल (किंवा: कमांड प्रॉम्प्ट) उघडावे लागेल.
[github.com](https://github.com/) वर जा आणि खाते तयार करा (जर तुम्ही आधीच केले नसेल), किंवा लॉग इन करा आणि तुमचे प्रोफाइल भरा.
[github.com](https://github.com/) वर जा आणि खाते तयार करा (जर तुम्ही आधीच केले नसेल), किंवा लॉग इन करा आणि तुमचा प्रोफाइल भरा.
✅ GitHub हा जगातील एकमेव कोड रिपॉझिटरी नाही; इतरही आहेत, पण GitHub सर्वात प्रसिद्ध आहे.
### तयारी
तुमच्या स्थानिक मशीनवर (लॅपटॉप किंवा पीसी) कोड प्रकल्प असलेला फोल्डर आणि GitHub वर सार्वजनिक रिपॉझिटरी आवश्यक आहे, जे इतरांच्या प्रकल्पांमध्ये योगदान कसे द्यायचे याचे उदाहरण म्हणून काम करेल.
तुमच्या स्थानिक मशीनवर (लॅपटॉप किंवा पीसी) कोड प्रकल्प असलेला फोल्डर आणि GitHub वरील सार्वजनिक रिपॉझिटरी आवश्यक आहे, जे इतरांच्या प्रकल्पांमध्ये योगदान कसे द्यावे याचे उदाहरण म्हणून काम करेल.
---
## कोड व्यवस्थापन
समजा तुमच्याकडे स्थानिक स्तरावर कोड प्रकल्प असलेला फोल्डर आहे आणि तुम्हाला git वापरून तुमच्या प्रगतीचा मागोवा सुरू करायचा आहे - जो एक व्हर्जन कंट्रोल सिस्टम आहे. काही लोक git वापरण्याची तुलना भविष्यातील स्वतःसाठी प्रेमपत्र लिहिण्याशी करतात. तुमचे "commit messages" वाचून तुम्हाला काही दिवस, आठवडे किंवा महिने नंतर का निर्णय घेतला हे आठवेल, किंवा बदल "rollback" करता येईल - अर्थात, तुम्ही चांगले "commit messages" लिहिल्यास.
समजा तुमच्याकडे स्थानिकपणे काही कोड प्रकल्प असलेला फोल्डर आहे आणि तुम्हाला git - आवृत्ती नियंत्रण प्रणाली वापरून तुमच्या प्रगतीचा मागोवा सुरू करायचा आहे. काही लोक git वापरण्याची तुलना भविष्यातील स्वतःसाठी प्रेमपत्र लिहिण्याशी करतात. तुमचे कमिट संदेश काही दिवस, आठवडे किंवा महिने नंतर वाचताना तुम्हाला निर्णय का घेतला हे आठवेल, किंवा बदल "रोलबॅक" करता येईल - म्हणजेच, जेव्हा तुम्ही चांगले "कमिट संदेश" लिहिता.
### कार्य: रिपॉझिटरी तयार करा आणि कोड commit करा
### कार्य: रिपॉझिटरी तयार करा आणि कोड कमिट करा
> व्हिडिओ पहा
> व्हिडिओ पहा
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub वर रिपॉझिटरी तयार करा**. GitHub.com वर, रिपॉझिटरी टॅबमध्ये, किंवा वरच्या उजव्या नेव्हिगेशन बारमधून, **नवीन रिपॉझिटरी** बटण शोधा.
1. **GitHub वर रिपॉझिटरी तयार करा**. GitHub.com वर, रिपॉझिटरी टॅबमध्ये, किंवा वरच्या उजव्या नेव्हिगेशन बारमधून, **नवीन रिपो** बटण शोधा.
1. तुमच्या रिपॉझिटरीला (फोल्डर) नाव द्या.
1. तुमच्या रिपॉझिटरीला (फोल्डर) नाव द्या
1. **रिपॉझिटरी तयार करा** निवडा.
1. **तुमच्या कार्यरत फोल्डरमध्ये जा**. टर्मिनलमध्ये, तुम्ही ट्रॅक करायचे असलेले फोल्डर (डायरेक्टरी म्हणूनही ओळखले जाते) निवडा. टाइप करा:
1. **तुमच्या कार्यरत फोल्डरमध्ये जा**. टर्मिनलमध्ये, तुम्ही ट्रॅकिंग सुरू करू इच्छित असलेल्या फोल्डरमध्ये (डायरेक्टरी म्हणूनही ओळखले जाते) स्विच करा. टाइप करा:
@ -93,10 +93,10 @@ Git आधीच कॉन्फिगर केले आहे का ते
modified: file2.txt
```
सामान्यतः `git status` कमांड तुम्हाला अशा गोष्टी सांगते जसे की कोणती फाइल्स _संचयित_ करण्यासाठी तयार आहेत किंवा त्यावर बदल आहेत जे तुम्हाला कायम ठेवायचे असतील.
सामान्यतः `git status` कमांड तुम्हाला अशा गोष्टी सांगते जसे की कोणती फाइल्स _सेव्ह_ करण्यासाठी तयार आहेत किंवा त्यावर बदल आहेत जे तुम्हाला कायम ठेवायचे असतील.
1. **सर्व फाइल्स ट्रॅकिंगसाठी जोडा**
याला फाइल्स स्टेजिंग/स्टेजिंग एरियामध्ये फाइल्स जोडणे असेही म्हणतात.
1. **सर्व फाइल्स ट्रॅकिंगसाठी जोडा**
याला फाइल्स स्टेजिंग/स्टेजिंग एरियामध्ये फाइल्स जोडणे असेही म्हणतात.
```bash
git add .
@ -110,7 +110,7 @@ Git आधीच कॉन्फिगर केले आहे का ते
git add [file or folder name]
```
हे आपल्याला एकाच वेळी सर्व फाइल्स commit न करता निवडलेल्या फाइल्स स्टेजिंग एरियामध्ये जोडण्यास मदत करते.
जेव्हा तुम्हाला सर्व फाइल्स एकाच वेळी कमिट करायच्या नसतील तेव्हा निवडलेल्या फाइल्स स्टेजिंग एरियामध्ये जोडण्यासाठी हे मदत करते.
1. **सर्व फाइल्स अनस्टेज करा**
@ -118,7 +118,7 @@ Git आधीच कॉन्फिगर केले आहे का ते
git reset
```
ही कमांड आपल्याला एकाच वेळी सर्व फाइल्स अनस्टेज करण्यास मदत करते.
ही कमांड तुम्हाला सर्व फाइल्स एकाच वेळी अनस्टेज करण्यास मदत करते.
1. **विशिष्ट फाइल अनस्टेज करा**
@ -126,25 +126,25 @@ Git आधीच कॉन्फिगर केले आहे का ते
git reset [file or folder name]
```
ही कमांड आपल्याला एकाच वेळी फक्त विशिष्ट फाइल अनस्टेज करण्यास मदत करते जी आपण पुढील commit मध्ये समाविष्ट करू इच्छित नाही.
ही कमांड तुम्हाला एकाच वेळी फक्त विशिष्ट फाइल अनस्टेज करण्यास मदत करते जी तुम्हाला पुढील कमिटमध्ये समाविष्ट करायची नाही.
1. **तुमचे काम कायम ठेवा**. या टप्प्यावर तुम्ही फाइल्स _स्टेजिंग एरिया_ मध्ये जोडल्या आहेत. Git तुमच्या फाइल्स ट्रॅक करत आहे. बदल कायम ठेवण्यासाठी तुम्हाला फाइल्स _commit_ कराव्या लागतील. _commit_ म्हणजे तुमच्या रिपॉझिटरीच्या इतिहासातील एक सेव्हिंग पॉइंट. _commit_ तयार करण्यासाठी टाइप करा:
1. **तुमचे काम कायम ठेवा**. या टप्प्यावर तुम्ही फाइल्स _स्टेजिंग एरियामध्ये_ जोडल्या आहेत. Git तुमच्या फाइल्स ट्रॅक करत आहे. बदल कायम ठेवण्यासाठी तुम्हाला फाइल्स _कमिट_ करणे आवश्यक आहे. _कमिट_ तयार करण्यासाठी `git commit` कमांड वापरा. _कमिट_ म्हणजे तुमच्या रिपॉझिटरीच्या इतिहासातील एक सेव्हिंग पॉइंट. _कमिट_ तयार करण्यासाठी खालील टाइप करा:
```bash
git commit -m "first commit"
```
हे तुमच्या सर्व फाइल्स commit करते, "first commit" संदेश जोडते. भविष्यातील commit messages साठी तुम्हाला अधिक वर्णनात्मक संदेश लिहायचे असतील जे तुम्ही केलेल्या बदलाचा प्रकार स्पष्ट करतात.
हे तुमच्या सर्व फाइल्स कमिट करते, "पहिले कमिट" संदेश जोडते. भविष्यातील कमिट संदेशांसाठी तुम्हाला तुमच्या बदलाचा प्रकार सांगण्यासाठी अधिक वर्णनात्मक असणे आवश्यक आहे.
1. **तुमच्या स्थानिक Git रिपॉझिटरीला GitHub शी कनेक्ट करा**. Git रिपॉझिटरी तुमच्या मशीनवर चांगली आहे, पण एका टप्प्यावर तुम्हाला तुमच्या फाइल्सचे बॅकअप कुठेतरी ठेवायचे आहे आणि इतर लोकांना तुमच्या रिपॉझिटरीवर काम करण्यासाठी आमंत्रित करायचे आहे. GitHub हे करण्यासाठी एक उत्तम ठिकाण आहे. लक्षात ठेवा आपण आधीच GitHub वर रिपॉझिटरी तयार केली आहे त्यामुळे आपल्याला फक्त स्थानिक Git रिपॉझिटरी GitHub शी कनेक्ट करायची आहे. `git remote add` कमांड हे काम करेल. खालील कमांड टाइप करा:
1. **तुमच्या स्थानिक Git रिपॉझिटरीला GitHub शी कनेक्ट करा**. Git रिपॉझिटरी तुमच्या मशीनवर चांगली आहे पण काही वेळाने तुम्हाला तुमच्या फाइल्सचे बॅकअप कुठेतरी ठेवायचे आहे आणि इतर लोकांना तुमच्या रिपॉझिटरीवर काम करण्यासाठी आमंत्रित करायचे आहे. GitHub हे करण्यासाठी एक उत्तम ठिकाण आहे. लक्षात ठेवा आपण आधीच GitHub वर रिपॉझिटरी तयार केली आहे त्यामुळे आपल्याला फक्त स्थानिक Git रिपॉझिटरी GitHub शी कनेक्ट करणे आवश्यक आहे. `git remote add` कमांड हे काम करेल. खालील कमांड टाइप करा:
> लक्षात ठेवा, कमांड टाइप करण्यापूर्वी तुमच्या GitHub रिपॉझिटरी पेजवर जा आणि रिपॉझिटरी URL शोधा. तुम्ही ते खालील कमांडमध्ये वापराल. ```https://github.com/username/repository_name.git``` ला तुमच्या GitHub URL ने बदला.
> लक्षात ठेवा, कमांड टाइप करण्यापूर्वी तुमच्या GitHub रिपॉझिटरी पेजवर जा आणि रिपॉझिटरी URL शोधा. तुम्ही ते खालील कमांडमध्ये वापराल. ```https://github.com/username/repository_name.git``` तुमच्या GitHub URL ने बदला.
हे "origin" नावाचा _remote_ किंवा कनेक्शन तयार करते जो तुम्ही आधी तयार केलेल्या GitHub रिपॉझिटरीकडे निर्देशित करतो.
हे "origin" नावाचा _remote_ किंवा कनेक्शन तयार करते जो तुम्ही पूर्वी तयार केलेल्या GitHub रिपॉझिटरीकडे निर्देशित करतो.
1. **स्थानिक फाइल्स GitHub वर पाठवा**. आतापर्यंत तुम्ही स्थानिक रिपॉझिटरी आणि GitHub रिपॉझिटरीमध्ये _कनेक्शन_ तयार केले आहे. आता या फाइल्स GitHub वर पाठवण्यासाठी `git push` कमांड वापरा, असे:
@ -154,7 +154,7 @@ Git आधीच कॉन्फिगर केले आहे का ते
git push -u origin main
```
हे तुमच्या "main" शाखेतील commits GitHub वर पाठवते.
हे तुमच्या "main" शाखेतील कमिट्स GitHub वर पाठवते. `upstream` शाखा सेट करणे आणि कमांडमध्ये `-u` समाविष्ट करणे स्थानिक शाखा आणि रिमोट शाखेमध्ये लिंक स्थापित करते, त्यामुळे तुम्ही शाखेचे नाव निर्दिष्ट न करता फक्त git push किंवा git pull वापरू शकता. Git स्वयंचलितपणे upstream शाखा वापरेल आणि तुम्हाला भविष्यातील कमांडमध्ये शाखेचे नाव स्पष्टपणे निर्दिष्ट करण्याची आवश्यकता नाही.
2. **अधिक बदल जोडण्यासाठी**. जर तुम्हाला बदल करत राहायचे असतील आणि ते GitHub वर पुश करायचे असतील तर तुम्हाला फक्त खालील तीन कमांड वापराव्या लागतील:
@ -164,17 +164,17 @@ Git आधीच कॉन्फिगर केले आहे का ते
git push
```
> टीप, तुम्हाला `.gitignore` फाइल स्वीकारायची असेल जी तुम्हाला GitHub वर ट्रॅक करू इच्छित नसलेल्या फाइल्स प्रतिबंधित करण्यास मदत करते - जसे की नोट्स फाइल जी तुम्ही त्याच फोल्डरमध्ये ठेवता पण सार्वजनिक रिपॉझिटरीमध्ये तिचे स्थान नाही. तुम्ही `.gitignore` फाइल्ससाठी टेम्पलेट्स [.gitignore templates](https://github.com/github/gitignore) येथे शोधू शकता.
> टीप, तुम्हाला `.gitignore` फाइल स्वीकारायची असेल जी तुम्हाला GitHub वर ट्रॅक करू इच्छित नसलेल्या फाइल्स प्रतिबंधित करण्यास मदत करते - जसे की तुमच्या नोट्स फाइल्स जी तुम्ही त्याच फोल्डरमध्ये ठेवता पण सार्वजनिक रिपॉझिटरीमध्ये त्याचे स्थान नाही. तुम्ही `.gitignore` फाइल्ससाठी टेम्पलेट्स [.gitignore templates](https://github.com/github/gitignore) येथे शोधू शकता.
#### Commit messages
#### कमिट संदेश
एक उत्कृष्ट Git commit विषय ओळ खालील वाक्य पूर्ण करते:
जर लागू केले, तर हा commit<तुमचा विषय येथे> करेल.
एक उत्कृष्ट Git कमिट विषय ओळ खालील वाक्य पूर्ण करते:
जर लागू केले, तर हा कमिट<तुमचा विषय येथे> करेल
विषयासाठी, आज्ञार्थक, वर्तमानकाळाचा वापर करा: "change" न की "changed" किंवा "changes".
विषयात जसे, शरीरात (पर्यायी) देखील आज्ञार्थक, वर्तमानकाळाचा वापर करा. शरीरात बदलासाठी प्रेरणा समाविष्ट करावी आणि यापूर्वीच्या वर्तनाशी तुलना करावी. तुम्ही `का` स्पष्ट करत आहात, `कसे` नाही.
विषयासाठी अनिवार्य, वर्तमान काळ वापरा: "change" नाही "changed" किंवा "changes".
विषयासारखेच, शरीरात (पर्यायी) देखील अनिवार्य, वर्तमान काळ वापरा. शरीरात बदलासाठी प्रेरणा समाविष्ट करावी आणि यापूर्वीच्या वर्तनाशी तुलना करावी. तुम्ही `का` स्पष्ट करत आहात, `कसे` नाही.
✅ GitHub वर थोडा वेळ घालवा. तुम्हाला खरोखर उत्कृष्ट commit message सापडते का? तुम्हाला खूपच साधा commit message सापडतो का? commit message मध्ये कोणती माहिती सर्वात महत्त्वाची आणि उपयुक्त वाटते?
✅ GitHub वर थोडा वेळ घालवा. तुम्हाला खरोखर उत्कृष्ट कमिट संदेश सापडतो का? तुम्हाला खूपच कमी माहिती असलेला सापडतो का? कमिट संदेशामध्ये कोणती माहिती सर्वात महत्त्वाची आणि उपयुक्त वाटते?
### कार्य: सहकार्य करा
@ -182,7 +182,7 @@ GitHub वर गोष्टी ठेवण्याचे मुख्य क
## इतरांसोबत प्रकल्पांवर काम करणे
> व्हिडिओ पहा
> व्हिडिओ पहा
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
@ -192,27 +192,27 @@ GitHub वर गोष्टी ठेवण्याचे मुख्य क
- **वर्णन**. तुमच्या प्रकल्पासाठी वर्णन जोडले आहे का?
- **README**. तुम्ही README जोडले आहे का? GitHub [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/) आहे का?
- **आचारसंहिता**. एक [आचारसंहिता](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 तयार करण्यासाठी काही साधने](https://www.makeareadme.com/) आहेत जी तुम्हाला वापरायला आवडतील.
✅ README फाइल्स, जरी तयार करण्यासाठी वेळ लागतो, व्यस्त देखरेख करणाऱ्यांकडून अनेकदा दुर्लक्षित केल्या जातात. तुम्हाला विशेषतः वर्णनात्मक README चे उदाहरण सापडते का? टीप: [चांगले README तयार करण्यासाठी काही साधने](https://www.makeareadme.com/) आहेत जी तुम्हाला वापरून पहायची असतील.
### कार्य: काही कोड मर्ज करा
योगदान दस्तऐवज लोकांना प्रकल्पात योगदान देण्यास मदत करतात. यात तुम्ही कोणत्या प्रकारचे योगदान शोधत आहात आणि प्रक्रिया कशी कार्य करते याचे स्पष्टीकरण दिले जाते. योगदानकर्त्यांना GitHub वर तुमच्या रिपॉझिटरीमध्ये योगदान देण्यासाठी काही चरणांमधून जावे लागेल:
योगदान दस्तऐवज लोकांना प्रकल्पात योगदान देण्यास मदत करतात. यात तुम्ही कोणत्या प्रकारचे योगदान शोधत आहात आणि प्रक्रिया कशी कार्य करते याचे स्पष्टीकरण दिले आहे. योगदानकर्त्यांना GitHub वर तुमच्या रिपॉझिटरीमध्ये योगदान देण्यासाठी काही चरणांमधून जावे लागेल:
1. **तुमची रिपॉझिटरी फोर्क करणे**. तुम्हाला कदाचित लोकांना तुमचा प्रकल्प _fork_ करायला सांगायचे असेल. फोर्क करणे म्हणजे त्यांच्या GitHub प्रोफाइलवर तुमच्या रिपॉझिटरीची प्रत तयार करणे.
1. **तुमची रिपॉझिटरी फोर्क करणे** तुम्हाला कदाचित लोकांना तुमचा प्रकल्प _फोर्क_ करायचा असेल. फोर्क करणे म्हणजे त्यांच्या GitHub प्रोफाइलवर तुमच्या रिपॉझिटरीची प्रत तयार करणे.
1. **क्लोन**. त्यानंतर ते प्रकल्प त्यांच्या स्थानिक मशीनवर क्लोन करतील.
1. **शाखा तयार करा**. तुम्ही त्यांना त्यांच्या कामासाठी _शाखा_ तयार करण्यास सांगाल.
1. **त्यांचा बदल एका क्षेत्रावर केंद्रित करा**. योगदानकर्त्यांना एकावेळी एका गोष्टीवर लक्ष केंद्रित करण्यास सांगा - अशा प्रकारे त्यांचे काम _मर्ज_होण्याची शक्यता जास्त आहे. कल्पना करा त्यांनी बग फिक्स लिहिला, नवीन वैशिष्ट्य जोडले आणि अनेक चाचण्या अपडेट केल्या - काय असेल जर तुम्हाला 3 पैकी 2 किंवा 3 पैकी 1 बदल लागू करायचा असेल?
1. **त्यांचा बदल एका क्षेत्रावर केंद्रित करा**. योगदानकर्त्यांना एकावेळी एका गोष्टीवर लक्ष केंद्रित करण्यास सांगा - अशा प्रकारे तुम्ही त्यांचे काम _मर्ज_करण्याची शक्यता जास्त आहे. कल्पना करा त्यांनी बग फिक्स लिहिला, नवीन वैशिष्ट्य जोडले आणि अनेक चाचण्या अपडेट केल्या - काय असेल तर तुम्हाला 3 पैकी 2 किंवा 3 पैकी 1 बदल लागू करायचा आहे किंवा लागू करता येतो?
✅ अशा परिस्थितीची कल्पना करा जिथे शाखा चांगला कोड लिहिण्यासाठी आणि वितरित करण्यासाठी विशेषतः महत्त्वपूर्ण आहेत. तुम्ही कोणते उपयोग प्रकरणे विचार करू शकता?
✅ शाखा लिहिणे आणि चांगला कोड तयार करणे यासाठी शाखा विशेषतः महत्त्वाच्या असलेल्या परिस्थितीची कल्पना करा. तुम्ही कोणते उपयोग प्रकरणे विचार करू शकता?
> टीप, तुम्ही जगात पाहू इच्छित असलेला बदल व्हा आणि तुमच्या स्वतःच्या कामासाठी शाखा तयार करा. तुम्ही केलेले कोणतेही commits तुम्ही सध्या "चेक आउट" केलेल्या शाखेत केले जातील. `git status` वापरून तुम्ही कोणत्या शाखेत आहात ते पहा.
> टीप, तुम्ही जगात पाहू इच्छित असलेला बदल व्हा आणि तुमच्या स्वतःच्या कामासाठी शाखा तयार करा. तुम्ही केलेले कोणतेही कमिट तुम्ही सध्या "चेक आउट" केलेल्या शाखेवर केले जातील. तुम्ही कोणत्या शाखेवर आहात हे पाहण्यासाठी `git status` वापरा.
आम्ही योगदानकर्त्याच्या वर्कफ्लोमधून जाऊया. गृहीत धरा की योगदानकर्त्याने आधीच रिपॉझिटरी _fork_ आणि _clone_ केली आहे त्यामुळे त्यांच्याकडे स्थानिक मशीनवर काम करण्यासाठी Git रिपॉझिटरी तयार आहे:
चला योगदानकर्त्याच्या कार्यप्रवाहातून जाऊया. समजा योगदानकर्त्याने आधीच रिपॉझिटरी _फोर्क_ आणि _क्लोन_ केली आहे त्यामुळे त्यांच्याकडे स्थानिक मशीनवर काम करण्यासाठी Git रिपॉझिटरी तयार आहे:
1. **शाखा तयार करा**. `git branch` कमांड वापरून शाखा तयार करा ज्यामध्ये ते योगदान देण्याचा विचार करत असलेले बदल असतील:
@ -226,114 +226,119 @@ GitHub वर गोष्टी ठेवण्याचे मुख्य क
git switch [branch-name]
```
1. **काम करा**. या टप्प्यावर तुम्हाला तुमचे बदल जोडायचे आहेत. खालील कमांड वापरून Git ला त्याबद्दल सांगायला विसरू नका:
1. **काम करा**. या टप्प्यावर तुम्हाला तुमचे बदल जोडायचे आहेत. खालील कमांड वापरून Git ला सांगायला विसरू नका:
```bash
git add .
git commit -m "my changes"
```
तुमच्या commit ला चांगले नाव द्या, तुमच्यासाठी तसेच तुम्ही मदत करत असलेल्या रिपॉझिटरीच्या देखरेख करणाऱ्यासाठी.
तुमच्या कमिटला चांगले नाव द्या, तुमच्यासाठी तसेच तुम्ही मदत करत असलेल्या रिपॉझिटरीच्या देखरेख करणाऱ्यासाठी.
1. **तुमचे काम `main` शाखेसोबत एकत्र करा**. एका टप्प्यावर तुम्ही काम पूर्ण केले आहे आणि तुम्हाला तुमचे काम `main` शाखेसोबत एकत्र करायचे आहे. दरम्यान `main` शाखा बदलली असू शकते त्यामुळे खालील कमांड वापरून ती नवीनतम स्थितीत अपडेट करा:
1. **तुमचे काम `main` शाखेसोबत एकत्र करा**. काही वेळाने तुम्ही काम पूर्ण केले आहे आणि तुम्हाला तुमचे काम `main` शाखेसोबत एकत्र करायचे आहे. दरम्यान `main` शाखा बदलली असू शकते त्यामुळे खालील कमांडसह ती नवीनतम असल्याचे सुनिश्चित करा:
```bash
git switch main
git pull
```
या टप्प्यावर तुम्हाला खात्री करायची आहे की कोणतेही _conflicts_, जिथे Git सहजपणे _combine_करू शकत नाही, तुमच्या कार्यरत शाखेत होतात. म्हणून खालील कमांड चालवा:
या टप्प्यावर तुम्हाला कोणतेही _conflicts_, जिथे Git सहजपणे _combine_बदल करू शकत नाही अशा परिस्थिती तुमच्या कार्यरत शाखेत होण्याची खात्री करायची आहे. म्हणून खालील कमांड चालवा:
```bash
git switch [branch_name]
git merge main
```
हे `main` मधील सर्व बदल तुमच्या शाखेत आणेल आणि आशा आहे की तुम्ही फक्त पुढे जाऊ शकता. जर तसे नसेल, तर VS Code तुम्हाला सांगेल की Git _गोंधळलेला_ आहे आणि तुम्ही प्रभावित फाइल्स बदलून कोणती सामग्री सर्वात अचूक आहे ते सांगू शकता.
`git merge main` कमांड `main` मधील सर्व बदल तुमच्या शाखेत आणेल. आशा आहे की तुम्ही फक्त पुढे जाऊ शकता. जर तसे नसेल तर, VS Code तुम्हाला सांगेल की Git कुठे _confused_ आहे आणि तुम्ही प्रभावित फाइल्स बदलून कोणती सामग्री सर्वात अचूक आहे ते सांगाल.
वेगळ्या शाखेत स्विच करण्यासाठी, आधुनिक `git switch` कमांड वापरा:
```bash
git switch [branch_name]
1. **तुमचे काम GitHub वर पाठवा**. GitHub वर तुमचे काम पाठवणे म्हणजे दोन गोष्टी. तुमची शाखा तुमच्या रिपॉझिटरीवर पुश करणे आणि नंतर PR, Pull Request उघडणे.
1. **तुमचे काम GitHub वर पाठवा**. तुमचे काम GitHub वर पाठवणे म्हणजे दोन गोष्टी. तुमची शाखा तुमच्या रिपॉझिटरीवर पुश करणे आणि नंतर PR, Pull Request उघडणे.
```bash
git push --set-upstream origin [branch-name]
```
वरील कमांड तुमच्या फोर्क केलेल्या रिपॉझिटरीवर शाखा तयार करते.
1. **PR उघडा**. पुढे, तुम्हाला PR उघडायचा आहे. तुम्ही GitHub वर fork केलेल्या रेपोवर जाऊन ते करू शकता. GitHub वर तुम्हाला एक सूचना दिसेल जिथे विचारले जाते की तुम्हाला नवीन PR तयार करायचा आहे का, तुम्ही त्यावर क्लिक करा आणि तुम्हाला अशा इंटरफेसवर नेले जाईल जिथे तुम्ही commit message चे शीर्षक बदलू शकता, त्याला अधिक योग्य वर्णन देऊ शकता. आता तुम्ही fork केलेल्या रेपोचा maintainer हा PR पाहील आणि _बोटे क्रॉस करून_ ते तुमच्या PR चे कौतुक करतील आणि _merge_ करतील. तुम्ही आता contributor आहात, याय :)
1. **PR उघडा**. पुढे, तुम्हाला PR उघडायचा आहे. तुम्ही GitHub वर फोर्क केलेल्या रिपॉझिटरीवर नेव्हिगेट करून ते करू शकता. GitHub वर तुम्हाला नवीन PR तयार करायचा आहे का असे विचारणारा संकेत दिसेल, तुम्ही त्यावर क्लिक करा आणि तुम्हाला commit message शीर्षक बदलण्यासाठी, अधिक योग्य वर्णन देण्यासाठी इंटरफेसवर नेले जाईल. आता तुम्ही फोर्क केलेल्या रिपॉझिटरीचा देखरेख करणारा हा PR पाहील आणि _बोटे क्रॉस_ करून ते तुमचा PR _मर्ज_ करतील. तुम्ही आता योगदानकर्ता आहात, याय :)
1. **स्वच्छता करा**. PR यशस्वीरित्या मर्ज केल्यानंतर _स्वच्छता_ करणे चांगली पद्धत मानली जाते. तुम्हाला तुमची स्थानिक शाखा आणि तुम्ही GitHub वर पुश केलेली शाखा साफ करायची आहे. प्रथम खालील कमांड वापरून ती स्थानिक स्तरावर हटवा:
1. **स्वच्छता करा**. PR यशस्वीपणे merge केल्यानंतर _स्वच्छता_ करणे चांगली पद्धत मानली जाते. तुम्हाला तुमची स्थानिक शाखा आणि GitHub वर तुम्ही पुश केलेली शाखा दोन्ही स्वच्छ करायची आहेत. प्रथम, खालील कमांडसह ती स्थानिकपणे हटवूया:
```bash
git branch -d [branch-name]
```
पुढे, फोर्क केलेल्या रिपॉझिटरीसाठी GitHub पेजवर जा आणि तुम्ही त्यावर पुश केलेली रिमोट शाखा हटवा.
`Pull request` हा शब्द थोडा विचित्र वाटतो कारण प्रत्यक्षात तुम्हाला तुमचे बदल प्रकल्पात `push` करायचे असतात. परंतु प्रकल्पाचा देखभालकर्ता (project owner) किंवा मुख्य टीमला तुमचे बदल प्रकल्पाच्या "main" शाखेत विलीन करण्यापूर्वी विचार करावा लागतो, त्यामुळे तुम्ही प्रत्यक्षात देखभालकर्त्याकडून बदलाचा निर्णय मागत आहात.
नंतर GitHub पृष्ठावर जा जिथे fork केलेला रेपो आहे आणि तुम्ही पुश केलेली remote शाखा हटवा.
`Pull request` हा शब्द थोडा विचित्र वाटतो कारण प्रत्यक्षात तुम्हाला तुमचे बदल प्रकल्पात पुश करायचे आहेत. पण maintainer (प्रकल्प मालक) किंवा core टीमला तुमचे बदल merge करण्यापूर्वी विचार करणे आवश्यक आहे, त्यामुळे तुम्ही प्रत्यक्षात maintainer कडून बदलाचा निर्णय मागत आहात.
`Pull request` हे एक असे ठिकाण आहे जिथे शाखेत केलेल्या बदलांची तुलना आणि चर्चा केली जाते, त्यात पुनरावलोकने, टिप्पण्या, समाकलित चाचण्या आणि बरेच काही समाविष्ट असते. एक चांगले `pull request` साधारणपणे `commit message` सारखेच नियम पाळते. जर तुमचे काम एखाद्या समस्येचे निराकरण करत असेल तर तुम्ही `issue tracker` मध्ये त्या समस्येचा संदर्भ देऊ शकता. हे `#` आणि तुमच्या समस्येच्या क्रमांकाचा वापर करून केले जाते. उदाहरणार्थ,`#97`.
Pull request ही एक जागा आहे जिथे शाखेत केलेल्या बदलांची तुलना आणि चर्चा केली जाते, त्यात reviews, comments, integrated tests आणि बरेच काही असते. चांगला pull request commit message सारख्याच नियमांचे अनुसरण करतो. तुम्ही issue tracker मध्ये issue संदर्भ जोडू शकता, उदाहरणार्थ तुमचे काम एखाद्या issue ला सोडवते तेव्हा. हे `#` आणि तुमच्या issue चा क्रमांक वापरून केले जाते. उदाहरणार्थ `#97`.
🤞बोटे क्रॉस करा की सर्व चाचण्या पास होतील आणि प्रकल्प मालक तुमचे बदल प्रकल्पात विलीन करतील🤞
🤞बोटे क्रॉस करून आशा आहे की सर्व चाचण्या पास होतील आणि प्रकल्प मालक तुमचे बदल प्रकल्पात merge करतील🤞
तुमच्या स्थानिक शाखेत GitHub वरील संबंधित `remote branch` मधील सर्व नवीन `commits` अपडेट करा:
GitHub वरच्या संबंधित remote शाखेतील सर्व नवीन commits सह तुमची सध्याची स्थानिक कार्यरत शाखा अपडेट करा:
`git pull`
## ओपन सोर्समध्ये योगदान कसे करावे
## ओपन सोर्समध्ये योगदान कसे द्यावे
सर्वप्रथम, GitHub वर तुमच्या आवडीचा आणि ज्यामध्ये तुम्हाला बदल करायचा आहे असा एखादा `repository` (किंवा **repo**) शोधा. तुम्हाला त्याची सामग्री तुमच्या मशीनवर कॉपी करायची असेल.
सर्वप्रथम, GitHub वर तुमच्या आवडीचा आणि ज्यामध्ये तुम्हाला बदल करायचा आहे असा रेपो (किंवा **repository**) शोधूया. तुम्हाला त्याची सामग्री तुमच्या मशीनवर कॉपी करायची आहे.
✅ 'beginner-friendly' `repos` शोधण्यासाठी [टॅग 'good-first-issue' ने शोधा](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ 'beginner-friendly' रेपो शोधण्याचा चांगला मार्ग म्हणजे [टॅग 'good-first-issue' ने शोधा](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
कोड कॉपी करण्याचे अनेक मार्ग आहेत. एक मार्ग म्हणजे HTTPS, SSH किंवा GitHub CLI (Command Line Interface) वापरून `repository`ची सामग्री "clone" करणे.
कोड कॉपी करण्याचे अनेक मार्ग आहेत. एक मार्ग म्हणजे HTTPS, SSH किंवा GitHub CLI (Command Line Interface) वापरून रेपोची सामग्री "clone" करणे.
तुमचा टर्मिनल उघडा आणि `repository` असे `clone` करा:
तुमचा टर्मिनल उघडा आणि रेपो खालीलप्रमाणे clone करा:
`git clone https://github.com/ProjectURL`
प्रकल्पावर काम करण्यासाठी योग्य फोल्डरमध्ये जा:
प्रकल्पावर काम करण्यासाठी, योग्य फोल्डरमध्ये जा:
`cd ProjectURL`
तुम्ही [Codespaces](https://github.com/features/codespaces), GitHub चे एम्बेडेड कोड एडिटर / क्लाउड डेव्हलपमेंट एन्व्हायर्नमेंट किंवा [GitHub Desktop](https://desktop.github.com/) वापरून संपूर्ण प्रकल्प उघडू शकता.
तुम्ही [Codespaces](https://github.com/features/codespaces), GitHub चा embedded code editor / cloud development environment, किंवा [GitHub Desktop](https://desktop.github.com/) वापरून संपूर्ण प्रकल्प उघडू शकता.
शेवटी, तुम्ही कोड झिप केलेल्या फोल्डरमध्ये डाउनलोड करू शकता.
शेवटी, तुम्ही कोड एका zipped फोल्डरमध्ये डाउनलोड करू शकता.
### GitHub बद्दल आणखी काही मनोरंजक गोष्टी
तुम्ही GitHub वरील कोणत्याही सार्वजनिक `repository` ला स्टार, वॉच आणि/किंवा "fork" करू शकता. तुमच्या स्टार केलेल्या `repositories` तुम्हाला वरच्या उजव्या ड्रॉप-डाउन मेनूमध्ये सापडतील. हे कोडसाठी बुकमार्क करण्यासारखे आहे.
तुम्ही GitHub वर कोणत्याही सार्वजनिक रेपोला स्टार, watch आणि/किंवा "fork" करू शकता. तुम्ही तुमचे starred रेपो वरच्या उजव्या drop-down मेनूमध्ये शोधू शकता. हे bookmarking सारखे आहे, पण कोडसाठी.
प्रकल्पांमध्ये `issue tracker` असतो, मुख्यतः GitHub वर "Issues" टॅबमध्ये, जोपर्यंत वेगळे सांगितले नाही, जिथे लोक प्रकल्पाशी संबंधित समस्यांवर चर्चा करतात. आणि `Pull Requests` टॅबमध्ये लोक प्रगतीपथावर असलेल्या बदलांवर चर्चा आणि पुनरावलोकन करतात.
प्रकल्पांमध्ये issue tracker असतो, मुख्यतः GitHub वर "Issues" टॅबमध्ये, जोपर्यंत वेगळे सांगितले नाही, जिथे लोक प्रकल्पाशी संबंधित समस्यांवर चर्चा करतात. आणि Pull Requests टॅब ही जागा आहे जिथे लोक प्रगतीत असलेल्या बदलांवर चर्चा आणि पुनरावलोकन करतात.
प्रकल्पांमध्ये फोरम, मेलिंग लिस्ट किंवा Slack, Discord किंवा IRC सारख्या चॅट चॅनेलमध्ये चर्चा असू शकते.
प्रकल्पांमध्ये forums, mailing lists, किंवा Slack, Discord किंवा IRC सारख्या chat channels मध्ये चर्चा असू शकते.
✅ तुमच्या नवीन GitHub `repo` चा फेरफटका मारा आणि काही गोष्टी करून पहा, जसे की सेटिंग्ज संपादित करणे, तुमच्या `repo`मध्ये माहिती जोडणे आणि प्रकल्प तयार करणे (जसे की Kanban बोर्ड). तुम्ही बरेच काही करू शकता!
✅ तुमच्या नवीन GitHub रेपोमध्ये फेरफटका मारा आणि काही गोष्टी करून पहा, जसे की सेटिंग्ज संपादित करणे, तुमच्या रेपोमध्ये माहिती जोडणे, आणि प्रकल्प तयार करणे (जसे की Kanban बोर्ड). तुम्ही खूप काही करू शकता!
---
## 🚀 आव्हान
## 🚀 आव्हान
मित्रासोबत जोडी बनवा आणि एकमेकांच्या कोडवर काम करा. एकत्रितपणे प्रकल्प तयार करा, कोड `fork` करा, शाखा तयार करा आणि बदल विलीन करा.
मित्रासोबत जोडी बनवा आणि एकमेकांच्या कोडवर काम करा. एकत्र प्रकल्प तयार करा, कोड fork करा, शाखा तयार करा, आणि बदल merge करा.
सराव करा, सराव करा, सराव करा. GitHub कडे [skills.github.com](https://skills.github.com) द्वारे उपलब्ध उत्कृष्ट शिक्षण मार्ग आहेत:
अभ्यास करा, सराव करा, सराव करा. GitHub कडे [skills.github.com](https://skills.github.com) द्वारे उपलब्ध उत्कृष्ट शिक्षण मार्ग आहेत:
- [GitHub वर पहिला आठवडा](https://skills.github.com/#first-week-on-github)
तुम्हाला अधिक प्रगत अभ्यासक्रम देखील सापडतील.
## असाइनमेंट
## असाइनमेंट
[GitHub वर पहिला आठवडा कोर्स पूर्ण करा](https://skills.github.com/#first-week-on-github)
---
**अस्वीकरण**:
हा दस्तऐवज AI भाषांतर सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) वापरून भाषांतरित करण्यात आला आहे. आम्ही अचूकतेसाठी प्रयत्नशील असलो तरी कृपया लक्षात ठेवा की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेचा अभाव असू शकतो. मूळ भाषेतील दस्तऐवज हा अधिकृत स्रोत मानला जावा. महत्त्वाच्या माहितीसाठी व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराचा वापर करून निर्माण होणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थासाठी आम्ही जबाबदार राहणार नाही.
हा दस्तऐवज [Co-op Translator](https://github.com/Azure/co-op-translator) या एआय भाषांतर सेवेचा वापर करून भाषांतरित करण्यात आला आहे. आम्ही अचूकतेसाठी प्रयत्नशील असलो तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेचा अभाव असू शकतो. मूळ भाषेतील दस्तऐवज हा अधिकृत स्रोत मानला जावा. महत्त्वाच्या माहितीसाठी व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराचा वापर केल्यामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थासाठी आम्ही जबाबदार राहणार नाही.
@ -22,12 +22,12 @@ Pelajaran ini merangkumi asas GitHub, sebuah platform untuk menghoskan dan mengu
Dalam pelajaran ini, kita akan membincangkan:
- menjejaki kerja yang anda lakukan pada mesin anda
- bekerja pada projek bersama orang lain
- bekerjasama dalam projek dengan orang lain
- cara menyumbang kepada perisian sumber terbuka
### Prasyarat
Sebelum anda bermula, anda perlu memeriksa sama ada Git telah dipasang. Dalam terminal taip:
Sebelum anda bermula, pastikan Git telah dipasang. Dalam terminal, taip:
`git --version`
Jika Git belum dipasang, [muat turun Git](https://git-scm.com/downloads). Kemudian, tetapkan profil Git tempatan anda dalam terminal:
@ -39,19 +39,19 @@ Untuk memeriksa sama ada Git telah dikonfigurasi, anda boleh taip:
Anda juga memerlukan akaun GitHub, editor kod (seperti Visual Studio Code), dan anda perlu membuka terminal anda (atau: command prompt).
Navigasi ke [github.com](https://github.com/) dan buat akaun jika anda belum ada, atau log masuk dan lengkapkan profil anda.
Navigasi ke [github.com](https://github.com/) dan buat akaun jika anda belum ada, atau log masuk dan lengkapkan profil anda.
✅ GitHub bukan satu-satunya repositori kod di dunia; terdapat yang lain, tetapi GitHub adalah yang paling terkenal.
### Persediaan
Anda memerlukan folder dengan projek kod pada mesin tempatan anda (laptop atau PC), dan repositori awam di GitHub, yang akan berfungsi sebagai contoh bagaimana untuk menyumbang kepada projek orang lain.
Anda memerlukan folder dengan projek kod pada mesin tempatan anda (laptop atau PC), dan repositori awam di GitHub, yang akan berfungsi sebagai contoh bagaimana untuk menyumbang kepada projek orang lain.
---
## Pengurusan Kod
Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin mula menjejaki kemajuan anda menggunakan git - sistem kawalan versi. Sesetengah orang membandingkan penggunaan git dengan menulis surat cinta kepada diri anda di masa depan. Membaca mesej commit anda beberapa hari, minggu, atau bulan kemudian akan membantu anda mengingati mengapa anda membuat keputusan tertentu, atau "rollback" perubahan - iaitu, apabila anda menulis mesej commit yang baik.
Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin mula menjejaki kemajuan anda menggunakan git - sistem kawalan versi. Sesetengah orang membandingkan penggunaan git dengan menulis surat cinta kepada diri anda di masa depan. Membaca mesej commit anda beberapa hari, minggu, atau bulan kemudian akan membantu anda mengingat mengapa anda membuat keputusan tertentu, atau "rollback" perubahan - iaitu, apabila anda menulis mesej commit yang baik.
### Tugasan: Buat repositori dan commit kod
@ -59,9 +59,9 @@ Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin m
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Buat repositori di GitHub**. Di GitHub.com, dalam tab repositori, atau dari bar navigasi di bahagian atas kanan, cari butang **new repo**.
1. **Buat repositori di GitHub**. Di GitHub.com, dalam tab repositori, atau dari bar navigasi di kanan atas, cari butang **new repo**.
1. Berikan nama kepada repositori (folder) anda.
1. Berikan nama kepada repositori anda (folder)
1. Pilih **create repository**.
1. **Navigasi ke folder kerja anda**. Dalam terminal anda, beralih ke folder (juga dikenali sebagai direktori) yang anda ingin mula jejaki. Taip:
@ -93,16 +93,16 @@ Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin m
modified: file2.txt
```
Biasanya, arahan `git status` memberitahu anda perkara seperti fail mana yang sedia untuk _disimpan_ ke repositori atau mempunyai perubahan yang mungkin anda ingin kekalkan.
Biasanya, arahan `git status` memberitahu anda perkara seperti fail mana yang sedia untuk _disimpan_ ke repositori atau mempunyai perubahan yang mungkin ingin anda kekalkan.
1. **Tambah semua fail untuk penjejakan**
Ini juga dikenali sebagai memuatkan fail/memasukkan fail ke kawasan staging.
Ini juga dikenali sebagai fail staging/menambah fail ke kawasan staging.
```bash
git add .
```
Argumen `git add` ditambah dengan `.` menunjukkan bahawa semua fail & perubahan anda untuk penjejakan.
Argumen `git add` ditambah dengan `.` menunjukkan bahawa semua fail & perubahan anda untuk penjejakan.
1. **Tambah fail terpilih untuk penjejakan**
@ -112,41 +112,41 @@ Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin m
Ini membantu kita menambah hanya fail terpilih ke kawasan staging apabila kita tidak mahu commit semua fail sekaligus.
1. **Batalkan pemuatan semua fail**
1. **Batalkan staging semua fail**
```bash
git reset
```
Arahan ini membantu kita membatalkan pemuatan semua fail sekaligus.
Arahan ini membantu kita membatalkan staging semua fail sekaligus.
1. **Batalkan pemuatan fail tertentu**
1. **Batalkan staging fail tertentu**
```bash
git reset [file or folder name]
```
Arahan ini membantu kita membatalkan pemuatan hanya fail tertentu sekaligus yang kita tidak mahu sertakan untuk commit seterusnya.
Arahan ini membantu kita membatalkan staging hanya fail tertentu sekaligus yang kita tidak mahu sertakan untuk commit seterusnya.
1. **Kekalkan kerja anda**. Pada ketika ini anda telah menambah fail ke kawasan yang dipanggil _staging area_. Tempat di mana Git menjejaki fail anda. Untuk menjadikan perubahan kekal, anda perlu _commit_ fail tersebut. Untuk melakukannya, anda membuat _commit_ dengan arahan `git commit`. _Commit_ mewakili titik simpanan dalam sejarah repositori anda. Taip arahan berikut untuk membuat _commit_:
1. **Kekalkan kerja anda**. Pada tahap ini, anda telah menambah fail ke kawasan yang dipanggil _staging area_. Tempat di mana Git menjejaki fail anda. Untuk menjadikan perubahan kekal, anda perlu _commit_ fail tersebut. Untuk melakukannya, anda membuat _commit_ dengan arahan `git commit`. _Commit_ mewakili titik simpanan dalam sejarah repositori anda. Taip arahan berikut untuk membuat _commit_:
```bash
git commit -m "first commit"
```
Ini akan commit semua fail anda, dengan mesej "first commit". Untuk mesej commit masa depan, anda akan mahu lebih deskriptif dalam penerangan anda untuk menyampaikan jenis perubahan yang telah anda buat.
Ini commit semua fail anda, dengan mesej "first commit". Untuk mesej commit masa depan, anda akan mahu lebih deskriptif dalam penerangan anda untuk menyampaikan jenis perubahan yang telah anda buat.
1. **Sambungkan repositori Git tempatan anda dengan GitHub**. Repositori Git adalah baik pada mesin anda tetapi pada satu ketika anda ingin mempunyai sandaran fail anda di tempat lain dan juga menjemput orang lain untuk bekerja dengan anda pada repositori anda. Salah satu tempat yang hebat untuk melakukannya ialah GitHub. Ingat kita telah membuat repositori di GitHub jadi satu-satunya perkara yang perlu kita lakukan ialah menyambungkan repositori Git tempatan kita dengan GitHub. Arahan `git remote add` akan melakukannya. Taip arahan berikut:
1. **Sambungkan repositori Git tempatan anda dengan GitHub**. Repositori Git adalah baik pada mesin anda tetapi pada satu ketika anda ingin mempunyai sandaran fail anda di suatu tempat dan juga menjemput orang lain untuk bekerja dengan anda pada repositori anda. Salah satu tempat yang hebat untuk melakukannya ialah GitHub. Ingat kita telah membuat repositori di GitHub, jadi satu-satunya perkara yang perlu kita lakukan ialah menyambungkan repositori Git tempatan kita dengan GitHub. Arahan `git remote add` akan melakukan perkara itu. Taip arahan berikut:
> Nota, sebelum anda taip arahan pergi ke halaman repositori GitHub anda untuk mencari URL repositori. Anda akan menggunakannya dalam arahan di bawah. Gantikan ```https://github.com/username/repository_name.git``` dengan URL GitHub anda.
> Nota, sebelum anda taip arahan, pergi ke halaman repositori GitHub anda untuk mencari URL repositori. Anda akan menggunakannya dalam arahan di bawah. Gantikan ```https://github.com/username/repository_name.git``` dengan URL GitHub anda.
Ini mencipta _remote_, atau sambungan, bernama "origin" yang menunjuk kepada repositori GitHub yang anda buat sebelum ini.
Ini mencipta _remote_, atau sambungan, yang dinamakan "origin" yang menunjuk kepada repositori GitHub yang anda buat sebelum ini.
1. **Hantar fail tempatan ke GitHub**. Setakat ini anda telah mencipta _sambungan_ antara repositori tempatan dan repositori GitHub. Mari hantar fail ini ke GitHub dengan arahan `git push`, seperti berikut:
1. **Hantar fail tempatan ke GitHub**. Setakat ini, anda telah mencipta _sambungan_ antara repositori tempatan dan repositori GitHub. Mari hantar fail ini ke GitHub dengan arahan `git push`, seperti berikut:
> Nota, nama cawangan anda mungkin berbeza secara lalai daripada ```main```.
@ -154,7 +154,7 @@ Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin m
git push -u origin main
```
Ini menghantar commit anda dalam cawangan "main" anda ke GitHub.
Ini menghantar commit anda dalam cawangan "main" anda ke GitHub. Menetapkan cawangan `upstream` termasuk `-u` dalam arahan mewujudkan pautan antara cawangan tempatan anda dan cawangan jauh, jadi anda boleh menggunakan git push atau git pull tanpa menentukan nama cawangan pada masa depan. Git akan secara automatik menggunakan cawangan upstream dan anda tidak perlu menentukan nama cawangan secara eksplisit dalam arahan masa depan.
2. **Untuk menambah lebih banyak perubahan**. Jika anda ingin terus membuat perubahan dan menghantarnya ke GitHub, anda hanya perlu menggunakan tiga arahan berikut:
@ -164,23 +164,23 @@ Katakan anda mempunyai folder secara tempatan dengan projek kod dan anda ingin m
git push
```
> Tip, Anda mungkin juga ingin menggunakan fail `.gitignore` untuk mengelakkan fail yang anda tidak mahu jejaki daripada muncul di GitHub - seperti fail nota yang anda simpan dalam folder yang sama tetapi tidak sesuai untuk repositori awam. Anda boleh mencari templat untuk fail `.gitignore` di [.gitignore templates](https://github.com/github/gitignore).
> Tip, Anda mungkin juga ingin menggunakan fail `.gitignore` untuk mengelakkan fail yang anda tidak mahu jejaki daripada muncul di GitHub - seperti fail nota yang anda simpan dalam folder yang sama tetapi tidak sesuai di repositori awam. Anda boleh mencari templat untuk fail `.gitignore` di [.gitignore templates](https://github.com/github/gitignore).
#### Mesej Commit
Baris subjek commit Git yang hebat melengkapkan ayat berikut:
Jika digunakan, commit ini akan <barissubjekandadisini>
Untuk subjek, gunakan bentuk imperatif, masa kini: "ubah" bukan "diubah" atau "mengubah".
Seperti dalam subjek, dalam badan (pilihan) juga gunakan bentuk imperatif, masa kini. Badan harus merangkumi motivasi untuk perubahan dan bandingkan ini dengan tingkah laku sebelumnya. Anda menerangkan `mengapa`, bukan `bagaimana`.
Untuk subjek, gunakan bentuk perintah, masa kini: "ubah" bukan "diubah" atau "mengubah".
Seperti dalam subjek, dalam badan (pilihan) juga gunakan bentuk perintah, masa kini. Badan harus merangkumi motivasi untuk perubahan dan bandingkan ini dengan tingkah laku sebelumnya. Anda menerangkan `mengapa`, bukan `bagaimana`.
✅ Luangkan beberapa minit untuk melayari GitHub. Bolehkah anda menemui mesej commit yang sangat hebat? Bolehkah anda menemui yang sangat minimal? Apakah maklumat yang anda fikir paling penting dan berguna untuk disampaikan dalam mesej commit?
### Tugasan: Bekerjasama
Sebab utama meletakkan perkara di GitHub adalah untuk memungkinkan kerjasama dengan pembangun lain.
Sebab utama meletakkan sesuatu di GitHub adalah untuk memungkinkan kerjasama dengan pembangun lain.
## Bekerja pada projek bersama orang lain
## Bekerja pada projek dengan orang lain
> Tonton video
>
@ -196,7 +196,7 @@ Dalam repositori anda, navigasi ke `Insights > Community` untuk melihat bagaiman
- **Lesen**. Mungkin yang paling penting, [lesen](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Semua sumber ini akan memberi manfaat kepada onboarding ahli pasukan baru. Dan ini biasanya perkara yang dilihat oleh penyumbang baru sebelum melihat kod anda, untuk mengetahui sama ada projek anda adalah tempat yang sesuai untuk mereka meluangkan masa.
Semua sumber ini akan memberi manfaat kepada onboarding ahli pasukan baru. Dan ini biasanya jenis perkara yang dilihat oleh penyumbang baru sebelum mereka melihat kod anda, untuk mengetahui sama ada projek anda adalah tempat yang sesuai untuk mereka meluangkan masa mereka.
✅ Fail README, walaupun memerlukan masa untuk disediakan, sering diabaikan oleh penyelenggara yang sibuk. Bolehkah anda menemui contoh yang sangat deskriptif? Nota: terdapat beberapa [alat untuk membantu mencipta README yang baik](https://www.makeareadme.com/) yang mungkin anda ingin cuba.
@ -204,14 +204,14 @@ Semua sumber ini akan memberi manfaat kepada onboarding ahli pasukan baru. Dan i
Dokumen penyumbangan membantu orang menyumbang kepada projek. Ia menerangkan jenis sumbangan yang anda cari dan bagaimana prosesnya berfungsi. Penyumbang perlu melalui beberapa langkah untuk dapat menyumbang kepada repositori anda di GitHub:
1. **Fork repositori anda** Anda mungkin mahu orang _fork_ projek anda. Fork bermaksud mencipta replika repositori anda pada profil GitHub mereka.
1. **Fork repositori anda** Anda mungkin ingin orang _fork_ projek anda. Fork bermaksud mencipta replika repositori anda pada profil GitHub mereka.
1. **Clone**. Dari situ mereka akan clone projek ke mesin tempatan mereka.
1. **Buat cawangan**. Anda akan mahu meminta mereka membuat _cawangan_ untuk kerja mereka.
1. **Fokuskan perubahan mereka pada satu kawasan**. Minta penyumbang untuk menumpukan sumbangan mereka pada satu perkara pada satu masa - dengan cara itu peluang untuk anda _merge_ kerja mereka adalah lebih tinggi. Bayangkan mereka menulis pembaikan bug, menambah ciri baru, dan mengemas kini beberapa ujian - bagaimana jika anda mahu, atau hanya boleh melaksanakan 2 daripada 3, atau 1 daripada 3 perubahan?
1. **Buat cawangan**. Anda akan ingin meminta mereka membuat _cawangan_ untuk kerja mereka.
1. **Fokuskan perubahan mereka pada satu kawasan**. Minta penyumbang untuk menumpukan sumbangan mereka pada satu perkara pada satu masa - dengan cara itu peluang untuk anda _merge_ kerja mereka adalah lebih tinggi. Bayangkan mereka menulis pembaikan bug, menambah ciri baru, dan mengemas kini beberapa ujian - bagaimana jika anda ingin, atau hanya boleh melaksanakan 2 daripada 3, atau 1 daripada 3 perubahan?
✅ Bayangkan situasi di mana cawangan sangat kritikal untuk menulis dan menghantar kod yang baik. Apakah kes penggunaan yang boleh anda fikirkan?
> Nota, jadilah perubahan yang anda ingin lihat di dunia, dan buat cawangan untuk kerja anda sendiri juga. Sebarang commit yang anda buat akan dibuat pada cawangan yang anda sedang "checked out". Gunakan `git status` untuk melihat cawangan mana itu.
> Nota, jadilah perubahan yang anda ingin lihat di dunia, dan buat cawangan untuk kerja anda sendiri juga. Sebarang commit yang anda buat akan dibuat pada cawangan yang anda sedang "checked out". Gunakan `git status` untuk melihat cawangan mana yang sedang digunakan.
Mari kita lalui aliran kerja penyumbang. Anggap penyumbang telah _fork_ dan _clone_ repositori jadi mereka mempunyai repositori Git yang sedia untuk digunakan, pada mesin tempatan mereka:
@ -227,7 +227,7 @@ Mari kita lalui aliran kerja penyumbang. Anggap penyumbang telah _fork_ dan _clo
git switch [branch-name]
```
1. **Lakukan kerja**. Pada ketika ini anda ingin menambah perubahan anda. Jangan lupa untuk memberitahu Git mengenainya dengan arahan berikut:
1. **Lakukan kerja**. Pada tahap ini, anda ingin menambah perubahan anda. Jangan lupa untuk memberitahu Git mengenainya dengan arahan berikut:
```bash
git add .
@ -236,21 +236,26 @@ Mari kita lalui aliran kerja penyumbang. Anggap penyumbang telah _fork_ dan _clo
Pastikan anda memberikan commit anda nama yang baik, untuk kebaikan anda serta penyelenggara repositori yang anda bantu.
1. **Gabungkan kerja anda dengan cawangan `main`**. Pada satu ketika anda selesai bekerja dan anda ingin menggabungkan kerja anda dengan cawangan `main`. Cawangan `main` mungkin telah berubah sementara itu jadi pastikan anda mengemas kini terlebih dahulu kepada yang terkini dengan arahan berikut:
1. **Gabungkan kerja anda dengan cawangan `main`**. Pada satu ketika, anda selesai bekerja dan anda ingin menggabungkan kerja anda dengan cawangan `main`. Cawangan `main` mungkin telah berubah sementara itu, jadi pastikan anda mengemas kini terlebih dahulu dengan arahan berikut:
```bash
git switch main
git pull
```
Pada ketika ini anda ingin memastikan bahawa sebarang _konflik_, situasi di mana Git tidak dapat dengan mudah _menggabungkan_ perubahan berlaku dalam cawangan kerja anda. Oleh itu jalankan arahan berikut:
Pada tahap ini, anda ingin memastikan bahawa sebarang _konflik_, situasi di mana Git tidak dapat dengan mudah _menggabungkan_ perubahan berlaku dalam cawangan kerja anda. Oleh itu, jalankan arahan berikut:
```bash
git switch [branch_name]
git merge main
```
Ini akan membawa semua perubahan dari `main` ke dalam cawangan anda dan semoga anda boleh teruskan. Jika tidak, VS Code akan memberitahu anda di mana Git _keliru_ dan anda hanya mengubah fail yang terjejas untuk mengatakan kandungan mana yang paling tepat.
Arahan `git merge main` akan membawa semua perubahan dari `main` ke dalam cawangan anda. Mudah-mudahan anda boleh teruskan. Jika tidak, VS Code akan memberitahu anda di mana Git _keliru_ dan anda hanya mengubah fail yang terjejas untuk mengatakan kandungan mana yang paling tepat.
Untuk beralih ke cawangan yang berbeza, gunakan arahan moden `git switch`:
```bash
git switch [branch_name]
1. **Hantar kerja anda ke GitHub**. Menghantar kerja anda ke GitHub bermaksud dua perkara. Menolak cawangan anda ke repositori anda dan kemudian membuka PR, Pull Request.
@ -258,22 +263,22 @@ Mari kita lalui aliran kerja penyumbang. Anggap penyumbang telah _fork_ dan _clo
git push --set-upstream origin [branch-name]
```
Arahan di atas mencipta cawangan pada repositori fork anda.
1. **Buka PR**. Seterusnya, anda ingin membuka PR. Anda melakukannya dengan menavigasi ke repositori fork di GitHub. Anda akan melihat petunjuk di GitHub di mana ia bertanya sama ada anda ingin mencipta PR baru, anda klik itu dan anda dibawa ke antara muka di mana anda boleh menukar tajuk mesej commit, memberikannya deskripsi yang lebih sesuai. Sekarang penyelenggara repositori yang anda fork akan melihat PR ini dan _semoga_ mereka menghargai dan _merge_ PR anda. Anda kini seorang penyumbang, yay :)
Arahan di atas mencipta cawangan pada repositori yang telah di-fork.
1. **Buka PR**. Seterusnya, anda perlu membuka PR. Anda boleh melakukannya dengan pergi ke repo yang telah difork di GitHub. Anda akan melihat petunjuk di GitHub yang bertanya sama ada anda ingin membuat PR baru, klik pada petunjuk tersebut dan anda akan dibawa ke antara muka di mana anda boleh menukar tajuk mesej commit, memberikan penerangan yang lebih sesuai. Kini penyelenggara repo yang anda fork akan melihat PR ini dan _harap-harap_ mereka menghargai dan _merge_ PR anda. Anda kini seorang penyumbang, yay :)
1. **Bersihkan**. Ia dianggap amalan yang baik untuk _membersihkan_ selepas anda berjaya merge PR. Anda ingin membersihkan kedua-dua cawangan tempatan anda dan cawangan yang anda tolak ke GitHub. Pertama mari kita hapuskannya secara tempatan dengan arahan berikut:
1. **Bersihkan**. Adalah amalan yang baik untuk _membersihkan_ selepas anda berjaya merge PR. Anda perlu membersihkan kedua-dua cawangan tempatan anda dan cawangan yang anda push ke GitHub. Pertama, mari kita hapuskannya secara tempatan dengan arahan berikut:
```bash
git branch -d [branch-name]
```
Pastikan anda pergi ke halaman GitHub untuk repositori fork dan hapuskan cawangan jauh yang baru sahaja anda tolak ke sana.
`Pull request` kelihatan seperti istilah yang pelik kerana sebenarnya anda ingin menolak (push) perubahan anda ke dalam projek. Tetapi penyelenggara (pemilik projek) atau pasukan teras perlu mempertimbangkan perubahan anda sebelum menggabungkannya dengan cawangan "main" projek, jadi sebenarnya anda sedang meminta keputusan perubahan daripada penyelenggara.
Pastikan anda pergi ke halaman GitHub untuk repo yang telah difork dan hapuskan cawangan jauh yang baru sahaja anda push ke sana.
`Pull request` mungkin kelihatan seperti istilah yang pelik kerana sebenarnya anda ingin push perubahan anda ke projek tersebut. Tetapi penyelenggara (pemilik projek) atau pasukan teras perlu mempertimbangkan perubahan anda sebelum menggabungkannya dengan cawangan "utama" projek, jadi anda sebenarnya meminta keputusan perubahan daripada penyelenggara.
`Pull request` adalah tempat untuk membandingkan dan membincangkan perbezaan yang diperkenalkan pada cawangan dengan ulasan, komen, ujian yang diintegrasikan, dan banyak lagi. `Pull request` yang baik mengikuti peraturan yang hampir sama seperti mesej commit. Anda boleh menambah rujukan kepada isu dalam penjejak isu, contohnya apabila kerja anda menyelesaikan sesuatu isu. Ini dilakukan dengan menggunakan `#` diikuti dengan nombor isu anda. Sebagai contoh,`#97`.
Pull request adalah tempat untuk membandingkan dan membincangkan perbezaan yang diperkenalkan pada cawangan dengan ulasan, komen, ujian yang diintegrasikan, dan banyak lagi. Pull request yang baik mengikuti peraturan yang hampir sama seperti mesej commit. Anda boleh menambah rujukan kepada isu dalam penjejak isu, contohnya apabila kerja anda menyelesaikan sesuatu isu. Ini dilakukan dengan menggunakan `#` diikuti dengan nombor isu anda. Sebagai contoh `#97`.
🤞Semoga semua semakan lulus dan pemilik projek menggabungkan perubahan anda ke dalam projek🤞
🤞Harap-harap semua semakan lulus dan pemilik projek merge perubahan anda ke dalam projek🤞
Kemas kini cawangan kerja tempatan anda dengan semua commit baru dari cawangan jauh yang sepadan di GitHub:
@ -281,39 +286,39 @@ Kemas kini cawangan kerja tempatan anda dengan semua commit baru dari cawangan j
## Cara menyumbang kepada sumber terbuka
Pertama, mari kita cari repositori (atau **repo**) di GitHub yang menarik minat anda dan yang anda ingin sumbangkan perubahan. Anda perlu menyalin kandungannya ke mesin anda.
Pertama, mari kita cari repositori (atau **repo**) di GitHub yang menarik minat anda dan yang ingin anda sumbangkan perubahan. Anda perlu menyalin kandungannya ke mesin anda.
✅ Cara yang baik untuk mencari repo yang 'mesra pemula' adalah dengan [mencari menggunakan tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Cara yang baik untuk mencari repo 'mesra pemula' adalah dengan [mencari menggunakan tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Terdapat beberapa cara untuk menyalin kod. Salah satu caranya adalah dengan "mengklon" kandungan repositori, menggunakan HTTPS, SSH, atau menggunakan GitHub CLI (Command Line Interface).
Terdapat beberapa cara untuk menyalin kod. Salah satu cara adalah dengan "clone" kandungan repositori, menggunakan HTTPS, SSH, atau menggunakan GitHub CLI (Command Line Interface).
Buka terminal anda dan klon repositori seperti berikut:
Buka terminal anda dan clone repositori seperti berikut:
`git clone https://github.com/ProjectURL`
Untuk bekerja pada projek, tukar ke folder yang betul:
Untuk bekerja pada projek tersebut, tukar ke folder yang betul:
`cd ProjectURL`
Anda juga boleh membuka keseluruhan projek menggunakan [Codespaces](https://github.com/features/codespaces), editor kod terbenam GitHub / persekitaran pembangunan awan, atau [GitHub Desktop](https://desktop.github.com/).
Akhir sekali, anda boleh memuat turun kod dalam folder zip.
Akhir sekali, anda boleh memuat turun kod dalam folder yang dimampatkan (zipped).
### Beberapa perkara menarik tentang GitHub
Anda boleh memberi bintang, menonton, dan/atau "fork" mana-mana repositori awam di GitHub. Anda boleh mencari repositori yang anda bintangi di menu drop-down di bahagian atas kanan. Ia seperti menanda buku, tetapi untuk kod.
Anda boleh memberi bintang, menonton dan/atau "fork" mana-mana repositori awam di GitHub. Anda boleh mencari repositori yang anda beri bintang dalam menu drop-down di bahagian atas kanan. Ia seperti menanda buku, tetapi untuk kod.
Projek mempunyai penjejak isu, kebanyakannya di GitHub dalam tab "Issues" kecuali dinyatakan sebaliknya, di mana orang membincangkan isu berkaitan projek. Dan tab Pull Requests adalah tempat orang membincangkan dan menyemak perubahan yang sedang dalam proses.
Projek mempunyai penjejak isu, kebanyakannya di GitHub dalam tab "Issues" kecuali dinyatakan sebaliknya, di mana orang membincangkan isu berkaitan projek. Dan tab Pull Requests adalah tempat orang membincangkan dan mengulas perubahan yang sedang berlangsung.
Projek mungkin juga mempunyai perbincangan dalam forum, senarai mel, atau saluran sembang seperti Slack, Discord, atau IRC.
Projek juga mungkin mempunyai perbincangan dalam forum, senarai mel, atau saluran sembang seperti Slack, Discord atau IRC.
✅ Lihat-lihat repo GitHub baru anda dan cuba beberapa perkara, seperti mengedit tetapan, menambah maklumat ke repo anda, dan mencipta projek (seperti papan Kanban). Terdapat banyak yang boleh anda lakukan!
✅ Lihat-lihat repo GitHub baru anda dan cuba beberapa perkara, seperti mengedit tetapan, menambah maklumat ke repo anda, dan mencipta projek (seperti papan Kanban). Terdapat banyak perkara yang boleh anda lakukan!
---
## 🚀 Cabaran
## 🚀 Cabaran
Berpasangan dengan rakan untuk bekerja pada kod masing-masing. Cipta projek secara kolaboratif, fork kod, cipta cawangan, dan gabungkan perubahan.
Bekerjasama dengan rakan untuk bekerja pada kod masing-masing. Cipta projek secara kolaboratif, fork kod, buat cawangan, dan merge perubahan.
## Kuiz Selepas Kuliah
[Kuiz selepas kuliah](https://ff-quizzes.netlify.app/web/en/)
@ -322,19 +327,19 @@ Berpasangan dengan rakan untuk bekerja pada kod masing-masing. Cipta projek seca
Baca lebih lanjut tentang [menyumbang kepada perisian sumber terbuka](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Berlatih, berlatih, berlatih. GitHub mempunyai laluan pembelajaran yang hebat melalui [skills.github.com](https://skills.github.com):
Berlatih, berlatih, berlatih. GitHub mempunyai laluan pembelajaran yang hebat tersedia melalui [skills.github.com](https://skills.github.com):
- [Minggu Pertama di GitHub](https://skills.github.com/#first-week-on-github)
Anda juga akan menemui kursus yang lebih maju.
## Tugasan
## Tugasan
Lengkapkan [kursus Minggu Pertama di GitHub](https://skills.github.com/#first-week-on-github)
---
**Penafian**:
Dokumen ini telah diterjemahkan menggunakan perkhidmatan terjemahan AI [Co-op Translator](https://github.com/Azure/co-op-translator). Walaupun kami berusaha untuk memastikan ketepatan, sila ambil maklum bahawa terjemahan automatik mungkin mengandungi kesilapan atau ketidaktepatan. Dokumen asal dalam bahasa asalnya harus dianggap sebagai sumber yang berwibawa. Untuk maklumat yang kritikal, terjemahan manusia profesional adalah disyorkan. Kami tidak bertanggungjawab atas sebarang salah faham atau salah tafsir yang timbul daripada penggunaan terjemahan ini.
Dokumen ini telah diterjemahkan menggunakan perkhidmatan terjemahan AI [Co-op Translator](https://github.com/Azure/co-op-translator). Walaupun kami berusaha untuk memastikan ketepatan, sila ambil perhatian bahawa terjemahan automatik mungkin mengandungi kesilapan atau ketidaktepatan. Dokumen asal dalam bahasa asalnya harus dianggap sebagai sumber yang berwibawa. Untuk maklumat yang kritikal, terjemahan manusia profesional adalah disyorkan. Kami tidak bertanggungjawab atas sebarang salah faham atau salah tafsir yang timbul daripada penggunaan terjemahan ini.
> स्केच नोट [Tomomi Imura](https://twitter.com/girlie_mac) द्वारा
@ -21,25 +21,25 @@ CO_OP_TRANSLATOR_METADATA:
यस पाठमा हामी निम्न विषयहरू समेट्नेछौं:
- तपाईंले आफ्नो मेसिनमा गर्ने कामको ट्र्याकिङ
- तपाईंले आफ्नो मेसिनमा गर्ने काम ट्र्याक गर्ने
- अरूसँग परियोजनाहरूमा काम गर्ने
- ओपन सोर्स सफ्टवेयरमा योगदान कसरी गर्ने
- ओपन सोर्स सफ्टवेयरमा योगदान गर्ने तरिका
### आवश्यकताहरू
सुरु गर्नु अघि, तपाईंले जाँच गर्नुपर्नेछ कि Git स्थापना भएको छ कि छैन। टर्मिनलमा टाइप गर्नुहोस्:
सुरु गर्नु अघि, तपाईंले Git स्थापना भएको छ कि छैन जाँच गर्नुपर्नेछ। टर्मिनलमा टाइप गर्नुहोस्:
`git --version`
यदि Git स्थापना भएको छैन भने, [Git डाउनलोड गर्नुहोस्](https://git-scm.com/downloads)। त्यसपछि, आफ्नो स्थानीय Git प्रोफाइल सेटअप गर्नुहोस् टर्मिनलमा:
यदि Git स्थापना भएको छैन भने, [Git डाउनलोड गर्नुहोस्](https://git-scm.com/downloads)। त्यसपछि, आफ्नो स्थानीय Git प्रोफाइल सेटअप गर्न टर्मिनलमा टाइप गर्नुहोस्:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
जाँच गर्न कि Git पहिले नै कन्फिगर गरिएको छ कि छैन, तपाईं टाइप गर्न सक्नुहुन्छ:
Git पहिले नै कन्फिग गरिएको छ कि छैन जाँच गर्न तपाईं टाइप गर्न सक्नुहुन्छ:
`git config --list`
तपाईंलाई GitHub खाता, कोड एडिटर (जस्तै Visual Studio Code), र टर्मिनल (वा: कमाण्ड प्रम्प्ट) खोल्न आवश्यक हुनेछ।
[github.com](https://github.com/) मा जानुहोस् र खाता सिर्जना गर्नुहोस् यदि तपाईंले पहिले नै खाता बनाउनु भएको छैन भने, वा लग इन गरेर आफ्नो प्रोफाइल भर्नुहोस्।
[github.com](https://github.com/) मा जानुहोस् र यदि तपाईंले खाता बनाउनु भएको छैन भने खाता बनाउनुहोस्, वा लग इन गरेर आफ्नो प्रोफाइल भर्नुहोस्।
✅ GitHub संसारको एकमात्र कोड रिपोजिटरी होइन; अरू पनि छन्, तर GitHub सबैभन्दा प्रख्यात हो।
@ -51,7 +51,7 @@ CO_OP_TRANSLATOR_METADATA:
## कोड व्यवस्थापन
मानौं तपाईंको स्थानीय मेसिनमा कोड परियोजनाको साथ एक फोल्डर छ र तपाईं git - संस्करण नियन्त्रण प्रणाली प्रयोग गरेर आफ्नो प्रगति ट्र्याक गर्न सुरु गर्न चाहनुहुन्छ। केही व्यक्तिहरू git प्रयोगलाई भविष्यको लागि प्रेम पत्र लेख्नसँग तुलना गर्छन्। तपाईंको कमिट सन्देशहरू दिन, हप्ता, वा महिनाहरू पछि पढ्दा तपाईंले किन निर्णय गर्नुभयो भनेर सम्झन सक्नुहुन्छ, वा परिवर्तन "रोलब्याक" गर्न सक्नुहुन्छ - अर्थात्, जब तपाईंले राम्रो "कमिट सन्देशहरू" लेख्नुहुन्छ।
मानौं तपाईंको स्थानीय फोल्डरमा केही कोड परियोजना छ र तपाईं आफ्नो प्रगति ट्र्याक गर्न चाहनुहुन्छ - संस्करण नियन्त्रण प्रणाली Git प्रयोग गरेर। केही मानिसहरूले Git प्रयोगलाई भविष्यको आफ्नै लागि प्रेम पत्र लेख्नसँग तुलना गर्छन्। तपाईंको कमिट सन्देशहरू दिन, हप्ता वा महिना पछि पढ्दा तपाईंले किन निर्णय गर्नुभयो भनेर सम्झन सक्नुहुन्छ, वा परिवर्तन "रोलब्याक" गर्न सक्नुहुन्छ - जब तपाईंले राम्रो "कमिट सन्देशहरू" लेख्नुहुन्छ।
### कार्य: रिपोजिटरी बनाउनुहोस् र कोड कमिट गर्नुहोस्
@ -59,18 +59,19 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub मा रिपोजिटरी सिर्जना गर्नुहोस्**। GitHub.com मा, रिपोजिटरी ट्याबमा, वा नेभिगेसन बारको माथि-दायाँ, **नयाँ रिपो** बटन खोज्नुहोस्।
1. आफ्नो रिपोजिटरी (फोल्डर) लाई नाम दिनुहोस्।
1. **रिपोजिटरी सिर्जना गर्नुहोस्** चयन गर्नुहोस्।
1. **GitHub मा रिपोजिटरी बनाउनुहोस्**। GitHub.com मा, रिपोजिटरी ट्याबमा, वा नेभिगेसन बारको माथि-दायाँमा, **नयाँ रिपो** बटन खोज्नुहोस्।
1. **आफ्नो कार्य फोल्डरमा जानुहोस्**। टर्मिनलमा, तपाईं ट्र्याक गर्न चाहनुहुने फोल्डर (डाइरेक्टरी) मा स्विच गर्नुहोस्। टाइप गर्नुहोस्:
1. आफ्नो रिपोजिटरी (फोल्डर) लाई नाम दिनुहोस्
1. **रिपोजिटरी बनाउनुहोस्** चयन गर्नुहोस्।
1. **आफ्नो कार्य फोल्डरमा जानुहोस्**। आफ्नो टर्मिनलमा, ट्र्याक गर्न चाहेको फोल्डर (डाइरेक्टरी) मा स्विच गर्नुहोस्। टाइप गर्नुहोस्:
```bash
cd [name of your folder]
```
1. **Git रिपोजिटरी इनिशियलाइज गर्नुहोस्**। आफ्नो परियोजनामा टाइप गर्नुहोस्:
1. **Git रिपोजिटरी इनिसियलाइज गर्नुहोस्**। आफ्नो परियोजनामा टाइप गर्नुहोस्:
```bash
git init
@ -95,14 +96,14 @@ CO_OP_TRANSLATOR_METADATA:
सामान्यतया `git status` कमाण्डले तपाईंलाई जस्तै जानकारी दिन्छ कि कुन फाइलहरू रिपोमा _सेभ_ गर्न तयार छन् वा त्यसमा परिवर्तनहरू छन् जुन तपाईंले कायम राख्न चाहनुहुन्छ।
1. **सबै फाइलहरू ट्र्याकिङका लागि थप्नुहोस्**
1. **ट्र्याकिङका लागि सबै फाइलहरू थप्नुहोस्**
यसलाई फाइलहरू स्टेजिङ/स्टेजिङ क्षेत्रमा फाइलहरू थप्ने पनि भनिन्छ।
```bash
git add .
```
`git add` प्लस `.` तर्कले सबै फाइलहरू र ट्र्याकिङका लागि परिवर्तनहरू संकेत गर्दछ।
`git add` प्लस `.` तर्कले ट्र्याकिङका लागि सबै फाइलहरू र परिवर्तनहरू संकेत गर्दछ।
1. **चयन गरिएका फाइलहरू ट्र्याकिङका लागि थप्नुहोस्**
@ -110,7 +111,7 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
जब हामी सबै फाइलहरू एकैपटक कमिट गर्न चाहँदैनौं, यसले हामीलाई केवल चयन गरिएका फाइलहरू स्टेजिङ क्षेत्रमा थप्न मद्दत गर्दछ।
जब हामी सबै फाइलहरू एकैपटक कमिट गर्न चाहँदैनौं, यो चयन गरिएका फाइलहरू मात्र स्टेजिङ क्षेत्रमा थप्न मद्दत गर्दछ।
1. **सबै फाइलहरू अनस्टेज गर्नुहोस्**
@ -118,45 +119,45 @@ CO_OP_TRANSLATOR_METADATA:
git reset
```
यो कमाण्डले हामीलाई एकैपटक सबै फाइलहरू अनस्टेज गर्न मद्दत गर्दछ।
यो कमाण्डले एकैपटक सबै फाइलहरू अनस्टेज गर्न मद्दत गर्दछ।
1. **विशिष्ट फाइल अनस्टेज गर्नुहोस्**
1. **विशेष फाइल अनस्टेज गर्नुहोस्**
```bash
git reset [file or folder name]
```
यो कमाण्डले हामीलाई एकै पटक केवल एक विशिष्ट फाइल अनस्टेज गर्न मद्दत गर्दछ जुन हामी अर्को कमिटमा समावेश गर्न चाहँदैनौं।
यो कमाण्डले एकैपटक मात्र विशेष फाइल अनस्टेज गर्न मद्दत गर्दछ जुन हामी अर्को कमिटमा समावेश गर्न चाहँदैनौं।
1. **आफ्नो काम कायम राख्नुहोस्**। यस बिन्दुमा तपाईंले फाइलहरूलाई तथाकथित _स्टेजिङ क्षेत्र_ मा थप्नुभएको छ। Git तपाईंको फाइलहरू ट्र्याक गर्दैछ। परिवर्तन स्थायी बनाउन तपाईंले फाइलहरू _कमिट_ गर्न आवश्यक छ। _कमिट_ बनाउन `git commit` कमाण्ड प्रयोग गर्नुहोस्। _कमिट_ तपाईंको रिपोको इतिहासमा एक बचत बिन्दु प्रतिनिधित्व गर्दछ। _कमिट_बनाउन निम्न टाइप गर्नुहोस्:
1. **आफ्नो काम कायम राख्नुहोस्**। यस बिन्दुमा तपाईंले फाइलहरूलाई तथाकथित _स्टेजिङ क्षेत्र_ मा थप्नुभएको छ। Git तपाईंको फाइलहरू ट्र्याक गर्दैछ। परिवर्तन स्थायी बनाउन तपाईंले फाइलहरू _कमिट_ गर्न आवश्यक छ। त्यसो गर्न तपाईं `git commit` कमाण्डको साथ _कमिट_ सिर्जना गर्नुहोस्। _कमिट_ तपाईंको रिपोको इतिहासमा बचत बिन्दु प्रतिनिधित्व गर्दछ। _कमिट_सिर्जना गर्न निम्न टाइप गर्नुहोस्:
```bash
git commit -m "first commit"
```
यसले तपाईंको सबै फाइलहरू कमिट गर्दछ, "पहिलो कमिट" सन्देश थप्दै। भविष्यका कमिट सन्देशहरूको लागि, तपाईंले आफ्नो परिवर्तनको प्रकार व्यक्त गर्न थप वर्णनात्मक विवरण प्रयोग गर्न चाहनुहुनेछ।
यसले तपाईंको सबै फाइलहरू कमिट गर्दछ, "पहिलो कमिट" सन्देश थप्दै। भविष्यका कमिट सन्देशहरूको लागि तपाईंले आफ्नो परिवर्तनको प्रकार व्यक्त गर्न थप वर्णनात्मक विवरण प्रयोग गर्न चाहनुहुनेछ।
1. **आफ्नो स्थानीय Git रिपो GitHub सँग जडान गर्नुहोस्**। Git रिपो तपाईंको मेसिनमा राम्रो छ तर कुनै बिन्दुमा तपाईं आफ्नो फाइलहरूको ब्याकअप चाहनुहुन्छ र अरू व्यक्तिहरूलाई तपाईंको रिपोमा काम गर्न आमन्त्रित गर्न चाहनुहुन्छ। यस्तो राम्रो ठाउँ GitHub हो। याद गर्नुहोस् हामीले पहिले नै GitHub मा रिपो सिर्जना गरिसकेका छौं त्यसैले हामीले गर्नुपर्ने एकमात्र कुरा भनेको हाम्रो स्थानीय Git रिपो GitHub सँग जडान गर्नु हो। कमाण्ड `git remote add` ले यो काम गर्नेछ। निम्न कमाण्ड टाइप गर्नुहोस्:
1. **आफ्नो स्थानीय Git रिपो GitHub सँग जडान गर्नुहोस्**। Git रिपो तपाईंको मेसिनमा राम्रो छ तर कुनै बिन्दुमा तपाईं आफ्नो फाइलहरूको ब्याकअप कतै चाहनुहुन्छ र तपाईंको रिपोमा अरू मानिसहरूलाई काम गर्न आमन्त्रित गर्न चाहनुहुन्छ। यस्तो राम्रो ठाउँ GitHub हो। याद गर्नुहोस् हामीले पहिले नै GitHub मा रिपो सिर्जना गरेका छौं त्यसैले हामीले गर्नुपर्ने एकमात्र कुरा भनेको हाम्रो स्थानीय Git रिपो GitHub सँग जडान गर्नु हो। `git remote add` कमाण्डले ठीक त्यही गर्नेछ। निम्न कमाण्ड टाइप गर्नुहोस्:
> नोट, कमाण्ड टाइप गर्नु अघि GitHub रिपो पेजमा जानुहोस् र रिपोजिटरी URL खोज्नुहोस्। तपाईंले यो URL तलको कमाण्डमा प्रयोग गर्नुहुनेछ। ```https://github.com/username/repository_name.git``` लाई आफ्नो GitHub URL सँग प्रतिस्थापन गर्नुहोस्।
> नोट, कमाण्ड टाइप गर्नु अघि आफ्नो GitHub रिपो पृष्ठमा जानुहोस् र रिपोजिटरी URL खोज्नुहोस्। तपाईं यसलाई तलको कमाण्डमा प्रयोग गर्नुहुनेछ। ```https://github.com/username/repository_name.git``` लाई आफ्नो GitHub URL सँग बदल्नुहोस्।
यसले "origin" नामक एक_remote_ वा जडान सिर्जना गर्दछ जुन तपाईंले पहिले सिर्जना गर्नुभएको GitHub रिपोजिटरीमा संकेत गर्दछ।
यसले "origin" नामको_remote_ वा जडान सिर्जना गर्दछ जुन तपाईंले पहिले सिर्जना गरेको GitHub रिपोजिटरीमा संकेत गर्दछ।
1. **स्थानीय फाइलहरू GitHub मा पठाउनुहोस्**। अहिलेसम्म तपाईंले स्थानीय रिपो र GitHub रिपो बीचमा _जडान_ सिर्जना गर्नुभएको छ। यी फाइलहरू GitHub मा पठाउन निम्न कमाण्ड `git push` प्रयोग गर्नुहोस्:
> नोट, तपाईंको ब्रान्च नाम ```main``` भन्दा फरक हुन सक्छ।
> नोट, तपाईंको शाखाको नाम ```main``` भन्दा फरक हुन सक्छ।
```bash
git push -u origin main
```
यसले तपाईंको "main" ब्रान्चमा भएका कमिटहरू GitHub मा पठाउँछ।
यसले तपाईंको "main" शाखामा भएका कमिटहरू GitHub मा पठाउँछ।`upstream` शाखा सेट गर्दै `-u` कमाण्डमा समावेश गर्दा तपाईंको स्थानीय शाखा र रिमोट शाखाबीच लिंक स्थापना हुन्छ, त्यसैले तपाईंले भविष्यमा शाखाको नाम निर्दिष्ट नगरी git push वा git pull मात्र प्रयोग गर्न सक्नुहुन्छ। Git स्वचालित रूपमा अपस्ट्रीम शाखा प्रयोग गर्नेछ र भविष्यका कमाण्डहरूमा शाखाको नाम स्पष्ट रूपमा निर्दिष्ट गर्न आवश्यक पर्दैन।
2. **थप परिवर्तनहरू थप्न**। यदि तपाईं परिवर्तनहरू जारी राख्न र तिनीहरूलाई GitHub मा पठाउन चाहनुहुन्छ भने तपाईंलाई केवल निम्न तीन कमाण्डहरू प्रयोग गर्न आवश्यक हुनेछ:
2. **थप परिवर्तनहरू थप्न**। यदि तपाईं परिवर्तनहरू जारी राख्न चाहनुहुन्छ र तिनीहरूलाई GitHub मा धकेल्न चाहनुहुन्छ भने तपाईंले केवल निम्न तीन कमाण्डहरू प्रयोग गर्न आवश्यक हुनेछ:
```bash
git add .
@ -164,17 +165,17 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> टिप, तपाईंले `.gitignore` फाइल अपनाउन पनि चाहन सक्नुहुन्छ ताकि तपाईं ट्र्याक गर्न चाहनुहुन्न फाइलहरू GitHub मा देखिनबाट रोक्न सक्नुहुन्छ - जस्तै नोट्स फाइल जुन तपाईंले त्यही फोल्डरमा भण्डारण गर्नुहुन्छ तर सार्वजनिक रिपोजिटरीमा कुनै स्थान छैन। तपाईं `.gitignore` फाइलहरूको टेम्प्लेट [यहाँ](https://github.com/github/gitignore) पाउन सक्नुहुन्छ।
> टिप, तपाईंले `.gitignore` फाइल अपनाउन चाहनुहुन्छ जसले तपाईं ट्र्याक गर्न चाहनुहुन्न फाइलहरू GitHub मा देखिनबाट रोक्न मद्दत गर्दछ - जस्तै त्यो नोट्स फाइल जुन तपाईंले त्यही फोल्डरमा भण्डारण गर्नुहुन्छ तर सार्वजनिक रिपोजिटरीमा कुनै स्थान छैन। तपाईं `.gitignore` फाइलहरूको टेम्प्लेटहरू [.gitignore templates](https://github.com/github/gitignore) मा फेला पार्न सक्नुहुन्छ।
#### कमिट सन्देशहरू
एक उत्कृष्ट Git कमिट विषय लाइनले निम्न वाक्य पूरा गर्दछ:
यदि लागू गरियो भने, यो कमिट <तपाईंको विषय लाइन यहाँ>
विषयको लागि, अनिवार्य, वर्तमान काल प्रयोग गर्नुहोस्: "change" होइन "changed" वा "changes"।
विषयको लागि अनिवार्य, वर्तमान काल प्रयोग गर्नुहोस्: "change" होइन "changed" वा "changes"।
विषयमा जस्तै, शरीरमा (वैकल्पिक) पनि अनिवार्य, वर्तमान काल प्रयोग गर्नुहोस्। शरीरले परिवर्तनको प्रेरणा समावेश गर्नुपर्छ र यसलाई अघिल्लो व्यवहारसँग तुलना गर्नुपर्छ। तपाईं `किन` व्याख्या गर्दै हुनुहुन्छ, `कसरी` होइन।
✅ GitHub मा केही समय बिताउनुहोस्। के तपाईं उत्कृष्ट कमिट सन्देश फेला पार्न सक्नुहुन्छ? के तपाईं न्यूनतम सन्देश फेला पार्न सक्नुहुन्छ? तपाईंको विचारमा कमिट सन्देशमा व्यक्त गर्न सबैभन्दा महत्त्वपूर्ण र उपयोगी जानकारी के हो?
✅ GitHub मा केही समय बिताउनुहोस्। के तपाईं उत्कृष्ट कमिट सन्देश फेला पार्न सक्नुहुन्छ? के तपाईं न्यूनतम सन्देश फेला पार्न सक्नुहुन्छ? कमिट सन्देशमा कुन जानकारी सबैभन्दा महत्त्वपूर्ण र उपयोगी छ भन्ने तपाईंलाई के लाग्छ?
### कार्य: सहकार्य गर्नुहोस्
@ -186,154 +187,159 @@ GitHub मा चीजहरू राख्ने मुख्य कारण
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
तपाईंको रिपोजिटरीमा, `Insights > Community` मा नेभिगेट गर्नुहोस् ताकि तपाईंको परियोजना सिफारिस गरिएका समुदाय मापदण्डहरूसँग कसरी तुलना हुन्छ हेर्न सक्नुहुन्छ।
तपाईंको रिपोजिटरीमा, `Insights > Community` मा जानुहोस् र तपाईंको परियोजना सिफारिस गरिएका समुदाय मापदण्डहरूसँग कसरी तुलना हुन्छ हेर्नुहोस्।
यहाँ केही चीजहरू छन् जसले तपाईंको GitHub रिपो सुधार गर्न सक्छ:
- **विवरण**। के तपाईंले आफ्नो परियोजनाको लागि विवरण थप्नुभएको छ?
- **README**। के तपाईंले README थप्नुभएको छ? GitHub ले [README लेख्न](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) मार्गदर्शन प्रदान गर्दछ।
- **README**। के तपाईंले README थप्नुभएको छ? GitHub ले [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-license-to-a-repository/)।
यी सबै स्रोतहरूले नयाँ टोली सदस्यहरूलाई अनबोर्डिङ गर्न फाइदा पुर्याउँछन्। र ती सामान्यतया नयाँ योगदानकर्ताहरूले तपाईंको कोड हेर्नु अघि हेर्ने प्रकारका चीजहरू हुन्, यो पत्ता लगाउन कि तपाईंको परियोजना उनीहरूको समय खर्च गर्नको लागि सही ठाउँ हो।
यी सबै स्रोतहरूले नयाँ टोली सदस्यहरूलाई लाभ पुर्याउनेछन्। र ती सामान्यतया नयाँ योगदानकर्ताहरूले तपाईंको कोड हेर्नु अघि हेर्ने प्रकारका चीजहरू हुन्, यो पत्ता लगाउन कि तपाईंको परियोजना उनीहरूको समय खर्च गर्नको लागि सही ठाउँ हो।
✅ README फाइलहरू, यद्यपि तिनीहरू तयार गर्न समय लाग्छ, अक्सर व्यस्त मर्मतकर्ताहरूले बेवास्ता गर्छन्। के तपाईं विशेष रूपमा वर्णनात्मक README को उदाहरण फेला पार्न सक्नुहुन्छ? नोट: त्यहाँ केही [उपकरणहरू](https://www.makeareadme.com/) छन् जसले राम्रो README बनाउन मद्दत गर्न सक्छ जुन तपाईंले प्रयास गर्न चाहन सक्नुहुन्छ।
✅ README फाइलहरू, यद्यपि तिनीहरू तयार गर्न समय लाग्छ, व्यस्त मर्मतकर्ताहरूले अक्सर बेवास्ता गर्छन्। के तपाईं विशेष रूपमा वर्णनात्मक README को उदाहरण फेला पार्न सक्नुहुन्छ? नोट: त्यहाँ केही [उपकरणहरू छन् जसले राम्रो README बनाउन मद्दत गर्छ](https://www.makeareadme.com/) जुन तपाईंले प्रयास गर्न चाहनुहुन्छ।
### कार्य: केही कोड मर्ज गर्नुहोस्
योगदान दस्तावेजहरूले व्यक्तिहरूलाई परियोजनामा योगदान गर्न मद्दत गर्दछ। यसले तपाईंले खोजिरहेका योगदानहरूको प्रकार र प्रक्रिया कसरी काम गर्दछ भनेर व्याख्या गर्दछ। योगदानकर्ताहरूले GitHub मा तपाईंको रिपोमा योगदान गर्न सक्षम हुन चरणहरूको श्रृंखला मार्फत जान आवश्यक हुनेछ:
योगदान दस्तावेजहरूले मानिसहरूलाई परियोजनामा योगदान गर्न मद्दत गर्दछ। यसले तपाईंले खोजिरहेका योगदानहरूको प्रकार र प्रक्रिया कसरी काम गर्दछ भनेर व्याख्या गर्दछ। योगदानकर्ताहरूले GitHub मा तपाईंको रिपोमा योगदान गर्न सक्षम हुन चरणहरूको श्रृंखला मार्फत जान आवश्यक छ:
1. **तपाईंको रिपो फोर्क गर्नुहोस्**। तपाईंले सम्भवतः व्यक्तिहरूलाई तपाईंको परियोजना _फोर्क_ गर्न चाहनुहुन्छ। फोर्क गर्नुको मतलब तपाईंको रिपोजिटरीको प्रतिकृति उनीहरूको GitHub प्रोफाइलमा सिर्जना गर्नु हो।
1. **क्लोन गर्नुहोस्**। त्यहाँबाट उनीहरूले परियोजनालाई आफ्नो स्थानीय मेसिनमा क्लोन गर्नेछन्।
1. **ब्रान्च सिर्जना गर्नुहोस्**। तपाईंले उनीहरूलाई आफ्नो कामको लागि _ब्रान्च_ सिर्जना गर्न सोध्न चाहनुहुन्छ।
1. **एक क्षेत्रमा परिवर्तन केन्द्रित गर्नुहोस्**। योगदानकर्ताहरूलाई एक पटकमा एक कुरामा आफ्नो योगदान केन्द्रित गर्न सोध्नुहोस् - यसले तपाईंको काम _मर्ज_ गर्ने सम्भावना उच्च बनाउँछ। कल्पना गर्नुहोस् कि उनीहरूले बग फिक्स लेख्छन्, नयाँ सुविधा थप्छन्, र धेरै परीक्षणहरू अपडेट गर्छन् - के हुन्छ यदि तपाईं ३ मध्ये २, वा ३ मध्ये १ मात्र कार्यान्वयन गर्न चाहनुहुन्छ वा सक्नुहुन्छ?
1. **शाखा बनाउनुहोस्**। तपाईंले उनीहरूलाई आफ्नो कामको लागि _शाखा_ सिर्जना गर्न सोध्न चाहनुहुन्छ।
1. **एक क्षेत्रमा परिवर्तन केन्द्रित गर्नुहोस्**। योगदानकर्ताहरूलाई एक पटकमा एक कुरामा आफ्नो योगदान केन्द्रित गर्न सोध्नुहोस् - यसले तपाईंको काम _मर्ज_ गर्ने सम्भावना बढाउँछ। कल्पना गर्नुहोस् कि उनीहरूले बग फिक्स लेख्छन्, नयाँ सुविधा थप्छन्, र धेरै परीक्षणहरू अपडेट गर्छन् - के हुन्छ यदि तपाईं ३ मध्ये २, वा ३ मध्ये १ मात्र कार्यान्वयन गर्न चाहनुहुन्छ वा सक्नुहुन्छ?
✅ ब्रान्चहरू लेख्न र राम्रो कोड शिप गर्न विशेष रूपमा महत्त्वपूर्ण हुने स्थिति कल्पना गर्नुहोस्। तपाईं के उपयोग केसहरू सोच्न सक्नुहुन्छ?
✅ शाखाहरू लेख्न र राम्रो कोड शिप गर्न विशेष रूपमा महत्त्वपूर्ण हुने स्थिति कल्पना गर्नुहोस्। तपाईं कुन प्रयोग केसहरू सोच्न सक्नुहुन्छ?
> नोट, तपाईं संसारमा देख्न चाहनुहुने परिवर्तन हुनुहोस्, र आफ्नो कामको लागि ब्रान्चहरू सिर्जना गर्नुहोस्। तपाईंले गर्ने कुनै पनि कमिटहरू तपाईं हाल "चेक आउट" गरिएको ब्रान्चमा गरिनेछ। `git status` प्रयोग गरेर कुन ब्रान्च हो हेर्नुहोस्।
> नोट, तपाईं संसारमा देख्न चाहनुहुन्छ परिवर्तन हुनुहोस्, र आफ्नो कामको लागि शाखाहरू सिर्जना गर्नुहोस्। तपाईंले गर्ने कुनै पनि कमिटहरू तपाईं हाल "चेक आउट" गरिएको शाखामा गरिनेछ। `git status` प्रयोग गरेर त्यो कुन शाखा हो हेर्नुहोस्।
आउनुहोस् योगदानकर्ताको वर्कफ्लोमा जानुहोस्। मानौं योगदानकर्ताले रिपो _फोर्क_ र _क्लोन_ गरिसकेका छन् ताकि उनीहरूको स्थानीय मेसिनमा काम गर्न तयार Git रिपो छ:
आउनुहोस् योगदानकर्ताको वर्कफ्लोमा जानुहोस्। मानौं योगदानकर्ताले रिपो _फोर्क_ र _क्लोन_ गरिसकेका छन् त्यसैले उनीहरूको स्थानीय मेसिनमा काम गर्न तयार Git रिपो छ:
1. **ब्रान्च सिर्जना गर्नुहोस्**। `git branch` कमाण्ड प्रयोग गरेर ब्रान्च सिर्जना गर्नुहोस् जसले उनीहरूले योगदान गर्न चाहेको परिवर्तनहरू समावेश गर्नेछ:
1. **शाखा बनाउनुहोस्**। `git branch` कमाण्ड प्रयोग गरेर शाखा बनाउनुहोस् जसले उनीहरूले योगदान गर्न चाहेको परिवर्तनहरू समावेश गर्नेछ:
```bash
git branch [branch-name]
```
1. **कार्य ब्रान्चमा स्विच गर्नुहोस्**। निर्दिष्ट ब्रान्चमा स्विच गर्नुहोस् र `git switch` प्रयोग गरेर कार्य डाइरेक्टरी अपडेट गर्नुहोस्:
1. **कार्य शाखामा स्विच गर्नुहोस्**। निर्दिष्ट शाखामा स्विच गर्नुहोस् र `git switch` प्रयोग गरेर कार्य डाइरेक्टरी अपडेट गर्नुहोस्:
```bash
git switch [branch-name]
```
1. **काम गर्नुहोस्**। यस बिन्दुमा तपाईंले आफ्नो परिवर्तनहरू थप्न चाहनुहुन्छ। Git लाई यसबारे बताउन नबिर्सनुहोस् निम्न कमाण्डहरू प्रयोग गरेर:
1. **काम गर्नुहोस्**। यस बिन्दुमा तपाईंले आफ्नो परिवर्तनहरू थप्न चाहनुहुन्छ। Git लाई यसबारे भन्न नबिर्सनुहोस् निम्न कमाण्डहरू प्रयोग गरेर:
```bash
git add .
git commit -m "my changes"
```
सुनिश्चित गर्नुहोस् तपाईंले आफ्नो कमिटलाई राम्रो नाम दिनुहोस्, तपाईंको लागि र तपाईंले मद्दत गरिरहेको रिपोको मर्मतकर्ताको लागि।
सुनिश्चित गर्नुहोस् तपाईंले आफ्नो कमिटलाई राम्रो नाम दिनुहोस्, तपाईंको लागि साथै तपाईंले मद्दत गरिरहेको रिपोको मर्मतकर्ताको लागि।
1. **आफ्नो काम`main` ब्रान्चसँग मिलाउनुहोस्**। कुनै बिन्दुमा तपाईं काम सक्नुहुन्छ र तपाईं आफ्नो काम`main` ब्रान्चको कामसँग मिलाउन चाहनुहुन्छ। यस बीचमा `main` ब्रान्च परिवर्तन भएको हुन सक्छ त्यसैले सुनिश्चित गर्नुहोस् कि तपाईंले पहिले यसलाई निम्न कमाण्डहरू प्रयोग गरेर नवीनतममा अपडेट गर्नुहोस्:
1. **आफ्नो कामलाई `main` शाखासँग मिलाउनुहोस्**। कुनै बिन्दुमा तपाईं काम सक्नुहुन्छ र तपाईं आफ्नो कामलाई `main` शाखासँग मिलाउन चाहनुहुन्छ। `main` शाखा यस बीचमा परिवर्तन भएको हुन सक्छ त्यसैले सुनिश्चित गर्नुहोस् तपाईंले पहिले यसलाई निम्न कमाण्डहरू प्रयोग गरेर पछिल्लोमा अपडेट गर्नुहोस्:
```bash
git switch main
git pull
```
यस बिन्दुमा तपाईं सुनिश्चित गर्न चाहनुहुन्छ कि कुनै पनि _conflicts_, जहाँ Git सजिलै _combine_ गर्न सक्दैन, तपाईंको कार्य ब्रान्चमा हुन्छ। त्यसैले निम्न कमाण्डहरू चलाउनुहोस्:
यस बिन्दुमा तपाईं सुनिश्चित गर्न चाहनुहुन्छ कि कुनै पनि _conflicts_, जहाँ Git सजिलै _combine_ गर्न सक्दैन, तपाईंको कार्य शाखामा हुन्छ। त्यसैले निम्न कमाण्डहरू चलाउनुहोस्:
```bash
git switch [branch_name]
git merge main
```
यसले `main` बाट सबै परिवर्तनहरू तपाईंको ब्रान्चमा ल्याउनेछ र आशा छ कि तपाईं केवल जारी राख्न सक्नुहुन्छ। यदि छैन भने, VS Code ले तपाईंलाई Git _confused_ भएको ठाउँ देखाउनेछ र तपाईंले प्रभावित फाइलहरू परिवर्तन गर्न सक्नुहुन्छ ताकि कुन सामग्री सबैभन्दा सही छ भनेर भन्न सक्नुहुन्छ।
`git merge main` कमाण्डले `main` बाट सबै परिवर्तनहरू तपाईंको शाखामा ल्याउनेछ। आशा छ तपाईं केवल जारी राख्न सक्नुहुन्छ। यदि छैन भने, VS Code ले तपाईंलाई Git _confused_ भएको ठाउँ बताउनेछ र तपाईंले प्रभावित फाइलहरू परिवर्तन गर्न सक्नुहुन्छ कि कुन सामग्री सबैभन्दा सही छ।
फरक शाखामा स्विच गर्न, आधुनिक `git switch` कमाण्ड प्रयोग गर्नुहोस्:
```bash
git switch [branch_name]
1. **आफ्नो काम GitHub मा पठाउनुहोस्**। GitHub मा आफ्नो काम पठाउनुको मतलब दुई चीज हो। तपाईंको ब्रान्चलाई तपाईंको रिपोमा पुश गर्नुहोस् र त्यसपछि PR, Pull Request खोल्नुहोस्।
1. **आफ्नो काम GitHub मा पठाउनुहोस्**। तपाईंको काम GitHub मा पठाउनुको मतलब दुई कुरा हो। तपाईंको शाखालाई तपाईंको रिपोमा धकेल्नुहोस् र त्यसपछि PR, Pull Request खोल्नुहोस्।
```bash
git push --set-upstream origin [branch-name]
```
माथिको कमाण्डले तपाईंको फोर्क गरिएको रिपोमा ब्रान्च सिर्जना गर्दछ।
1. **PR खोल्नुहोस्**। त्यसपछि, तपाईं PR खोल्न चाहनुहुन्छ। तपाईंले GitHub मा फोर्क गरिएको रिपोमा नेभिगेट गरेर यो गर्न सक्नुहुन्छ। GitHub ले संकेत देखाउनेछ जहाँ यसले सोध्छ कि तपाईं नयाँ PR सिर्जना गर्न चाहनुहुन्छ कि छैन, तपाईंले क्लिक गर्नुहोस् र तपाईंलाई एक इन्टरफेसमा लगिन्छ जहाँ तपाईं कमिट सन्देश शीर्षक परिवर्तन गर्न सक्नुहुन्छ, यसलाई थप उपयुक्त विवरण दिन सक्नुहुन्छ। अब तपाईंले फोर्क गरेको रिपोको मर्मतकर्ताले यो PR देख्नेछन् र _फिंगर्स क्रस्ड_ उनीहरूले तपाईंको PR लाई सराहना गर्नेछन् र _मर्ज_ गर्नेछन्। तपाईं अब योगदानकर्ता हुनुहुन्छ, याय :)
माथिको कमाण्डले तपाईंको फोर्क गरिएको रिपोमा शाखा सिर्जना गर्दछ।
1. **PR खोल्नुहोस्**। अब, तपाईंले PR खोल्न चाहनुहुन्छ। त्यसका लागि GitHub मा फोर्क गरिएको रिपोमा जानुहोस्। GitHub मा तपाईंलाई नयाँ PR बनाउने विकल्प देखिन्छ, त्यसमा क्लिक गर्नुहोस् र तपाईंलाई एउटा इन्टरफेसमा लैजान्छ जहाँ तपाईंले कमिट मेसेजको शीर्षक परिवर्तन गर्न, उपयुक्त विवरण दिन सक्नुहुन्छ। अब तपाईंले फोर्क गरेको रिपोको मेन्टेनरले यो PR देख्नेछन् र _आशा गरौं_ उनीहरूले तपाईंको PR लाई मन पराउनेछन् र _मर्ज_ गर्नेछन्। अब तपाईं योगदानकर्ता हुनुहुन्छ, वाह :)
1. **सफा गर्नुहोस्**। PR सफलतापूर्वक मर्ज गरेपछि _सफा गर्नु_ राम्रो अभ्यास मानिन्छ। तपाईं आफ्नो स्थानीय ब्रान्च र तपाईंले GitHub मा पुश गरेको ब्रान्च दुवै सफा गर्न चाहनुहुन्छ। पहिले यसलाई स्थानीय रूपमा निम्न कमाण्ड प्रयोग गरेर मेटाउनुहोस्:
1. **सफा गर्नुहोस्**। PR सफलतापूर्वक मर्ज गरेपछि _सफा गर्नु_ राम्रो अभ्यास मानिन्छ। तपाईंले आफ्नो स्थानीय ब्रान्च र GitHub मा पुश गरिएको ब्रान्च दुवै सफा गर्नुपर्छ। पहिले यसलाई स्थानीय रूपमा निम्न कमाण्ड प्रयोग गरेर हटाउनुहोस्:
```bash
git branch -d [branch-name]
```
सुनिश्चित गर्नुहोस् कि तपाईं फोर्क गरिएको रिपोको GitHub पेजमा जानुहोस् र तपाईंले यसमा पुश गरेको रिमोट ब्रान्च हटाउनुहोस्।
`Pull request` भन्ने शब्द अलि अनौठो लाग्न सक्छ, किनभने वास्तवमा तपाईं आफ्नो परिवर्तनहरू परियोजनामा पठाउन चाहनुहुन्छ। तर परियोजनाको मालिक (maintainer) वा कोर टिमले तपाईंको परिवर्तनहरूलाई परियोजनाको "main" शाखामा मर्ज गर्नु अघि विचार गर्नुपर्छ, त्यसैले तपाईं वास्तवमा परियोजनाको मालिकसँग परिवर्तनको निर्णयको अनुरोध गर्दै हुनुहुन्छ।
त्यसपछि GitHub मा फोर्क गरिएको रिपोको पेजमा जानुहोस् र तपाईंले त्यहाँ पुश गरेको रिमोट ब्रान्च हटाउनुहोस्।
`Pull request` शब्द अलि अचम्मको लाग्न सक्छ किनभने वास्तवमा तपाईं आफ्नो परिवर्तनहरू प्रोजेक्टमा पुश गर्न चाहनुहुन्छ। तर मेन्टेनर (प्रोजेक्ट मालिक) वा कोर टिमले तपाईंको परिवर्तनहरूलाई प्रोजेक्टको "मुख्य" ब्रान्चमा मर्ज गर्नु अघि विचार गर्नुपर्छ, त्यसैले तपाईं वास्तवमा मेन्टेनरबाट परिवर्तनको निर्णयको अनुरोध गर्दै हुनुहुन्छ।
Pull request भनेको एउटा ठाउँ हो जहाँ शाखामा गरिएका फरक-फरक परिवर्तनहरू तुलना र छलफल गर्न सकिन्छ, समीक्षा, टिप्पणी, एकीकृत परीक्षणहरू, र अन्य कुराहरूको साथ। राम्रो pull request ले प्रायः commit message जस्तै नियमहरू पालना गर्छ। तपाईं आफ्नो कामले कुनै समस्या समाधान गरेको छ भने, issue tracker मा त्यसको सन्दर्भ थप्न सक्नुहुन्छ। यो `#` र त्यसपछि issue को नम्बर प्रयोग गरेर गरिन्छ। उदाहरणका लागि `#97`।
Pull request एउटा ठाउँ हो जहाँ ब्रान्चमा गरिएका परिवर्तनहरू तुलना र छलफल गर्न सकिन्छ, समीक्षा, टिप्पणीहरू, एकीकृत परीक्षणहरू, र अन्य धेरै कुराहरू गर्न सकिन्छ। राम्रो pull request ले कमिट मेसेजको जस्तै नियमहरू पालना गर्छ। तपाईं आफ्नो कामले कुनै समस्या समाधान गरेमा, समस्या ट्र्याकरमा समस्या उल्लेख गर्न सक्नुहुन्छ। यो `#` पछि तपाईंको समस्याको नम्बर प्रयोग गरेर गरिन्छ। उदाहरणका लागि `#97`।
🤞आशा गरौं कि सबै जाँचहरू पास हुन्छन् र परियोजनाको मालिक(हरू)ले तपाईंको परिवर्तनहरू परियोजनामा मर्ज गर्छन्🤞
🤞आशा गरौं कि सबै चेक पास हुन्छन् र प्रोजेक्ट मालिक(हरू)ले तपाईंको परिवर्तनहरू प्रोजेक्टमा मर्ज गर्छन्🤞
तपाईंको हालको स्थानीय कार्य शाखालाई GitHub मा रहेको सम्बन्धित रिमोट शाखाबाट सबै नयाँ commits हरूसँग अपडेट गर्नुहोस्:
GitHub मा रहेको रिमोट ब्रान्चबाट सबै नयाँ कमिटहरू आफ्नो स्थानीय कार्यरत ब्रान्चमा अपडेट गर्नुहोस्:
`git pull`
## खुला स्रोतमा योगदान गर्ने तरिका
## ओपन सोर्समा योगदान कसरी गर्ने
पहिले, GitHub मा तपाईंलाई चासो लाग्ने र जसमा तपाईं परिवर्तन गर्न चाहनुहुन्छ त्यस्तो एउटा repository (वा **repo**) खोजौं। तपाईंले यसको सामग्री आफ्नो कम्प्युटरमा प्रतिलिपि गर्न चाहनुहुनेछ।
पहिले, GitHub मा तपाईंलाई चासो लाग्ने र जसमा तपाईं परिवर्तन गर्न चाहनुहुन्छ त्यस्तो रिपोजिटरी (वा **repo**) खोजौं। तपाईंले यसको सामग्री आफ्नो मेसिनमा कपी गर्न चाहनुहुन्छ।
✅ 'सुरुवाती-अनुकूल' repos खोज्नको लागि [ट्याग 'good-first-issue' द्वारा खोजी गर्नुहोस्](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)।
✅ 'सुरुवाती-अनुकूल' रिपोहरू खोज्नको लागि [ट्याग 'good-first-issue' द्वारा खोज्नुहोस्](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)।
कोड प्रतिलिपि गर्ने धेरै तरिकाहरू छन्। एउटा तरिका भनेको HTTPS, SSH, वा GitHub CLI (Command Line Interface) प्रयोग गरेर repository को सामग्री "clone" गर्नु हो।
कोड कपी गर्ने धेरै तरिकाहरू छन्। एउटा तरिका भनेको HTTPS, SSH, वा GitHub CLI (कमाण्ड लाइन इन्टरफेस) प्रयोग गरेर रिपोजिटरीको सामग्री "क्लोन" गर्नु हो।
तपाईंको टर्मिनल खोल्नुहोस् र यसरी repository clone गर्नुहोस्:
टर्मिनल खोल्नुहोस् र रिपोजिटरी यसरी क्लोन गर्नुहोस्:
`git clone https://github.com/ProjectURL`
परियोजनामा काम गर्न, सही फोल्डरमा स्विच गर्नुहोस्:
प्रोजेक्टमा काम गर्न, सही फोल्डरमा स्विच गर्नुहोस्:
`cd ProjectURL`
तपाईं [Codespaces](https://github.com/features/codespaces), GitHub को embedded code editor / cloud development environment, वा [GitHub Desktop](https://desktop.github.com/) प्रयोग गरेर पनि सम्पूर्ण परियोजना खोल्न सक्नुहुन्छ।
तपाईं [Codespaces](https://github.com/features/codespaces), GitHub को एम्बेडेड कोड एडिटर / क्लाउड डेभलपमेन्ट वातावरण, वा [GitHub Desktop](https://desktop.github.com/) प्रयोग गरेर पनि सम्पूर्ण प्रोजेक्ट खोल्न सक्नुहुन्छ।
अन्तमा, तपाईं कोडलाई zipped फोल्डरको रूपमा डाउनलोड गर्न सक्नुहुन्छ।
अन्तमा, तपाईं कोडलाई जिप गरिएको फोल्डरमा डाउनलोड गर्न सक्नुहुन्छ।
### GitHub का केही थप रोचक कुरा
तपाईं GitHub मा कुनै पनि सार्वजनिक repository लाई star, watch, र/वा "fork" गर्न सक्नुहुन्छ। तपाईंले आफ्नो starred repositories शीर्ष-दायाँ ड्रप-डाउन मेनुमा फेला पार्न सक्नुहुन्छ। यो bookmark जस्तै हो, तर कोडको लागि।
तपाईं GitHub मा कुनै पनि सार्वजनिक रिपोजिटरीलाई स्टार, वाच र/वा "फोर्क" गर्न सक्नुहुन्छ। तपाईंले स्टार गरेका रिपोजिटरीहरूलाई शीर्ष-दायाँ ड्रप-डाउन मेनुमा फेला पार्न सक्नुहुन्छ। यो कोडको लागि बुकमार्क जस्तै हो।
परियोजनाहरूमा issue tracker हुन्छ, प्रायः GitHub मा "Issues" ट्याबमा, जहाँ परियोजनासँग सम्बन्धित समस्याहरूको बारेमा छलफल गरिन्छ। र Pull Requests ट्याबमा मानिसहरूले प्रगतिमा रहेका परिवर्तनहरूको बारेमा छलफल र समीक्षा गर्छन्।
प्रोजेक्टहरूमा समस्या ट्र्याकर हुन्छ, प्रायः GitHub मा "Issues" ट्याबमा, जबसम्म अन्यथा उल्लेख गरिएको छैन, जहाँ मानिसहरूले प्रोजेक्टसँग सम्बन्धित समस्याहरूको बारेमा छलफल गर्छन्। र Pull Requests ट्याबमा मानिसहरूले प्रगतिको क्रममा रहेका परिवर्तनहरूको बारेमा छलफल र समीक्षा गर्छन्।
परियोजनाहरूमा फोरम, मेलिङ लिस्ट, वा Slack, Discord, वा IRC जस्ता च्याट च्यानलहरूमा पनि छलफल हुन सक्छ।
प्रोजेक्टहरूमा फोरम, मेलिङ लिस्ट, वा Slack, Discord वा IRC जस्ता च्याट च्यानलहरूमा पनि छलफल हुन सक्छ।
✅ आफ्नो नयाँ GitHub repo मा वरिपरि हेर्नुहोस् र केही कुरा प्रयास गर्नुहोस्, जस्तै सेटिङहरू सम्पादन गर्नु, आफ्नो repo मा जानकारी थप्नु, र एउटा परियोजना (जस्तै Kanban बोर्ड) सिर्जना गर्नु। तपाईंले धेरै कुरा गर्न सक्नुहुन्छ!
✅ आफ्नो नयाँ GitHub रिपो वरिपरि हेर्नुहोस् र केही कुरा प्रयास गर्नुहोस्, जस्तै सेटिङहरू सम्पादन गर्नु, आफ्नो रिपोमा जानकारी थप्नु, र प्रोजेक्ट बनाउनुहोस् (जस्तै Kanban बोर्ड)। तपाईं धेरै कुरा गर्न सक्नुहुन्छ!
---
## 🚀 चुनौती
## 🚀 चुनौती
एउटा साथीलाई आफ्नो कोडमा काम गर्नको लागि जोडी बनाउनुहोस्। सहकार्यात्मक रूपमा एउटा परियोजना सिर्जना गर्नुहोस्, कोड fork गर्नुहोस्, शाखाहरू सिर्जना गर्नुहोस्, र परिवर्तनहरू मर्ज गर्नुहोस्।
साथीसँग जोडी बनाएर एक-अर्काको कोडमा काम गर्नुहोस्। सहकार्यात्मक रूपमा प्रोजेक्ट बनाउनुहोस्, कोड फोर्क गर्नुहोस्, ब्रान्चहरू बनाउनुहोस्, र परिवर्तनहरू मर्ज गर्नुहोस्।
अभ्यास, अभ्यास, अभ्यास। GitHub ले [skills.github.com](https://skills.github.com) मार्फत उत्कृष्ट सिकाइ मार्गहरू उपलब्ध गराएको छ:
अभ्यास, अभ्यास, अभ्यास। GitHub मा [skills.github.com](https://skills.github.com) मार्फत उत्कृष्ट सिकाइ मार्गहरू उपलब्ध छन्:
- [GitHub मा पहिलो हप्ता](https://skills.github.com/#first-week-on-github)
तपाईंले थप उन्नत पाठ्यक्रमहरू पनि फेला पार्नुहुनेछ।
तपाईंले थप उन्नत पाठ्यक्रमहरू पनि फेला पार्नुहुनेछ।
## असाइनमेन्ट
## असाइनमेन्ट
[GitHub मा पहिलो हप्ता कोर्स](https://skills.github.com/#first-week-on-github) पूरा गर्नुहोस्।
[GitHub मा पहिलो हप्ता पाठ्यक्रम](https://skills.github.com/#first-week-on-github) पूरा गर्नुहोस्।
---
**अस्वीकरण**:
यो दस्तावेज़ AI अनुवाद सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) प्रयोग गरेर अनुवाद गरिएको छ। हामी शुद्धताको लागि प्रयास गर्छौं, तर कृपया ध्यान दिनुहोस् कि स्वचालित अनुवादमा त्रुटिहरू वा अशुद्धताहरू हुन सक्छ। यसको मूल भाषा मा रहेको मूल दस्तावेज़लाई आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीको लागि, व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न हुने कुनै पनि गलतफहमी वा गलत व्याख्याको लागि हामी जिम्मेवार हुने छैनौं।
यो दस्तावेज़ [Co-op Translator](https://github.com/Azure/co-op-translator) नामक एआई अनुवाद सेवा प्रयोग गरेर अनुवाद गरिएको हो। हामी यथासम्भव शुद्धता सुनिश्चित गर्न प्रयास गर्छौं, तर कृपया ध्यान दिनुहोस् कि स्वचालित अनुवादमा त्रुटिहरू वा अशुद्धताहरू हुन सक्छ। मूल दस्तावेज़ यसको मातृभाषामा आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीको लागि, व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न हुने कुनै पनि गलतफहमी वा गलत व्याख्याको लागि हामी जिम्मेवार हुने छैनौं।
@ -14,8 +14,8 @@ Deze les behandelt de basisprincipes van GitHub, een platform om je code te host
> Sketchnote door [Tomomi Imura](https://twitter.com/girlie_mac)
## Quiz voorafgaand aan de les
[Quiz voorafgaand aan de les](https://ff-quizzes.netlify.app)
## Pre-Les Quiz
[Pre-les quiz](https://ff-quizzes.netlify.app)
## Introductie
@ -51,13 +51,13 @@ Je hebt zowel een map met een codeproject op je lokale computer (laptop of pc) n
## Codebeheer
Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan bijhouden met behulp van Git - het versiebeheersysteem. Sommige mensen vergelijken het gebruik van Git met het schrijven van een liefdesbrief aan je toekomstige zelf. Door je commit-berichten later terug te lezen, kun je je herinneren waarom je een bepaalde beslissing hebt genomen, of een wijziging "terugdraaien" - mits je goede "commit-berichten" schrijft.
Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan bijhouden met git - het versiebeheersysteem. Sommige mensen vergelijken het gebruik van git met het schrijven van een liefdesbrief aan je toekomstige zelf. Door je commitberichten dagen, weken of maanden later te lezen, kun je je herinneren waarom je een bepaalde beslissing hebt genomen, of een wijziging "terugdraaien" - dat is, wanneer je goede "commitberichten" schrijft.
### Taak: Maak een repository en commit code
> Bekijk de video
> Bekijk de video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Maak een repository op GitHub**. Op GitHub.com, in het tabblad repositories, of via de navigatiebalk rechtsboven, vind je de knop **new repo**.
@ -70,7 +70,7 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
cd [name of your folder]
```
1. **Initialiseer een Git-repository**. Typ in je project:
1. **Initialiseer een git-repository**. Typ in je project:
```bash
git init
@ -82,7 +82,7 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
git status
```
De uitvoer kan er ongeveer zo uitzien:
De output kan er ongeveer zo uitzien:
```output
Changes not staged for commit:
@ -93,7 +93,7 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
modified: file2.txt
```
Meestal vertelt een `git status`-commando je dingen zoals welke bestanden klaar zijn om _opgeslagen_ te worden in de repository of welke bestanden wijzigingen bevatten die je mogelijk wilt vastleggen.
Meestal vertelt een `git status`-commando je dingen zoals welke bestanden klaar zijn om te worden _opgeslagen_ in de repo of wijzigingen hebben die je wilt behouden.
1. **Voeg alle bestanden toe voor tracking**
Dit wordt ook wel het "stagen" van bestanden genoemd, of het toevoegen van bestanden aan de staging area.
@ -102,7 +102,7 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
git add .
```
Het argument `git add` plus `.` geeft aan dat al je bestanden en wijzigingen worden gevolgd.
Het `git add`-commando met het argument `.` geeft aan dat alle bestanden en wijzigingen worden bijgehouden.
1. **Voeg geselecteerde bestanden toe voor tracking**
@ -110,15 +110,15 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
git add [file or folder name]
```
Dit helpt ons om alleen geselecteerde bestanden toe te voegen aan de staging area wanneer we niet alle bestanden in één keer willen committen.
Hiermee kun je alleen geselecteerde bestanden toevoegen aan de staging area wanneer je niet alle bestanden tegelijk wilt committen.
1. **Haal bestanden uit de staging area**
1. **Haal alle bestanden uit de staging area**
```bash
git reset
```
Dit commando helpt ons om alle bestanden in één keer uit de staging area te halen.
Dit commando helpt je om alle bestanden in één keer uit de staging area te halen.
1. **Haal een specifiek bestand uit de staging area**
@ -126,37 +126,37 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
git reset [file or folder name]
```
Dit commando helpt ons om slechts één specifiek bestand uit de staging area te halen dat we niet willen opnemen in de volgende commit.
Dit commando helpt je om slechts één specifiek bestand uit de staging area te halen dat je niet wilt opnemen in de volgende commit.
1. **Leg je werk vast**. Op dit punt heb je de bestanden toegevoegd aan een zogenaamde _staging area_. Dit is een plek waar Git je bestanden bijhoudt. Om de wijziging permanent te maken, moet je de bestanden _committen_. Dit doe je door een _commit_ te maken met het `git commit`-commando. Een _commit_ vertegenwoordigt een opslagpunt in de geschiedenis van je repository. Typ het volgende om een _commit_ te maken:
1. **Je werk vastleggen**. Op dit punt heb je de bestanden toegevoegd aan een zogenaamde _staging area_. Een plek waar Git je bestanden bijhoudt. Om de wijziging permanent te maken, moet je de bestanden _committen_. Dit doe je door een _commit_ te maken met het `git commit`-commando. Een _commit_ vertegenwoordigt een opslaappunt in de geschiedenis van je repo. Typ het volgende om een _commit_ te maken:
```bash
git commit -m "first commit"
```
Dit commit al je bestanden met het bericht "first commit". Voor toekomstige commit-berichten wil je een meer beschrijvende omschrijving geven om aan te geven wat voor soort wijziging je hebt aangebracht.
Dit commit alle bestanden en voegt het bericht "first commit" toe. Voor toekomstige commitberichten wil je meer beschrijvende berichten gebruiken om duidelijk te maken wat voor soort wijziging je hebt aangebracht.
1. **Verbind je lokale Git-repository met GitHub**. Een Git-repository is handig op je computer, maar op een gegeven moment wil je een back-up van je bestanden ergens anders hebben en ook andere mensen uitnodigen om met je samen te werken aan je repository. Een geweldige plek om dit te doen is GitHub. We hebben al een repository op GitHub gemaakt, dus het enige wat we nog moeten doen is onze lokale Git-repository verbinden met GitHub. Het commando `git remote add` doet precies dat. Typ het volgende commando:
1. **Verbind je lokale Git-repo met GitHub**. Een Git-repo is handig op je computer, maar op een gegeven moment wil je een back-up van je bestanden ergens anders hebben en ook andere mensen uitnodigen om met je mee te werken aan je repo. Een geweldige plek om dat te doen is GitHub. We hebben al een repo op GitHub gemaakt, dus het enige wat we moeten doen is onze lokale Git-repo verbinden met GitHub. Het commando `git remote add` doet precies dat. Typ het volgende commando:
> Let op, voordat je het commando typt, ga naar de pagina van je GitHub-repository om de repository-URL te vinden. Je gebruikt deze in het onderstaande commando. Vervang ```https://github.com/username/repository_name.git``` door je GitHub-URL.
> Let op, voordat je het commando typt, ga naar de pagina van je GitHub-repo om de repository-URL te vinden. Je gebruikt deze in het onderstaande commando. Vervang ```https://github.com/username/repository_name.git``` door je GitHub-URL.
Dit creëert een _remote_, of verbinding, genaamd "origin" die verwijst naar de GitHub-repository die je eerder hebt gemaakt.
1. **Stuur lokale bestanden naar GitHub**. Tot nu toe heb je een _verbinding_ gemaakt tussen de lokale repository en de GitHub-repository. Laten we deze bestanden naar GitHub sturen met het volgende commando `git push`, zoals hieronder:
Dit maakt een _remote_, of verbinding, genaamd "origin" die wijst naar de GitHub-repository die je eerder hebt gemaakt.
1. **Stuur lokale bestanden naar GitHub**. Tot nu toe heb je een _verbinding_ gemaakt tussen de lokale repo en de GitHub-repo. Laten we deze bestanden naar GitHub sturen met het volgende commando `git push`, zoals hieronder:
> Let op, je branchnaam kan standaard anders zijn dan ```main```.
```bash
git push -u origin main
```
Dit stuurt je commits in je "main"-branch naar GitHub.
Dit stuurt je commits in je "main"-branch naar GitHub. Het instellen van de `upstream`-branch inclusief `-u` in het commando maakt een link tussen je lokale branch en de remote branch, zodat je eenvoudig `git push` of `git pull` kunt gebruiken zonder de branchnaam in de toekomst te specificeren. Git zal automatisch de upstream-branch gebruiken en je hoeft de branchnaam niet expliciet op te geven in toekomstige commando's.
2. **Meer wijzigingen toevoegen**. Als je verder wilt gaan met het aanbrengen van wijzigingen en deze naar GitHub wilt pushen, hoef je alleen de volgende drie commando's te gebruiken:
2. **Om meer wijzigingen toe te voegen**. Als je verder wilt gaan met het aanbrengen van wijzigingen en deze naar GitHub wilt pushen, hoef je alleen de volgende drie commando's te gebruiken:
```bash
git add .
@ -164,55 +164,55 @@ Stel dat je lokaal een map hebt met een codeproject en je wilt je voortgang gaan
git push
```
> Tip: Je wilt misschien ook een `.gitignore`-bestand gebruiken om te voorkomen dat bestanden die je niet wilt volgen, op GitHub verschijnen - zoals dat notitiebestand dat je in dezelfde map opslaat, maar geen plaats heeft in een openbare repository. Je kunt sjablonen voor `.gitignore`-bestanden vinden op [.gitignore templates](https://github.com/github/gitignore).
> Tip, je wilt misschien ook een `.gitignore`-bestand gebruiken om te voorkomen dat bestanden die je niet wilt bijhouden op GitHub verschijnen - zoals dat notitiebestand dat je in dezelfde map opslaat maar geen plaats heeft in een openbare repository. Je kunt sjablonen voor `.gitignore`-bestanden vinden op [.gitignore templates](https://github.com/github/gitignore).
#### Commit-berichten
#### Commitberichten
Een geweldig Git-commit-onderwerp voltooit de volgende zin:
Als dit wordt toegepast, zal deze commit <jouwonderwerphier>.
Een geweldig Git-commitonderwerp voltooit de volgende zin:
Als toegepast, zal deze commit <jouwonderwerphier>
Voor het onderwerp gebruik je de gebiedende wijs in de tegenwoordige tijd: "verander" in plaats van "veranderd" of "verandert".
Net als in het onderwerp, gebruik je in de optionele toelichting ook de gebiedende wijs in de tegenwoordige tijd. De toelichting moet de motivatie voor de wijziging bevatten en dit contrasteren met het vorige gedrag. Je legt de `waarom` uit, niet de `hoe`.
Voor het onderwerp gebruik je de gebiedende wijs, tegenwoordige tijd: "verander" in plaats van "veranderd" of "verandert".
Net als in het onderwerp, gebruik je in de body (optioneel) ook de gebiedende wijs, tegenwoordige tijd. De body moet de motivatie voor de wijziging bevatten en dit contrasteren met het vorige gedrag. Je legt de `waarom` uit, niet de `hoe`.
✅ Neem een paar minuten de tijd om rond te kijken op GitHub. Kun je een echt geweldig commit-bericht vinden? Kun je een heel minimaal bericht vinden? Welke informatie denk je dat het belangrijkst en nuttigst is om over te brengen in een commit-bericht?
✅ Neem een paar minuten de tijd om rond te surfen op GitHub. Kun je een echt geweldig commitbericht vinden? Kun je een heel minimaal bericht vinden? Welke informatie denk je dat het belangrijkst en nuttigst is om over te brengen in een commitbericht?
### Taak: Samenwerken
De belangrijkste reden om dingen op GitHub te zetten, was om het mogelijk te maken samen te werken met andere ontwikkelaars.
De belangrijkste reden om dingen op GitHub te zetten was om het mogelijk te maken samen te werken met andere ontwikkelaars.
## Samenwerken aan projecten met anderen
> Bekijk de video
> Bekijk de video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
In je repository, navigeer naar `Insights > Community` om te zien hoe jouw project zich verhoudt tot de aanbevolen community-standaarden.
In je repository, navigeer naar `Insights > Community` om te zien hoe jouw project zich verhoudt tot aanbevolen communitystandaarden.
Hier zijn enkele dingen die je GitHub-repository kunnen verbeteren:
- **Beschrijving**. Heb je een beschrijving toegevoegd voor je project?
- **README**. Heb je een README toegevoegd? GitHub biedt richtlijnen voor het schrijven van een [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Bijdragegids**. Heeft je project [bijdragegidsen](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Gedragscode**. Een [gedragscode](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licentie**. Misschien wel het belangrijkst, een [licentie](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Hier zijn enkele dingen die je GitHub-repo kunnen verbeteren:
- **Beschrijving**. Heb je een beschrijving toegevoegd voor je project?
- **README**. Heb je een README toegevoegd? GitHub biedt richtlijnen voor het schrijven van een [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Richtlijnen voor bijdragen**. Heeft je project [richtlijnen voor bijdragen](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Gedragscode**. Een [gedragscode](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licentie**. Misschien wel het belangrijkst, een [licentie](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Al deze middelen zullen het onboarden van nieuwe teamleden ten goede komen. Dit zijn doorgaans de dingen waar nieuwe bijdragers naar kijken voordat ze zelfs maar naar je code kijken, om te bepalen of jouw project de juiste plek is om hun tijd aan te besteden.
Al deze middelen zullen het onboardingproces voor nieuwe teamleden ten goede komen. En dit zijn meestal de dingen waar nieuwe bijdragers naar kijken voordat ze zelfs maar naar je code kijken, om te bepalen of jouw project de juiste plek is om hun tijd aan te besteden.
✅ README-bestanden, hoewel ze tijd kosten om voor te bereiden, worden vaak verwaarloosd door drukke maintainers. Kun je een voorbeeld vinden van een bijzonder beschrijvende README? Opmerking: er zijn enkele [tools om goede READMEs te maken](https://www.makeareadme.com/) die je misschien wilt proberen.
✅ README-bestanden, hoewel ze tijd kosten om te maken, worden vaak verwaarloosd door drukke beheerders. Kun je een voorbeeld vinden van een bijzonder beschrijvende README? Opmerking: er zijn enkele [tools om goede READMEs te maken](https://www.makeareadme.com/) die je misschien wilt proberen.
### Taak: Code samenvoegen
Bijdragedocumenten helpen mensen bijdragen aan het project. Ze leggen uit wat voor soort bijdragen je zoekt en hoe het proces werkt. Bijdragers moeten een reeks stappen doorlopen om te kunnen bijdragen aan jouw repository op GitHub:
Bijdragedocumenten helpen mensen bijdragen aan het project. Ze leggen uit wat voor soort bijdragen je zoekt en hoe het proces werkt. Bijdragers moeten een reeks stappen doorlopen om te kunnen bijdragen aan je repo op GitHub:
1. **Fork je repository**. Je wilt waarschijnlijk dat mensen je project _forken_. Forken betekent dat ze een kopie van jouw repository maken op hun GitHub-profiel.
1. **Klonen**. Vanaf daar klonen ze het project naar hun lokale computer.
1. **Fork je repo**. Je wilt waarschijnlijk dat mensen je project _forken_. Forken betekent dat ze een replica van je repository maken op hun GitHub-profiel.
1. **Clone**. Vanaf daar zullen ze het project naar hun lokale computer clonen.
1. **Maak een branch**. Je wilt dat ze een _branch_ maken voor hun werk.
1. **Focus hun wijziging op één gebied**. Vraag bijdragers om hun bijdragen op één ding tegelijk te concentreren - zo is de kans groter dat je hun werk kunt _mergen_. Stel je voor dat ze een bugfix schrijven, een nieuwe functie toevoegen en verschillende tests bijwerken - wat als je slechts 2 van de 3, of 1 van de 3 wijzigingen wilt of kunt implementeren?
1. **Focus hun wijziging op één gebied**. Vraag bijdragers om hun bijdragen op één ding tegelijk te concentreren - zo is de kans groter dat je hun werk kunt _samenvoegen_. Stel je voor dat ze een bugfix schrijven, een nieuwe functie toevoegen en verschillende tests bijwerken - wat als je slechts 2 van de 3, of 1 van de 3 wijzigingen wilt implementeren?
✅ Stel je een situatie voor waarin branches bijzonder belangrijk zijn voor het schrijven en leveren van goede code. Aan welke gebruiksscenario's kun je denken?
✅ Stel je een situatie voor waarin branches bijzonder belangrijk zijn voor het schrijven en leveren van goede code. Welke gebruiksscenario's kun je bedenken?
> Opmerking: wees de verandering die je in de wereld wilt zien, en maak ook branches voor je eigen werk. Alle commits die je maakt, worden gemaakt op de branch waar je momenteel op "uitgecheckt" bent. Gebruik `git status` om te zien op welke branch dat is.
> Opmerking, wees de verandering die je in de wereld wilt zien, en maak ook branches voor je eigen werk. Alle commits die je maakt, worden gemaakt op de branch waar je momenteel "uitgecheckt" bent. Gebruik `git status` om te zien op welke branch dat is.
Laten we een workflow voor bijdragers doorlopen. Stel dat de bijdrager de repository al heeft _geforkt_ en _gekloned_, zodat ze een Git-repository hebben die klaar is om aan te werken op hun lokale computer:
Laten we een workflow voor bijdragers doorlopen. Stel dat de bijdrager de repo al heeft _geforkt_ en _gecloned_, zodat ze een Git-repo hebben die klaar is om aan te werken op hun lokale computer:
1. **Maak een branch**. Gebruik het commando `git branch` om een branch te maken die de wijzigingen bevat die ze willen bijdragen:
@ -220,120 +220,125 @@ Laten we een workflow voor bijdragers doorlopen. Stel dat de bijdrager de reposi
git branch [branch-name]
```
1. **Schakel over naar de werkbranch**. Schakel over naar de opgegeven branch en werk de werkdirectory bij met `git switch`:
1. **Schakel over naar de werkbranch**. Schakel over naar de opgegeven branch en werk de werkmap bij met `git switch`:
```bash
git switch [branch-name]
```
1. **Doe je werk**. Op dit punt wil je je wijzigingen toevoegen. Vergeet niet om Git hierover te informeren met de volgende commando's:
1. **Doe werk**. Op dit punt wil je je wijzigingen toevoegen. Vergeet niet om Git hierover te informeren met de volgende commando's:
```bash
git add .
git commit -m "my changes"
```
Zorg ervoor dat je je commit een goede naam geeft, zowel voor jezelf als voor de maintainer van de repository waaraan je helpt.
Zorg ervoor dat je je commit een goede naam geeft, zowel voor jezelf als voor de beheerder van de repo waaraan je helpt.
1. **Combineer je werk met de `main`-branch**. Op een gegeven moment ben je klaar met werken en wil je je werk combineren met dat van de `main`-branch. De `main`-branch kan ondertussen zijn gewijzigd, dus zorg ervoor dat je deze eerst bijwerkt naar de nieuwste versie met de volgende commando's:
1. **Combineer je werk met de `main`branch**. Op een gegeven moment ben je klaar met werken en wil je je werk combineren met dat van de `main` branch. De `main`branch kan ondertussen zijn gewijzigd, dus zorg ervoor dat je deze eerst bijwerkt naar de nieuwste versie met de volgende commando's:
```bash
git switch main
git pull
```
Op dit punt wil je ervoor zorgen dat eventuele _conflicten_, situaties waarin Git de wijzigingen niet gemakkelijk kan _combineren_, plaatsvinden in jouw werkbranch. Voer daarom de volgende commando's uit:
Op dit punt wil je ervoor zorgen dat eventuele _conflicten_, situaties waarin Git de wijzigingen niet gemakkelijk kan _combineren_, plaatsvinden in je werkbranch. Voer daarom de volgende commando's uit:
```bash
git switch [branch_name]
git merge main
```
Dit brengt alle wijzigingen van `main` naar jouw branch en hopelijk kun je gewoon doorgaan. Zo niet, dan zal VS Code je vertellen waar Git _in de war_ is en pas je de betreffende bestanden aan om aan te geven welke inhoud het meest accuraat is.
Het `git merge main`-commando brengt alle wijzigingen van `main` naar je branch. Hopelijk kun je gewoon doorgaan. Zo niet, dan zal VS Code je vertellen waar Git _verward_ is en pas je de getroffen bestanden aan om aan te geven welke inhoud het meest accuraat is.
Om naar een andere branch te schakelen, gebruik je het moderne `git switch`-commando:
```bash
git switch [branch_name]
1. **Stuur je werk naar GitHub**. Je werk naar GitHub sturen betekent twee dingen: je branch pushen naar je repository en vervolgens een PR (Pull Request) openen.
1. **Stuur je werk naar GitHub**. Je werk naar GitHub sturen betekent twee dingen: je branch naar je repo pushen en vervolgens een PR (Pull Request) openen.
```bash
git push --set-upstream origin [branch-name]
```
Het bovenstaande commando maakt de branch aan op je geforkte repository.
1. **Open een PR**. Vervolgens wil je een PR openen. Dit doe je door naar de geforkte repository op GitHub te navigeren. Je ziet een indicatie op GitHub waar wordt gevraagd of je een nieuwe PR wilt maken. Klik daarop en je wordt naar een interface geleid waar je de commit-berichttitel kunt wijzigen en een meer geschikte beschrijving kunt geven. Nu ziet de maintainer van de repository die je hebt geforkt deze PR en _met een beetje geluk_ waarderen ze het en _mergen_ ze je PR. Je bent nu een bijdrager, hoera :)
Het bovenstaande commando maakt de branch aan op je geforkte repo.
1. **Open een PR**. Vervolgens wil je een PR openen. Dit doe je door naar de geforkte repo op GitHub te gaan. Je ziet op GitHub een indicatie waar wordt gevraagd of je een nieuwe PR wilt maken. Klik daarop en je komt in een interface waar je de commitberichttitel kunt wijzigen en een meer geschikte beschrijving kunt toevoegen. Nu zal de maintainer van de repo die je hebt geforkt deze PR zien en _duimen maar_ dat ze het waarderen en jouw PR _mergen_. Je bent nu een bijdrager, yay :)
1. **Ruim op**. Het wordt als goede gewoonte beschouwd om op te ruimen nadat je succesvol een PR hebt gemerged. Je wilt zowel je lokale branch als de branch die je naar GitHub hebt gepusht opruimen. Verwijder deze eerst lokaal met het volgende commando:
1. **Opruimen**. Het wordt als goede gewoonte beschouwd om na het succesvol mergen van een PR je werk op te ruimen. Je wilt zowel je lokale branch als de branch die je naar GitHub hebt gepusht opruimen. Laten we eerst de lokale branch verwijderen met het volgende commando:
```bash
git branch -d [branch-name]
```
Zorg er vervolgens voor dat je naar de GitHub-pagina van de geforkte repo gaat en de remote branch verwijdert die je net hebt gepusht.
Zorg ervoor dat je naar de GitHub-pagina van de geforkte repository gaat en de remote branch verwijdert die je zojuist hebt gepusht.
`Pull request` lijkt misschien een rare term, omdat je eigenlijk je wijzigingen naar het project wilt pushen. Maar de maintainer (projecteigenaar) of het kernteam moet je wijzigingen beoordelen voordat ze worden samengevoegd met de "main" branch van het project. Je vraagt dus eigenlijk om een besluit van een maintainer over je wijziging.
`Pull request` lijkt een vreemde term, omdat je eigenlijk je wijzigingen naar het project wilt pushen. Maar de maintainer (projecteigenaar) of het kernteam moet je wijzigingen beoordelen voordat ze worden gemerged met de "main" branch van het project. Je vraagt dus eigenlijk om een besluit over je wijziging van een maintainer.
Een pull request is de plek waar je de verschillen die op een branch zijn geïntroduceerd kunt vergelijken en bespreken, met reviews, opmerkingen, geïntegreerde tests en meer. Een goede pull request volgt ongeveer dezelfde regels als een commitbericht. Je kunt een verwijzing toevoegen naar een issue in de issue tracker, bijvoorbeeld wanneer je werk een issue oplost. Dit doe je door een `#` te gebruiken, gevolgd door het nummer van je issue. Bijvoorbeeld `#97`.
Een pull request is de plek waar je de verschillen die op een branch zijn geïntroduceerd kunt vergelijken en bespreken, met reviews, opmerkingen, geïntegreerde tests en meer. Een goede pull request volgt ongeveer dezelfde regels als een commitbericht. Je kunt een verwijzing naar een issue in de issue tracker toevoegen, bijvoorbeeld wanneer je werk een issue oplost. Dit doe je door een `#` te gebruiken, gevolgd door het nummer van je issue. Bijvoorbeeld `#97`.
🤞Duimen dat alle controles slagen en de projecteigenaar(s) je wijzigingen samenvoegen met het project🤞
🤞Duimen maar dat alle checks slagen en de projecteigenaar(s) je wijzigingen in het project mergen🤞
Werk je huidige lokale werkbranch bij met alle nieuwe commits van de bijbehorende remote branch op GitHub:
Werk je huidige lokale werkbranch bij met alle nieuwe commits van de corresponderende remote branch op GitHub:
`git pull`
## Hoe bijdragen aan open source
## Hoe draag je bij aan open source
Laten we eerst een repository (of **repo**) op GitHub vinden die je interesse heeft en waaraan je een wijziging wilt bijdragen. Je wilt de inhoud ervan naar je computer kopiëren.
Laten we eerst een repository (of **repo**) op GitHub vinden die je interesseert en waaraan je een wijziging wilt bijdragen. Je wilt de inhoud ervan naar je machine kopiëren.
✅ Een goede manier om 'beginner-vriendelijke' repos te vinden is door te [zoeken op de tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Een goede manier om 'beginner-vriendelijke' repos te vinden is door [te zoeken op de tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Er zijn verschillende manieren om code te kopiëren. Een manier is om de inhoud van de repository te "clonen" met behulp van HTTPS, SSH of de GitHub CLI (Command Line Interface).
Er zijn verschillende manieren om code te kopiëren. Eén manier is om de inhoud van de repository te "clonen", via HTTPS, SSH of met de GitHub CLI (Command Line Interface).
Open je terminal en clone de repository als volgt:
Open je terminal en clone de repository zoals hieronder:
`git clone https://github.com/ProjectURL`
Om aan het project te werken, ga je naar de juiste map:
Om aan het project te werken, ga naar de juiste map:
`cd ProjectURL`
Je kunt het hele project ook openen met [Codespaces](https://github.com/features/codespaces), de ingebouwde code-editor / cloudontwikkelomgeving van GitHub, of met [GitHub Desktop](https://desktop.github.com/).
Je kunt het hele project ook openen met [Codespaces](https://github.com/features/codespaces), de ingebouwde code-editor / cloudontwikkelomgeving van GitHub, of [GitHub Desktop](https://desktop.github.com/).
Ten slotte kun je de code downloaden in een gezipte map.
Tot slot kun je de code downloaden in een gezipte map.
### Een paar andere interessante dingen over GitHub
### Een paar interessante dingen over GitHub
Je kunt elke openbare repository op GitHub ster geven, volgen en/of "forken". Je vindt je gestar-de repositories in het menu rechtsboven. Het is als bladwijzers maken, maar dan voor code.
Je kunt elke openbare repository op GitHub ster geven, volgen en/of "forken". Je kunt je gestarred repositories vinden in het drop-down menu rechtsboven. Het is als bladwijzers maken, maar dan voor code.
Projecten hebben een issue tracker, meestal op GitHub in het tabblad "Issues", tenzij anders aangegeven, waar mensen problemen met betrekking tot het project bespreken. En in het tabblad Pull Requests bespreken en beoordelen mensen wijzigingen die in behandeling zijn.
Projecten hebben een issue tracker, meestal op GitHub in het tabblad "Issues", tenzij anders aangegeven, waar mensen problemen met betrekking tot het project bespreken. En het tabblad Pull Requests is waar mensen wijzigingen bespreken en beoordelen die in behandeling zijn.
Projecten kunnen ook discussies hebben in forums, mailinglijsten of chatkanalen zoals Slack, Discord of IRC.
✅ Kijk eens rond in je nieuwe GitHub-repo en probeer een paar dingen, zoals instellingen bewerken, informatie toevoegen aan je repo en een project maken (zoals een Kanban-bord). Er is veel te ontdekken!
✅ Kijk eens rond in je nieuwe GitHub-repo en probeer een paar dingen, zoals instellingen bewerken, informatie toevoegen aan je repo en een project maken (zoals een Kanban-bord). Er is veel dat je kunt doen!
---
## 🚀 Uitdaging
## 🚀 Uitdaging
Werk samen met een vriend aan elkaars code. Maak samen een project, fork code, maak branches en voeg wijzigingen samen.
Werk samen met een vriend aan elkaars code. Maak samen een project, fork code, maak branches en merge wijzigingen.
## Quiz na de les
## Quiz na de les
[Quiz na de les](https://ff-quizzes.netlify.app/web/en/)
## Herhaling& Zelfstudie
## Review& Zelfstudie
Lees meer over [bijdragen aan open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Lees meer over [bijdragen aan open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Oefen, oefen, oefen. GitHub biedt geweldige leerpaden aan via [skills.github.com](https://skills.github.com):
Oefen, oefen, oefen. GitHub heeft geweldige leerpaden beschikbaar via [skills.github.com](https://skills.github.com):
- [Eerste week op GitHub](https://skills.github.com/#first-week-on-github)
Je vindt er ook meer gevorderde cursussen.
Je vindt er ook meer gevorderde cursussen.
## Opdracht
## Opdracht
Voltooi [de cursus Eerste week op GitHub](https://skills.github.com/#first-week-on-github)
---
**Disclaimer**:
Dit document is vertaald met behulp van de AI-vertalingsservice [Co-op Translator](https://github.com/Azure/co-op-translator). Hoewel we streven naar nauwkeurigheid, dient u zich ervan bewust te zijn dat geautomatiseerde vertalingen fouten of onnauwkeurigheden kunnen bevatten. Het originele document in de oorspronkelijke taal moet worden beschouwd als de gezaghebbende bron. Voor kritieke informatie wordt professionele menselijke vertaling aanbevolen. Wij zijn niet aansprakelijk voor misverstanden of verkeerde interpretaties die voortvloeien uit het gebruik van deze vertaling.
Dit document is vertaald met behulp van de AI-vertalingsservice [Co-op Translator](https://github.com/Azure/co-op-translator). Hoewel we streven naar nauwkeurigheid, dient u zich ervan bewust te zijn dat geautomatiseerde vertalingen fouten of onnauwkeurigheden kunnen bevatten. Het originele document in de oorspronkelijke taal moet worden beschouwd als de gezaghebbende bron. Voor cruciale informatie wordt professionele menselijke vertaling aanbevolen. Wij zijn niet aansprakelijk voor misverstanden of verkeerde interpretaties die voortvloeien uit het gebruik van deze vertaling.
@ -23,11 +23,11 @@ I denne leksjonen skal vi dekke:
- hvordan du sporer arbeidet du gjør på din maskin
- hvordan du jobber med prosjekter sammen med andre
- hvordan du bidrar til åpen kildekode
- hvordan du bidrar til åpen kildekode-programvare
### Forutsetninger
Før du begynner, må du sjekke om Git er installert. I terminalen skriver du:
Før du begynner, må du sjekke om Git er installert. Skriv følgende i terminalen:
`git --version`
Hvis Git ikke er installert, [last ned Git](https://git-scm.com/downloads). Deretter setter du opp din lokale Git-profil i terminalen:
@ -39,19 +39,19 @@ For å sjekke om Git allerede er konfigurert, kan du skrive:
Du trenger også en GitHub-konto, en kodeeditor (som Visual Studio Code), og du må åpne terminalen (eller: kommandoprompt).
Gå til [github.com](https://github.com/) og opprett en konto hvis du ikke allerede har gjort det, eller logg inn og fyll ut profilen din.
Gå til [github.com](https://github.com/) og opprett en konto hvis du ikke allerede har en, eller logg inn og fyll ut profilen din.
✅ GitHub er ikke den eneste kode-repositoriet i verden; det finnes andre, men GitHub er den mest kjente.
✅ GitHub er ikke det eneste kodearkivet i verden; det finnes andre, men GitHub er det mest kjente.
### Forberedelse
Du trenger både en mappe med et kodeprosjekt på din lokale maskin (laptop eller PC), og et offentlig repository på GitHub, som vil tjene som et eksempel på hvordan du kan bidra til andres prosjekter.
Du trenger både en mappe med et kodeprosjekt på din lokale maskin (laptop eller PC), og et offentlig repository på GitHub, som vil tjene som et eksempel på hvordan du kan bidra til andres prosjekter.
---
## Kodeadministrasjon
La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å spore fremgangen din ved hjelp av git - versjonskontrollsystemet. Noen sammenligner det å bruke git med å skrive et kjærlighetsbrev til ditt fremtidige jeg. Når du leser commit-meldingene dine dager, uker eller måneder senere, vil du kunne huske hvorfor du tok en beslutning, eller "rulle tilbake" en endring - det vil si, når du skriver gode "commit-meldinger".
La oss si at du har en mappe lokalt med et kodeprosjekt, og du ønsker å begynne å spore fremgangen din ved hjelp av git - versjonskontrollsystemet. Noen sammenligner det å bruke git med å skrive et kjærlighetsbrev til ditt fremtidige jeg. Når du leser commit-meldingene dine dager, uker eller måneder senere, vil du kunne huske hvorfor du tok en beslutning, eller "rulle tilbake" en endring - det vil si, når du skriver gode "commit-meldinger".
### Oppgave: Lag et repository og commit kode
@ -59,9 +59,10 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Opprett repository på GitHub**. På GitHub.com, i repositories-fanen, eller fra navigasjonslinjen øverst til høyre, finn knappen **new repo**.
1. Gi repositoryet (mappen) ditt et navn.
1. Gi repositoryet (mappen) ditt et navn
1. Velg **create repository**.
1. **Naviger til arbeidsmappen din**. I terminalen, bytt til mappen (også kjent som katalogen) du vil begynne å spore. Skriv:
@ -70,19 +71,19 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
cd [name of your folder]
```
1. **Initialiser et git-repository**. I prosjektet ditt skriver du:
1. **Initialiser et git-repository**. I prosjektet ditt, skriv:
```bash
git init
```
1. **Sjekk status**. For å sjekke statusen til repositoryet ditt, skriver du:
1. **Sjekk status**. For å sjekke statusen til repositoryet ditt, skriv:
```bash
git status
```
Utdataene kan se slik ut:
Utdataene kan se omtrent slik ut:
```output
Changes not staged for commit:
@ -93,16 +94,16 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
modified: file2.txt
```
Typisk vil en `git status`-kommando fortelle deg ting som hvilke filer som er klare til å _lagres_ i repoet eller har endringer som du kanskje vil vedvare.
Typisk gir kommandoen `git status` deg informasjon som hvilke filer som er klare til å bli _lagret_ i repoet eller har endringer som du kanskje vil vedvare.
1. **Legg til alle filer for sporing**
Dette kalles også staging av filer/legging av filer i staging-området.
1. **Legg til alle filer for sporing**
Dette kalles også staging av filer/legging av filer til staging-området.
```bash
git add .
```
`git add` pluss `.`-argumentet indikerer at alle filene og endringene dine skal spores.
Argumentet `git add` pluss `.` indikerer at alle filene og endringene dine skal spores.
1. **Legg til utvalgte filer for sporing**
@ -110,7 +111,7 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
git add [file or folder name]
```
Dette hjelper oss med å legge til kun utvalgte filer i staging-området når vi ikke vil committe alle filene samtidig.
Dette hjelper oss med å legge til kun utvalgte filer i staging-området når vi ikke ønsker å commit alle filer samtidig.
1. **Fjern staging for alle filer**
@ -126,19 +127,19 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
git reset [file or folder name]
```
Denne kommandoen hjelper oss med å fjerne staging for kun en bestemt fil som vi ikke vil inkludere i neste commit.
Denne kommandoen hjelper oss med å fjerne staging for kun en bestemt fil som vi ikke ønsker å inkludere i neste commit.
1. **Vedvar arbeidet ditt**. På dette punktet har du lagt til filene i et såkalt _staging-område_. Et sted hvor Git sporer filene dine. For å gjøre endringen permanent må du _committe_ filene. For å gjøre dette oppretter du en _commit_ med kommandoen `git commit`. En _commit_ representerer et lagringspunkt i historien til repoet ditt. Skriv følgende for å opprette en _commit_:
1. **Vedvar arbeidet ditt**. På dette tidspunktet har du lagt til filene i et såkalt _staging-område_. Et sted hvor Git sporer filene dine. For å gjøre endringen permanent må du _commit_ filene. For å gjøre dette oppretter du en _commit_ med kommandoen `git commit`. En _commit_ representerer et lagringspunkt i historien til repoet ditt. Skriv følgende for å opprette en _commit_:
```bash
git commit -m "first commit"
```
Dette committe alle filene dine, med meldingen "first commit". For fremtidige commit-meldinger vil du ønske å være mer beskrivende for å formidle hvilken type endring du har gjort.
Dette committer alle filene dine, med meldingen "first commit". For fremtidige commit-meldinger vil du ønske å være mer beskrivende for å formidle hvilken type endring du har gjort.
1. **Koble ditt lokale Git-repo med GitHub**. Et Git-repo er nyttig på din maskin, men på et tidspunkt vil du ha en backup av filene dine et sted og også invitere andre til å jobbe med deg på repoet ditt. Et flott sted å gjøre dette er GitHub. Husk at vi allerede har opprettet et repo på GitHub, så det eneste vi trenger å gjøre er å koble vårt lokale Git-repo med GitHub. Kommandoen `git remote add` vil gjøre nettopp dette. Skriv følgende kommando:
1. **Koble ditt lokale Git-repo med GitHub**. Et Git-repo er nyttig på din maskin, men på et tidspunkt vil du ha en backup av filene dine et annet sted og også invitere andre til å jobbe med deg på repoet ditt. Et flott sted å gjøre dette er GitHub. Husk at vi allerede har opprettet et repo på GitHub, så det eneste vi trenger å gjøre er å koble vårt lokale Git-repo med GitHub. Kommandoen `git remote add` vil gjøre nettopp dette. Skriv følgende kommando:
> Merk, før du skriver kommandoen, gå til GitHub-reposiden din for å finne repository-URL-en. Du vil bruke den i kommandoen nedenfor. Erstatt ```https://github.com/username/repository_name.git``` med din GitHub-URL.
> Merk, før du skriver kommandoen, gå til GitHub-repo-siden din for å finne repository-URL-en. Du vil bruke den i kommandoen nedenfor. Erstatt ```https://github.com/username/repository_name.git``` med din GitHub-URL.
@ -148,13 +149,13 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
1. **Send lokale filer til GitHub**. Så langt har du opprettet en _tilkobling_ mellom det lokale repoet og GitHub-repoet. La oss sende disse filene til GitHub med følgende kommando `git push`, slik:
> Merk, gren-navnet ditt kan være forskjellig fra ```main``` som standard.
> Merk, navnet på grenen din kan være forskjellig fra ```main``` som standard.
```bash
git push -u origin main
```
Dette sender commitene dine i "main"-grenen til GitHub.
Dette sender commitene dine i "main"-grenen til GitHub. Å sette opp `upstream`-grenen inkludert `-u` i kommandoen etablerer en kobling mellom din lokale gren og den eksterne grenen, slik at du enkelt kan bruke git push eller git pull uten å spesifisere grenens navn i fremtiden. Git vil automatisk bruke upstream-grenen, og du trenger ikke å spesifisere grenens navn eksplisitt i fremtidige kommandoer.
2. **Legg til flere endringer**. Hvis du vil fortsette å gjøre endringer og sende dem til GitHub, trenger du bare å bruke følgende tre kommandoer:
@ -164,14 +165,14 @@ La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å sp
git push
```
> Tips, du vil kanskje også adoptere en `.gitignore`-fil for å forhindre at filer du ikke vil spore dukker opp på GitHub - som den notatfilen du lagrer i samme mappe, men som ikke har noen plass i et offentlig repository. Du kan finne maler for `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
> Tips, du vil kanskje også adoptere en `.gitignore`-fil for å forhindre at filer du ikke ønsker å spore dukker opp på GitHub - som den notatfilen du lagrer i samme mappe, men som ikke har noen plass i et offentlig repository. Du kan finne maler for `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
#### Commit-meldinger
En flott Git commit-emnelinje fullfører følgende setning:
Hvis den brukes, vil denne committen<dinemnelinjeher>
En flott Git commit-emnelinje fullfører følgende setning:
Hvis den brukes, vil denne commit <dinemnelinjeher>
For emnet, bruk imperativ, nåtid: "endre" ikke "endret" eller "endrer".
For emnet, bruk imperativ, nåtid: "endre" ikke "endret" eller "endrer".
Som i emnet, bruk også imperativ, nåtid i kroppen (valgfritt). Kroppen bør inkludere motivasjonen for endringen og kontrastere dette med tidligere oppførsel. Du forklarer `hvorfor`, ikke `hvordan`.
✅ Ta noen minutter til å surfe rundt på GitHub. Kan du finne en virkelig flott commit-melding? Kan du finne en veldig minimal en? Hvilken informasjon synes du er den viktigste og mest nyttige å formidle i en commit-melding?
@ -188,25 +189,25 @@ Hovedgrunnen til å legge ting på GitHub var å gjøre det mulig å samarbeide
I repositoryet ditt, naviger til `Insights > Community` for å se hvordan prosjektet ditt sammenlignes med anbefalte fellesskapsstandarder.
Her er noen ting som kan forbedre GitHub-repoet ditt:
- **Beskrivelse**. La du til en beskrivelse for prosjektet ditt?
- **README**. La du til en README? GitHub gir veiledning for å skrive en [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Retningslinjer for bidrag**. Har prosjektet ditt [retningslinjer for bidrag](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Code of Conduct**. En [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Lisens**. Kanskje viktigst, en [lisens](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Her er noen ting som kan forbedre GitHub-repoet ditt:
- **Beskrivelse**. La du til en beskrivelse for prosjektet ditt?
- **README**. La du til en README? GitHub gir veiledning for å skrive en [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Retningslinjer for bidrag**. Har prosjektet ditt [retningslinjer for bidrag](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Etiske retningslinjer**. Har prosjektet ditt en [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Lisens**. Kanskje viktigst, har prosjektet en [lisens](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Alle disse ressursene vil være til nytte for å onboarde nye teammedlemmer. Og dette er typisk de tingene nye bidragsytere ser på før de i det hele tatt ser på koden din, for å finne ut om prosjektet ditt er det rette stedet for dem å bruke tiden sin.
✅ README-filer, selv om de tar tid å forberede, blir ofte neglisjert av travle vedlikeholdere. Kan du finne et eksempel på en spesielt beskrivende README? Merk: det finnes noen [verktøy for å lage gode README-er](https://www.makeareadme.com/) som du kanskje vil prøve.
✅ README-filer, selv om de tar tid å forberede, blir ofte neglisjert av travle vedlikeholdere. Kan du finne et eksempel på en spesielt beskrivende README? Merk: det finnes noen [verktøy for å lage gode README-filer](https://www.makeareadme.com/) som du kanskje vil prøve.
### Oppgave: Slå sammen kode
Bidragsdokumenter hjelper folk med å bidra til prosjektet. Det forklarer hvilke typer bidrag du ser etter og hvordan prosessen fungerer. Bidragsytere må gå gjennom en rekke trinn for å kunne bidra til repoet ditt på GitHub:
Bidragsdokumenter hjelper folk med å bidra til prosjektet. De forklarer hvilke typer bidrag du ser etter og hvordan prosessen fungerer. Bidragsytere må gå gjennom en rekke trinn for å kunne bidra til repoet ditt på GitHub:
1. **Forke repoet ditt**. Du vil sannsynligvis at folk skal _forke_ prosjektet ditt. Forking betyr å opprette en kopi av repositoryet på deres GitHub-profil.
1. **Clone**. Derfra vil de klone prosjektet til sin lokale maskin.
1. **Opprett en gren**. Du vil be dem om å opprette en _gren_ for arbeidet sitt.
1. **Fokuser endringen på ett område**. Be bidragsytere om å konsentrere bidragene sine om én ting om gangen - på den måten er sjansen for at du kan _slå sammen_ arbeidet deres høyere. Tenk deg at de skriver en feilretting, legger til en ny funksjon, og oppdaterer flere tester - hva om du vil, eller bare kan implementere 2 av 3, eller 1 av 3 endringer?
1. **Fork repoet ditt**. Du vil sannsynligvis at folk skal _forke_ prosjektet ditt. Forking betyr å lage en kopi av repositoryet ditt på deres GitHub-profil.
1. **Clone**. Derfra vil de klone prosjektet til sin lokale maskin.
1. **Opprett en gren**. Du vil be dem om å opprette en _gren_ for arbeidet sitt.
1. **Fokuser endringen på ett område**. Be bidragsytere om å konsentrere bidragene sine på én ting om gangen - på den måten er sjansen større for at du kan _slå sammen_ arbeidet deres. Tenk deg at de skriver en feilretting, legger til en ny funksjon og oppdaterer flere tester - hva om du vil, eller bare kan implementere 2 av 3, eller 1 av 3 endringer?
✅ Tenk deg en situasjon der grener er spesielt kritiske for å skrive og levere god kode. Hvilke bruksområder kan du komme på?
@ -226,14 +227,14 @@ La oss gå gjennom en bidragsarbeidsflyt. Anta at bidragsyteren allerede har _fo
git switch [branch-name]
```
1. **Utfør arbeid**. På dette punktet vil du legge til endringene dine. Ikke glem å fortelle Git om det med følgende kommandoer:
1. **Utfør arbeid**. På dette tidspunktet vil du legge til endringene dine. Ikke glem å fortelle Git om det med følgende kommandoer:
```bash
git add .
git commit -m "my changes"
```
Sørg for å gi committen din et godt navn, både for din egen skyld og for vedlikeholderen av repoet du hjelper til med.
Sørg for å gi commit-en din et godt navn, for din egen skyld så vel som for vedlikeholderen av repoet du hjelper til med.
1. **Kombiner arbeidet ditt med `main`-grenen**. På et tidspunkt er du ferdig med arbeidet, og du vil kombinere arbeidet ditt med det som er i `main`-grenen. `main`-grenen kan ha endret seg i mellomtiden, så sørg for at du først oppdaterer den til den nyeste med følgende kommandoer:
@ -242,14 +243,19 @@ La oss gå gjennom en bidragsarbeidsflyt. Anta at bidragsyteren allerede har _fo
git pull
```
På dette punktet vil du sørge for at eventuelle _konflikter_, situasjoner der Git ikke enkelt kan _kombinere_ endringene, skjer i arbeidsgrenen din. Derfor kjør følgende kommandoer:
På dette tidspunktet vil du sørge for at eventuelle _konflikter_, situasjoner der Git ikke enkelt kan _kombinere_ endringene, skjer i arbeidsgrenen din. Derfor kjør følgende kommandoer:
```bash
git switch [branch_name]
git merge main
```
Dette vil hente inn alle endringer fra `main` til grenen din, og forhåpentligvis kan du bare fortsette. Hvis ikke, vil VS Code fortelle deg hvor Git er _forvirret_, og du endrer de berørte filene for å si hvilket innhold som er mest nøyaktig.
Kommandoen `git merge main` vil bringe inn alle endringer fra `main` til grenen din. Forhåpentligvis kan du bare fortsette. Hvis ikke, vil VS Code fortelle deg hvor Git er _forvirret_, og du endrer de berørte filene for å si hvilket innhold som er mest nøyaktig.
For å bytte til en annen gren, bruk den moderne kommandoen `git switch`:
```bash
git switch [branch_name]
1. **Send arbeidet ditt til GitHub**. Å sende arbeidet ditt til GitHub betyr to ting. Å pushe grenen din til repoet ditt og deretter åpne en PR, Pull Request.
@ -258,40 +264,40 @@ La oss gå gjennom en bidragsarbeidsflyt. Anta at bidragsyteren allerede har _fo
```
Kommandoen ovenfor oppretter grenen på ditt forkede repo.
1. **Åpne en PR**. Neste steg er å åpne en PR. Du gjør dette ved å navigere til den forkede repoen på GitHub. Du vil se en indikasjon på GitHub som spør om du vil opprette en ny PR. Klikk på den, og du blir tatt til et grensesnitt hvor du kan endre commit-meldingens tittel og gi en mer passende beskrivelse. Nå vil vedlikeholderen av repoen du forked se denne PR-en, og _krysser fingrene_ de vil sette pris på og _merge_ PR-en din. Du er nå en bidragsyter, yay :)
1. **Åpne en PR**. Deretter vil du åpne en PR. Du gjør det ved å navigere til det forkede repoet på GitHub. Du vil se en indikasjon på GitHub der det spør om du vil opprette en ny PR, du klikker på det, og du blir tatt til et grensesnitt der du kan endre commit-meldingens tittel, gi den en mer passende beskrivelse. Nå vil vedlikeholderen av repoet du forked se denne PR-en, og _fingers crossed_ de vil sette pris på og _slå sammen_ PR-en din. Du er nå en bidragsyter, yay :)
1. **Rydd opp**. Det anses som god praksis å _rydde opp_ etter at du har lykkes med å slå sammen en PR. Du vil rydde opp både den lokale grenen din og grenen du pushet til GitHub. Først, la oss slette den lokalt med følgende kommando:
1. **Rydd opp**. Det anses som god praksis å _rydde opp_ etter at du har fått en PR merget. Du bør rydde opp både i din lokale branch og i branchen du har pushet til GitHub. Først, la oss slette den lokalt med følgende kommando:
```bash
git branch -d [branch-name]
```
Sørg for at du går til GitHub-siden for det forkede repoet og fjerner den eksterne grenen du nettopp pushet til det.
`Pull request` kan virke som et rart begrep, fordi du egentlig ønsker å "pushe" endringene dine til prosjektet. Men vedlikeholderen (prosjekteieren) eller kjerneteamet må vurdere endringene dine før de blir slått sammen med prosjektets "main"-gren, så du ber egentlig om en beslutning om endringen fra en vedlikeholder.
Sørg for å gå til GitHub-siden for den forkede repoen og fjern den eksterne branchen du nettopp pushet til.
`Pull request` kan virke som et rart begrep, fordi du egentlig ønsker å pushe endringene dine til prosjektet. Men vedlikeholderen (prosjekteieren) eller kjerneteamet må vurdere endringene dine før de merges med prosjektets "main"-branch, så du ber egentlig om en beslutning om endringen fra en vedlikeholder.
En pull request er stedet hvor man kan sammenligne og diskutere forskjellene som er introdusert på en gren, med anmeldelser, kommentarer, integrerte tester og mer. En god pull request følger omtrent de samme reglene som en commit-melding. Du kan legge til en referanse til en sak i sakssporingen, for eksempel når arbeidet ditt løser en sak. Dette gjøres ved å bruke `#` etterfulgt av nummeret på saken din. For eksempel `#97`.
En pull request er stedet hvor man kan sammenligne og diskutere forskjellene som er introdusert på en branch, med anmeldelser, kommentarer, integrerte tester og mer. En god pull request følger omtrent de samme reglene som en commit-melding. Du kan legge til en referanse til et issue i issue tracker, for eksempel når arbeidet ditt løser et problem. Dette gjøres ved å bruke `#` etterfulgt av nummeret på ditt issue. For eksempel `#97`.
🤞Krysser fingrene for at alle sjekker går gjennom og at prosjekteieren(e) slår sammen endringene dine med prosjektet🤞
🤞Krysser fingrene for at alle sjekker går gjennom og at prosjekteieren(e) merger endringene dine inn i prosjektet🤞
Oppdater din nåværende lokale arbeidsgren med alle nye commits fra den tilsvarende eksterne grenen på GitHub:
Oppdater din nåværende lokale arbeidsbranch med alle nye commits fra den tilsvarende eksterne branchen på GitHub:
`git pull`
## Hvordan bidra til open source
Først, finn et repository (eller **repo**) på GitHub som interesserer deg og som du ønsker å bidra med en endring til. Du vil kopiere innholdet til din maskin.
Først, la oss finne et repository (eller **repo**) på GitHub som interesserer deg og som du ønsker å bidra med en endring til. Du vil kopiere innholdet til din maskin.
✅ En god måte å finne 'nybegynnervennlige' repos er å [søke etter taggen 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ En god måte å finne 'nybegynnervennlige' repoer på er å [søke etter taggen 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Det finnes flere måter å kopiere kode på. En måte er å "klone" innholdet i repositoryet, ved å bruke HTTPS, SSH eller GitHub CLI (Command Line Interface).
Det finnes flere måter å kopiere kode på. En måte er å "klone" innholdet i repoen, ved å bruke HTTPS, SSH eller GitHub CLI (Command Line Interface).
Åpne terminalen din og klon repositoryet slik:
Åpne terminalen din og klon repoen slik:
`git clone https://github.com/ProjectURL`
For å jobbe med prosjektet, bytt til riktig mappe:
For å jobbe med prosjektet, gå til riktig mappe:
`cd ProjectURL`
Du kan også åpne hele prosjektet ved å bruke [Codespaces](https://github.com/features/codespaces), GitHubs innebygde kodeeditor / skyutviklingsmiljø, eller [GitHub Desktop](https://desktop.github.com/).
@ -300,19 +306,19 @@ Til slutt kan du laste ned koden i en zip-mappe.
### Noen flere interessante ting om GitHub
Du kan stjerne, følge og/eller "forke" ethvert offentlig repository på GitHub. Du finner dine stjernemerkede repositories i rullegardinmenyen øverst til høyre. Det er som å bokmerke, men for kode.
Du kan stjerne, følge og/eller "forke" enhver offentlig repo på GitHub. Du finner dine stjernemerkede repoer i rullegardinmenyen øverst til høyre. Det er som å bokmerke, men for kode.
Prosjekter har en sakssporing, som oftest på GitHub under "Issues"-fanen med mindre annet er angitt, hvor folk diskuterer problemer relatert til prosjektet. Og Pull Requests-fanen er der folk diskuterer og vurderer endringer som er underveis.
Prosjekter har en issue tracker, som oftest på GitHub under "Issues"-fanen med mindre annet er angitt, hvor folk diskuterer problemer relatert til prosjektet. Og Pull Requests-fanen er der folk diskuterer og vurderer endringer som er under arbeid.
Prosjekter kan også ha diskusjoner i forum, e-postlister eller chattekanaler som Slack, Discord eller IRC.
✅ Ta en titt rundt i ditt nye GitHub-repo og prøv noen ting, som å redigere innstillinger, legge til informasjon i repoet ditt, og opprette et prosjekt (som et Kanban-brett). Det er mye du kan gjøre!
✅ Ta en titt rundt i din nye GitHub-repo og prøv noen ting, som å redigere innstillinger, legge til informasjon i repoen din, og opprette et prosjekt (som et Kanban-brett). Det er mye du kan gjøre!
---
## 🚀 Utfordring
Samarbeid med en venn for å jobbe med hverandres kode. Lag et prosjekt sammen, fork kode, opprett grener og slå sammen endringer.
Samarbeid med en venn for å jobbe på hverandres kode. Opprett et prosjekt sammen, fork kode, opprett branches, og merge endringer.
## Quiz etter forelesning
[Quiz etter forelesning](https://ff-quizzes.netlify.app/web/en/)
@ -336,4 +342,4 @@ Fullfør [kurset Første uke på GitHub](https://skills.github.com/#first-week-o
---
**Ansvarsfraskrivelse**:
Dette dokumentet er oversatt ved hjelp av AI-oversettelsestjenesten [Co-op Translator](https://github.com/Azure/co-op-translator). Selv om vi streber etter nøyaktighet, vær oppmerksom på at automatiske oversettelser kan inneholde feil eller unøyaktigheter. Det originale dokumentet på sitt opprinnelige språk bør anses som den autoritative kilden. For kritisk informasjon anbefales profesjonell menneskelig oversettelse. Vi er ikke ansvarlige for misforståelser eller feiltolkninger som oppstår ved bruk av denne oversettelsen.
Dette dokumentet er oversatt ved hjelp av AI-oversettelsestjenesten [Co-op Translator](https://github.com/Azure/co-op-translator). Selv om vi tilstreber nøyaktighet, vennligst vær oppmerksom på at automatiserte oversettelser kan inneholde feil eller unøyaktigheter. Det originale dokumentet på sitt opprinnelige språk bør betraktes som den autoritative kilden. For kritisk informasjon anbefales profesjonell menneskelig oversettelse. Vi er ikke ansvarlige for eventuelle misforståelser eller feiltolkninger som oppstår ved bruk av denne oversettelsen.
Ta lekcja obejmuje podstawy GitHub, platformy do hostowania i zarządzania zmianami w kodzie.
> Sketchnote autorstwa [Tomomi Imura](https://twitter.com/girlie_mac)
## Quiz przed lekcją
@ -21,7 +21,7 @@ Ta lekcja obejmuje podstawy GitHub, platformy do hostowania i zarządzania zmian
W tej lekcji omówimy:
- śledzenie pracy wykonywanej na Twoim komputerze
- śledzenie pracy na Twoim komputerze
- pracę nad projektami z innymi
- jak przyczyniać się do rozwoju oprogramowania open source
@ -37,27 +37,27 @@ Jeśli Git nie jest zainstalowany, [pobierz Git](https://git-scm.com/downloads).
Aby sprawdzić, czy Git jest już skonfigurowany, możesz wpisać:
`git config --list`
Będziesz także potrzebować konta na GitHub, edytora kodu (np. Visual Studio Code) oraz otwartego terminala (lub wiersza poleceń).
Będziesz także potrzebować konta GitHub, edytora kodu (np. Visual Studio Code) oraz otwartego terminala (lub wiersza poleceń).
Przejdź na [github.com](https://github.com/) i załóż konto, jeśli jeszcze go nie masz, lub zaloguj się i uzupełnij swój profil.
✅ GitHub nie jest jedynym repozytorium kodu na świecie; są inne, ale GitHub jest najbardziej znany.
✅ GitHub nie jest jedynym repozytorium kodu na świecie; istnieją inne, ale GitHub jest najbardziej znany.
### Przygotowanie
Będziesz potrzebować folderu z projektem kodu na swoim lokalnym komputerze (laptopie lub PC) oraz publicznego repozytorium na GitHub, które posłuży jako przykład, jak przyczyniać się do projektów innych osób.
Będziesz potrzebować zarówno folderu z projektem kodu na swoim lokalnym komputerze (laptopie lub PC), jak i publicznego repozytorium na GitHub, które posłuży jako przykład, jak przyczyniać się do projektów innych osób.
---
## Zarządzanie kodem
Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzić swoje postępy za pomocą git - systemu kontroli wersji. Niektórzy porównują używanie git do pisania listu miłosnego do siebie w przyszłości. Czytając swoje wiadomości commit po dniach, tygodniach czy miesiącach, będziesz w stanie przypomnieć sobie, dlaczego podjąłeś daną decyzję lub "cofnąć" zmianę - pod warunkiem, że piszesz dobre wiadomości commit.
Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzić swoje postępy za pomocą git - systemu kontroli wersji. Niektórzy porównują używanie git do pisania listu miłosnego do swojego przyszłego "ja". Czytając swoje wiadomości commit po dniach, tygodniach czy miesiącach, będziesz w stanie przypomnieć sobie, dlaczego podjąłeś daną decyzję, lub "cofnąć" zmianę - pod warunkiem, że piszesz dobre wiadomości commit.
### Zadanie: Utwórz repozytorium i zatwierdź kod
> Obejrzyj wideo
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Utwórz repozytorium na GitHub**. Na GitHub.com, w zakładce repozytoriów lub z paska nawigacyjnego w prawym górnym rogu, znajdź przycisk **new repo**.
@ -102,7 +102,7 @@ Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzi
git add .
```
Argument `git add` plus `.`oznacza, że wszystkie Twoje pliki i zmiany zostaną dodane do śledzenia.
Argument `git add` plus `.`wskazuje, że wszystkie Twoje pliki i zmiany są gotowe do śledzenia.
1. **Dodaj wybrane pliki do śledzenia**
@ -128,15 +128,15 @@ Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzi
To polecenie pozwala cofnąć etapowanie tylko konkretnego pliku, którego nie chcesz uwzględniać w następnym zatwierdzeniu.
1. **Utrwal swoją pracę**. Na tym etapie dodałeś pliki do tzw. _obszaru etapowania_. Miejsca, w którym Git śledzi Twoje pliki. Aby zmiana była trwała, musisz _zatwierdzić_ pliki. Aby to zrobić, tworzysz _commit_ za pomocą polecenia `git commit`. _Commit_ reprezentuje punkt zapisu w historii Twojego repozytorium. Wpisz następujące polecenie, aby utworzyć _commit_:
1. **Utrwal swoją pracę**. Na tym etapie dodałeś pliki do tzw. _obszaru etapowania_. Miejsca, w którym Git śledzi Twoje pliki. Aby zmiana była trwała, musisz _zatwierdzić_ pliki. Aby to zrobić, tworzysz _commit_ za pomocą polecenia `git commit`. _Commit_ reprezentuje punkt zapisu w historii Twojego repozytorium. Wpisz poniższe polecenie, aby utworzyć _commit_:
```bash
git commit -m "first commit"
```
To zatwierdza wszystkie Twoje pliki, dodając wiadomość "first commit". W przyszłych wiadomościach commit warto być bardziej opisowym, aby przekazać, jakiego rodzaju zmiany zostały dokonane.
To zatwierdza wszystkie Twoje pliki, dodając wiadomość "first commit". W przyszłych wiadomościach commit warto być bardziej opisowym, aby przekazać, jaki rodzaj zmiany został dokonany.
1. **Połącz swoje lokalne repozytorium Git z GitHub**. Repozytorium Git na Twoim komputerze jest przydatne, ale w pewnym momencie będziesz chciał mieć kopię zapasową swoich plików gdzieś indziej i zaprosić innych do pracy nad swoim repozytorium. Jednym z takich miejsc jest GitHub. Pamiętaj, że już utworzyliśmy repozytorium na GitHub, więc jedyne, co musimy zrobić, to połączyć nasze lokalne repozytorium Git z GitHub. Polecenie `git remote add` właśnie to zrobi. Wpisz następujące polecenie:
1. **Połącz lokalne repozytorium Git z GitHub**. Repozytorium Git na Twoim komputerze jest przydatne, ale w pewnym momencie będziesz chciał mieć kopię zapasową swoich plików gdzieś indziej i zaprosić innych do pracy nad swoim repozytorium. Jednym z takich miejsc jest GitHub. Pamiętaj, że już utworzyliśmy repozytorium na GitHub, więc jedyne, co musimy zrobić, to połączyć lokalne repozytorium Git z GitHub. Polecenie `git remote add` właśnie to zrobi. Wpisz poniższe polecenie:
> Uwaga, zanim wpiszesz polecenie, przejdź na stronę swojego repozytorium GitHub, aby znaleźć URL repozytorium. Użyjesz go w poniższym poleceniu. Zastąp ```https://github.com/username/repository_name.git``` swoim URL GitHub.
@ -146,17 +146,17 @@ Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzi
To tworzy _remote_, czyli połączenie, nazwane "origin", wskazujące na repozytorium GitHub, które utworzyłeś wcześniej.
1. **Wyślij lokalne pliki na GitHub**. Do tej pory utworzyłeś _połączenie_ między lokalnym repozytorium a repozytorium GitHub. Wyślij te pliki na GitHub za pomocą następującego polecenia `git push`, jak poniżej:
1. **Wyślij lokalne pliki na GitHub**. Do tej pory utworzyłeś _połączenie_ między lokalnym repozytorium a repozytorium GitHub. Wyślij te pliki na GitHub za pomocą poniższego polecenia `git push`:
> Uwaga, nazwa Twojej gałęzi może być domyślnie inna niż ```main```.
```bash
git push -u origin main
```
To wysyła Twoje zatwierdzenia w gałęzi "main" na GitHub.
To wysyła Twoje commity w gałęzi "main" na GitHub. Ustawienie gałęzi `upstream`, w tym `-u` w poleceniu, tworzy link między lokalną gałęzią a gałęzią zdalną, dzięki czemu możesz po prostu używać git push lub git pull bez określania nazwy gałęzi w przyszłości. Git automatycznie użyje gałęzi upstream i nie będziesz musiał jawnie określać nazwy gałęzi w przyszłych poleceniach.
2. **Dodawanie kolejnych zmian**. Jeśli chcesz kontynuować wprowadzanie zmian i wysyłanie ich na GitHub, wystarczy użyć następujących trzech poleceń:
2. **Dodawanie kolejnych zmian**. Jeśli chcesz kontynuować wprowadzanie zmian i wysyłanie ich na GitHub, wystarczy użyć poniższych trzech poleceń:
```bash
git add .
@ -164,12 +164,12 @@ Załóżmy, że masz lokalnie folder z projektem kodu i chcesz zacząć śledzi
git push
```
> Wskazówka, możesz również rozważyć użycie pliku `.gitignore`, aby zapobiec śledzeniu plików, których nie chcesz umieszczać na GitHub - na przykład pliku z notatkami, który przechowujesz w tym samym folderze, ale nie powinien znaleźć się w publicznym repozytorium. Możesz znaleźć szablony plików `.gitignore` na stronie [.gitignore templates](https://github.com/github/gitignore).
> Wskazówka, możesz również rozważyć użycie pliku `.gitignore`, aby zapobiec śledzeniu plików, których nie chcesz umieszczać na GitHub - na przykład pliku z notatkami, który przechowujesz w tym samym folderze, ale nie ma miejsca w publicznym repozytorium. Możesz znaleźć szablony plików `.gitignore` na stronie [.gitignore templates](https://github.com/github/gitignore).
#### Wiadomości commit
Świetna wiadomość commit w linii tematu powinna kończyć następujące zdanie:
Jeśli zostanie zastosowana, ten commit <tuwpiszswojąliniętematu>
Jeśli zastosowane, ten commit <Twojaliniatematututaj>
W temacie używaj trybu rozkazującego, czasu teraźniejszego: "zmień" zamiast "zmieniono" czy "zmienia".
Podobnie w treści (opcjonalnej) używaj trybu rozkazującego, czasu teraźniejszego. Treść powinna zawierać motywację dla zmiany i kontrastować ją z wcześniejszym zachowaniem. Wyjaśniasz `dlaczego`, a nie `jak`.
@ -178,24 +178,25 @@ Podobnie w treści (opcjonalnej) używaj trybu rozkazującego, czasu teraźniejs
### Zadanie: Współpraca
Głównym powodem umieszczania rzeczy na GitHub było umożliwienie współpracy z innymi programistami.
Głównym powodem umieszczania rzeczy na GitHub było umożliwienie współpracy z innymi deweloperami.
## Praca nad projektami z innymi
> Obejrzyj wideo
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
W swoim repozytorium przejdź do `Insights > Community`, aby zobaczyć, jak Twój projekt wypada w porównaniu do zalecanych standardów społeczności.
W swoim repozytorium przejdź do `Insights > Community`, aby zobaczyć, jak Twój projekt wypada w porównaniu z zalecanymi standardami społeczności.
Oto kilka rzeczy, które mogą poprawić Twoje repozytorium GitHub:
- **Opis**. Czy dodałeś opis swojego projektu?
- **README**. Czy dodałeś README? GitHub oferuje wskazówki dotyczące pisania [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Wytyczne dotyczące współpracy**. Czy Twój projekt ma [wytyczne dotyczące współpracy](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kodeks postępowania**. Czy dodałeś [Kodeks postępowania](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licencja**. Być może najważniejsze, czy dodałeś [licencję](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Licencja**. Być może najważniejsze, [licencja](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Wszystkie te zasoby będą korzystne dla nowych członków zespołu. Są to zazwyczaj rzeczy, na które nowi współpracownicy zwracają uwagę, zanim jeszcze spojrzą na Twój kod, aby dowiedzieć się, czy Twój projekt jest odpowiednim miejscem, w którym warto spędzać czas.
Wszystkie te zasoby będą korzystne dla onboardingu nowych członków zespołu. Są to zazwyczaj rzeczy, na które nowi współpracownicy zwracają uwagę, zanim jeszcze spojrzą na Twój kod, aby dowiedzieć się, czy Twój projekt jest odpowiednim miejscem, w którym warto spędzać czas.
✅ Pliki README, choć wymagają czasu na przygotowanie, są często zaniedbywane przez zajętych opiekunów. Czy możesz znaleźć przykład szczególnie opisowego README? Uwaga: istnieją [narzędzia pomagające tworzyć dobre README](https://www.makeareadme.com/), które możesz wypróbować.
@ -204,13 +205,13 @@ Wszystkie te zasoby będą korzystne dla nowych członków zespołu. Są to zazw
Dokumenty dotyczące współpracy pomagają ludziom przyczyniać się do projektu. Wyjaśniają, jakiego rodzaju wkładu szukasz i jak działa proces. Współpracownicy będą musieli przejść przez szereg kroków, aby móc przyczynić się do Twojego repozytorium na GitHub:
1. **Forkowanie Twojego repozytorium**. Prawdopodobnie będziesz chciał, aby ludzie _forkowali_ Twój projekt. Forkowanie oznacza utworzenie repliki Twojego repozytorium na ich profilu GitHub.
1. **Klonowanie**. Następnie sklonują projekt na swój lokalny komputer.
1. **Utworzenie gałęzi**. Poproś ich o utworzenie _gałęzi_ dla swojej pracy.
1. **Skupienie się na jednej zmianie**. Poproś współpracowników, aby skoncentrowali swoje zmiany na jednej rzeczy naraz - w ten sposób szanse na to, że będziesz mógł _scalić_ ich pracę, są większe. Wyobraź sobie, że naprawiają błąd, dodają nową funkcję i aktualizują kilka testów - co jeśli chcesz lub możesz zaimplementować tylko 2 z 3, albo 1 z 3 zmian?
1. **Klonowanie**. Następnie sklonują projekt na swój lokalny komputer.
1. **Utworzenie gałęzi**. Poproś ich o utworzenie _gałęzi_ dla swojej pracy.
1. **Skupienie się na jednej zmianie**. Poproś współpracowników, aby skoncentrowali swoje zmiany na jednej rzeczy naraz - w ten sposób szanse na to, że będziesz mógł _scalić_ ich pracę, są większe. Wyobraź sobie, że naprawiają błąd, dodają nową funkcję i aktualizują kilka testów - co jeśli chcesz lub możesz zaimplementować tylko 2 z 3, lub 1 z 3 zmian?
✅ Wyobraź sobie sytuację, w której gałęzie są szczególnie istotne dla pisania i dostarczania dobrego kodu. Jakie przypadki użycia przychodzą Ci na myśl?
> Uwaga, bądź zmianą, którą chcesz zobaczyć na świecie, i twórz gałęzie dla swojej własnej pracy. Każde zatwierdzenie, które wykonasz, będzie wykonane na gałęzi, na której obecnie się znajdujesz. Użyj `git status`, aby zobaczyć, na której gałęzi jesteś.
> Uwaga, bądź zmianą, którą chcesz zobaczyć na świecie, i twórz gałęzie dla swojej własnej pracy. Wszystkie commity, które wykonasz, będą wykonane na gałęzi, na której obecnie jesteś "zalogowany". Użyj `git status`, aby zobaczyć, na której gałęzi się znajdujesz.
Przejdźmy przez proces pracy współpracownika. Załóżmy, że współpracownik już _forkował_ i _sklonował_ repozytorium, więc ma gotowe repozytorium Git na swoim lokalnym komputerze:
@ -226,7 +227,7 @@ Przejdźmy przez proces pracy współpracownika. Załóżmy, że współpracowni
git switch [branch-name]
```
1. **Wykonaj pracę**. Na tym etapie chcesz wprowadzić swoje zmiany. Nie zapomnij poinformować o tym Git za pomocą następujących poleceń:
1. **Wykonaj pracę**. Na tym etapie chcesz dodać swoje zmiany. Nie zapomnij poinformować o tym Git za pomocą poniższych poleceń:
```bash
git add .
@ -235,21 +236,26 @@ Przejdźmy przez proces pracy współpracownika. Załóżmy, że współpracowni
Upewnij się, że nadajesz swojemu commitowi dobrą nazwę, zarówno dla siebie, jak i dla opiekuna repozytorium, któremu pomagasz.
1. **Połącz swoją pracę z gałęzią `main`**. W pewnym momencie kończysz pracę i chcesz połączyć ją z gałęzią `main`. Gałąź `main` mogła się zmienić w międzyczasie, więc upewnij się, że najpierw ją zaktualizujesz do najnowszej wersji za pomocą następujących poleceń:
1. **Połącz swoją pracę z gałęzią `main`**. W pewnym momencie kończysz pracę i chcesz połączyć ją z gałęzią `main`. Gałąź `main` mogła się zmienić w międzyczasie, więc upewnij się, że najpierw ją zaktualizujesz za pomocą poniższych poleceń:
```bash
git switch main
git pull
```
Na tym etapie chcesz upewnić się, że wszelkie _konflikty_, sytuacje, w których Git nie może łatwo _połączyć_ zmian, występują w Twojej gałęzi roboczej. Dlatego uruchom następujące polecenia:
Na tym etapie chcesz upewnić się, że wszelkie _konflikty_, sytuacje, w których Git nie może łatwo _połączyć_ zmian, występują w Twojej gałęzi roboczej. Dlatego uruchom poniższe polecenia:
```bash
git switch [branch_name]
git merge main
```
To wprowadzi wszystkie zmiany z `main` do Twojej gałęzi i miejmy nadzieję, że możesz po prostu kontynuować. Jeśli nie, VS Code wskaże, gdzie Git jest _zdezorientowany_, a Ty po prostu zmienisz odpowiednie pliki, aby określić, która zawartość jest najbardziej dokładna.
Polecenie `git merge main` wprowadzi wszystkie zmiany z `main` do Twojej gałęzi. Miejmy nadzieję, że możesz po prostu kontynuować. Jeśli nie, VS Code wskaże, gdzie Git jest _zdezorientowany_, a Ty po prostu zmienisz odpowiednie pliki, aby wskazać, która zawartość jest najbardziej dokładna.
Aby przełączyć się na inną gałąź, użyj nowoczesnego polecenia `git switch`:
```bash
git switch [branch_name]
1. **Wyślij swoją pracę na GitHub**. Wysłanie swojej pracy na GitHub oznacza dwie rzeczy. Wypchnięcie swojej gałęzi do repozytorium i otwarcie PR, Pull Request.
@ -258,29 +264,29 @@ Przejdźmy przez proces pracy współpracownika. Załóżmy, że współpracowni
```
Powyższe polecenie tworzy gałąź w Twoim repozytorium forkowanym.
1. **Otwórz PR**. Następnie chcesz otworzyć PR. Robisz to, przechodząc do sforkowanego repozytorium na GitHub. Zobaczysz na GitHubie wskazówkę, która pyta, czy chcesz utworzyć nowy PR. Klikasz to i zostajesz przeniesiony do interfejsu, w którym możesz zmienić tytuł wiadomości commit, nadać jej bardziej odpowiedni opis. Teraz właściciel repozytorium, które sforkowałeś, zobaczy ten PR i _trzymamy kciuki_, że doceni go i _scali_ Twój PR. Jesteś teraz współtwórcą, hurra :)
1. **Otwórz PR**. Następnie chcesz otworzyć PR. Robisz to, przechodząc do forkowanego repozytorium na GitHub. Zobaczysz wskazówkę na GitHub, gdzie pyta, czy chcesz utworzyć nowy PR, kliknij to, a zostaniesz przeniesiony do interfejsu, w którym możesz zmienić tytuł wiadomości commit, nadać jej bardziej odpowiedni opis. Teraz opiekun repozytorium, które forkowałeś, zobaczy ten PR i _trzymaj kciuki_, doceni go i _scali_ Twój PR. Jesteś teraz współpracownikiem, hurra :)
1. **Posprzątaj**. Uważa się za dobrą praktykę _posprzątanie_ po pomyślnym scaleniu PR. Chcesz usunąć zarówno lokalną gałąź, jak i gałąź, którą wypchnąłeś na GitHub. Najpierw usuń ją lokalnie za pomocą następującego polecenia:
1. **Posprzątaj**. Uważa się za dobrą praktykę _posprzątanie_ po pomyślnym scaleniu PR. Chcesz posprzątać zarówno swoją lokalną gałąź, jak i gałąź, którą wypchnąłeś na GitHub. Najpierw usuń ją lokalnie za pomocą następującego polecenia:
```bash
git branch -d [branch-name]
```
Upewnij się, że przechodzisz na stronę GitHub dla forkowanego repozytorium i usuwasz zdalną gałąź, którą właśnie tam wypchnąłeś.
`Pull request` wydaje się być dziwnym określeniem, ponieważ tak naprawdę chcesz "wypchnąć" swoje zmiany do projektu. Jednak osoba odpowiedzialna za projekt (właściciel projektu) lub główny zespół musi rozważyć Twoje zmiany przed ich połączeniem z "główną" gałęzią projektu, więc w rzeczywistości prosisz o decyzję dotyczącą zmiany od osoby zarządzającej projektem.
Następnie przejdź na stronę GitHub dla sforkowanego repozytorium i usuń zdalną gałąź, którą właśnie tam wypchnąłeś.
`Pull request` wydaje się być dziwnym terminem, ponieważ tak naprawdę chcesz wypchnąć swoje zmiany do projektu. Ale właściciel projektu lub główny zespół musi rozważyć Twoje zmiany przed scaleniem ich z "główną" gałęzią projektu, więc tak naprawdę prosisz o decyzję dotyczącą zmiany od właściciela projektu.
Pull request to miejsce, gdzie można porównać i omówić różnice wprowadzone w gałęzi, korzystając z recenzji, komentarzy, zintegrowanych testów i innych narzędzi. Dobry pull request przestrzega mniej więcej tych samych zasad co wiadomość commit. Możesz dodać odniesienie do problemu w trackerze problemów, na przykład gdy Twoja praca rozwiązuje jakiś problem. Robi się to za pomocą `#`, po którym następuje numer problemu. Na przykład `#97`.
Pull request to miejsce, w którym można porównać i omówić różnice wprowadzone w gałęzi, z recenzjami, komentarzami, zintegrowanymi testami i nie tylko. Dobry pull request przestrzega mniej więcej tych samych zasad co wiadomość commit. Możesz dodać odniesienie do problemu w trackerze problemów, na przykład gdy Twoja praca rozwiązuje jakiś problem. Robi się to za pomocą `#`, po którym następuje numer problemu. Na przykład `#97`.
🤞Trzymamy kciuki, że wszystkie testy przejdą pomyślnie i właściciel(e) projektu połączą Twoje zmiany z projektem🤞
🤞Trzymamy kciuki, że wszystkie testy przejdą pomyślnie i właściciel(e) projektu scalą Twoje zmiany z projektem🤞
Zaktualizuj swoją lokalną gałąź roboczą o wszystkie nowe commity z odpowiadającej jej zdalnej gałęzi na GitHubie:
Zaktualizuj swoją bieżącą lokalną gałąź roboczą o wszystkie nowe commity z odpowiadającej jej zdalnej gałęzi na GitHub:
`git pull`
## Jak przyczynić się do rozwoju open source
Najpierw znajdź repozytorium (lub **repo**) na GitHubie, które Cię interesuje i do którego chciałbyś wnieść zmiany. Będziesz chciał skopiować jego zawartość na swój komputer.
Najpierw znajdź repozytorium (lub **repo**) na GitHub, które Cię interesuje i do którego chciałbyś wprowadzić zmiany. Chcesz skopiować jego zawartość na swój komputer.
✅ Dobrym sposobem na znalezienie repozytoriów przyjaznych dla początkujących jest [wyszukiwanie według tagu 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
@ -288,31 +294,31 @@ Najpierw znajdź repozytorium (lub **repo**) na GitHubie, które Cię interesuje
Istnieje kilka sposobów kopiowania kodu. Jednym z nich jest "klonowanie" zawartości repozytorium za pomocą HTTPS, SSH lub GitHub CLI (Command Line Interface).
Otwórz terminal i sklonuj repozytorium w następujący sposób:
Otwórz terminal i sklonuj repozytorium w ten sposób:
`git clone https://github.com/ProjectURL`
Aby pracować nad projektem, przejdź do odpowiedniego folderu:
`cd ProjectURL`
Możesz również otworzyć cały projekt za pomocą [Codespaces](https://github.com/features/codespaces), wbudowanego edytora kodu / środowiska programistycznego w chmurze od GitHuba, lub [GitHub Desktop](https://desktop.github.com/).
Możesz również otworzyć cały projekt za pomocą [Codespaces](https://github.com/features/codespaces), wbudowanego edytora kodu / środowiska programistycznego w chmurze GitHub, lub [GitHub Desktop](https://desktop.github.com/).
Na koniec możesz pobrać kod w formie spakowanego folderu.
Na koniec możesz pobrać kod w spakowanym folderze.
### Kilka ciekawych rzeczy o GitHubie
### Kilka ciekawych rzeczy o GitHub
Możesz oznaczyć gwiazdką, obserwować lub "forkować" dowolne publiczne repozytorium na GitHubie. Swoje oznaczone gwiazdką repozytoria znajdziesz w menu rozwijanym w prawym górnym rogu. To jak zakładki, ale dla kodu.
Możesz oznaczyć gwiazdką, obserwować i/lub "sforkować" każde publiczne repozytorium na GitHub. Znajdziesz swoje oznaczone gwiazdką repozytoria w menu rozwijanym w prawym górnym rogu. To jak zakładki, ale dla kodu.
Projekty mają tracker problemów, zazwyczaj na GitHubie w zakładce "Issues", chyba że wskazano inaczej, gdzie ludzie omawiają problemy związane z projektem. Zakładka Pull Requests to miejsce, gdzie ludzie omawiają i recenzują zmiany, które są w trakcie realizacji.
Projekty mają tracker problemów, najczęściej na GitHub w zakładce "Issues", chyba że wskazano inaczej, gdzie ludzie omawiają problemy związane z projektem. Zakładka Pull Requests to miejsce, gdzie ludzie omawiają i recenzują zmiany, które są w toku.
Projekty mogą również mieć dyskusje na forach, listach mailingowych lub kanałach czatu, takich jak Slack, Discord czy IRC.
✅ Rozejrzyj się po swoim nowym repozytorium na GitHubie i spróbuj kilku rzeczy, takich jak edytowanie ustawień, dodawanie informacji do repozytorium i tworzenie projektu (np. tablicy Kanban). Możesz zrobić naprawdę wiele!
✅ Rozejrzyj się po swoim nowym repozytorium na GitHub i spróbuj kilku rzeczy, takich jak edytowanie ustawień, dodawanie informacji do repozytorium i tworzenie projektu (np. tablicy Kanban). Możesz zrobić naprawdę wiele!
---
## 🚀 Wyzwanie
Połącz siły z przyjacielem, aby pracować nad kodem nawzajem. Stwórzcie wspólnie projekt, forkowanie kodu, tworzenie gałęzi i łączenie zmian.
Połącz siły z przyjacielem, aby pracować nad kodem nawzajem. Stwórzcie wspólnie projekt, sforkujcie kod, utwórzcie gałęzie i scalcie zmiany.
## Quiz po wykładzie
[Quiz po wykładzie](https://ff-quizzes.netlify.app/web/en/)
@ -325,13 +331,13 @@ Przeczytaj więcej o [przyczynianiu się do rozwoju oprogramowania open source](
Ćwicz, ćwicz, ćwicz. GitHub oferuje świetne ścieżki edukacyjne dostępne na [skills.github.com](https://skills.github.com):
- [Pierwszy tydzień na GitHubie](https://skills.github.com/#first-week-on-github)
- [Pierwszy tydzień na GitHub](https://skills.github.com/#first-week-on-github)
Znajdziesz tam również bardziej zaawansowane kursy.
## Zadanie
Ukończ [kurs Pierwszy tydzień na GitHubie](https://skills.github.com/#first-week-on-github)
Ukończ kurs [Pierwszy tydzień na GitHub](https://skills.github.com/#first-week-on-github)
Antes de começar, verifique se o Git está instalado. No terminal, escreva:
Antes de começar, verifique se o Git está instalado. No terminal, digite:
`git --version`
Se o Git não estiver instalado, [faça o download do Git](https://git-scm.com/downloads). Depois, configure o seu perfil local do Git no terminal:
* `git config --global user.name "seu-nome"`
* `git config --global user.email "seu-email"`
Para verificar se o Git já está configurado, pode escrever:
Para verificar se o Git já está configurado, pode digitar:
`git config --list`
Também precisará de uma conta no GitHub, um editor de código (como o Visual Studio Code) e de abrir o seu terminal (ou: prompt de comando).
Também precisará de uma conta no GitHub, um editor de código (como o Visual Studio Code) e de abrir o seu terminal (ou prompt de comando).
Aceda a [github.com](https://github.com/) e crie uma conta, se ainda não tiver uma, ou inicie sessão e preencha o seu perfil.
Acesse [github.com](https://github.com/) e crie uma conta, caso ainda não tenha uma, ou faça login e preencha o seu perfil.
✅ O GitHub não é o único repositório de código no mundo; existem outros, mas o GitHub é o mais conhecido.
@ -49,34 +49,34 @@ Vai precisar de uma pasta com um projeto de código na sua máquina local (port
---
## Gestão de Código
## Gestão de código
Vamos supor que tem uma pasta localmente com um projeto de código e quer começar a acompanhar o seu progresso usando o Git - o sistema de controlo de versões. Algumas pessoas comparam o uso do Git a escrever uma carta de amor para o seu "eu" do futuro. Ao ler as mensagens de commit dias, semanas ou meses depois, será capaz de recordar por que tomou uma decisão ou "reverter" uma alteração - isto é, quando escreve boas mensagens de commit.
Imagine que tem uma pasta local com um projeto de código e quer começar a acompanhar o seu progresso usando o Git - o sistema de controlo de versões. Algumas pessoas comparam usar o Git a escrever uma carta de amor para o seu "eu" futuro. Ao ler as mensagens de commit dias, semanas ou meses depois, será capaz de recordar por que tomou uma decisão ou "reverter" uma alteração - isto é, quando escreve boas "mensagens de commit".
### Tarefa: Criar um repositório e fazer commit do código
### Tarefa: Criar um repositório e fazer commit de código
> Veja o vídeo
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Criar um repositório no GitHub**. No GitHub.com, no separador de repositórios ou na barra de navegação no canto superior direito, encontre o botão **novo repositório**.
1. **Criar um repositório no GitHub**. No GitHub.com, na aba de repositórios ou na barra de navegação no canto superior direito, encontre o botão **novo repositório**.
1. Dê um nome ao seu repositório (pasta).
1. Selecione **criar repositório**.
1. **Navegar até à sua pasta de trabalho**. No terminal, mude para a pasta (também conhecida como diretório) que deseja começar a acompanhar. Escreva:
1. **Navegar até à sua pasta de trabalho**. No terminal, mude para a pasta (também conhecida como diretório) que deseja começar a acompanhar. Digite:
```bash
cd [name of your folder]
```
1. **Inicializar um repositório Git**. No seu projeto, escreva:
1. **Inicializar um repositório Git**. No seu projeto, digite:
```bash
git init
```
1. **Verificar o estado**. Para verificar o estado do seu repositório, escreva:
1. **Verificar o estado**. Para verificar o estado do seu repositório, digite:
```bash
git status
@ -93,10 +93,10 @@ Vamos supor que tem uma pasta localmente com um projeto de código e quer começ
modified: file2.txt
```
Normalmente, o comando `git status` informa sobre quais ficheiros estão prontos para serem _guardados_ no repositório ou têm alterações que talvez queira persistir.
Normalmente, o comando `git status` informa coisas como quais ficheiros estão prontos para serem _salvos_ no repositório ou têm alterações que talvez queira persistir.
1. **Adicionar todos os ficheiros para acompanhamento**
Isto também é chamado de preparar ficheiros/adicionar ficheiros à área de staging.
1. **Adicionar todos os ficheiros para acompanhamento**
Isto também é chamado de "staging files" ou adicionar ficheiros à área de staging.
```bash
git add .
@ -110,7 +110,7 @@ Vamos supor que tem uma pasta localmente com um projeto de código e quer começ
git add [file or folder name]
```
Isto permite adicionar apenas ficheiros selecionados à área de staging quando não quer fazer commit de todos os ficheiros de uma vez.
Isto ajuda a adicionar apenas ficheiros selecionados à área de staging quando não quer fazer commit de todos os ficheiros de uma vez.
1. **Remover todos os ficheiros da área de staging**
@ -118,7 +118,7 @@ Vamos supor que tem uma pasta localmente com um projeto de código e quer começ
git reset
```
Este comando permite remover todos os ficheiros da área de staging de uma vez.
Este comando ajuda a remover todos os ficheiros da área de staging de uma vez.
1. **Remover um ficheiro específico da área de staging**
@ -126,37 +126,37 @@ Vamos supor que tem uma pasta localmente com um projeto de código e quer começ
git reset [file or folder name]
```
Este comando permite remover apenas um ficheiro específico da área de staging que não quer incluir no próximo commit.
Este comando ajuda a remover apenas um ficheiro específico da área de staging que não quer incluir no próximo commit.
1. **Persistir o seu trabalho**. Neste ponto, adicionou os ficheiros a uma chamada _área de staging_. Um local onde o Git acompanha os seus ficheiros. Para tornar a alteração permanente, precisa de fazer um _commit_ dos ficheiros. Para isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto de salvaguarda na história do seu repositório. Escreva o seguinte para criar um _commit_:
1. **Persistir o seu trabalho**. Neste ponto, já adicionou os ficheiros a uma área chamada _staging area_. Um local onde o Git está a acompanhar os seus ficheiros. Para tornar a alteração permanente, precisa de _fazer commit_ dos ficheiros. Para isso, crie um _commit_ com o comando `git commit`. Um _commit_ representa um ponto de salvamento na história do seu repositório. Digite o seguinte para criar um _commit_:
```bash
git commit -m "first commit"
```
Isto faz o commit de todos os seus ficheiros, adicionando a mensagem "primeiro commit". Para mensagens de commit futuras, será mais útil ser mais descritivo na sua descrição para transmitir o tipo de alteração que fez.
Isto faz commit de todos os seus ficheiros, adicionando a mensagem "primeiro commit". Para mensagens de commit futuras, será melhor ser mais descritivo na sua descrição para transmitir que tipo de alteração fez.
1. **Conectar o seu repositório Git local ao GitHub**. Um repositório Git é útil na sua máquina, mas em algum momento vai querer ter um backup dos seus ficheiros em algum lugar e também convidar outras pessoas a trabalhar consigo no repositório. Um ótimo lugar para isso é o GitHub. Lembre-se de que já criámos um repositório no GitHub, então só precisamos de conectar o repositório Git local ao GitHub. O comando `git remote add` faz exatamente isso. Escreva o seguinte comando:
1. **Conectar o seu repositório Git local ao GitHub**. Um repositório Git é útil na sua máquina, mas em algum momento vai querer ter um backup dos seus ficheiros noutro lugar e também convidar outras pessoas para trabalhar consigo no repositório. Um ótimo lugar para isso é o GitHub. Lembre-se de que já criámos um repositório no GitHub, então só precisamos de conectar o repositório Git local ao GitHub. O comando `git remote add` fará isso. Digite o seguinte comando:
> Nota: antes de escrever o comando, vá à página do repositório no GitHub para encontrar o URL do repositório. Vai usá-lo no comando abaixo. Substitua ```https://github.com/username/repository_name.git``` pelo URL do seu GitHub.
> Nota: Antes de digitar o comando, vá à página do seu repositório no GitHub para encontrar o URL do repositório. Vai usá-lo no comando abaixo. Substitua ```https://github.com/username/repository_name.git``` pelo URL do seu GitHub.
Isto cria uma _remota_, ou conexão, chamada "origin", apontando para o repositório GitHub que criou anteriormente.
Isto cria um_remote_, ou conexão, chamado "origin", apontando para o repositório GitHub que criou anteriormente.
1. **Enviar ficheiros locais para o GitHub**. Até agora, criou uma _conexão_ entre o repositório local e o repositório GitHub. Vamos enviar estes ficheiros para o GitHub com o seguinte comando `git push`, assim:
> Nota: o nome da sua branch pode ser diferente por padrão de ```main```.
> Nota: O nome da sua branch pode ser diferente por padrão de ```main```.
```bash
git push -u origin main
```
Isto envia os seus commits na branch "main" para o GitHub.
Isto envia os seus commits na branch "main" para o GitHub. Definir a branch `upstream`, incluindo `-u` no comando, estabelece um link entre a sua branch local e a branch remota, para que possa simplesmente usar git push ou git pull sem especificar o nome da branch no futuro. O Git usará automaticamente a branch upstream e não precisará de especificar o nome da branch explicitamente em comandos futuros.
2. **Para adicionar mais alterações**. Se quiser continuar a fazer alterações e enviá-las para o GitHub, só precisará de usar os seguintes três comandos:
2. **Adicionar mais alterações**. Se quiser continuar a fazer alterações e enviá-las para o GitHub, só precisará de usar os seguintes três comandos:
```bash
git add .
@ -164,55 +164,55 @@ Vamos supor que tem uma pasta localmente com um projeto de código e quer começ
git push
```
> Dica: também pode querer adotar um ficheiro `.gitignore` para evitar que ficheiros que não quer acompanhar apareçam no GitHub - como aquele ficheiro de notas que guarda na mesma pasta, mas que não tem lugar num repositório público. Pode encontrar modelos para ficheiros `.gitignore` em [.gitignore templates](https://github.com/github/gitignore).
> Dica: Também pode querer adotar um ficheiro `.gitignore` para evitar que ficheiros que não quer acompanhar apareçam no GitHub - como aquele ficheiro de notas que guarda na mesma pasta, mas que não tem lugar num repositório público. Pode encontrar modelos para ficheiros `.gitignore` em [.gitignore templates](https://github.com/github/gitignore).
#### Mensagens de Commit
#### Mensagens de commit
Uma ótima linha de assunto para um commit Git completa a seguinte frase:
Se aplicada, esta alteração irá <aquiasualinhadeassunto>
Uma ótima linha de assunto para um commit do Git completa a seguinte frase:
Se aplicado, este commit irá <aquiasualinhadeassunto>
Para o assunto, use o imperativo no presente: "alterar" em vez de "alterado" ou "altera".
Tal como no assunto, no corpo (opcional) também use o imperativo no presente. O corpo deve incluir a motivação para a alteração e contrastar isso com o comportamento anterior. Está a explicar o `porquê`, não o `como`.
Tal como no assunto, no corpo (opcional) também use o imperativo no presente. O corpo deve incluir a motivação para a alteração e contrastá-la com o comportamento anterior. Está a explicar o `porquê`, não o `como`.
✅ Dedique alguns minutos a explorar o GitHub. Consegue encontrar uma mensagem de commit realmente boa? E uma muito minimalista? Que informações acha que são mais importantes e úteis de transmitir numa mensagem de commit?
✅ Dedique alguns minutos a explorar o GitHub. Consegue encontrar uma mensagem de commit realmente boa? Consegue encontrar uma muito minimalista? Que informações acha que são mais importantes e úteis de transmitir numa mensagem de commit?
### Tarefa: Colaborar
A principal razão para colocar coisas no GitHub foi tornar possível colaborar com outros programadores.
## Trabalhar em Projetos com Outros
## Trabalhar em projetos com outras pessoas
> Veja o vídeo
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
No seu repositório, navegue até `Insights > Community` para ver como o seu projeto se compara aos padrões recomendados da comunidade.
No seu repositório, navegue até `Insights > Community` para ver como o seu projeto se compara aos padrões recomendados para a comunidade.
Aqui estão algumas coisas que podem melhorar o seu repositório GitHub:
- **Descrição**. Adicionou uma descrição ao seu projeto?
- **README**. Adicionou um README? O GitHub fornece orientações para escrever um [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Diretrizes de Contribuição**. O seu projeto tem [diretrizes de contribuição](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Código de Conduta**. Um [Código de Conduta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licença**. Talvez o mais importante, uma [licença](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Aqui estão algumas coisas que podem melhorar o seu repositório GitHub:
- **Descrição**. Adicionou uma descrição ao seu projeto?
- **README**. Adicionou um README? O GitHub fornece orientações para escrever um [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Diretrizes de contribuição**. O seu projeto tem [diretrizes de contribuição](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Código de Conduta**. Um [Código de Conduta](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Licença**. Talvez o mais importante, uma [licença](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Todos estes recursos beneficiarão a integração de novos membros na equipa. E são tipicamente o tipo de coisas que novos contribuidores analisam antes mesmo de olhar para o seu código, para descobrir se o seu projeto é o lugar certo para eles investirem o seu tempo.
Todos estes recursos beneficiarão a integração de novos membros da equipa. E são tipicamente o tipo de coisas que novos contribuidores olham antes mesmo de ver o seu código, para descobrir se o seu projeto é o lugar certo para eles dedicarem o seu tempo.
✅ Ficheiros README, embora levem tempo a preparar, são frequentemente negligenciados por mantenedores ocupados. Consegue encontrar um exemplo de um particularmente descritivo? Nota: existem algumas [ferramentas para ajudar a criar bons READMEs](https://www.makeareadme.com/) que pode querer experimentar.
### Tarefa: Fazer Merge de Código
### Tarefa: Fazer merge de algum código
Documentos de contribuição ajudam as pessoas a contribuir para o projeto. Explicam que tipos de contribuições está a procurar e como funciona o processo. Os contribuidores precisarão de passar por uma série de passos para poderem contribuir para o seu repositório no GitHub:
Documentos de contribuição ajudam as pessoas a contribuir para o projeto. Explicam que tipos de contribuições está a procurar e como funciona o processo. Os contribuidores precisarão de passar por uma série de etapas para poderem contribuir para o seu repositório no GitHub:
1. **Fazer fork do seu repositório**. Provavelmente vai querer que as pessoas façam _fork_ do seu projeto. Fazer fork significa criar uma réplica do seu repositório no perfil GitHub delas.
1. **Clonar**. A partir daí, elas irão clonar o projeto para a máquina local.
1. **Fazer fork do seu repositório**. Provavelmente vai querer que as pessoas _façam fork_ do seu projeto. Fazer fork significa criar uma réplica do seu repositório no perfil GitHub delas.
1. **Clonar**. A partir daí, vão clonar o projeto para a máquina local delas.
1. **Criar uma branch**. Vai querer pedir-lhes que criem uma _branch_ para o trabalho delas.
1. **Focar a alteração numa área**. Peça aos contribuidores para concentrarem as contribuições numa coisa de cada vez - assim, as hipóteses de conseguir fazer _merge_ do trabalho deles são maiores. Imagine que escrevem uma correção de bug, adicionam uma nova funcionalidade e atualizam vários testes - e se quiser ou puder implementar apenas 2 de 3, ou 1 de 3 alterações?
1. **Focar a alteração numa área**. Peça aos contribuidores para concentrarem as contribuições deles numa coisa de cada vez - assim, as chances de conseguir _fazer merge_ do trabalho deles são maiores. Imagine que escrevem uma correção de bug, adicionam uma nova funcionalidade e atualizam vários testes - e se quiser implementar apenas 2 de 3 ou 1 de 3 alterações?
✅ Imagine uma situação em que as branches são particularmente críticas para escrever e enviar bom código. Que casos de uso consegue imaginar?
> Nota: seja a mudança que quer ver no mundo e crie branches para o seu próprio trabalho também. Quaisquer commits que fizer serão feitos na branch em que está atualmente "checkout". Use `git status` para ver em que branch está.
> Nota: Seja a mudança que quer ver no mundo e crie branches para o seu próprio trabalho também. Qualquer commit que fizer será feito na branch em que está atualmente "checkout". Use `git status` para ver em que branch está.
Vamos passar por um fluxo de trabalho de contribuidor. Suponha que o contribuidor já fez _fork_ e _clone_ do repositório, então tem um repositório Git pronto para trabalhar na máquina local:
Vamos passar por um fluxo de trabalho de contribuidores. Assuma que o contribuidor já fez _fork_ e _clone_ do repositório, então tem um repositório Git pronto para trabalhar na máquina local:
1. **Criar uma branch**. Use o comando `git branch` para criar uma branch que conterá as alterações que pretende contribuir:
@ -226,53 +226,58 @@ Vamos passar por um fluxo de trabalho de contribuidor. Suponha que o contribuido
git switch [branch-name]
```
1. **Fazer o trabalho**. Neste ponto, adicione as suas alterações. Não se esqueça de informar o Git com os seguintes comandos:
1. **Fazer alterações**. Neste ponto, quer adicionar as suas alterações. Não se esqueça de informar o Git com os seguintes comandos:
```bash
git add .
git commit -m "my changes"
```
Certifique-se de dar um bom nome ao commit, tanto para si como para o mantenedor do repositório que está a ajudar.
Certifique-se de dar um bom nome ao seu commit, para seu benefício e para o mantenedor do repositório que está a ajudar.
1. **Combinar o seu trabalho com a branch `main`**. Em algum momento, termina o trabalho e quer combiná-lo com o da branch `main`. A branch `main` pode ter mudado entretanto, então certifique-se de primeiro atualizá-la para a versão mais recente com os seguintes comandos:
1. **Combinar o seu trabalho com a branch `main`**. Em algum momento, termina o trabalho e quer combinar o seu trabalho com o da branch `main`. A branch `main` pode ter mudado entretanto, então certifique-se de primeiro atualizá-la para a versão mais recente com os seguintes comandos:
```bash
git switch main
git pull
```
Neste ponto, certifique-se de que quaisquer _conflitos_, situações em que o Git não consegue facilmente _combinar_ as alterações, acontecem na sua branch de trabalho. Portanto, execute os seguintes comandos:
Neste ponto, quer garantir que quaisquer _conflitos_, situações em que o Git não consegue facilmente _combinar_ as alterações, aconteçam na sua branch de trabalho. Portanto, execute os seguintes comandos:
```bash
git switch [branch_name]
git merge main
```
Isto trará todas as alterações da `main` para a sua branch e, com sorte, poderá continuar. Se não, o VS Code indicará onde o Git está _confuso_ e só precisa de alterar os ficheiros afetados para indicar qual conteúdo é mais preciso.
O comando `git merge main` trará todas as alterações da `main` para a sua branch. Esperemos que possa simplesmente continuar. Caso contrário, o VS Code dirá onde o Git está _confuso_ e só precisa de alterar os ficheiros afetados para indicar qual conteúdo é o mais preciso.
Para mudar para uma branch diferente, use o comando moderno `git switch`:
```bash
git switch [branch_name]
1. **Enviar o seu trabalho para o GitHub**. Enviar o seu trabalho para o GitHub significa duas coisas: enviar a sua branch para o seu repositório e depois abrir um PR (Pull Request).
1. **Enviar o seu trabalho para o GitHub**. Enviar o seu trabalho para o GitHub significa duas coisas: enviar a sua branch para o seu repositório e depois abrir um PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
O comando acima cria a branch no seu repositório de fork.
1. **Abrir um PR**. De seguida, quer abrir um PR. Faça isso navegando até ao repositório de fork no GitHub. Verá uma indicação no GitHub a perguntar se quer criar um novo PR; clique nisso e será levado para uma interface onde pode alterar o título da mensagem de commit e dar-lhe uma descrição mais adequada. Agora, o mantenedor do repositório que fez fork verá este PR e, _dedos cruzados_, apreciará e fará _merge_ do seu PR. Agora é um contribuidor, yay :)
O comando acima cria a branch no seu repositório com fork.
1. **Abrir um PR**. O próximo passo é abrir um PR. Para isso, navegue até o repositório que foi bifurcado no GitHub. No GitHub, verá uma indicação perguntando se deseja criar um novo PR. Clique nessa opção e será levado para uma interface onde pode alterar o título da mensagem de commit e adicionar uma descrição mais adequada. Agora, o mantenedor do repositório que bifurcou verá este PR e, _dedos cruzados_, irá apreciar e _fazer merge_ do seu PR. Parabéns, agora é um colaborador, yay :)
1. **Limpar**. É considerado boa prática _limpar_ depois de um PR ser fundido com sucesso. Quer limpar tanto a sua branch local como a branch que enviou para o GitHub. Primeiro, elimine-a localmente com o seguinte comando:
1. **Limpar**. É considerado uma boa prática _limpar_ depois de conseguir fazer merge de um PR. Deve limpar tanto a sua branch local como a branch que enviou para o GitHub. Primeiro, vamos eliminá-la localmente com o seguinte comando:
```bash
git branch -d [branch-name]
```
Certifique-se de ir à página do GitHub do repositório bifurcado e remover a branch remota que acabou de enviar.
Certifique-se de ir à página do repositório de fork no GitHub e remover a branch remota que acabou de enviar.
`Pull request` parece um termo estranho porque, na verdade, o que você quer é enviar as suas alterações para o projeto. No entanto, o responsável pelo projeto (o proprietário) ou a equipa principal precisa avaliar as suas alterações antes de as integrar na branch "main" do projeto. Portanto, você está, na verdade, a solicitar uma decisão de alteração ao responsável.
`Pull request` parece um termo estranho porque, na verdade, quer enviar as suas alterações para o projeto. Mas o mantenedor (proprietário do projeto) ou a equipa principal precisa considerar as suas alterações antes de fazer merge com a branch "main" do projeto. Portanto, está realmente a solicitar uma decisão de alteração ao mantenedor.
Um pull request é o local onde se comparam e discutem as diferenças introduzidas numa branch, com revisões, comentários, testes integrados e mais. Um bom pull request segue aproximadamente as mesmas regras de uma mensagem de commit. Pode adicionar uma referência a um problema no rastreador de problemas, por exemplo, quando o seu trabalho resolve um problema. Isto é feito utilizando um `#` seguido do número do problema. Por exemplo, `#97`.
Um pull request é o local onde se comparam e discutem as diferenças introduzidas numa branch, com revisões, comentários, testes integrados e mais. Um bom pull request segue aproximadamente as mesmas regras de uma mensagem de commit. Pode adicionar uma referência a um problema no rastreador de problemas, por exemplo, quando o seu trabalho resolve um problema. Isto é feito usando um `#` seguido do número do problema. Por exemplo, `#97`.
🤞Dedos cruzados para que todos os testes sejam aprovados e o(s) proprietário(s) do projeto integrem as suas alterações no projeto🤞
🤞Dedos cruzados para que todos os testes passem e o(s) proprietário(s) do projeto façam merge das suas alterações no projeto🤞
Atualize a sua branch local de trabalho com todos os novos commits da branch remota correspondente no GitHub:
@ -280,27 +285,27 @@ Atualize a sua branch local de trabalho com todos os novos commits da branch rem
## Como contribuir para open source
Primeiro, vamos encontrar um repositório (ou **repo**) no GitHub que seja do seu interesse e ao qual gostaria de contribuir com uma alteração. Vai querer copiar o conteúdo para a sua máquina.
Primeiro, vamos encontrar um repositório (ou **repo**) no GitHub que seja do seu interesse e ao qual gostaria de contribuir com uma alteração. Deve copiar o conteúdo para a sua máquina.
✅ Uma boa forma de encontrar repositórios 'amigáveis para iniciantes' é [procurar pela tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Existem várias formas de copiar código. Uma delas é "clonar" o conteúdo do repositório, utilizando HTTPS, SSH ou a CLI (Interface de Linha de Comando) do GitHub.
Existem várias formas de copiar código. Uma delas é "clonar" o conteúdo do repositório, usando HTTPS, SSH ou o GitHub CLI (Interface de Linha de Comando).
Abra o seu terminal e clone o repositório desta forma:
Abra o terminal e clone o repositório assim:
`git clone https://github.com/ProjectURL`
Para trabalhar no projeto, mude para a pasta correta:
Para trabalhar no projeto, mude para a pasta correta:
`cd ProjectURL`
Também pode abrir o projeto inteiro utilizando [Codespaces](https://github.com/features/codespaces), o editor de código integrado / ambiente de desenvolvimento na nuvem do GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Também pode abrir o projeto inteiro usando [Codespaces](https://github.com/features/codespaces), o editor de código integrado / ambiente de desenvolvimento na nuvem do GitHub, ou [GitHub Desktop](https://desktop.github.com/).
Por fim, pode descarregar o código numa pasta comprimida.
Por fim, pode fazer o download do código num ficheiro zipado.
### Algumas coisas interessantes sobre o GitHub
Pode marcar com estrela, seguir e/ou "forkar" qualquer repositório público no GitHub. Pode encontrar os seus repositórios marcados com estrela no menu suspenso no canto superior direito. É como guardar nos favoritos, mas para código.
Pode marcar com estrela, seguir e/ou "bifurcar" qualquer repositório público no GitHub. Pode encontrar os seus repositórios marcados com estrela no menu suspenso no canto superior direito. É como guardar nos favoritos, mas para código.
Os projetos têm um rastreador de problemas, geralmente no GitHub na aba "Issues", salvo indicação em contrário, onde as pessoas discutem problemas relacionados ao projeto. E a aba Pull Requests é onde as pessoas discutem e revisam alterações que estão em progresso.
@ -312,16 +317,16 @@ Os projetos também podem ter discussões em fóruns, listas de e-mails ou canai
## 🚀 Desafio
Trabalhe em parceria com um amigo para colaborar no código um do outro. Crie um projeto colaborativo, faça fork do código, crie branches e integre alterações.
Trabalhe em parceria com um amigo no código um do outro. Criem um projeto colaborativo, bifurquem o código, criem branches e façam merge das alterações.
Leia mais sobre [como contribuir para software open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Guia rápido de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
[Cheatsheet de Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Pratique, pratique, pratique. O GitHub tem ótimos percursos de aprendizagem disponíveis em [skills.github.com](https://skills.github.com):
@ -331,9 +336,9 @@ Também encontrará cursos mais avançados.
## Tarefa
Complete [o curso Primeira Semana no GitHub](https://skills.github.com/#first-week-on-github)
Complete o curso [Primeira Semana no GitHub](https://skills.github.com/#first-week-on-github)
---
**Aviso Legal**:
Este documento foi traduzido utilizando o serviço de tradução por IA [Co-op Translator](https://github.com/Azure/co-op-translator). Embora nos esforcemos para garantir a precisão, é importante notar que traduções automáticas podem conter erros ou imprecisões. O documento original na sua língua nativa deve ser considerado a fonte autoritária. Para informações críticas, recomenda-se a tradução profissional realizada por humanos. Não nos responsabilizamos por quaisquer mal-entendidos ou interpretações incorretas decorrentes da utilização desta tradução.
**Aviso**:
Este documento foi traduzido utilizando o serviço de tradução por IA [Co-op Translator](https://github.com/Azure/co-op-translator). Embora nos esforcemos pela precisão, é importante notar que traduções automáticas podem conter erros ou imprecisões. O documento original na sua língua nativa deve ser considerado a fonte autoritária. Para informações críticas, recomenda-se uma tradução profissional realizada por humanos. Não nos responsabilizamos por quaisquer mal-entendidos ou interpretações incorretas decorrentes do uso desta tradução.
@ -19,7 +19,7 @@ Această lecție acoperă elementele de bază ale GitHub, o platformă pentru g
## Introducere
În această lecție, vom acoperi:
În această lecție vom acoperi:
- urmărirea muncii pe care o faci pe mașina ta
- lucrul la proiecte împreună cu alții
@ -27,7 +27,7 @@ Această lecție acoperă elementele de bază ale GitHub, o platformă pentru g
### Cerințe preliminare
Înainte de a începe, trebuie să verifici dacă Git este instalat. În terminal, tastează:
Înainte de a începe, trebuie să verifici dacă Git este instalat. În terminal, tastează:
`git --version`
Dacă Git nu este instalat, [descarcă Git](https://git-scm.com/downloads). Apoi, configurează profilul local Git în terminal:
@ -39,13 +39,13 @@ Pentru a verifica dacă Git este deja configurat, poți tasta:
De asemenea, vei avea nevoie de un cont GitHub, un editor de cod (cum ar fi Visual Studio Code) și trebuie să deschizi terminalul (sau: command prompt).
Accesează [github.com](https://github.com/) și creează un cont dacă nu ai deja unul, sau conectează-te și completează profilul tău.
Accesează [github.com](https://github.com/) și creează un cont dacă nu ai deja unul, sau autentifică-te și completează profilul tău.
✅ GitHub nu este singurul depozit de cod din lume; există și altele, dar GitHub este cel mai cunoscut.
### Pregătire
Vei avea nevoie de un folder cu un proiect de cod pe mașina ta locală (laptop sau PC) și de un depozit public pe GitHub, care va servi ca exemplu pentru cum să contribui la proiectele altora.
Vei avea nevoie de un folder cu un proiect de cod pe mașina ta locală (laptop sau PC) și de un depozit public pe GitHub, care va servi ca exemplu pentru cum să contribui la proiectele altora.
---
@ -59,9 +59,10 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Creează un depozit pe GitHub**. Pe GitHub.com, în fila depozite sau din bara de navigare din dreapta sus, găsește butonul **new repo**.
1. Dă un nume depozitului tău (folderului).
1. Dă un nume depozitului tău (folderului)
1. Selectează **create repository**.
1. **Navighează la folderul tău de lucru**. În terminal, schimbă directorul la folderul pe care vrei să începi să îl urmărești. Tastează:
@ -70,13 +71,13 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
cd [name of your folder]
```
1. **Inițializează un depozit git**. În proiectul tău, tastează:
1. **Inițializează un depozit git**. În proiectul tău tastează:
```bash
git init
```
1. **Verifică statusul**. Pentru a verifica statusul depozitului, tastează:
1. **Verifică statusul**. Pentru a verifica statusul depozitului tău tastează:
```bash
git status
@ -95,14 +96,14 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
De obicei, comanda `git status` îți spune lucruri precum ce fișiere sunt gata să fie _salvate_ în depozit sau ce fișiere au modificări pe care poate vrei să le persiști.
1. **Adaugă toate fișierele pentru urmărire**
Acest proces este numit și "staging files"/adăugarea fișierelor în zona de staging.
1. **Adaugă toate fișierele pentru urmărire**
Acest proces este numit și etapizarea fișierelor/adăugarea fișierelor în zona de etapizare.
```bash
git add .
```
Argumentul `git add` plus `.` indică faptul că toate fișierele și modificările sunt pregătite pentru urmărire.
Argumentul `git add` plus `.` indică faptul că toate fișierele și modificările tale sunt pregătite pentru urmărire.
1. **Adaugă fișiere selectate pentru urmărire**
@ -110,35 +111,35 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
git add [file or folder name]
```
Acest lucru ne ajută să adăugăm doar fișierele selectate în zona de staging atunci când nu vrem să comitem toate fișierele deodată.
Acest lucru ne ajută să adăugăm doar fișierele selectate în zona de etapizare atunci când nu vrem să comitem toate fișierele deodată.
1. **Elimină toate fișierele din staging**
1. **De-etapizează toate fișierele**
```bash
git reset
```
Această comandă ne ajută să eliminăm toate fișierele din staging deodată.
Această comandă ne ajută să de-etapizăm toate fișierele deodată.
1. **Elimină un fișier specific din staging**
1. **De-etapizează un fișier specific**
```bash
git reset [file or folder name]
```
Această comandă ne ajută să eliminăm doar un fișier specific din staging pe care nu vrem să îl includem în următorul commit.
Această comandă ne ajută să de-etapizăm doar un fișier specific deodată pe care nu vrem să îl includem în următorul commit.
1. **Persistă munca ta**. În acest punct, ai adăugat fișierele într-o zonă numită _staging area_. Un loc unde Git urmărește fișierele tale. Pentru a face modificarea permanentă, trebuie să _comitezi_ fișierele. Pentru a face acest lucru, creezi un _commit_ cu comanda `git commit`. Un _commit_ reprezintă un punct de salvare în istoria depozitului tău. Tastează următoarele pentru a crea un _commit_:
1. **Persistă munca ta**. În acest punct ai adăugat fișierele într-o așa-numită _zonă de etapizare_. Un loc unde Git îți urmărește fișierele. Pentru a face modificarea permanentă, trebuie să _comitezi_ fișierele. Pentru a face acest lucru, creezi un _commit_ cu comanda `git commit`. Un _commit_ reprezintă un punct de salvare în istoricul depozitului tău. Tastează următoarele pentru a crea un _commit_:
```bash
git commit -m "first commit"
```
Acest lucru comite toate fișierele tale, adăugând mesajul "first commit". Pentru mesajele de commit viitoare, vei dori să fii mai descriptiv pentru a transmite ce tip de modificare ai făcut.
Acest lucru comite toate fișierele tale, adăugând mesajul "first commit". Pentru mesajele de commit viitoare, vei dori să fii mai descriptiv în descrierea ta pentru a transmite ce tip de modificare ai făcut.
1. **Conectează depozitul local Git cu GitHub**. Un depozit Git este util pe mașina ta, dar la un moment dat vei dori să ai un backup al fișierelor undeva și să inviți alte persoane să lucreze cu tine pe depozit. Un loc excelent pentru asta este GitHub. Am creat deja un depozit pe GitHub, așa că singurul lucru pe care trebuie să îl facem este să conectăm depozitul local Git cu GitHub. Comanda `git remote add` va face exact asta. Tastează următoarea comandă:
1. **Conectează depozitul local Git cu GitHub**. Un depozit Git este util pe mașina ta, dar la un moment dat vei dori să ai un backup al fișierelor tale undeva și să inviți și alte persoane să lucreze cu tine pe depozitul tău. Un astfel de loc grozav este GitHub. Amintește-ți că am creat deja un depozit pe GitHub, așa că singurul lucru pe care trebuie să îl facem este să conectăm depozitul local Git cu GitHub. Comanda `git remote add` va face exact acest lucru. Tastează următoarea comandă:
> Notă, înainte de a tasta comanda, accesează pagina depozitului GitHub pentru a găsi URL-ul depozitului. Vei folosi acest URL în comanda de mai jos. Înlocuiește ```https://github.com/username/repository_name.git``` cu URL-ul GitHub.
> Notă, înainte de a tasta comanda, accesează pagina depozitului tău GitHub pentru a găsi URL-ul depozitului. Îl vei folosi în comanda de mai jos. Înlocuiește ```https://github.com/username/repository_name.git``` cu URL-ul GitHub al tău.
@ -146,17 +147,17 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
Aceasta creează o _remote_, sau conexiune, numită "origin", care indică spre depozitul GitHub pe care l-ai creat anterior.
1. **Trimite fișierele locale pe GitHub**. Până acum ai creat o _conexiune_ între depozitul local și depozitul GitHub. Să trimitem aceste fișiere pe GitHub cu următoarea comandă `git push`, astfel:
> Notă, numele branch-ului tău poate fi diferit de ```main```.
1. **Trimite fișierele locale pe GitHub**. Până acum ai creat o _conexiune_ între depozitul local și depozitul GitHub. Să trimitem aceste fișiere pe GitHub cu următoarea comandă `git push`, astfel:
> Notă, numele ramurii tale poate fi diferit de cel implicit, ```main```.
```bash
git push -u origin main
```
Aceasta trimite commit-urile tale din branch-ul "main" pe GitHub.
Aceasta trimite commit-urile tale din ramura "main" pe GitHub. Setarea ramurii `upstream`, inclusiv `-u` în comandă, stabilește o legătură între ramura locală și ramura remote, astfel încât să poți folosi pur și simplu git push sau git pull fără a specifica numele ramurii în viitor. Git va folosi automat ramura upstream și nu va fi nevoie să specifici numele ramurii explicit în comenzile viitoare.
2. **Adaugă mai multe modificări**. Dacă vrei să continui să faci modificări și să le trimiți pe GitHub, va trebui doar să folosești următoarele trei comenzi:
2. **Pentru a adăuga mai multe modificări**. Dacă vrei să continui să faci modificări și să le trimiți pe GitHub, va trebui doar să folosești următoarele trei comenzi:
```bash
git add .
@ -164,14 +165,14 @@ Să presupunem că ai un folder local cu un proiect de cod și vrei să începi
git push
```
> Sfat, Poate vrei să adopți un fișier `.gitignore` pentru a preveni ca fișierele pe care nu vrei să le urmărești să apară pe GitHub - cum ar fi acel fișier de notițe pe care îl stochezi în același folder, dar care nu are loc într-un depozit public. Poți găsi șabloane pentru fișiere `.gitignore` la [.gitignore templates](https://github.com/github/gitignore).
> Sfaturi, Poate vei dori să adopți un fișier `.gitignore` pentru a preveni ca fișierele pe care nu vrei să le urmărești să apară pe GitHub - cum ar fi acel fișier de notițe pe care îl stochezi în același folder, dar care nu are loc într-un depozit public. Poți găsi șabloane pentru fișiere `.gitignore` la [.gitignore templates](https://github.com/github/gitignore).
#### Mesaje de commit
Un subiect grozav pentru un commit Git completează următoarea propoziție:
Un subiect grozav pentru un commit Git completează următoarea propoziție:
Dacă se aplică, acest commit va <subiectultăuaici>
Pentru subiect, folosește timpul prezent imperativ: "modifică" nu "modificat" sau "modificări".
Pentru subiect, folosește timpul prezent imperativ: "modifică" nu "modificat" sau "modificări".
La fel ca în subiect, în corpul mesajului (opțional) folosește timpul prezent imperativ. Corpul ar trebui să includă motivația pentru modificare și să contrasteze aceasta cu comportamentul anterior. Explici `de ce`, nu `cum`.
✅ Ia câteva minute pentru a naviga pe GitHub. Poți găsi un mesaj de commit cu adevărat grozav? Poți găsi unul foarte minimal? Ce informații crezi că sunt cele mai importante și utile de transmis într-un mesaj de commit?
@ -191,36 +192,38 @@ Principalul motiv pentru a pune lucruri pe GitHub a fost să faci posibilă cola
Iată câteva lucruri care pot îmbunătăți depozitul tău GitHub:
- **Descriere**. Ai adăugat o descriere pentru proiectul tău?
- **README**. Ai adăugat un README? GitHub oferă îndrumări pentru scrierea unui [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Ghid de contribuție**. Proiectul tău are [ghiduri de contribuție](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Cod de conduită**. Un [Cod de conduită](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/).
- **Ghid de contribuție**. Proiectul tău are [ghiduri de contribuție](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Cod de conduită**. Un [Cod de conduită](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licență**. Poate cel mai important, o [licență](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Toate aceste resurse vor ajuta la integrarea noilor membri ai echipei. Și acestea sunt, de obicei, lucrurile pe care noii contribuitori le analizează înainte de a se uita la codul tău, pentru a afla dacă proiectul tău este locul potrivit pentru a-și petrece timpul.
✅ Fișierele README, deși necesită timp pentru a fi pregătite, sunt adesea neglijate de mentori ocupați. Poți găsi un exemplu de README deosebit de descriptiv? Notă: există [instrumente pentru a ajuta la crearea de README-uri bune](https://www.makeareadme.com/) pe care s-ar putea să vrei să le încerci.
Toate aceste resurse vor fi benefice pentru integrarea noilor membri ai echipei. Și acestea sunt, de obicei, genul de lucruri pe care noii contribuitori le analizează înainte de a se uita la codul tău, pentru a afla dacă proiectul tău este locul potrivit pentru a-și petrece timpul.
### Sarcină: Combină codul
✅ Fișierele README, deși necesită timp pentru a fi pregătite, sunt adesea neglijate de către mentori ocupați. Poți găsi un exemplu de README deosebit de descriptiv? Notă: există unele [instrumente pentru a ajuta la crearea de README-uri bune](https://www.makeareadme.com/) pe care s-ar putea să vrei să le încerci.
### Sarcină: Combină niște cod
Documentele de contribuție ajută oamenii să contribuie la proiect. Ele explică ce tipuri de contribuții cauți și cum funcționează procesul. Contribuitorii vor trebui să parcurgă o serie de pași pentru a putea contribui la depozitul tău pe GitHub:
1. **Fork-ul depozitului tău**. Probabil vei dori ca oamenii să _fork-eze_ proiectul tău. Fork-ul înseamnă crearea unei replici a depozitului tău pe profilul lor GitHub.
1. **Clonează**. De acolo, vor clona proiectul pe mașina lor locală.
1. **Creează un branch**. Vei dori să le ceri să creeze un _branch_ pentru munca lor.
1. **Concentrează modificarea pe o singură zonă**. Cere contribuitorilor să își concentreze contribuțiile pe un singur lucru la un moment dat - astfel șansele ca tu să poți _combina_ munca lor sunt mai mari. Imaginează-ți că scriu o corecție de bug, adaugă o funcționalitate nouă și actualizează mai multe teste - ce se întâmplă dacă vrei sau poți implementa doar 2 din 3 sau 1 din 3 modificări?
✅ Imaginează-ți o situație în care branch-urile sunt deosebit de critice pentru scrierea și livrarea unui cod bun. Ce cazuri de utilizare îți vin în minte?
1. **Forking-ul depozitului tău** Probabil vei dori ca oamenii să _forkeze_ proiectul tău. Forking înseamnă crearea unei replici a depozitului tău pe profilul lor GitHub.
1. **Clonare**. De acolo, vor clona proiectul pe mașina lor locală.
1. **Crearea unei ramuri**. Vei dori să le ceri să creeze o _ramură_ pentru munca lor.
1. **Concentrarea modificării pe o singură zonă**. Cere contribuitorilor să își concentreze contribuțiile pe un singur lucru la un moment dat - astfel șansele ca tu să poți _combina_ munca lor sunt mai mari. Imaginează-ți că scriu o corecție de bug, adaugă o funcționalitate nouă și actualizează mai multe teste - ce se întâmplă dacă vrei sau poți implementa doar 2 din 3 sau 1 din 3 modificări?
✅ Imaginează-ți o situație în care ramurile sunt deosebit de critice pentru scrierea și livrarea unui cod bun. Ce cazuri de utilizare îți vin în minte?
> Notă, fii schimbarea pe care vrei să o vezi în lume și creează branch-uri pentru propria ta muncă. Orice commit-uri pe care le faci vor fi făcute pe branch-ul pe care ești în prezent "checked out". Folosește `git status` pentru a vedea pe ce branch te afli.
> Notă, fii schimbarea pe care vrei să o vezi în lume și creează ramuri pentru propria ta muncă. Orice commit-uri pe care le faci vor fi făcute pe ramura pe care ești în prezent "verificat". Folosește `git status` pentru a vedea pe ce ramură te afli.
Să parcurgem un flux de lucru al contribuitorului. Presupunem că contribuitorul a _fork-at_ și _clonat_ depozitul, astfel încât are un depozit Git gata de lucru pe mașina sa locală:
Să parcurgem un flux de lucru al contribuitorului. Presupunem că contribuitorul a _forkat_ și _clonat_ deja depozitul, astfel încât are un depozit Git gata de lucru pe mașina sa locală:
1. **Creează un branch**. Folosește comanda `git branch` pentru a crea un branch care va conține modificările pe care intenționează să le contribuie:
1. **Crearea unei ramuri**. Folosește comanda `git branch` pentru a crea o ramură care va conține modificările pe care intenționează să le contribuie:
```bash
git branch [branch-name]
```
1. **Schimbă-te pe branch-ul de lucru**. Schimbă-te pe branch-ul specificat și actualizează directorul de lucru cu `git switch`:
1. **Schimbă-te la ramura de lucru**. Schimbă-te la ramura specificată și actualizează directorul de lucru cu `git switch`:
```bash
git switch [branch-name]
@ -233,97 +236,101 @@ Să parcurgem un flux de lucru al contribuitorului. Presupunem că contribuitoru
git commit -m "my changes"
```
Asigură-te că dai commit-ului tău un nume bun, atât pentru tine, cât și pentru mentorul depozitului pe care îl ajuți.
Asigură-te că dai commit-ului tău un nume bun, pentru binele tău, precum și al mentorului depozitului pe care îl ajuți.
1. **Combină munca ta cu branch-ul `main`**. La un moment dat, ai terminat de lucrat și vrei să combini munca ta cu cea din branch-ul `main`. Branch-ul `main` s-ar putea să se fi schimbat între timp, așa că asigură-te că îl actualizezi mai întâi la cea mai recentă versiune cu următoarele comenzi:
1. **Combină munca ta cu ramura `main`**. La un moment dat, ai terminat de lucrat și vrei să combini munca ta cu cea din ramura `main`. Ramura `main` s-ar putea să se fi schimbat între timp, așa că asigură-te că o actualizezi mai întâi la cea mai recentă versiune cu următoarele comenzi:
```bash
git switch main
git pull
```
În acest punct, vrei să te asiguri că orice _conflicte_, situații în care Git nu poate _combina_ ușor modificările, apar în branch-ul tău de lucru. Prin urmare, rulează următoarele comenzi:
În acest punct, vrei să te asiguri că orice _conflicte_, situații în care Git nu poate _combina_ ușor modificările, apar în ramura ta de lucru. Prin urmare, rulează următoarele comenzi:
```bash
git switch [branch_name]
git merge main
```
Aceasta va aduce toate modificările din `main` în branch-ul tău și, sperăm, poți continua. Dacă nu, VS Code îți va spune unde Git este _confuz_ și doar modifici fișierele afectate pentru a indica ce conținut este cel mai precis.
Comanda `git merge main` va aduce toate modificările din `main` în ramura ta. Sperăm că poți continua fără probleme. Dacă nu, VS Code îți va spune unde Git este _confuz_ și doar modifici fișierele afectate pentru a indica ce conținut este cel mai precis.
1. **Trimite munca ta pe GitHub**. Trimiterea muncii tale pe GitHub înseamnă două lucruri. Pushing-ul branch-ului tău pe depozitul tău și apoi deschiderea unui PR, Pull Request.
Pentru a schimba la o altă ramură, folosește comanda modernă `git switch`:
```bash
git switch [branch_name]
1. **Trimite munca ta pe GitHub**. Trimiterea muncii tale pe GitHub înseamnă două lucruri. Împingerea ramurii tale în depozitul tău și apoi deschiderea unui PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Comanda de mai sus creează branch-ul pe depozitul tău fork-at.
1. **Deschide un PR**. Următorul pas este să deschizi un PR. Faci asta navigând la depozitul fork-at pe GitHub. Vei vedea o indicație pe GitHub unde te întreabă dacă vrei să creezi un nou PR, dai click pe asta și vei fi dus la o interfață unde poți schimba titlul mesajului de commit, să îi dai o descriere mai potrivită. Acum mentorul depozitului pe care l-ai fork-at va vedea acest PR și _sperăm_ că îl va aprecia și va _combina_ PR-ul tău. Acum ești un contribuitor, yay :)
Comanda de mai sus creează ramura în depozitul tău forkat.
1. **Deschide un PR**. Următorul pas este să deschizi un PR. Pentru asta, navighează la repo-ul bifurcat pe GitHub. Vei vedea o indicație pe GitHub care te întreabă dacă vrei să creezi un nou PR; dai clic pe aceasta și vei fi dus la o interfață unde poți modifica titlul mesajului de commit și să îi oferi o descriere mai potrivită. Acum, administratorul repo-ului pe care l-ai bifurcat va vedea acest PR și, _sperăm_, îl va aprecia și îl va _îmbina_ cu repo-ul principal. Felicitări, ești acum un contributor, yay :)
1. **Curăță**. Este considerat o practică bună să _curăți_ după ce ai combinat cu succes un PR. Vrei să cureți atât branch-ul local, cât și branch-ul pe care l-ai trimis pe GitHub. Mai întâi, să îl ștergem local cu următoarea comandă:
1. **Curățenie**. Este considerată o practică bună să faci _curățenie_ după ce ai reușit să îmbini un PR. Trebuie să cureți atât ramura locală, cât și ramura pe care ai împins-o pe GitHub. Mai întâi, șterge-o local cu următoarea comandă:
```bash
git branch -d [branch-name]
```
Asigură-te că accesezi pagina GitHub a repo-ului bifurcat și ștergi ramura remote pe care tocmai ai împins-o.
Asigură-te că accesezi pagina GitHub pentru depozitul fork-at și elimină branch-ul remote pe care tocmai l-ai trimis.
`Pull request` pare un termen ciudat, deoarece, în realitate, vrei să împingi modificările tale către proiect. Totuși, menținătorul (proprietarul proiectului) sau echipa de bază trebuie să analizeze modificările tale înainte de a le îmbina cu ramura "principală" a proiectului, așa că, de fapt, soliciți o decizie de modificare de la un menținător.
`Pull request` pare un termen ciudat, deoarece, în realitate, vrei să împingi modificările tale către proiect. Dar administratorul (proprietarul proiectului) sau echipa principală trebuie să ia în considerare modificările tale înainte de a le îmbina cu ramura "principală" a proiectului, așa că, de fapt, soliciți o decizie de modificare de la un administrator.
Un pull request este locul unde poți compara și discuta diferențele introduse pe o ramură, cu recenzii, comentarii, teste integrate și altele. Un pull request bun urmează, în mare parte, aceleași reguli ca un mesaj de commit. Poți adăuga o referință la o problemă din tracker-ul de probleme, de exemplu, atunci când munca ta rezolvă o problemă. Acest lucru se face folosind un `#` urmat de numărul problemei. De exemplu, `#97`.
Un pull request este locul unde poți compara și discuta diferențele introduse pe o ramură, cu recenzii, comentarii, teste integrate și altele. Un pull request bun urmează, în general, aceleași reguli ca un mesaj de commit. Poți adăuga o referință la o problemă din tracker-ul de probleme, de exemplu, atunci când munca ta rezolvă o problemă. Acest lucru se face folosind un `#` urmat de numărul problemei. De exemplu, `#97`.
🤞Sperăm că toate verificările trec și proprietarul/proprietarii proiectului îmbină modificările tale în proiect🤞
🤞Sperăm că toate verificările trec și proprietarul proiectului îmbină modificările tale în proiect🤞
Actualizează ramura ta locală curentă cu toate commit-urile noi din ramura corespunzătoare de pe GitHub:
Actualizează ramura locală curentă cu toate commit-urile noi din ramura corespunzătoare de pe GitHub:
`git pull`
## Cum să contribui la open source
Mai întâi, să găsim un depozit (sau **repo**) pe GitHub care te interesează și la care ai dori să contribui cu o modificare. Vei dori să copiezi conținutul acestuia pe mașina ta.
Mai întâi, să găsim un repository (sau **repo**) pe GitHub care te interesează și la care ai dori să contribui cu o modificare. Va trebui să copiezi conținutul acestuia pe mașina ta.
✅ O modalitate bună de a găsi repo-uri 'prietenoase pentru începători' este să [cauți după eticheta 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Există mai multe modalități de a copia codul. O modalitate este să "clonezi" conținutul depozitului, folosind HTTPS, SSH sau GitHub CLI (Command Line Interface).
Există mai multe modalități de a copia codul. O modalitate este să "clonezi" conținutul repository-ului, folosind HTTPS, SSH sau GitHub CLI (Command Line Interface).
Deschide terminalul și clonează depozitul astfel:
Deschide terminalul și clonează repository-ul astfel:
`git clone https://github.com/ProjectURL`
Pentru a lucra la proiect, schimbă folderul:
`cd ProjectURL`
De asemenea, poți deschide întregul proiect folosind [Codespaces](https://github.com/features/codespaces), editorul de cod integrat / mediul de dezvoltare în cloud al GitHub, sau [GitHub Desktop](https://desktop.github.com/).
De asemenea, poți deschide întregul proiect folosind [Codespaces](https://github.com/features/codespaces), editorul de cod integrat / mediu de dezvoltare cloud al GitHub, sau [GitHub Desktop](https://desktop.github.com/).
În cele din urmă, poți descărca codul într-un folder arhivat.
### Câteva lucruri interesante despre GitHub
Poți să dai stea, să urmărești și/sau să "forkezi" orice depozit public pe GitHub. Poți găsi depozitele marcate cu stea în meniul drop-down din dreapta sus. Este ca și cum ai salva un bookmark, dar pentru cod.
Poți să dai stea, să urmărești și/sau să "bifurci" orice repository public pe GitHub. Poți găsi repository-urile marcate cu stea în meniul drop-down din dreapta sus. Este ca și cum ai salva un bookmark, dar pentru cod.
Proiectele au un tracker de probleme, de obicei pe GitHub, în fila "Issues", dacă nu este indicat altfel, unde oamenii discută probleme legate de proiect. Iar fila Pull Requests este locul unde oamenii discută și revizuiesc modificările aflate în progres.
Proiectele pot avea, de asemenea, discuții în forumuri, liste de e-mail sau canale de chat precum Slack, Discord sau IRC.
✅ Aruncă o privire în noul tău repo GitHub și încearcă câteva lucruri, cum ar fi editarea setărilor, adăugarea de informații în repo-ul tău și crearea unui proiect (cum ar fi un panou Kanban). Sunt multe lucruri pe care le poți face!
✅ Explorează noul tău repo GitHub și încearcă câteva lucruri, cum ar fi editarea setărilor, adăugarea de informații în repo-ul tău și crearea unui proiect (cum ar fi un panou Kanban). Sunt multe lucruri pe care le poți face!
---
## 🚀 Provocare
Lucrează împreună cu un prieten la codul fiecăruia. Creați un proiect colaborativ, faceți fork la cod, creați ramuri și îmbinați modificările.
Lucrează împreună cu un prieten la codul fiecăruia. Creați un proiect colaborativ, bifurcați codul, creați ramuri și îmbinați modificările.
[Fișă de referință Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Exersează, exersează, exersează. GitHub are trasee de învățare excelente disponibile prin [skills.github.com](https://skills.github.com):
Exersează, exersează, exersează. GitHub oferă trasee de învățare excelente prin [skills.github.com](https://skills.github.com):
- [Prima săptămână pe GitHub](https://skills.github.com/#first-week-on-github)
@ -335,5 +342,5 @@ Completează [cursul Prima săptămână pe GitHub](https://skills.github.com/#f
---
**Declinarea responsabilității**:
Acest document a fost tradus utilizând serviciul de traducere AI [Co-op Translator](https://github.com/Azure/co-op-translator). Deși depunem eforturi pentru a asigura acuratețea, vă rugăm să aveți în vedere că traducerile automate pot conține erori sau inexactități. Documentul original în limba sa nativă ar trebui considerat sursa autoritară. Pentru informații critice, se recomandă traducerea realizată de un profesionist uman. Nu ne asumăm răspunderea pentru eventualele neînțelegeri sau interpretări greșite care pot apărea din utilizarea acestei traduceri.
**Declinare de responsabilitate**:
Acest document a fost tradus folosind serviciul de traducere AI [Co-op Translator](https://github.com/Azure/co-op-translator). Deși ne străduim să asigurăm acuratețea, vă rugăm să fiți conștienți că traducerile automate pot conține erori sau inexactități. Documentul original în limba sa natală ar trebui considerat sursa autoritară. Pentru informații critice, se recomandă traducerea profesională realizată de un specialist uman. Nu ne asumăm responsabilitatea pentru eventualele neînțelegeri sau interpretări greșite care pot apărea din utilizarea acestei traduceri.
- отслеживание работы, которую вы выполняете на своем компьютере
- отслеживание работы на вашем компьютере
- совместную работу над проектами с другими
- как вносить вклад в проекты с открытым исходным кодом
### Предварительные требования
Перед началом убедитесь, что Git установлен. В терминале введите:
Перед началом убедитесь, что Git установлен. В терминале введите:
`git --version`
Если Git не установлен, [скачайте Git](https://git-scm.com/downloads). Затем настройте локальный профиль Git в терминале:
@ -39,19 +39,19 @@ CO_OP_TRANSLATOR_METADATA:
Вам также понадобится аккаунт на GitHub, редактор кода (например, Visual Studio Code) и доступ к терминалу (или командной строке).
Перейдите на [github.com](https://github.com/), создайте аккаунт, если у вас его еще нет, или войдите в систему и заполните свой профиль.
Перейдите на [github.com](https://github.com/), создайте аккаунт, если у вас его еще нет, или войдите в систему и заполните профиль.
✅ GitHub — не единственное хранилище кода в мире; есть и другие, но GitHub — самое известное.
✅ GitHub — не единственный репозиторий кода в мире; есть и другие, но GitHub — самый известный.
### Подготовка
Вам понадобится папка с проектом кода на вашем локальном компьютере (ноутбуке или ПК) и публичное хранилище на GitHub, которое будет служить примером того, как вносить вклад в проекты других людей.
Вам понадобится папка с проектом кода на вашем локальном компьютере (ноутбуке или ПК) и публичный репозиторий на GitHub, который будет служить примером того, как вносить вклад в проекты других.
---
## Управление кодом
Предположим, у вас есть локальная папка с проектом кода, и вы хотите начать отслеживать свой прогресс с помощью git — системы контроля версий. Некоторые люди сравнивают использование git с написанием любовного письма самому себе в будущем. Читая сообщения о коммитах через дни, недели или месяцы, вы сможете вспомнить, почему приняли то или иное решение, или "откатить" изменения — при условии, что вы пишете хорошие сообщения о коммитах.
Предположим, у вас есть локальная папка с проектом кода, и вы хотите начать отслеживать свой прогресс с помощью git — системы контроля версий. Некоторые сравнивают использование git с написанием любовного письма самому себе в будущем. Читая сообщения о коммитах через дни, недели или месяцы, вы сможете вспомнить, почему приняли то или иное решение, или "откатить" изменения — при условии, что вы пишете хорошие сообщения о коммитах.
### Задача: Создать репозиторий и зафиксировать код
@ -59,7 +59,7 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Создайте репозиторий на GitHub**. На GitHub.com, в разделе репозиториев или в верхней навигационной панели, найдите кнопку **new repo**.
1. **Создайте репозиторий на GitHub**. На GitHub.com, в разделе репозиториев или в верхнем правом углу навигационной панели, найдите кнопку **new repo**.
1. Дайте вашему репозиторию (папке) имя.
1. Выберите **create repository**.
@ -70,13 +70,13 @@ CO_OP_TRANSLATOR_METADATA:
cd [name of your folder]
```
1. **Инициализируйте git-репозиторий**. В вашем проекте введите:
1. **Инициализируйте репозиторий git**. В вашем проекте введите:
```bash
git init
```
1. **Проверьте статус**. Чтобы проверить статус вашего репозитория, введите:
1. **Проверьте статус**. Чтобы проверить статус репозитория, введите:
```bash
git status
@ -93,10 +93,10 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
Обычно команда `git status` сообщает вам, какие файлы готовы к _сохранению_ в репозитории или имеют изменения, которые вы, возможно, захотите зафиксировать.
Обычно команда `git status` сообщает, какие файлы готовы к _сохранению_ в репозитории или содержат изменения, которые вы, возможно, захотите зафиксировать.
1. **Добавьте все файлы для отслеживания**
Это также называется этапом подготовки файлов/добавлением файлов в область подготовки.
Это также называется подготовкой файлов/добавлением файлов в область подготовки.
```bash
git add .
@ -112,21 +112,21 @@ CO_OP_TRANSLATOR_METADATA:
Это позволяет добавлять только выбранные файлы в область подготовки, если вы не хотите фиксировать все файлы сразу.
1. **Уберите все файлы из области подготовки**
1. **Отмените подготовку всех файлов**
```bash
git reset
```
Эта команда позволяет убрать все файлы из области подготовки сразу.
Эта команда позволяет отменить подготовку всех файлов сразу.
1. **Уберите конкретный файл из области подготовки**
1. **Отмените подготовку конкретного файла**
```bash
git reset [file or folder name]
```
Эта команда позволяет убрать только конкретный файл из области подготовки, если вы не хотите включать его в следующий коммит.
Эта команда позволяет отменить подготовку только одного конкретного файла, который вы не хотите включать в следующий коммит.
1. **Сохраните свою работу**. На этом этапе вы добавили файлы в так называемую _область подготовки_. Это место, где Git отслеживает ваши файлы. Чтобы сделать изменения постоянными, вам нужно _зафиксировать_ файлы. Для этого создайте _коммит_с помощью команды `git commit`. Коммит представляет собой точку сохранения в истории вашего репозитория. Введите следующую команду, чтобы создать коммит:
@ -134,11 +134,11 @@ CO_OP_TRANSLATOR_METADATA:
git commit -m "first commit"
```
Это фиксирует все ваши файлы, добавляя сообщение "first commit". В будущем вы захотите быть более описательными в своих сообщениях о коммитах, чтобы передать, какие изменения вы внесли.
Это фиксирует все ваши файлы, добавляя сообщение "first commit". В будущем для сообщений о коммитах вы захотите быть более описательными, чтобы передать, какой тип изменений вы внесли.
1. **Свяжите локальный репозиторий Git с GitHub**. Репозиторий Git хорош на вашем компьютере, но в какой-то момент вы захотите создать резервную копию своих файлов где-то еще и пригласить других людей работать с вами над вашим репозиторием. Одно из таких отличных мест — GitHub. Помните, что мы уже создали репозиторий на GitHub, поэтому единственное, что нам нужно сделать, это связать наш локальный репозиторий Git с GitHub. Команда `git remote add` сделает это. Введите следующую команду:
1. **Свяжите локальный репозиторий Git с GitHub**. Репозиторий Git полезен на вашем компьютере, но в какой-то момент вы захотите создать резервную копию ваших файлов где-то еще и пригласить других людей работать с вами над вашим репозиторием. Одним из таких отличных мест является GitHub. Помните, мы уже создали репозиторий на GitHub, поэтому единственное, что нам нужно сделать, это связать наш локальный репозиторий Git с GitHub. Команда `git remote add` сделает это. Введите следующую команду:
> Примечание: перед вводом команды перейдите на страницу вашего репозитория на GitHub, чтобы найти URL репозитория. Вы будете использовать его в команде ниже. Замените ```https://github.com/username/repository_name.git``` на ваш URL GitHub.
> Примечание: перед вводом команды перейдите на страницу вашего репозитория GitHub, чтобы найти URL репозитория. Вы будете использовать его в команде ниже. Замените ```https://github.com/username/repository_name.git``` на ваш URL GitHub.
1. **Отправьте локальные файлы на GitHub**. До сих пор вы создали _подключение_ между локальным репозиторием и репозиторием GitHub. Давайте отправим эти файлы на GitHub с помощью следующей команды `git push`, как показано ниже:
> Примечание: имя вашей ветки может отличаться от ```main```.
> Примечание: имя вашей ветки по умолчанию может отличаться от ```main```.
```bash
git push -u origin main
```
Это отправляет ваши коммиты в ветку "main" на GitHub.
Это отправляет ваши коммиты в ветке "main" на GitHub. Установка ветки `upstream`, включая `-u` в команде, устанавливает связь между вашей локальной веткой и удаленной веткой, так что вы можете просто использовать git push или git pull без указания имени ветки в будущем. Git автоматически будет использовать ветку upstream, и вам не нужно будет явно указывать имя ветки в будущих командах.
2. **Добавьте больше изменений**. Если вы хотите продолжить вносить изменения и отправлять их на GitHub, вам нужно будет использовать следующие три команды:
2. **Добавление новых изменений**. Если вы хотите продолжить внесение изменений и отправку их на GitHub, вам нужно будет использовать следующие три команды:
```bash
git add .
@ -164,17 +164,17 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> Совет: возможно, вы захотите использовать файл `.gitignore`, чтобы предотвратить отображение файлов, которые вы не хотите отслеживать, на GitHub — например, файл заметок, который вы храните в той же папке, но который не должен быть в публичном репозитории. Вы можете найти шаблоны для файлов `.gitignore` на [шаблоны .gitignore](https://github.com/github/gitignore).
> Совет: возможно, вы захотите использовать файл `.gitignore`, чтобы предотвратить отображение файлов, которые вы не хотите отслеживать, на GitHub — например, файл заметок, который вы храните в той же папке, но который не должен быть в публичном репозитории. Вы можете найти шаблоны для файлов `.gitignore` на [.gitignore templates](https://github.com/github/gitignore).
#### Сообщения о коммитах
Отличная строка темы коммита Git завершает следующее предложение:
Отличная строка темы коммита Git завершает следующее предложение:
Если применить, этот коммит <ваша строка темы здесь>
Для темы используйте повелительное наклонение в настоящем времени: "изменить", а не "изменено" или "изменяет".
Для темы используйте повелительное наклонение в настоящем времени: "изменить", а не "изменено" или "изменяет".
Как и в теме, в теле (опционально) также используйте повелительное наклонение в настоящем времени. Тело должно включать мотивацию для изменения и контрастировать это с предыдущим поведением. Вы объясняете `почему`, а не `как`.
✅ Потратьте несколько минут, чтобы просмотреть GitHub. Можете ли вы найти действительно отличное сообщение о коммите? А минимальное? Какую информацию, по вашему мнению, наиболее важно и полезно передать в сообщении о коммите?
✅ Потратьте несколько минут, чтобы поискать на GitHub. Можете ли вы найти действительно отличное сообщение о коммите? А минимальное? Какую информацию, по вашему мнению, наиболее важно и полезно передать в сообщении о коммите?
### Задача: Сотрудничество
@ -186,7 +186,7 @@ CO_OP_TRANSLATOR_METADATA:
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
В вашем репозитории перейдите в `Insights > Community`, чтобы увидеть, как ваш проект соответствует рекомендуемым стандартам сообщества.
В вашем репозитории перейдите в `Insights > Community`, чтобы увидеть, как ваш проект соответствует рекомендованным стандартам сообщества.
Вот несколько вещей, которые могут улучшить ваш репозиторий на GitHub:
- **Описание**. Добавили ли вы описание для вашего проекта?
- **Лицензия**. Возможно, самое важное — [лицензия](https://docs.github.com/articles/adding-a-license-to-a-repository/).
Все эти ресурсы помогут новым участникам команды. Обычно это те вещи, которые новые участники смотрят перед тем, как изучить ваш код, чтобы понять, подходит ли ваш проект для их времени.
Все эти ресурсы помогут новым участникам команды быстрее адаптироваться. Обычно именно такие вещи новые участники изучают перед тем, как взглянуть на ваш код, чтобы понять, подходит ли ваш проект для их времени и усилий.
✅ Файлы README, хотя их подготовка занимает время, часто игнорируются занятыми поддерживающими. Можете ли вы найти пример особенно описательного README? Примечание: есть [инструменты для создания хороших README](https://www.makeareadme.com/), которые вам могут понравиться.
✅ Файлы README, хотя их подготовка занимает время, часто игнорируются занятыми поддерживающими проект разработчиками. Можете ли вы найти пример особенно описательного README? Примечание: существуют [инструменты для создания хороших README](https://www.makeareadme.com/), которые вам могут понравиться.
### Задача: Объединить код
### Задача: Объединение кода
Документы о внесении изменений помогают людям вносить вклад в проект. Они объясняют, какие типы вкладов вы ищете и как работает процесс. Участники должны пройти серию шагов, чтобы внести вклад в ваш репозиторий на GitHub:
Документы для внесения изменений помогают людям вносить вклад в проект. Они объясняют, какие типы вкладов вы ищете и как работает процесс. Участники должны пройти ряд шагов, чтобы иметь возможность внести вклад в ваш репозиторий на GitHub:
1. **Форк вашего репозитория**. Вы, вероятно, захотите, чтобы люди _форкнули_ ваш проект. Форк означает создание копии вашего репозитория в их профиле GitHub.
1. **Форк вашего репозитория**. Вы, вероятно, захотите, чтобы люди _форкали_ ваш проект. Форк означает создание копии вашего репозитория в их профиле GitHub.
1. **Клонирование**. После этого они клонируют проект на свой локальный компьютер.
1. **Создание ветки**. Вы захотите попросить их создать _ветку_ для своей работы.
1. **Сосредоточение изменений на одной области**. Попросите участников сосредоточить свои изменения на одной вещи за раз — так вероятность того, что вы сможете _объединить_ их работу, будет выше. Представьте, что они исправляют баг, добавляют новую функцию и обновляют несколько тестов — что, если вы хотите или можете реализовать только 2 из 3 или 1 из 3 изменений?
@ -212,21 +212,21 @@ CO_OP_TRANSLATOR_METADATA:
> Примечание: будьте тем изменением, которое вы хотите видеть в мире, и создавайте ветки для своей работы. Любые коммиты, которые вы делаете, будут сделаны в ветке, в которой вы сейчас "находитесь". Используйте `git status`, чтобы увидеть, в какой ветке вы находитесь.
Давайте рассмотрим рабочий процесс участника. Предположим, участник уже _форкнул_ и _клонировал_ репозиторий, поэтомуу него есть готовый репозиторий Git на локальном компьютере:
Давайте рассмотрим рабочий процесс участника. Предположим, участник уже _форкал_ и _клонировал_ репозиторий, так чтоу него есть готовый репозиторий Git на локальном компьютере:
1. **Создайте ветку**. Используйте команду `git branch`, чтобы создать ветку, которая будет содержать изменения, которые они хотят внести:
1. **Создайте ветку**. Используйте команду `git branch`, чтобы создать ветку, которая будет содержать изменения, которые они планируют внести:
```bash
git branch [branch-name]
```
1. **Переключитесь на рабочую ветку**. Переключитесь на указанную ветку и обновите рабочую директорию с помощью `git switch`:
1. **Переключитесь на рабочую ветку**. Переключитесь на указанную ветку и обновите рабочую директорию с помощью команды `git switch`:
```bash
git switch [branch-name]
```
1. **Работайте**. На этом этапе вы хотите добавить свои изменения. Не забудьте сообщить об этом Git с помощью следующих команд:
1. **Работайте**. На этом этапе вы хотите внести свои изменения. Не забудьте сообщить об этом Git с помощью следующих команд:
```bash
git add .
@ -235,7 +235,7 @@ CO_OP_TRANSLATOR_METADATA:
Убедитесь, что вы дали вашему коммиту хорошее имя — для вашего удобства, а также для удобства поддерживающего репозиторий, которому вы помогаете.
1. **Объедините свою работу с веткой `main`**. В какой-то момент вы завершите работу и захотите объединить еес веткой `main`. Ветка `main` могла измениться за это время, поэтому сначала убедитесь, что вы обновили ее до последней версии с помощью следующих команд:
1. **Объедините вашу работу с веткой `main`**. В какой-то момент вы завершите работу и захотите объединить еес веткой `main`. Ветка `main` могла измениться за это время, поэтому сначала убедитесь, что вы обновили ее до последней версии с помощью следующих команд:
```bash
git switch main
@ -249,30 +249,35 @@ CO_OP_TRANSLATOR_METADATA:
git merge main
```
Это принесет все изменения из `main` в вашу ветку, и, надеемся, вы сможете просто продолжить. Если нет, VS Code покажет вам, где Git _запутался_, и вы просто измените затронутые файлы, чтобы указать, какой контент наиболее точен.
Команда `git merge main` объединит все изменения из `main` в вашу ветку. Надеемся, вы сможете просто продолжить. Если нет, VS Code покажет вам, где Git _запутался_, и вы просто измените затронутые файлы, чтобы указать, какой контент наиболее точен.
Чтобы переключиться на другую ветку, используйте современную команду `git switch`:
```bash
git switch [branch_name]
1. **Отправьте свою работу на GitHub**. Отправка вашей работы на GitHub означает две вещи: отправка вашей ветки в ваш репозиторий и открытие PR (Pull Request).
1. **Отправьте вашу работу на GitHub**. Отправка вашей работы на GitHub означает две вещи: отправку вашей ветки в ваш репозиторий и открытие PR (Pull Request).
```bash
git push --set-upstream origin [branch-name]
```
Команда выше создает ветку в вашем форкнутом репозитории.
1. **Открыть PR**. Далее вам нужно открыть PR. Для этого перейдите в форкнутый репозиторий на GitHub. На GitHub будет указано, хотите ли вы создать новый PR. Нажмите на это, и вы попадете в интерфейс, где можно изменить заголовок сообщения коммита и добавить более подходящее описание. Теперь владелец репозитория, который вы форкнули, увидит ваш PR и, _держим кулачки_, оценит его и _объединит_ ваш PR. Поздравляем, теперь вы — участник проекта, ура! :)
1. **Откройте PR**. Далее вы захотите открыть PR. Для этого перейдите в форкнутый репозиторий на GitHub. Вы увидите уведомление на GitHub, где вас спросят, хотите ли вы создать новый PR. Нажмите на него, и вы попадете в интерфейс, где сможете изменить заголовок сообщения коммита, дать ему более подходящее описание. Теперь поддерживающий репозиторий, который вы форкнули, увидит этот PR, и _надеемся_, он оценит и _объединит_ ваш PR. Теперь вы участник, ура :)
1. **Очистите**. Считается хорошей практикой _очистить_ после успешного объединения PR. Вы захотите удалить как локальную ветку, так и ветку, которую вы отправили на GitHub. Сначала удалите ее локально с помощью следующей команды:
1. **Очистка**. Считается хорошей практикой _очистить_ после успешного объединения PR. Вам нужно очистить как локальную ветку, так и ветку, которую вы отправили на GitHub. Сначала удалим ее локально с помощью следующей команды:
```bash
git branch -d [branch-name]
```
Убедитесь, что вы перешли на страницу форкнутого репозитория на GitHub и удалили удаленную ветку, которую только что отправили.
Убедитесь, что вы также удалили удаленную ветку на странице форкнутого репозитория на GitHub.
`Pull request` кажется странным термином, ведь на самом деле вы хотите "запушить" свои изменения в проект. Однако владелец проекта или основная команда должны рассмотреть ваши изменения перед их объединением с "главной" веткой проекта, так что вы, по сути, запрашиваете решение о внесении изменений у владельца проекта.
`Pull request` может показаться странным термином, ведь на самом деле вы хотите отправить свои изменения в проект. Но владелец проекта или основная команда должны рассмотреть ваши изменения перед их объединением с "основной" веткой проекта, так что вы фактически запрашиваете решение о внесении изменений у владельца.
`Pull request` — это место, где можно сравнить и обсудить различия, внесенные в ветку, с помощью обзоров, комментариев, интегрированных тестов и других инструментов. Хороший `pull request` следует примерно тем же правилам, что и сообщение о коммите. Вы можете добавить ссылку на задачу в трекере задач, если ваша работа, например, исправляет проблему. Это делается с помощью символа `#`, за которым следует номер задачи. Например, `#97`.
Pull request — это место, где можно сравнить и обсудить различия, внесенные в ветку, с помощью обзоров, комментариев, интегрированных тестов и других инструментов. Хороший pull request следует примерно тем же правилам, что и сообщение коммита. Вы можете добавить ссылку на задачу в трекере задач, если ваша работа, например, решает проблему. Это делается с помощью `#`, за которым следует номер вашей задачи. Например, `#97`.
🤞Держим кулачки, чтобы все проверки прошли успешно и владелец(ы) проекта объединили ваши изменения с проектом🤞
🤞Держим кулачки, чтобы все проверки прошли успешно и владелец(ы) проекта объединили ваши изменения в проект🤞
Обновите текущую локальную рабочую ветку, добавив все новые коммиты из соответствующей удаленной ветки на GitHub:
@ -280,60 +285,60 @@ CO_OP_TRANSLATOR_METADATA:
## Как внести вклад в open source
Сначала найдите репозиторий (или **repo**) на GitHub, который вас интересует и в который вы хотели бы внести изменения. Вам нужно будет скопировать его содержимое на свой компьютер.
Сначала найдите репозиторий (или **repo**) на GitHub, который вас интересует и в который вы хотели бы внести изменения. Вам нужно скопировать его содержимое на свой компьютер.
✅ Хороший способ найти репозитории, подходящие для новичков, — [поиск по тегу 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Хороший способ найти репозитории, подходящие для новичков, — [искать по тегу 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Существует несколько способов копирования кода. Один из них — "клонировать" содержимое репозитория, используя HTTPS, SSH или GitHub CLI (Command Line Interface).
Есть несколько способов скопировать код. Один из них — "клонировать" содержимое репозитория, используя HTTPS, SSH или GitHub CLI (Command Line Interface).
Откройте терминал и клонируйте репозиторий следующим образом:
Откройте терминал и клонируйте репозиторий следующим образом:
`git clone https://github.com/ProjectURL`
Чтобы работать над проектом, перейдите в нужную папку:
Чтобы работать над проектом, перейдите в нужную папку:
`cd ProjectURL`
Вы также можете открыть весь проект, используя [Codespaces](https://github.com/features/codespaces), встроенный редактор кода / облачную среду разработки от GitHub, или [GitHub Desktop](https://desktop.github.com/).
Вы также можете открыть весь проект, используя [Codespaces](https://github.com/features/codespaces), встроенный редактор кода / облачную среду разработки GitHub, или [GitHub Desktop](https://desktop.github.com/).
Наконец, вы можете скачать код в виде архива.
### Несколько интересных фактов о GitHub
Вы можете поставить звезду, подписаться на обновления или "форкнуть" любой публичный репозиторий на GitHub. Найти свои отмеченные звездами репозитории можно в выпадающем меню в правом верхнем углу. Это как закладки, но для кода.
Вы можете поставить звезду, подписаться на обновления или "форкнуть" любой публичный репозиторий на GitHub. Вы найдете свои отмеченные звездами репозитории в выпадающем меню в правом верхнем углу. Это как закладки, но для кода.
У проектов есть трекер задач, чаще всего на GitHub во вкладке "Issues", если не указано иначе, где люди обсуждают проблемы, связанные с проектом. А во вкладке Pull Requests обсуждаются и проверяются изменения, которые находятся в процессе работы.
У проектов есть трекер задач, обычно на GitHub во вкладке "Issues", если не указано иначе, где люди обсуждают проблемы, связанные с проектом. А вкладка Pull Requests — это место, где обсуждаются и рассматриваются изменения, которые находятся в процессе.
У проектов также могут быть форумы, списки рассылки или чаты, такие как Slack, Discord или IRC.
У проектов также могут быть обсуждения на форумах, в списках рассылки или в чатах, таких как Slack, Discord или IRC.
✅ Осмотритесь в своем новом репозитории на GitHub и попробуйте сделать несколько вещей, например, изменить настройки, добавить информацию в репозиторий или создать проект (например, Канбан-доску). Возможностей много!
✅ Ознакомьтесь с вашим новым репозиторием на GitHub и попробуйте сделать несколько вещей, например, изменить настройки, добавить информацию в репозиторий или создать проект (например, доску Kanban). Возможностей много!
---
## 🚀 Задание
## 🚀 Задание
Работайте в паре с другом над кодом друг друга. Создайте проект совместно, форкните код, создайте ветки и объедините изменения.
## Викторина после лекции
## Викторина после лекции
[Викторина после лекции](https://ff-quizzes.netlify.app/web/en/)
## Обзор и самостоятельное изучение
Прочитайте больше о [внесении вклада в open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Прочитайте больше о [внесении вклада в open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Шпаргалка по Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Практика, практика, практика. GitHub предлагает отличные учебные материалы на [skills.github.com](https://skills.github.com):
Практикуйтесь, практикуйтесь, практикуйтесь. GitHub предлагает отличные учебные курсы на [skills.github.com](https://skills.github.com):
- [Первая неделя на GitHub](https://skills.github.com/#first-week-on-github)
Там также можно найти более продвинутые курсы.
Там также есть более продвинутые курсы.
## Задание
## Задание
Пройдите [курс "Первая неделя на GitHub"](https://skills.github.com/#first-week-on-github)
Пройдите курс [Первая неделя на GitHub](https://skills.github.com/#first-week-on-github)
---
**Отказ от ответственности**:
Этот документ был переведен с помощью сервиса автоматического перевода [Co-op Translator](https://github.com/Azure/co-op-translator). Несмотря на наши усилия по обеспечению точности, автоматические переводы могут содержать ошибки или неточности. Оригинальный документ на его родном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется профессиональный перевод человеком. Мы не несем ответственности за любые недоразумения или неправильные интерпретации, возникающие в результате использования данного перевода.
Этот документ был переведен с помощью сервиса автоматического перевода [Co-op Translator](https://github.com/Azure/co-op-translator). Несмотря на наши усилия обеспечить точность, автоматические переводы могут содержать ошибки или неточности. Оригинальный документ на его родном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется профессиональный перевод человеком. Мы не несем ответственности за любые недоразумения или неправильные интерпретации, возникшие в результате использования данного перевода.
@ -19,52 +19,53 @@ Táto lekcia pokrýva základy GitHubu, platformy na hosťovanie a správu zmien
## Úvod
V tejto lekcii sa naučíme:
V tejto lekcii sa naučíte:
- sledovať prácu, ktorú robíte na svojom počítači
- pracovať na projektoch s ostatnými
- ako prispievať do open source softvéru
### Požiadavky
### Predpoklady
Predtým, než začnete, skontrolujte, či máte nainštalovaný Git. V termináli zadajte:
Predtým, než začnete, skontrolujte, či máte nainštalovaný Git. V termináli zadajte:
`git --version`
Ak Git nie je nainštalovaný, [stiahnite si Git](https://git-scm.com/downloads). Potom nastavte svoj lokálny Git profil v termináli:
Ak Git nie je nainštalovaný, [stiahnite Git](https://git-scm.com/downloads). Potom nastavte svoj lokálny Git profil v termináli:
* `git config --global user.name "vaše-meno"`
* `git config --global user.email "váš-email"`
Ak chcete skontrolovať, či je Git už nakonfigurovaný, môžete zadať:
`git config --list`
Budete tiež potrebovať účet na GitHube, editor kódu (napríklad Visual Studio Code) a otvorený terminál (alebo príkazový riadok).
Budete tiež potrebovať účet na GitHub, editor kódu (napríklad Visual Studio Code) a otvorený terminál (alebo: príkazový riadok).
Prejdite na [github.com](https://github.com/) a vytvorte si účet, ak ho ešte nemáte, alebo sa prihláste a vyplňte svoj profil.
Prejdite na [github.com](https://github.com/) a vytvorte si účet, ak ho ešte nemáte, alebo sa prihláste a vyplňte svoj profil.
✅ GitHub nie je jediným úložiskom kódu na svete; existujú aj iné, ale GitHub je najznámejší.
### Príprava
Budete potrebovať priečinok s projektom kódu na svojom lokálnom počítači (notebooku alebo PC) a verejné úložisko na GitHube, ktoré bude slúžiť ako príklad, ako prispievať do projektov iných.
Budete potrebovať priečinok s projektom kódu na vašom lokálnom počítači (notebook alebo PC) a verejné úložisko na GitHub, ktoré bude slúžiť ako príklad, ako prispievať do projektov ostatných.
---
## Správa kódu
Predstavte si, že máte lokálne priečinok s projektom kódu a chcete začať sledovať svoj pokrok pomocou systému na správu verzií git. Niektorí ľudia prirovnávajú používanie gitu k písaniu ľúbostného listu svojmu budúcemu ja. Čítaním svojich commit správ o dni, týždne alebo mesiace neskôr si budete môcť spomenúť, prečo ste urobili určité rozhodnutie, alebo "vrátiť" zmenu - samozrejme, ak píšete dobré "commit správy".
Predstavte si, že máte lokálny priečinok s projektom kódu a chcete začať sledovať svoj pokrok pomocou git - systému na správu verzií. Niektorí ľudia prirovnávajú používanie git k písaniu milostného listu svojmu budúcemu ja. Čítaním vašich commit správ o dni, týždne alebo mesiace neskôr si budete môcť spomenúť, prečo ste urobili určité rozhodnutie, alebo "vrátiť" zmenu - samozrejme, ak píšete dobré "commit správy".
### Úloha: Vytvorte úložisko a commitnite kód
> Pozrite si video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Vytvorte úložisko na GitHube**. Na GitHub.com, v záložke úložísk alebo v navigačnom paneli vpravo hore, nájdite tlačidlo **new repo**.
1. Dajte svojmu úložisku (priečinku) názov.
1. **Vytvorte úložisko na GitHub**. Na GitHub.com, v záložke úložísk alebo z navigačného panela vpravo hore, nájdite tlačidlo **new repo**.
1. Dajte svojmu úložisku (priečinku) názov
1. Vyberte **create repository**.
1. **Prejdite do svojho pracovného priečinka**. V termináli prepnite do priečinka (tiež známeho ako adresár), ktorý chcete začať sledovať. Zadajte:
1. **Prejdite do svojho pracovného priečinka**. V termináli prepnite na priečinok (tiež známy ako adresár), ktorý chcete začať sledovať. Zadajte:
```bash
cd [name of your folder]
@ -95,14 +96,14 @@ Predstavte si, že máte lokálne priečinok s projektom kódu a chcete začať
Typicky príkaz `git status` vám povie veci ako, ktoré súbory sú pripravené na _uloženie_ do úložiska alebo majú zmeny, ktoré by ste mohli chcieť zachovať.
1. **Pridajte všetky súbory na sledovanie**
1. **Pridajte všetky súbory na sledovanie**
Toto sa tiež nazýva staging súborov/pridávanie súborov do staging oblasti.
```bash
git add .
```
Argument `git add`spolu s `.` znamená, že všetky vaše súbory a zmeny budú sledované.
Argument `git add`plus `.` označuje, že všetky vaše súbory a zmeny sú pripravené na sledovanie.
1. **Pridajte vybrané súbory na sledovanie**
@ -110,23 +111,23 @@ Predstavte si, že máte lokálne priečinok s projektom kódu a chcete začať
git add [file or folder name]
```
Toto nám umožňuje pridať iba vybrané súbory do staging oblasti, keď nechceme commitnúť všetky súbory naraz.
Toto nám pomáha pridať iba vybrané súbory do staging oblasti, keď nechceme commitnúť všetky súbory naraz.
1. **Zrušte staging všetkých súborov**
1. **Odstráňte všetky súbory zo staging oblasti**
```bash
git reset
```
Tento príkaz nám umožňuje zrušiť staging všetkých súborov naraz.
Tento príkaz nám pomáha odstrániť všetky súbory zo staging oblasti naraz.
1. **Zrušte staging konkrétneho súboru**
1. **Odstráňte konkrétny súbor zo staging oblasti**
```bash
git reset [file or folder name]
```
Tento príkaz nám umožňuje zrušiť staging iba konkrétneho súboru naraz, ktorý nechceme zahrnúť do ďalšieho commitu.
Tento príkaz nám pomáha odstrániť iba konkrétny súbor zo staging oblasti, ktorý nechceme zahrnúť do ďalšieho commitu.
1. **Uložte svoju prácu**. V tomto bode ste pridali súbory do tzv. _staging oblasti_. Miesto, kde Git sleduje vaše súbory. Aby ste zmenu urobili trvalou, musíte _commitnúť_ súbory. Na to vytvoríte _commit_ pomocou príkazu `git commit`. _Commit_ predstavuje bod uloženia v histórii vášho úložiska. Zadajte nasledujúce na vytvorenie _commit_:
@ -134,29 +135,29 @@ Predstavte si, že máte lokálne priečinok s projektom kódu a chcete začať
git commit -m "first commit"
```
Tento príkaz commitne všetky vaše súbory a pridá správu "first commit". Pre budúce commit správy budete chcieť byť viac popisní, aby ste vyjadrili, aký typ zmeny ste urobili.
Tento príkaz commitne všetky vaše súbory, pričom pridá správu "first commit". Pre budúce commit správy budete chcieť byť viac popisní vo svojom popise, aby ste vyjadrili, aký typ zmeny ste urobili.
1. **Prepojte svoje lokálne Git úložisko s GitHubom**. Git úložisko je užitočné na vašom počítači, ale v určitom bode budete chcieť mať zálohu svojich súborov niekde inde a tiež pozvať iných ľudí, aby s vami pracovali na vašom úložisku. Jedným z takých skvelých miest je GitHub. Pamätajte, že sme už vytvorili úložisko na GitHube, takže jediná vec, ktorú musíme urobiť, je prepojiť naše lokálne Git úložisko s GitHubom. Príkaz `git remote add` to urobí. Zadajte nasledujúci príkaz:
1. **Prepojte svoje lokálne Git úložisko s GitHubom**. Git úložisko je dobré na vašom počítači, ale v určitom bode budete chcieť mať zálohu svojich súborov niekde a tiež pozvať ostatných ľudí, aby s vami pracovali na vašom úložisku. Jedným z takých skvelých miest je GitHub. Pamätajte, že sme už vytvorili úložisko na GitHub, takže jediná vec, ktorú musíme urobiť, je prepojiť naše lokálne Git úložisko s GitHubom. Príkaz `git remote add` to urobí. Zadajte nasledujúci príkaz:
> Poznámka: Predtým, než zadáte príkaz, prejdite na stránku svojho GitHub úložiska a nájdite URL úložiska. Použijete ho v nasledujúcom príkaze. Nahraďte ```https://github.com/username/repository_name.git``` svojou GitHub URL.
> Poznámka, predtým než zadáte príkaz, prejdite na stránku svojho GitHub úložiska, aby ste našli URL úložiska. Použijete ho v nasledujúcom príkaze. Nahraďte ```https://github.com/username/repository_name.git``` svojou GitHub URL.
Tento príkaz vytvorí _remote_, alebo spojenie, s názvom "origin", ktoré ukazuje na GitHub úložisko, ktoré ste vytvorili skôr.
Tento príkaz vytvorí _remote_, alebo spojenie, nazvané "origin", ktoré ukazuje na GitHub úložisko, ktoré ste vytvorili skôr.
1. **Odošlite lokálne súbory na GitHub**. Doteraz ste vytvorili _spojenie_ medzi lokálnym úložiskom a GitHub úložiskom. Pošlime tieto súbory na GitHub pomocou nasledujúceho príkazu `git push`, takto:
1. **Odošlite lokálne súbory na GitHub**. Doteraz ste vytvorili _spojenie_ medzi lokálnym úložiskom a GitHub úložiskom. Pošlite tieto súbory na GitHub pomocou nasledujúceho príkazu `git push`, takto:
> Poznámka: Názov vašej vetvy môže byť predvolene iný ako ```main```.
> Poznámka, názov vašej vetvy môže byť predvolene odlišný od ```main```.
```bash
git push -u origin main
```
Tento príkaz odošle vaše commity vo vetve "main" na GitHub.
Tento príkaz odošle vaše commity vo vetve "main" na GitHub. Nastavenie `upstream` vetvy vrátane `-u` v príkaze vytvorí prepojenie medzi vašou lokálnou vetvou a vzdialenou vetvou, takže môžete jednoducho používať git push alebo git pull bez špecifikovania názvu vetvy v budúcnosti. Git automaticky použije upstream vetvu a nebudete musieť explicitne špecifikovať názov vetvy v budúcich príkazoch.
2. **Pridanie ďalších zmien**. Ak chcete pokračovať v robení zmien a ich odosielaní na GitHub, budete potrebovať použiť nasledujúce tri príkazy:
2. **Pridajte ďalšie zmeny**. Ak chcete pokračovať v robení zmien a ich odosielaní na GitHub, budete potrebovať použiť nasledujúce tri príkazy:
```bash
git add .
@ -164,125 +165,131 @@ Predstavte si, že máte lokálne priečinok s projektom kódu a chcete začať
git push
```
> Tip: Možno budete chcieť pridať aj `.gitignore` súbor, aby ste zabránili sledovaniu súborov, ktoré nechcete mať na GitHube - napríklad poznámkový súbor, ktorý si ukladáte v rovnakom priečinku, ale nemá miesto vo verejnom úložisku. Šablóny pre `.gitignore` súbory nájdete na [.gitignore templates](https://github.com/github/gitignore).
> Tip, Možno budete chcieť pridať súbor `.gitignore`, aby ste zabránili tomu, aby sa súbory, ktoré nechcete sledovať, zobrazovali na GitHub - napríklad ten súbor s poznámkami, ktorý uchovávate v rovnakom priečinku, ale nemá miesto vo verejnom úložisku. Šablóny pre súbory `.gitignore` nájdete na [.gitignore templates](https://github.com/github/gitignore).
#### Commit správy
Skvelý predmet commit správy dokončí nasledujúcu vetu:
Ak sa použije, tento commit bude <vášpredmetsprávytu>
Skvelý predmet commit správy dokončí nasledujúcu vetu:
Ak sa použije, tento commit <vášpredmetsprávytu>
Pre predmet používajte rozkazovací, prítomný čas: "zmeniť" namiesto "zmenené" alebo "mení".
Rovnako ako v predmete, aj v tele (voliteľné) používajte rozkazovací, prítomný čas. Telo by malo obsahovať motiváciu pre zmenu a porovnať ju s predchádzajúcim správaním. Vysvetľujete `prečo`, nie `ako`.
Pre predmet použite imperatív, prítomný čas: "zmeniť" nie "zmenené" ani "zmeny".
Rovnako ako v predmete, aj v tele (voliteľné) použite imperatív, prítomný čas. Telo by malo obsahovať motiváciu pre zmenu a porovnať to s predchádzajúcim správaním. Vysvetľujete `prečo`, nie `ako`.
✅ Strávte pár minút prehliadaním GitHubu. Nájdete skvelú commit správu? Nájdete veľmi stručnú? Aké informácie považujete za najdôležitejšie a najužitočnejšie na vyjadrenie v commit správe?
✅ Venujte pár minút prehliadaniu GitHubu. Nájdete naozaj skvelú commit správu? Nájdete naozaj minimálnu? Aké informácie si myslíte, že sú najdôležitejšie a najužitočnejšie na vyjadrenie v commit správe?
### Úloha: Spolupracujte
Hlavným dôvodom pre umiestnenie vecí na GitHub bolo umožniť spoluprácu s inými vývojármi.
Hlavným dôvodom pre umiestnenie vecí na GitHub bolo umožniť spoluprácu s ostatnými vývojármi.
## Práca na projektoch s ostatnými
> Pozrite si video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Vo svojom úložisku prejdite na `Insights > Community`, aby ste videli, ako váš projekt porovnáva s odporúčanými komunitnými štandardmi.
Tu je niekoľko vecí, ktoré môžu zlepšiť vaše GitHub úložisko:
- **Popis**. Pridali ste popis pre svoj projekt?
- **README**. Pridali ste README? GitHub poskytuje pokyny na písanie [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Pravidlá prispievania**. Má váš projekt [pravidlá prispievania](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Licencia**. Možno najdôležitejšie, máte [licenciu](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Tu sú niektoré veci, ktoré môžu zlepšiť vaše GitHub úložisko:
- **Popis**. Pridali ste popis pre svoj projekt?
- **README**. Pridali ste README? GitHub poskytuje pokyny na písanie [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Pravidlá prispievania**. Má váš projekt [pravidlá prispievania](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon),
- **Licencia**. Možno najdôležitejšie, [licenciu](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Všetky tieto zdroje budú prínosom pre onboarding nových členov tímu. A to sú typicky veci, na ktoré sa noví prispievatelia pozerajú predtým, než sa pozrú na váš kód, aby zistili, či je váš projekt správnym miestom, kde by mali tráviť svoj čas.
Všetky tieto zdroje budú prospešné pri onboardingu nových členov tímu. A to sú typicky veci, na ktoré sa noví prispievatelia pozerajú predtým, než sa pozrú na váš kód, aby zistili, či je váš projekt správnym miestom, kde by mali tráviť svoj čas.
✅ README súbory, hoci ich príprava zaberá čas, sú často zanedbávané zaneprázdnenými správcami. Nájdete príklad obzvlášť popisného README? Poznámka: existujú niektoré [nástroje na vytváranie dobrých README](https://www.makeareadme.com/), ktoré by ste mohli vyskúšať.
✅ README súbory, aj keď ich príprava zaberá čas, sú často zanedbávané zaneprázdnenými správcami. Nájdete príklad obzvlášť popisného README? Poznámka: existujú niektoré [nástroje na vytváranie dobrých README](https://www.makeareadme.com/), ktoré by ste mohli vyskúšať.
### Úloha: Spojte kód
Dokumenty o prispievaní pomáhajú ľuďom prispievať do projektu. Vysvetľujú, aké typy príspevkov hľadáte a ako proces funguje. Prispievatelia budú musieť prejsť sériou krokov, aby mohli prispieť do vášho úložiska na GitHube:
Dokumenty o prispievaní pomáhajú ľuďom prispievať do projektu. Vysvetľujú, aké typy príspevkov hľadáte a ako proces funguje. Prispievatelia budú musieť prejsť sériou krokov, aby mohli prispievať do vášho úložiska na GitHub:
1. **Forkovanie vášho úložiska**. Pravdepodobne budete chcieť, aby ľudia _forkovali_ váš projekt. Forkovanie znamená vytvorenie repliky vášho úložiska na ich GitHub profile.
1. **Klonovanie**. Odtiaľ si projekt naklonujú na svoj lokálny počítač.
1. **Vytvorenie vetvy**. Budete chcieť, aby si vytvorili _vetvu_ pre svoju prácu.
1. **Zameranie zmien na jednu oblasť**. Požiadajte prispievateľov, aby sa sústredili na jednu vec naraz - tým sa zvýši šanca, že ich prácu budete môcť _spojiť_ s vašou. Predstavte si, že opravia chybu, pridajú novú funkciu a aktualizujú niekoľko testov - čo ak chcete alebo môžete implementovať iba 2 z 3, alebo 1 z 3 zmien?
✅ Predstavte si situáciu, kde sú vetvy obzvlášť dôležité pre písanie a doručovanie dobrého kódu. Aké prípady použitia si viete predstaviť?
1. **Forkovanie vášho úložiska** Pravdepodobne budete chcieť, aby ľudia _forkovali_ váš projekt. Forkovanie znamená vytvorenie repliky vášho úložiska na ich GitHub profile.
1. **Klonovanie**. Odtiaľ si projekt naklonujú na svoj lokálny počítač.
1. **Vytvorenie vetvy**. Budete chcieť, aby si vytvorili _vetvu_ pre svoju prácu.
1. **Zameranie zmeny na jednu oblasť**. Požiadajte prispievateľov, aby sa sústredili na jeden príspevok naraz - tým sa zvýši šanca, že budete môcť _spojiť_ ich prácu. Predstavte si, že napíšu opravu chyby, pridajú novú funkciu a aktualizujú niekoľko testov - čo ak chcete, alebo môžete implementovať iba 2 z 3, alebo 1 z 3 zmien?
> Poznámka: Buďte zmenou, ktorú chcete vidieť vo svete, a vytvárajte vetvy aj pre svoju vlastnú prácu. Akékoľvek commity, ktoré urobíte, budú urobené vo vetve, na ktorej ste aktuálne "checkoutnutí". Použite `git status`, aby ste videli, na ktorej vetve sa nachádzate.
✅ Predstavte si situáciu, kde sú vetvy obzvlášť kritické pre písanie a dodávanie dobrého kódu. Aké prípady použitia vás napadajú?
Prejdime si pracovný postup prispievateľa. Predpokladajme, že prispievateľ už _forkol_ a _naklonoval_ úložisko, takže má Git úložisko pripravené na prácu na svojom lokálnom počítači:
> Poznámka, buďte zmenou, ktorú chcete vidieť vo svete, a vytvorte vetvy aj pre svoju vlastnú prácu. Akékoľvek commity, ktoré urobíte, budú urobené na vetve, na ktorej ste aktuálne "checkoutnutí". Použite `git status`, aby ste videli, na ktorej vetve sa nachádzate.
1. **Vytvorte vetvu**. Použite príkaz `git branch` na vytvorenie vetvy, ktorá bude obsahovať zmeny, ktoré chcú prispieť:
Prejdime si pracovný postup prispievateľa. Predpokladajme, že prispievateľ už _forkoval_ a _klonoval_ úložisko, takže má Git úložisko pripravené na prácu na svojom lokálnom počítači:
1. **Vytvorenie vetvy**. Použite príkaz `git branch` na vytvorenie vetvy, ktorá bude obsahovať zmeny, ktoré chcú prispieť:
```bash
git branch [branch-name]
```
1. **Prepnite sa na pracovnú vetvu**. Prepnite sa na špecifikovanú vetvu a aktualizujte pracovný adresár pomocou `git switch`:
1. **Prepnite na pracovnú vetvu**. Prepnite na špecifikovanú vetvu a aktualizujte pracovný adresár pomocou `git switch`:
```bash
git switch [branch-name]
```
1. **Pracujte**. V tomto bode chcete pridať svoje zmeny. Nezabudnite o nich informovať Git pomocou nasledujúcich príkazov:
1. **Pracujte**. V tomto bode chcete pridať svoje zmeny. Nezabudnite o tom informovať Git pomocou nasledujúcich príkazov:
```bash
git add .
git commit -m "my changes"
```
Uistite sa, že svoj commit pomenujete vhodne, pre svoje dobro aj pre správcu úložiska, na ktorom pomáhate.
Uistite sa, že svoj commit pomenovali dobre, pre svoje dobro, ako aj pre správcu úložiska, ktorému pomáhajú.
1. **Spojte svoju prácu s vetvou `main`**. V určitom bode skončíte s prácou a budete chcieť spojiť svoju prácu s tou vo vetve `main`. Vetva `main` sa medzitým mohla zmeniť, takže sa uistite, že ju najskôr aktualizujete na najnovšiu verziu pomocou nasledujúcich príkazov:
1. **Spojte svoju prácu s vetvou `main`**. V určitom bode ste skončili s prácou a chcete spojiť svoju prácu s tou vo vetve `main`. Vetva `main` sa medzitým mohla zmeniť, takže sa uistite, že ju najskôr aktualizujete na najnovšiu pomocou nasledujúcich príkazov:
```bash
git switch main
git pull
```
V tomto bode sa chcete uistiť, že akékoľvek _konflikty_, situácie, kde Git nemôže ľahko _skombinovať_ zmeny, sa vyriešia vo vašej pracovnej vetve. Preto spustite nasledujúce príkazy:
V tomto bode sa chcete uistiť, že akékoľvek _konflikty_, situácie, kde Git nemôže ľahko _spojiť_ zmeny, sa vyskytnú vo vašej pracovnej vetve. Preto spustite nasledujúce príkazy:
```bash
git switch [branch_name]
git merge main
```
Tento príkaz prinesie všetky zmeny z vetvy `main` do vašej vetvy a dúfajme, že budete môcť pokračovať. Ak nie, VS Code vám ukáže, kde je Git _zmätený_, a jednoducho upravíte dotknuté súbory, aby ste určili, ktorý obsah je najpresnejší.
Príkaz `git merge main` prinesie všetky zmeny z `main` do vašej vetvy. Dúfajme, že môžete jednoducho pokračovať. Ak nie, VS Code vám ukáže, kde je Git _zmätený_ a jednoducho upravíte dotknuté súbory, aby ste určili, ktorý obsah je najpresnejší.
Ak chcete prepnúť na inú vetvu, použite moderný príkaz `git switch`:
```bash
git switch [branch_name]
1. **Odošlite svoju prácu na GitHub**. Odošlanie vašej práce na GitHub znamená dve veci. Pushnutie vašej vetvy do vášho úložiska a potom otvorenie PR, Pull Request.
1. **Odošlite svoju prácu na GitHub**. Odoslanie vašej práce na GitHub znamená dve veci. Pushnutie vašej vetvy do vášho úložiska a potom otvorenie PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Vyššie uvedený príkaz vytvorí vetvu vo vašom forknutom úložisku.
Vyššie uvedený príkaz vytvorí vetvu vo vašom forkovanom úložisku.
1. **Otvorte PR**. Ďalej chcete otvoriť PR. Urobíte to tak, že prejdete na forknuté repo na GitHube. Na GitHube uvidíte indikáciu, kde sa vás pýta, či chcete vytvoriť nový PR. Kliknete na to a dostanete sa do rozhrania, kde môžete zmeniť názov správy o commite a pridať vhodnejší popis. Teraz uvidí správca repozitára, ktorý ste forkovali, tento PR a _držme palce_, že ho ocení a _zmerguje_ váš PR. Teraz ste prispievateľ, hurá :)
1. **Otvorte PR**. Ďalej chcete otvoriť PR. Urobíte to tak, že prejdete na forknuté úložisko na GitHube. Na GitHube uvidíte indikáciu, kde sa vás opýta, či chcete vytvoriť nový PR, kliknete na to a dostanete sa do rozhrania, kde môžete zmeniť názov commit správy, dať jej vhodnejší popis. Teraz správca úložiska, ktoré ste forkovali, uvidí tento PR a _držme palce_, že ho ocení a _spojí_ váš PR. Teraz ste prispievateľ, hurá :)
1. **Upracte**. Považuje sa za dobrú prax _upratať_ po úspešnom spojení PR. Chcete upratať svoju lokálnu vetvu aj vetvu, ktorú ste pushli na GitHub. Najskôr ju lokálne odstráňte pomocou nasledujúceho príkazu:
1. **Upratovanie**. Považuje sa za dobrú prax _upratať_ po úspešnom zmergovaní PR. Chcete upratať tak lokálnu vetvu, ako aj vetvu, ktorú ste pushli na GitHub. Najskôr ju lokálne vymažte pomocou nasledujúceho príkazu:
```bash
git branch -d [branch-name]
```
Uistite sa, že prejdete na stránku GitHub pre forknuté úložisko a odstránite vzdialenú vetvu, ktorú ste práve pushli.
`Pull request` sa môže zdať ako zvláštny termín, pretože v skutočnosti chcete svoje zmeny "pushnúť" do projektu. Avšak správca (vlastník projektu) alebo hlavný tím musí vaše zmeny zvážiť predtým, než ich zlúči s "hlavnou" vetvou projektu, takže v podstate žiadate správcu o rozhodnutie o zmene.
Uistite sa, že prejdete na stránku GitHubu pre forknuté repo a odstránite vzdialenú vetvu, ktorú ste práve pushli.
`Pull request` sa môže zdať ako zvláštny termín, pretože v skutočnosti chcete pushnúť svoje zmeny do projektu. Ale správca (vlastník projektu) alebo hlavný tím musí zvážiť vaše zmeny pred ich zmergovaním do "hlavnej" vetvy projektu, takže v skutočnosti žiadate rozhodnutie o zmene od správcu.
Pull request je miesto, kde môžete porovnať a diskutovať o rozdieloch zavedených vo vetve, a to prostredníctvom recenzií, komentárov, integrovaných testov a ďalších nástrojov. Dobrý pull request sa riadi približne rovnakými pravidlami ako správa pri commite. Môžete pridať odkaz na problém v issue trackeri, napríklad keď vaša práca rieši konkrétny problém. Toto sa robí použitím`#` nasledovaného číslom problému. Napríklad `#97`.
Pull request je miesto, kde môžete porovnať a diskutovať o rozdieloch zavedených vo vetve pomocou recenzií, komentárov, integrovaných testov a ďalších nástrojov. Dobrý pull request dodržiava približne rovnaké pravidlá ako správa o commite. Môžete pridať odkaz na problém v issue trackeri, napríklad keď vaša práca rieši konkrétny problém. To sa robí pomocou `#` nasledovaného číslom vášho problému. Napríklad `#97`.
🤞Držíme palce, aby všetky kontroly prešli a vlastníci projektu zlúčili vaše zmeny do projektu🤞
🤞Držme palce, že všetky kontroly prejdú a vlastník(y) projektu zmergujú vaše zmeny do projektu🤞
Aktualizujte svoju aktuálnu lokálnu pracovnú vetvu všetkými novými commitmi z príslušnej vzdialenej vetvy na GitHube:
`git pull`
## Ako prispieť do open source
## Ako prispievať do open source
Najprv si nájdime repozitár (alebo **repo**) na GitHube, ktorý vás zaujíma a do ktorého by ste chceli prispieť zmenou. Budete chcieť skopírovať jeho obsah na svoj počítač.
Najskôr si nájdime repozitár (alebo **repo**) na GitHube, ktorý vás zaujíma a do ktorého by ste chceli prispieť zmenou. Budete chcieť skopírovať jeho obsah na svoj počítač.
✅ Dobrý spôsob, ako nájsť repozitáre vhodné pre začiatočníkov, je [vyhľadávať podľa značky 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Dobrý spôsob, ako nájsť repozitáre vhodné pre začiatočníkov, je [vyhľadávanie podľa tagu 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
@ -294,36 +301,36 @@ Otvorte svoj terminál a klonujte repozitár takto:
Ak chcete pracovať na projekte, prepnite sa do správneho priečinka:
`cd ProjectURL`
Celý projekt môžete otvoriť aj pomocou [Codespaces](https://github.com/features/codespaces), integrovaného editoru kódu / cloudového vývojového prostredia od GitHubu, alebo pomocou [GitHub Desktop](https://desktop.github.com/).
Celý projekt môžete otvoriť aj pomocou [Codespaces](https://github.com/features/codespaces), integrovaného editoru kódu / cloudového vývojového prostredia GitHubu, alebo [GitHub Desktop](https://desktop.github.com/).
Nakoniec si môžete kód stiahnuť v zipovanom priečinku.
Nakoniec si môžete stiahnuť kód v zipovanom priečinku.
### Niekoľko ďalších zaujímavostí o GitHube
### Niekoľko ďalších zaujímavých vecí o GitHube
Na GitHube môžete "hviezdičkovať", sledovať alebo "forkovať" akýkoľvek verejný repozitár. Svoje označené repozitáre nájdete v rozbaľovacom menu v pravom hornom rohu. Je to ako záložky, ale pre kód.
Na GitHube môžete "hviezdičkovať", sledovať a/alebo "forkovať" akýkoľvek verejný repozitár. Svoje hviezdičkované repozitáre nájdete v rozbaľovacom menu v pravom hornom rohu. Je to ako záložky, ale pre kód.
Projekty majú issue tracker, väčšinou na GitHube v záložke "Issues", pokiaľ nie je uvedené inak, kde ľudia diskutujú o problémoch súvisiacich s projektom. Záložka Pull Requests je miestom, kde ľudia diskutujú a recenzujú zmeny, ktoré sú v procese.
Projekty majú issue tracker, väčšinou na GitHube v záložke "Issues", pokiaľ nie je uvedené inak, kde ľudia diskutujú o problémoch súvisiacich s projektom. Záložka Pull Requests je miesto, kde ľudia diskutujú a recenzujú zmeny, ktoré sú v procese.
Projekty môžu mať diskusie vo fórach, mailing listoch alebo chatovacích kanáloch ako Slack, Discord alebo IRC.
✅ Prezrite si svoj nový GitHub repozitár a vyskúšajte niekoľko vecí, ako napríklad úpravu nastavení, pridanie informácií do repozitára a vytvorenie projektu (napríklad Kanban board). Možností je veľa!
✅ Prezrite si svoj nový GitHub repozitár a vyskúšajte niekoľko vecí, ako napríklad úpravu nastavení, pridanie informácií do repozitára a vytvorenie projektu (napríklad Kanban tabuľky). Je toho veľa, čo môžete robiť!
---
## 🚀 Výzva
Spojte sa s priateľom a pracujte na kóde toho druhého. Spoločne vytvorte projekt, forkujte kód, vytvorte vetvy a zlúčte zmeny.
Spojte sa s priateľom a pracujte na kóde jeden druhého. Vytvorte projekt spoločne, forkujte kód, vytvárajte vetvy a zmergujte zmeny.
## Kvíz po prednáške
[Kvíz po prednáške](https://ff-quizzes.netlify.app/web/en/)
## Recenzia a samoštúdium
## Prehľad a samostatné štúdium
Prečítajte si viac o [prispievaní do open source softvéru](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Cvičte, cvičte, cvičte. GitHub ponúka skvelé vzdelávacie cesty dostupné cez [skills.github.com](https://skills.github.com):
Cvičte, cvičte, cvičte. GitHub má skvelé vzdelávacie cesty dostupné cez [skills.github.com](https://skills.github.com):
- [Prvý týždeň na GitHube](https://skills.github.com/#first-week-on-github)
@ -331,9 +338,9 @@ Nájdete tam aj pokročilejšie kurzy.
## Zadanie
Dokončite kurz [Prvý týždeň na GitHube](https://skills.github.com/#first-week-on-github)
Dokončite [kurz Prvý týždeň na GitHube](https://skills.github.com/#first-week-on-github)
---
**Upozornenie**:
Tento dokument bol preložený pomocou služby AI prekladu [Co-op Translator](https://github.com/Azure/co-op-translator). Hoci sa snažíme o presnosť, prosím, berte na vedomie, že automatizované preklady môžu obsahovať chyby alebo nepresnosti. Pôvodný dokument v jeho rodnom jazyku by mal byť považovaný za autoritatívny zdroj. Pre kritické informácie sa odporúča profesionálny ľudský preklad. Nie sme zodpovední za žiadne nedorozumenia alebo nesprávne interpretácie vyplývajúce z použitia tohto prekladu.
Tento dokument bol preložený pomocou služby AI prekladu [Co-op Translator](https://github.com/Azure/co-op-translator). Hoci sa snažíme o presnosť, upozorňujeme, že automatizované preklady môžu obsahovať chyby alebo nepresnosti. Pôvodný dokument v jeho rodnom jazyku by mal byť považovaný za autoritatívny zdroj. Pre kritické informácie sa odporúča profesionálny ľudský preklad. Nenesieme zodpovednosť za akékoľvek nedorozumenia alebo nesprávne interpretácie vyplývajúce z použitia tohto prekladu.
[Kviz pred predavanjem](https://ff-quizzes.netlify.app)
## Predhodni kviz
[Predhodni kviz](https://ff-quizzes.netlify.app)
## Uvod
@ -27,42 +27,43 @@ V tej lekciji bomo obravnavali:
### Predpogoji
Preden začnete, preverite, ali imate nameščen Git. V terminal vnesite:
Preden začnete, preverite, ali je Git nameščen. V terminal vnesite:
`git --version`
Če Git ni nameščen, ga [prenesite](https://git-scm.com/downloads). Nato nastavite svoj lokalni Git profil v terminalu:
Če Git ni nameščen, [prenesite Git](https://git-scm.com/downloads). Nato nastavite svoj lokalni Git profil v terminalu:
* `git config --global user.name "vaše-ime"`
* `git config --global user.email "vaš-email"`
Če želite preveriti, ali je Git že konfiguriran, lahko vnesete:
`git config --list`
Potrebovali boste tudi GitHub račun, urejevalnik kode (na primer Visual Studio Code) in odprt terminal (ali ukazno vrstico).
Potrebovali boste tudi GitHub račun, urejevalnik kode (na primer Visual Studio Code) in odprt terminal (ali ukazni poziv).
Pojdite na [github.com](https://github.com/), ustvarite račun, če ga še nimate, ali se prijavite in izpolnite svoj profil.
Obiščite [github.com](https://github.com/) in ustvarite račun, če ga še nimate, ali se prijavite in izpolnite svoj profil.
✅ GitHub ni edino skladišče kode na svetu; obstajajo tudi druga, vendar je GitHub najbolj znan.
✅ GitHub ni edini repozitorij kode na svetu; obstajajo tudi drugi, vendar je GitHub najbolj poznan.
### Priprava
Potrebovali boste mapo s projektom kode na svojem lokalnem računalniku (prenosniku ali osebnem računalniku) in javno skladišče na GitHubu, ki bo služilo kot primer, kako prispevati k projektom drugih.
Potrebovali boste mapo s projektom kode na svojem lokalnem računalniku (prenosniku ali PC-ju) in javni repozitorij na GitHubu, ki bo služil kot primer, kako prispevati k projektom drugih.
---
## Upravljanje kode
Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojemu napredku z uporabo git-a – sistema za nadzor različic. Nekateri primerjajo uporabo git-a s pisanjem ljubezenskega pisma svojemu prihodnjemu jazu. Ko boste čez dneve, tedne ali mesece brali svoja sporočila o potrditvah (commit messages), se boste lahko spomnili, zakaj ste sprejeli določeno odločitev, ali pa "razveljavili" spremembo – seveda, če pišete dobra sporočila o potrditvah.
Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojemu napredku z uporabo git-a – sistema za nadzor različic. Nekateri primerjajo uporabo git-a s pisanjem ljubezenskega pisma svojemu prihodnjemu jaz-u. Ko boste čez dni, tedne ali mesece prebirali svoja sporočila o potrditvah (commit messages), se boste lahko spomnili, zakaj ste sprejeli določeno odločitev, ali pa "razveljavili" spremembo – seveda, če pišete dobra sporočila o potrditvah.
### Naloga: Ustvarite skladišče in potrdite kodo
### Naloga: Ustvarite repozitorij in potrdite kodo
> Oglejte si video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Ustvarite skladišče na GitHubu**. Na GitHub.com, v zavihku skladišč ali v zgornji desni navigacijski vrstici poiščite gumb **new repo**.
1. Dajte svojemu skladišču (mapi) ime.
1. Izberite **create repository**.
1. **Ustvarite repozitorij na GitHubu**. Na GitHub.com, v zavihku repozitoriji ali v zgornji desni navigacijski vrstici poiščite gumb **nov repozitorij**.
1. Dajte svojemu repozitoriju (mapi) ime.
1. Izberite **ustvari repozitorij**.
1. **Pomaknite se do svoje delovne mape**. V terminalu preklopite na mapo (imenovano tudi imenik), ki ji želite začeti slediti. Vnesite:
@ -70,19 +71,19 @@ Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojem
cd [name of your folder]
```
1. **Inicializirajte git skladišče**. V svojem projektu vnesite:
1. **Inicializirajte git repozitorij**. V svojem projektu vnesite:
```bash
git init
```
1. **Preverite stanje**. Če želite preveriti stanje svojega skladišča, vnesite:
1. **Preverite stanje**. Za preverjanje stanja repozitorija vnesite:
```bash
git status
```
Izhod lahko izgleda nekako takole:
Izpis lahko izgleda nekako takole:
```output
Changes not staged for commit:
@ -93,16 +94,16 @@ Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojem
modified: file2.txt
```
Običajno ukaz `git status` pove stvari, kot so, kateri datoteki so pripravljeni za _shranjevanje_ v skladišče ali imajo spremembe, ki jih morda želite ohraniti.
Običajno ukaz `git status` pove stvari, kot so, kateri datoteki so pripravljeni za _shranjevanje_ v repozitorij ali imajo spremembe, ki jih morda želite ohraniti.
1. **Dodajte vse datoteke za sledenje**
To se imenuje tudi postavljanje datotek/dodajanje datotek v območje priprave.
1. **Dodajte vse datoteke za sledenje**
To se imenuje tudi priprava datotek/dodajanje datotek v pripravljalno območje.
```bash
git add .
```
Ukaz `git add` z argumentom `.` pomeni, da so vse vaše datoteke in spremembe pripravljene za sledenje.
Argument `git add` plus `.` označuje, da so vse vaše datoteke in spremembe pripravljene za sledenje.
1. **Dodajte izbrane datoteke za sledenje**
@ -110,53 +111,53 @@ Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojem
git add [file or folder name]
```
To nam omogoča, da dodamo samo izbrane datoteke v območje priprave, ko ne želimo potrditi vseh datotek hkrati.
To nam omogoča dodajanje samo izbranih datotek v pripravljalno območje, ko ne želimo potrditi vseh datotek naenkrat.
1. **Odstranite vse datoteke iz območja priprave**
1. **Odstranite vse datoteke iz pripravljalnega območja**
```bash
git reset
```
Ta ukaz nam omogoča, da odstranimo vse datoteke iz območja priprave hkrati.
Ta ukaz nam omogoča, da naenkrat odstranimo vse datoteke iz pripravljalnega območja.
1. **Odstranite določeno datoteko iz območja priprave**
1. **Odstranite določeno datoteko iz pripravljalnega območja**
```bash
git reset [file or folder name]
```
Ta ukaz nam omogoča, da odstranimo samo določeno datoteko iz območja priprave, ki je ne želimo vključiti v naslednjo potrditev.
Ta ukaz nam omogoča, da naenkrat odstranimo samo določeno datoteko, ki je ne želimo vključiti v naslednjo potrditev.
1. **Shranjevanje vašega dela**. Na tej točki ste dodali datoteke v tako imenovano _območje priprave_. To je mesto, kjer Git sledi vašim datotekam. Da bi spremembo naredili trajno, morate _potrditi_ datoteke. To storite tako, da ustvarite _potrditev_ z ukazom `git commit`. Potrditev predstavlja točko shranjevanja v zgodovini vašega skladišča. Vnesite naslednje, da ustvarite potrditev:
1. **Ohranite svoje delo**. Na tej točki ste dodali datoteke v tako imenovano _pripravljalno območje_. To je mesto, kjer Git sledi vašim datotekam. Da bi spremembo naredili trajno, morate _potrditi_ datoteke. To storite tako, da ustvarite _potrditev_ z ukazom `git commit`. _Potrditev_ predstavlja točko shranjevanja v zgodovini vašega repozitorija. Vnesite naslednje, da ustvarite _potrditev_:
```bash
git commit -m "first commit"
```
To potrdi vse vaše datoteke in doda sporočilo "first commit". Za prihodnja sporočila o potrditvah boste želeli biti bolj opisni, da boste jasno izrazili, kakšno spremembo ste naredili.
To potrdi vse vaše datoteke in doda sporočilo "prva potrditev". Za prihodnja sporočila o potrditvah boste želeli biti bolj opisni, da boste jasno izrazili, kakšno vrsto spremembe ste naredili.
1. **Povežite svoje lokalno Git skladišče z GitHubom**. Git skladišče je uporabno na vašem računalniku, vendar boste na neki točki želeli imeti varnostno kopijo svojih datotek nekje drugje in povabiti druge ljudi, da sodelujejo z vami na vašem skladišču. Odličen kraj za to je GitHub. Spomnite se, da smo že ustvarili skladišče na GitHubu, zato moramo le še povezati naše lokalno Git skladišče z GitHubom. Ukaz `git remote add` bo to storil. Vnesite naslednji ukaz:
1. **Povežite svoj lokalni Git repozitorij z GitHubom**. Git repozitorij je koristen na vašem računalniku, vendar boste na neki točki želeli imeti varnostno kopijo svojih datotek nekje drugje in povabiti druge ljudi, da delajo z vami na vašem repozitoriju. Ena takšnih odličnih mest za to je GitHub. Spomnite se, da smo že ustvarili repozitorij na GitHubu, zato moramo le povezati naš lokalni Git repozitorij z GitHubom. Ukaz `git remote add` bo to storil. Vnesite naslednji ukaz:
> Opomba: Preden vnesete ukaz, pojdite na stran svojega GitHub skladišča, da poiščete URL skladišča. Uporabili ga boste v spodnjem ukazu. Zamenjajte ```https://github.com/username/repository_name.git``` z vašim GitHub URL-jem.
> Opomba: Preden vnesete ukaz, pojdite na stran svojega GitHub repozitorija, da najdete URL repozitorija. Uporabili ga boste v spodnjem ukazu. Zamenjajte ```https://github.com/username/repository_name.git``` z vašim GitHub URL-jem.
To ustvari _oddaljeno povezavo_ (remote), imenovano "origin", ki kaže na GitHub skladišče, ki ste ga ustvarili prej.
1. **Pošljite lokalne datoteke na GitHub**. Do zdaj ste ustvarili _povezavo_ med lokalnim skladiščem in GitHub skladiščem. Pošljimo te datoteke na GitHub z naslednjim ukazom `git push`, kot sledi:
To ustvari _oddaljeno povezavo_, imenovano "origin", ki kaže na GitHub repozitorij, ki ste ga ustvarili prej.
1. **Pošljite lokalne datoteke na GitHub**. Do sedaj ste ustvarili _povezavo_ med lokalnim repozitorijem in GitHub repozitorijem. Pošljimo te datoteke na GitHub z naslednjim ukazom `git push`, kot sledi:
> Opomba: Vaše ime veje je lahko privzeto drugačno od ```main```.
```bash
git push -u origin main
```
To pošlje vaše potrditve v vašo vejo "main" na GitHub.
To pošlje vaše potrditve v vaši veji "main" na GitHub. Nastavitev veje `upstream`, vključno z `-u` v ukazu, vzpostavi povezavo med vašo lokalno vejo in oddaljeno vejo, tako da lahko v prihodnje preprosto uporabite git push ali git pull brez navedbe imena veje. Git bo samodejno uporabil vejo `upstream` in vam ne bo treba izrecno navesti imena veje v prihodnjih ukazih.
2. **Dodajanje več sprememb**. Če želite nadaljevati z dodajanjem sprememb in njihovim pošiljanjem na GitHub, boste morali uporabiti naslednje tri ukaze:
2. **Dodajte več sprememb**. Če želite nadaljevati z delom in pošiljanjem sprememb na GitHub, boste morali uporabiti naslednje tri ukaze:
```bash
git add .
@ -164,55 +165,57 @@ Recimo, da imate lokalno mapo s projektom kode in želite začeti slediti svojem
git push
```
> Nasvet: Morda boste želeli uporabiti tudi datoteko `.gitignore`, da preprečite, da bi se datoteke, ki jih ne želite slediti, prikazale na GitHubu – na primer beležka, ki jo shranjujete v isti mapi, vendar nima mesta v javnem skladišču. Predloge za `.gitignore` datoteke lahko najdete na [.gitignore templates](https://github.com/github/gitignore).
> Nasvet: Morda boste želeli sprejeti datoteko `.gitignore`, da preprečite, da bi se datoteke, ki jih ne želite slediti, pojavile na GitHubu – na primer tiste beležke, ki jih shranjujete v isti mapi, vendar nimajo mesta v javnem repozitoriju. Predloge za datoteke `.gitignore` lahko najdete na [.gitignore templates](https://github.com/github/gitignore).
#### Sporočila o potrditvah
Odličen naslov sporočila o potrditvi Git dopolni naslednji stavek:
Če se uporabi, bo ta potrditev <vašnaslovsporočilatukaj>.
Odličen naslov sporočila o potrditvi Git-a dopolni naslednji stavek:
Če se uporabi, bo ta potrditev <vašnaslov tukaj>
Za naslov uporabite velelnik v sedanjiku: "spremeni" namesto "spremenil" ali "spreminja".
Kot v naslovu, tudi v telesu (neobvezno) uporabite velelnik v sedanjiku. Telo naj vključuje motivacijo za spremembo in primerjavo s prejšnjim vedenjem. Razlagate `zakaj`, ne `kako`.
Za naslov uporabite ukazni, sedanjik: "spremeni" ne "spremenjeno" ali "spremembe".
Kot pri naslovu, tudi v telesu (neobvezno) uporabite ukazni, sedanjik. Telo naj vključuje motivacijo za spremembo in primerjavo s prejšnjim vedenjem. Pojasnjujete `zakaj`, ne `kako`.
✅ Vzemite si nekaj minut in pobrskajte po GitHubu. Ali lahko najdete res odlično sporočilo o potrditvi? Ali lahko najdete res minimalno? Katere informacije se vam zdijo najpomembnejše in najbolj uporabne za posredovanje v sporočilu o potrditvi?
✅ Vzemite si nekaj minut in pobrskajte po GitHubu. Ali lahko najdete res odlično sporočilo o potrditvi? Ali lahko najdete res minimalno? Katere informacije se vam zdijo najpomembnejše in najbolj koristne za sporočanje v sporočilu o potrditvi?
### Naloga: Sodelovanje
### Naloga: Sodelujte
Glavni razlog za nalaganje stvari na GitHub je omogočiti sodelovanje z drugimi razvijalci.
Glavni razlog za objavo stvari na GitHubu je omogočiti sodelovanje z drugimi razvijalci.
## Delo na projektih z drugimi
> Oglejte si video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
V svojem skladišču pojdite na `Insights > Community`, da vidite, kako se vaš projekt primerja s priporočenimi standardi skupnosti.
V svojem repozitoriju se pomaknite na `Insights > Community`, da vidite, kako se vaš projekt primerja s priporočenimi standardi skupnosti.
Tukaj je nekaj stvari, ki lahko izboljšajo vaše GitHub skladišče:
Tukaj je nekaj stvari, ki lahko izboljšajo vaš GitHub repozitorij:
- **Opis**. Ali ste dodali opis za svoj projekt?
- **README**. Ali ste dodali README? GitHub ponuja smernice za pisanje [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Smernice za prispevanje**. Ali ima vaš projekt [smernice za prispevanje](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kodeks ravnanja**. Ali ima vaš projekt [kodeks ravnanja](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **Licenca**. Morda najpomembneje, ali ima vaš projekt [licenco](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
- **Smernice za prispevanje**. Ali ima vaš projekt [smernice za prispevanje](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Licenca**. Morda najpomembneje, [licenca](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Vsi ti viri bodo koristili pri vključevanju novih članov ekipe. To so običajno stvari, ki jih novi prispevki pregledajo, preden sploh pogledajo vašo kodo, da ugotovijo, ali je vaš projekt pravo mesto za njihovo sodelovanje.
Vsi ti viri bodo koristili pri uvajanju novih članov ekipe. In to so običajno stvari, ki jih novi prispevalci pregledajo, preden sploh pogledajo vašo kodo, da ugotovijo, ali je vaš projekt pravo mesto za njihovo porabo časa.
✅ README datoteke, čeprav zahtevajo čas za pripravo, pogosto zanemarjajo zaposleni vzdrževalci. Ali lahko najdete primer posebej opisnega README-ja? Opomba: Obstajajo nekateri [orodja za pomoč pri ustvarjanju dobrih README-jev](https://www.makeareadme.com/), ki jih morda želite preizkusiti.
✅ README datoteke, čeprav zahtevajo čas za pripravo, pogosto zanemarjajo zaposleni vzdrževalci. Ali lahko najdete primer posebej opisne README datoteke? Opomba: obstajajo nekateri [orodja za pomoč pri ustvarjanju dobrih README datotek](https://www.makeareadme.com/), ki jih morda želite preizkusiti.
### Naloga: Združite nekaj kode
Dokumenti za prispevanje pomagajo ljudem prispevati k projektu. Razložijo, kakšne vrste prispevkov iščete in kako poteka postopek. Prispevki bodo morali opraviti vrsto korakov, da bodo lahko prispevali v vaše skladišče na GitHubu:
Dokumenti za prispevanje pomagajo ljudem prispevati k projektu. Pojasnjujejo, kakšne vrste prispevkov iščete in kako poteka proces. Prispevalci bodo morali opraviti vrsto korakov, da bodo lahko prispevali v vaš repozitorij na GitHubu:
1. **Razvejitev vašega skladišča**. Verjetno boste želeli, da ljudje _razvejijo_ vaš projekt. Razvejitev pomeni ustvarjanje kopije vašega skladišča na njihovem GitHub profilu.
1. **Kloniranje**. Od tam bodo projekt klonirali na svoj lokalni računalnik.
1. **Ustvarjanje veje**. Želeli boste, da ustvarijo _vejo_ za svoje delo.
1. **Osredotočanje na eno področje**. Prosite prispevke, naj se osredotočijo na eno stvar naenkrat – tako bodo večje možnosti, da boste lahko _združili_ njihovo delo. Predstavljajte si, da napišejo odpravo napake, dodajo novo funkcijo in posodobijo več testov – kaj, če želite ali lahko implementirate le 2 od 3 ali 1 od 3 sprememb?
1. **Razvejitev vašega repozitorija**. Verjetno boste želeli, da ljudje _razvejejo_ vaš projekt. Razvejitev pomeni ustvarjanje replike vašega repozitorija na njihovem GitHub profilu.
1. **Kloniranje**. Od tam bodo klonirali projekt na svoj lokalni računalnik.
1. **Ustvarjanje veje**. Želeli boste, da ustvarijo _vejo_ za svoje delo.
1. **Osredotočite spremembo na eno področje**. Prosite prispevalce, naj se osredotočijo na eno stvar naenkrat – tako bodo možnosti, da lahko _združite_ njihovo delo, večje. Predstavljajte si, da napišejo popravek napake, dodajo novo funkcijo in posodobijo več testov – kaj, če želite ali lahko implementirate le 2 od 3 ali 1 od 3 sprememb?
✅ Predstavljajte si situacijo, kjer so veje še posebej ključne za pisanje in dostavo dobre kode. Katere primere uporabe si lahko zamislite?
> Opomba: Bodite sprememba, ki jo želite videti v svetu, in ustvarite veje tudi za svoje delo. Vse potrditve, ki jih naredite, bodo narejene na veji, na kateri ste trenutno "prijavljeni". Uporabite `git status`, da vidite, na kateri veji ste.
> Opomba: Bodite sprememba, ki jo želite videti v svetu, in ustvarite veje za svoje delo. Vsaka potrditev, ki jo naredite, bo narejena na veji, na kateri ste trenutno "prijavljeni". Uporabite `git status`, da vidite, na kateri veji ste.
Pojdimo skozi potek dela prispevka. Predpostavimo, da je prispevek že _razvejal_ in _kloniral_ skladišče, tako da ima Git skladišče pripravljeno za delo na svojem lokalnem računalniku:
Pojdimo skozi potek dela prispevalca. Predpostavimo, da je prispevalec že _razvejal_ in _kloniral_ repozitorij, tako da ima Git repozitorij pripravljen za delo na svojem lokalnem računalniku:
1. **Ustvarite vejo**. Uporabite ukaz `git branch`, da ustvarite vejo, ki bo vsebovala spremembe, ki jih nameravate prispevati:
@ -233,54 +236,58 @@ Pojdimo skozi potek dela prispevka. Predpostavimo, da je prispevek že _razvejal
git commit -m "my changes"
```
Poskrbite, da boste svoji potrditvi dali dobro ime, tako za vas kot za vzdrževalca skladišča, ki mu pomagate.
Poskrbite, da boste svoji potrditvi dali dobro ime, za vaše dobro in za dobro vzdrževalca repozitorija, ki mu pomagate.
1. **Združite svoje delo z vejo `main`**. Na neki točki ste končali z delom in želite združiti svoje delo z vejo`main`. Veja `main` se je medtem morda spremenila, zato se prepričajte, da jo najprej posodobite na najnovejšo različico z naslednjimi ukazi:
1. **Združite svoje delo z vejo `main`**. Na neki točki ste končali z delom in želite združiti svoje delo z delom veje`main`. Veja `main` se je medtem morda spremenila, zato se prepričajte, da jo najprej posodobite na najnovejšo različico z naslednjimi ukazi:
```bash
git switch main
git pull
```
Na tej točki želite zagotoviti, da se morebitni _konflikti_, situacije, kjer Git ne more enostavno_združiti_ sprememb, zgodijo v vaši delovni veji. Zato zaženite naslednje ukaze:
Na tej točki želite zagotoviti, da se morebitni _konflikti_, situacije, kjer Git ne more zlahka_združiti_ sprememb, zgodijo v vaši delovni veji. Zato zaženite naslednje ukaze:
```bash
git switch [branch_name]
git merge main
```
To bo prineslo vse spremembe iz `main` v vašo vejo in upajmo, da boste lahko nadaljevali. Če ne, vam bo VS Code pokazal, kje je Git _zmeden_, in preprosto spremenite prizadete datoteke, da poveste, katera vsebina je najbolj točna.
Ukaz `git merge main` bo prinesel vse spremembe iz `main` v vašo vejo. Upajmo, da lahko preprosto nadaljujete. Če ne, vam bo VS Code povedal, kje je Git _zmeden_, in preprosto spremenite prizadete datoteke, da določite, katera vsebina je najbolj natančna.
1. **Pošljite svoje delo na GitHub**. Pošiljanje vašega dela na GitHub pomeni dve stvari. Potisnite svojo vejo v svoje skladišče in nato odprite PR (Pull Request).
Za preklop na drugo vejo uporabite sodobni ukaz `git switch`:
```bash
git switch [branch_name]
1. **Pošljite svoje delo na GitHub**. Pošiljanje vašega dela na GitHub pomeni dve stvari. Potiskanje vaše veje v vaš repozitorij in nato odpiranje PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Zgornji ukaz ustvari vejo na vašem razvejanem skladišču.
Zgornji ukaz ustvari vejo v vašem razvejanem repozitoriju.
1. **Odpri PR**. Naslednji korak je, da odpreš PR. To storiš tako, da odpreš forkan repozitorij na GitHubu. Na GitHubu boš videl oznako, ki te vpraša, ali želiš ustvariti nov PR. Klikneš nanjo in preusmerjen boš na vmesnik, kjer lahko spremeniš naslov sporočila o potrditvi (commit message), dodaš bolj ustrezen opis. Zdaj bo vzdrževalec repozitorija, ki si ga forkal, videl ta PR in _držimo pesti_, da ga bo cenil in _združil_ (merge) tvoj PR. Zdaj si prispeval k projektu, juhu! :)
1. **Odprite PR**. Nato želite odpreti PR. To storite tako, da se pomaknete do razvejanega skladišča na GitHubu. Videli boste oznako na GitHubu, kjer vas vpraša, ali želite ustvariti nov PR, kliknete to in preusmerjeni boste na vmesnik, kjer lahko spremenite naslov sporočila o potrditvi, mu daste bolj ustrezen opis. Zdaj bo vzdrževalec skladišča, ki ste ga razvejali, videl ta PR in _držimo pesti_, da bo cenil in _združil_ vaš PR. Zdaj ste prispevalec, juhu :)
1. **Počistite**. Šteje se za dobro prakso, da _počistite_ po uspešnem združevanju PR. Želite počistiti tako svojo lokalno vejo kot vejo, ki ste jo potisnili na GitHub. Najprej jo izbrišite lokalno z naslednjim ukazom:
1. **Počisti**. Velja za dobro prakso, da _počistiš_ po uspešnem združevanju PR. Počistiti moraš tako lokalno vejo kot vejo, ki si jo potisnil na GitHub. Najprej jo izbriši lokalno z naslednjim ukazom:
```bash
git branch -d [branch-name]
```
Prepričajte se, da greste na stran GitHub za razvejano skladišče in odstranite oddaljeno vejo, ki ste jo pravkar potisnili.
`Pull request` se morda zdi nenavadna besedna zveza, saj v resnici želite potisniti svoje spremembe v projekt. Vendar mora vzdrževalec (lastnik projekta) ali osrednja ekipa najprej preučiti vaše spremembe, preden jih združi z "glavno" vejo projekta, zato v bistvu zahtevate odločitev o spremembi od vzdrževalca.
Nato pojdi na GitHub stran forkanega repozitorija in odstrani oddaljeno vejo, ki si jo pravkar potisnil nanj.
`Pull request` se morda zdi nenavadna fraza, saj v resnici želiš potisniti svoje spremembe v projekt. Vendar mora vzdrževalec (lastnik projekta) ali osrednja ekipa najprej preučiti tvoje spremembe, preden jih združi z "glavno" vejo projekta, zato v bistvu zahtevaš odločitev o spremembi od vzdrževalca.
Pull request je mesto, kjer primerjate in razpravljate o razlikah, ki jih uvaja veja, z ocenami, komentarji, integriranimi testi in še več. Dober pull request sledi približno istim pravilom kot sporočilo ob commitu. Lahko dodate referenco na težavo v sledilniku težav, na primer, ko vaše delo odpravi določeno težavo. To storite z uporabo `#`, ki mu sledi številka vaše težave. Na primer `#97`.
Pull request je prostor za primerjavo in razpravo o razlikah, ki jih uvaja veja, z ocenami, komentarji, integriranimi testi in še več. Dober pull request sledi približno enakim pravilom kot sporočilo o potrditvi (commit message). Lahko dodaš referenco na težavo v sledilniku težav, na primer, ko tvoje delo odpravi težavo. To storiš z uporabo `#`, ki mu sledi številka težave. Na primer `#97`.
🤞Držimo pesti, da vsi pregledi uspejo in da lastnik(i) projekta združijo vaše spremembe v projekt🤞
🤞Držimo pesti, da vsi pregledi uspešno opravijo in da lastnik(i) projekta združijo tvoje spremembe v projekt🤞
Posodobite svojo trenutno lokalno delovno vejo z vsemi novimi commit-i iz ustrezne oddaljene veje na GitHubu:
Posodobi svojo trenutno lokalno delovno vejo z vsemi novimi potrditvami iz ustrezne oddaljene veje na GitHubu:
`git pull`
## Kako prispevati k odprtokodni programski opremi
## Kako prispevati k odprti kodi
Najprej poiščimo repozitorij (ali **repo**) na GitHubu, ki vas zanima in h kateremu želite prispevati spremembo. Njegovo vsebino boste želeli kopirati na svoj računalnik.
Najprej poiščimo repozitorij (ali **repo**) na GitHubu, ki te zanima in k kateremu bi rad prispeval spremembo. Njegovo vsebino boš želel kopirati na svoj računalnik.
✅ Dober način za iskanje repozitorijev, prijaznih začetnikom, je [iskanje po oznaki 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
@ -288,42 +295,42 @@ Najprej poiščimo repozitorij (ali **repo**) na GitHubu, ki vas zanima in h kat
Obstaja več načinov za kopiranje kode. Eden od načinov je "kloniranje" vsebine repozitorija z uporabo HTTPS, SSH ali GitHub CLI (Command Line Interface).
Odprite terminal in klonirajte repozitorij na naslednji način:
Odpri terminal in kloniraj repozitorij na naslednji način:
`git clone https://github.com/ProjectURL`
Za delo na projektu preklopite v ustrezno mapo:
Za delo na projektu preklopi v ustrezno mapo:
`cd ProjectURL`
Celoten projekt lahko odprete tudi z [Codespaces](https://github.com/features/codespaces), vgrajenim urejevalnikom kode / oblačnim razvojnim okoljem GitHuba, ali z [GitHub Desktop](https://desktop.github.com/).
Celoten projekt lahko odpreš tudi z [Codespaces](https://github.com/features/codespaces), vgrajenim urejevalnikom kode / oblačnim razvojnim okoljem GitHuba, ali z [GitHub Desktop](https://desktop.github.com/).
Nazadnje lahko kodo prenesete v stisnjeni mapi.
Nazadnje lahko kodo preneseš v stisnjeni mapi.
### Nekaj zanimivosti o GitHubu
Na GitHubu lahko označite z zvezdico, spremljate ali "forkate" kateri koli javni repozitorij. Svoje označene repozitorije najdete v spustnem meniju zgoraj desno. To je kot zaznamovanje, vendar za kodo.
Na GitHubu lahko označiš z zvezdico, spremljaš ali "forkaš" kateri koli javni repozitorij. Svoje označene repozitorije najdeš v spustnem meniju zgoraj desno. To je kot zaznamovanje, vendar za kodo.
Projekti imajo sledilnik težav, večinoma na GitHubu v zavihku "Issues", razen če ni navedeno drugače, kjer ljudje razpravljajo o težavah, povezanih s projektom. Zavihek Pull Requests je mesto, kjer ljudje razpravljajo in ocenjujejo spremembe, ki so v teku.
Projekti imajo sledilnik težav, večinoma na GitHubu v zavihku "Issues", razen če je navedeno drugače, kjer ljudje razpravljajo o težavah, povezanih s projektom. Zavihek Pull Requests je mesto, kjer ljudje razpravljajo in ocenjujejo spremembe, ki so v teku.
Projekti imajo lahko tudi razprave v forumih, poštnih seznamih ali komunikacijskih kanalih, kot so Slack, Discord ali IRC.
Projekti imajo lahko tudi razprave v forumih, poštnih seznamih ali klepetalnicah, kot so Slack, Discord ali IRC.
✅ Razglejte se po svojem novem GitHub repozitoriju in preizkusite nekaj stvari, kot so urejanje nastavitev, dodajanje informacij v repozitorij in ustvarjanje projekta (na primer Kanban deske). Možnosti je veliko!
✅ Razglej se po svojem novem GitHub repozitoriju in preizkusi nekaj stvari, kot so urejanje nastavitev, dodajanje informacij v repozitorij in ustvarjanje projekta (na primer Kanban tabla). Možnosti je veliko!
---
## 🚀 Izziv
Sodelujte s prijateljem pri delu na kodi drug drugega. Skupaj ustvarite projekt, forkajte kodo, ustvarite veje in združite spremembe.
Sodeluj s prijateljem pri delu na medsebojni kodi. Ustvarita projekt skupaj, forkajta kodo, ustvarita veje in združita spremembe.
## Kviz po predavanju
[Kviz po predavanju](https://ff-quizzes.netlify.app/web/en/)
## Pregled in samostojno učenje
Preberite več o [prispevanju k odprtokodni programski opremi](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Preberi več o [prispevanju k odprtokodni programski opremi](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Vadite, vadite, vadite. GitHub ponuja odlične učne poti prek [skills.github.com](https://skills.github.com):
Vadi, vadi, vadi. GitHub ima odlične učne poti, ki so na voljo prek [skills.github.com](https://skills.github.com):
- [Prvi teden na GitHubu](https://skills.github.com/#first-week-on-github)
@ -331,9 +338,9 @@ Na voljo so tudi bolj napredni tečaji.
## Naloga
Dokončajte [tečaj Prvi teden na GitHubu](https://skills.github.com/#first-week-on-github).
Dokončaj [tečaj Prvi teden na GitHubu](https://skills.github.com/#first-week-on-github)
---
**Omejitev odgovornosti**:
Ta dokument je bil preveden z uporabo storitve za strojno prevajanje [Co-op Translator](https://github.com/Azure/co-op-translator). Čeprav si prizadevamo za natančnost, vas opozarjamo, da lahko avtomatizirani prevodi vsebujejo napake ali netočnosti. Izvirni dokument v njegovem izvirnem jeziku je treba obravnavati kot avtoritativni vir. Za ključne informacije priporočamo strokovno človeško prevajanje. Ne prevzemamo odgovornosti za morebitna nesporazumevanja ali napačne razlage, ki bi nastale zaradi uporabe tega prevoda.
Ta dokument je bil preveden z uporabo storitve AI za prevajanje [Co-op Translator](https://github.com/Azure/co-op-translator). Čeprav si prizadevamo za natančnost, vas prosimo, da upoštevate, da lahko avtomatizirani prevodi vsebujejo napake ali netočnosti. Izvirni dokument v njegovem maternem jeziku je treba obravnavati kot avtoritativni vir. Za ključne informacije priporočamo profesionalni človeški prevod. Ne prevzemamo odgovornosti za morebitna nesporazumevanja ali napačne razlage, ki izhajajo iz uporabe tega prevoda.
Ова лекција покрива основе GitHub-а, платформе за хостовање и управљање променама у вашем коду.
Ова лекција покрива основе GitHub-а, платформе за хостовање и управљање изменама у вашем коду.
> Скетч од [Tomomi Imura](https://twitter.com/girlie_mac)
@ -21,20 +21,20 @@ CO_OP_TRANSLATOR_METADATA:
У овој лекцији ћемо обрадити:
- праћење рада који обављате на вашем рачунару
- праћење рада на вашем рачунару
- рад на пројектима са другима
- како допринети софтверу отвореног кода
### Предуслови
Пре него што почнете, проверите да ли је Git инсталиран. У терминалу укуцајте:
Пре него што почнете, потребно је да проверите да ли је Git инсталиран. У терминалу укуцајте:
`git --version`
Ако Git није инсталиран, [преузмите Git](https://git-scm.com/downloads). Затим подесите свој локални Git профил у терминалу:
* `git config --global user.name "ваше-име"`
* `git config --global user.email "ваш-имејл"`
Да бисте проверили да ли је Git већ конфигурисан, можете укуцати:
Да бисте проверили да ли је Git већ конфигурисан, можете укуцати:
`git config --list`
Такође ће вам бити потребан GitHub налог, едитор за код (као што је Visual Studio Code), и потребно је да отворите терминал (или командну линију).
@ -45,26 +45,26 @@ CO_OP_TRANSLATOR_METADATA:
### Припрема
Биће вам потребан фолдер са код пројектом на вашем локалном рачунару (лаптопу или ПЦ-у) и јавни репозиторијум на GitHub-у, који ће служити као пример како допринети пројектима других.
Потребан вам је фолдер са код пројектом на вашем локалном рачунару (лаптопу или десктопу) и јавни репозиторијум на GitHub-у, који ће служити као пример за то како допринети пројектима других.
---
## Управљање кодом
Претпоставимо да имате фолдер локалноса неким код пројектом и желите да почнете да пратите свој напредак користећи git - систем за контролу верзија. Неки људи пореде коришћење git-аса писањем љубавног писма свом будућем себи. Читајући поруке о комитима након неколико дана, недеља или месеци, моћи ћете да се сетите зашто сте донели одређену одлуку или да "вратите" промену - под условом да пишете добре поруке о комитима.
Рецимо да имате локални фолдерса неким код пројектом и желите да почнете да пратите свој напредак користећи git - систем за контролу верзија. Неки људи пореде коришћење git-аса писањем љубавног писма себи у будућности. Читајући своје поруке о изменама (commit messages) данима, недељама или месецима касније, моћи ћете да се сетите зашто сте донели одређену одлуку или да "вратите" промену - то јест, ако пишете добре поруке о изменама.
### Задатак: Направите репозиторијум и комитујте код
### Задатак: Направите репозиторијум и сачувајте код
> Погледајте видео
> Погледајте видео
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Направите репозиторијум на GitHub-у**. На GitHub.com, у картици репозиторијума или из навигационог менија у горњем десном углу, пронађите дугме **new repo**.
1. **Направите репозиторијум на GitHub-у**. На GitHub.com, у картици репозиторијума или из горње десне навигационе траке, пронађите дугме **new repo**.
1. Дајте свом репозиторијуму (фолдеру) име.
1. Изаберите **create repository**.
1. **Пребаците сеу свој радни фолдер**. У терминалу, промените директоријум на фолдер који желите да почнете да пратите. Укуцајте:
1. **Навигирајте до свог радног фолдера**. У вашем терминалу, пребаците сеу фолдер (такође познат као директоријум) који желите да почнете да пратите. Укуцајте:
```bash
cd [name of your folder]
@ -82,7 +82,7 @@ CO_OP_TRANSLATOR_METADATA:
git status
```
Излаз може изгледати овако:
излаз може изгледати овако:
```output
Changes not staged for commit:
@ -93,16 +93,16 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
Типично, команда `git status` вам говори, на пример, који фајлови су спремни за _чување_у репозиторијуму или имају промене које можда желите да сачувате.
Обично команда `git status` говори ствари као што су који фајлови су спремни за _чување_у репозиторијуму или имају измене које можда желите да сачувате.
1. **Додајте све фајлове за праћење**
Ово се такође назива стаговање фајлова/додавање фајлова устагинг зону.
Ово се такође назива постављање фајлова/додавање фајлова уобласт за постављање.
```bash
git add .
```
Команда `git add`са аргументом `.` означава да су сви ваши фајлови и промене спремни за праћење.
`git add`са аргументом `.` означава да су сви ваши фајлови и измене спремни за праћење.
1. **Додајте одабране фајлове за праћење**
@ -110,53 +110,53 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
Ово нам помаже да додамо само одабране фајлове устагинг зону када не желимо да комитујемо све фајлове одједном.
Ово нам помаже да додамо само одабране фајлове уобласт за постављање када не желимо да сачувамо све фајлове одједном.
1. **Уклони све фајлове из стагинг зоне**
1. **Уклони све фајлове из области за постављање**
```bash
git reset
```
Ова команда нам помаже да уклонимо све фајлове из стагинг зоне одједном.
Ова команда нам помаже да уклонимо све фајлове из области за постављање одједном.
1. **Уклони одређени фајл из стагинг зоне**
1. **Уклони одређени фајл из области за постављање**
```bash
git reset [file or folder name]
```
Ова команда нам помаже да уклонимо само одређени фајл из стагинг зоне који не желимо да укључимо у следећи комит.
Ова команда нам помаже да уклонимо само одређени фајл из области за постављање који не желимо да укључимо у следеће чување.
1. **Сачувајте свој рад**. У овом тренутку сте додали фајлове у такозвану _стагинг зону_. Тоје место где Git прати ваше фајлове. Да бисте промену учинили трајном, потребно је да _комитујете_ фајлове. Да бисте то урадили, креирајте _комит_ командом `git commit`. Комит представља тачку чувања у историји вашег репозиторијума. Укуцајте следеће да бисте креирали _комит_:
1. **Сачувајте свој рад**. У овом тренутку сте додали фајлове у такозвану _област за постављање_. Место где Git прати ваше фајлове. Да бисте учинили промену трајном, потребно је да _сачувате_ фајлове. Да бисте то урадили, креирате _измену_ (commit) командом `git commit`. _Измена_ представља тачку чувања у историји вашег репозиторијума. Укуцајте следеће да бисте креирали _измену_:
```bash
git commit -m "first commit"
```
Ово комитује све ваше фајлове, додајући поруку "first commit". За будуће поруке окомитима, желећете да будете описнији како бисте пренели какву сте промену направили.
Ово чува све ваше фајлове, додајући поруку "first commit". За будуће поруке о изменама, желећете да будете описнијиу свом опису како бисте пренели какву сте промену направили.
1. **Повежите свој локални Git репозиторијум са GitHub-ом**. Git репозиторијум је добар на вашем рачунару, али у неком тренутку ћете желети да направите резервну копију својих фајлова негде и такође позовете друге људе да раде са вама на вашем репозиторијуму. Једно одлично место за то је GitHub. Сетите се да смо већ креирали репозиторијум на GitHub-у, тако да је једино што треба да урадимо да повежемо наш локални Git репозиторијум са GitHub-ом. Команда `git remote add` ће то урадити. Укуцајте следећу команду:
1. **Повежите свој локални Git репозиторијум са GitHub-ом**. Git репозиторијум је добар на вашем рачунару, али у неком тренутку желите да имате резервну копију ваших фајлова негде и такође позовете друге људе да раде са вама на вашем репозиторијуму. Једно такво одлично место за то је GitHub. Запамтите да смо већ креирали репозиторијум на GitHub-у, тако да је једино што треба да урадимо да повежемо наш локални Git репозиторијум са GitHub-ом. Команда `git remote add` ће то урадити. Укуцајте следећу команду:
> Напомена: Пре него што укуцате команду, идите на страницу вашег GitHub репозиторијума да бисте пронашли URL репозиторијума. Користићете гау команди испод. Замените ```https://github.com/username/repository_name.git``` са вашим GitHub URL-ом.
> Напомена, пре него што укуцате команду, идите на страницу вашег GitHub репозиторијума да бисте пронашли URL репозиторијума. Користићете гаунаредној команди. Замените ```https://github.com/username/repository_name.git``` са вашим GitHub URL-ом.
Ово креира _remote_, или везу, под именом "origin" која показује на GitHub репозиторијум који сте раније креирали.
Ово креира _remote_, или везу, названу "origin" која показује на GitHub репозиторијум који сте раније креирали.
1. **Пошаљите локалне фајлове на GitHub**. До сада сте креирали _везу_ између локалног репозиторијума и GitHub репозиторијума. Хајде да пошаљемо ове фајлове на GitHub следећом командом `git push`, овако:
> Напомена: Име ваше гране може бити другачије од ```main```.
1. **Пошаљите локалне фајлове на GitHub**. До сада сте креирали _везу_ између локалног репозиторијума и GitHub репозиторијума. Хајде да пошаљемо ове фајлове на GitHub следећом командом `git push`, овако:
> Напомена, име ваше гране може бити другачије од ```main```.
```bash
git push -u origin main
```
Ово шаље ваше комитове у вашу "main" грану на GitHub-у.
Ово шаље ваше измене у вашој "main" грани на GitHub. Постављање `upstream` гране укључујући `-u`у команди успоставља везу између ваше локалне гране и удаљене гране, тако да можете једноставно користити git push или git pull без навођења имена гране у будућности. Git ће аутоматски користити upstream грану и нећете морати експлицитно да наводите име гране у будућим командама.
2. **Додајте још промена**. Ако желите да наставите са прављењем промена и њиховим слањем на GitHub, само ћете морати да користите следеће три команде:
2. **Да додате још измена**. Ако желите да наставите са прављењем измена и њиховим слањем на GitHub, само ћете морати да користите следеће три команде:
```bash
git add .
@ -164,57 +164,57 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> Савет: Можда ћете желети да усвојите `.gitignore` фајл како бисте спречили да се фајлови које не желите да пратите појаве на GitHub-у - као што јеонај фајл са белешкама који чувате у истом фолдеру, али нема место у јавном репозиторијуму. Можете пронаћи шаблоне за `.gitignore` фајлове на [.gitignore templates](https://github.com/github/gitignore).
> Савет, Можда ћете желети да усвојите `.gitignore` фајл како бисте спречили да се фајлови које не желите да пратите појаве на GitHub-у - као што јетај фајл са белешкама који чувате у истом фолдеру, али нема место у јавном репозиторијуму. Можете пронаћи шаблоне за `.gitignore` фајлове на [.gitignore templates](https://github.com/github/gitignore).
#### Поруке окомитима
#### Поруке о изменама
Одлична порука окомиту треба да заврши следећу реченицу:
Ако се примени, овај комит ће <ваша порука овде>.
Одлична порука оGit измени завршава следећу реченицу:
Ако се примени, ова измена ће <ваша порука овде>
Занаслов користите императив, садашње време: "промени" уместо "промењено" или "мења".
Као и унаслову, у телу (опционо) такође користите императив, садашње време. Тело треба да укључи мотивацију за промену и упореди јеса претходним понашањем. Објашњавате `зашто`, а не `како`.
Запоруку користите императив, садашње време: "промени" уместо "променио" или "промена".
Као и упоруци, у телу (опционо) такође користите императив, садашње време. Тело треба да укључи мотивацију за промену и упореди јеса претходним понашањем. Објашњавате `зашто`, а не `како`.
✅ Одвојите неколико минута да прегледате GitHub. Можете ли пронаћи заиста добру поруку о комиту? Можете ли пронаћи заиста минималну? Које информације мислите да су најважније и најкорисније за преношење у поруци окомиту?
✅ Одвојите неколико минута да истражите GitHub. Можете ли пронаћи заиста добру поруку о измени? Можете ли пронаћи заиста минималну? Које информације мислите да су најважније и најкорисније за преношење у поруци оизмени?
### Задатак: Сарадња
### Задатак: Сарађујте
Главни разлог за постављање ствари на GitHub био је да се омогући сарадња са другим програмерима.
Главни разлог за постављање ствари на GitHub је да се омогући сарадња са другим програмерима.
## Рад на пројектима са другима
> Погледајте видео
> Погледајте видео
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
У вашем репозиторијуму, идите на `Insights > Community` да видите како ваш пројекат стоји уодносу на препоручене стандарде заједнице.
У вашем репозиторијуму, идите на `Insights > Community` да видите како ваш пројекат стоји упоређењу са препорученим стандардима за заједницу.
Ево неких ствари које могу побољшати ваш GitHub репозиторијум:
- **Опис**. Да ли сте додали опис за ваш пројекат?
- **README**. Да ли сте додали README? GitHub пружа смернице за писање [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/)?
Ево неких ствари које могу побољшати ваш GitHub репозиторијум:
- **Опис**. Да ли сте додали опис за ваш пројекат?
- **README**. Да ли сте додали README? GitHub пружа смернице за писање [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-а](https://www.makeareadme.com/) које бисте можда желели да испробате.
✅ README фајлови, иако захтевају време за припрему, често се занемарују од стране заузетих одржавалаца. Можете ли пронаћи пример посебно описног README-а? Напомена: постоје неки [алати за креирање добрих README-ова](https://www.makeareadme.com/) које бисте могли да испробате.
### Задатак: Спојите код
Документација за доприносе помаже људима да допринесу пројекту. Она објашњава које врсте доприноса тражите и како процес функционише. Доприносиоци ће морати да прођу кроз низ корака како би могли да допринесу вашем репозиторијуму на GitHub-у:
Документација о доприносу помаже људима да допринесу пројекту. Она објашњава које врсте доприноса тражите и како процес функционише. Доприносиоци ће морати да прођу кроз низ корака да би могли да допринесу вашем репозиторијуму на GitHub-у:
1. **Форковање вашег репозиторијума**. Вероватно ћете желети да људи _форкују_ ваш пројекат. Форковање значи креирање реплике вашег репозиторијума на њиховом GitHub профилу.
1. **Клонирање**. Након тога ће клонирати пројекат на свој локални рачунар.
1. **Fork вашег репозиторијума**. Вероватно ћете желети да људи _fork-ују_ ваш пројекат. Fork значи креирање реплике вашег репозиторијума на њиховом GitHub профилу.
1. **Clone**. Одатле ће клонирати пројекат на свој локални рачунар.
1. **Креирање гране**. Желите да их замолите да креирају _грану_ за свој рад.
1. **Фокусирање на једну област**. Замолите доприносиоце да секонцентришу на једну ствар у исто време - на тај начин сувеће шансе да можете _спојити_ њихов рад. Замислите да напишу исправку грешке, додају нову функцију и ажурирају неколико тестова - шта ако желите да имплементирате само 2 од 3 или 1 од 3 промене?
1. **Фокусирање измена на једну област**. Замолите доприносиоце да концентришу своје доприносе на једну ствар у исто време - на тај начин су шансе да можете _спојити_ њихов рад веће. Замислите да напишу исправку грешке, додају нову функцију и ажурирају неколико тестова - шта ако желите или можете да имплементирате само 2 од 3 или 1 од 3 измене?
✅ Замислите ситуацију у којој су гране посебно критичне за писање и испоруку доброг кода. Које случајеве употребе можете замислити?
> Напомена: Будите промена коју желите да видите у свету и креирајте гране за свој рад. Сви комитови које направите биће направљени на грани на којој сте тренутно "чековани". Користите `git status` да видите на којој сте грани.
> Напомена, будите промена коју желите да видите у свету и креирајте гране за свој рад. Све измене које направите биће направљене на грани на којој сте тренутно "checked out". Користите `git status` да видите на којој гранисе налазите.
Хајде да прођемо кроз процес рада доприносиоца. Претпоставимо да је доприносилац већ _форковао_ и _клонирао_ репозиторијум, тако да има Git репозиторијум спреман за рад на свом локалном рачунару:
Хајде да прођемо кроз процес рада доприносиоца. Претпоставимо да је доприносилац већ _fork-овао_ и _клонирао_ репозиторијум, тако да има Git репозиторијум спреман за рад на свом локалном рачунару:
1. **Креирање гране**. Користите команду `git branch` да креирате грану која ће садржати промене које желите да допринесете:
1. **Креирање гране**. Користите команду `git branch` да креирате грану која ће садржати измене које намеравају да допринесу:
```bash
git branch [branch-name]
@ -226,87 +226,94 @@ CO_OP_TRANSLATOR_METADATA:
git switch [branch-name]
```
1. **Радите на променама**. У овом тренутку желите да додате своје промене. Не заборавите да обавестите Gitо томе следећим командама:
1. **Радите на изменама**. У овом тренутку желите да додате своје измене. Не заборавите да кажете Git-уо томе следећим командама:
```bash
git add .
git commit -m "my changes"
```
Уверите се да сте дали добар назив свом комиту, како за себе тако и за одржаваоца репозиторијума коме помажете.
Уверите се да сте дали добро име својој измени, за ваше добро као и за добро одржаваоца репозиторијума на којем помажете.
1. **Комбинујте свој рад са`main` граном**. У неком тренутку завршавате рад и желите да комбинујете свој рад са оним из `main` гране. `Main` грана је можда у међувремену промењена, па се уверите да сте је прво ажурирали на најновију верзију следећим командама:
1. **Спојите свој рад са`main` граном**. У неком тренутку сте завршили са радом и желите да спојите свој рад са оним из `main` гране. `main` грана је можда промењена у међувремену, па се уверите да сте је прво ажурирали на најновију верзију следећим командама:
```bash
git switch main
git pull
```
У овом тренутку желите да се уверите да се сви _конфликти_, ситуације у којима Git не може лако да _комбинује_ промене, дешавају у вашој радној грани. Због тога покрените следеће команде:
У овом тренутку желите да се уверите да се сви _конфликти_, ситуације у којима Git не може лако да _споји_ измене, дешавају у вашој радној грани. Зато покрените следеће команде:
```bash
git switch [branch_name]
git merge main
```
Ово ће унети све промене из `main` гране у вашу грану и, надамо се, можете само наставити. Ако не, VS Code ће вам показати где је Git _збуњен_, а ви само измените погођене фајлове како бисте рекли који садржај је најтачнији.
Команда `git merge main` ће донети све измене из `main` гране у вашу грану. Надамо се да можете само наставити. Ако не, VS Code ће вам рећи где је Git _збуњен_ и само измените погођене фајлове да бисте навели који садржај је најтачнији.
Да бисте се пребацили на другу грану, користите модерну команду `git switch`:
```bash
git switch [branch_name]
1. **Пошаљите свој рад на GitHub**. Слање вашег рада на GitHub подразумева две ствари. Гурање ваше гране на ваш репозиторијум и затим отварање PR-а (Pull Request).
1. **Пошаљите свој рад на GitHub**. Слање вашег рада на GitHub подразумева две ствари.
1. **Отворите PR**. Следећи корак је да отворите PR. То радите тако што одете на форковани репозиторијум на GitHub-у. На GitHub-у ћете видети опцију која вас пита да ли желите да креирате нови PR, кликнете на то и бићете преусмерени на интерфејс где можете променити наслов поруке комита, додати прикладнији опис. Сада ће одржавалац репозиторијума који сте форковали видети овај PR и _држимо палчеве_ да ће га ценити и _спојити_ ваш PR. Сада сте сарадник, ура! :)
1. **Очистите**. Сматра се добром праксом да _очистите_ након што успешно спојите PR. Треба да очистите и локалну грану и грану коју сте послали на GitHub. Прво је избришите локално помоћу следеће команде:
```bash
git push --set-upstream origin [branch-name]
git branch -d [branch-name]
```
Затим идите на GitHub страницу форкованог репозиторијума и уклоните удаљену грану коју сте управо послали.
Горња команда креира грану на вашем форкованом репозиторијуму.
1. **Отворите PR**. Затим, желите да отворите PR. То радите тако што одете на форковани репозиторијум на GitHub-у. Видећете индикацију на GitHub-у где вас пита да ли желите да креирате нови PR, кликнете на то и бићете одведени
`Pull request` изгледа као смешан термин јеру ствари желите да "пушујете" своје измене у пројекат. Али одржавалац (власник пројекта) или главни тим треба да размотри ваше измене пре него што их споји са "главном" граном пројекта, тако да у суштини тражите одлуку о промени од одржаваоца.
`Pull request` може звучати као чудан термин јер заправо желите да "пошаљете" своје измене у пројекат. Али одржавалац (власник пројекта) или главни тим треба да размотри ваше измене пре него што их споји са "главном" граном пројекта, тако да заправо тражите одржавалаца да донесу одлуку о изменама.
`Pull request`је место где се упоређују и дискутују разлике уведене на грани уз рецензије, коментаре, интегрисане тестове и још много тога. Добар `pull request` прати отприлике иста правила као и порука комита. Можете додати референцу на проблем у трагачу за проблемима, на пример када ваш рад решава неки проблем. Овосе ради коришћењем `#` праћеног бројем вашег проблема. На пример,`#97`.
Pull request је место где можете упоредити и дискутовати о разликама које сте унели у грану уз рецензије, коментаре, интегрисане тестове и још много тога. Добар pull request прати отприлике исте смернице као и порука комита. Можете додати референцу на проблем у трагачу проблема, на пример када ваш рад решава одређени проблем. Тосе ради коришћењем `#` праћеног бројем вашег проблема. На пример `#97`.
🤞Држимо палчеве да сви провери прођу и да власник(ци) пројекта споје ваше измене у пројекат🤞
🤞Држимо палчеве да сви тестови прођу и да власник(ци) пројекта споје ваше измене у пројекат🤞
Ажурирајте своју тренутну локалну радну грану са свим новим комитима са одговарајуће удаљене гране на GitHub-у:
Ажурирајте своју тренутну локалну радну грану са свим новим комитима из одговарајуће удаљене гране на GitHub-у:
`git pull`
## Како допринети отвореном коду
Прво, хајде да пронађемо репозиторијум (или **репо**) на GitHub-у који вас занима и коме бисте желели да допринесете неком променом. Желите да копирате његов садржај на свој рачунар.
Прво, пронађите репозиторијум (или **repo**) на GitHub-у који вас занима и коме бисте желели да допринесете изменом. Желите да копирате његов садржај на свој рачунар.
✅ Добар начин да пронађете репозиторијуме погодне за почетнике је [претрага по ознаци 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Постоји неколико начина за копирање кода. Један од начина је да "клонирате" садржај репозиторијума, користећи HTTPS, SSH или GitHub CLI (Command Line Interface).
Отворите свој терминал и клонирајте репозиторијум овако:
Отворите терминал и клонирајте репозиторијум овако:
`git clone https://github.com/ProjectURL`
Да бисте радили на пројекту, промените директоријум на одговарајући фолдер:
Да бисте радили на пројекту, промените директоријум на одговарајући:
`cd ProjectURL`
Такође можете отворити цео пројекат користећи [Codespaces](https://github.com/features/codespaces), GitHub-ов уграђени едитор кода / облачно окружење за развој, или [GitHub Desktop](https://desktop.github.com/).
Такође можете отворити цео пројекат користећи [Codespaces](https://github.com/features/codespaces), GitHub-ов уграђени едитор кода / облачно развојно окружење, или [GitHub Desktop](https://desktop.github.com/).
На крају, можете преузети код у зипованом фолдеру.
### Неколико занимљивих ствари о GitHub-у
Можете да означите звездицом, пратите и/или "форкујете" било који јавни репозиторијум на GitHub-у. Своје означене репозиторијуме можете пронаћи у падајућем менију у горњем десном углу. Тоје као обележивање, али за код.
Можете да означите звездицом, пратите и/или "форкујете" било који јавни репозиторијум на GitHub-у. Своје репозиторијуме означене звездицом можете пронаћи у падајућем менију у горњем десном углу. Тоје као обележавање, али за код.
Пројекти имају трагач за проблемима, углавном на GitHub-уу картици "Issues", осим ако није другачије назначено, где људи дискутују о проблемима везаним за пројекат. А картица "Pull Requests"је место где људи дискутују и прегледају измене које суу току.
Пројекти имају трагач проблема, углавном на GitHub-уу картици "Issues", осим ако није другачије назначено, где људи дискутују о проблемима везаним за пројекат. А картица Pull Requests је место где људи дискутују и прегледају измене које суу току.
Пројекти могу такође имати дискусије у форумима, мејлинг листама или чет каналима као што су Slack, Discord или IRC.
Пројекти могу имати дискусије у форумима, мејлинг листама или каналима за ћаскање као што су Slack, Discord или IRC.
✅ Погледајте свој нови GitHub репозиторијум и испробајте неколико ствари, као што су подешавање опција, додавање информација у свој репозиторијум и креирање пројекта (као што је Канбан табла). Постоји много тога што можете да урадите!
✅ Погледајте свој нови GitHub репозиторијум и испробајте неке ствари, као што су уређивање подешавања, додавање информација у репозиторијум и креирање пројекта (као што је Канбан табла). Постоји много тога што можете урадити!
---
## 🚀 Изазов
Упарите сеса пријатељем и радите на коду једно другог. Креирајте пројекат заједно, форкујте код, креирајте гране и спајајте измене.
Упарите сеса пријатељем да радите на кодовима једно другог. Креирајте пројекат заједно, форкујте код, креирајте гране и спојите измене.
## Квиз након предавања
## Квиз након предавања
[Квиз након предавања](https://ff-quizzes.netlify.app/web/en/)
## Преглед и самостално учење
@ -319,7 +326,7 @@ CO_OP_TRANSLATOR_METADATA:
- [Прва недеља на GitHub-у](https://skills.github.com/#first-week-on-github)
Ту ћете пронаћи и напредније курсеве.
Такође ћете пронаћи напредније курсеве.
## Задатак
@ -328,4 +335,4 @@ CO_OP_TRANSLATOR_METADATA:
---
**Одрицање од одговорности**:
Овај документ је преведен коришћењем услуге за превођење помоћу вештачке интелигенције [Co-op Translator](https://github.com/Azure/co-op-translator). Иако тежимо тачности, молимо вас да имате у виду да аутоматски преводи могу садржати грешке или нетачности. Оригинални документ на изворном језику треба сматрати ауторитативним извором. За критичне информације препоручује се професионални превод од стране људи. Несносимо одговорност за било каква неспоразумевања или погрешна тумачења која могу произаћи из коришћења овог превода.
Овај документ је преведен коришћењем услуге за превођење помоћу вештачке интелигенције [Co-op Translator](https://github.com/Azure/co-op-translator). Иако се трудимо да обезбедимо тачност, молимо вас да имате у виду да аутоматски преводи могу садржати грешке или нетачности. Оригинални документ на његовом изворном језику треба сматрати меродавним извором. За критичне информације препоручује се професионални превод од стране људи. Непреузимамо одговорност за било каква погрешна тумачења или неспоразуме који могу произаћи из коришћења овог превода.
[Quiz före föreläsningen](https://ff-quizzes.netlify.app)
## Introduktion
@ -37,13 +37,13 @@ Om Git inte är installerat, [ladda ner Git](https://git-scm.com/downloads). St
För att kontrollera om Git redan är konfigurerat kan du skriva:
`git config --list`
Du behöver också ett GitHub-konto, en kodredigerare (som Visual Studio Code), och du behöver öppna din terminal (eller kommandotolken).
Du behöver också ett GitHub-konto, en kodredigerare (som Visual Studio Code), och du behöver öppna din terminal (eller: kommandotolken).
Navigera till [github.com](https://github.com/) och skapa ett konto om du inte redan har ett, eller logga in och fyll i din profil.
✅ GitHub är inte den enda kodförvaringen i världen; det finns andra, men GitHub är den mest kända.
### Förberedelser
### Förberedelse
Du behöver både en mapp med ett kodprojekt på din lokala dator (laptop eller PC) och ett offentligt repository på GitHub, som kommer att fungera som ett exempel på hur man bidrar till andras projekt.
@ -51,13 +51,13 @@ Du behöver både en mapp med ett kodprojekt på din lokala dator (laptop eller
## Kodhantering
Låt oss säga att du har en mapp lokalt med ett kodprojekt och du vill börja spåra dina framsteg med hjälp av git - versionshanteringssystemet. Vissa människor jämför att använda git med att skriva ett kärleksbrev till sitt framtida jag. Genom att läsa dina commit-meddelanden dagar, veckor eller månader senare kan du minnas varför du tog ett beslut, eller "rulla tillbaka" en ändring - det vill säga, om du skriver bra "commit-meddelanden".
Låt oss säga att du har en mapp lokalt med ett kodprojekt och du vill börja spåra dina framsteg med hjälp av git - versionshanteringssystemet. Vissa jämför att använda git med att skriva ett kärleksbrev till ditt framtida jag. Genom att läsa dina commit-meddelanden dagar, veckor eller månader senare kommer du att kunna minnas varför du fattade ett beslut, eller "rulla tillbaka" en ändring - det vill säga, när du skriver bra "commit-meddelanden".
### Uppgift: Skapa ett repository och commit:a kod
> Se video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Skapa repository på GitHub**. På GitHub.com, i fliken repositories, eller från navigeringsfältet uppe till höger, hitta knappen **new repo**.
@ -93,7 +93,7 @@ Låt oss säga att du har en mapp lokalt med ett kodprojekt och du vill börja s
modified: file2.txt
```
Vanligtvis berättar kommandot `git status` saker som vilka filer som är redo att _sparas_ till repo:t eller har ändringar som du kanske vill bevara.
Vanligtvis berättar kommandot `git status` saker som vilka filer som är redo att _sparas_ till repositoryt eller har ändringar som du kanske vill bevara.
1. **Lägg till alla filer för spårning**
Detta kallas också att staga filer/lägga till filer i staging-området.
@ -126,37 +126,37 @@ Låt oss säga att du har en mapp lokalt med ett kodprojekt och du vill börja s
git reset [file or folder name]
```
Detta kommando hjälper oss att avstaga endast en specifik fil som vi inte vill inkludera i nästa commit.
Detta kommando hjälper oss att avstaga endast en specifik fil på en gång som vi inte vill inkludera i nästa commit.
1. **Spara ditt arbete**. Vid det här laget har du lagt till filerna i ett så kallat _staging-område_. En plats där Git spårar dina filer. För att göra ändringen permanent behöver du _commit:a_ filerna. För att göra det skapar du en _commit_ med kommandot `git commit`. En _commit_ representerar en sparpunkt i historiken för ditt repo. Skriv följande för att skapa en _commit_:
1. **Bevara ditt arbete**. Vid det här laget har du lagt till filerna i ett så kallat _staging-område_. En plats där Git spårar dina filer. För att göra ändringen permanent behöver du _commit:a_ filerna. För att göra det skapar du en _commit_ med kommandot `git commit`. En _commit_ representerar en sparpunkt i historiken för ditt repository. Skriv följande för att skapa en _commit_:
```bash
git commit -m "first commit"
```
Detta commit:ar alla dina filer och lägger till meddelandet "first commit". För framtida commit-meddelanden vill du vara mer beskrivande för att förmedla vilken typ av ändring du har gjort.
Detta commit:ar alla dina filer och lägger till meddelandet "first commit". För framtida commit-meddelanden vill du vara mer beskrivande i din beskrivning för att förmedla vilken typ av ändring du har gjort.
1. **Koppla ditt lokala Git-repo till GitHub**. Ett Git-repo är bra på din dator, men vid något tillfälle vill du ha en backup av dina filer någonstans och även bjuda in andra att arbeta med dig på ditt repo. En sådan bra plats är GitHub. Kom ihåg att vi redan har skapat ett repo på GitHub, så det enda vi behöver göra är att koppla vårt lokala Git-repo till GitHub. Kommandot `git remote add` gör just det. Skriv följande kommando:
1. **Koppla ditt lokala Git-repository med GitHub**. Ett Git-repository är bra på din dator, men vid någon punkt vill du ha en backup av dina filer någonstans och även bjuda in andra att arbeta med dig på ditt repository. En sådan bra plats är GitHub. Kom ihåg att vi redan har skapat ett repository på GitHub, så det enda vi behöver göra är att koppla vårt lokala Git-repository med GitHub. Kommandot `git remote add` gör just det. Skriv följande kommando:
> Obs, innan du skriver kommandot, gå till din GitHub-repo-sida för att hitta repository-URL:en. Du kommer att använda den i kommandot nedan. Ersätt ```https://github.com/username/repository_name.git``` med din GitHub-URL.
> Observera, innan du skriver kommandot, gå till din GitHub-repository-sida för att hitta repository-URL:en. Du kommer att använda den i kommandot nedan. Ersätt ```https://github.com/username/repository_name.git``` med din GitHub-URL.
Detta skapar en _remote_, eller anslutning, med namnet "origin" som pekar på GitHub-repository:t du skapade tidigare.
Detta skapar en _remote_, eller anslutning, med namnet "origin" som pekar på GitHub-repositoryt du skapade tidigare.
1. **Skicka lokala filer till GitHub**. Hittills har du skapat en _anslutning_ mellan det lokala repo:t och GitHub-repo:t. Låt oss skicka dessa filer till GitHub med följande kommando `git push`, så här:
1. **Skicka lokala filer till GitHub**. Hittills har du skapat en _anslutning_ mellan det lokala repositoryt och GitHub-repositoryt. Låt oss skicka dessa filer till GitHub med följande kommando `git push`, så här:
> Obs, ditt branch-namn kan vara annorlunda som standard från ```main```.
> Observera, ditt branch-namn kan vara annorlunda som standard från ```main```.
```bash
git push -u origin main
```
Detta skickar dina commits i din "main"-branch till GitHub.
Detta skickar dina commits i din "main"-branch till GitHub. Att ställa in `upstream`-branchen inklusive `-u` i kommandot etablerar en länk mellan din lokala branch och den fjärranslutna branchen, så att du enkelt kan använda git push eller git pull utan att ange branch-namnet i framtiden. Git kommer automatiskt att använda upstream-branchen och du behöver inte ange branch-namnet explicit i framtida kommandon.
2. **Lägg till fler ändringar**. Om du vill fortsätta göra ändringar och skicka dem till GitHub behöver du bara använda följande tre kommandon:
2. **För att lägga till fler ändringar**. Om du vill fortsätta göra ändringar och skicka dem till GitHub behöver du bara använda följande tre kommandon:
```bash
git add .
@ -164,17 +164,17 @@ Låt oss säga att du har en mapp lokalt med ett kodprojekt och du vill börja s
git push
```
> Tips, du kanske också vill använda en `.gitignore`-fil för att förhindra att filer du inte vill spåra dyker upp på GitHub - som den anteckningsfilen du lagrar i samma mapp men som inte har någon plats i ett offentligt repository. Du kan hitta mallar för `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
> Tips, du kanske också vill använda en `.gitignore`-fil för att förhindra att filer du inte vill spåra visas på GitHub - som den där anteckningsfilen du lagrar i samma mapp men som inte har någon plats i ett offentligt repository. Du kan hitta mallar för `.gitignore`-filer på [.gitignore templates](https://github.com/github/gitignore).
#### Commit-meddelanden
Ett bra Git-commit ämnesrad kompletterar följande mening:
Om det tillämpas, kommer denna commit att <dinämnesradhär>
En bra Git commit-rubrik kompletterar följande mening:
Om den tillämpas, kommer denna commit att <dinrubrikhär>
För ämnet, använd imperativ, presens: "ändra" inte "ändrade" eller "ändringar".
Precis som i ämnet, använd också imperativ, presens i kroppen (valfritt). Kroppen bör inkludera motivationen för ändringen och kontrastera detta med tidigare beteende. Du förklarar `varför`, inte `hur`.
För rubriken, använd imperativ, presens: "ändra" inte "ändrade" eller "ändringar".
Precis som i rubriken, använd också imperativ, presens i kroppen (valfritt). Kroppen bör inkludera motivationen för ändringen och kontrastera detta med tidigare beteende. Du förklarar `varför`, inte `hur`.
✅ Ta några minuter och surfa runt på GitHub. Kan du hitta ett riktigt bra commit-meddelande? Kan du hitta ett riktigt minimalt? Vilken information tycker du är viktigast och mest användbar att förmedla i ett commit-meddelande?
✅ Ta några minuter att surfa runt på GitHub. Kan du hitta ett riktigt bra commit-meddelande? Kan du hitta ett riktigt minimalt? Vilken information tycker du är den viktigaste och mest användbara att förmedla i ett commit-meddelande?
### Uppgift: Samarbeta
@ -184,11 +184,11 @@ Huvudsyftet med att lägga upp saker på GitHub var att göra det möjligt att s
> Se video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
I ditt repository, navigera till `Insights > Community` för att se hur ditt projekt jämför med rekommenderade community-standarder.
I ditt repository, navigera till `Insights > Community` för att se hur ditt projekt jämför sig med rekommenderade community-standarder.
Här är några saker som kan förbättra ditt GitHub-repo:
Här är några saker som kan förbättra ditt GitHub-repository:
- **Beskrivning**. Har du lagt till en beskrivning för ditt projekt?
- **README**. Har du lagt till en README? GitHub ger vägledning för att skriva en [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Riktlinjer för bidrag**. Har ditt projekt [riktlinjer för bidrag](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
@ -197,22 +197,22 @@ I ditt repository, navigera till `Insights > Community` för att se hur ditt pro
Alla dessa resurser kommer att gynna onboarding av nya teammedlemmar. Och det är typiskt sådana saker nya bidragsgivare tittar på innan de ens tittar på din kod, för att ta reda på om ditt projekt är rätt plats för dem att spendera sin tid.
✅ README-filer, även om de tar tid att förbereda, förbises ofta av upptagna underhållare. Kan du hitta ett exempel på en särskilt beskrivande README? Obs: det finns några [verktyg för att skapa bra READMEs](https://www.makeareadme.com/) som du kanske vill prova.
✅ README-filer, även om de tar tid att förbereda, försummas ofta av upptagna underhållare. Kan du hitta ett exempel på en särskilt beskrivande README? Obs: det finns några [verktyg för att skapa bra README-filer](https://www.makeareadme.com/) som du kanske vill prova.
### Uppgift: Slå ihop kod
Bidragsdokument hjälper människor att bidra till projektet. Det förklarar vilka typer av bidrag du letar efter och hur processen fungerar. Bidragsgivare måste gå igenom en serie steg för att kunna bidra till ditt repo på GitHub:
Bidragsdokument hjälper människor att bidra till projektet. Det förklarar vilka typer av bidrag du letar efter och hur processen fungerar. Bidragsgivare kommer att behöva gå igenom en serie steg för att kunna bidra till ditt repository på GitHub:
1. **Forka ditt repo**. Du kommer förmodligen vilja att folk ska _forka_ ditt projekt. Forking innebär att skapa en kopia av ditt repository på deras GitHub-profil.
1. **Klona**. Därefter klonar de projektet till sin lokala dator.
1. **Skapa en branch**. Du vill be dem att skapa en _branch_ för sitt arbete.
1. **Fokusera sin ändring på ett område**. Be bidragsgivare att koncentrera sina bidrag på en sak i taget - på så sätt är chansen att du kan _slå ihop_ deras arbete högre. Tänk dig att de skriver en buggfix, lägger till en ny funktion och uppdaterar flera tester - vad händer om du vill, eller bara kan implementera 2 av 3, eller 1 av 3 ändringar?
1. **Forka ditt repository**. Du kommer förmodligen vilja att folk ska _forka_ ditt projekt. Forkning innebär att skapa en kopia av ditt repository på deras GitHub-profil.
1. **Klona**. Därefter kommer de att klona projektet till sin lokala dator.
1. **Skapa en branch**. Du kommer vilja be dem att skapa en _branch_ för sitt arbete.
1. **Fokusera ändringen på ett område**. Be bidragsgivare att koncentrera sina bidrag på en sak i taget - på så sätt är chansen att du kan _slå ihop_ deras arbete högre. Tänk dig att de skriver en buggfix, lägger till en ny funktion och uppdaterar flera tester - vad händer om du vill, eller bara kan implementera 2 av 3, eller 1 av 3 ändringar?
✅ Föreställ dig en situation där branches är särskilt kritiska för att skriva och leverera bra kod. Vilka användningsfall kan du tänka dig?
> Obs, var den förändring du vill se i världen och skapa branches för ditt eget arbete också. Alla commits du gör kommer att göras på den branch du för närvarande är "utcheckad" till. Använd `git status` för att se vilken branch det är.
Låt oss gå igenom en bidragsgivares arbetsflöde. Anta att bidragsgivaren redan har _forkat_ och _klonat_ repo:t så att de har ett Git-repo redo att arbeta med på sin lokala dator:
Låt oss gå igenom en bidragsgivares arbetsflöde. Anta att bidragsgivaren redan har _forkat_ och _klonat_ repositoryt så att de har ett Git-repository redo att arbeta med på sin lokala dator:
1. **Skapa en branch**. Använd kommandot `git branch` för att skapa en branch som kommer att innehålla de ändringar de avser att bidra med:
@ -233,9 +233,9 @@ Låt oss gå igenom en bidragsgivares arbetsflöde. Anta att bidragsgivaren reda
git commit -m "my changes"
```
Se till att du ger din commit ett bra namn, för din egen skull såväl som för underhållaren av repo:t du hjälper till med.
Se till att ge din commit ett bra namn, för din egen skull såväl som för underhållaren av repositoryt du hjälper till med.
1. **Kombinera ditt arbete med `main`-branchen**. Vid något tillfälle är du klar med ditt arbete och vill kombinera det med `main`-branchen. `Main`-branchen kan ha ändrats under tiden, så se till att du först uppdaterar den till det senaste med följande kommandon:
1. **Kombinera ditt arbete med `main`-branchen**. Vid någon punkt är du klar med ditt arbete och du vill kombinera ditt arbete med det i `main`-branchen. `main`-branchen kan ha ändrats under tiden, så se till att du först uppdaterar den till det senaste med följande kommandon:
```bash
git switch main
@ -249,44 +249,49 @@ Låt oss gå igenom en bidragsgivares arbetsflöde. Anta att bidragsgivaren reda
git merge main
```
Detta kommer att ta in alla ändringar från `main` till din branch och förhoppningsvis kan du bara fortsätta. Om inte, kommer VS Code att visa dig var Git är _förvirrad_ och du ändrar de berörda filerna för att ange vilket innehåll som är mest korrekt.
Kommandot `git merge main` kommer att ta in alla ändringar från `main` till din branch. Förhoppningsvis kan du bara fortsätta. Om inte, kommer VS Code att berätta var Git är _förvirrad_ och du ändrar bara de berörda filerna för att ange vilket innehåll som är mest korrekt.
För att byta till en annan branch, använd det moderna kommandot `git switch`:
```bash
git switch [branch_name]
1. **Skicka ditt arbete till GitHub**. Att skicka ditt arbete till GitHub innebär två saker. Att pusha din branch till ditt repo och sedan öppna en PR, Pull Request.
1. **Skicka ditt arbete till GitHub**. Att skicka ditt arbete till GitHub innebär två saker. Att pusha din branch till ditt repository och sedan öppna en PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Kommandot ovan skapar branchen på ditt forkade repo.
1. **Öppna en PR**. Nästa steg är att öppna en PR. Du gör det genom att navigera till det forkade repo:t på GitHub. Du kommer att se en indikation på GitHub där det frågar om du vill skapa en ny PR, du klickar på det och tas till ett gränssnitt där du kan ändra commit-meddelandets titel, ge det en mer lämplig beskrivning. Nu kommer underhållaren av repo:t du forkade att se denna PR och _håller tummarna_ att de uppskattar och _slår ihop_ din PR. Du är nu en bidragsgivare, yay :)
Kommandot ovan skapar branchen på ditt forkade repository.
1. **Öppna en PR**. Nästa steg är att öppna en PR. Det gör du genom att navigera till den forkade repot på GitHub. Du kommer att se en indikation på GitHub där det frågas om du vill skapa en ny PR, klicka på det och du tas till en gränssnitt där du kan ändra commit-meddelandets titel och ge det en mer passande beskrivning. Nu kommer underhållaren av repot du forkade att se denna PR och _hoppas på det bästa_ att de uppskattar och _merger_ din PR. Du är nu en bidragsgivare, yay :)
1. **Städa upp**. Det anses vara god praxis att _städa upp_ efter att du framgångsrikt har slagit ihop en PR. Du vill städa upp både din lokala branch och branchen du pushade till GitHub. Först, låt oss ta bort den lokalt med följande kommando:
1. **Rensa upp**. Det anses vara god praxis att _rensa upp_ efter att du framgångsrikt har mergat en PR. Du vill rensa upp både din lokala branch och den branch du pushade till GitHub. Först, låt oss ta bort den lokalt med följande kommando:
```bash
git branch -d [branch-name]
```
Se till att du går till GitHub-sidan för det forkade repo:t och tar bort den remote-branch du just pushade till det.
`Pull request` kan låta som ett konstigt uttryck eftersom du egentligen vill "pusha" dina ändringar till projektet. Men projektets ansvariga (ägare) eller kärnteamet behöver granska dina ändringar innan de slås ihop med projektets "main"-gren, så det handlar egentligen om att begära ett beslut om ändringen från en ansvarig.
Se till att du går till GitHub-sidan för det forkade repot och tar bort den fjärrgren du just pushade till.
`Pull request` kan verka som ett konstigt begrepp eftersom du egentligen vill pusha dina ändringar till projektet. Men underhållaren (projektägaren) eller kärnteamet behöver överväga dina ändringar innan de mergas med projektets "main"-branch, så du begär egentligen ett beslut om ändring från en underhållare.
En pull request är platsen där du kan jämföra och diskutera skillnader som introducerats i en gren, med hjälp av recensioner, kommentarer, integrerade tester och mer. En bra pull request följer ungefär samma regler som ett commit-meddelande. Du kan lägga till en referens till ett ärende i ärendespåraren, till exempel när ditt arbete löser ett problem. Detta görs med ett `#` följt av ärendenumret. Till exempel `#97`.
En pull request är platsen där man jämför och diskuterar skillnader som introducerats på en branch med recensioner, kommentarer, integrerade tester och mer. En bra pull request följer ungefär samma regler som ett commit-meddelande. Du kan lägga till en referens till ett ärende i ärendespåraren, till exempel när ditt arbete löser ett problem. Detta görs med ett `#` följt av numret på ditt ärende. Till exempel `#97`.
🤞Håller tummarna för att alla kontroller går igenom och att projektägaren/ägarna slår ihop dina ändringar med projektet🤞
🤞Hoppas att alla kontroller går igenom och att projektägaren/ägarna mergar dina ändringar till projektet🤞
Uppdatera din nuvarande lokala arbetsgren med alla nya commits från motsvarande fjärrgren på GitHub:
Uppdatera din aktuella lokala arbetsbranch med alla nya commits från motsvarande fjärrbranch på GitHub:
`git pull`
## Hur man bidrar till öppen källkod
## Hur man bidrar till open source
Först, hitta ett repository (eller **repo**) på GitHub som intresserar dig och som du vill bidra med en ändring till. Du kommer vilja kopiera dess innehåll till din dator.
Först, låt oss hitta ett repository (eller **repo**) på GitHub som intresserar dig och som du vill bidra med en ändring till. Du kommer att vilja kopiera dess innehåll till din dator.
✅ Ett bra sätt att hitta 'nybörjarvänliga' repos är att [söka efter taggen 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Det finns flera sätt att kopiera kod. Ett sätt är att "klona" innehållet i repot, antingen via HTTPS, SSH eller med hjälp av GitHub CLI (Command Line Interface).
Det finns flera sätt att kopiera kod. Ett sätt är att "klona" innehållet i repot, med hjälp av HTTPS, SSH eller GitHub CLI (Command Line Interface).
Öppna din terminal och klona repot så här:
`git clone https://github.com/ProjectURL`
@ -294,46 +299,46 @@ Det finns flera sätt att kopiera kod. Ett sätt är att "klona" innehållet i r
För att arbeta med projektet, byt till rätt mapp:
`cd ProjectURL`
Du kan också öppna hela projektet med [Codespaces](https://github.com/features/codespaces), GitHubs inbyggda kodredigerare/molnutvecklingsmiljö, eller [GitHub Desktop](https://desktop.github.com/).
Du kan också öppna hela projektet med [Codespaces](https://github.com/features/codespaces), GitHubs inbyggda kodredigerare/molnutvecklingsmiljö, eller [GitHub Desktop](https://desktop.github.com/).
Slutligen kan du ladda ner koden i en zip-fil.
Slutligen kan du ladda ner koden i en zippad mapp.
### Några fler intressanta saker om GitHub
Du kan stjärnmärka, bevaka och/eller "forka" vilket offentligt repository som helst på GitHub. Du hittar dina stjärnmärkta repos i rullgardinsmenyn uppe till höger. Det är som att bokmärka, fast för kod.
Du kan stjärnmärka, bevaka och/eller "forka" vilket offentligt repository som helst på GitHub. Du hittar dina stjärnmärkta repositories i rullgardinsmenyn längst upp till höger. Det är som att bokmärka, fast för kod.
Projekt har en ärendespårare, oftast på GitHub under fliken "Issues" om inget annat anges, där folk diskuterar problem relaterade till projektet. Fliken Pull Requests är där folk diskuterar och granskar ändringar som pågår.
Projekt har en ärendespårare, oftast på GitHub under fliken "Issues" om inte annat anges, där folk diskuterar problem relaterade till projektet. Och fliken Pull Requests är där folk diskuterar och granskar ändringar som är på gång.
Projekt kan också ha diskussioner i forum, e-postlistor eller chattkanaler som Slack, Discord eller IRC.
✅ Utforska ditt nya GitHub-repo och prova några saker, som att redigera inställningar, lägga till information i ditt repo och skapa ett projekt (som en Kanban-tavla). Det finns mycket att göra!
✅ Ta en titt runt ditt nya GitHub-repo och prova några saker, som att redigera inställningar, lägga till information till ditt repo och skapa ett projekt (som en Kanban-tavla). Det finns mycket du kan göra!
---
## 🚀 Utmaning
## 🚀 Utmaning
Jobba tillsammans med en vän på varandras kod. Skapa ett projekt tillsammans, forka kod, skapa grenar och slå ihop ändringar.
Arbeta tillsammans med en vän för att arbeta med varandras kod. Skapa ett projekt tillsammans, forka kod, skapa branches och merge ändringar.
Öva, öva, öva. GitHub har fantastiska inlärningsvägar tillgängliga via [skills.github.com](https://skills.github.com):
- [Första veckan på GitHub](https://skills.github.com/#first-week-on-github)
Du hittar också mer avancerade kurser.
Du hittar också mer avancerade kurser.
## Uppgift
## Uppgift
Slutför [kursen Första veckan på GitHub](https://skills.github.com/#first-week-on-github)
---
**Ansvarsfriskrivning**:
Detta dokument har översatts med hjälp av AI-översättningstjänsten [Co-op Translator](https://github.com/Azure/co-op-translator). Även om vi strävar efter noggrannhet, vänligen notera att automatiska översättningar kan innehålla fel eller felaktigheter. Det ursprungliga dokumentet på dess originalspråk bör betraktas som den auktoritativa källan. För kritisk information rekommenderas professionell mänsklig översättning. Vi ansvarar inte för eventuella missförstånd eller feltolkningar som uppstår vid användning av denna översättning.
Detta dokument har översatts med hjälp av AI-översättningstjänsten [Co-op Translator](https://github.com/Azure/co-op-translator). Även om vi strävar efter noggrannhet, bör det noteras att automatiserade översättningar kan innehålla fel eller felaktigheter. Det ursprungliga dokumentet på dess originalspråk bör betraktas som den auktoritativa källan. För kritisk information rekommenderas professionell mänsklig översättning. Vi ansvarar inte för eventuella missförstånd eller feltolkningar som uppstår vid användning av denna översättning.
Ili kuthibitisha kama Git tayari imewekwa, unaweza kuandika:
Ili kuangalia kama Git tayari imewekwa unaweza kuandika:
`git config --list`
Utahitaji pia akaunti ya GitHub, mhariri wa msimbo (kama Visual Studio Code), na ufungue terminal yako (au: command prompt).
Pia utahitaji akaunti ya GitHub, mhariri wa msimbo (kama Visual Studio Code), na ufungue terminal yako (au: command prompt).
Tembelea [github.com](https://github.com/) na unda akaunti ikiwa bado huna, au ingia na ujaze wasifu wako.
Tembelea [github.com](https://github.com/) na unda akaunti ikiwa bado huna, au ingia na ujaze wasifu wako.
✅ GitHub siyo hifadhi pekee ya msimbo duniani; kuna zingine, lakini GitHub ndiyo inayojulikana zaidi.
✅ GitHub si jukwaa pekee la kuhifadhi msimbo duniani; kuna mengine, lakini GitHub ndilo linalojulikana zaidi.
### Maandalizi
Utahitaji folda yenye mradi wa msimbo kwenye mashine yako ya ndani (laptop au PC), na hifadhi ya umma kwenye GitHub, ambayo itatumika kama mfano wa jinsi ya kuchangia kwenye miradi ya wengine.
Utahitaji folda yenye mradi wa msimbo kwenye kompyuta yako ya ndani (laptop au PC), na hifadhi ya umma kwenye GitHub, ambayo itatumika kama mfano wa jinsi ya kuchangia miradi ya wengine.
---
## Usimamizi wa Msimbo
Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia maendeleo yako ukitumia git - mfumo wa kudhibiti matoleo. Watu wengine hulinganisha kutumia git na kuandika barua ya mapenzi kwa nafsi yako ya baadaye. Ukisoma ujumbe wako wa commit baada ya siku, wiki, au miezi, utaweza kukumbuka kwa nini ulifanya uamuzi fulani, au "kurudisha nyuma" mabadiliko - yaani, unapokuwa umeandika "commit messages" nzuri.
Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia maendeleo yako kwa kutumia git - mfumo wa kudhibiti matoleo. Watu wengine hulinganisha kutumia git na kuandika barua ya mapenzi kwa nafsi yako ya baadaye. Ukisoma ujumbe wa "commit" siku, wiki, au miezi baadaye utaweza kukumbuka kwa nini ulifanya uamuzi fulani, au "kurudisha nyuma" mabadiliko - yaani, unapokuwa umeandika ujumbe mzuri wa "commit".
### Kazi: Unda Hifadhi na Fanya Commit ya Msimbo
### Kazi: Unda hifadhi na uhifadhi msimbo
> Tazama video
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **Unda hifadhi kwenye GitHub**. Kwenye GitHub.com, katika kichupo cha hifadhi, au kutoka kwenye upau wa urambazaji wa juu-kulia, tafuta kitufe cha **new repo**.
1. Pea hifadhi yako jina
1. **Unda hifadhi kwenye GitHub**. Kwenye GitHub.com, katika tab ya hifadhi, au kutoka kwenye upau wa urambazaji juu-kulia, tafuta kitufe cha **new repo**.
1. Peana jina kwa hifadhi yako (folda)
1. Chagua **create repository**.
1. **Nenda kwenye folda yako ya kazi**. Katika terminal yako, badilisha hadi kwenye folda (inayojulikana pia kama directory) unayotaka kuanza kufuatilia. Andika:
1. **Nenda kwenye folda unayofanyia kazi**. Katika terminal yako, badilisha hadi folda (inayojulikana pia kama directory) unayotaka kuanza kufuatilia. Andika:
```bash
cd [name of your folder]
@ -82,7 +83,7 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
git status
```
matokeo yanaweza kuonekana kama haya:
matokeo yanaweza kuonekana kama hivi:
```output
Changes not staged for commit:
@ -93,7 +94,7 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
modified: file2.txt
```
Kwa kawaida amri ya `git status` inakuambia vitu kama faili zipi ziko tayari _kuhifadhiwa_ kwenye hifadhi au zina mabadiliko unayoweza kutaka kuhifadhi.
Kwa kawaida amri ya `git status` inakuambia vitu kama faili gani ziko tayari _kuhifadhiwa_ kwenye hifadhi au zina mabadiliko ambayo unaweza kutaka kuhifadhi.
1. **Ongeza faili zote kwa kufuatilia**
Hii pia inaitwa kuweka faili kwenye eneo la staging.
@ -102,7 +103,7 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
git add .
```
Amri ya `git add` pamoja na hoja ya `.` inaonyesha kuwa faili zako zote na mabadiliko yako yameongezwa kwa kufuatilia.
Amri ya `git add` pamoja na hoja ya `.` inaonyesha kuwa faili zako zote na mabadiliko yako yamewekwa kwa kufuatilia.
1. **Ongeza faili zilizochaguliwa kwa kufuatilia**
@ -110,35 +111,35 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
git add [file or folder name]
```
Hii inatusaidia kuongeza faili zilizochaguliwa tu kwenye eneo la staging wakati hatutaki kufanya commit ya faili zote mara moja.
Hii inatusaidia kuongeza faili zilizochaguliwa tu kwenye eneo la staging wakati hatutaki kuhifadhi faili zote mara moja.
1. **Ondoa faili zote kutoka kwenye eneo la staging**
1. **Ondoa faili zote kutoka eneo la staging**
```bash
git reset
```
Amri hii inatusaidia kuondoa faili zote kutoka kwenye eneo la staging mara moja.
Amri hii inatusaidia kuondoa faili zote mara moja kutoka eneo la staging.
1. **Ondoa faili maalum kutoka kwenye eneo la staging**
1. **Ondoa faili fulani kutoka eneo la staging**
```bash
git reset [file or folder name]
```
Amri hii inatusaidia kuondoa faili maalum tu kutoka kwenye eneo la staging ambayo hatutaki kujumuisha kwenye commit inayofuata.
Amri hii inatusaidia kuondoa faili fulani tu mara moja ambayo hatutaki kujumuisha kwa "commit" inayofuata.
1. **Hifadhi kazi yako**. Kwa sasa umeongeza faili kwenye eneo linaloitwa _staging area_. Mahali ambapo Git inafuatilia faili zako. Ili kufanya mabadiliko yawe ya kudumu unahitaji _commit_ faili hizo. Ili kufanya hivyo unaunda _commit_ kwa amri ya `git commit`. _Commit_ inawakilisha hatua ya kuhifadhi katika historia ya hifadhi yako. Andika yafuatayo kuunda _commit_:
1. **Hifadhi kazi yako**. Kwa sasa umeongeza faili kwenye eneo linaloitwa _staging area_. Sehemu ambapo Git inafuatilia faili zako. Ili kufanya mabadiliko yawe ya kudumu unahitaji _kuhifadhi_ faili. Ili kufanya hivyo unaunda _commit_ kwa amri ya `git commit`. _Commit_ inawakilisha sehemu ya kuhifadhi katika historia ya hifadhi yako. Andika yafuatayo kuunda _commit_:
```bash
git commit -m "first commit"
```
Hii inafanya commit ya faili zako zote, ikiongeza ujumbe "first commit". Kwa ujumbe wa commit wa baadaye utataka kuwa na maelezo zaidi ili kuelezea aina ya mabadiliko uliyofanya.
Hii inahifadhi faili zako zote, ikiongeza ujumbe "first commit". Kwa ujumbe wa "commit" wa baadaye utataka kuwa na maelezo zaidi ili kueleza aina ya mabadiliko uliyofanya.
1. **Unganisha hifadhi yako ya Git ya ndani na GitHub**. Hifadhi ya Git ni nzuri kwenye mashine yako lakini wakati fulani utataka kuwa na nakala rudufu ya faili zako mahali pengine na pia kuwaalika watu wengine kufanya kazi na wewe kwenye hifadhi yako. Mahali pazuri pa kufanya hivyo ni GitHub. Kumbuka tayari tumeunda hifadhi kwenye GitHub kwa hivyo kitu pekee tunachohitaji kufanya ni kuunganisha hifadhi yetu ya Git ya ndani na GitHub. Amri ya `git remote add` itafanya hivyo. Andika amri ifuatayo:
1. **Unganisha hifadhi yako ya Git ya ndani na GitHub**. Hifadhi ya Git ni nzuri kwenye kompyuta yako lakini wakati fulani utataka kuwa na nakala ya faili zako mahali fulani na pia kuwaalika watu wengine kufanya kazi na wewe kwenye hifadhi yako. Mahali pazuri pa kufanya hivyo ni GitHub. Kumbuka tayari tumeunda hifadhi kwenye GitHub kwa hivyo tunachohitaji kufanya ni kuunganisha hifadhi yetu ya Git ya ndani na GitHub. Amri ya `git remote add` itafanya hivyo. Andika amri ifuatayo:
> Kumbuka, kabla ya kuandika amri nenda kwenye ukurasa wa hifadhi yako ya GitHub ili kupata URL ya hifadhi. Utaitumia kwenye amri hapa chini. Badilisha ```https://github.com/username/repository_name.git``` na URL yako ya GitHub.
> Kumbuka, kabla ya kuandika amri nenda kwenye ukurasa wa hifadhi yako ya GitHub ili kupata URL ya hifadhi. Utaitumia katika amri hapa chini. Badilisha ```https://github.com/username/repository_name.git``` na URL yako ya GitHub.
@ -146,7 +147,7 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
Hii inaunda _remote_, au muunganisho, unaoitwa "origin" unaoelekeza kwenye hifadhi ya GitHub uliyounda awali.
1. **Tuma faili za ndani kwenda GitHub**. Hadi sasa umeunda _muunganisho_ kati ya hifadhi ya ndani na hifadhi ya GitHub. Hebu tutume faili hizi kwenda GitHub kwa amri ifuatayo `git push`, kama ifuatavyo:
1. **Tuma faili za ndani kwenye GitHub**. Hadi sasa umeunda _muunganisho_ kati ya hifadhi ya ndani na hifadhi ya GitHub. Hebu tutume faili hizi kwenye GitHub kwa amri ifuatayo `git push`, kama hivi:
> Kumbuka, jina la tawi lako linaweza kuwa tofauti kwa chaguo-msingi kutoka ```main```.
@ -154,9 +155,9 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
git push -u origin main
```
Hii inatuma commits zako kwenye tawi lako la "main" kwenda GitHub.
Hii inatuma "commits" zako kwenye tawi lako la "main" kwenda GitHub. Kuweka tawi la `upstream` ikiwa ni pamoja na `-u` katika amri kunaanzisha kiungo kati ya tawi lako la ndani na tawi la mbali, kwa hivyo unaweza kutumia tu `git push` au `git pull` bila kutaja jina la tawi siku zijazo. Git itatumia moja kwa moja tawi la upstream na hutahitaji kutaja jina la tawi waziwazi katika amri za baadaye.
2. **Kuongeza mabadiliko zaidi**. Ikiwa unataka kuendelea kufanya mabadiliko na kuyasukuma kwenda GitHub utahitaji tu kutumia amri hizi tatu:
2. **Kuongeza mabadiliko zaidi**. Ikiwa unataka kuendelea kufanya mabadiliko na kuyasukuma kwenye GitHub utahitaji tu kutumia amri hizi tatu:
```bash
git add .
@ -164,17 +165,17 @@ Tuseme una folda ya ndani yenye mradi wa msimbo na unataka kuanza kufuatilia mae
git push
```
> Kidokezo, unaweza pia kutaka kutumia faili ya `.gitignore` ili kuzuia faili ambazo hutaki kufuatilia zisionekane kwenye GitHub - kama faili ya maelezo unayohifadhi kwenye folda hiyo hiyo lakini haina nafasi kwenye hifadhi ya umma. Unaweza kupata violezo vya faili za `.gitignore` kwenye [.gitignore templates](https://github.com/github/gitignore).
> Kidokezo, Unaweza pia kutaka kutumia faili ya `.gitignore` ili kuzuia faili ambazo hutaki kufuatilia zisionekane kwenye GitHub - kama faili ya maelezo unayohifadhi kwenye folda hiyo hiyo lakini haina nafasi kwenye hifadhi ya umma. Unaweza kupata templeti za faili za `.gitignore` kwenye [.gitignore templates](https://github.com/github/gitignore).
#### Ujumbe wa Commit
Mstari mzuri wa somo la commit ya Git unakamilisha sentensi ifuatayo:
Ikiwa itatumika, commit hii itafanya <weka somolako hapa>
Ujumbe mzuri wa Git commit unakamilisha sentensi ifuatayo:
Ikiwa itatumika, commit hii itafanya <ujumbe wako hapa>
Kwa somo tumia hali ya amri, wakati wa sasa: "badilisha" siyo "ilibadilishwa" wala "inabadilisha".
Kama ilivyo kwenye somo, kwenye mwili (hiari) pia tumia hali ya amri, wakati wa sasa. Mwili unapaswa kujumuisha motisha ya mabadiliko na kulinganisha haya na tabia ya awali. Unaelezea `kwa nini`, siyo`jinsi`.
Kwa somo tumia hali ya amri, wakati uliopo: "badilisha" si "ilibadilishwa" wala "inabadilisha".
Kama ilivyo kwenye somo, katika mwili (hiari) pia tumia hali ya amri, wakati uliopo. Mwili unapaswa kujumuisha motisha ya mabadiliko na kulinganisha haya na tabia ya awali. Unafafanua `kwa nini`, si`jinsi`.
✅ Chukua dakika chache kuvinjari GitHub. Je, unaweza kupata ujumbe wa commit mzuri sana? Je, unaweza kupata mmoja wa kiwango cha chini sana? Unafikiri ni taarifa gani muhimu zaidi na yenye manufaa kuwasilisha kwenye ujumbe wa commit?
✅ Chukua dakika chache kuvinjari GitHub. Je, unaweza kupata ujumbe mzuri wa commit? Je, unaweza kupata ujumbe wa commit ulio rahisi sana? Ni taarifa gani unadhani ni muhimu zaidi na yenye manufaa kufikisha katika ujumbe wa commit?
### Kazi: Kushirikiana
@ -184,156 +185,162 @@ Sababu kuu ya kuweka vitu kwenye GitHub ilikuwa kufanya iwezekane kushirikiana n
> Tazama video
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Katika hifadhi yako, nenda kwenye `Insights > Community` ili kuona jinsi mradi wako unavyolinganishwa na viwango vya jamii vinavyopendekezwa.
Hapa kuna baadhi ya mambo yanayoweza kuboresha hifadhi yako ya GitHub:
Hapa kuna mambo ambayo yanaweza kuboresha hifadhi yako ya GitHub:
- **Maelezo**. Je, umeongeza maelezo kwa mradi wako?
- **README**. Je, umeongeza README? GitHub inatoa mwongozo wa kuandika [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Mwongozo wa kuchangia**. Je, mradi wako una [miongozo ya kuchangia](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
- **Kanuni za Maadili**. [Kanuni za Maadili](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Mwongozo wa kuchangia**. Je, mradi wako una [miongozo ya kuchangia](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon),
- **Kanuni za Maadili**. [Kanuni za Maadili](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Leseni**. Labda muhimu zaidi, [leseni](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Rasilimali hizi zote zitafaidisha kuwaingiza wanachama wapya wa timu. Na haya ndiyo kwa kawaida mambo ambayo wachangiaji wapya huangalia kabla hata ya kuangalia msimbo wako, ili kujua kama mradi wako ni mahali sahihi kwao kutumia muda wao.
✅ Faili za README, ingawa zinachukua muda kuandaa, mara nyingi hupuuzwa na waangalizi wenye shughuli nyingi. Je, unaweza kupata mfano wa README iliyoelezea vizuri sana? Kumbuka: kuna baadhi ya [zana za kusaidia kuunda README nzuri](https://www.makeareadme.com/) ambazo unaweza kupenda kujaribu.
Rasilimali hizi zote zitasaidia kuingiza wanachama wapya wa timu. Na haya ni mambo ambayo wachangiaji wapya huangalia kabla hata ya kuangalia msimbo wako, ili kujua kama mradi wako ni mahali sahihi pa kutumia muda wao.
✅ Faili za README, ingawa zinachukua muda kuandaa, mara nyingi hupuuzwa na waangalizi wenye shughuli nyingi. Je, unaweza kupata mfano wa README iliyoelezea vizuri? Kumbuka: kuna baadhi ya [zana za kusaidia kuunda README nzuri](https://www.makeareadme.com/) ambazo unaweza kupenda kujaribu.
### Kazi: Unganisha msimbo fulani
### Kazi: Unganisha msimbo
Nyaraka za kuchangia husaidia watu kuchangia mradi. Inaelezea aina gani za michango unayotafuta na jinsi mchakato unavyofanya kazi. Wachangiaji watahitaji kupitia mfululizo wa hatua ili waweze kuchangia kwenye hifadhi yako kwenye GitHub:
Nyaraka za kuchangia husaidia watu kuchangia mradi. Inaelezea aina gani za michango unayotafuta na jinsi mchakato unavyofanya kazi. Wachangiaji watahitaji kupitia mfululizo wa hatua ili waweze kuchangia kwenye hifadhi yako ya GitHub:
1. **Kufork hifadhi yako**. Huenda utataka watu _wafork_ mradi wako. Kufork kunamaanisha kuunda nakala ya hifadhi yako kwenye wasifu wao wa GitHub.
1. **Clone**. Kutoka hapo wata-clone mradi kwenye mashine yao ya ndani.
1. **Unda tawi**. Utataka kuwaomba waunde _tawi_ kwa kazi yao.
1. **Kuzingatia mabadiliko yao kwenye eneo moja**. Waombe wachangiaji kuzingatia michango yao kwenye jambo moja kwa wakati mmoja - kwa njia hiyo nafasi za kuweza _kuunganisha_ kazi yao ni kubwa zaidi. Fikiria wanaandika marekebisho ya hitilafu, kuongeza kipengele kipya, na kusasisha majaribio kadhaa - je, ikiwa unataka, au unaweza kutekeleza 2 kati ya 3, au 1 kati ya 3 mabadiliko?
✅ Fikiria hali ambapo matawi ni muhimu sana kwa kuandika na kusafirisha msimbo mzuri. Unaweza kufikiria matumizi gani?
1. **Kufork hifadhi yako** Labda utataka watu _kufork_ mradi wako. Kufork kunamaanisha kuunda nakala ya hifadhi yako kwenye wasifu wao wa GitHub.
1. **Clone**. Kutoka hapo wata-clone mradi kwenye kompyuta yao ya ndani.
1. **Unda tawi**. Utataka kuwaomba waunde _tawi_ kwa kazi yao.
1. **Lenga mabadiliko yao kwenye eneo moja**. Waombe wachangiaji kulenga michango yao kwenye jambo moja kwa wakati mmoja - kwa njia hiyo nafasi ya kwamba unaweza _kuunganisha_ kazi yao ni kubwa. Fikiria wanaandika marekebisho ya hitilafu, kuongeza kipengele kipya, na kusasisha majaribio kadhaa - vipi ikiwa unataka, au unaweza kutekeleza 2 kati ya 3, au 1 kati ya 3 mabadiliko?
> Kumbuka, kuwa mabadiliko unayotaka kuona duniani, na uunde matawi kwa kazi yako mwenyewe pia. Commit yoyote unayofanya itafanywa kwenye tawi ambalo umefungua kwa sasa. Tumia `git status` kuona ni tawi gani hilo.
✅ Fikiria hali ambapo matawi ni muhimu sana kwa kuandika na kusafirisha msimbo mzuri. Ni matumizi gani unayoweza kufikiria?
Hebu tupitie mtiririko wa kazi wa mchangiaji. Fikiria mchangiaji tayari ame-_fork_ na _clone_ hifadhi kwa hivyo wana hifadhi ya Git tayari kwa kufanyiwa kazi, kwenye mashine yao ya ndani:
> Kumbuka, kuwa mabadiliko unayotaka kuona duniani, na unda matawi kwa kazi yako mwenyewe pia. Mabadiliko yoyote unayofanya yatafanywa kwenye tawi ambalo kwa sasa umechagua "checked out". Tumia `git status` kuona ni tawi gani hilo.
1. **Unda tawi**. Tumia amri `git branch` kuunda tawi ambalo litajumuisha mabadiliko wanayokusudia kuchangia:
Hebu tuendelee na mtiririko wa kazi wa mchangiaji. Fikiria mchangiaji tayari ame-_fork_ na _clone_ hifadhi kwa hivyo ana hifadhi ya Git tayari kufanyiwa kazi, kwenye kompyuta yake ya ndani:
1. **Unda tawi**. Tumia amri ya `git branch` kuunda tawi ambalo litakuwa na mabadiliko wanayokusudia kuchangia:
```bash
git branch [branch-name]
```
1. **Badilisha hadi tawi la kazi**. Badilisha hadi tawi maalum na usasishe folda ya kazi kwa `git switch`:
1. **Badilisha hadi tawi la kazi**. Badilisha hadi tawi lililotajwa na sasisha folda ya kazi kwa `git switch`:
```bash
git switch [branch-name]
```
1. **Fanya kazi**. Kwa sasa unataka kuongeza mabadiliko yako. Usisahau kuijulisha Git kuhusu hilo kwa kutumia amri zifuatazo:
1. **Fanya kazi**. Kwa sasa unataka kuongeza mabadiliko yako. Usisahau kuambia Git kuhusu hilo kwa amri zifuatazo:
```bash
git add .
git commit -m "my changes"
```
Hakikisha unatoa commit jina zuri, kwa manufaa yako na pia kwa mwangalizi wa hifadhi unayosaidia.
Hakikisha unatoa commit yako jina zuri, kwa manufaa yako mwenyewe na pia kwa msimamizi wa hifadhi unayesaidia.
1. **Unganisha kazi yako na tawi la `main`**. Wakati fulani unamaliza kazi na unataka kuunganisha kazi yako na ile ya tawi la `main`. Tawi la `main` linaweza kuwa limebadilika wakati huo kwa hivyo hakikisha kwanza unalisasisha hadi la hivi karibuni kwa amri zifuatazo:
1. **Unganisha kazi yako na tawi la `main`**. Wakati fulani umemaliza kufanya kazi na unataka kuunganisha kazi yako na ile ya tawi la `main`. Tawi la `main` linaweza kuwa limebadilika wakati huo kwa hivyo hakikisha unalisasisha kwanza hadi la hivi karibuni kwa amri zifuatazo:
```bash
git switch main
git pull
```
Kwa sasa unataka kuhakikisha kuwa mizozo yoyote, hali ambapo Git haiwezi _kuunganisha_ mabadiliko kwa urahisi, inatokea kwenye tawi lako la kazi. Kwa hivyo tumia amri zifuatazo:
Kwa sasa unataka kuhakikisha kuwa mizozo yoyote, hali ambapo Git haiwezi _kuunganisha_ mabadiliko kwa urahisi inatokea kwenye tawi lako la kazi. Kwa hivyo tumia amri zifuatazo:
```bash
git switch [branch_name]
git merge main
```
Hii italeta mabadiliko yote kutoka `main` hadi kwenye tawi lako na tunatumaini unaweza kuendelea. Ikiwa sivyo, VS Code itakuonyesha mahali ambapo Git _imechanganyikiwa_ na unarekebisha faili zilizoathiriwa ili kusema ni maudhui gani yaliyo sahihi zaidi.
Amri ya `git merge main` italeta mabadiliko yote kutoka `main` hadi kwenye tawi lako. Tunatumaini unaweza kuendelea tu. Ikiwa sivyo, VS Code itakuonyesha mahali ambapo Git ime-_changanyikiwa_ na unabadilisha faili zilizoathiriwa ili kusema ni maudhui gani yaliyo sahihi zaidi.
1. **Tuma kazi yako kwenda GitHub**. Kutuma kazi yako kwenda GitHub kunamaanisha mambo mawili. Kusukuma tawi lako kwenye hifadhi yako na kisha kufungua PR, Pull Request.
Ili kubadilisha hadi tawi tofauti, tumia amri ya kisasa ya `git switch`:
```bash
git switch [branch_name]
1. **Tuma kazi yako kwenye GitHub**. Kutuma kazi yako kwenye GitHub kunamaanisha mambo mawili. Kusukuma tawi lako kwenye hifadhi yako na kisha kufungua PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Amri hapo juu inaunda tawi kwenye hifadhi yako ya forked.
1. **Fungua PR**. Hatua inayofuata ni kufungua PR. Unaifanya kwa kwenda kwenye hifadhi ya forked kwenye GitHub. Utaona kiashiria kwenye GitHub kinachouliza ikiwa unataka kuunda PR mpya, bonyeza hiyo na utaelekezwa kwenye kiolesura ambapo unaweza kubadilisha kichwa cha ujumbe wa commit, ukape maelezo yanayofaa zaidi. Sasa mwangalizi wa hifadhi uliyofork ataona PR hii na _vidole vimevukwa_ wataithamini na _kuunganisha_ PR yako. Sasa wewe ni mchangiaji, hongera :)
Amri hapo juu inaunda tawi kwenye hifadhi yako ya kufork.
1. **Fungua PR**. Hatua inayofuata ni kufungua PR. Unaweza kufanya hivyo kwa kwenda kwenye repo uliyoifork kwenye GitHub. Utapata maelezo kwenye GitHub yanayokuuliza kama unataka kuunda PR mpya, bonyeza hapo na utapelekwa kwenye kiolesura ambapo unaweza kubadilisha kichwa cha ujumbe wa commit, na kutoa maelezo yanayofaa zaidi. Sasa mtunzaji wa repo uliyoifork ataona PR hii na _kwa matumaini_ wataithamini na _kuunganisha_ PR yako. Sasa umekuwa mchangiaji, hongera! :)
1. **Safisha**. Inachukuliwa kuwa ni mazoea mazuri _kusafisha_ baada ya kufanikiwa kuunganisha PR. Unataka kusafisha tawi lako la ndani na tawi ulilosukuma kwenda GitHub. Kwanza futa tawi hilo kwa ndani kwa amri ifuatayo:
1. **Safisha**. Inachukuliwa kuwa ni tabia nzuri _kusafisha_ baada ya kufanikisha kuunganisha PR. Unapaswa kusafisha tawi lako la ndani na tawi ulilolisukuma kwenye GitHub. Kwanza, futa tawi hilo kwa kutumia amri ifuatayo:
```bash
git branch -d [branch-name]
```
Hakikisha unatembelea ukurasa wa GitHub wa repo uliyoifork na kuondoa tawi la mbali ulilolisukuma.
Hakikisha unaenda kwenye ukurasa wa GitHub wa hifadhi ya forked na kuondoa tawi la mbali ulilosukuma kwenda.
`Pull request` inaonekana kama neno la ajabu kwa sababu kwa kweli unataka kusukuma mabadiliko yako kwenye mradi. Lakini mhifadhi (mmiliki wa mradi) au timu ya msingi inahitaji kuzingatia mabadiliko yako kabla ya kuyachanganya na tawi kuu la mradi, kwa hivyo kwa kweli unaomba uamuzi wa mabadiliko kutoka kwa mhifadhi.
`Pull request` linaweza kuonekana kama neno la ajabu kwa sababu kwa kweli unataka kusukuma mabadiliko yako kwenye mradi. Lakini mtunzaji (mmiliki wa mradi) au timu ya msingi inahitaji kuzingatia mabadiliko yako kabla ya kuyaunganisha na tawi kuu la mradi, kwa hivyo kwa kweli unatoa ombi la uamuzi wa mabadiliko kutoka kwa mtunzaji.
`Pull request` ni mahali pa kulinganisha na kujadili tofauti zilizotangulizwa kwenye tawi kwa kutumia maoni, hakiki, majaribio yaliyounganishwa, na zaidi. `Pull request` nzuri hufuata takriban sheria sawa na ujumbe wa `commit`. Unaweza kuongeza rejeleo kwa suala kwenye orodha ya masuala, kwa mfano ikiwa kazi yako inatatua suala fulani. Hii hufanyika kwa kutumia `#` ikifuatiwa na namba ya suala lako. Kwa mfano `#97`.
Pull request ni mahali pa kulinganisha na kujadili tofauti zilizotolewa kwenye tawi kwa kutumia ukaguzi, maoni, majaribio yaliyounganishwa, na zaidi. Pull request nzuri inafuata takriban sheria sawa na ujumbe wa commit. Unaweza kuongeza rejeleo kwa suala kwenye tracker ya masuala, kwa mfano ikiwa kazi yako inatatua suala. Hii inafanywa kwa kutumia `#` ikifuatiwa na namba ya suala lako. Kwa mfano `#97`.
🤞Tunaomba dua kwamba majaribio yote yamefaulu na wamiliki wa mradi wanachanganya mabadiliko yako kwenye mradi🤞
🤞Kwa matumaini kwamba ukaguzi wote utapita na mmiliki wa mradi ataunganisha mabadiliko yako kwenye mradi🤞
Sasisha tawi lako la kazi la ndani na `commit` zote mpya kutoka kwenye tawi la mbali linalolingana kwenye GitHub:
Sasisha tawi lako la kazi la ndani na commit zote mpya kutoka kwenye tawi la mbali linalolingana kwenye GitHub:
`git pull`
## Jinsi ya kuchangia kwenye chanzo huria
## Jinsi ya kuchangia kwenye open source
Kwanza, tafuta hifadhi (au **repo**) kwenye GitHub inayokuvutia na unayotaka kuchangia mabadiliko. Utataka kunakili yaliyomo kwenye mashine yako.
Kwanza, tafuta repo kwenye GitHub inayokuvutia na ambayo ungependa kuchangia mabadiliko. Utataka kunakili yaliyomo kwenye mashine yako.
✅ Njia nzuri ya kupata hifadhi zinazofaa kwa wanaoanza ni [kutafuta kwa alama 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Njia nzuri ya kupata repo zinazofaa kwa wanaoanza ni [kutafuta kwa tagi 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Kuna njia kadhaa za kunakili msimbo. Njia moja ni "kuzalisha" yaliyomo kwenye hifadhi, kwa kutumia HTTPS, SSH, au kutumia GitHub CLI (Command Line Interface).
Kuna njia kadhaa za kunakili msimbo. Njia moja ni "kuclone" yaliyomo kwenye repo, kwa kutumia HTTPS, SSH, au GitHub CLI (Command Line Interface).
Fungua terminal yako na zalisha hifadhi kama ifuatavyo:
Fungua terminal yako na clone repo kama ifuatavyo:
`git clone https://github.com/ProjectURL`
Ili kufanya kazi kwenye mradi, badilisha hadi kwenye folda sahihi:
Ili kufanya kazi kwenye mradi, nenda kwenye folda sahihi:
`cd ProjectURL`
Unaweza pia kufungua mradi mzima kwa kutumia [Codespaces](https://github.com/features/codespaces), mhariri wa msimbo wa GitHub uliojengwa ndani / mazingira ya maendeleo ya wingu, au [GitHub Desktop](https://desktop.github.com/).
Unaweza pia kufungua mradi mzima kwa kutumia [Codespaces](https://github.com/features/codespaces), mhariri wa msimbo wa GitHub / mazingira ya maendeleo ya wingu, au [GitHub Desktop](https://desktop.github.com/).
Mwisho, unaweza kupakua msimbo katika folda iliyoshinikizwa (zipped).
Mwisho, unaweza kupakua msimbo katika folda iliyobanwa (zipped).
### Mambo machache ya kuvutia kuhusu GitHub
Unaweza kuweka alama ya nyota, kufuatilia, na/au "fork" hifadhi yoyote ya umma kwenye GitHub. Unaweza kupata hifadhi zako ulizoweka alama ya nyota kwenye menyu ya kushuka juu kulia. Ni kama kuweka alama ya kurasa, lakini kwa msimbo.
Unaweza ku-star, ku-watch, na/au "kufork" repo yoyote ya umma kwenye GitHub. Unaweza kupata repo zako ulizo-star kwenye menyu ya kushuka juu kulia. Ni kama kuweka alama ya kurasa, lakini kwa msimbo.
Miradi ina orodha ya masuala, mara nyingi kwenye GitHub katika kichupo cha "Issues" isipokuwa imeonyeshwa vinginevyo, ambapo watu hujadili masuala yanayohusiana na mradi. Na kichupo cha `Pull Requests` ni mahali ambapo watu hujadili na kukagua mabadiliko yanayoendelea.
Miradi ina tracker ya masuala, mara nyingi kwenye GitHub katika tab ya "Issues" isipokuwa imeonyeshwa vinginevyo, ambapo watu wanajadili masuala yanayohusiana na mradi. Na tab ya Pull Requests ni mahali ambapo watu wanajadili na kukagua mabadiliko yanayoendelea.
Miradi inaweza pia kuwa na mijadala kwenye majukwaa, orodha za barua pepe, au njia za mazungumzo kama Slack, Discord au IRC.
Miradi inaweza pia kuwa na majadiliano katika vikao, orodha za barua pepe, au njia za mazungumzo kama Slack, Discord au IRC.
✅ Angalia hifadhi yako mpya ya GitHub na ujaribu mambo kadhaa, kama kuhariri mipangilio, kuongeza taarifa kwenye hifadhi yako, na kuunda mradi (kama bodi ya Kanban). Kuna mengi unaweza kufanya!
✅ Tazama repo yako mpya ya GitHub na jaribu mambo kadhaa, kama kuhariri mipangilio, kuongeza maelezo kwenye repo yako, na kuunda mradi (kama bodi ya Kanban). Kuna mengi unaweza kufanya!
---
## 🚀 Changamoto
## 🚀 Changamoto
Shirikiana na rafiki kufanya kazi kwenye msimbo wa kila mmoja. Unda mradi kwa pamoja, zalisha msimbo, unda matawi, na changanya mabadiliko.
Shirikiana na rafiki kufanya kazi kwenye msimbo wa kila mmoja. Unda mradi kwa kushirikiana, fork msimbo, unda matawi, na unganisha mabadiliko.
## Jaribio la Baada ya Somo
## Jaribio la Baada ya Somo
[Jaribio la baada ya somo](https://ff-quizzes.netlify.app/web/en/)
## Mapitio na Kujisomea
Soma zaidi kuhusu [kuchangia kwenye programu huria](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Soma zaidi kuhusu [kuchangia kwenye programu za open source](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Karatasi ya kumbukumbu ya Git](https://training.github.com/downloads/github-git-cheat-sheet/).
[Cheatsheet ya Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Fanya mazoezi, mazoezi, mazoezi. GitHub ina njia nzuri za kujifunza zinazopatikana kupitia [skills.github.com](https://skills.github.com):
- [Wiki ya Kwanza kwenye GitHub](https://skills.github.com/#first-week-on-github)
Pia utapata kozi za hali ya juu zaidi.
Pia utapata kozi za hali ya juu zaidi.
## Kazi
## Kazi
Kamilisha [kozi ya Wiki ya Kwanza kwenye GitHub](https://skills.github.com/#first-week-on-github)
---
**Kanusho**:
Hati hii imetafsiriwa kwa kutumia huduma ya kutafsiri ya AI [Co-op Translator](https://github.com/Azure/co-op-translator). Ingawa tunajitahidi kuhakikisha usahihi, tafadhali fahamu kuwa tafsiri za kiotomatiki zinaweza kuwa na makosa au kutokuwa sahihi. Hati ya asili katika lugha yake ya awali inapaswa kuzingatiwa kama chanzo cha mamlaka. Kwa taarifa muhimu, tafsiri ya kitaalamu ya binadamu inapendekezwa. Hatutawajibika kwa kutoelewana au tafsiri zisizo sahihi zinazotokana na matumizi ya tafsiri hii.
Hati hii imetafsiriwa kwa kutumia huduma ya tafsiri ya AI [Co-op Translator](https://github.com/Azure/co-op-translator). Ingawa tunajitahidi kuhakikisha usahihi, tafadhali fahamu kuwa tafsiri za kiotomatiki zinaweza kuwa na makosa au kutokuwa sahihi. Hati ya asili katika lugha yake ya awali inapaswa kuchukuliwa kama chanzo cha mamlaka. Kwa taarifa muhimu, tafsiri ya kitaalamu ya binadamu inapendekezwa. Hatutawajibika kwa kutoelewana au tafsiri zisizo sahihi zinazotokana na matumizi ya tafsiri hii.
1. **Combine your work with the `main` branch** ในบางจุดคุณทำงานเสร็จแล้วและต้องการรวมงานของคุณเข้ากับ branch `main` branch `main` อาจมีการเปลี่ยนแปลงในระหว่างนี้ ดังนั้นให้แน่ใจว่าคุณอัปเดต branch`main` ให้เป็นเวอร์ชันล่าสุดด้วยคำสั่งต่อไปนี้:
Ang araling ito ay tumatalakay sa mga pangunahing kaalaman ng GitHub, isang platform para mag-host at mag-manage ng mga pagbabago sa iyong code.
Ang araling ito ay tumatalakay sa mga pangunahing kaalaman sa GitHub, isang platform para mag-host at mag-manage ng mga pagbabago sa iyong code.
> Sketchnote ni [Tomomi Imura](https://twitter.com/girlie_mac)
@ -21,13 +21,13 @@ Ang araling ito ay tumatalakay sa mga pangunahing kaalaman ng GitHub, isang plat
Sa araling ito, tatalakayin natin ang:
- pagsubaybay sa mga gawaing ginagawa mo sa iyong makina
- pagsubaybay sa mga ginagawa mo sa iyong makina
- pakikipagtulungan sa mga proyekto kasama ang iba
- paano mag-ambag sa open source software
### Mga Kinakailangan
Bago magsimula, kailangang tiyakin kung naka-install na ang Git. Sa terminal, i-type:
Bago magsimula, kailangan mong tiyakin kung naka-install na ang Git. Sa terminal, i-type:
`git --version`
Kung hindi pa naka-install ang Git, [i-download ang Git](https://git-scm.com/downloads). Pagkatapos, i-setup ang iyong lokal na Git profile sa terminal:
@ -37,7 +37,7 @@ Kung hindi pa naka-install ang Git, [i-download ang Git](https://git-scm.com/dow
Para suriin kung naka-configure na ang Git, maaari mong i-type:
`git config --list`
Kailangan mo rin ng GitHub account, isang code editor (tulad ng Visual Studio Code), at kailangang buksan ang iyong terminal (o: command prompt).
Kailangan mo rin ng GitHub account, isang code editor (tulad ng Visual Studio Code), at kailangan mong buksan ang iyong terminal (o: command prompt).
Pumunta sa [github.com](https://github.com/) at gumawa ng account kung wala ka pa, o mag-login at punan ang iyong profile.
@ -51,7 +51,7 @@ Kailangan mo ng folder na may code project sa iyong lokal na makina (laptop o PC
## Pamamahala ng Code
Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mong simulan ang pagsubaybay sa iyong progreso gamit ang git - ang version control system. Inihahambing ng ilan ang paggamit ng git sa pagsusulat ng love letter para sa iyong hinaharap na sarili. Sa pagbabasa ng iyong mga commit message makalipas ang ilang araw, linggo, o buwan, maaalala mo kung bakit mo ginawa ang isang desisyon, o "i-rollback" ang isang pagbabago - iyon ay, kung nagsusulat ka ng magagandang "commit messages".
Halimbawa, mayroon kang folder sa lokal na makina na may code project at gusto mong simulan ang pagsubaybay sa iyong progreso gamit ang git - ang version control system. Ang iba ay inihahalintulad ang paggamit ng git sa pagsusulat ng love letter para sa iyong hinaharap na sarili. Sa pagbabasa ng iyong commit messages makalipas ang ilang araw, linggo, o buwan, maaalala mo kung bakit mo ginawa ang isang desisyon, o "rollback" ang isang pagbabago - iyon ay, kung nagsusulat ka ng magagandang "commit messages".
### Gawain: Gumawa ng repository at mag-commit ng code
@ -64,13 +64,13 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
1. Bigyan ng pangalan ang iyong repository (folder)
1. Piliin ang **create repository**.
1. **Pumunta sa iyong working folder**. Sa iyong terminal, lumipat sa folder (kilala rin bilang directory) na nais mong simulan ang pagsubaybay. I-type:
1. **Pumunta sa iyong working folder**. Sa iyong terminal, lumipat sa folder (kilala rin bilang directory) na gusto mong simulan ang pagsubaybay. I-type:
```bash
cd [name of your folder]
```
1. **I-initialize ang git repository**. Sa iyong proyekto, i-type:
1. **I-initialize ang isang git repository**. Sa iyong proyekto, i-type:
```bash
git init
@ -93,7 +93,7 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
modified: file2.txt
```
Karaniwan, ang `git status` command ay nagsasabi ng mga bagay tulad ng kung anong mga file ang handa nang _i-save_ sa repo o may mga pagbabago na maaaring nais mong i-persist.
Karaniwan, ang `git status` command ay nagsasabi ng mga bagay tulad ng kung anong mga file ang handa nang _i-save_ sa repo o may mga pagbabago na maaaring gusto mong i-persist.
1. **Idagdag ang lahat ng file para sa pagsubaybay**
Tinatawag din itong pag-stage ng mga file/pagdaragdag ng mga file sa staging area.
@ -102,7 +102,7 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git add .
```
Ang `git add` kasama ang `.` argument ay nagpapahiwatig na lahat ng iyong mga file at pagbabago ay isasama para sa pagsubaybay.
Ang `git add` kasama ang `.` argument ay nagpapahiwatig na lahat ng iyong mga file at pagbabago ay para sa pagsubaybay.
1. **Idagdag ang mga napiling file para sa pagsubaybay**
@ -118,7 +118,7 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git reset
```
Ang command na ito ay tumutulong upang i-unstage ang lahat ng file nang sabay-sabay.
Ang command na ito ay nakakatulong upang i-unstage ang lahat ng file nang sabay-sabay.
1. **I-unstage ang isang partikular na file**
@ -126,7 +126,7 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git reset [file or folder name]
```
Ang command na ito ay tumutulong upang i-unstage lamang ang isang partikular na file na ayaw mong isama sa susunod na commit.
Ang command na ito ay nakakatulong upang i-unstage lamang ang isang partikular na file na ayaw mong isama sa susunod na commit.
1. **I-persist ang iyong trabaho**. Sa puntong ito, naidagdag mo na ang mga file sa tinatawag na _staging area_. Isang lugar kung saan sinusubaybayan ng Git ang iyong mga file. Para gawing permanente ang pagbabago, kailangan mong _i-commit_ ang mga file. Para gawin ito, gumawa ng _commit_ gamit ang `git commit` command. Ang _commit_ ay kumakatawan sa isang saving point sa kasaysayan ng iyong repo. I-type ang sumusunod para gumawa ng _commit_:
@ -134,11 +134,11 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git commit -m "first commit"
```
Iko-commit nito ang lahat ng iyong mga file, na may mensaheng "first commit". Para sa mga susunod na commit message, mas mabuting maging mas detalyado sa iyong paglalarawan upang maipakita kung anong uri ng pagbabago ang ginawa mo.
Iko-commit nito ang lahat ng iyong mga file, na may mensaheng "first commit". Para sa mga susunod na commit messages, mas mainam na maging mas detalyado sa iyong paglalarawan upang maipahayag kung anong uri ng pagbabago ang ginawa mo.
1. **Ikonekta ang iyong lokal na Git repo sa GitHub**. Ang Git repo ay maganda sa iyong makina ngunit sa isang punto, nais mong magkaroon ng backup ng iyong mga file sa ibang lugar at mag-imbita ng ibang tao na makipagtulungan sa iyong repo. Ang isang mahusay na lugar para gawin ito ay ang GitHub. Tandaan na gumawa na tayo ng repo sa GitHub kaya ang tanging kailangan nating gawin ay ikonekta ang lokal na Git repo sa GitHub. Ang command na `git remote add` ang gagawa nito. I-type ang sumusunod na command:
1. **Ikonekta ang iyong lokal na Git repo sa GitHub**. Ang isang Git repo ay maganda sa iyong makina ngunit sa isang punto, gusto mong magkaroon ng backup ng iyong mga file sa isang lugar at mag-imbita ng ibang tao na makipagtulungan sa iyong repo. Ang isang mahusay na lugar para gawin ito ay ang GitHub. Tandaan na gumawa na tayo ng repo sa GitHub kaya ang tanging kailangan nating gawin ay ikonekta ang lokal na Git repo sa GitHub. Ang command na `git remote add` ang gagawa nito. I-type ang sumusunod na command:
> Tandaan, bago i-type ang command, pumunta sa iyong GitHub repo page upang hanapin ang repository URL. Gagamitin mo ito sa command sa ibaba. Palitan ang ```https://github.com/username/repository_name.git``` ng iyong GitHub URL.
> Tandaan, bago mo i-type ang command, pumunta sa iyong GitHub repo page upang hanapin ang repository URL. Gagamitin mo ito sa command sa ibaba. Palitan ang ```https://github.com/username/repository_name.git``` ng iyong GitHub URL.
@ -146,7 +146,7 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
Gumagawa ito ng _remote_, o koneksyon, na pinangalanang "origin" na tumuturo sa GitHub repository na ginawa mo kanina.
1. **Ipadala ang mga lokal na file sa GitHub**. Sa ngayon, gumawa ka ng _connection_ sa pagitan ng lokal na repo at ng GitHub repo. Ipadala ang mga file na ito sa GitHub gamit ang sumusunod na command na `git push`, ganito:
1. **Ipadala ang mga lokal na file sa GitHub**. Sa ngayon, gumawa ka ng _connection_ sa pagitan ng lokal na repo at ng GitHub repo. Ipadala natin ang mga file na ito sa GitHub gamit ang sumusunod na command na `git push`, ganito:
> Tandaan, maaaring iba ang pangalan ng iyong branch sa default na ```main```.
@ -154,9 +154,9 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git push -u origin main
```
Ipinapadala nito ang iyong mga commit sa iyong "main" branch sa GitHub.
Ipinapadala nito ang iyong mga commits sa iyong "main" branch sa GitHub. Ang pag-set ng `upstream` branch kabilang ang `-u` sa command ay nagtatatag ng link sa pagitan ng iyong lokal na branch at ng remote branch, kaya maaari mong gamitin ang git push o git pull nang hindi tinutukoy ang pangalan ng branch sa hinaharap. Awtomatikong gagamitin ng Git ang upstream branch at hindi mo na kailangang tukuyin ang pangalan ng branch sa mga susunod na command.
2. **Magdagdag ng higit pang mga pagbabago**. Kung nais mong magpatuloy sa paggawa ng mga pagbabago at i-push ang mga ito sa GitHub, kakailanganin mo lamang gamitin ang sumusunod na tatlong command:
2. **Para magdagdag ng higit pang mga pagbabago**. Kung gusto mong magpatuloy sa paggawa ng mga pagbabago at i-push ang mga ito sa GitHub, kakailanganin mo lang gamitin ang sumusunod na tatlong command:
```bash
git add .
@ -164,9 +164,9 @@ Halimbawa, mayroon kang folder sa lokal na makina na may code project at nais mo
git push
```
> Tip, Maaaring nais mo ring gumamit ng `.gitignore` file upang maiwasan ang mga file na ayaw mong i-track na lumitaw sa GitHub - tulad ng notes file na iniimbak mo sa parehong folder ngunit walang lugar sa pampublikong repository. Maaari kang makahanap ng mga template para sa `.gitignore` files sa [.gitignore templates](https://github.com/github/gitignore).
> Tip, Maaaring gusto mo ring gumamit ng `.gitignore` file upang maiwasan ang mga file na ayaw mong i-track na lumitaw sa GitHub - tulad ng notes file na iniimbak mo sa parehong folder ngunit walang lugar sa isang pampublikong repository. Maaari kang makahanap ng mga template para sa `.gitignore` files sa [.gitignore templates](https://github.com/github/gitignore).
#### Mga Commit Message
#### Mga Commit Messages
Ang isang mahusay na Git commit subject line ay kumukumpleto sa sumusunod na pangungusap:
Kung ilalapat, ang commit na ito ay <angiyongsubjectlinedito>
@ -174,7 +174,7 @@ Kung ilalapat, ang commit na ito ay <ang iyong subject line dito>
Para sa subject, gamitin ang imperative, present tense: "change" hindi "changed" o "changes".
Tulad ng sa subject, sa body (opsyonal) ay gamitin din ang imperative, present tense. Ang body ay dapat maglaman ng motibasyon para sa pagbabago at ikumpara ito sa nakaraang behavior. Ipinaliwanag mo ang `bakit`, hindi ang `paano`.
✅ Maglaan ng ilang minuto upang mag-surf sa GitHub. Makakakita ka ba ng isang talagang mahusay na commit message? Makakakita ka ba ng isang talagang minimal na mensahe? Anong impormasyon ang sa tingin mo ay pinakamahalaga at kapaki-pakinabang na ipahayag sa isang commit message?
✅ Maglaan ng ilang minuto upang mag-surf sa GitHub. Makakakita ka ba ng isang talagang mahusay na commit message? Makakakita ka ba ng isang talagang minimal na isa? Anong impormasyon ang sa tingin mo ay pinakamahalaga at kapaki-pakinabang na ipahayag sa isang commit message?
### Gawain: Makipagtulungan
@ -195,26 +195,26 @@ Sa iyong repository, pumunta sa `Insights > Community` upang makita kung paano i
- **Code of Conduct**. Mayroon bang [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
- **License**. Marahil ang pinakamahalaga, isang [license](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Ang lahat ng mga resource na ito ay makakatulong sa onboarding ng mga bagong miyembro ng team. At ang mga ito ay karaniwang ang uri ng mga bagay na tinitingnan ng mga bagong contributor bago pa man tingnan ang iyong code, upang malaman kung ang iyong proyekto ay ang tamang lugar para sa kanila upang gugulin ang kanilang oras.
Ang lahat ng mga resource na ito ay makikinabang sa onboarding ng mga bagong miyembro ng team. At ang mga ito ay karaniwang ang uri ng mga bagay na tinitingnan ng mga bagong contributor bago pa man tingnan ang iyong code, upang malaman kung ang iyong proyekto ay ang tamang lugar para sa kanila upang gugulin ang kanilang oras.
✅ Ang mga README file, bagama't nangangailangan ng oras upang ihanda, ay madalas na napapabayaan ng mga abalang maintainer. Makakakita ka ba ng halimbawa ng isang partikular na deskriptibong README? Tandaan: may ilang [tools para tumulong gumawa ng magagandang README](https://www.makeareadme.com/) na maaaring gusto mong subukan.
### Gawain: Mag-merge ng code
Ang mga contributing docs ay tumutulong sa mga tao na mag-ambag sa proyekto. Ipinaliwanag nito kung anong uri ng mga kontribusyon ang hinahanap mo at kung paano gumagana ang proseso. Kailangang dumaan ang mga contributor sa isang serye ng mga hakbang upang makapag-ambag sa iyong repo sa GitHub:
Ang mga contributing docs ay tumutulong sa mga tao na mag-ambag sa proyekto. Ipinaliwanag nito kung anong uri ng mga kontribusyon ang hinahanap mo at kung paano gumagana ang proseso. Ang mga contributor ay kailangang dumaan sa isang serye ng mga hakbang upang makapag-ambag sa iyong repo sa GitHub:
1. **Forking ng iyong repo**. Malamang na nais mong ipa-fork ang iyong proyekto sa mga tao. Ang forking ay nangangahulugan ng paggawa ng replika ng iyong repository sa kanilang GitHub profile.
1. **Forking ng iyong repo**. Malamang na gusto mong mag-_fork_ ang mga tao sa iyong proyekto. Ang pag-fork ay nangangahulugan ng paggawa ng replika ng iyong repository sa kanilang GitHub profile.
1. **Clone**. Mula doon, i-clone nila ang proyekto sa kanilang lokal na makina.
1. **Gumawa ng branch**. Nais mong hilingin sa kanila na gumawa ng _branch_ para sa kanilang trabaho.
1. **Mag-focus sa isang lugar ng pagbabago**. Hilingin sa mga contributor na ituon ang kanilang kontribusyon sa isang bagay lamang sa bawat pagkakataon - sa ganitong paraan, mas mataas ang tsansa na ma-merge ang kanilang trabaho. Halimbawa, gumawa sila ng bug fix, magdagdag ng bagong feature, at mag-update ng ilang tests - paano kung nais mo, o maaari lamang i-implement ang 2 sa 3, o 1 sa 3 pagbabago?
1. **Gumawa ng branch**. Gusto mong hilingin sa kanila na gumawa ng _branch_ para sa kanilang trabaho.
1. **Mag-focus sa isang lugar ng pagbabago**. Hilingin sa mga contributor na ituon ang kanilang kontribusyon sa isang bagay lamang sa bawat pagkakataon - sa ganitong paraan, mas mataas ang tsansa na ma-_merge_ ang kanilang trabaho. Halimbawa, nagsulat sila ng bug fix, nagdagdag ng bagong feature, at nag-update ng ilang tests - paano kung gusto mo, o maaari mo lamang i-implement ang 2 sa 3, o 1 sa 3 pagbabago?
✅ Mag-isip ng sitwasyon kung saan ang mga branch ay partikular na mahalaga sa pagsusulat at pagpapadala ng magandang code. Anong mga use case ang naiisip mo?
> Tandaan, maging ang pagbabago na nais mong makita sa mundo, at gumawa ng mga branch para sa iyong sariling trabaho. Ang anumang mga commit na gagawin mo ay gagawin sa branch na kasalukuyan mong "checked out". Gamitin ang `git status` upang makita kung aling branch iyon.
> Tandaan, maging ang pagbabago na gusto mong makita sa mundo, at gumawa ng mga branch para sa iyong sariling trabaho. Ang anumang mga commit na gagawin mo ay gagawin sa branch na kasalukuyan mong "checked out". Gamitin ang `git status` upang makita kung aling branch iyon.
Dumaan tayo sa workflow ng isang contributor. Ipagpalagay na ang contributor ay na-fork at na-clone na ang repo kaya mayroon silang Git repo na handang trabahuin, sa kanilang lokal na makina:
Dumaan tayo sa workflow ng isang contributor. Ipagpalagay na ang contributor ay nag-_fork_ at nag-_clone_ na ng repo kaya mayroon silang Git repo na handa nang trabahuin, sa kanilang lokal na makina:
1. **Gumawa ng branch**. Gamitin ang command na `git branch` upang gumawa ng branch na maglalaman ng mga pagbabago na nais nilang i-ambag:
1. **Gumawa ng branch**. Gamitin ang command na `git branch` upang gumawa ng branch na maglalaman ng mga pagbabago na balak nilang i-ambag:
```bash
git branch [branch-name]
@ -226,30 +226,35 @@ Dumaan tayo sa workflow ng isang contributor. Ipagpalagay na ang contributor ay
git switch [branch-name]
```
1. **Gumawa ng trabaho**. Sa puntong ito, nais mong idagdag ang iyong mga pagbabago. Huwag kalimutang ipaalam ito sa Git gamit ang mga sumusunod na command:
1. **Gumawa ng trabaho**. Sa puntong ito, gusto mong idagdag ang iyong mga pagbabago. Huwag kalimutang ipaalam ito sa Git gamit ang mga sumusunod na command:
```bash
git add .
git commit -m "my changes"
```
Tiyaking bigyan ang iyong commit ng magandang pangalan, para sa iyong kapakanan pati na rin sa maintainer ng repo na iyong tinutulungan.
Tiyaking bibigyan mo ang iyong commit ng magandang pangalan, para sa iyong kapakanan pati na rin sa maintainer ng repo na tinutulungan mo.
1. **Pagsamahin ang iyong trabaho sa `main` branch**. Sa isang punto, tapos ka na sa paggawa at nais mong pagsamahin ang iyong trabaho sa `main` branch. Ang `main` branch ay maaaring nagbago sa pagitan kaya tiyaking i-update muna ito sa pinakabago gamit ang mga sumusunod na command:
1. **Pagsamahin ang iyong trabaho sa `main` branch**. Sa isang punto, tapos ka na sa paggawa at gusto mong pagsamahin ang iyong trabaho sa `main` branch. Ang `main` branch ay maaaring nagbago sa pagitan kaya siguraduhing i-update muna ito sa pinakabago gamit ang mga sumusunod na command:
```bash
git switch main
git pull
```
Sa puntong ito, nais mong tiyakin na ang anumang _conflicts_, mga sitwasyon kung saan hindi madaling ma-_combine_ ng Git ang mga pagbabago, ay mangyayari sa iyong working branch. Kaya't patakbuhin ang mga sumusunod na command:
Sa puntong ito, gusto mong tiyakin na anumang _conflicts_, mga sitwasyon kung saan hindi madaling ma-_combine_ ng Git ang mga pagbabago, ay mangyayari sa iyong working branch. Kaya't patakbuhin ang mga sumusunod na command:
```bash
git switch [branch_name]
git merge main
```
Dadalhin nito ang lahat ng pagbabago mula sa `main` papunta sa iyong branch at sana ay maaari kang magpatuloy. Kung hindi, ipapakita sa iyo ng VS Code kung saan nalilito ang Git at babaguhin mo lang ang mga apektadong file upang sabihin kung aling content ang pinaka-tama.
Ang `git merge main` command ay magdadala ng lahat ng pagbabago mula sa `main` papunta sa iyong branch. Sana ay maaari kang magpatuloy. Kung hindi, sasabihin sa iyo ng VS Code kung saan nalilito ang Git at babaguhin mo lang ang mga apektadong file upang sabihin kung aling content ang pinaka-tama.
Para lumipat sa ibang branch, gamitin ang modernong `git switch` command:
```bash
git switch [branch_name]
1. **Ipadala ang iyong trabaho sa GitHub**. Ang pagpapadala ng iyong trabaho sa GitHub ay nangangahulugan ng dalawang bagay. Ang pag-push ng iyong branch sa iyong repo at pagkatapos ay magbukas ng PR, Pull Request.
@ -258,55 +263,55 @@ Dumaan tayo sa workflow ng isang contributor. Ipagpalagay na ang contributor ay
```
Ang command sa itaas ay lumilikha ng branch sa iyong forked repo.
1. **Magbukas ng PR**. Susunod, gusto mong magbukas ng PR. Magagawa mo ito sa pamamagitan ng pagpunta sa forked na repo sa GitHub. Makikita mo ang indikasyon sa GitHub kung saan tinatanong kung gusto mong gumawa ng bagong PR, i-click mo iyon at dadalhin ka sa interface kung saan maaari mong baguhin ang pamagat ng commit message, magbigay ng mas angkop na deskripsyon. Ngayon, makikita ng maintainer ng repo na iyong na-fork ang PR na ito at _sana_ ma-appreciate nila at _i-merge_ ang iyong PR. Isa ka nang contributor, yay :)
1. **Magbukas ng PR**. Susunod, nais mong magbukas ng PR. Gawin ito sa pamamagitan ng pagpunta sa forked repo sa GitHub. Makikita mo ang indikasyon sa GitHub kung saan tinatanong kung nais mong gumawa ng bagong PR, i-click mo iyon at dadalhin ka sa interface kung saan maaari mong baguhin ang commit message title, bigyan ito ng mas angkop na paglalarawan. Ngayon makikita ng maintainer ng repo na iyong na-fork ang PR na ito at _fingers crossed_ maa-appreciate nila at _merge_ ang iyong PR. Isa ka nang contributor, yay :)
1. **Linisin ang trabaho**. Itinuturing na magandang kasanayan ang _linisin_ ang iyong trabaho pagkatapos mong matagumpay na ma-merge ang isang PR. Nais mong linisin ang parehong lokal na branch at ang branch na iyong na-push sa GitHub. Una, tanggalin ito nang lokal gamit ang sumusunod na command:
1. **Linisin ang branch**. Itinuturing na magandang praktis ang _linisin_ ang branch pagkatapos mong matagumpay na ma-merge ang isang PR. Gusto mong linisin ang parehong lokal na branch at ang branch na iyong na-push sa GitHub. Una, burahin ito sa lokal gamit ang sumusunod na command:
```bash
git branch -d [branch-name]
```
Tiyaking pumunta sa GitHub page ng forked repo at tanggalin ang remote branch na iyong na-push dito.
`Pull request` ay tila isang nakakatawang termino dahil sa totoo lang, nais mong i-push ang iyong mga pagbabago sa proyekto. Ngunit kailangang suriin ng maintainer (may-ari ng proyekto) o core team ang iyong mga pagbabago bago ito pagsamahin sa "main" branch ng proyekto, kaya't sa esensya, humihiling ka ng desisyon mula sa maintainer tungkol sa iyong pagbabago.
Siguraduhing pumunta sa GitHub page ng forked na repo at tanggalin ang remote branch na iyong na-push dito.
Ang `Pull request` ay tila nakakatawang termino dahil ang totoo ay gusto mong i-push ang iyong mga pagbabago sa proyekto. Ngunit ang maintainer (may-ari ng proyekto) o core team ay kailangang suriin ang iyong mga pagbabago bago ito i-merge sa "main" branch ng proyekto, kaya't talagang humihiling ka ng desisyon sa pagbabago mula sa maintainer.
Ang pull request ay isang lugar kung saan maaaring ikumpara at talakayin ang mga pagkakaiba na ipinakilala sa isang branch gamit ang mga review, komento, integrated tests, at iba pa. Ang isang mahusay na pull request ay sumusunod sa halos parehong mga patakaran tulad ng isang commit message. Maaari kang magdagdag ng reference sa isang isyu sa issue tracker, halimbawa kung ang iyong trabaho ay nag-aayos ng isang isyu. Ginagawa ito gamit ang `#` na sinusundan ng numero ng iyong isyu. Halimbawa:`#97`.
Ang pull request ay lugar kung saan maikukumpara at mapag-uusapan ang mga pagkakaiba na idinagdag sa isang branch gamit ang mga review, komento, integrated tests, at iba pa. Ang isang mahusay na pull request ay sumusunod sa halos parehong mga patakaran tulad ng commit message. Maaari kang magdagdag ng reference sa isang isyu sa issue tracker, halimbawa kung ang iyong trabaho ay nag-aayos ng isang isyu. Ginagawa ito gamit ang `#` na sinusundan ng numero ng iyong isyu. Halimbawa,`#97`.
🤞Sana'y pumasa ang lahat ng pagsusuri at ma-merge ng may-ari ng proyekto ang iyong mga pagbabago sa proyekto🤞
🤞Sana pumasa ang lahat ng checks at i-merge ng may-ari ng proyekto ang iyong mga pagbabago sa proyekto🤞
I-update ang kasalukuyang lokal na working branch gamit ang lahat ng bagong commit mula sa kaukulang remote branch sa GitHub:
I-update ang kasalukuyang lokal na working branch gamit ang lahat ng bagong commits mula sa kaukulang remote branch sa GitHub:
`git pull`
## Paano mag-ambag sa open source
## Paano mag-contribute sa open source
Una, maghanap ng repository (o **repo**) sa GitHub na interesado ka at nais mong ambagan ng pagbabago. Kakailanganin mong kopyahin ang nilalaman nito sa iyong makina.
Una, maghanap ng repository (o **repo**) sa GitHub na interesado ka at gusto mong magdagdag ng pagbabago. Gusto mong kopyahin ang nilalaman nito sa iyong makina.
✅ Isang magandang paraan upang makahanap ng mga 'beginner-friendly' na repo ay ang [maghanap gamit ang tag na 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Isang magandang paraan para makahanap ng 'beginner-friendly' na mga repo ay ang [maghanap gamit ang tag na 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
May ilang paraan upang makopya ang code. Isa sa mga ito ay ang "i-clone" ang nilalaman ng repository gamit ang HTTPS, SSH, o ang GitHub CLI (Command Line Interface).
May ilang paraan para makopya ang code. Isa sa mga paraan ay ang "i-clone" ang nilalaman ng repository, gamit ang HTTPS, SSH, o ang GitHub CLI (Command Line Interface).
Buksan ang iyong terminal at i-clone ang repository tulad nito:
`git clone https://github.com/ProjectURL`
Upang magtrabaho sa proyekto, lumipat sa tamang folder:
Para magtrabaho sa proyekto, pumunta sa tamang folder:
`cd ProjectURL`
Maaari mo ring buksan ang buong proyekto gamit ang [Codespaces](https://github.com/features/codespaces), ang embedded code editor / cloud development environment ng GitHub, o [GitHub Desktop](https://desktop.github.com/).
Sa huli, maaari mo ring i-download ang code sa isang naka-zip na folder.
Sa huli, maaari mong i-download ang code sa isang zipped folder.
### Ilang mga kawili-wiling bagay tungkol sa GitHub
Maaari kang mag-star, mag-watch, at/o "fork" ng anumang pampublikong repository sa GitHub. Makikita mo ang iyong mga starred repository sa drop-down menu sa kanang-itaas. Para itong pag-bookmark, pero para sa code.
Maaari kang mag-star, mag-watch, at/o "mag-fork" ng anumang pampublikong repository sa GitHub. Makikita mo ang iyong mga starred repositories sa drop-down menu sa kanang itaas. Para itong pag-bookmark, pero para sa code.
Ang mga proyekto ay may issue tracker, kadalasan sa GitHub sa tab na "Issues" maliban kung may ibang indikasyon, kung saan tinatalakay ng mga tao ang mga isyung may kaugnayan sa proyekto. At ang tab na Pull Requests ay kung saan tinatalakay at nire-review ang mga pagbabagong ginagawa.
Ang mga proyekto ay may issue tracker, kadalasan sa GitHub sa tab na "Issues" maliban kung may ibang indikasyon, kung saan pinag-uusapan ng mga tao ang mga isyu na may kaugnayan sa proyekto. At ang tab na Pull Requests ay kung saan pinag-uusapan at nire-review ang mga pagbabago na nasa proseso.
Ang mga proyekto ay maaaring may mga talakayan sa forums, mailing lists, o chat channels tulad ng Slack, Discord, o IRC.
Ang mga proyekto ay maaaring may diskusyon sa mga forum, mailing lists, o chat channels tulad ng Slack, Discord, o IRC.
✅ Maglibot sa iyong bagong GitHub repo at subukan ang ilang bagay, tulad ng pag-edit ng mga setting, pagdaragdag ng impormasyon sa iyong repo, at paggawa ng proyekto (tulad ng isang Kanban board). Maraming magagawa!
✅ Tingnan ang paligid ng iyong bagong GitHub repo at subukan ang ilang bagay, tulad ng pag-edit ng mga setting, pagdaragdag ng impormasyon sa iyong repo, at paggawa ng proyekto (tulad ng isang Kanban board). Maraming magagawa!
---
@ -317,23 +322,23 @@ Makipag-partner sa isang kaibigan upang magtrabaho sa code ng isa't isa. Gumawa
Practice, practice, practice. May mga mahusay na learning paths ang GitHub na makikita sa [skills.github.com](https://skills.github.com):
Practice, practice, practice. May magagandang learning paths ang GitHub na makikita sa [skills.github.com](https://skills.github.com):
- [First Week on GitHub](https://skills.github.com/#first-week-on-github)
Makakahanap ka rin ng mas advanced na mga kurso.
Makakakita ka rin ng mas advanced na mga kurso.
## Takdang-Aralin
## Assignment
Kumpletuhin ang [First Week on GitHub course](https://skills.github.com/#first-week-on-github)
---
**Paunawa**:
Ang dokumentong ito ay isinalin gamit ang AI translation service na [Co-op Translator](https://github.com/Azure/co-op-translator). Bagama't sinisikap naming maging tumpak, pakitandaan na ang mga awtomatikong pagsasalin ay maaaring maglaman ng mga pagkakamali o hindi pagkakatugma. Ang orihinal na dokumento sa orihinal nitong wika ang dapat ituring na opisyal na sanggunian. Para sa mahalagang impormasyon, inirerekomenda ang propesyonal na pagsasalin ng tao. Hindi kami mananagot sa anumang hindi pagkakaunawaan o maling interpretasyon na dulot ng paggamit ng pagsasaling ito.
Ang dokumentong ito ay isinalin gamit ang AI translation service na [Co-op Translator](https://github.com/Azure/co-op-translator). Bagama't sinisikap naming maging tumpak, mangyaring tandaan na ang mga awtomatikong pagsasalin ay maaaring maglaman ng mga pagkakamali o hindi pagkakatugma. Ang orihinal na dokumento sa kanyang katutubong wika ang dapat ituring na opisyal na pinagmulan. Para sa mahalagang impormasyon, inirerekomenda ang propesyonal na pagsasalin ng tao. Hindi kami mananagot sa anumang hindi pagkakaunawaan o maling interpretasyon na dulot ng paggamit ng pagsasaling ito.
Git'in zaten yapılandırılmış olup olmadığını kontrol etmek için şu komutu yazabilirsiniz:
Git'in zaten yapılandırılmış olup olmadığını kontrol etmek için şu komutu yazabilirsiniz:
`git config --list`
Ayrıca bir GitHub hesabına, bir kod düzenleyiciye (örneğin Visual Studio Code) ve terminalinizi (veya komut istemcisini) açmanız gerekecek.
Ayrıca bir GitHub hesabına, bir kod düzenleyiciye (örneğin Visual Studio Code) ve terminalinizi (veya komut istemini) açmanız gerekecek.
[github.com](https://github.com/) adresine gidin ve henüz bir hesabınız yoksa bir hesap oluşturun ya da giriş yaparak profilinizi doldurun.
[github.com](https://github.com/) adresine gidin ve henüz yapmadıysanız bir hesap oluşturun veya giriş yaparak profilinizi doldurun.
✅ GitHub, dünyadaki tek kod deposu değildir; başka seçenekler de vardır, ancak GitHub en bilinenidir.
✅ GitHub dünyadaki tek kod deposu değildir; başka seçenekler de vardır, ancak GitHub en bilinenidir.
### Hazırlık
Yerel makinenizde (dizüstü bilgisayar veya PC) bir kod projesi içeren bir klasöre ve başkalarının projelerine nasıl katkıda bulunacağınızı göstermek için bir örnek olarak kullanılacak bir GitHub'da halka açık bir depoya ihtiyacınız olacak.
Yerel makinenizde (laptop veya PC) bir kod projesi içeren bir klasöre ve başkalarının projelerine nasıl katkıda bulunacağınızı göstermek için bir örnek olarak kullanılacak bir GitHub'da halka açık bir depoya ihtiyacınız olacak.
---
## Kod Yönetimi
Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlemenizi Git - sürüm kontrol sistemi - kullanarak takip etmeye başlamak istiyorsunuz. Bazı insanlar Git kullanmayı, gelecekteki kendinize bir aşk mektubu yazmaya benzetir. Günler, haftalar veya aylar sonra commit mesajlarınızı okuduğunuzda, neden bir karar verdiğinizi hatırlayabilir veya bir değişikliği "geri alabilirsiniz" - tabii ki iyi "commit mesajları" yazdığınızda.
Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlemenizi Git - sürüm kontrol sistemi - kullanarak takip etmek istiyorsunuz. Bazı insanlar Git kullanmayı gelecekteki kendinize bir aşk mektubu yazmaya benzetir. Günler, haftalar veya aylar sonra commit mesajlarınızı okuduğunuzda neden bir karar verdiğinizi hatırlayabilir veya bir değişikliği "geri alabilirsiniz" - tabii ki iyi "commit mesajları" yazdığınızda.
### Görev: Bir Depo Oluşturun ve Kodu Commit Edin
### Görev: Bir depo oluşturun ve kodu commit edin
> Videoyu izleyin
> Videoyu izleyin
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **GitHub'da bir depo oluşturun**. GitHub.com'da, depolar sekmesinde veya sağ üstteki gezinme çubuğundan **yeni depo** düğmesini bulun.
1. Depoya bir ad verin.
1. Depoya (klasöre) bir ad verin.
1. **Depo oluştur** seçeneğini seçin.
1. **Çalışma klasörünüze gidin**. Terminalinizde, takip etmek istediğiniz klasöre (dizin olarak da bilinir) geçin. Şunu yazın:
1. **Çalışma klasörünüze gidin**. Terminalinizde, takip etmek istediğiniz klasöre (dizin olarak da bilinir) geçin. Şu komutu yazın:
1. **Bir git deposu başlatın**. Projenizde şu komutu yazın:
```bash
git init
```
1. **Durumu kontrol edin**. Depo durumunu kontrol etmek için şunu yazın:
1. **Durumu kontrol edin**. Depo durumunu kontrol etmek için şu komutu yazın:
```bash
git status
@ -93,9 +93,9 @@ Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlem
modified: file2.txt
```
Genellikle `git status` komutu, depoya _kaydedilmeye_ hazır olan veya üzerinde değişiklik yapılan dosyalar gibi bilgileri size söyler.
Genellikle `git status` komutu, repo için _kaydedilmeye hazır_ olan dosyalar veya üzerinde değişiklik yapılmış ve kalıcı hale getirilmesi gereken dosyalar gibi bilgileri verir.
1. **Tüm dosyaları takibe ekleyin**
1. **Tüm dosyaları takibe ekleyin**
Bu işlem, dosyaları sahneleme alanına eklemek olarak da adlandırılır.
```bash
@ -110,7 +110,7 @@ Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlem
git add [file or folder name]
```
Bu, tüm dosyaları bir kerede commit etmek istemediğinizde yalnızca seçili dosyaları sahneleme alanına eklemenize yardımcı olur.
Bu komut, tüm dosyaları bir kerede commit etmek istemediğinizde yalnızca seçili dosyaları sahneleme alanına eklemenize yardımcı olur.
1. **Tüm dosyaları sahneleme alanından çıkarın**
@ -126,9 +126,9 @@ Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlem
git reset [file or folder name]
```
Bu komut, yalnızca belirli bir dosyayı sahneleme alanından çıkarmanıza yardımcı olur.
Bu komut, yalnızca bir dosyayı sahneleme alanından çıkarmanıza yardımcı olur.
1. **Çalışmanızı kalıcı hale getirin**. Bu noktada dosyaları_sahneleme alanına_ eklediniz. Git'in dosyalarınızı takip ettiği bir yer. Değişikliği kalıcı hale getirmek için dosyaları_commit_ etmeniz gerekir. Bunu yapmak için `git commit` komutunu kullanarak bir _commit_ oluşturun. Bir _commit_, deponuzun geçmişinde bir kayıt noktasıdır. Bir _commit_ oluşturmak için şunu yazın:
1. **Çalışmanızı kalıcı hale getirin**. Bu noktada dosyaları_sahneleme alanına_ eklediniz. Git dosyalarınızı burada takip ediyor. Değişikliği kalıcı hale getirmek için dosyaları_commit_ etmeniz gerekiyor. Bunu yapmak için `git commit` komutunu kullanarak bir _commit_ oluşturun. Bir _commit_, depo geçmişinizde bir kayıt noktasıdır. Şu komutu yazarak bir _commit_ oluşturun:
```bash
git commit -m "first commit"
@ -136,27 +136,27 @@ Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlem
Bu, tüm dosyalarınızı "ilk commit" mesajıyla commit eder. Gelecekteki commit mesajlarınızda, yaptığınız değişiklik türünü açıklamak için daha açıklayıcı bir açıklama kullanmak isteyeceksiniz.
1. **Yerel Git deponuzu GitHub ile bağlayın**. Bir Git deposu makinenizde iyidir, ancak bir noktada dosyalarınızın bir yedeğini bir yerde almak ve ayrıca diğer insanları deponuzda sizinle çalışmaya davet etmek istersiniz. Bunu yapabileceğiniz harika bir yer GitHub'dır. Daha önce GitHub'da bir depo oluşturduğumuzu hatırlayın, bu yüzden yapmamız gereken tek şey yerel Git depomuzu GitHub ile bağlamaktır. `git remote add` komutu bunu yapacaktır. Şu komutu yazın:
1. **Yerel Git deponuzu GitHub ile bağlayın**. Bir Git deposu makinenizde iyidir, ancak bir noktada dosyalarınızın bir yedeğini bir yerde tutmak ve ayrıca başkalarını deponuzda sizinle çalışmaya davet etmek isteyeceksiniz. Bunun için harika bir yer GitHub'dır. Daha önce GitHub'da bir depo oluşturduğumuzu hatırlayın, bu yüzden yapmamız gereken tek şey yerel Git depomuzu GitHub ile bağlamaktır. `git remote add` komutu bunu yapacaktır. Şu komutu yazın:
> Not: Komutu yazmadan önce GitHub depo sayfanıza gidin ve depo URL'sini bulun. Aşağıdaki komutta ```https://github.com/username/repository_name.git``` yerine GitHub URL'nizi kullanın.
> Not: Komutu yazmadan önce GitHub depo sayfanıza giderek depo URL'sini bulun. Aşağıdaki komutta bu URL'yi kullanacaksınız. ```https://github.com/kullanıcı_adı/depo_adı.git``` kısmını GitHub URL'nizle değiştirin.
Bu, daha önce oluşturduğunuz GitHub deposunu işaret eden "origin" adlı bir _uzaktan bağlantı_ oluşturur.
Bu, daha önce oluşturduğunuz GitHub deposuna işaret eden "origin" adlı bir _uzaktan bağlantı_ oluşturur.
1. **Yerel dosyaları GitHub'a gönderin**. Şimdiye kadar yerel depo ile GitHub deposu arasında bir _bağlantı_ oluşturduk. Bu dosyaları GitHub'a göndermek için şu komutu kullanın:
> Not: Varsayılan olarak dal adınız ```main```'den farklı olabilir.
1. **Yerel dosyaları GitHub'a gönderin**. Şimdiye kadar yerel depo ile GitHub deposu arasında bir _bağlantı_ oluşturduk. Bu dosyaları GitHub'a göndermek için `git push` komutunu şu şekilde kullanın:
> Not: Varsayılan dal adınız ```main```den farklı olabilir.
```bash
git push -u origin main
```
Bu, "main" dalınızdaki commit'lerinizi GitHub'a gönderir.
Bu, "main" dalınızdaki commit'lerinizi GitHub'a gönderir. Komutta `-u` ile birlikte `upstream` dalını ayarlamak, yerel dalınız ile uzak dal arasında bir bağlantı kurar, böylece gelecekte dal adını belirtmeden git push veya git pull komutlarını kullanabilirsiniz. Git, otomatik olarak upstream dalını kullanır ve gelecekteki komutlarda dal adını açıkça belirtmeniz gerekmez.
2. **Daha fazla değişiklik eklemek için**. Değişiklik yapmaya ve bunları GitHub'a göndermeye devam etmek istiyorsanız, şu üç komutu kullanmanız yeterlidir:
2. **Daha fazla değişiklik eklemek**. Değişiklik yapmaya ve bunları GitHub'a göndermeye devam etmek istiyorsanız, sadece şu üç komutu kullanmanız yeterli olacaktır:
```bash
git add .
@ -164,17 +164,17 @@ Diyelim ki yerel olarak bir kod projesi içeren bir klasörünüz var ve ilerlem
git push
```
> İpucu: `.gitignore` dosyasını benimsemek isteyebilirsiniz. Bu, GitHub'da takip etmek istemediğiniz dosyaların görünmesini engeller - örneğin, aynı klasörde sakladığınız ancak bir genel depoda yeri olmayan not dosyası gibi. `.gitignore` dosyaları için şablonları [.gitignore templates](https://github.com/github/gitignore) adresinde bulabilirsiniz.
> İpucu: `.gitignore` dosyasını benimsemek isteyebilirsiniz. Bu dosya, GitHub'da takip etmek istemediğiniz dosyaların görünmesini engeller - örneğin, aynı klasörde sakladığınız ancak halka açık bir depoda yeri olmayan notlar dosyası. `.gitignore` dosyaları için şablonları [.gitignore şablonları](https://github.com/github/gitignore) adresinde bulabilirsiniz.
#### Commit Mesajları
Harika bir Git commit başlık satırı şu cümleyi tamamlar:
Eğer uygulanırsa, bu commit <burayabaşlıksatırınız> yapacaktır.
Harika bir Git commit başlık satırı şu cümleyi tamamlar:
Eğer uygulanırsa, bu commit <burayabaşlıksatırınızıyazın> yapacaktır.
Başlık için emir kipinde, şimdiki zamanı kullanın: "değiştir" (changed veya changes değil).
Başlıkta olduğu gibi, gövdede (isteğe bağlı) de emir kipinde, şimdiki zamanı kullanın. Gövde, değişikliğin motivasyonunu ve bunu önceki davranışla karşılaştırmayı içermelidir. `Neden`i açıklıyorsunuz, `nasıl`ı değil.
Başlıkta emir kipini ve şimdiki zamanı kullanın: "değiştir" değil "değiştirildi" veya "değişiklikler".
Başlıkta olduğu gibi, gövdede (isteğe bağlı) de emir kipini ve şimdiki zamanı kullanın. Gövde, değişikliğin motivasyonunu ve bunu önceki davranışla karşılaştırmayı içermelidir. `neden`i açıklıyorsunuz, `nasıl`ı değil.
✅ GitHub'da biraz dolaşmak için birkaç dakikanızı ayırın. Gerçekten harika bir commit mesajı bulabilir misiniz? Çok minimal bir tane bulabilir misiniz? Commit mesajında iletilmesi gereken en önemli ve faydalı bilgilerin neler olduğunu düşünüyorsunuz?
✅ GitHub'da biraz gezinin. Harika bir commit mesajı bulabilir misiniz? Çok minimal bir tane bulabilir misiniz? Sizce commit mesajında iletilmesi gereken en önemli ve faydalı bilgi nedir?
### Görev: İşbirliği Yapın
@ -182,51 +182,51 @@ GitHub'a bir şeyler koymanın ana nedeni, diğer geliştiricilerle işbirliği
## Başkalarıyla Projeler Üzerinde Çalışmak
> Videoyu izleyin
> Videoyu izleyin
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Depo sayfanızda, `Insights > Community` sekmesine giderek projenizin önerilen topluluk standartlarına nasıl uyduğunu görebilirsiniz.
Depo içinde, `Insights > Community` bölümüne giderek projenizin önerilen topluluk standartlarına nasıl uyduğunu görebilirsiniz.
GitHub deponuzu geliştirebilecek bazı şeyler şunlardır:
- **Açıklama**. Projeniz için bir açıklama eklediniz mi?
- **README**. Bir README eklediniz mi? GitHub, bir [README yazma](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) konusunda rehberlik sağlar.
- **KatkıKılavuzu**. Projenizin bir [katkı kılavuzu](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) var mı?
- **Davranış Kuralları**. Bir [Davranış Kuralları](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/) eklediniz mi?
- **Lisans**. Belki de en önemlisi, bir [lisans](https://docs.github.com/articles/adding-a-license-to-a-repository/) eklediniz mi?
- **README**. Bir README eklediniz mi? GitHub, [README yazma](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) konusunda rehberlik sağlar.
- **Katkıyönergeleri**. Projenizde [katkı yönergeleri](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) var mı?
- **Davranış Kuralları**. Bir [Davranış Kuralları](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/) var mı?
- **Lisans**. Belki de en önemlisi, bir [lisans](https://docs.github.com/articles/adding-a-license-to-a-repository/) var mı?
Tüm bu kaynaklar, yeni ekip üyelerinin projeye dahil olmasına fayda sağlar. Ve bunlar genellikle yeni katkıda bulunanların, zamanlarını harcamak için doğru yerin sizin projeniz olup olmadığını öğrenmek için kodunuza bakmadan önce incelediği şeylerdir.
Tüm bu kaynaklar, yeni ekip üyelerinin projeye dahil olmasına fayda sağlar. Ve bunlar genellikle yeni katkıda bulunanların kodunuza bakmadan önce projenizin zamanlarını harcamaları için doğru yer olup olmadığını anlamak için baktıkları şeylerdir.
✅ README dosyaları, hazırlanması zaman alsa da, genellikle meşgul bakımcılar tarafından ihmal edilir. Özellikle açıklayıcı bir README örneği bulabilir misiniz? Not: [İyi README'ler oluşturmanıza yardımcı olacak araçlar](https://www.makeareadme.com/) vardır, bunları denemek isteyebilirsiniz.
✅ README dosyaları, hazırlanması zaman almasına rağmen, genellikle meşgul bakımcılar tarafından ihmal edilir. Özellikle açıklayıcı bir README örneği bulabilir misiniz? Not: [README oluşturmak için araçlar](https://www.makeareadme.com/) var, bunları denemek isteyebilirsiniz.
### Görev: Kod Birleştirin
Katkı belgeleri, insanların projeye katkıda bulunmasına yardımcı olur. Hangi tür katkılara ihtiyaç duyduğunuzu ve sürecin nasıl işlediğini açıklar. Katkıda bulunanlar, GitHub'daki deponuza katkıda bulunabilmek için bir dizi adımı takip etmek zorunda kalacaklar:
Katkı belgeleri, insanların projeye katkıda bulunmasına yardımcı olur. Hangi tür katkılar aradığınızı ve sürecin nasıl işlediğini açıklar. Katkıda bulunanlar, GitHub'daki deponuza katkıda bulunabilmek için bir dizi adımı takip etmek zorunda kalacaklar:
1. **Depoyu çatallama**. İnsanların projenizi _çatallamasını_ isteyeceksiniz. Çatallama, deponuzun GitHub profillerinde bir kopyasını oluşturmak anlamına gelir.
1. **Klonlama**. Daha sonra projeyi yerel makinelerine klonlayacaklar.
1. **Klonlama**. Buradan projeyi yerel makinesine klonlayacaklar.
1. **Dal oluşturma**. Çalışmaları için bir _dal_ oluşturmalarını isteyeceksiniz.
1. **Değişikliklerini bir alana odaklama**. Katkıda bulunanlardan katkılarını bir seferde bir şeye odaklamalarını isteyin - bu şekilde çalışmalarını_birleştirme_ şansınız daha yüksek olur. Örneğin, bir hata düzeltmesi yazdıklarını, yeni bir özellik eklediklerini ve birkaç testi güncellediklerini hayal edin - ya 3'ten 2'sini veya 1'ini uygulamak istiyorsanız?
1. **Değişikliklerini bir alana odaklama**. Katkıda bulunanlardan katkılarını bir seferde bir şeye odaklamalarını isteyin - böylece çalışmalarını_birleştirme_ olasılığınız daha yüksek olur. Diyelim ki bir hata düzeltmesi yazıyorlar, yeni bir özellik ekliyorlar ve birkaç testi güncelliyorlar - ya 3 değişiklikten sadece 2'sini veya 1'ini uygulamak istiyorsanız?
✅ Dalların iyi kod yazma ve gönderme açısından özellikle kritik olduğu bir durumu hayal edin. Hangi kullanım durumlarını düşünebilirsiniz?
✅ Dalların iyi kod yazmak ve göndermek için özellikle kritik olduğu bir durumu hayal edin. Hangi kullanım durumlarını düşünebilirsiniz?
> Not: Dünyada görmek istediğiniz değişim olun ve kendi çalışmalarınız için de dallar oluşturun. Yaptığınız commit'ler, şu anda "checkout" yaptığınız dalda yapılacaktır. Hangi dalda olduğunuzu görmek için `git status` kullanın.
Bir katkıda bulunan iş akışını inceleyelim. Katkıda bulunanın zaten depoyu _çatalladığını_ ve _klonladığını_ ve yerel makinesinde çalışmaya hazır bir Git deposuna sahip olduğunu varsayalım:
Bir katkıda bulunanın iş akışını inceleyelim. Katkıda bulunanın zaten depoyu _çatalladığı_ ve _klonladığı_ ve yerel makinesinde çalışmaya hazır bir Git deposuna sahip olduğunu varsayalım:
1. **Dal oluşturma**. Katkıda bulunmayı düşündükleri değişiklikleri içerecek bir dal oluşturmak için `git branch` komutunu kullanın:
1. **Dal oluşturma**. `git branch` komutunu kullanarak katkıda bulunmayı düşündükleri değişiklikleri içerecek bir dal oluşturun:
```bash
git branch [branch-name]
```
1. **Çalışma dalına geçiş yapın**. Belirtilen dala geçin ve çalışma dizinini `git switch` ile güncelleyin:
1. **Çalışma dalına geçiş yapma**. Belirtilen dala geçin ve çalışma dizinini `git switch` ile güncelleyin:
```bash
git switch [branch-name]
```
1. **Çalışma yapın**. Bu noktada değişikliklerinizi eklemek istersiniz. Git'e bunu şu komutlarla bildirmeyi unutmayın:
1. **Çalışma yapma**. Bu noktada değişikliklerinizi eklemek istiyorsunuz. Git'e bunu şu komutlarla bildirmeyi unutmayın:
```bash
git add .
@ -235,60 +235,65 @@ Bir katkıda bulunan iş akışını inceleyelim. Katkıda bulunanın zaten depo
Commit'inize iyi bir ad verdiğinizden emin olun, hem sizin hem de yardım ettiğiniz depo bakımcısı için.
1. **Çalışmanızı`main` dalıyla birleştirin**. Bir noktada çalışmanızı tamamladınız ve bunu `main` dalındaki çalışmalarla birleştirmek istiyorsunuz. Bu arada `main` dalı değişmiş olabilir, bu yüzden önce aşağıdaki komutlarla en son sürüme güncellediğinizden emin olun:
1. **Çalışmanızı`main` dalıyla birleştirme**. Bir noktada çalışmanızı tamamladınız ve bunu `main` dalıyla birleştirmek istiyorsunuz. Bu arada `main` dalı değişmiş olabilir, bu yüzden önce aşağıdaki komutlarla en son haline güncellediğinizden emin olun:
```bash
git switch main
git pull
```
Bu noktada, herhangi bir _çatışmanın_, yani Git'in değişiklikleri kolayca _birleştiremediği_ durumların çalışma dalınızda gerçekleştiğinden emin olmak istersiniz. Bu nedenle şu komutları çalıştırın:
Bu noktada, herhangi bir _çakışmanın_, Git'in değişiklikleri kolayca _birleştiremediği_ durumların çalışma dalınızda gerçekleştiğinden emin olun. Bu nedenle şu komutları çalıştırın:
```bash
git switch [branch_name]
git merge main
```
Bu, `main` dalındaki tüm değişiklikleri dalınıza getirir ve umarım sadece devam edebilirsiniz. Eğer edemezseniz, VS Code, Git'in _kafasının karıştığı_ yerleri size gösterecek ve etkilenen dosyaları değiştirerek hangi içeriğin en doğru olduğunu belirteceksiniz.
`git merge main` komutu, `main` dalından tüm değişiklikleri dalınıza getirir. Umarız devam edebilirsiniz. Eğer edemezseniz, VS Code, Git'in _kafasının karıştığı_ yerleri size gösterecek ve etkilenen dosyaları değiştirerek hangi içeriğin en doğru olduğunu belirteceksiniz.
Farklı bir dala geçmek için modern `git switch` komutunu kullanın:
```bash
git switch [branch_name]
1. **Çalışmanızı GitHub'a gönderin**. Çalışmanızı GitHub'a göndermek iki şey anlamına gelir. Dalınızı deponuza göndermek ve ardından bir PR (Pull Request) açmak.
1. **Çalışmanızı GitHub'a gönderin**. Çalışmanızı GitHub'a göndermek iki şey anlamına gelir. Dalınızı deponuza itmek ve ardından bir PR (Pull Request) açmak.
```bash
git push --set-upstream origin [branch-name]
```
Yukarıdaki komut, çatalladığınız depoda dalı oluşturur.
1. **Bir PR açın**. Ardından, bir PR açmak istersiniz. Bunu, GitHub'daki çatalladığınız depo sayfasına giderek yapabilirsiniz. GitHub'da yeni bir PR oluşturmak isteyip istemediğinizi soran bir gösterge göreceksiniz, buna tıklayın ve commit mesajı başlığını değiştirebileceğiniz, daha uygun bir açıklama ekleyebileceğiniz bir arayüze yönlendirilirsiniz. Şimdi, çatalladığınız deponun bakımcısı bu PR'ı görecek ve _parmaklar çapraz_ PR'ınızı takdir edip _birleştirecek_. Artık bir katkıda bulunan oldunuz, yaşasın :)
Yukarıdaki komut, çatallanan deponuzda dalı oluşturur.
1. **Bir PR Açın**. Şimdi bir PR açmak istiyorsunuz. Bunu GitHub'daki çatalladığınız repo'ya giderek yapabilirsiniz. GitHub'da yeni bir PR oluşturmak isteyip istemediğinizi soran bir gösterge göreceksiniz, buna tıklayın ve sizi commit mesaj başlığını değiştirebileceğiniz, daha uygun bir açıklama ekleyebileceğiniz bir arayüze yönlendirecek. Çatalladığınız repo'nun sahibi bu PR'ı görecek ve _parmaklar çapraz_ umarız PR'ınızı beğenip _birleştirecek_. Artık bir katkıcı oldunuz, yaşasın :)
1. **Temizlik yapın**. Bir PR'ı başarıyla birleştirdikten sonra _temizlik yapmak_ iyi bir uygulama olarak kabul edilir. Yerel dalınızı ve GitHub'a gönderdiğiniz dalı temizlemek istersiniz. Öncelikle, yerel olarak şu komutla silin:
1. **Temizlik Yapın**. Bir PR'ı başarıyla birleştirdikten sonra _temizlik yapmak_ iyi bir uygulama olarak kabul edilir. Hem yerel dalınızı hem de GitHub'a gönderdiğiniz dalı temizlemek istersiniz. Önce aşağıdaki komutla yerel olarak silelim:
```bash
git branch -d [branch-name]
```
Ardından, GitHub'daki çatalladığınız depo sayfasına gidin ve az önce gönderdiğiniz uzak dalı kaldırın.
`Pull request` terimi biraz garip gelebilir çünkü aslında değişikliklerinizi projeye "push" etmek istersiniz. Ancak, proje sahibi (maintainer) veya çekirdek ekip, değişikliklerinizi projenin "main" dalıyla birleştirmeden önce değerlendirmelidir. Yani aslında bir maintainer'dan değişiklik kararı talep ediyorsunuz.
Ardından GitHub'daki çatalladığınız repo sayfasına gidin ve az önce gönderdiğiniz uzak dalı kaldırın.
`Pull request` (Çekme isteği) biraz garip bir terim gibi görünüyor çünkü aslında değişikliklerinizi projeye göndermek istiyorsunuz. Ancak repo sahibi (proje sahibi) veya çekirdek ekip, değişikliklerinizi projedeki "ana" dal ile birleştirmeden önce değerlendirmelidir, bu yüzden aslında bir değişiklik kararı talep ediyorsunuz.
Bir pull request, bir dalda yapılan değişiklikleri karşılaştırmak ve tartışmak için incelemeler, yorumlar, entegre testler ve daha fazlasını içeren bir yerdir. İyi bir pull request, kabaca bir commit mesajı ile aynı kuralları takip eder. Örneğin, çalışmanız bir sorunu çözdüğünde, issue tracker'daki bir soruya referans ekleyebilirsiniz. Bu, `#` işareti ve ardından sorunun numarası kullanılarak yapılır. Örneğin `#97`.
Bir çekme isteği, bir dalda yapılan değişiklikleri incelemek ve tartışmak için yorumlar, entegre testler ve daha fazlasıyla bir yerdir. İyi bir çekme isteği, yaklaşık olarak bir commit mesajı ile aynı kuralları takip eder. Örneğin, çalışmanız bir sorunu çözdüğünde, sorun izleyicisine bir referans ekleyebilirsiniz. Bu, `#` işareti ve ardından sorun numarası kullanılarak yapılır. Örneğin `#97`.
🤞Umarız tüm kontroller başarıyla geçer ve proje sahibi(leri) değişikliklerinizi projeye birleştirir🤞
🤞Parmaklar çapraz, umarız tüm kontroller geçer ve proje sahibi(leri) değişikliklerinizi projeye birleştirir🤞
GitHub'daki ilgili uzak dalda yapılan tüm yeni commit'leri mevcut yerel çalışma dalınıza güncelleyin:
GitHub'daki ilgili uzak dalda yapılan tüm yeni commit'lerle mevcut yerel çalışma dalınızı güncelleyin:
`git pull`
## Açık Kaynağa Nasıl Katkıda Bulunulur?
## Açık Kaynağa Nasıl Katkıda Bulunulur
Öncelikle, GitHub'da ilginizi çeken ve değişiklik yapmak istediğiniz bir depo (**repo**) bulalım. İçeriğini bilgisayarınıza kopyalamak isteyeceksiniz.
✅ 'Yeni başlayanlar için uygun' depoları bulmanın iyi bir yolu, [‘good-first-issue’ etiketiyle arama yapmaktır](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ 'Yeni başlayanlar için uygun' repoları bulmanın iyi bir yolu [‘good-first-issue’ etiketiyle arama yapmaktır](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Kod kopyalamanın birkaç yolu vardır. Bir yol, HTTPS, SSH veya GitHub CLI (Komut Satırı Arayüzü) kullanarak depoyu "klonlamaktır".
Kod kopyalamanın birkaç yolu vardır. Bir yol, HTTPS, SSH veya GitHub CLI (Komut Satırı Arayüzü) kullanarak repoyu "klonlamaktır".
Terminalinizi açın ve depoyu şu şekilde klonlayın:
Terminalinizi açın ve repoyu şu şekilde klonlayın:
`git clone https://github.com/ProjectURL`
Projede çalışmak için doğru klasöre geçin:
@ -296,44 +301,44 @@ Projede çalışmak için doğru klasöre geçin:
Ayrıca projeyi [Codespaces](https://github.com/features/codespaces), GitHub'ın entegre kod editörü / bulut geliştirme ortamı veya [GitHub Desktop](https://desktop.github.com/) kullanarak açabilirsiniz.
Son olarak, kodu sıkıştırılmış bir klasör olarak indirebilirsiniz.
Son olarak, kodu sıkıştırılmış bir klasör olarak indirebilirsiniz.
### GitHub Hakkında Birkaç İlginç Bilgi
GitHub'daki herhangi bir genel depoyu yıldızlayabilir, izleyebilir ve/veya "fork" edebilirsiniz. Yıldızladığınız depoları sağ üstteki açılır menüde bulabilirsiniz. Bu, kod için bir tür yer imi gibidir.
GitHub'daki herhangi bir açık repo'yu yıldızlayabilir, izleyebilir ve/veya "çatallayabilirsiniz". Yıldızladığınız repoları sağ üst açılır menüde bulabilirsiniz. Bu, kod için bir tür yer imi gibidir.
Projelerde genellikle GitHub'daki "Issues" sekmesinde (aksi belirtilmedikçe) bir issue tracker bulunur. Burada insanlar projeyle ilgili sorunları tartışır. Pull Requests sekmesi ise devam eden değişikliklerin tartışıldığı ve incelendiği yerdir.
Projelerde genellikle GitHub'daki "Issues" sekmesinde (aksi belirtilmedikçe) bir sorun izleyici bulunur, burada insanlar projeyle ilgili sorunları tartışır. Ve Çekme İstekleri sekmesi, devam eden değişikliklerin tartışıldığı ve incelendiği yerdir.
Projeler ayrıca forumlarda, e-posta listelerinde veya Slack, Discord veya IRC gibi sohbet kanallarında tartışmalara sahip olabilir.
Projelerde ayrıca forumlarda, e-posta listelerinde veya Slack, Discord veya IRC gibi sohbet kanallarında tartışmalar olabilir.
✅ Yeni GitHub deponuzda biraz dolaşın ve ayarları düzenlemek, deponuza bilgi eklemek ve bir proje (örneğin bir Kanban panosu) oluşturmak gibi birkaç şey deneyin. Yapabileceğiniz çok şey var!
✅ Yeni GitHub repo'nuzda biraz dolaşın ve ayarları düzenlemek, repoya bilgi eklemek ve bir proje (örneğin bir Kanban panosu) oluşturmak gibi birkaç şey deneyin. Yapabileceğiniz çok şey var!
---
## 🚀 Meydan Okuma
## 🚀 Meydan Okuma
Bir arkadaşınızla eşleşerek birbirinizin kodu üzerinde çalışın. Ortak bir proje oluşturun, kodu fork edin, dallar oluşturun ve değişiklikleri birleştirin.
Bir arkadaşınızla eşleşerek birbirinizin kodu üzerinde çalışın. Ortak bir proje oluşturun, kodu çatallayın, dallar oluşturun ve değişiklikleri birleştirin.
- [GitHub'da İlk Hafta](https://skills.github.com/#first-week-on-github)
Ayrıca daha ileri düzey kurslar da bulabilirsiniz.
Ayrıca daha ileri düzey kurslar da bulabilirsiniz.
## Ödev
## Ödev
[GitHub'da İlk Hafta kursunu](https://skills.github.com/#first-week-on-github) tamamlayın.
---
**Feragatname**:
Bu belge, [Co-op Translator](https://github.com/Azure/co-op-translator) adlı yapay zeka çeviri hizmeti kullanılarak çevrilmiştir. Doğruluk için çaba göstersek de, otomatik çevirilerin hata veya yanlışlıklar içerebileceğini lütfen unutmayın. Belgenin orijinal dili, yetkili kaynak olarak kabul edilmelidir. Kritik bilgiler için profesyonel insan çevirisi önerilir. Bu çevirinin kullanımından kaynaklanan herhangi bir yanlış anlama veya yanlış yorumlama durumunda sorumluluk kabul edilmez.
Bu belge, AI çeviri hizmeti [Co-op Translator](https://github.com/Azure/co-op-translator) kullanılarak çevrilmiştir. Doğruluğu sağlamak için çaba göstersek de, otomatik çevirilerin hata veya yanlışlık içerebileceğini lütfen unutmayın. Belgenin orijinal dili, yetkili kaynak olarak kabul edilmelidir. Kritik bilgiler için profesyonel insan çevirisi önerilir. Bu çevirinin kullanımından kaynaklanan yanlış anlamalar veya yanlış yorumlamalar için sorumluluk kabul edilmemektedir.
[Тест перед лекцією](https://ff-quizzes.netlify.app)
## Вступ
У цьому уроці ми розглянемо:
- як відстежувати роботу, яку ви виконуєте на своєму комп'ютері
- як працювати над проєктами разом з іншими
- як робити внескиу програмне забезпечення з відкритим кодом
- відстеження роботи на вашому комп'ютері
- роботу над проектами з іншими
- як зробити внесок у програмне забезпечення з відкритим кодом
### Попередні вимоги
Перед початком перевірте, чи встановлений у вас Git. У терміналі введіть:
Перед початком перевірте, чи встановлений Git. У терміналі введіть:
`git --version`
Якщо Git не встановлений, [завантажте Git](https://git-scm.com/downloads). Потім налаштуйте свій локальний профіль Git у терміналі:
Якщо Git не встановлений, [завантажте Git](https://git-scm.com/downloads). Потім налаштуйте локальний профіль Git у терміналі:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
Щоб перевірити, чи вже налаштований Git, введіть:
Щоб перевірити, чи Git вже налаштований, введіть:
`git config --list`
Вам також знадобиться обліковий запис GitHub, редактор коду (наприклад, Visual Studio Code)і доступ до терміналу (або командного рядка).
Вам також знадобиться обліковий запис GitHub, редактор коду (наприклад, Visual Studio Code), і потрібно буде відкрити термінал (або командний рядок).
Перейдіть на [github.com](https://github.com/) і створіть обліковий запис, якщо у вас його ще немає, або увійдіть і заповніть свій профіль.
✅ GitHub — це не єдиний репозиторій коду у світі; є й інші, але GitHub є найвідомішим.
✅ GitHub — не єдиний репозиторій коду у світі; є й інші, але GitHub — найвідоміший.
### Підготовка
Вам знадобиться папка з проєктом коду на вашому локальному комп'ютері (ноутбуці або ПК) і публічний репозиторій на GitHub, який слугуватиме прикладом того, як робити внески в проєкти інших.
Вам знадобиться папка з проектом коду на вашому локальному комп'ютері (ноутбуці або ПК) і публічний репозиторій на GitHub, який буде слугувати прикладом того, як робити внесок у проекти інших.
---
## Управління кодом
Припустимо, у вас є локальна папка з якимось проєктом коду, і ви хочете почати відстежувати свій прогрес за допомогою git — системи контролю версій. Деякі люди порівнюють використання git із написанням любовного листа до свого майбутнього "я". Читаючи свої повідомлення про коміти через дні, тижні чи місяці, ви зможете згадати, чому прийняли те чи інше рішення, або "відкотити" зміни — за умови, що ви пишете хороші повідомлення про коміти.
Припустимо, у вас є локальна папка з проектом коду, і ви хочете почати відстежувати свій прогрес за допомогою git — системи контролю версій. Дехто порівнює використання git із написанням любовного листа до себе в майбутньому. Читаючи ваші повідомлення про коміти через дні, тижні чи місяці, ви зможете згадати, чому прийняли те чи інше рішення, або "відкотити" зміни — за умови, що ви пишете хороші "повідомлення про коміти".
### Завдання: Створіть репозиторій і зафіксуйте код
### Завдання: Створіть репозиторій і закомітьте код
> Перегляньте відео
>
@ -62,15 +62,15 @@ CO_OP_TRANSLATOR_METADATA:
1. **Створіть репозиторій на GitHub**. На GitHub.com, у вкладці репозиторіїв абоу верхньому правому куті навігаційної панелі, знайдіть кнопку **new repo**.
1. Дайте вашому репозиторію (папці) назву.
1. Натисніть **create repository**.
1. Виберіть **create repository**.
1. **Перейдіть до вашої робочої папки**. У терміналі перейдіть до папки (також відомої як директорія), яку ви хочете почати відстежувати. Введіть:
1. **Перейдіть до вашої робочої папки**. У терміналі перейдіть до папки (також відомої як каталог), яку ви хочете почати відстежувати. Введіть:
```bash
cd [name of your folder]
```
1. **Ініціалізуйте git-репозиторій**. У вашому проєкті введіть:
1. **Ініціалізуйте git-репозиторій**. У вашому проекті введіть:
```bash
git init
@ -93,16 +93,16 @@ CO_OP_TRANSLATOR_METADATA:
modified: file2.txt
```
Зазвичай команда `git status` повідомляє вам, які файли готові до _збереження_у репозиторії або мають зміни, які ви, можливо, хочете зафіксувати.
Зазвичай команда `git status` повідомляє вам, які файли готові до _збереження_у репозиторії або мають зміни, які ви, можливо, захочете зберегти.
1. **Додайте всі файли для відстеження**
1. **Додайте всі файли для відстеження**
Це також називається підготовкою файлів/додаванням файлів до області підготовки.
```bash
git add .
```
Аргумент `git add` плюс `.`вказує, що всі ваші файли та зміни будуть відстежуватися.
Аргумент `git add` плюс `.`означає, що всі ваші файли та зміни будуть відстежуватися.
1. **Додайте вибрані файли для відстеження**
@ -110,53 +110,53 @@ CO_OP_TRANSLATOR_METADATA:
git add [file or folder name]
```
Це дозволяє додати лише вибрані файли до області підготовки, якщо ви не хочете комітити всі файли одразу.
Це дозволяє додати лише вибрані файли до області підготовки, якщо ви не хочете закомітити всі файли одразу.
1. **Зніміть підготовку з усіх файлів**
1. **Відмінити підготовку всіх файлів**
```bash
git reset
```
Ця команда дозволяє зняти підготовку з усіх файлів одразу.
Ця команда дозволяє відмінити підготовку всіх файлів одразу.
1. **Зніміть підготовку з конкретного файлу**
1. **Відмінити підготовку конкретного файлу**
```bash
git reset [file or folder name]
```
Ця команда дозволяє зняти підготовку лише з конкретного файлу, який ви не хочете включати до наступного коміту.
Ця команда дозволяє відмінити підготовку лише конкретного файлу, який ви не хочете включати до наступного коміту.
1. **Збережіть свою роботу**. На цьому етапі ви додали файли до так званої _області підготовки_. Це місце, де Git відстежує ваші файли. Щоб зробити зміни постійними, вам потрібно _зафіксувати_ файли. Для цього створіть _коміт_ за допомогою команди `git commit`. Коміт представляє точку збереження в історії вашого репозиторію. Введіть наступне, щоб створити коміт:
1. **Збереження вашої роботи**. На цьому етапі ви додали файли до так званої _області підготовки_. Це місце, де Git відстежує ваші файли. Щоб зробити зміни постійними, вам потрібно _закомітити_ файли. Для цього створіть _коміт_ за допомогою команди `git commit`. _Коміт_ представляє точку збереження в історії вашого репозиторію. Введіть наступне, щоб створити _коміт_:
```bash
git commit -m "first commit"
```
Ця команда фіксує всі ваші файли, додаючи повідомлення "first commit". Для майбутніх повідомлень про коміти варто бути більш описовими, щоб передати, які саме зміни ви зробили.
Це закомітить всі ваші файли, додавши повідомлення "first commit". У майбутніх повідомленнях про коміти вам слід бути більш описовими, щоб передати, який тип змін ви зробили.
1. **Підключіть ваш локальний репозиторій Git до GitHub**. Репозиторій Git корисний на вашому комп'ютері, але в якийсь момент ви захочете створити резервну копію своїх файлів десь і запросити інших людей працювати з вами над вашим репозиторієм. Одне з чудових місць для цього — GitHub. Пам'ятайте, що ми вже створили репозиторій на GitHub, тому єдине, що потрібно зробити, це підключити ваш локальний репозиторій Git до GitHub. Команда `git remote add` зробить це. Введіть наступну команду:
1. **Підключіть ваш локальний Git-репозиторій до GitHub**. Git-репозиторій добре працює на вашому комп'ютері, але в якийсь момент ви захочете створити резервну копію ваших файлів десь і запросити інших людей працювати з вами над вашим репозиторієм. Одне з чудових місць для цього — GitHub. Пам'ятайте, що ми вже створили репозиторій на GitHub, тому єдине, що нам потрібно зробити, це підключити наш локальний Git-репозиторій до GitHub. Команда `git remote add` зробить саме це. Введіть наступну команду:
> Зверніть увагу, перед тим як вводити команду, перейдіть на сторінку вашого репозиторію на GitHub, щоб знайти URL репозиторію. Ви використаєте його в команді нижче. Замініть ```https://github.com/username/repository_name.git``` на ваш URL GitHub.
> Зверніть увагу, перед введенням команди перейдіть на сторінку вашого репозиторію на GitHub, щоб знайти URL репозиторію. Ви використаєте його в команді нижче. Замініть ```https://github.com/username/repository_name.git``` на ваш URL GitHub.
Це створює _віддалене підключення_ (remote), назване "origin", яке вказує на репозиторій GitHub, створений раніше.
Це створює _віддалене підключення_, назване "origin", яке вказує на репозиторій GitHub, створений раніше.
1. **Відправте локальні файли на GitHub**. До цього моменту ви створили _підключення_ між локальним репозиторієм і репозиторієм GitHub. Відправимо ці файли на GitHub за допомогою команди `git push`, ось так:
1. **Відправте локальні файли на GitHub**. До цього моменту ви створили _підключення_ між локальним репозиторієм і репозиторієм GitHub. Відправте ці файли на GitHub за допомогою наступної команди `git push`, як показано нижче:
> Зверніть увагу, ваша назва гілки за замовчуванням може відрізнятися від ```main```.
> Зверніть увагу, ваша назва гілки може відрізнятися за замовчуванням від ```main```.
```bash
git push -u origin main
```
Це відправляє ваші коміти у гілку "main" на GitHub.
Це відправляє ваші коміти увашу гілку "main" на GitHub. Встановлення гілки `upstream`, включаючи `-u`у команді, створює зв'язок між вашою локальною гілкою та віддаленою гілкою, тому ви можете просто використовувати git push або git pull без вказівки назви гілки в майбутньому. Git автоматично використовуватиме гілку upstream, і вам не потрібно буде явно вказувати назву гілки в майбутніх командах.
2. **Щоб додати більше змін**. Якщо ви хочете продовжити вносити зміни та відправляти їх на GitHub, вам потрібно буде використовувати наступні три команди:
2. **Додайте більше змін**. Якщо ви хочете продовжити вносити зміни та відправляти їх на GitHub, вам потрібно буде використовувати наступні три команди:
```bash
git add .
@ -164,63 +164,63 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> Порада: Можливо, ви також захочете додати файл `.gitignore`, щоб запобігти відстеженню файлів, які ви не хочете бачити на GitHub — наприклад, файлу з нотатками, який ви зберігаєте в тій самій папці, але який не має бути у публічному репозиторії. Ви можете знайти шаблони для файлів `.gitignore` на сторінці [.gitignore templates](https://github.com/github/gitignore).
> Порада: Можливо, вам також захочеться використовувати файл `.gitignore`, щоб запобігти появі файлів, які ви не хочете відстежувати, на GitHub — наприклад, файл нотаток, який ви зберігаєте в тій самій папці, але який не має місця в публічному репозиторії. Ви можете знайти шаблони для файлів `.gitignore` на [.gitignore templates](https://github.com/github/gitignore).
#### Повідомлення про коміти
Чудовий заголовок повідомлення про коміт завершує наступне речення:
Якщо застосувати, цей коміт <ваш заголовок тут>.
Чудовий заголовок повідомлення про коміт завершує наступне речення:
Якщо застосувати, цей коміт <ваш заголовок тут>
Для заголовка використовуйте наказовий теперішній час: "змінити", а не "змінив" чи "зміни".
Як і в заголовку, у тілі (необов'язково) також використовуйте наказовий теперішній час. Тіло має включати мотивацію для зміни та порівняння з попередньою поведінкою. Ви пояснюєте `чому`, а не `як`.
Для заголовка використовуйте наказовий теперішній час: "змінити", а не "змінив" чи "зміни".
Як і в заголовку, у тілі (необов'язковому) також використовуйте наказовий теперішній час. Тіло має включати мотивацію для зміни та порівняти це з попередньою поведінкою. Ви пояснюєте `чому`, а не `як`.
✅ Приділіть кілька хвилин, щоб переглянути GitHub. Чи можете ви знайти справді чудове повідомлення про коміт? А мінімальне? Яка інформація, на вашу думку, є найважливішою та найкориснішою для передачі у повідомленні про коміт?
✅ Приділіть кілька хвилин, щоб переглянути GitHub. Чи можете ви знайти дійсно чудове повідомлення про коміт? Чи можете знайти дуже мінімальне? Яка інформація, на вашу думку, є найважливішою та корисною для передачі у повідомленні про коміт?
### Завдання: Співпраця
### Завдання: Співпрацюйте
Основна причина розміщення проєктів на GitHub — це можливість співпрацювати з іншими розробниками.
Основна причина розміщення речей на GitHub — це зробити можливим співпрацю з іншими розробниками.
## Робота над проєктами з іншими
## Робота над проектами з іншими
> Перегляньте відео
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
У вашому репозиторії перейдіть до `Insights > Community`, щоб побачити, як ваш проєкт відповідає рекомендованим стандартам спільноти.
У вашому репозиторії перейдіть до `Insights > Community`, щоб побачити, як ваш проект порівнюється з рекомендованими стандартами спільноти.
Ось кілька речей, які можуть покращити ваш репозиторій на GitHub:
- **Опис**. Чи додали ви опис вашого проєкту?
Ось деякі речі, які можуть покращити ваш репозиторій на GitHub:
- **Опис**. Чи додали ви опис вашого проекту?
- **README**. Чи додали ви README? GitHub надає рекомендації щодо написання [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/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](https://www.makeareadme.com/), які вам можуть сподобатися.
### Завдання: Об'єднайте код
Документація для внесків допомагає людям робити внески у проєкт. Вона пояснює, які типи внесків ви шукаєте і як працює процес. Учасники повинні пройти серію кроків, щоб мати змогу зробити внесок у ваш репозиторій на GitHub:
Документація для внесків допомагає людям робити внески у проект. Вона пояснює, які типи внесків ви шукаєте і як працює процес. Учасники повинні пройти серію кроків, щоб мати змогу зробити внесок у ваш репозиторій на GitHub:
1. **Форк вашого репозиторію**. Ви, ймовірно, захочете, щоб люди _форкали_ ваш проєкт. Форк означає створення копії вашого репозиторію у їхньому профілі GitHub.
1. **Клонування**. Після цього вони клонують проєкт на свій локальний комп'ютер.
1. **Форк вашого репозиторію**. Ви, ймовірно, захочете, щоб люди _форкнули_ ваш проект. Форк означає створення копії вашого репозиторію у їхньому профілі GitHub.
1. **Клонування**. Звідти вони клонують проект на свій локальний комп'ютер.
1. **Створення гілки**. Ви захочете попросити їх створити _гілку_ для своєї роботи.
1. **Фокусування змін на одній області**. Попросіть учасників зосередити свої внески на чомусь одному за раз — таким чином шанси, що ви зможете _об'єднати_ їхню роботу, будуть вищими. Уявіть, що вони виправляють помилку, додають нову функцію та оновлюють кілька тестів — що, якщо ви хочете або можете реалізувати лише 2 із 3, або 1 із 3 змін?
1. **Зосередження змін на одній області**. Попросіть учасників зосередити свої внески на одній речі за раз — таким чином шанси, що ви зможете _об'єднати_ їхню роботу, будуть вищими. Уявіть, що вони виправляють баг, додають нову функцію і оновлюють кілька тестів — що, якщо ви хочете або можете реалізувати лише 2 з 3, або 1 з 3 змін?
✅ Уявіть ситуацію, коли гілки є особливо важливими для написання та випуску хорошого коду. Які випадки використання ви можете придумати?
✅ Уявіть ситуацію, коли гілки є особливо важливими для написання та доставки хорошого коду. Які випадки використання ви можете придумати?
> Примітка: будьте зміною, яку хочете бачити у світі, і створюйте гілки для своєї роботи також. Усі коміти, які ви робите, будуть зроблені у гілці, до якої ви зараз "перемкнуті". Використовуйте `git status`, щоб побачити, у якій гілці ви перебуваєте.
> Примітка: будьте зміною, яку хочете бачити у світі, і створюйте гілки для своєї власної роботи також. Усі коміти, які ви робите, будуть зроблені у гілці, до якої ви зараз "перейшли". Використовуйте `git status`, щоб побачити, у якій гілці ви перебуваєте.
Давайте розглянемо робочий процес учасника. Припустимо, учасник вже _форкнув_і_клонував_ репозиторій, тому у нього є готовий Git-репозиторій на локальному комп'ютері:
Давайте пройдемо робочий процес учасника. Припустимо, учасник вже _форкнув_і_клонував_ репозиторій, тому у нього є готовий Git-репозиторій на локальному комп'ютері:
1. **Створіть гілку**. Використовуйте команду `git branch`, щоб створити гілку, яка міститиме зміни, які вони планують внести:
1. **Створіть гілку**. Використовуйте команду `git branch`, щоб створити гілку, яка міститиме зміни, які вони мають намір внести:
```bash
git branch [branch-name]
```
1. **Перемкніться на робочу гілку**. Перемкніться на вказану гілку та оновіть робочу директорію за допомогою `git switch`:
1. **Перейдіть до робочої гілки**. Перейдіть до зазначеної гілки та оновіть робочий каталог за допомогою `git switch`:
```bash
git switch [branch-name]
@ -233,9 +233,9 @@ CO_OP_TRANSLATOR_METADATA:
git commit -m "my changes"
```
Переконайтеся, що ви дали своєму коміту гарну назву — для себе, а також для підтримувача репозиторію, якому ви допомагаєте.
Переконайтеся, що ви дали своєму коміту хорошу назву, для вашого блага, а також для підтримувача репозиторію, якому ви допомагаєте.
1. **Об'єднайте свою роботу з гілкою `main`**. У якийсь момент ви закінчите роботу і захочете об'єднати її з гілкою `main`. Гілка `main` могла змінитися за цей час, тому переконайтеся, що ви спочатку оновили її до останньої версії за допомогою наступних команд:
1. **Об'єднайте вашу роботу з гілкою `main`**. У якийсь момент ви закінчите роботу і захочете об'єднати її з гілкою `main`. Гілка `main` могла змінитися за цей час, тому переконайтеся, що спочатку оновили її до останньої версії за допомогою наступних команд:
```bash
git switch main
@ -249,44 +249,49 @@ CO_OP_TRANSLATOR_METADATA:
git merge main
```
Це принесе всі зміни з `main`у вашу гілку, і, сподіваємося, ви зможете просто продовжити. Якщо ні, VS Code покаже вам, де Git _заплутався_, і ви просто зміните відповідні файли, щоб вказати, який вміст є найбільш точним.
Команда `git merge main` принесе всі зміни з `main`у вашу гілку. Сподіваємося, ви зможете просто продовжити. Якщо ні, VS Code покаже вам, де Git _заплутався_, і ви просто зміните відповідні файли, щоб вказати, який контент є найбільш точним.
Щоб перейти до іншої гілки, використовуйте сучасну команду `git switch`:
```bash
git switch [branch_name]
1. **Відправте свою роботу на GitHub**. Відправка вашої роботи на GitHub означає дві речі: відправку вашої гілки у ваш репозиторій і відкриття PR (Pull Request).
1. **Відправте вашу роботу на GitHub**. Відправка вашої роботи на GitHub означає дві речі: відправка вашої гілки у ваш репозиторій і відкриття PR (Pull Request).
```bash
git push --set-upstream origin [branch-name]
```
Наведена вище команда створює гілку у вашому форкнутому репозиторії.
1. **Відкрити PR**. Далі вам потрібно відкрити PR. Для цього перейдіть до форкнутого репозиторію на GitHub. Ви побачите на GitHub запит, чи хочете створити новий PR. Натисніть на нього, і вас перенаправлять на інтерфейс, де можна змінити заголовок повідомлення коміту, додати більш відповідний опис. Тепер власник репозиторію, який ви форкнули, побачить цей PR і, _сподіваємося_, оцінить його та _зміржить_. Вітаємо, тепер ви — контриб'ютор, ура! :)
1. **Відкрийте PR**. Далі ви хочете відкрити PR. Ви робите це, перейшовши до форкнутого репозиторію на GitHub. Ви побачите індикацію на GitHub, де вас запитають, чи хочете ви створити новий PR. Натисніть це, і ви потрапите в інтерфейс, де зможете змінити заголовок повідомлення коміту, дати йому більш відповідний опис. Тепер підтримувач репозиторію, який ви форкнули, побачить цей PR і, _сподіваємося_, оцінить і_об'єднає_ ваш PR. Ви тепер учасник, ура :)
1. **Очистіть**. Вважається гарною практикою _очистити_ після успішного об'єднання PR. Ви хочете очистити як локальну гілку, так і гілку, яку ви відправили на GitHub. Спочатку видаліть її локально за допомогою наступної команди:
1. **Прибирання**. Вважається гарною практикою _прибирати_ після успішного злиття PR. Вам потрібно очистити як локальну гілку, так і гілку, яку ви запушили на GitHub. Спочатку видаліть її локально за допомогою наступної команди:
```bash
git branch -d [branch-name]
```
Переконайтеся, що ви перейшли на сторінку GitHub для форкнут
`Pull request` здається трохи дивним терміном, адже насправді ви хочете "запушити" свої зміни до проєкту. Але власник проєкту або основна команда повинні розглянути ваші зміни перед тим, як об'єднати їх із "головною" гілкою проєкту, тому ви фактично запитуєте рішення про внесення змін у власника.
Переконайтеся, що ви перейшли на сторінку GitHub форкнутого репозиторію і видалили віддалену гілку, яку щойно запушили.
`Pull request` може здатися дивним терміном, адже насправді ви хочете запушити свої зміни до проєкту. Але власник проєкту або основна команда повинні розглянути ваші зміни перед тим, як злиття їх із "головною" гілкою проєкту, тому ви фактично запитуєте рішення про зміну у власника.
Pull request — це місце для порівняння та обговорення відмінностей, внесених у гілку, з рецензіями, коментарями, інтегрованими тестами тощо. Хороший pull request дотримується приблизно тих самих правил, що й повідомлення про коміт. Ви можете додати посилання на проблему в трекері проблем, якщо ваша робота, наприклад, виправляє цю проблему. Це робиться за допомогою символу `#`, за яким слідує номер вашої проблеми. Наприклад, `#97`.
Pull request — це місце для порівняння та обговорення змін, внесених у гілку, з рецензіями, коментарями, інтегрованими тестами тощо. Хороший pull request дотримується приблизно тих самих правил, що й повідомлення коміту. Ви можете додати посилання на проблему в трекері проблем, якщо ваша робота, наприклад, вирішує проблему. Це робиться за допомогою `#`, після якого йде номер вашої проблеми. Наприклад, `#97`.
🤞Тримаємо кулаки, щоб усі перевірки пройшли успішно, і власник(и) проєкту об'єднали ваші зміни з проєктом🤞
🤞Сподіваємося, що всі перевірки пройдуть успішно, і власник(и) проєкту зіллють ваші зміни в проєкт🤞
Оновіть вашу поточну локальну робочу гілку всіма новими комітами з відповідної віддаленої гілки на GitHub:
`git pull`
## Як зробити внесок упроєкти з відкритим кодом
## Як зробити внесок увідкритий код
Спочатку знайдіть репозиторій (або**репо**) на GitHub, який вас цікавить і до якого ви хочете внести зміни. Вам потрібно буде скопіювати його вміст на свій комп'ютер.
Спочатку знайдіть репозиторій (або**repo**) на GitHub, який вас цікавить і до якого ви хотіли б внести зміни. Вам потрібно скопіювати його вміст на свій комп'ютер.
✅ Хороший спосіб знайти репозиторії для початківців — це [шукати за тегом 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Хороший спосіб знайти репозиторії, дружні до новачків, — це [шукати за тегом 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Є кілька способів скопіювати код. Один із них — "клонувати" вміст репозиторію, використовуючи HTTPS, SSH або GitHub CLI (інтерфейс командного рядка).
Існує кілька способів копіювання коду. Один із них — "клонувати" вміст репозиторію, використовуючи HTTPS, SSH або GitHub CLI (інтерфейс командного рядка).
Відкрийте термінал і клонуйте репозиторій таким чином:
`git clone https://github.com/ProjectURL`
@ -294,46 +299,46 @@ Pull request — це місце для порівняння та обговор
Щоб працювати над проєктом, перейдіть до потрібної папки:
`cd ProjectURL`
Ви також можете відкрити весь проєкт за допомогою [Codespaces](https://github.com/features/codespaces), вбудованого редактора коду / хмарного середовища розробки від GitHub, або [GitHub Desktop](https://desktop.github.com/).
Ви також можете відкрити весь проєкт за допомогою [Codespaces](https://github.com/features/codespaces), вбудованого редактора коду / хмарного середовища розробки GitHub, або [GitHub Desktop](https://desktop.github.com/).
Нарешті, ви можете завантажити код у вигляді архіву.
Нарешті, ви можете завантажити код у вигляді архівованої папки.
### Кілька цікавих фактів про GitHub
Ви можете додати зірочку, спостерігати або "форкнути" будь-який публічний репозиторій на GitHub. Ваші зіркові репозиторії можна знайти у випадаючому меню у верхньому правому куті. Це як закладки, але для коду.
Ви можете поставити зірочку, стежити або "форкнути" будь-який публічний репозиторій на GitHub. Ви знайдете свої репозиторії зі зірочками у випадаючому меню у верхньому правому куті. Це як закладки, але для коду.
У проєктах є трекер проблем, зазвичай на GitHub у вкладці "Issues", якщо не вказано інше, де люди обговорюють проблеми, пов'язані з проєктом. А вкладка Pull Requests — це місце, де обговорюють і переглядають зміни, які перебувають у процесі.
У проєктах є трекер проблем, здебільшого на GitHub у вкладці "Issues", якщо не зазначено інше, де люди обговорюють проблеми, пов’язані з проєктом. А вкладка Pull Requests — це місце, де люди обговорюють і переглядають зміни, які перебувають у процесі.
У проєктах також можуть бути обговорення на форумах, у списках розсилки абов чатах, таких як Slack, Discord чи IRC.
У проєктах також можуть бути обговорення на форумах, у списках розсилки абочат-каналах, таких як Slack, Discord або IRC.
✅ Ознайомтеся з вашим новим репозиторієм на GitHub і спробуйте кілька речей, наприклад, змінити налаштування, додати інформацію до репозиторію або створити проєкт (наприклад, дошку Kanban). Є багато цікавого, що можна зробити!
✅ Ознайомтеся з вашим новим репозиторієм на GitHub і спробуйте кілька речей, наприклад, змінити налаштування, додати інформацію до репозиторію та створити проєкт (наприклад, дошку Kanban). Можливостей багато!
---
## 🚀 Виклик
Попрацюйте в парі з другом над кодом один одного. Створіть спільний проєкт, форкніть код, створіть гілки та об'єднайте зміни.
Попрацюйте разом із другом над кодом один одного. Створіть проєкт спільно, форкніть код, створіть гілки та злийте зміни.
Практикуйтеся, практикуйтеся, практикуйтеся. GitHub пропонує чудові навчальні шляхи через [skills.github.com](https://skills.github.com):
- [Перший тиждень на GitHub](https://skills.github.com/#first-week-on-github)
Там ви також знайдете більш просунуті курси.
Там також є більш просунуті курси.
## Завдання
Пройдіть [курс "Перший тиждень на GitHub"](https://skills.github.com/#first-week-on-github)
Пройдіть курс [Перший тиждень на GitHub](https://skills.github.com/#first-week-on-github)
---
**Відмова від відповідальності**:
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильне тлумачення, що виникають внаслідок використання цього перекладу.
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу.
شروع کرنے سے پہلے، آپ کو یہ چیک کرنا ہوگا کہ آیا گِٹ انسٹال ہے یا نہیں۔ ٹرمینل میں یہ ٹائپ کریں:
شروع کرنے سے پہلے، آپ کو چیک کرنا ہوگا کہ آیا Git انسٹال ہے۔ ٹرمینل میں درج کریں:
`git --version`
اگر گِٹ انسٹال نہیں ہے، تو [گِٹ ڈاؤن لوڈ کریں](https://git-scm.com/downloads)۔ پھر، اپنے لوکل گِٹ پروفائل کو ٹرمینل میں سیٹ اپ کریں:
اگر 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)، اور اپنا ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔
آپ کو ایک GitHub اکاؤنٹ، ایک کوڈ ایڈیٹر (جیسے Visual Studio Code)، اور اپنا ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔
[githhub.com](https://github.com/) پر جائیں اور اگر آپ کے پاس پہلے سے اکاؤنٹ نہیں ہے تو ایک اکاؤنٹ بنائیں، یا لاگ ان کریں اور اپنی پروفائل مکمل کریں۔
[github.com](https://github.com/) پر جائیں اور اگر آپ نے پہلے سے اکاؤنٹ نہیں بنایا تو ایک اکاؤنٹ بنائیں، یا لاگ ان کریں اور اپنا پروفائل مکمل کریں۔
✅ گِٹ ہب دنیا میں واحد کوڈ ریپوزٹری نہیں ہے؛ دیگر بھی موجود ہیں، لیکن گِٹ ہب سب سے زیادہ مشہور ہے۔
✅ GitHub دنیا میں واحد کوڈ ریپوزیٹری نہیں ہے؛ دیگر بھی موجود ہیں، لیکن GitHub سب سے زیادہ مشہور ہے۔
### تیاری
آپ کو اپنے لوکل کمپیوٹر (لیپ ٹاپ یا پی سی) پر کوڈ پروجیکٹ کے ساتھ ایک فولڈر اور گِٹ ہب پر ایک پبلک ریپوزٹری کی ضرورت ہوگی، جو دوسروں کے پروجیکٹس میں تعاون کرنے کی مثال کے طور پر کام کرے گی۔
آپ کو اپنے لوکل کمپیوٹر (لیپ ٹاپ یا پی سی) پر کوڈ پروجیکٹ کے ساتھ ایک فولڈر اور GitHub پر ایک پبلک ریپوزیٹری کی ضرورت ہوگی، جو دوسروں کے پروجیکٹس میں تعاون کرنے کے طریقے کے لیے ایک مثال کے طور پر کام کرے گا۔
---
## کوڈ مینجمنٹ
فرض کریں کہ آپ کے پاس لوکل طور پر ایک فولڈر میں کوئی کوڈ پروجیکٹ موجود ہے اور آپ گِٹ کے ذریعے اپنی پیش رفت کو ٹریک کرنا چاہتے ہیں - جو کہ ایک ورژن کنٹرول سسٹم ہے۔ کچھ لوگ گِٹ کے استعمال کو اپنے مستقبل کے لیے محبت نامہ لکھنے سے تشبیہ دیتے ہیں۔ جب آپ دنوں، ہفتوں یا مہینوں بعد اپنے کمیٹ میسجز پڑھیں گے، تو آپ کو یاد آئے گا کہ آپ نے کوئی فیصلہ کیوں کیا تھا، یا آپ کسی تبدیلی کو "واپس" لے سکتے ہیں - بشرطیکہ آپ نے اچھے "کمیٹ میسجز" لکھے ہوں۔
فرض کریں کہ آپ کے پاس لوکل طور پر ایک فولڈر میں کچھ کوڈ پروجیکٹ ہے اور آپ اس پر اپنی پیشرفت کو ٹریک کرنا چاہتے ہیں، Git - ورژن کنٹرول سسٹم کا استعمال کرتے ہوئے۔ کچھ لوگ Git کے استعمال کو اپنے مستقبل کے خود کے لیے محبت کا خط لکھنے کے مترادف قرار دیتے ہیں۔ جب آپ اپنے کمیٹ میسیجز کو دنوں، ہفتوں یا مہینوں بعد پڑھیں گے، تو آپ کو یاد ہوگا کہ آپ نے کوئی فیصلہ کیوں کیا، یا کسی تبدیلی کو "رول بیک" کریں گے - بشرطیکہ آپ نے اچھے "کمیٹ میسیجز" لکھے ہوں۔
### کام: ریپوزٹری بنائیں اور کوڈ کمیٹ کریں
### کام: ریپوزیٹری بنائیں اور کوڈ کمیٹ کریں
> ویڈیو دیکھیں
>
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **گِٹ ہب پر ریپوزٹری بنائیں**۔ GitHub.com پر، ریپوزٹریز ٹیب میں، یا نیویگیشن بار کے اوپر دائیں جانب، **نئی ریپو** بٹن تلاش کریں۔
1. **GitHub پر ریپوزیٹری بنائیں**۔ GitHub.com پر، ریپوزیٹریز ٹیب میں، یا نیویگیشن بار کے اوپر دائیں جانب، **نیا ریپو** بٹن تلاش کریں۔
1. اپنی ریپوزٹری (فولڈر) کو ایک نام دیں۔
1. **ریپوزٹری بنائیں** کو منتخب کریں۔
1. اپنی ریپوزیٹری (فولڈر) کو ایک نام دیں۔
1. **ریپوزیٹری بنائیں** منتخب کریں۔
1. **اپنے ورکنگ فولڈر پر جائیں**۔ اپنے ٹرمینل میں، اس فولڈر (جسے ڈائریکٹری بھی کہا جاتا ہے) پر سوئچ کریں جسے آپ ٹریک کرنا چاہتے ہیں۔ ٹائپ کریں:
1. **اپنے ورکنگ فولڈر پر جائیں**۔ اپنے ٹرمینل میں، اس فولڈر (جسے ڈائریکٹری بھی کہا جاتا ہے) پر سوئچ کریں جسے آپ ٹریک کرنا شروع کرنا چاہتے ہیں۔ درج کریں:
```bash
cd [name of your folder]
```
1. **گِٹ ریپوزٹری کو انیشیالائز کریں**۔ اپنے پروجیکٹ میں ٹائپ کریں:
1. **Git ریپوزیٹری کو انیشیئلائز کریں**۔ اپنے پروجیکٹ میں درج کریں:
```bash
git init
```
1. **اسٹیٹس چیک کریں**۔اپنی ریپوزٹری کی اسٹیٹس چیک کرنے کے لیے ٹائپ کریں:
1. **اسٹیٹس چیک کریں**۔ ریپوزیٹری کی اسٹیٹس چیک کرنے کے لیے درج کریں:
```bash
git status
@ -95,22 +95,22 @@ CO_OP_TRANSLATOR_METADATA:
عام طور پر `git status` کمانڈ آپ کو یہ بتاتی ہے کہ کون سی فائلیں ریپو میں _محفوظ_ کرنے کے لیے تیار ہیں یا ان میں ایسی تبدیلیاں ہیں جنہیں آپ محفوظ کرنا چاہتے ہیں۔
1. **تمام فائلوں کو ٹریکنگ کے لیے شامل کریں**
اسے فائلوں کو اسٹیجنگ ایریا میں شامل کرنا بھی کہا جاتا ہے۔
1. **تمام فائلیں ٹریکنگ کے لیے شامل کریں**
اسے اسٹیجنگ فائلز/فائلز کو اسٹیجنگ ایریا میں شامل کرنا بھی کہا جاتا ہے۔
```bash
git add .
```
`git add` کے ساتھ `.` دلیل یہ ظاہر کرتی ہے کہ آپ کی تمام فائلیں اور تبدیلیاں ٹریکنگ کے لیے شامل کی جائیں۔
`git add` کے ساتھ `.` دلیل یہ ظاہر کرتی ہے کہ آپ کی تمام فائلیں اور تبدیلیاں ٹریکنگ کے لیے شامل کی گئی ہیں۔
1. **منتخب فائلوں کو ٹریکنگ کے لیے شامل کریں**
1. **منتخب فائلیں ٹریکنگ کے لیے شامل کریں**
```bash
git add [file or folder name]
```
یہ کمانڈ ہمیں صرف منتخب فائلوں کو اسٹیجنگ ایریا میں شامل کرنے میں مدد دیتی ہے جب ہم تمام فائلوں کو ایک ساتھ کمیٹ نہیں کرنا چاہتے۔
یہ ہمیں صرف منتخب فائلوں کو اسٹیجنگ ایریا میں شامل کرنے میں مدد کرتا ہے جب ہم تمام فائلوں کو ایک ساتھ کمیٹ نہیں کرنا چاہتے۔
1. **تمام فائلوں کو ان اسٹیج کریں**
@ -118,7 +118,7 @@ CO_OP_TRANSLATOR_METADATA:
git reset
```
یہ کمانڈ ہمیں تمام فائلوں کو ایک ساتھ ان اسٹیج کرنے میں مدد دیتی ہے۔
یہ کمانڈ ہمیں تمام فائلوں کو ایک ساتھ ان اسٹیج کرنے میں مدد کرتی ہے۔
1. **کسی خاص فائل کو ان اسٹیج کریں**
@ -126,37 +126,37 @@ CO_OP_TRANSLATOR_METADATA:
git reset [file or folder name]
```
یہ کمانڈ ہمیں کسی خاص فائل کو ان اسٹیج کرنے میں مدد دیتی ہے جسے ہم اگلے کمیٹ میں شامل نہیں کرنا چاہتے۔
یہ کمانڈ ہمیں صرف ایک خاص فائل کو ان اسٹیج کرنے میں مدد کرتی ہے جسے ہم اگلے کمیٹ میں شامل نہیں کرنا چاہتے۔
1. **اپنے کام کو محفوظ کریں**۔ اس مرحلے پر آپ نے فائلوں کو ایک _اسٹیجنگ ایریا_ میں شامل کر لیا ہے۔ یہ وہ جگہ ہے جہاں گِٹ آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو _کمیٹ_ کرنا ہوگا۔ ایسا کرنے کے لیے آپ `git commit` کمانڈ استعمال کرتے ہیں۔ ایک _کمیٹ_ آپ کی ریپو کی ہسٹری میں ایک محفوظ پوائنٹ کی نمائندگی کرتا ہے۔ کمیٹ بنانے کے لیے درج ذیل ٹائپ کریں:
1. **اپنے کام کو محفوظ کریں**۔ اس وقت آپ نے فائلوں کو ایک _اسٹیجنگ ایریا_ میں شامل کیا ہے۔ ایک ایسی جگہ جہاں Git آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو _کمیٹ_ کرنا ہوگا۔ ایسا کرنے کے لیے آپ `git commit` کمانڈ کے ساتھ ایک _کمیٹ_ بناتے ہیں۔ ایک _کمیٹ_ آپ کے ریپو کی تاریخ میں ایک محفوظ پوائنٹ کی نمائندگی کرتا ہے۔ درج ذیل درج کریں:
```bash
git commit -m "first commit"
```
یہ آپ کی تمام فائلوں کو کمیٹ کرتا ہے اور "پہلا کمیٹ" کے پیغام کے ساتھ محفوظ کرتا ہے۔ مستقبل کے کمیٹ میسجز کے لیے آپ کو اپنی تبدیلی کی قسم کو بیان کرنے کے لیے زیادہ وضاحتی ہونا چاہیے۔
یہ آپ کی تمام فائلوں کو کمیٹ کرتا ہے، اور پیغام "پہلا کمیٹ" شامل کرتا ہے۔ مستقبل کے کمیٹ میسیجز کے لیے آپ اپنی وضاحت میں زیادہ وضاحتی ہونا چاہیں گے تاکہ یہ ظاہر ہو سکے کہ آپ نے کس قسم کی تبدیلی کی ہے۔
1. **اپنی لوکل گِٹ ریپو کو گِٹ ہب سے جوڑیں**۔ ایک گِٹ ریپو آپ کے کمپیوٹر پر اچھی ہے لیکن کسی وقت آپ اپنی فائلوں کا بیک اپ کہیں اور رکھنا چاہیں گے اور دوسروں کو اپنی ریپو پر کام کرنے کی دعوت دینا چاہیں گے۔ گِٹ ہب ایسا کرنے کے لیے ایک بہترین جگہ ہے۔ یاد رکھیں کہ ہم نے پہلے ہی گِٹ ہب پر ایک ریپو بنایا ہے، لہذا ہمیں صرف اپنی لوکل گِٹ ریپو کو گِٹ ہب سے جوڑنا ہے۔ کمانڈ `git remote add` یہ کام کرے گی۔ درج ذیل کمانڈ ٹائپ کریں:
1. **اپنے لوکل Git ریپو کو GitHub کے ساتھ کنیکٹ کریں**۔ ایک Git ریپو آپ کے کمپیوٹر پر اچھا ہے لیکن کسی وقت آپ اپنی فائلوں کا بیک اپ کہیں رکھنا چاہتے ہیں اور دوسروں کو اپنے ریپو پر کام کرنے کی دعوت دینا چاہتے ہیں۔ ایسا کرنے کے لیے ایک بہترین جگہ GitHub ہے۔ یاد رکھیں کہ ہم نے پہلے ہی GitHub پر ایک ریپو بنایا ہے، لہذا ہمیں صرف اپنے لوکل Git ریپو کو GitHub کے ساتھ کنیکٹ کرنا ہے۔ کمانڈ `git remote add` یہی کام کرے گی۔ درج ذیل کمانڈ درج کریں:
> نوٹ: کمانڈ ٹائپ کرنے سے پہلے اپنی گِٹ ہب ریپو پیج پر جائیں اور ریپوزٹری یو آر ایل تلاش کریں۔ آپ اسے نیچے دی گئی کمانڈ میں استعمال کریں گے۔ ```https://github.com/username/repository_name.git``` کو اپنے گِٹ ہب یو آر ایل سے تبدیل کریں۔
> نوٹ، کمانڈ درج کرنے سے پہلے اپنے GitHub ریپو پیج پر جائیں تاکہ ریپوزیٹری URL تلاش کریں۔ آپ اسے نیچے دی گئی کمانڈ میں استعمال کریں گے۔ ```https://github.com/username/repository_name.git``` کو اپنے GitHub URL سے تبدیل کریں۔
یہ ایک _ریموٹ_ یا کنکشن بناتا ہے، جسے "origin" کہا جاتا ہے، جو آپ کی پہلے بنائی گئی گِٹ ہب ریپوزٹری کی طرف اشارہ کرتا ہے۔
یہ ایک _ریموٹ_ یا کنیکشن بناتا ہے، جس کا نام "origin" ہے، جو آپ کے پہلے سے بنائے گئے GitHub ریپوزیٹری کی طرف اشارہ کرتا ہے۔
1. **لوکل فائلوں کو گِٹ ہب پر بھیجیں**۔ اب تک آپ نے لوکل ریپو اور گِٹ ہب ریپو کے درمیان ایک _کنکشن_ بنایا ہے۔ آئیے ان فائلوں کو گِٹ ہب پر بھیجتے ہیں درج ذیل کمانڈ `git push` کے ساتھ:
1. **لوکل فائلیں GitHub پر بھیجیں**۔ اب تک آپ نے لوکل ریپو اور GitHub ریپو کے درمیان ایک _کنیکشن_ بنایا ہے۔ آئیے ان فائلوں کو GitHub پر بھیجیں درج ذیل کمانڈ `git push` کے ساتھ:
> نوٹ: آپ کی برانچ کا نام ```main``` سے مختلف ہو سکتا ہے۔
> نوٹ، آپ کی برانچ کا نام ڈیفالٹ سے ```main``` مختلف ہو سکتا ہے۔
```bash
git push -u origin main
```
یہ آپ کی "main" برانچ میں موجود کمیٹس کو گِٹ ہب پر بھیجتا ہے۔
یہ آپ کی "main" برانچ میں موجود کمیٹس کو GitHub پر بھیجتا ہے۔ کمانڈ میں `-u` شامل کرنے کے ساتھ `upstream` برانچ سیٹ کرنا آپ کی لوکل برانچ اور ریموٹ برانچ کے درمیان ایک لنک قائم کرتا ہے، تاکہ آپ مستقبل میں برانچ کا نام بتائے بغیر صرف git push یا git pull استعمال کر سکیں۔ Git خود بخود اپ اسٹریم برانچ استعمال کرے گا اور آپ کو مستقبل کی کمانڈز میں برانچ کا نام واضح طور پر بتانے کی ضرورت نہیں ہوگی۔
2. **مزید تبدیلیاں شامل کریں**۔ اگر آپ مزید تبدیلیاں کرنا اور انہیں گِٹ ہب پر بھیجنا چاہتے ہیں تو آپ کو صرف درج ذیل تین کمانڈز استعمال کرنے کی ضرورت ہوگی:
2. **مزید تبدیلیاں شامل کریں**۔ اگر آپ مزید تبدیلیاں کرنا اور انہیں GitHub پر بھیجنا چاہتے ہیں تو آپ کو صرف درج ذیل تین کمانڈز استعمال کرنے کی ضرورت ہوگی:
```bash
git add .
@ -164,69 +164,69 @@ CO_OP_TRANSLATOR_METADATA:
git push
```
> ٹپ: آپ `.gitignore` فائل اپنانا بھی چاہیں گے تاکہ وہ فائلیں جو آپ ٹریک نہیں کرنا چاہتے گِٹ ہب پر ظاہر نہ ہوں - جیسے وہ نوٹس فائل جو آپ اسی فولڈر میں رکھتے ہیں لیکن اس کا کوئی مقام پبلک ریپوزٹری میں نہیں ہے۔ آپ `.gitignore` فائلز کے ٹیمپلیٹس یہاں تلاش کر سکتے ہیں: [.gitignore templates](https://github.com/github/gitignore)۔
> ٹپ، آپ `.gitignore` فائل اپنانا بھی چاہ سکتے ہیں تاکہ وہ فائلیں جنہیں آپ ٹریک نہیں کرنا چاہتے GitHub پر ظاہر نہ ہوں - جیسے وہ نوٹس فائل جو آپ اسی فولڈر میں محفوظ کرتے ہیں لیکن اس کا کوئی مقام پبلک ریپوزیٹری میں نہیں ہے۔ آپ `.gitignore` فائلز کے ٹیمپلیٹس یہاں تلاش کر سکتے ہیں: [.gitignore templates](https://github.com/github/gitignore)۔
#### کمیٹ میسجز
#### کمیٹ میسیجز
ایک بہترین گِٹ کمیٹ سبجیکٹ لائن درج ذیل جملے کو مکمل کرتی ہے:
ایک بہترین Git کمیٹ سبجیکٹ لائن درج ذیل جملے کو مکمل کرتی ہے:
اگر لاگو کیا گیا، تو یہ کمیٹ <آپ کی سبجیکٹ لائن یہاں> کرے گا۔
سبجیکٹ کے لیے حکم دینے والے، موجودہ زمانے کا استعمال کریں: "change" نہ کہ "changed" یا "changes"۔
سبجیکٹ کی طرح، باڈی (اختیاری) میں بھی حکم دینے والے، موجودہ زمانے کا استعمال کریں۔ باڈی میں تبدیلی کی وجہ شامل کریں اور اسے پچھلے رویے کے ساتھ موازنہ کریں۔ آپ `کیوں` کی وضاحت کر رہے ہیں، نہ کہ `کیسے`۔
سبجیکٹ کے لیے imperative، present tense استعمال کریں: "change" نہ کہ "changed" یا "changes"۔
سبجیکٹ کی طرح، باڈی (اختیاری) میں بھی imperative، present tense استعمال کریں۔ باڈی میں تبدیلی کی وجہ شامل کریں اور اسے پچھلے رویے کے ساتھ موازنہ کریں۔ آپ `کیوں` کی وضاحت کر رہے ہیں، نہ کہ `کیسے`۔
✅ گِٹ ہب پر کچھ وقت گزاریں۔ کیا آپ کوئی واقعی بہترین کمیٹ میسج تلاش کر سکتے ہیں؟ کیا آپ کوئی بہت ہی مختصر میسج تلاش کر سکتے ہیں؟ آپ کے خیال میں کمیٹ میسج میں کون سی معلومات سب سے زیادہ اہم اور مفید ہیں؟
✅ چند منٹ نکال کر GitHub پر گھومیں۔ کیا آپ کوئی واقعی بہترین کمیٹ میسیج تلاش کر سکتے ہیں؟ کیا آپ کوئی بہت ہی مختصر میسیج تلاش کر سکتے ہیں؟ آپ کے خیال میں کمیٹ میسیج میں کون سی معلومات سب سے زیادہ اہم اور مفید ہیں؟
### کام: تعاون کریں
گِٹ ہب پر چیزیں ڈالنے کی بنیادی وجہ یہ تھی کہ دوسرے ڈویلپرز کے ساتھ تعاون ممکن ہو سکے۔
GitHub پر چیزیں ڈالنے کی بنیادی وجہ دوسرے ڈویلپرز کے ساتھ تعاون ممکن بنانا تھا۔
## دوسروں کے ساتھ پروجیکٹس پر کام کرنا
> ویڈیو دیکھیں
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
اپنی ریپوزٹری میں، `Insights > Community` پر جائیں تاکہ یہ دیکھ سکیں کہ آپ کا پروجیکٹ تجویز کردہ کمیونٹی معیارات کے ساتھ کیسے موازنہ کرتا ہے۔
اپنی ریپوزیٹری میں، `Insights > Community` پر جائیں تاکہ دیکھ سکیں کہ آپ کا پروجیکٹ تجویز کردہ کمیونٹی معیارات کے ساتھ کیسے موازنہ کرتا ہے۔
یہاں کچھ چیزیں ہیں جو آپ کی گِٹ ہب ریپو کو بہتر بنا سکتی ہیں:
یہاں کچھ چیزیں ہیں جو آپ کے GitHub ریپو کو بہتر بنا سکتی ہیں:
- **تفصیل**۔ کیا آپ نے اپنے پروجیکٹ کے لیے تفصیل شامل کی؟
- **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 شامل کیا؟ GitHub [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 فائلز، اگرچہ انہیں تیار کرنے میں وقت لگتا ہے، اکثر مصروف مینٹینرز نظر انداز کر دیتے ہیں۔ کیا آپ کسی خاص طور پر وضاحتی مثال تلاش کر سکتے ہیں؟ نوٹ: کچھ [اوزار](https://www.makeareadme.com/) ہیں جو اچھی README بنانے میں مدد کرتے ہیں، آپ انہیں آزما سکتے ہیں۔
✅ README فائلز، حالانکہ انہیں تیار کرنے میں وقت لگتا ہے، اکثر مصروف مینٹینرز نظر انداز کر دیتے ہیں۔ کیا آپ کسی خاص طور پر وضاحتی مثال تلاش کر سکتے ہیں؟ نوٹ: کچھ [اوزار](https://www.makeareadme.com/) ہیں جو اچھے READMEs بنانے میں مدد کرتے ہیں، جنہیں آپ آزما سکتے ہیں۔
### کام: کوڈ کو مرج کریں
### کام: کچھ کوڈ مرج کریں
تعاون کی دستاویزات لوگوں کو پروجیکٹ میں تعاون کرنے میں مدد دیتی ہیں۔ یہ وضاحت کرتی ہیں کہ آپ کس قسم کے تعاون کی تلاش میں ہیں اور یہ عمل کیسے کام کرتا ہے۔ تعاون کرنے والوں کو آپ کی گِٹ ہب ریپو میں تعاون کرنے کے لیے درج ذیل مراحل سے گزرنا ہوگا:
تعاون کی دستاویزات لوگوں کو پروجیکٹ میں تعاون کرنے میں مدد دیتی ہیں۔ یہ وضاحت کرتی ہیں کہ آپ کس قسم کے تعاون کی تلاش کر رہے ہیں اور یہ عمل کیسے کام کرتا ہے۔ تعاون کرنے والوں کو آپ کے GitHub ریپو میں تعاون کرنے کے قابل ہونے کے لیے ایک سلسلہ وار مراحل سے گزرنا ہوگا:
1. **آپ کی ریپو کو فورک کرنا**۔ آپ شاید چاہیں گے کہ لوگ آپ کے پروجیکٹ کو _فورک_ کریں۔ فورک کرنے کا مطلب ہے کہ آپ کی ریپوزٹری کی ایک نقل ان کے گِٹ ہب پروفائل پر بنائی جائے۔
1. **کلون**۔اس کے بعد وہ پروجیکٹ کو اپنے لوکل کمپیوٹر پر کلون کریں گے۔
1. **آپ کے ریپو کو فورک کرنا**۔ آپ شاید چاہیں گے کہ لوگ آپ کے پروجیکٹ کو _فورک_ کریں۔ فورک کرنے کا مطلب ہے کہ آپ کے ریپوزیٹری کی ایک نقل ان کے GitHub پروفائل پر بنائی جائے۔
1. **کلون**۔وہاں سے وہ پروجیکٹ کو اپنے لوکل کمپیوٹر پر کلون کریں گے۔
1. **برانچ بنائیں**۔ آپ چاہیں گے کہ وہ اپنے کام کے لیے ایک _برانچ_ بنائیں۔
1. **اپنی تبدیلی کو ایک علاقے پر مرکوز کریں**۔ تعاون کرنے والوں سے کہیں کہ وہ اپنی تبدیلیوں کو ایک وقت میں ایک چیز پر مرکوز کریں - اس طرح ان کے کام کو _مرج_ کرنے کے امکانات زیادہ ہوں گے۔ تصور کریں کہ وہ ایک بگ فکس لکھتے ہیں، ایک نئی خصوصیت شامل کرتے ہیں، اور کئی ٹیسٹ اپ ڈیٹ کرتے ہیں - اگر آپ 3 میں سے 2 یا 1 تبدیلیاں لاگو کرنا چاہتے ہیں تو کیا ہوگا؟
1. **اپنی تبدیلی کو ایک علاقے پر مرکوز کریں**۔ تعاون کرنے والوں سے کہیں کہ وہ اپنی شراکت کو ایک وقت میں ایک چیز پر مرکوز کریں - اس طرح ان کے کام کو _مرج_ کرنے کے امکانات زیادہ ہیں۔ تصور کریں کہ وہ ایک بگ فکس لکھتے ہیں، ایک نئی خصوصیت شامل کرتے ہیں، اور کئی ٹیسٹس کو اپ ڈیٹ کرتے ہیں - اگر آپ 3 میں سے 2 یا 3 میں سے 1 تبدیلی کو نافذ کرنا چاہتے ہیں یا کر سکتے ہیں تو کیا ہوگا؟
✅ ایسی صورتحال کا تصور کریں جہاں برانچز خاص طور پر اچھا کوڈ لکھنے اور بھیجنے کے لیے اہم ہوں۔ آپ کون سے استعمال کے کیسز سوچ سکتے ہیں؟
✅ ایسی صورتحال کا تصور کریں جہاں برانچز اچھا کوڈ لکھنے اور بھیجنے کے لیے خاص طور پر اہم ہوں۔ آپ کون سے استعمال کے کیسز سوچ سکتے ہیں؟
> نوٹ: وہ تبدیلی بنیں جو آپ دنیا میں دیکھنا چاہتے ہیں، اور اپنے کام کے لیے برانچز بنائیں۔ آپ جو بھی کمیٹ کریں گے وہ اس برانچ پر ہوگا جس پر آپ اس وقت "چیک آؤٹ" ہیں۔ `git status` استعمال کریں تاکہ یہ دیکھ سکیں کہ آپ کس برانچ پر ہیں۔
> نوٹ، وہ تبدیلی بنیں جو آپ دنیا میں دیکھنا چاہتے ہیں، اور اپنے کام کے لیے برانچز بنائیں۔ آپ جو بھی کمیٹس کریں گے وہ اس برانچ پر کیے جائیں گے جس پر آپ اس وقت "چیک آؤٹ" ہیں۔ `git status` استعمال کریں تاکہ دیکھ سکیں کہ وہ کون سی برانچ ہے۔
آئیے ایک تعاون کرنے والے کے ورک فلو سے گزرتے ہیں۔ فرض کریں کہ تعاون کرنے والے نے پہلے ہی ریپو کو _فورک_ اور _کلون_ کر لیا ہے، لہذا ان کے پاس ایک گِٹ ریپو ہے جو ان کے لوکل کمپیوٹر پر کام کرنے کے لیے تیار ہے:
آئیے ایک تعاون کرنے والے کے ورک فلو سے گزرتے ہیں۔ فرض کریں کہ تعاون کرنے والے نے پہلے ہی ریپو کو _فورک_ اور _کلون_ کیا ہے تاکہ ان کے پاس ایک Git ریپو ہو جس پر وہ اپنے لوکل کمپیوٹر پر کام کر سکیں:
1. **برانچ بنائیں**۔`git branch` کمانڈ استعمال کریں تاکہ ایک برانچ بنائی جا سکے جس میں وہ تبدیلیاں ہوں جو وہ تعاون کے لیے دینا چاہتے ہیں:
1. **برانچ بنائیں**۔کمانڈ `git branch` استعمال کریں تاکہ ایک برانچ بنائی جا سکے جو ان تبدیلیوں کو شامل کرے گی جنہیں وہ تعاون کرنا چاہتے ہیں:
```bash
git branch [branch-name]
```
1. **ورکنگ برانچ پر سوئچ کریں**۔ مخصوص برانچ پر سوئچ کریں اور `git switch` کے ساتھ ورکنگ ڈائریکٹری کو اپ ڈیٹ کریں:
1. **ورکنگ برانچ پر سوئچ کریں**۔ مخصوص برانچ پر سوئچ کریں اور ورکنگ ڈائریکٹری کو `git switch` کے ساتھ اپ ڈیٹ کریں:
```bash
git switch [branch-name]
```
1. **کام کریں**۔ اس مرحلے پر آپ اپنی تبدیلیاں شامل کرنا چاہتے ہیں۔ گِٹ کو اس کے بارے میں بتانا نہ بھولیں درج ذیل کمانڈز کے ساتھ:
1. **کام کریں**۔ اس وقت آپ اپنی تبدیلیاں شامل کرنا چاہتے ہیں۔ Git کو اس کے بارے میں بتانا نہ بھولیں درج ذیل کمانڈز کے ساتھ:
```bash
git add .
@ -235,52 +235,63 @@ CO_OP_TRANSLATOR_METADATA:
یقینی بنائیں کہ آپ اپنی کمیٹ کو اچھا نام دیں، اپنے لیے اور اس ریپو کے مینٹینر کے لیے جس پر آپ مدد کر رہے ہیں۔
1. **اپنے کام کو `main` برانچ کے ساتھ ملائیں**۔ کسی وقت آپ کام مکمل کر لیتے ہیں اور آپ اپنے کام کو `main` برانچ کے ساتھ ملانا چاہتے ہیں۔ اس دوران `main` برانچ میں تبدیلیاں ہو سکتی ہیں، لہذا یقینی بنائیں کہ آپ پہلے اسے درج ذیل کمانڈز کے ساتھ تازہ ترین کریں:
1. **اپنے کام کو `main` برانچ کے ساتھ ملائیں**۔ کسی وقت آپ کام مکمل کر لیتے ہیں اور آپ اپنے کام کو `main` برانچ کے ساتھ ملانا چاہتے ہیں۔ اس دوران `main` برانچ میں تبدیلی ہو سکتی ہے، لہذا یقینی بنائیں کہ آپ پہلے اسے درج ذیل کمانڈز کے ساتھ تازہ ترین کریں:
```bash
git switch main
git pull
```
اس مرحلے پر آپ یہ یقینی بنانا چاہتے ہیں کہ کوئی بھی _تنازعہ_، ایسی صورتحال جہاں گِٹ آسانی سے تبدیلیوں کو _ملانے_ میں ناکام ہو، آپ کی ورکنگ برانچ میں ہو۔ لہذا درج ذیل کمانڈز چلائیں:
اس وقت آپ یہ یقینی بنانا چاہتے ہیں کہ کوئی _تنازعات_، ایسی صورتحال جہاں Git آسانی سے _تبدیلیوں کو ملانے_ میں ناکام ہو، آپ کی ورکنگ برانچ میں ہوں۔ لہذا درج ذیل کمانڈز چلائیں:
```bash
git switch [branch_name]
git merge main
```
یہ `main` سے تمام تبدیلیاں آپ کی برانچ میں لے آئے گا اور امید ہے کہ آپ آسانی سے کام جاری رکھ سکیں گے۔ اگر نہیں، تو VS Code آپ کو بتائے گا کہ گِٹ کہاں _کنفیوز_ ہے اور آپ متاثرہ فائلوں کو تبدیل کر کے بتا سکتے ہیں کہ کون سا مواد زیادہ درست ہے۔
کمانڈ `git merge main``main` سے تمام تبدیلیاں آپ کی برانچ میں لے آئے گی۔ امید ہے کہ آپ بس جاری رکھ سکتے ہیں۔ اگر نہیں، تو VS Code آپ کو بتائے گا کہ Git کہاں _کنفیوز_ ہے اور آپ متاثرہ فائلوں کو تبدیل کر کے بتا سکتے ہیں کہ کون سا مواد سب سے زیادہ درست ہے۔
1. **اپنا کام گِٹ ہب پر بھیجیں**۔ گِٹ ہب پر اپنا کام بھیجنے کا مطلب دو چیزیں ہیں۔ اپنی برانچ کو اپنی ریپو پر پش کرنا اور پھر ایک PR (پُل ریکویسٹ) کھولنا۔
کسی مختلف برانچ پر سوئچ کرنے کے لیے، جدید `git switch` کمانڈ استعمال کریں:
```bash
git switch [branch_name]
1. **اپنا کام GitHub پر بھیجیں**۔ اپنا کام GitHub پر بھیجنے کا مطلب دو چیزیں ہیں۔ اپنی برانچ کو اپنے ریپو پر پش کریں اور پھر ایک PR، Pull Request کھولیں۔
```bash
git push --set-upstream origin [branch-name]
```
اوپر دی گئی کمانڈ آپ کی فورک کی گئی ریپو پر برانچ بناتی ہے۔
اوپر دی گئی کمانڈ آپ کے فورک کیے گئے ریپو پر برانچ بناتی ہے۔
1. **PR کھولیں**۔ اگلا مرحلہ PR کھولنا ہے۔ آپ یہ کام GitHub پر فورک کیے گئے ریپو پر جا کر کرتے ہیں۔ GitHub پر آپ کو ایک اشارہ نظر آئے گا جہاں یہ پوچھا جائے گا کہ آیا آپ نیا PR بنانا چاہتے ہیں، آپ اس پر کلک کریں گے اور ایک انٹرفیس پر پہنچیں گے جہاں آپ کمیٹ میسج کا عنوان تبدیل کر سکتے ہیں اور اسے ایک مناسب تفصیل دے سکتے ہیں۔ اب وہ ریپو کا مینٹینر جسے آپ نے فورک کیا تھا، اس PR کو دیکھے گا اور _امید ہے_ کہ وہ آپ کی کوشش کو سراہیں گے اور _merge_ کریں گے۔ آپ اب ایک کنٹریبیوٹر ہیں، واہ! :)
1. **صفائی کریں**۔ یہ اچھا عمل سمجھا جاتا ہے کہ PR کامیابی سے merge ہونے کے بعد _صفائی کریں_۔ آپ کو اپنی لوکل برانچ اور وہ برانچ جو آپ نے GitHub پر پش کی تھی، دونوں کو صاف کرنا ہوگا۔ پہلے اسے لوکل طور پر درج ذیل کمانڈ کے ذریعے ڈیلیٹ کریں:
```bash
git branch -d [branch-name]
```
1. **PR کھولیں**۔ اگلا، آپ ایک PR کھولنا چاہتے ہیں۔ آپ یہ گِٹ ہب پر فورک کی گئی ریپو پر جا کر کرتے ہیں۔ آپ کو گِٹ ہب پر ایک اشارہ نظر آئے گا جہاں یہ پوچھے گا کہ کیا آپ ایک نیا PR بنانا چاہتے ہیں، آپ اس پر کلک کریں گے اور آپ کو ایک انٹرفیس پر لے جایا جائے گا جہاں آپ کمیٹ میسج کا عنوان تبدیل کر سکتے ہیں، اسے ایک زیادہ موزوں وضاحت دے سکتے ہیں۔ اب وہ ریپو مینٹینر جسے آپ نے فورک کیا تھا، اس PR کو دیکھے گا اور _امید ہے_ کہ وہ اس کی تعریف کریں گے اور آپ کے PR کو _مرج_ کریں گے۔ آپ اب ایک تعاون کرنے والے ہیں، مبارک ہو :)
اس کے بعد GitHub پر فورک کیے گئے ریپو کے صفحے پر جائیں اور وہ ریموٹ برانچ ہٹا دیں جو آپ نے ابھی پش کی تھی۔
1. **صفائی کریں**۔ یہ اچھا عمل سمجھا
`پُل ریکویسٹ` ایک عجیب سا لفظ لگتا ہے کیونکہ حقیقت میں آپ اپنی تبدیلیاں پروجیکٹ میں "پش" کرنا چاہتے ہیں۔ لیکن پروجیکٹ کے مالک یا کور ٹیم کو آپ کی تبدیلیوں پر غور کرنا ہوتا ہے اس سے پہلے کہ وہ پروجیکٹ کی "مین" برانچ کے ساتھ ضم کریں، تو آپ دراصل ایک فیصلہ کی درخواست کر رہے ہیں کہ آیا یہ تبدیلی قبول کی جائے یا نہیں۔
`Pull request` ایک عجیب سا لفظ لگتا ہے کیونکہ حقیقت میں آپ اپنی تبدیلیاں پروجیکٹ میں پش کرنا چاہتے ہیں۔ لیکن مینٹینر (پروجیکٹ کے مالک) یا کور ٹیم کو آپ کی تبدیلیوں پر غور کرنا ہوتا ہے اس سے پہلے کہ وہ پروجیکٹ کی "main" برانچ کے ساتھ merge کریں، اس لیے آپ حقیقت میں مینٹینر سے تبدیلی کی منظوری کی درخواست کر رہے ہیں۔
پُل ریکویسٹ وہ جگہ ہے جہاں آپ برانچ پر کی گئی تبدیلیوں کا موازنہ اور بحث کر سکتے ہیں، ریویوز، کمنٹس، انٹیگریٹڈ ٹیسٹس، اور مزید کے ساتھ۔ ایک اچھا پُل ریکویسٹ تقریباً وہی اصول اپناتا ہے جو ایک کمیٹ میسج کے لیے ہوتے ہیں۔ آپ مسئلے کے ٹریکر میں کسی مسئلے کا حوالہ دے سکتے ہیں، جب آپ کا کام مثلاً کسی مسئلے کو حل کرتا ہے۔ یہ `#` کے ساتھ مسئلے کے نمبر کا استعمال کرتے ہوئے کیا جاتا ہے۔ مثال کے طور پر `#97`۔
Pull request وہ جگہ ہے جہاں آپ برانچ پر کی گئی تبدیلیوں کا موازنہ اور بحث کر سکتے ہیں، ریویوز، کمنٹس، انٹیگریٹڈ ٹیسٹس، اور مزید کے ساتھ۔ ایک اچھا pull request تقریباً وہی اصول اپناتا ہے جو کمیٹ میسج کے لیے ہوتے ہیں۔ آپ مسئلے کے ٹریکر میں کسی مسئلے کا حوالہ دے سکتے ہیں، جب آپ کا کام کسی مسئلے کو حل کرتا ہے۔ یہ `#` کے ساتھ اور مسئلے کے نمبر کے ذریعے کیا جاتا ہے۔ مثال کے طور پر `#97`۔
🤞امید ہے کہ تمام چیکس پاس ہو جائیں اور پروجیکٹ کے مالک آپ کی تبدیلیوں کو پروجیکٹ میں ضم کر دیں🤞
🤞امید ہے کہ تمام چیکس پاس ہو جائیں اور پروجیکٹ کے مالک آپ کی تبدیلیوں کو پروجیکٹ میں merge کر دیں🤞
اپنی موجودہ لوکل ورکنگ برانچ کو GitHub پر متعلقہ ریموٹ برانچ سے تمام نئے کمیٹس کے ساتھ اپڈیٹ کریں:
اپنی موجودہ لوکل ورکنگ برانچ کو GitHub پر متعلقہ ریموٹ برانچ سے تمام نئے کمیٹس کے ساتھ اپڈیٹ کریں:
`git pull`
## اوپن سورس میں تعاون کیسے کریں
سب سے پہلے، GitHub پر ایک ایسا ریپوزیٹری (یا **ریپو**) تلاش کریں جو آپ کے دلچسپی کا ہو اور جس میں آپ تبدیلی کرنا چاہتے ہوں۔ آپ اس کے مواد کو اپنی مشین پر کاپی کرنا چاہیں گے۔
سب سے پہلے، GitHub پر ایک ریپوزیٹری (یا **ریپو**) تلاش کریں جو آپ کے دلچسپی کے مطابق ہو اور جس میں آپ تبدیلی کرنا چاہتے ہوں۔ آپ اس کے مواد کو اپنی مشین پر کاپی کرنا چاہیں گے۔
✅ 'ابتدائی دوستانہ' ریپوز تلاش کرنے کا ایک اچھا طریقہ یہ ہے کہ [ٹیگ 'good-first-issue' کے ذریعے تلاش کریں](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)۔
✅ 'beginner-friendly' ریپوز تلاش کرنے کا ایک اچھا طریقہ یہ ہے کہ [tag 'good-first-issue' کے ذریعے تلاش کریں](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)۔
کوڈ کاپی کرنے کے کئی طریقے ہیں۔ ایک طریقہ یہ ہے کہ ریپوزیٹری کے مواد کو "کلون" کریں، HTTPS، SSH، یا GitHub CLI (کمانڈ لائن انٹرفیس) کا استعمال کرتے ہوئے۔
کوڈ کاپی کرنے کے کئی طریقے ہیں۔ ایک طریقہ یہ ہے کہ ریپوزیٹری کے مواد کو "clone" کریں، HTTPS، SSH، یا GitHub CLI (کمانڈ لائن انٹرفیس) کا استعمال کرتے ہوئے۔
اپنا ٹرمینل کھولیں اور ریپوزیٹری کو اس طرح کلون کریں:
`git clone https://github.com/ProjectURL`
@ -288,32 +299,32 @@ CO_OP_TRANSLATOR_METADATA:
پروجیکٹ پر کام کرنے کے لیے، صحیح فولڈر پر جائیں:
`cd ProjectURL`
آپ پورے پروجیکٹ کو [Codespaces](https://github.com/features/codespaces)، GitHub کے ایمبیڈڈ کوڈ ایڈیٹر / کلاؤڈ ڈیولپمنٹ ماحول، یا [GitHub Desktop](https://desktop.github.com/) کا استعمال کرتے ہوئے بھی کھول سکتے ہیں۔
آپ پورے پروجیکٹ کو [Codespaces](https://github.com/features/codespaces)، GitHub کے ایمبیڈڈ کوڈ ایڈیٹر / کلاؤڈ ڈیولپمنٹ ماحول، یا [GitHub Desktop](https://desktop.github.com/) کے ذریعے بھی کھول سکتے ہیں۔
آخر میں، آپ کوڈ کو زپ فولڈر میں ڈاؤنلوڈ بھی کر سکتے ہیں۔
آخر میں، آپ کوڈ کو زپ فولڈر میں ڈاؤنلوڈ کر سکتے ہیں۔
### GitHub کے بارے میں کچھ مزید دلچسپ باتیں
آپ GitHub پر کسی بھی پبلک ریپوزیٹری کو اسٹار، واچ اور/یا "فورک" کر سکتے ہیں۔ آپ اپنے اسٹار کردہ ریپوزیٹریز کو اوپر دائیں ڈراپ ڈاؤن مینو میں تلاش کر سکتے ہیں۔ یہ کوڈ کے لیے بک مارکنگ جیسا ہے۔
آپ GitHub پر کسی بھی پبلک ریپوزیٹری کو اسٹار، واچ اور/یا "fork" کر سکتے ہیں۔ آپ اپنے اسٹار کردہ ریپوز کو اوپر دائیں ڈراپ ڈاؤن مینو میں تلاش کر سکتے ہیں۔ یہ کوڈ کے لیے بک مارکنگ کی طرح ہے۔
پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر GitHub پر "Issues" ٹیب میں جب تک کہ دوسری جگہ نہ بتایا جائے، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور Pull Requests ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بحث اور جائزہ لیتے ہیں۔
پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر GitHub پر "Issues" ٹیب میں جب تک کہ دوسری جگہ کا ذکر نہ ہو، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور Pull Requests ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بحث اور جائزہ لیتے ہیں۔
پروجیکٹس میں فورمز، میلنگ لسٹس، یا چیٹ چینلز جیسے Slack، Discord یا IRC میں بھی گفتگو ہو سکتی ہے۔
✅ اپنے نئے GitHub ریپو کے ارد گرد دیکھیں اور کچھ چیزیں آزمائیں، جیسے سیٹنگز میں ترمیم کرنا، اپنے ریپو میں معلومات شامل کرنا، اور ایک پروجیکٹ بنانا (جیسے کانبان بورڈ)۔ کرنے کے لیے بہت کچھ ہے!
✅ اپنے نئے GitHub ریپو کے ارد گرد دیکھیں اور کچھ چیزیں آزمائیں، جیسے سیٹنگز میں ترمیم کرنا، اپنے ریپو میں معلومات شامل کرنا، اور ایک پروجیکٹ بنانا (جیسے Kanban بورڈ)۔ آپ بہت کچھ کر سکتے ہیں!
---
## 🚀 چیلنج
ایک دوست کے ساتھ جوڑی بنائیں اور ایک دوسرے کے کوڈ پر کام کریں۔ ایک پروجیکٹ مل کر بنائیں، کوڈ فورک کریں، برانچز بنائیں، اور تبدیلیوں کو ضم کریں۔
کسی دوست کے ساتھ جوڑی بنائیں اور ایک دوسرے کے کوڈ پر کام کریں۔ ایک پروجیکٹ مل کر بنائیں، کوڈ فورک کریں، برانچز بنائیں، اور تبدیلیوں کو merge کریں۔
## لیکچر کے بعد کا کوئز
[لیکچر کے بعد کا کوئز](https://ff-quizzes.netlify.app/web/en/)
## لیکچر کے بعد کوئز
[لیکچر کے بعد کوئز](https://ff-quizzes.netlify.app/web/en/)
## جائزہ اور خود مطالعہ
اوپن سورس سافٹ ویئر میں تعاون کے بارے میں مزید پڑھیں: [contributing to open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)۔
[اوپن سورس سافٹ ویئر میں تعاون کرنے کے بارے میں مزید پڑھیں](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)۔
Để kiểm tra xem Git đã được cấu hình chưa, bạn có thể gõ:
Để kiểm tra xem Git đã được cấu hình hay chưa, bạn có thể gõ:
`git config --list`
Bạn cũng sẽ cần một tài khoản GitHub, một trình soạn thảo mã (như Visual Studio Code), và mở terminal (hoặc: command prompt).
Truy cập [github.com](https://github.com/) và tạo tài khoản nếu bạn chưa có, hoặc đăng nhập và điền thông tin hồ sơ của bạn.
Truy cập [github.com](https://github.com/) và tạo tài khoản nếu bạn chưa có, hoặc đăng nhập và điền thông tin hồ sơ của mình.
✅ GitHub không phải là kho mã duy nhất trên thế giới; còn có những nền tảng khác, nhưng GitHub là nền tảng được biết đến nhiều nhất.
### Chuẩn bị
Bạn sẽ cần một thư mục chứa dự án mã nguồn trên máy tính cục bộ của mình (laptop hoặc PC), và một kho lưu trữ công khai trên GitHub, nơi sẽ đóng vai trò làm ví dụ để bạn học cách đóng góp vào các dự án của người khác.
Bạn sẽ cần một thư mục chứa dự án mã nguồn trên máy tính của mình (laptop hoặc PC), và một kho lưu trữ công khai trên GitHub, để làm ví dụ về cách đóng góp vào các dự án của người khác.
---
## Quản lý mã nguồn
Giả sử bạn có một thư mục cục bộ chứa một dự án mã nguồn và bạn muốn bắt đầu theo dõi tiến trình của mình bằng git - hệ thống kiểm soát phiên bản. Một số người so sánh việc sử dụng git giống như viết một lá thư tình gửi đến bản thân trong tương lai. Khi đọc lại các thông điệp commit sau vài ngày, vài tuần hoặc vài tháng, bạn sẽ nhớ lại lý do tại sao bạn đã đưa ra quyết định đó, hoặc "quay lại" một thay đổi - điều này xảy ra khi bạn viết các thông điệp commit tốt.
Giả sử bạn có một thư mục cục bộ chứa một dự án mã nguồn và bạn muốn bắt đầu theo dõi tiến trình của mình bằng git - hệ thống kiểm soát phiên bản. Một số người ví việc sử dụng git như viết một lá thư tình gửi cho chính mình trong tương lai. Khi đọc lại các thông điệp commit sau vài ngày, vài tuần hoặc vài tháng, bạn sẽ có thể nhớ lại lý do tại sao bạn đưa ra quyết định, hoặc "quay lại" một thay đổi - điều này xảy ra khi bạn viết các thông điệp commit tốt.
### Nhiệm vụ: Tạo kho lưu trữ và commit mã nguồn
@ -61,16 +61,16 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
1. **Tạo kho lưu trữ trên GitHub**. Trên GitHub.com, trong tab kho lưu trữ, hoặc từ thanh điều hướng ở góc trên bên phải, tìm nút **new repo**.
1. Đặt tên cho kho lưu trữ (thư mục) của bạn.
1. Đặt tên cho kho lưu trữ của bạn (thư mục)
1. Chọn **create repository**.
1. **Điều hướng đến thư mục làm việc của bạn**. Trong terminal, chuyển đến thư mục (còn gọi là thư mục làm việc) mà bạn muốn bắt đầu theo dõi. Gõ:
1. **Đi đến thư mục làm việc của bạn**. Trong terminal, chuyển đến thư mục (còn gọi là thư mục làm việc) mà bạn muốn bắt đầu theo dõi. Gõ:
```bash
cd [name of your folder]
```
1. **Khởi tạo một kho lưu trữ git**. Trong dự án của bạn, gõ:
1. **Khởi tạo kho lưu trữ git**. Trong dự án của bạn, gõ:
```bash
git init
@ -82,7 +82,7 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
git status
```
Kết quả có thể trông giống như sau:
Kết quả đầu ra có thể trông giống như sau:
```output
Changes not staged for commit:
@ -93,16 +93,16 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
modified: file2.txt
```
Thông thường, lệnh `git status`sẽ cho bạn biết những tệp nào đã sẵn sàng để _lưu_ vào kho lưu trữ hoặc có thay đổi mà bạn có thể muốn lưu lại.
Thông thường, lệnh `git status` cho bạn biết những thông tin như tệp nào đã sẵn sàng để _lưu_ vào kho lưu trữ hoặc có thay đổi mà bạn có thể muốn lưu lại.
1. **Thêm tất cả các tệp để theo dõi**
Điều này còn được gọi là đưa tệp vào khu vực staging.
Điều này còn được gọi là giai đoạn staging tệp/ thêm tệp vào khu vực staging.
```bash
git add .
```
Lệnh `git add` cùng với đối số `.` chỉ định rằng tất cả các tệp và thay đổi của bạn sẽ được theo dõi.
Lệnh `git add` cộng với đối số `.` chỉ định rằng tất cả các tệp và thay đổi của bạn sẽ được theo dõi.
1. **Thêm các tệp được chọn để theo dõi**
@ -110,25 +110,25 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
git add [file or folder name]
```
Điều này giúp chúng ta chỉ thêm các tệp được chọn vào khu vực staging khi không muốn commit tất cả các tệp cùng một lúc.
Lệnh này giúp chúng ta chỉ thêm các tệp được chọn vào khu vực staging khi không muốn commit tất cả các tệp cùng một lúc.
1. **Hủy bỏ staging tất cả các tệp**
1. **Hủy giai đoạn tất cả các tệp**
```bash
git reset
```
Lệnh này giúp chúng ta hủy bỏ staging tất cả các tệp cùng một lúc.
Lệnh này giúp chúng ta hủy giai đoạn tất cả các tệp cùng một lúc.
1. **Hủy bỏ staging một tệp cụ thể**
1. **Hủy giai đoạn một tệp cụ thể**
```bash
git reset [file or folder name]
```
Lệnh này giúp chúng ta hủy bỏ staging chỉ một tệp cụ thể mà chúng ta không muốn đưa vào commit tiếp theo.
Lệnh này giúp chúng ta hủy giai đoạn chỉ một tệp cụ thể mà chúng ta không muốn đưa vào commit tiếp theo.
1. **Lưu công việc của bạn**. Tại thời điểm này, bạn đã thêm các tệp vào cái gọi là _khu vực staging_. Đây là nơi Git đang theo dõi các tệp của bạn. Để làm cho thay đổi trở nên vĩnh viễn, bạn cần _commit_ các tệp. Để làm điều này, bạn tạo một _commit_ bằng lệnh `git commit`. Một _commit_ đại diện cho một điểm lưu trong lịch sử của kho lưu trữ của bạn. Gõ lệnh sau để tạo một _commit_:
1. **Lưu công việc của bạn**. Tại thời điểm này, bạn đã thêm các tệp vào cái gọi là _khu vực staging_. Đây là nơi Git theo dõi các tệp của bạn. Để làm cho thay đổi trở thành vĩnh viễn, bạn cần _commit_ các tệp. Để làm điều này, bạn tạo một _commit_ bằng lệnh `git commit`. Một _commit_ đại diện cho một điểm lưu trong lịch sử của kho lưu trữ. Gõ lệnh sau để tạo một _commit_:
```bash
git commit -m "first commit"
@ -136,7 +136,7 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
Lệnh này commit tất cả các tệp của bạn, thêm thông điệp "first commit". Đối với các thông điệp commit trong tương lai, bạn sẽ muốn mô tả chi tiết hơn để truyền đạt loại thay đổi bạn đã thực hiện.
1. **Kết nối kho lưu trữ Git cục bộ của bạn với GitHub**. Một kho lưu trữ Git trên máy của bạn là tốt, nhưng đến một lúc nào đó, bạn sẽ muốn sao lưu các tệp của mình ở đâu đó và cũng mời người khác làm việc cùng bạn trên kho lưu trữ của mình. Một nơi tuyệt vời để làm điều đó là GitHub. Nhớ rằng chúng ta đã tạo một kho lưu trữ trên GitHub, vì vậy điều duy nhất cần làm là kết nối kho lưu trữ Git cục bộ của bạn với GitHub. Lệnh `git remote add` sẽ làm điều đó. Gõ lệnh sau:
1. **Kết nối kho lưu trữ Git cục bộ của bạn với GitHub**. Một kho lưu trữ Git trên máy của bạn là tốt, nhưng tại một thời điểm nào đó, bạn sẽ muốn có bản sao lưu các tệp của mình ở đâu đó và cũng mời người khác làm việc với bạn trên kho lưu trữ của mình. Một nơi tuyệt vời để làm điều này là GitHub. Nhớ rằng chúng ta đã tạo một kho lưu trữ trên GitHub, vì vậy điều duy nhất cần làm là kết nối kho lưu trữ Git cục bộ của bạn với GitHub. Lệnh `git remote add` sẽ làm điều đó. Gõ lệnh sau:
> Lưu ý, trước khi gõ lệnh, hãy truy cập trang kho lưu trữ GitHub của bạn để tìm URL kho lưu trữ. Bạn sẽ sử dụng nó trong lệnh dưới đây. Thay thế ```https://github.com/username/repository_name.git``` bằng URL GitHub của bạn.
@ -144,17 +144,17 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
Lệnh này tạo một _remote_, hoặc kết nối, có tên là "origin" trỏ đến kho lưu trữ GitHub mà bạn đã tạo trước đó.
Lệnh này tạo một _remote_, hoặc kết nối, có tên "origin" trỏ đến kho lưu trữ GitHub mà bạn đã tạo trước đó.
1. **Gửi tệp cục bộ lên GitHub**. Cho đến nay, bạn đã tạo một _kết nối_ giữa kho lưu trữ cục bộ và kho lưu trữ GitHub. Hãy gửi các tệp này lên GitHub bằng lệnh `git push`, như sau:
1. **Gửi các tệp cục bộ lên GitHub**. Cho đến nay, bạn đã tạo một _kết nối_ giữa kho lưu trữ cục bộ và kho lưu trữ GitHub. Hãy gửi các tệp này lên GitHub bằng lệnh `git push`, như sau:
> Lưu ý, tên nhánh của bạn có thể khác mặc định so với ```main```.
```bash
git push -u origin main
```
Lệnh này gửi các commit của bạn trong nhánh "main" lên GitHub.
Lệnh này gửi các commit của bạn trong nhánh "main" lên GitHub. Việc thiết lập nhánh `upstream` bao gồm `-u` trong lệnh tạo liên kết giữa nhánh cục bộ của bạn và nhánh từ xa, vì vậy bạn có thể chỉ cần sử dụng git push hoặc git pull mà không cần chỉ định tên nhánh trong tương lai. Git sẽ tự động sử dụng nhánh upstream và bạn sẽ không cần chỉ định tên nhánh rõ ràng trong các lệnh sau này.
2. **Thêm các thay đổi mới**. Nếu bạn muốn tiếp tục thực hiện các thay đổi và đẩy chúng lên GitHub, bạn chỉ cần sử dụng ba lệnh sau:
@ -164,21 +164,21 @@ Giả sử bạn có một thư mục cục bộ chứa một dự án mã ngu
git push
```
> Mẹo, bạn cũng có thể muốn sử dụng tệp `.gitignore` để ngăn các tệp bạn không muốn theo dõi xuất hiện trên GitHub - như tệp ghi chú mà bạn lưu trữ trong cùng thư mục nhưng không có chỗ trong kho lưu trữ công khai. Bạn có thể tìm các mẫu tệp `.gitignore` tại [.gitignore templates](https://github.com/github/gitignore).
> Mẹo, bạn cũng có thể muốn áp dụng tệp `.gitignore` để ngăn các tệp bạn không muốn theo dõi xuất hiện trên GitHub - như tệp ghi chú mà bạn lưu trong cùng thư mục nhưng không có chỗ trong kho lưu trữ công khai. Bạn có thể tìm các mẫu tệp `.gitignore` tại [.gitignore templates](https://github.com/github/gitignore).
#### Thông điệp commit
Một dòng tiêu đề commit Git tuyệt vời hoàn thành câu sau:
Nếu được áp dụng, commit này sẽ <dòngtiêuđềcủabạnởđây>
Đối với tiêu đề, sử dụng thì hiện tại, dạng mệnh lệnh: "thay đổi" thay vì "đã thay đổi" hoặc "đang thay đổi".
Cũng như trong tiêu đề, trong phần thân (tùy chọn), cũng sử dụng thì hiện tại, dạng mệnh lệnh. Phần thân nên bao gồm lý do cho thay đổi và so sánh điều này với hành vi trước đó. Bạn đang giải thích `tại sao`, không phải `như thế nào`.
Đối với tiêu đề, sử dụng thì hiện tại, dạng mệnh lệnh: "change" thay vì "changed" hoặc "changes".
Cũng như trong tiêu đề, trong phần thân (tùy chọn), cũng sử dụng thì hiện tại, dạng mệnh lệnh. Phần thân nên bao gồm lý do cho thay đổi và so sánh điều này với hành vi trước đó. Bạn đang giải thích `tại sao`, không phải `cách thực hiện`.
✅ Dành vài phút để lướt qua GitHub. Bạn có thể tìm thấy một thông điệp commit thực sự tuyệt vời không? Bạn có thể tìm thấy một thông điệp rất tối giản không? Theo bạn, thông tin nào là quan trọng và hữu ích nhất để truyền đạt trong một thông điệp commit?
### Nhiệm vụ: Cộng tác
### Nhiệm vụ: Hợp tác
Lý do chính để đưa mọi thứ lên GitHub là để làm cho việc cộng tác với các nhà phát triển khác trở nên khả thi.
Lý do chính để đưa mọi thứ lên GitHub là để làm cho việc hợp tác với các nhà phát triển khác trở nên khả thi.
## Làm việc trên các dự án cùng người khác
@ -186,35 +186,35 @@ Lý do chính để đưa mọi thứ lên GitHub là để làm cho việc cộ
>
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
Trong kho lưu trữ của bạn, điều hướng đến `Insights > Community` để xem dự án của bạn so sánh như thế nào với các tiêu chuẩn cộng đồng được khuyến nghị.
Trong kho lưu trữ của bạn, điều hướng đến `Insights > Community` để xem dự án của bạn so với các tiêu chuẩn cộng đồng được khuyến nghị như thế nào.
Đây là một số điều có thể cải thiện kho lưu trữ GitHub của bạn:
- **Mô tả**. Bạn đã thêm mô tả cho dự án của mình chưa?
- **README**. Bạn đã thêm README chưa? GitHub cung cấp hướng dẫn để viết một [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **README**. Bạn đã thêm README chưa? GitHub cung cấp hướng dẫn viết [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
- **Hướng dẫn đóng góp**. Dự án của bạn có [hướng dẫn đóng góp](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) không?
- **Quy tắc ứng xử**. Một [Quy tắc ứng xử](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/),
- **Giấy phép**. Có lẽ quan trọng nhất, một [giấy phép](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
Tất cả các tài nguyên này sẽ có lợi cho việc giới thiệu các thành viên mới vào nhóm. Và đây thường là những điều mà các nhà đóng góp mới xem xét trước khi thậm chí nhìn vào mã nguồn của bạn, để tìm hiểu xem dự án của bạn có phải là nơi phù hợp để họ dành thời gian hay không.
Tất cả các tài nguyên này sẽ có lợi cho việc giới thiệu thành viên mới vào nhóm. Và đây thường là những điều mà các cộng tác viên mới xem xét trước khi nhìn vào mã nguồn của bạn, để tìm hiểu xem dự án của bạn có phải là nơi phù hợp để họ dành thời gian hay không.
✅ Các tệp README, mặc dù mất thời gian để chuẩn bị, thường bị bỏ qua bởi các nhà bảo trì bận rộn. Bạn có thể tìm thấy một ví dụ về một README đặc biệt mô tả không? Lưu ý: có một số [công cụ để giúp tạo README tốt](https://www.makeareadme.com/) mà bạn có thể muốn thử.
✅ Các tệp README, mặc dù mất thời gian để chuẩn bị, thường bị bỏ qua bởi các nhà bảo trì bận rộn. Bạn có thể tìm thấy một ví dụ về một tệp README đặc biệt mô tả chi tiết không? Lưu ý: có một số [công cụ giúp tạo README tốt](https://www.makeareadme.com/) mà bạn có thể muốn thử.
### Nhiệm vụ: Gộp mã nguồn
### Nhiệm vụ: Hợp nhất mã nguồn
Tài liệu đóng góp giúp mọi người đóng góp vào dự án. Nó giải thích các loại đóng góp mà bạn đang tìm kiếm và cách quy trình hoạt động. Các nhà đóng góp sẽ cần thực hiện một loạt các bước để có thể đóng góp vào kho lưu trữ của bạn trên GitHub:
Tài liệu đóng góp giúp mọi người đóng góp vào dự án. Nó giải thích các loại đóng góp mà bạn đang tìm kiếm và cách quy trình hoạt động. Các cộng tác viên sẽ cần thực hiện một loạt các bước để có thể đóng góp vào kho lưu trữ của bạn trên GitHub:
1. **Fork kho lưu trữ của bạn**. Bạn có thể muốn mọi người _fork_ dự án của mình. Fork có nghĩa là tạo một bản sao của kho lưu trữ trên hồ sơ GitHub của họ.
1. **Clone**. Từ đó, họ sẽ clone dự án về máy cục bộ của họ.
1. **Tạo một nhánh**. Bạn sẽ muốn yêu cầu họ tạo một _nhánh_ cho công việc của họ.
1. **Tập trung thay đổi vào một khu vực**. Yêu cầu các nhà đóng góp tập trung các đóng góp của họ vào một điều tại một thời điểm - theo cách đó, khả năng bạn có thể _gộp_ công việc của họ sẽ cao hơn. Hãy tưởng tượng họ viết một bản sửa lỗi, thêm một tính năng mới và cập nhật một số bài kiểm tra - điều gì sẽ xảy ra nếu bạn muốn, hoặc chỉ có thể triển khai 2 trong số 3, hoặc 1 trong số 3 thay đổi?
1. **Fork kho lưu trữ của bạn**. Bạn có thể muốn mọi người _fork_ dự án của mình. Fork nghĩa là tạo một bản sao của kho lưu trữ trên hồ sơ GitHub của họ.
1. **Clone**. Từ đó, họ sẽ clone dự án về máy tính cục bộ của mình.
1. **Tạo một nhánh**. Bạn sẽ muốn yêu cầu họ tạo một _nhánh_ cho công việc của mình.
1. **Tập trung thay đổi vào một khu vực**. Yêu cầu các cộng tác viên tập trung đóng góp của họ vào một việc tại một thời điểm - theo cách đó, khả năng bạn có thể _hợp nhất_ công việc của họ sẽ cao hơn. Hãy tưởng tượng họ viết một bản sửa lỗi, thêm một tính năng mới và cập nhật một số bài kiểm tra - điều gì sẽ xảy ra nếu bạn muốn, hoặc chỉ có thể triển khai 2 trong số 3, hoặc 1 trong số 3 thay đổi?
✅ Hãy tưởng tượng một tình huống mà các nhánh đặc biệt quan trọng đối với việc viết và triển khai mã nguồn tốt. Bạn có thể nghĩ ra những trường hợp sử dụng nào?
✅ Hãy tưởng tượng một tình huống mà các nhánh đặc biệt quan trọng đối với việc viết và triển khai mã nguồn tốt. Bạn có thể nghĩ đến những trường hợp sử dụng nào?
> Lưu ý, hãy là sự thay đổi mà bạn muốn thấy trên thế giới, và tạo các nhánh cho công việc của chính bạn. Bất kỳ commit nào bạn thực hiện sẽ được thực hiện trên nhánh mà bạn hiện đang "checkout". Sử dụng `git status` để xem bạn đang ở nhánh nào.
> Lưu ý, hãy là sự thay đổi mà bạn muốn thấy trên thế giới, và tạo các nhánh cho công việc của chính bạn. Bất kỳ commit nào bạn thực hiện sẽ được thực hiện trên nhánh mà bạn hiện đang "checked out". Sử dụng `git status` để xem đó là nhánh nào.
Hãy cùng đi qua quy trình làm việc của một nhà đóng góp. Giả sử nhà đóng góp đã _fork_ và _clone_ kho lưu trữ, vì vậy họ đã có một kho lưu trữ Git sẵn sàng để làm việc trên máy cục bộ của họ:
Hãy đi qua quy trình làm việc của cộng tác viên. Giả sử cộng tác viên đã _fork_ và _clone_ kho lưu trữ, vì vậy họ có một kho lưu trữ Git sẵn sàng để làm việc trên máy cục bộ của mình:
1. **Tạo một nhánh**. Sử dụng lệnh `git branch` để tạo một nhánh sẽ chứa các thay đổi mà họ dự định đóng góp:
1. **Tạo một nhánh**. Sử dụng lệnh `git branch` để tạo một nhánh chứa các thay đổi mà họ dự định đóng góp:
```bash
git branch [branch-name]
@ -235,60 +235,65 @@ Hãy cùng đi qua quy trình làm việc của một nhà đóng góp. Giả s
Đảm bảo bạn đặt tên commit tốt, vì lợi ích của bạn cũng như của người bảo trì kho lưu trữ mà bạn đang giúp đỡ.
1. **Kết hợp công việc của bạn với nhánh `main`**. Đến một lúc nào đó, bạn đã hoàn thành công việc và muốn kết hợp công việc của mình với nhánh `main`. Nhánh `main` có thể đã thay đổi trong khi đó, vì vậy hãy đảm bảo bạn cập nhật nó lên phiên bản mới nhất bằng các lệnh sau:
1. **Kết hợp công việc của bạn với nhánh `main`**. Tại một thời điểm nào đó, bạn đã hoàn thành công việc và muốn kết hợp công việc của mình với nhánh `main`. Nhánh `main` có thể đã thay đổi trong thời gian đó, vì vậy hãy đảm bảo bạn cập nhật nó lên phiên bản mới nhất bằng các lệnh sau:
```bash
git switch main
git pull
```
Tại thời điểm này, bạn muốn đảm bảo rằng bất kỳ _xung đột_ nào, những tình huống mà Git không thể dễ dàng _kết hợp_ các thay đổi, xảy ra trong nhánh làm việc của bạn. Do đó, chạy các lệnh sau:
Tại thời điểm này, bạn muốn đảm bảo rằng bất kỳ _xung đột_ nào, tình huống mà Git không thể dễ dàng _kết hợp_ các thay đổi, xảy ra trong nhánh làm việc của bạn. Do đó, hãy chạy các lệnh sau:
```bash
git switch [branch_name]
git merge main
```
Lệnh này sẽ mang tất cả các thay đổi từ `main` vào nhánh của bạn và hy vọng bạn có thể tiếp tục. Nếu không, VS Code sẽ cho bạn biết nơi Git bị _nhầm lẫn_ và bạn chỉ cần chỉnh sửa các tệp bị ảnh hưởng để xác định nội dung nào là chính xác nhất.
Lệnh `git merge main` sẽ mang tất cả các thay đổi từ `main` vào nhánh của bạn. Hy vọng rằng bạn có thể tiếp tục. Nếu không, VS Code sẽ cho bạn biết nơi Git bị _nhầm lẫn_ và bạn chỉ cần thay đổi các tệp bị ảnh hưởng để nói nội dung nào là chính xác nhất.
Để chuyển sang một nhánh khác, sử dụng lệnh hiện đại `git switch`:
```bash
git switch [branch_name]
1. **Gửi công việc của bạn lên GitHub**. Gửi công việc của bạn lên GitHub có nghĩa là hai điều. Đẩy nhánh của bạn lên kho lưu trữ của bạn và sau đó mở một PR, Pull Request.
1. **Gửi công việc của bạn lên GitHub**. Gửi công việc của bạn lên GitHub nghĩa là hai việc. Đẩy nhánh của bạn lên kho lưu trữ và sau đó mở một PR, Pull Request.
```bash
git push --set-upstream origin [branch-name]
```
Lệnh trên tạo nhánh trên kho lưu trữ đã fork.
1. **Mở một PR**. Tiếp theo, bạn muốn mở một PR. Bạn làm điều đó bằng cách điều hướng đến kho lưu trữ đã fork trên GitHub. Bạn sẽ thấy một chỉ báo trên GitHub hỏi liệu bạn có muốn tạo một PR mới không, bạn nhấp vào đó và được đưa đến giao diện nơi bạn có thể thay đổi tiêu đề thông điệp commit, đưa ra mô tả phù hợp hơn. Bây giờ người bảo trì kho lưu trữ mà bạn đã fork sẽ thấy PR này và _hy vọng_ họ sẽ đánh giá cao và _gộp_ PR của bạn. Bạn bây giờ là một nhà đóng góp, tuyệt vời :)
Lệnh trên tạo nhánh trên kho lưu trữ đã fork của bạn.
1. **Mở PR**. Tiếp theo, bạn cần mở một PR. Bạn làm điều này bằng cách truy cập vào repo đã fork trên GitHub. Bạn sẽ thấy một thông báo trên GitHub hỏi liệu bạn có muốn tạo một PR mới hay không, bạn nhấp vào đó và sẽ được chuyển đến giao diện nơi bạn có thể thay đổi tiêu đề thông điệp commit, thêm mô tả phù hợp hơn. Bây giờ, người quản lý repo mà bạn đã fork sẽ thấy PR này và _hy vọng_ họ sẽ đánh giá cao và _merge_ PR của bạn. Bạn đã trở thành một người đóng góp, tuyệt vời :)
1. **Dọn dẹp**. Việc dọn dẹp sau khi bạn thành công gộp một PR được coi là một thực hành tốt. Bạn muốn dọn dẹp cả nhánh cục bộ của mình và nhánh bạn đã đẩy lên GitHub. Đầu tiên, hãy xóa nó cục bộ bằng lệnh sau:
1. **Dọn dẹp**. Việc _dọn dẹp_ sau khi bạn merge thành công một PR được coi là một thói quen tốt. Bạn cần dọn dẹp cả nhánh cục bộ và nhánh bạn đã đẩy lên GitHub. Đầu tiên, hãy xóa nhánh cục bộ bằng lệnh sau:
```bash
git branch -d [branch-name]
```
Đảm bảo bạn truy cập trang GitHub của kho lưu trữ đã fork và xóa nhánh từ xa mà bạn vừa đẩy lên.
`Pull request` có vẻ là một thuật ngữ kỳ lạ vì thực tế bạn muốn "đẩy" các thay đổi của mình vào dự án. Nhưng người duy trì (chủ dự án) hoặc nhóm cốt lõi cần xem xét các thay đổi của bạn trước khi hợp nhất chúng vào nhánh "main" của dự án, vì vậy thực chất bạn đang yêu cầu một quyết định thay đổi từ người duy trì.
Đảm bảo bạn truy cập trang GitHub của repo đã fork và xóa nhánh từ xa mà bạn vừa đẩy lên.
`Pull request` có vẻ là một thuật ngữ kỳ lạ vì thực tế bạn muốn đẩy thay đổi của mình vào dự án. Nhưng người quản lý (chủ sở hữu dự án) hoặc nhóm cốt lõi cần xem xét thay đổi của bạn trước khi merge nó vào nhánh "main" của dự án, vì vậy thực chất bạn đang yêu cầu một quyết định thay đổi từ người quản lý.
Pull request là nơi để so sánh và thảo luận về các khác biệt được giới thiệu trên một nhánh với các đánh giá, bình luận, kiểm tra tích hợp, và nhiều hơn nữa. Một pull request tốt tuân theo các quy tắc tương tự như một thông điệp commit. Bạn có thể thêm tham chiếu đến một vấn đề trong trình theo dõi vấn đề, ví dụ khi công việc của bạn sửa một vấn đề. Điều này được thực hiện bằng cách sử dụng `#` theo sau bởi số của vấn đề. Ví dụ:`#97`.
Pull request là nơi để so sánh và thảo luận về các khác biệt được giới thiệu trên một nhánh với các đánh giá, bình luận, kiểm tra tích hợp, và nhiều hơn nữa. Một pull request tốt tuân theo các quy tắc tương tự như thông điệp commit. Bạn có thể thêm tham chiếu đến một vấn đề trong trình theo dõi vấn đề, ví dụ khi công việc của bạn sửa một vấn đề. Điều này được thực hiện bằng cách sử dụng `#` theo sau là số của vấn đề. Ví dụ`#97`.
🤞Hy vọng rằng tất cả các kiểm tra đều vượt qua và chủ dự án hợp nhất các thay đổi của bạn vào dự án🤞
🤞Hy vọng rằng tất cả các kiểm tra đều vượt qua và chủ sở hữu dự án merge thay đổi của bạn vào dự án🤞
Cập nhật nhánh làm việc cục bộ hiện tại của bạn với tất cả các commit mới từ nhánh tương ứng trên GitHub:
Cập nhật nhánh làm việc cục bộ hiện tại của bạn với tất cả các commit mới từ nhánh từ xa tương ứng trên GitHub:
`git pull`
## Cách đóng góp cho mã nguồn mở
Đầu tiên, hãy tìm một kho lưu trữ (hoặc **repo**) trên GitHub mà bạn quan tâm và muốn đóng góp một thay đổi. Bạn sẽ muốn sao chép nội dung của nó về máy của mình.
Đầu tiên, hãy tìm một repository (hoặc **repo**) trên GitHub mà bạn quan tâm và muốn đóng góp một thay đổi. Bạn sẽ cần sao chép nội dung của nó về máy của mình.
✅ Một cách tốt để tìm các repo 'thân thiện với người mới bắt đầu' là [tìm kiếm theo thẻ 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
✅ Một cách tốt để tìm các repo 'thân thiện với người mới bắt đầu' là [tìm kiếm theo tag 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Có nhiều cách để sao chép mã. Một cách là "clone" nội dung của kho lưu trữ, sử dụng HTTPS, SSH, hoặc sử dụng GitHub CLI (Command Line Interface).
Có nhiều cách để sao chép mã. Một cách là "clone" nội dung của repository, sử dụng HTTPS, SSH, hoặc sử dụng GitHub CLI (Command Line Interface).
Mở terminal của bạn và clone kho lưu trữ như sau:
Mở terminal của bạn và clone repository như sau:
`git clone https://github.com/ProjectURL`
Để làm việc trên dự án, chuyển đến thư mục phù hợp:
@ -296,23 +301,23 @@ Mở terminal của bạn và clone kho lưu trữ như sau:
Bạn cũng có thể mở toàn bộ dự án bằng [Codespaces](https://github.com/features/codespaces), trình chỉnh sửa mã tích hợp / môi trường phát triển trên đám mây của GitHub, hoặc [GitHub Desktop](https://desktop.github.com/).
Cuối cùng, bạn có thể tải mã xuống dưới dạng một thư mục nén.
Cuối cùng, bạn có thể tải mã về dưới dạng một thư mục nén.
### Một vài điều thú vị hơn về GitHub
Bạn có thể gắn sao, theo dõi và/hoặc "fork" bất kỳ kho lưu trữ công khai nào trên GitHub. Bạn có thể tìm các kho lưu trữ đã gắn sao của mình trong menu thả xuống ở góc trên bên phải. Nó giống như đánh dấu trang, nhưng dành cho mã.
Bạn có thể gắn sao, theo dõi và/hoặc "fork" bất kỳ repository công khai nào trên GitHub. Bạn có thể tìm các repository đã gắn sao của mình trong menu thả xuống ở góc trên bên phải. Nó giống như đánh dấu trang, nhưng dành cho mã.
Các dự án có một trình theo dõi vấn đề, thường là trên GitHub trong tab "Issues" trừ khi được chỉ định khác, nơi mọi người thảo luận về các vấn đề liên quan đến dự án. Và tab Pull Requests là nơi mọi người thảo luận và đánh giá các thay đổi đang được thực hiện.
Các dự án có trình theo dõi vấn đề, thường trên GitHub trong tab "Issues" trừ khi được chỉ định khác, nơi mọi người thảo luận về các vấn đề liên quan đến dự án. Và tab Pull Requests là nơi mọi người thảo luận và đánh giá các thay đổi đang được thực hiện.
Các dự án cũng có thể có các cuộc thảo luận trong diễn đàn, danh sách gửi thư, hoặc các kênh trò chuyện như Slack, Discord hoặc IRC.
Các dự án cũng có thể có thảo luận trong các diễn đàn, danh sách gửi thư, hoặc các kênh trò chuyện như Slack, Discord hoặc IRC.
✅ Hãy khám phá kho lưu trữ GitHub mới của bạn và thử một vài điều, như chỉnh sửa cài đặt, thêm thông tin vào repo của bạn, và tạo một dự án (như bảng Kanban). Có rất nhiều điều bạn có thể làm!
✅ Hãy khám phá repo GitHub mới của bạn và thử một vài điều, như chỉnh sửa cài đặt, thêm thông tin vào repo của bạn, và tạo một dự án (như bảng Kanban). Có rất nhiều điều bạn có thể làm!
---
## 🚀 Thử thách
Hợp tác với một người bạn để làm việc trên mã của nhau. Tạo một dự án chung, fork mã, tạo nhánh, và hợp nhất các thay đổi.
Hợp tác với một người bạn để làm việc trên mã của nhau. Tạo một dự án cùng nhau, fork mã, tạo nhánh, và merge các thay đổi.
## Câu hỏi sau bài giảng
[Câu hỏi sau bài giảng](https://ff-quizzes.netlify.app/web/en/)
@ -321,7 +326,7 @@ Hợp tác với một người bạn để làm việc trên mã của nhau. T
Đọc thêm về [cách đóng góp cho phần mềm mã nguồn mở](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
Luyện tập, luyện tập, luyện tập. GitHub có các lộ trình học tập tuyệt vời tại [skills.github.com](https://skills.github.com):
@ -336,4 +341,4 @@ Hoàn thành [khóa học Tuần đầu tiên trên GitHub](https://skills.githu
---
**Tuyên bố miễn trừ trách nhiệm**:
Tài liệu này đã được dịch bằng dịch vụ dịch thuật AI [Co-op Translator](https://github.com/Azure/co-op-translator). Mặc dù chúng tôi cố gắng đảm bảo độ chính xác, xin lưu ý rằng các bản dịch tự động có thể chứa lỗi hoặc không chính xác. Tài liệu gốc bằng ngôn ngữ bản địa nên được coi là nguồn tham khảo chính thức. Đối với các thông tin quan trọng, chúng tôi khuyến nghị sử dụng dịch vụ dịch thuật chuyên nghiệp từ con người. Chúng tôi không chịu trách nhiệm cho bất kỳ sự hiểu lầm hoặc diễn giải sai nào phát sinh từ việc sử dụng bản dịch này.
Tài liệu này đã được dịch bằng dịch vụ dịch thuật AI [Co-op Translator](https://github.com/Azure/co-op-translator). Mặc dù chúng tôi cố gắng đảm bảo độ chính xác, xin lưu ý rằng các bản dịch tự động có thể chứa lỗi hoặc không chính xác. Tài liệu gốc bằng ngôn ngữ bản địa nên được coi là nguồn thông tin chính thức. Đối với các thông tin quan trọng, nên sử dụng dịch vụ dịch thuật chuyên nghiệp của con người. Chúng tôi không chịu trách nhiệm về bất kỳ sự hiểu lầm hoặc diễn giải sai nào phát sinh từ việc sử dụng bản dịch này.
leestott
7 months ago
committed by
GitHub