ฉันควรคาดหวังให้ทีมของฉันมีความสามารถขั้นพื้นฐานมากกว่าด้วยระบบควบคุมแหล่งที่มาของเราหรือไม่?

บริษัท ของฉันเปลี่ยนจากการโค่นล้มเป็น Git เมื่อประมาณสามเดือนที่แล้ว เรามีการแจ้งล่วงหน้าหลายสัปดาห์ก่อนการเปลี่ยน เนื่องจากฉันไม่เคยใช้ Git มาก่อน (หรือ DVCS อื่น ๆ ) ฉันอ่านPro Gitและใช้เวลาเล็กน้อยหมุนที่เก็บของตัวเองและเล่นรอบ ๆ ดังนั้นเมื่อเราเปลี่ยนฉันจะสามารถทำงานด้วยความเจ็บปวดน้อยที่สุด ตอนนี้ฉันเป็น 'Git guy' โดยค่าเริ่มต้น

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

กำหนดลักษณะพื้นฐานของการควบคุมแหล่งที่มาในการทำงานประจำวันของเรา (ไม่พูดถึงจำนวนเงินที่ไร้สาระของการใช้พลังงาน Git กำบังเรา) ผมมีความเห็นว่า dev ใด ๆ ที่ไม่ประสบความสำเร็จในระดับหนึ่งของความสามารถกับมันเป็นความรับผิด

ฉันควรคาดหวังให้ทีมของฉันมีความเข้าใจอย่างน้อยเกี่ยวกับวิธีการทำงานของ Git ภายในและวิธีการใช้งานนอกเหนือจากการดำเนินการดึง / ผสาน / การกดพื้นฐานที่สุด? หรือฉันแค่ทำอะไรที่ไร้ค่า?

ความเป็นมืออาชีพย่อมบอกให้ผู้พัฒนาคุ้นเคยกับเครื่องมือมาตรฐานของทีมแม้ว่าพวกเขาจะเป็นคนใหม่และไม่คุ้นเคย (หรือไม่ต้องการก็ตาม)

อย่างไรก็ตามมีบางสิ่งในโพสต์ของคุณที่ให้ฉันหยุดชั่วคราว

เรามีการแจ้งล่วงหน้าหลายสัปดาห์ก่อนการเปลี่ยน

สัปดาห์ที่ผ่านมา? การสลับการควบคุมแหล่งที่มาเป็นเรื่องใหญ่ ควรมีการแจ้งให้ทราบล่วงหน้าหลายเดือนเพื่อนำไปสู่การเปลี่ยนแปลงเช่นนั้น

ด้วยข้อยกเว้นบางประการทีมของฉันส่วนใหญ่ยังไม่รู้ว่า Git ทำงานอย่างไร

ดังนั้น บริษัท ของคุณเปลี่ยนไปใช้ระบบควบคุมแหล่งที่น้อยถ้าใครเข้าใจในเวลา?

เว้นแต่จะมีบริบทอื่น ๆ ดูเหมือนว่าการเคลื่อนไหวทั้งหมดนั้นไม่ได้รับการพิจารณา (การย้ายไม่ใช่ทางเลือก - ฉันเป็นแฟนตัวยง)

เราได้แนะนำ Git ที่ฉันทำงานและมีการต่อต้านตามธรรมชาติ มันเป็นโครงการใหม่ดังนั้นตอนนี้เราจึงมีที่เก็บสองแห่ง

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

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

ฯลฯ แต่ละปัญหาเหล่านี้แก้ไขปัญหาที่เราได้พบกับ SCM ก่อนหน้าของเราและเพื่อให้ผู้คนได้ชื่นชม Git มากขึ้น

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

ดังนั้นในฐานะ 'ผู้เชี่ยวชาญ Git' คุณต้องนั่งลงและทำให้มันง่ายที่สุดสำหรับผู้ใช้ พวกเขาต้องการที่จะเขียนโค้ดไม่ยุ่งกับระบบ SCM ของพวกเขา

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

• Git กับ SSH บน Windows เป็นปัญหาทั่วไป
• ผู้คนจะดึงผสาน แต่ไม่รวมการผสาน ดังนั้นกราฟจะเป็นระเบียบที่ทำให้เกิดความสับสนอย่างมาก
• ปัญหาประสิทธิภาพการทำงานบน Windows ทำให้ "สถานะ git" ใช้เวลา 15 วินาที
• ไม่สามารถหาวิธีดึงสาขาใหม่ได้ พวกเขาจะทำ "git checkout -b" ซึ่งจะแยกออกจากสิ่งที่พวกเขากำลังทำงานอยู่
• EGit ใน eclipse มีเมนูมากมาย จบลงด้วยการบอกให้ทุกคนใช้บรรทัดคำสั่งในตอนแรก
• อ้างอิงจากรายการก่อนหน้าการรวมและตั้งค่า git mergetool
• สับสนเกี่ยวกับความแตกต่างระหว่าง "git add" และ "git commit" และ "git push"

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

เชี่ยวชาญกับ Git-mania

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

ทำไมมันถึงสำคัญ (มาก)

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

ความเชี่ยวชาญขั้นพื้นฐานมีลักษณะอย่างไร

