โอเพ่นซอร์ส: มันไม่ได้น่ากลัวขนาดนั้น!

ข้อมูลต่อไปนี้ถูกโพสต์ล่วงหน้าก่อนการเปิดตัว Toptal Scholarships for Female Developers

ในฐานะนักพัฒนา การตามทันกระแสเทคโนโลยีล่าสุดเป็นเรื่องที่น่าตื่นเต้นและท้าทาย ทุกๆ วัน ภาษา เฟรมเวิร์ก และอุปกรณ์ใหม่ๆ จะดึงดูดความสนใจและกระตุ้นให้เกิดการสนทนาในการพบปะ ฟอรัม และแชท อย่างไรก็ตาม ชุมชนนักพัฒนาของเราสร้างขึ้นจากผู้คน ไม่ใช่เครื่องมือ และการสำรวจแง่มุมทางสังคมการเมืองเป็นเรื่องที่น่าสนใจ (เพราะขาดคำพูดที่ดีกว่า "สังคม" มักจะเกี่ยวข้องกับเครือข่ายสังคมออนไลน์ในทุกวันนี้)

เมื่อเร็วๆ นี้ที่ Toptal เรามีการสนทนาที่น่าสนใจเกี่ยวกับจำนวนผู้หญิงที่มีส่วนร่วมในโอเพ่นซอร์สและสิ่งที่อาจขัดขวางไม่ให้พวกเขามีส่วนร่วมมากขึ้น เราจึงได้ตรวจสอบเรื่องนี้แล้ว ฉันได้เป็นส่วนหนึ่งของการสนทนากับ Breanden Beneschott และ Bozhidar Batsov ฉันจึงสงสัยว่า: Bozhidar เป็นหนึ่งในผู้ให้การสนับสนุนโอเพ่นซอร์สอันดับต้นๆ บน GitHub ฉันอยู่ที่ไหน? หากคุณตรวจสอบบัญชี GitHub สาธารณะของฉัน ณ วันนี้ ส่วนใหญ่เป็นโครงการทดสอบขนาดเล็กที่ฉันใช้ในชั้นเรียนสำหรับนักเรียนของฉัน พวกเขาเป็นคนครึ่งๆ กลางๆ และไม่ได้เป็นตัวแทนของทักษะหรือความเชี่ยวชาญของฉันอย่างแน่นอน (คุณจะต้องเชื่อคำพูดของฉันในเรื่องนี้) ถ้ามีคนพิจารณาจ้างฉันโดยพิจารณาจากสิ่งที่พวกเขาสามารถหาได้ในบัญชีนั้น ฉันเดาว่าฉันคงจะลำบากในการหาเลี้ยงชีพ ถึงกระนั้น ฉันเป็นนักพัฒนามืออาชีพมากว่า 20 ปีแล้ว และในงานประจำวันของฉัน ฉันได้ใช้ซอฟต์แวร์โอเพ่นซอร์สมากกว่าที่ฉันจะจำ เมื่อเวลาผ่านไป ฉันได้แฮ็กเคอร์เนล Linux เพื่อปรับให้เข้ากับความต้องการเฉพาะ ปรับแต่งเราเตอร์และ NAS ทุกตัวที่ฉันซื้อ อดทนรอเป็นเวลาหลายเดือนในรายการรอ Raspberry Pi เพื่อรับมือกับมันและรับ domotics ที่ทำเองที่บ้าน ฉันชอบมัน. ถึงกระนั้น การปรับแต่งและการทดสอบเหล่านี้ไม่เคยทำให้ GitHub ของฉันกลายเป็นโอเพ่นซอร์ส นอกจากนี้ นอกจากการแก้ไขข้อผิดพลาดใน Tomcat เวอร์ชันแรกแล้ว ฉันไม่เคยมีส่วนร่วมในโครงการโอเพ่นซอร์ส อยากรู้อยากเห็นไม่ได้หรือไม่

