You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
339 lines
35 KiB
339 lines
35 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "05666cecb8983a72cf0ce1d18932b5b7",
|
|
"translation_date": "2025-08-26T22:12:37+00:00",
|
|
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
|
|
"language_code": "th"
|
|
}
|
|
-->
|
|
# แนะนำ GitHub
|
|
|
|
บทเรียนนี้จะครอบคลุมพื้นฐานของ GitHub ซึ่งเป็นแพลตฟอร์มสำหรับโฮสต์และจัดการการเปลี่ยนแปลงในโค้ดของคุณ
|
|
|
|
|
|
> ภาพสเก็ตโน้ตโดย [Tomomi Imura](https://twitter.com/girlie_mac)
|
|
|
|
## แบบทดสอบก่อนเรียน
|
|
[แบบทดสอบก่อนเรียน](https://ff-quizzes.netlify.app/web/quiz/3)
|
|
|
|
## บทนำ
|
|
|
|
ในบทเรียนนี้ เราจะพูดถึง:
|
|
|
|
- การติดตามงานที่คุณทำบนเครื่องของคุณ
|
|
- การทำงานร่วมกับผู้อื่นในโปรเจกต์
|
|
- วิธีการมีส่วนร่วมในซอฟต์แวร์โอเพนซอร์ส
|
|
|
|
### สิ่งที่ต้องเตรียมก่อนเริ่ม
|
|
|
|
ก่อนเริ่มต้น คุณต้องตรวจสอบว่า Git ได้ติดตั้งไว้แล้วหรือยัง ในเทอร์มินัลให้พิมพ์:
|
|
`git --version`
|
|
|
|
หากยังไม่ได้ติดตั้ง Git [ดาวน์โหลด Git](https://git-scm.com/downloads) จากนั้นตั้งค่าโปรไฟล์ Git บนเครื่องของคุณในเทอร์มินัล:
|
|
* `git config --global user.name "your-name"`
|
|
* `git config --global user.email "your-email"`
|
|
|
|
เพื่อเช็คว่า Git ได้รับการตั้งค่าแล้วหรือยัง คุณสามารถพิมพ์:
|
|
`git config --list`
|
|
|
|
คุณยังต้องมีบัญชี GitHub, โปรแกรมแก้ไขโค้ด (เช่น Visual Studio Code) และเปิดเทอร์มินัล (หรือ: command prompt)
|
|
|
|
ไปที่ [github.com](https://github.com/) และสร้างบัญชีหากคุณยังไม่มี หรือเข้าสู่ระบบและกรอกโปรไฟล์ของคุณ
|
|
|
|
✅ GitHub ไม่ใช่ที่เก็บโค้ดเพียงแห่งเดียวในโลก ยังมีที่อื่นอีก แต่ GitHub เป็นที่รู้จักมากที่สุด
|
|
|
|
### การเตรียมตัว
|
|
|
|
คุณจะต้องมีทั้งโฟลเดอร์ที่มีโปรเจกต์โค้ดบนเครื่องของคุณ (แล็ปท็อปหรือพีซี) และที่เก็บสาธารณะบน GitHub ซึ่งจะใช้เป็นตัวอย่างสำหรับการมีส่วนร่วมในโปรเจกต์ของผู้อื่น
|
|
|
|
---
|
|
|
|
## การจัดการโค้ด
|
|
|
|
สมมติว่าคุณมีโฟลเดอร์ในเครื่องที่มีโปรเจกต์โค้ด และคุณต้องการเริ่มติดตามความคืบหน้าของคุณโดยใช้ git - ระบบควบคุมเวอร์ชัน บางคนเปรียบการใช้ git เหมือนการเขียนจดหมายรักถึงตัวคุณในอนาคต การอ่านข้อความ commit ของคุณในอีกไม่กี่วัน สัปดาห์ หรือเดือนข้างหน้า คุณจะสามารถระลึกได้ว่าทำไมคุณถึงตัดสินใจเช่นนั้น หรือ "ย้อนกลับ" การเปลี่ยนแปลงได้ หากคุณเขียนข้อความ commit ที่ดี
|
|
|
|
### งาน: สร้างที่เก็บและ commit โค้ด
|
|
|
|
> ดูวิดีโอ
|
|
>
|
|
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
|
|
|
|
1. **สร้างที่เก็บบน GitHub** บน GitHub.com ในแท็บที่เก็บ หรือจากแถบนำทางด้านบนขวา ให้ค้นหาปุ่ม **new repo**
|
|
|
|
1. ตั้งชื่อให้กับที่เก็บของคุณ (โฟลเดอร์)
|
|
1. เลือก **create repository**
|
|
|
|
1. **ไปยังโฟลเดอร์ที่คุณทำงานอยู่** ในเทอร์มินัลของคุณ ให้เปลี่ยนไปยังโฟลเดอร์ (หรือที่เรียกว่าไดเรกทอรี) ที่คุณต้องการเริ่มติดตาม พิมพ์:
|
|
|
|
```bash
|
|
cd [name of your folder]
|
|
```
|
|
|
|
1. **เริ่มต้นที่เก็บ git** ในโปรเจกต์ของคุณพิมพ์:
|
|
|
|
```bash
|
|
git init
|
|
```
|
|
|
|
1. **ตรวจสอบสถานะ** เพื่อดูสถานะของที่เก็บของคุณ พิมพ์:
|
|
|
|
```bash
|
|
git status
|
|
```
|
|
|
|
ผลลัพธ์อาจดูเหมือนดังนี้:
|
|
|
|
```output
|
|
Changes not staged for commit:
|
|
(use "git add <file>..." to update what will be committed)
|
|
(use "git checkout -- <file>..." to discard changes in working directory)
|
|
|
|
modified: file.txt
|
|
modified: file2.txt
|
|
```
|
|
|
|
โดยทั่วไป คำสั่ง `git status` จะบอกคุณเกี่ยวกับไฟล์ที่พร้อมจะ _บันทึก_ ลงในที่เก็บ หรือไฟล์ที่มีการเปลี่ยนแปลงที่คุณอาจต้องการบันทึก
|
|
|
|
1. **เพิ่มไฟล์ทั้งหมดสำหรับการติดตาม**
|
|
นี่เรียกอีกอย่างว่าการ staging ไฟล์/การเพิ่มไฟล์ไปยังพื้นที่ staging
|
|
|
|
```bash
|
|
git add .
|
|
```
|
|
|
|
คำสั่ง `git add` พร้อมอาร์กิวเมนต์ `.` หมายถึงการเพิ่มไฟล์และการเปลี่ยนแปลงทั้งหมดสำหรับการติดตาม
|
|
|
|
1. **เพิ่มไฟล์ที่เลือกสำหรับการติดตาม**
|
|
|
|
```bash
|
|
git add [file or folder name]
|
|
```
|
|
|
|
คำสั่งนี้ช่วยให้เราเพิ่มเฉพาะไฟล์ที่เลือกไปยังพื้นที่ staging เมื่อเราไม่ต้องการ commit ไฟล์ทั้งหมดในครั้งเดียว
|
|
|
|
1. **ยกเลิกการ staging ไฟล์ทั้งหมด**
|
|
|
|
```bash
|
|
git reset
|
|
```
|
|
|
|
คำสั่งนี้ช่วยให้เรายกเลิกการ staging ไฟล์ทั้งหมดในครั้งเดียว
|
|
|
|
1. **ยกเลิกการ staging ไฟล์เฉพาะ**
|
|
|
|
```bash
|
|
git reset [file or folder name]
|
|
```
|
|
|
|
คำสั่งนี้ช่วยให้เรายกเลิกการ staging ไฟล์เฉพาะในครั้งเดียวที่เราไม่ต้องการรวมไว้สำหรับ commit ถัดไป
|
|
|
|
1. **บันทึกงานของคุณ** ณ จุดนี้คุณได้เพิ่มไฟล์ไปยังพื้นที่ staging ซึ่งเป็นที่ที่ Git กำลังติดตามไฟล์ของคุณ เพื่อทำให้การเปลี่ยนแปลงถาวร คุณต้อง _commit_ ไฟล์เหล่านั้น โดยการสร้าง _commit_ ด้วยคำสั่ง `git commit` _commit_ แสดงถึงจุดบันทึกในประวัติของที่เก็บของคุณ พิมพ์คำสั่งต่อไปนี้เพื่อสร้าง _commit_:
|
|
|
|
```bash
|
|
git commit -m "first commit"
|
|
```
|
|
|
|
คำสั่งนี้จะ commit ไฟล์ทั้งหมดของคุณ พร้อมเพิ่มข้อความ "first commit" สำหรับข้อความ commit ในอนาคต คุณควรเขียนคำอธิบายที่ชัดเจนเพื่อสื่อถึงประเภทของการเปลี่ยนแปลงที่คุณทำ
|
|
|
|
1. **เชื่อมต่อที่เก็บ Git ในเครื่องของคุณกับ GitHub** ที่เก็บ Git บนเครื่องของคุณนั้นดี แต่ในบางจุดคุณอาจต้องการสำรองไฟล์ของคุณไว้ที่อื่น และยังเชิญผู้อื่นมาทำงานร่วมกับคุณในที่เก็บของคุณ สถานที่ที่ดีสำหรับการทำเช่นนั้นคือ GitHub จำไว้ว่าคุณได้สร้างที่เก็บบน GitHub แล้ว ดังนั้นสิ่งเดียวที่คุณต้องทำคือเชื่อมต่อที่เก็บ Git ในเครื่องของคุณกับ GitHub คำสั่ง `git remote add` จะทำสิ่งนี้ พิมพ์คำสั่งต่อไปนี้:
|
|
|
|
> หมายเหตุ ก่อนพิมพ์คำสั่ง ให้ไปที่หน้าที่เก็บ GitHub ของคุณเพื่อค้นหา URL ของที่เก็บ คุณจะใช้มันในคำสั่งด้านล่าง แทนที่ ```https://github.com/username/repository_name.git``` ด้วย URL GitHub ของคุณ
|
|
|
|
```bash
|
|
git remote add origin https://github.com/username/repository_name.git
|
|
```
|
|
|
|
คำสั่งนี้สร้าง _remote_ หรือการเชื่อมต่อ ชื่อ "origin" ที่ชี้ไปยังที่เก็บ GitHub ที่คุณสร้างไว้ก่อนหน้านี้
|
|
|
|
1. **ส่งไฟล์ในเครื่องไปยัง GitHub** จนถึงตอนนี้คุณได้สร้าง _connection_ ระหว่างที่เก็บในเครื่องและที่เก็บ GitHub แล้ว มาส่งไฟล์เหล่านี้ไปยัง GitHub ด้วยคำสั่ง `git push` ดังนี้:
|
|
|
|
> หมายเหตุ ชื่อ branch ของคุณอาจแตกต่างจาก ```main``` โดยค่าเริ่มต้น
|
|
|
|
```bash
|
|
git push -u origin main
|
|
```
|
|
|
|
คำสั่งนี้จะส่ง commit ของคุณใน branch "main" ไปยัง GitHub
|
|
|
|
2. **เพิ่มการเปลี่ยนแปลงเพิ่มเติม** หากคุณต้องการทำการเปลี่ยนแปลงเพิ่มเติมและส่งไปยัง GitHub คุณเพียงแค่ใช้สามคำสั่งต่อไปนี้:
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "type your commit message here"
|
|
git push
|
|
```
|
|
|
|
> เคล็ดลับ คุณอาจต้องการใช้ไฟล์ `.gitignore` เพื่อป้องกันไม่ให้ไฟล์ที่คุณไม่ต้องการติดตามปรากฏบน GitHub เช่น ไฟล์บันทึกที่คุณเก็บไว้ในโฟลเดอร์เดียวกันแต่ไม่มีที่ในที่เก็บสาธารณะ คุณสามารถค้นหาเทมเพลตสำหรับไฟล์ `.gitignore` ได้ที่ [.gitignore templates](https://github.com/github/gitignore)
|
|
|
|
#### ข้อความ Commit
|
|
|
|
หัวข้อของข้อความ commit ที่ดีควรตอบคำถามนี้:
|
|
หากนำไปใช้ ข้อความ commit นี้จะ <หัวข้อของคุณที่นี่>
|
|
|
|
สำหรับหัวข้อ ให้ใช้คำกริยาในรูปแบบคำสั่งและปัจจุบัน: "change" ไม่ใช่ "changed" หรือ "changes"
|
|
เช่นเดียวกับหัวข้อ ในเนื้อหา (ถ้ามี) ให้ใช้คำกริยาในรูปแบบคำสั่งและปัจจุบัน เนื้อหาควรรวมถึงเหตุผลของการเปลี่ยนแปลงและเปรียบเทียบกับพฤติกรรมก่อนหน้า คุณกำลังอธิบาย `ทำไม` ไม่ใช่ `อย่างไร`
|
|
|
|
✅ ใช้เวลาสักครู่เพื่อสำรวจ GitHub คุณสามารถหาข้อความ commit ที่ดีมากๆ ได้หรือไม่? หรือข้อความที่สั้นมาก? ข้อมูลใดที่คุณคิดว่าสำคัญและมีประโยชน์ที่สุดในการสื่อสารในข้อความ commit?
|
|
|
|
### งาน: ทำงานร่วมกัน
|
|
|
|
เหตุผลหลักในการนำสิ่งต่างๆ ไปไว้บน GitHub คือการทำให้สามารถทำงานร่วมกับนักพัฒนาคนอื่นๆ ได้
|
|
|
|
## การทำงานในโปรเจกต์ร่วมกับผู้อื่น
|
|
|
|
> ดูวิดีโอ
|
|
>
|
|
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
|
|
|
|
ในที่เก็บของคุณ ไปที่ `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/) หรือไม่
|
|
|
|
ทรัพยากรเหล่านี้จะช่วยให้สมาชิกใหม่ในทีมเริ่มต้นได้ง่ายขึ้น และสิ่งเหล่านี้มักเป็นสิ่งที่ผู้มีส่วนร่วมใหม่มองหาก่อนที่จะดูโค้ดของคุณ เพื่อดูว่าโปรเจกต์ของคุณเหมาะสมกับเวลาของพวกเขาหรือไม่
|
|
|
|
✅ ไฟล์ README แม้ว่าจะใช้เวลาในการเตรียม แต่ก็มักถูกละเลยโดยผู้ดูแลที่ยุ่ง คุณสามารถหาตัวอย่าง README ที่อธิบายได้ดีมากๆ ได้หรือไม่? หมายเหตุ: มี [เครื่องมือช่วยสร้าง README ที่ดี](https://www.makeareadme.com/) ที่คุณอาจอยากลองใช้
|
|
|
|
### งาน: รวมโค้ดบางส่วน
|
|
|
|
เอกสารการมีส่วนร่วมช่วยให้ผู้คนมีส่วนร่วมในโปรเจกต์ได้ง่ายขึ้น มันอธิบายถึงประเภทของการมีส่วนร่วมที่คุณกำลังมองหาและกระบวนการทำงาน ผู้มีส่วนร่วมจะต้องผ่านขั้นตอนต่างๆ เพื่อที่จะมีส่วนร่วมในที่เก็บของคุณบน GitHub:
|
|
|
|
1. **Fork ที่เก็บของคุณ** คุณอาจต้องการให้ผู้คน _fork_ โปรเจกต์ของคุณ Fork หมายถึงการสร้างสำเนาของที่เก็บของคุณบนโปรไฟล์ GitHub ของพวกเขา
|
|
1. **Clone** จากนั้นพวกเขาจะ clone โปรเจกต์ไปยังเครื่องของพวกเขา
|
|
1. **สร้าง branch** คุณจะต้องขอให้พวกเขาสร้าง _branch_ สำหรับงานของพวกเขา
|
|
1. **มุ่งเน้นการเปลี่ยนแปลงในพื้นที่เดียว** ขอให้ผู้มีส่วนร่วมมุ่งเน้นการเปลี่ยนแปลงในสิ่งเดียวในแต่ละครั้ง - วิธีนี้โอกาสที่คุณจะ _merge_ งานของพวกเขาจะสูงขึ้น ลองนึกภาพว่าพวกเขาเขียนการแก้ไขข้อบกพร่อง เพิ่มฟีเจอร์ใหม่ และอัปเดตการทดสอบหลายรายการ - จะเกิดอะไรขึ้นถ้าคุณต้องการหรือสามารถนำไปใช้ได้เพียง 2 ใน 3 หรือ 1 ใน 3 การเปลี่ยนแปลง?
|
|
|
|
✅ ลองจินตนาการถึงสถานการณ์ที่ branch มีความสำคัญอย่างยิ่งต่อการเขียนและส่งโค้ดที่ดี คุณสามารถนึกถึงกรณีการใช้งานใดบ้าง?
|
|
|
|
> หมายเหตุ เป็นการดีที่จะเป็นตัวอย่างที่ดีและสร้าง branch สำหรับงานของคุณเองด้วย การ commit ใดๆ ที่คุณทำจะถูกทำใน branch ที่คุณกำลัง "checked out" อยู่ ใช้ `git status` เพื่อดูว่า branch นั้นคืออะไร
|
|
|
|
มาดูขั้นตอนการทำงานของผู้มีส่วนร่วมกัน สมมติว่าผู้มีส่วนร่วมได้ _fork_ และ _clone_ ที่เก็บแล้ว ดังนั้นพวกเขาจึงมีที่เก็บ Git พร้อมที่จะทำงานบนเครื่องของพวกเขา:
|
|
|
|
1. **สร้าง branch** ใช้คำสั่ง `git branch` เพื่อสร้าง branch ที่จะมีการเปลี่ยนแปลงที่พวกเขาตั้งใจจะมีส่วนร่วม:
|
|
|
|
```bash
|
|
git branch [branch-name]
|
|
```
|
|
|
|
1. **สลับไปยัง branch ที่ทำงานอยู่** สลับไปยัง branch ที่ระบุและอัปเดตไดเรกทอรีการทำงานด้วย `git switch`:
|
|
|
|
```bash
|
|
git switch [branch-name]
|
|
```
|
|
|
|
1. **ทำงาน** ณ จุดนี้คุณต้องการเพิ่มการเปลี่ยนแปลงของคุณ อย่าลืมบอก Git เกี่ยวกับมันด้วยคำสั่งต่อไปนี้:
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "my changes"
|
|
```
|
|
|
|
อย่าลืมตั้งชื่อ commit ของคุณให้ดี เพื่อประโยชน์ของคุณเองและผู้ดูแลที่เก็บที่คุณกำลังช่วยเหลือ
|
|
|
|
1. **รวมงานของคุณกับ branch `main`** ในบางจุดคุณทำงานเสร็จแล้วและต้องการรวมงานของคุณกับ branch `main` branch `main` อาจมีการเปลี่ยนแปลงในระหว่างนี้ ดังนั้นให้แน่ใจว่าคุณอัปเดตมันให้เป็นเวอร์ชันล่าสุดด้วยคำสั่งต่อไปนี้:
|
|
|
|
```bash
|
|
git switch main
|
|
git pull
|
|
```
|
|
|
|
ณ จุดนี้คุณต้องการให้แน่ใจว่าความ _ขัดแย้ง_ ใดๆ สถานการณ์ที่ Git ไม่สามารถ _รวม_ การเปลี่ยนแปลงได้ง่ายๆ เกิดขึ้นใน branch การทำงานของคุณ ดังนั้นให้รันคำสั่งต่อไปนี้:
|
|
|
|
```bash
|
|
git switch [branch_name]
|
|
git merge main
|
|
```
|
|
|
|
คำสั่งนี้จะนำการเปลี่ยนแปลงทั้งหมดจาก `main` เข้าสู่ branch ของคุณ และหวังว่าคุณจะสามารถดำเนินการต่อได้ หากไม่เป็นเช่นนั้น VS Code จะแจ้งให้คุณทราบว่าที่ใดที่ Git _สับสน_ และคุณเพียงแค่แก้ไขไฟล์ที่ได้รับผลกระทบเพื่อระบุว่าข้อมูลใดถูกต้องที่สุด
|
|
|
|
1. **ส่งงานของคุณไปยัง GitHub** การส่งงานของคุณไปยัง GitHub หมายถึงสองสิ่ง การ push branch ของคุณไปยังที่เก็บของคุณและจากนั้นเปิด PR (Pull Request)
|
|
|
|
```bash
|
|
git push --set-upstream origin [branch-name]
|
|
```
|
|
|
|
คำสั่งด้านบนจะสร้าง branch บนที่เก็บ fork ของคุณ
|
|
|
|
1. **เปิด PR** ต่อไป คุณต้องการเปิด PR คุณทำได้โดยไปที่ที่เก็บ fork บน GitHub คุณจะเห็นการแจ้งเตือนบน GitHub ที่ถามว่าคุณต้องการสร้าง PR ใหม่หรือไม่ ให้คลิกที่นั่นและคุณจะถูกนำไปยังอินเทอร์เฟซที่คุณสามารถเปลี่ยนชื่อหัวข้อ commit และให้คำอธิบายที่เหมาะสมยิ่งขึ้น ตอนนี้ผู้ดูแลที่เก็บที่คุณ fork จะเห็น PR นี้และ _หวังว่า_ พวกเขาจะชื่นชมและ _merge_ PR ของคุณ คุณเป็นผู้มีส่วนร่วมแล้ว เย้ :)
|
|
|
|
1. **ล้างข้อมูล** ถือเป็นแนวปฏิบัติที่ดีในการ _ล้างข้อมูล_ หลังจากที่คุณ merge PR สำเร็จแล้ว คุณต้องการลบทั้ง branch ในเครื่องและ branch ที่คุณ push ไปยัง GitHub ก่อนอื่นให้ลบ branch ในเครื่องด้วยคำสั่งต่อไปนี้:
|
|
|
|
```bash
|
|
git branch -d [branch-name]
|
|
```
|
|
ไปที่หน้า GitHub ของ repo ที่คุณ fork แล้วลบ remote branch ที่คุณเพิ่ง push ไป
|
|
|
|
`Pull request` ดูเหมือนจะเป็นคำที่แปลก เพราะจริงๆ แล้วคุณต้องการ push การเปลี่ยนแปลงของคุณไปยังโปรเจกต์ แต่ผู้ดูแล (เจ้าของโปรเจกต์) หรือทีมหลักต้องพิจารณาการเปลี่ยนแปลงของคุณก่อนที่จะรวมเข้ากับ branch "main" ของโปรเจกต์ ดังนั้นจริงๆ แล้วคุณกำลังขอให้ผู้ดูแลตัดสินใจเกี่ยวกับการเปลี่ยนแปลงนั้น
|
|
|
|
Pull request เป็นพื้นที่สำหรับเปรียบเทียบและพูดคุยเกี่ยวกับความแตกต่างที่เกิดขึ้นใน branch พร้อมกับการรีวิว, คอมเมนต์, การทดสอบที่รวมเข้ามา และอื่นๆ Pull request ที่ดีควรปฏิบัติตามกฎเดียวกันกับข้อความ commit คุณสามารถเพิ่มการอ้างอิงไปยัง issue ใน issue tracker ได้ เช่น เมื่อการทำงานของคุณแก้ไขปัญหาใดปัญหาหนึ่ง วิธีการทำคือใช้ `#` ตามด้วยหมายเลขของ issue ตัวอย่างเช่น `#97`
|
|
|
|
🤞ขอให้ทุกการตรวจสอบผ่านและเจ้าของโปรเจกต์รวมการเปลี่ยนแปลงของคุณเข้ากับโปรเจกต์🤞
|
|
|
|
อัปเดต branch ที่คุณกำลังทำงานอยู่ในเครื่องให้มี commit ใหม่ทั้งหมดจาก branch remote ที่เกี่ยวข้องบน GitHub:
|
|
|
|
`git pull`
|
|
|
|
## วิธีการมีส่วนร่วมในโอเพ่นซอร์ส
|
|
|
|
ก่อนอื่น มาหา repository (หรือ **repo**) บน GitHub ที่คุณสนใจและต้องการมีส่วนร่วมในการเปลี่ยนแปลง คุณจะต้องคัดลอกเนื้อหาของ repo นั้นมายังเครื่องของคุณ
|
|
|
|
✅ วิธีที่ดีในการหา repo ที่เหมาะสำหรับผู้เริ่มต้นคือ [ค้นหาด้วยแท็ก 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)
|
|
|
|
|
|
|
|
มีหลายวิธีในการคัดลอกโค้ด วิธีหนึ่งคือ "clone" เนื้อหาของ repository โดยใช้ HTTPS, SSH หรือ GitHub CLI (Command Line Interface)
|
|
|
|
เปิด terminal ของคุณและ clone repository ด้วยคำสั่ง:
|
|
`git clone https://github.com/ProjectURL`
|
|
|
|
เพื่อทำงานในโปรเจกต์ ให้เปลี่ยนไปยังโฟลเดอร์ที่ถูกต้อง:
|
|
`cd ProjectURL`
|
|
|
|
คุณยังสามารถเปิดโปรเจกต์ทั้งหมดโดยใช้ [Codespaces](https://github.com/features/codespaces) ซึ่งเป็นตัวแก้ไขโค้ดแบบฝังตัว / สภาพแวดล้อมการพัฒนาบนคลาวด์ของ GitHub หรือ [GitHub Desktop](https://desktop.github.com/)
|
|
|
|
สุดท้าย คุณสามารถดาวน์โหลดโค้ดในรูปแบบโฟลเดอร์ที่ถูกบีบอัด
|
|
|
|
### สิ่งที่น่าสนใจเพิ่มเติมเกี่ยวกับ GitHub
|
|
|
|
คุณสามารถ star, watch และ/หรือ "fork" repository สาธารณะใดๆ บน GitHub คุณสามารถค้นหา repository ที่คุณ star ไว้ในเมนูดรอปดาวน์ด้านขวาบน มันเหมือนกับการบุ๊กมาร์ก แต่สำหรับโค้ด
|
|
|
|
โปรเจกต์มี issue tracker ซึ่งส่วนใหญ่จะอยู่บน GitHub ในแท็บ "Issues" เว้นแต่จะระบุไว้เป็นอย่างอื่น ซึ่งเป็นที่ที่ผู้คนพูดคุยเกี่ยวกับปัญหาที่เกี่ยวข้องกับโปรเจกต์ และแท็บ Pull Requests เป็นที่ที่ผู้คนพูดคุยและรีวิวการเปลี่ยนแปลงที่กำลังดำเนินการอยู่
|
|
|
|
โปรเจกต์อาจมีการพูดคุยในฟอรัม, รายการอีเมล หรือช่องแชท เช่น Slack, Discord หรือ IRC
|
|
|
|
✅ ลองสำรวจ repo ใหม่ของคุณบน GitHub และลองทำสิ่งต่างๆ เช่น แก้ไขการตั้งค่า เพิ่มข้อมูลใน repo ของคุณ และสร้างโปรเจกต์ (เช่น Kanban board) มีหลายสิ่งที่คุณสามารถทำได้!
|
|
|
|
---
|
|
|
|
## 🚀 ความท้าทาย
|
|
|
|
จับคู่กับเพื่อนเพื่อทำงานร่วมกันในโค้ดของกันและกัน สร้างโปรเจกต์ร่วมกัน, fork โค้ด, สร้าง branch และรวมการเปลี่ยนแปลง
|
|
|
|
## แบบทดสอบหลังการบรรยาย
|
|
[แบบทดสอบหลังการบรรยาย](https://ff-quizzes.netlify.app/web/quiz/4)
|
|
|
|
## ทบทวนและศึกษาด้วยตัวเอง
|
|
|
|
อ่านเพิ่มเติมเกี่ยวกับ [การมีส่วนร่วมในซอฟต์แวร์โอเพ่นซอร์ส](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)
|
|
|
|
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/)
|
|
|
|
ฝึกฝน ฝึกฝน ฝึกฝน GitHub มีเส้นทางการเรียนรู้ที่ยอดเยี่ยมผ่าน [skills.github.com](https://skills.github.com):
|
|
|
|
- [First Week on GitHub](https://skills.github.com/#first-week-on-github)
|
|
|
|
คุณยังจะพบคอร์สที่มีความซับซ้อนมากขึ้น
|
|
|
|
## งานที่ได้รับมอบหมาย
|
|
|
|
ทำให้เสร็จ [คอร์ส First Week on GitHub](https://skills.github.com/#first-week-on-github)
|
|
|
|
---
|
|
|
|
**ข้อจำกัดความรับผิดชอบ**:
|
|
เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษา AI [Co-op Translator](https://github.com/Azure/co-op-translator) แม้ว่าเราจะพยายามให้การแปลมีความถูกต้องมากที่สุด แต่โปรดทราบว่าการแปลโดยอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาดั้งเดิมควรถือเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ ขอแนะนำให้ใช้บริการแปลภาษามืออาชีพ เราไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความผิดที่เกิดจากการใช้การแปลนี้ |