เกณฑ์ที่เป็นรูปธรรม ได้แก่ :

• ไม่มีเอกสารอ้างอิง:

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

• ด้วยเอกสาร:

  • เพิ่มผู้ใช้และข้อมูลประจำตัวสำหรับ repo ท้องถิ่น
  • เริ่มต้น repo ท้องถิ่น
  • จัดการ repo ระยะไกล
  • กำหนดค่าไฟล์ที่ถูกละเว้นสร้างคู่คีย์สาธารณะ / ส่วนตัว PKI
  • ย้ายและลบไฟล์
  • ใช้ bisect เพื่อค้นหาการเปลี่ยนแปลงที่นำข้อผิดพลาดเฉพาะ

รูปแบบจิตที่มั่นคงของคอมไพล์และการจัดการรหัสเป็นสิ่งสำคัญเพื่อหลีกเลี่ยงข้อผิดพลาด

สิ่งที่คุณจะเพิ่มสำหรับความเชี่ยวชาญ / ความเชี่ยวชาญขั้นสูง?

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

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

GIT เป็นเครื่องมือที่ใช้ในการทำงานและหนึ่งในปัญหาที่ใหญ่ที่สุดคือผู้ประกาศข่าวประเสริฐ GIT หลายคนคาดหวังให้ผู้ใช้ GIT ทุกคนกลายเป็นผู้เชี่ยวชาญด้านฝากระโปรงเพื่อทำความเข้าใจกับจุดที่ดีที่สุดของวิธีการทำงาน นี่คือจุดอ่อนที่ใหญ่ที่สุดของ GIT - ในการใช้งานคุณจำเป็นต้องรู้ว่ามันทำงานอย่างไร ไม่มีสูตรกับ GIT คุณคาดว่าจะเป็นผู้เชี่ยวชาญ GIT หรือไม่ใช้ เป็นเรื่องดีที่คุณอ่าน Pro-GIT องค์กรของคุณต้องการกูรู GIT (หรือสอง) เพื่อเพิ่มการลงทุนให้สูงสุดเพราะไม่ใช่นักพัฒนาทุกคนที่ต้องการเป็น GIT Guru - และนั่นก็โอเค

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

ฉันไม่ให้ลิงทำงาน GIT ตราบใดที่ฉันรู้วิธีที่จะทำให้ git ทำงานให้ฉันได้

ใช่.

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

Git เป็นช่วงการเปลี่ยนภาพที่ยากลำบากสำหรับหลาย ๆ คนดังนั้นการฝึกซ้อมซิทดาวน์อาจเป็นไปได้ สิ่งนี้จะช่วยตอกย้ำประเด็นที่ผู้คนมีอยู่มากมาย

ฉันใช้ Git ในสภาพแวดล้อมที่เป็นส่วนตัวไม่ใช่มืออาชีพและในขณะที่ฉันชอบพลังที่มีอยู่และความคิดในการควบคุมแหล่งที่มาที่กระจายอำนาจมากขึ้นก็มีปัญหาใหญ่ Git มีสิ่งที่เป็นนามธรรมรั่วไหลและต้องใช้หลายคำสั่งในการทำสิ่งง่าย ๆ (ตัวอย่างเช่นทำการเปลี่ยนแปลง: git add, git commit, จากนั้น git push) นอกจากนี้เอกสารบางส่วนยังขาดและ / หรือสับสนเช่นเดียวกับคำอธิบายคำสั่ง rebase ... "Local-port ท้องถิ่นมุ่งมั่นที่จะอัปเดตหัวอัปสตรีม" ฉันไม่รู้ว่าหมายถึงอะไรและแม้ว่าตอนนี้ฉันรู้ว่าคุณสามารถย้ายคอมมิชชันไปรอบ ๆ และเขียนประวัติใหม่ได้ (รำคาญอีกครั้ง ... ทำไมคุณควรได้รับอนุญาตให้ทำเช่นนี้ ???) ฉันจะไม่เดาได้เลยว่าจากคำสั่งนั้น ลักษณะ ฉันคิดว่าการอ่านบางอย่างในส่วนของทีมของคุณและการฝึกอบรมเพิ่มเติมจากคุณนั้นเป็นไปตามลำดับ

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

ไม่มี ฉันคิดว่ามันสมเหตุสมผลที่จะคาดหวังสิ่งต่อไปนี้:

1. ทำงานประจำวัน (กระทำ, ผลัก, ดึง, แยก, รวม, แบ่งครึ่ง ฯลฯ ) โดยไม่ต้องใช้มือจับ
2. ทำงานที่ไม่ใช่งานประจำโดยไม่ต้องมีคำสั่งซ้ำ ๆ (การทำซ้ำสองสามครั้งก็โอเค - ฉันต้องพบกับใครสักคน 2-3 ครั้งก่อนที่ชื่อของพวกเขาจะยึดมั่นจริงๆ)

หากพวกเขาทำไม่ได้ # 1 แสดงว่าส่วนของการฝึกอบรมของคุณอาจไม่เพียงพอ หากพวกเขาทำไม่ได้ # 2 อันดับแรกให้แน่ใจว่าคุณอธิบายสิ่งต่าง ๆ ให้ชัดเจนก่อนที่จะอารมณ์เสีย