คุณอาจคิดว่ามันเป็นแค่การไม่มีเวลาหรือความสนใจ แต่ฉันรู้ว่ามันไม่ใช่ สำหรับโครงการส่วนตัวของฉัน ฉันอาจเคยคิดว่าไม่มีใครสนใจในสิ่งที่ฉันได้ทำไปแล้วจริงๆ แต่ส่วนใหญ่เป็นเพียงแนวคิดในการเผยแพร่งานของฉันที่นั่น เพื่อให้ทุกคนได้เห็นและสำหรับรุ่นหลัง ทำให้ฉันกลัวมาก และในขณะที่คุณสามารถทำลายโปรเจ็กต์ส่วนตัวจาก GitHub ได้เสมอ ในวันที่คุณพยายามและมีส่วนร่วมในโปรเจ็กต์โอเพ่นซอร์สที่มีอยู่อย่างแพร่หลาย จะไม่มีวันหวนกลับ จะทำอย่างไรถ้ารหัสของฉันไม่ดีพอ จะเกิดอะไรขึ้นหากฉันไม่เข้าใจปัญหาอย่างถูกต้อง จะเกิดอะไรขึ้นหากคำขอดึงของฉันถูกปฏิเสธ เกิดอะไรขึ้นถ้าคนหมุนรอบฉัน?

การโทรศัพท์หาเพื่อนนักพัฒนาซอฟต์แวร์คนอื่นๆ อย่างรวดเร็ว ซึ่งส่วนใหญ่เป็นผู้หญิง ในไม่ช้าก็ทำให้ฉันเชื่อว่าไม่ใช่คนเดียวที่มีปัญหานี้ แต่สำหรับวิศวกรไม่มีปัญหา มีแต่วิธีแก้ปัญหาใช่ไหม

นี่เป็นปัญหาสำคัญที่ต้องแก้ไข เนื่องจากการมีส่วนร่วมในโครงการโอเพ่นซอร์สสามารถสร้างความแตกต่างอย่างมาก:

• ตลอดอาชีพการทำงานของคุณ : ลูกค้าจำนวนมากจะมองที่สังคมของคุณทุกอย่างก่อนตัดสินใจจ้างคุณ บัญชี GitHub และประวัติย่อ LinkedIn ของคุณอยู่ในอันดับต้นๆ ของรายการ พร้อมด้วยโปรไฟล์ Facebook และ Twitter ของคุณ คุณควรใช้มันอย่างชาญฉลาด
• สำหรับทักษะทางเทคนิคของคุณ : การตรวจสอบ codebase ที่เขียนโดยนักพัฒนาคนอื่น ๆ และบ่อยครั้งที่ความรู้ที่ดีมาก ๆ จะสอนคุณได้มาก ความสามารถในการแยกแยะความหมายออกจาก codebase ที่เขียนไม่ดีจะท้าทายและสอนคุณมากเช่นเดียวกัน
• สำหรับทักษะที่อ่อนนุ่มของคุณ ซอฟต์แวร์โอเพ่นซอร์สเป็นกระบวนการทำงานร่วมกัน และโครงการที่น่าสนใจเกือบทั้งหมดสร้างขึ้นโดยทีม การเรียนรู้ที่จะทำงานร่วมกับนักพัฒนาคนอื่นๆ ผ่านเครื่องมือที่ทุกคนใช้ ผสมผสานกับทีม เพื่อสื่อสารอย่างมีประสิทธิภาพ คือสิ่งที่จะทำให้คุณเป็นนักพัฒนาที่ยอดเยี่ยม ไม่ใช่แค่นักพัฒนาที่มีทักษะ
• สำหรับชุมชน : ทุกบิตที่คุณมีส่วนร่วมในโครงการโอเพ่นซอร์สมีค่า ยิ่งคุณมีส่วนร่วมมากเท่าไหร่ ก็ยิ่งดีมากขึ้นเท่านั้น แต่การแก้ไขข้อผิดพลาดเล็กๆ น้อยๆ ในการแปลจะทำให้ผลงานในขั้นสุดท้ายดีขึ้น
• สำหรับเครือข่ายของคุณ : คุณสามารถส่งเรซูเม่ไปยังบริษัทต่างๆ ได้หลายร้อยรายการ แต่ไม่มีอะไรดีไปกว่าการมีเพื่อนร่วมงานที่มีคนรู้จักส่วนตัว การมีส่วนร่วมอย่างแข็งขันในโครงการโอเพ่นซอร์สจะช่วยให้คุณได้พบปะผู้คนและได้รับความเคารพจากพวกเขา และชื่อเสียงของคุณจะเติบโตขึ้น ซึ่งประเมินค่าไม่ได้สำหรับมืออาชีพ

นี่คือการเดินทางส่วนตัวเล็กๆ น้อยๆ ของฉันในการต่อสู้กับความกลัวนี้ การเผยแพร่บทความนี้เป็นส่วนหนึ่งของการเดินทาง ฉันกำลังเขียนด้วยความหวังว่าใครก็ตามที่ถูกบล็อกในการเขียนโพสต์บนบล็อกหรือกลัวที่จะมีส่วนร่วมแม้แต่น้อย จะเห็นว่าสุดท้ายแล้วมันก็ไม่ได้น่ากลัวขนาดนั้น นอกจากนี้ มันยังมีไว้เพื่อช่วยทุกคนที่ต้องการมีส่วนร่วมในโอเพ่นซอร์ส แต่ไม่รู้ว่าจะเริ่มต้นจากตรงไหน ดังนั้นฉันจะเริ่มต้นด้วยพื้นฐาน

ซอฟต์แวร์โอเพ่นซอร์สคืออะไรและจะหาได้จากที่ไหน?

ซอฟต์แวร์โอเพ่นซอร์ส หรือเรียกสั้นๆ ว่า OSS คือซอฟต์แวร์ใดๆ ที่เผยแพร่พร้อมกับซอร์สโค้ด และมีใบอนุญาตที่อนุญาตให้คุณแก้ไขและแจกจ่ายซ้ำได้ สามารถจัดส่งได้ทุกที่: บนเว็บไซต์ ผ่านรายชื่อผู้รับจดหมาย หรือด้วยนกฮูก สถานการณ์สมมติที่พบบ่อยที่สุดและเหตุการณ์ที่เราสนใจคือเมื่อฐานข้อมูลได้รับการดูแลรักษาบนที่เก็บการทำงานร่วมกัน ที่นี่ เรากำลังมุ่งเน้นไปที่ GitHub แต่มีตัวเลือกอื่นๆ เช่น SourceForge และ Bitbucket GitHub เป็นมิตรมาก มีฐานผู้ใช้ขนาดใหญ่ สามารถใช้กับโค้ดประเภทใดก็ได้ และกับสภาพแวดล้อมการพัฒนาใดๆ ที่คุณใช้ ที่สำคัญ ยังใช้กันอย่างแพร่หลายสำหรับโครงการที่ไม่ใช่โอเพ่นซอร์ส เป็นไปได้มากที่โครงการลูกค้ารายต่อไปของคุณจะถูกโฮสต์ที่นั่น ดังนั้นการรู้วิธีทำงานกับมันจึงเป็นทักษะที่มีประโยชน์ในตัวมันเอง

จะเกิดอะไรขึ้นหากฉันไม่ทราบวิธีการโค้ด

หากคุณกำลังอ่านข้อความนี้ เป็นไปได้ว่าคุณต้องการเรียนรู้วิธีการเขียนโค้ด คุณสามารถหาหลักสูตรที่น่าทึ่งได้จากเว็บไซต์ทั้งแบบฟรีและมีค่าใช้จ่าย คุณควรเลือกหนึ่งภาษาที่จะเรียนรู้ หากคุณไม่มีความชอบ ให้ไปที่ JavaScript คุณมีทุกสิ่งที่จำเป็นสำหรับการเริ่มต้นใช้งานเว็บเบราว์เซอร์ของคุณแล้ว และเป็นหนึ่งในทักษะที่ใช้กันอย่างแพร่หลายและเป็นที่ต้องการของตลาดมากที่สุด รายการโปรดส่วนตัวของฉันคือ Python ซึ่งใช้ทั้งในการพัฒนาเว็บและในแอปพลิเคชันทางวิทยาศาสตร์ ฉันยังมีหลักสูตรเริ่มต้นที่ชื่นชอบเป็นการส่วนตัว "Intro to Computer Science" ใน Udacity ฉันชอบเพราะเป็นหลักสูตรภาคปฏิบัติที่คุณทำงานในโครงการตามที่คุณเรียนรู้ นอกจากนี้คุณยังสามารถค้นหาหลักสูตรอื่น ๆ อีกหลายหลักสูตรใน Coursera, Khan Academy และ PluralSight

จะเป็นอย่างไรถ้าฉันไม่รู้จัก Git

ดังที่ได้กล่าวไว้ก่อนหน้านี้ การรู้จัก Git เป็นสิ่งสำคัญ ดังนั้นควรเรียน Git ทำแม้ว่าคุณจะทำงานกับ Git มาระยะหนึ่งแล้ว คุณไม่รู้หรอกว่าคุณไม่รู้เกี่ยวกับ Git มากแค่ไหน จนกว่าคุณจะศึกษามันจริงๆ ทำถ้าคุณไม่สามารถอธิบายได้อย่างมั่นใจว่าคำสั่ง rebase ทำอะไร ทำแม้ว่ารีเบสผิดก็ไม่ทำให้คุณกลัว ฉันใช้เส้นทาง Git แบบเต็มใน Code School แต่อีกครั้ง คุณสามารถสำรวจไซต์อื่นๆ เพื่อดูตัวเลือกเพิ่มเติมได้

ฉันจะเลือกโครงการบน GitHub ได้อย่างไร

เป็นไปได้ที่คุณจะใช้ OSS บางอย่างในการพัฒนาชีวิตประจำวันของคุณ การเลือกเฟรมเวิร์กที่คุ้นเคยเป็นจุดเริ่มต้นที่ดี คุณคุ้นเคยกับคุณสมบัติและวิธีการทำงานของเฟรมเวิร์กอยู่แล้ว เมื่อคุณดำดิ่งลงไปในซอร์สโค้ด คุณจะได้เรียนรู้เพิ่มเติม และคุณจะเข้าใจตรรกะของมันชัดเจนยิ่งขึ้น หากมีเทคโนโลยีหรือเครื่องมือที่คุณชอบเป็นพิเศษ ให้มองหาโปรเจ็กต์ที่กล่าวถึงมัน หรือตัวโปรเจ็กต์ของเครื่องมือเอง เป็นทางเลือกสุดท้าย คุณสามารถตรวจสอบโครงการบน GitHub Showcases และเริ่มต้นด้วยการเลือกหมวดหมู่ที่คุณสนใจ

ตัวอย่างเช่น การค้นหา "Raspberry" อย่างรวดเร็วในการค้นหาของ GitHub จะแสดงที่เก็บมากกว่า 17,000 แห่ง มันง่ายที่จะหลงทาง ดังนั้นให้มองหาโครงการที่มีชุมชนที่ดีและติดตามปัญหาที่ดี เมื่อเลือกโครงการ ให้ตรวจสอบจำนวน:

• Contributors : กำหนดเป้าหมายอะไรก็ได้ที่เกิน 10 Contributors สิ่งนี้ควรตรวจสอบให้แน่ใจว่าโครงการมีความสนใจเพียงพอและไม่ใช่แค่ความพยายามของทีมเพียงเล็กน้อย หากคุณยังใหม่ต่อ OSS หรือไม่มีทักษะมากเกินไป ให้จำกัดการค้นหาของคุณไว้เฉพาะโครงการที่มีผู้มีส่วนร่วมสูงสุดห้าสิบคน ชุมชนที่ใหญ่ขึ้นหมายถึง codebase ที่ใหญ่ขึ้นและโครงการที่ซับซ้อนมากขึ้น
• ความ มุ่งมั่น : ไปหาโครงการที่มีอย่างน้อยหนึ่งพันครั้งและกิจกรรมล่าสุดไม่เกินหนึ่งสัปดาห์ โปรเจ็กต์ที่ไม่มีการใช้งานเป็นเวลาหนึ่งเดือนขึ้นไปเป็นโปรเจ็กต์ที่เก่าและค้างตามเงื่อนไขของ OSS และคุณอาจไม่ได้รับคำตอบอย่างรวดเร็ว กิจกรรมประจำวันเป็นสัญลักษณ์ของโครงการที่ดี
• ปัญหา : ปัญหาคือปัญหาที่เปิดอยู่ ข้อบกพร่องที่มีการรายงานหรือร้องขอคุณลักษณะที่จะนำไปใช้ พวกเขาจะให้จุดเริ่มต้นและเป็นตัวชี้วัดที่ดีของความสนใจในโครงการ

นอกจากนี้ ให้ค้นหาว่าภาษาหลักของโครงการคืออะไร คุณสามารถดูสถิติภาษาในแถบด้านบนของหน้าโครงการหลัก ใช้เวลาในการอ่านโทนของการสนทนา ดูว่าความคิดเห็นที่เป็นมิตรและให้ความรู้ดีเพียงใด บางโครงการอาจมีชื่อเสียงสำหรับชุมชนที่ก้าวร้าว ดังนั้นจึงอาจไม่ใช่จุดเริ่มต้นที่ถูกต้อง

ฉันเลือก ScyllaDB ซึ่งเป็นโปรเจ็กต์การจัดเก็บข้อมูลแบบเสา เนื่องจากฉันมีความหลงใหลในข้อมูล-ทุกอย่างที่เกี่ยวข้องกับประสิทธิภาพ ฉันไม่เคยทำงานกับมัน แต่ฉันคาดหวังว่าจะสามารถดำดิ่งลงไปใน codebase ของมันได้ การทำงานกับเครื่องมือที่ฉันรู้อาจง่ายกว่า แต่ถือว่านี่เป็นความท้าทายและเป็นโอกาสในการเรียนรู้สิ่งใหม่ สำหรับส่วนที่เหลือก็ลงตัวพอดี มีผู้ร่วมให้ข้อมูล 18 คน คอมมิชชัน 6.5k ครั้ง (ล่าสุดคือ 23 ชั่วโมงที่แล้ว ณ เวลาที่เขียน) 178 ปัญหาที่เปิดอยู่และปรากฏว่าใช้งานอยู่

ฉันทำอะไรตอนนี้?

ขั้นแรก โคลนที่เก็บและติดตั้งซอฟต์แวร์บนเครื่องของคุณเพื่อให้ทราบถึงชิ้นส่วนที่เคลื่อนไหวได้ จากนั้นเริ่มอ่านประเด็นต่างๆ เมื่อคุณรู้สึกว่าพร้อมแล้ว ให้ดูว่าคุณสามารถสร้างปัญหาซ้ำในเครื่องของคุณได้หรือไม่ จากนั้นเริ่มวิเคราะห์สิ่งที่ทำให้ซอฟต์แวร์ทำงานผิดปกติ

อีกแนวทางหนึ่งคือการหาสิ่งที่สามารถปรับปรุงหรือปรับเปลี่ยนได้ด้วยตัวเอง คุณอาจสังเกตเห็นการพิมพ์ผิดหรือแบบอักษรไม่ตรงแนว เป็นต้น ฉันเลือกที่จะแก้ไขข้อผิดพลาดเล็กๆ น้อยๆ โดยเฉพาะชื่อตัวแปรที่ไม่ถูกต้องที่ใช้ในเอกสารประกอบของสคริปต์

ดูเหมือนเล็ก แต่เอกสารที่ไม่ถูกต้องนั้นแย่กว่าการไม่มีเอกสารมาก ผู้ใช้จะติดตั้ง ScyllaDB และทำตามขั้นตอนการติดตั้ง พวกเขาจะพึ่งพาสิ่งที่เขียนในสคริปต์นั้นอย่างสุ่มสี่สุ่มห้า และจะจบลงด้วยความหงุดหงิดมากมาย สิ่งนี้สมบูรณ์แบบสำหรับความสามารถของฉัน และการแก้ไขจะทำให้ฉันต้องทำตามขั้นตอนทั้งหมด และทำความคุ้นเคยกับ codebase เล็กน้อย การแก้ไขข้อบกพร่องเป็นเรื่องที่น่าเบื่อ แต่เป็นการเริ่มต้นที่ดีในการหาทางเข้าสู่โครงการ

การสร้างส้อม

นี่อาจเป็นเรื่องเล็กน้อย แต่สำหรับโครงการ ScyllaDB ในตอนนี้ ฉันคือคุณโนบอดี้ การอนุญาตให้ฉันเปลี่ยนแปลงโค้ดโดยไม่ต้องมีการควบคุมดูแลถือเป็นความเสี่ยง สิ่งที่ฉันต้องทำคือสร้าง "ส้อม" ในบัญชี GitHub ของฉันเอง นี่คือส้อม ScyllaDB ของฉัน มันเป็นสนามเด็กเล่นของฉันเองที่ฉันสามารถเข้าถึงรหัสทั้งหมดได้ และฉันสามารถแก้ไขไฟล์ได้ตามต้องการ ถ้าฉันต้องการสร้าง ScyllaDB เวอร์ชันของตัวเองและปรับแต่งให้ทำสิ่งที่แตกต่างไปจากจุดประสงค์ดั้งเดิมโดยสิ้นเชิง ฉันสามารถทำได้ที่นี่ การสร้างส้อมนั้นง่าย ไปที่หน้าหลักของโครงการแล้วคลิกปุ่ม "แยก" ไม่น่ากลัวเลย

ถึงเวลาแก้ไขข้อผิดพลาด

ถึงเวลาทดสอบโค้ดบนคอมพิวเตอร์ของคุณและทำการแก้ไขที่จำเป็น ก่อนอื่น ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งไคลเอนต์ Git บนเครื่องของคุณแล้ว จากนั้น เพิ่มคีย์สาธารณะ SSH ของคุณไปที่ GitHub และตรวจสอบให้แน่ใจว่า ssh-agent โหลดไว้ การรับรหัสในเครื่องนั้นง่าย เพียงใช้คำสั่ง git clone ที่ชี้ไปที่ส้อมของคุณ แทนที่จะเป็นสาขาหลัก:

 git clone [email protected]:acbellini/scylla.git

ถึงตอนนี้ คุณควรทดสอบโปรเจ็กต์บนสาขาหลักแล้ว ดังนั้นคุณจะต้องสร้างโค้ดของคุณในเครื่องและทดสอบด้วยวิธีเดียวกัน โปรดทราบว่าคุณจะต้องแยกโปรเจ็กต์ GitHub อื่นๆ ที่โปรเจ็กต์ของคุณใช้ เนื่องจากการอ้างอิงนั้นสัมพันธ์กัน ในกรณีของฉัน ฉันต้องแยก seastar, scylla-ami และ scylla-swagger-ui

ข้อบกพร่องที่ฉันต้องแก้ไขนั้นค่อนข้างง่าย เอกสารประกอบใน conf/scylla.yaml กล่าวถึงไดเร็กทอรีที่กำหนดค่าได้สามไดเร็กทอรี: หนึ่งรายการสำหรับไฟล์ข้อมูล หนึ่งรายการสำหรับบันทึกการคอมมิต และอีกรายการหนึ่งสำหรับแคช ซึ่งเห็นได้ชัดว่าไม่ได้ใช้ สำหรับไดเรกทอรีย่อยบางรายการของ $CASSANDRA_HOME :

เมื่อพิจารณาจากโค้ด แสดงว่าค่าเริ่มต้นแตกต่างกัน และดังที่กล่าวไว้ในปัญหา #372 ที่ฉันเริ่มต้น ไม่ควรใช้ $CASSANDRA_HOME ฉันตรวจสอบสมมติฐานของฉันโดยทดสอบโค้ดด้วยการตั้งค่าที่แตกต่างกันสองสามอย่าง โดยลบการตั้งค่าออกจากไฟล์ปรับแต่งและตรวจสอบว่าไดเร็กทอรีใดใช้ เมื่อมั่นใจว่าทุกอย่างถูกต้องเพียงพอแล้ว ฉันสามารถเพิ่ม คอมมิต และพุชไฟล์ที่แก้ไขได้:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

โปรดทราบว่าฉันแนะนำหมายเลขปัญหาที่นำหน้าด้วยแฮชในข้อความยืนยัน สิ่งนี้จะบอก GitHub ให้เชื่อมโยงรหัสของฉันกับปัญหาโดยอัตโนมัติ

สิ่งสำคัญอีกประการหนึ่งที่ควรทราบคือ เมื่อฉันสำรวจโค้ด ฉันรู้ว่าไดเร็กทอรีที่สาม ไดเร็กทอรีสำหรับแคช นั้นไม่ได้ถูกใช้งานจริงๆ เป็นการยั่วยวนใจที่จะก้าวไปไกลเกินไปและลบการตั้งค่านี้ออกเอง หรือเพิ่มความคิดเห็นที่ไม่ได้ใช้ แต่นั่นจะอยู่นอกขอบเขตของปัญหา #372 และจะเป็นการผิดหากกระทำสิ่งใดๆ ที่ไม่เกี่ยวข้องกับเรื่องนี้อย่างเคร่งครัด ปัญหา. คุณต้องให้ความสำคัญกับการเปลี่ยนแปลงและจำกัดเฉพาะงานที่ทำอยู่

ณ จุดนี้รหัสได้รับการแก้ไขและอยู่ใน GitHub ในส้อมส่วนตัวของฉัน นี่คือส่วนที่น่ากลัว: การขอให้คน ScyllaDB ยอมรับรหัสของฉัน นี่เรียกว่าคำขอดึง

ขั้นตอนสุดท้าย: คำขอดึง

ฉันชอบสร้างคำขอดึงโดยตรงจากเว็บอินเตอร์เฟสบน GitHub ฉันพบว่าใช้งานง่ายและป้องกันข้อผิดพลาดได้ง่ายกว่าการลองทำจากบรรทัดคำสั่ง ทั้งหมดที่ฉันต้องทำเพื่อสร้างคำขอดึงของฉันคือคลิกปุ่มสีเขียวเล็กๆ ข้างชื่อสาขาของฉัน:

โปรดทราบว่าความคิดเห็นนั้นคำนวณโดยอัตโนมัติโดย GitHub ตอนนี้สาขาของฉันมีการคอมมิตใหม่ 1 รายการ แต่ตั้งแต่สร้างส้อม มีคอมมิชชันมากกว่า 14 รายการในที่เก็บหลัก ดังนั้นฉันจะคลิกไอคอนสีเขียวทางด้านซ้าย

โชคดีที่การคอมมิชชันเดี่ยวของฉันไม่ขัดแย้งกับอีก 14 คน ดังนั้น GitHub จึงแจ้งฉันว่าฉันพร้อมแล้ว ฉันไม่จำเป็นต้องเพิ่มความคิดเห็นหรือข้อความอื่นใด ในขณะที่ข้อความที่คอมมิตนั้นสั้นมาก บอกได้ทั้งหมด: โค้ดของฉันที่เปลี่ยนคืออะไรและมันเกี่ยวข้องกับอะไร เมื่อฉันคลิกปุ่มสุดท้ายเพื่อยืนยันคำขอของฉัน ฉันสงสัยว่ามันคืออะไรที่ฉันพบว่าน่ากลัวเมื่อไม่กี่วันก่อน ตอนนี้ไม่มีสัตว์ประหลาดคำรามใส่ฉันแล้ว และเปลวไฟแห่งนรกก็ดูเหมือนจะไม่แผดเผา บอกตรงๆ ว่าไม่ได้น่ากลัวเลยสักนิด ในกรณีที่ฉันเข้าใจผิด การแก้ไขของฉันจะไม่ได้รับการยอมรับและจะเป็นเช่นนั้น

หากคุณตรวจสอบรายละเอียดปัญหาแล้ว คุณจะพบว่า GitHub ได้เพิ่มหมายเหตุโดยอัตโนมัติว่ามีคำขอดึงที่อ้างอิงถึงปัญหานี้ นี่คือความมหัศจรรย์ของ #372 ในข้อความยืนยัน วิธีนี้จะช่วยหลีกเลี่ยงไม่ให้คนอื่นเสียเวลาแก้ไขสิ่งที่แก้ไขไปแล้ว

บันทึกสุดท้าย

ตอนนี้ฉันกำลังรอให้คำขอดึงของฉันได้รับการยอมรับ ฉันจะได้รับการแจ้งเตือนเมื่อสิ่งนั้นเกิดขึ้น โปรดทราบว่าอาจใช้เวลาสองสามวันหรือหลายสัปดาห์ บางคนต้องตรวจทานโค้ดของฉัน ทดสอบว่ามันใช้งานได้ตามที่อธิบายไว้ แก้ไขปัญหา และท้ายที่สุด ตรวจสอบให้แน่ใจว่าโค้ดนั้นไม่ส่งผลเสียต่อการทำงานของโค้ดที่เหลือ (อ่าน: สร้างบั๊กใหม่) ทั้งหมดนี้ต้องใช้เวลาของใครบางคน ดังนั้นจงอดทน ในท้ายที่สุด เมื่อคำขอดึงของฉันได้รับการยอมรับ ScyllaDB จะมีผู้ร่วมให้ข้อมูลเพิ่มอีกหนึ่งราย ปัญหาน้อยกว่าหนึ่งฉบับ และฉันจะได้รับการสนับสนุน OSS ครั้งแรก ตอนนี้ก็ถึงเวลาที่คุณจะลองเช่นกัน ท้ายที่สุดมันไม่น่ากลัวเลย