บริบท

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

คำถาม

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

ฉันสามารถทำอะไรได้บ้างเพื่อช่วยให้พนักงานเหล่านี้เรียนรู้ Git?

Sourcetreeเป็นลูกค้าที่ใช้งานโดยทีมงานทั้งหมด

ให้ของเล่นกับพวกเขา

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

ฉันต้องการสถานที่ที่ปลอดภัยในการเล่น

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

หากคุณเพียงแค่โยนพวกเขาลงไปในส่วนลึกคุณจะโชคดีถ้าพวกเขาสามารถลอยได้

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

คำสั่งหลักที่ทีมของคุณต้องการคือ:

• ดึงและผสานการเปลี่ยนแปลงจากระยะไกลและจัดการกับความขัดแย้งที่เกิดขึ้น (อาจรีบูต)
• กระทำและผลักดันการกระทำที่ห่างไกล (หรือกดไปที่การแสดงละคร repo / สาขาเพื่อรับการเปลี่ยนแปลงที่ดึงเข้ามาหลักหลังจากตรวจสอบ)
• สำหรับการสนับสนุน: แก้ไขปัญหาหลังจากทำสิ่งผิดปกติ

คนที่ผู้ใช้ขั้นสูงจะต้องมี

• จัดการกระทำในท้องถิ่น
• จัดการสาขา

สำหรับคนที่ไม่คุ้นเคยกับคอมไพล์และผู้ที่ไม่ต้องการที่จะเรียนรู้การตั้งค่าคำสั่งนามแฝงที่รวดเร็วในการทำและตรวจสอบให้แน่ใจว่าทุกอย่างถูกต้อง (เพิ่มไฟล์ใหม่ลบไฟล์ที่ถูกลบออกจาก repo ฯลฯ )

ตรวจสอบให้แน่ใจว่าเอกสารเหล่านี้เป็นเอกสารที่ดีและมีหลักฐานโง่ ๆ ที่เหมาะสม

นี่คือเส้นเลือดของการ์ตูน xkcdเพียงแค่จดจำคำสั่งและหวังว่าสิ่งต่าง ๆ จะไม่เลอะเทอะมากนักเมื่อพวกเขาถามมืออาชีพ

ให้พวกเขาใช้ Git UI

หากพวกเขามีประสบการณ์กับ TortoiseSVN, TortoiseGit (Windows เท่านั้น)จะทำงานเหมือนกันเกือบทั้งหมด ไม่อย่างนั้นSourceTree (Windows + Mac)นั้นยอดเยี่ยม - เรามีนักพัฒนาระบบคุณภาพหลายคนที่สามารถควบคุมงานที่ซับซ้อนใน Git ได้อย่างง่ายดายด้วย SourceTree

คำตอบนี้พยายามพูดถึงวิธีทำให้โปรแกรมเมอร์อาวุโสให้ความสนใจgitไม่ใช่เกี่ยวกับวิธีการเรียนรู้gitวิธีที่เร็วที่สุด - สำหรับหนังสือ git ที่ยอดเยี่ยมนั้นยอดเยี่ยมหรือบทเรียนจำนวนมาก (=> Google) ลิงก์ที่ดีที่จะไปพร้อมกับคำตอบนี้คือGit เป็นโครงสร้างข้อมูลที่ทำงานได้อย่างหมดจดหรือโดยเฉพาะอย่างยิ่งในระยะสั้นGit เก็บข้อมูลของคุณอย่างไร

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

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

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

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

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

GUI

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

โครงสร้างข้อมูล (คงที่) เป็นกุญแจสำคัญ

เริ่มต้นด้วยการอธิบายประเภทข้อมูลภายใน (มีเพียงสามบวกหนึ่งของพวกเขา: blobs, ต้นไม้, commits, แท็กคำอธิบายประกอบสุดท้ายซึ่งไม่เกี่ยวข้องใด ๆ ในขั้นตอนนี้) และโครงสร้างของพวกเขา คุณสามารถทำได้อย่างง่ายดายบนไวท์บอร์ด / ด้วยดินสอ ต้นไม้นั้นง่ายต่อการวาดเนื่องจากไม่สามารถเปลี่ยนแปลงได้คุณสามารถเพิ่มสิ่งต่าง ๆ ได้ตลอดเวลา คุณสามารถเล่นเซสชั่นในพื้นที่เก็บข้อมูลท้องถิ่นที่สร้างขึ้นใหม่และใช้git cat-fileในการมองเข้าไปในวัตถุที่เกิดขึ้นจริงเพื่อแสดงให้พวกเขาเห็นว่าพวกเขาในความเป็นจริงเป็นเรื่องเล็กน้อยตามที่โฆษณา

หากคุณสามารถช่วยให้พวกเขาเข้าใจว่า

• ... มีเพียงวัตถุ 3 ประเภทในประวัติศาสตร์วัตถุทั้งหมดนั้นเรียบง่ายแทบจะไม่สำคัญและ
• ... คำgitสั่งย่อยส่วนใหญ่เพียงแค่ "นวด" วัตถุเหล่านั้นในทางเดียวด้วยการดำเนินการที่ไม่สำคัญ (โดยทั่วไปมีเพียงอันเดียว: เพิ่มคอมมิชชันใหม่ที่ใดที่หนึ่ง) และ ...
• ... ทุกสิ่งสามารถมองเห็นได้ทันทีต่อหน้าคุณด้วยlsและgit cat-file...

แล้วพวกเขาก็จะมีการแปลจิตของสิ่งที่เป็นจริงในพื้นที่เก็บข้อมูล เมื่อมาถึงจุดนี้ seniours อาจจำได้ว่าภายในsvnมีเวทมนตร์อาถรรพ์ (เคยมีปัญหากับล็อคในพื้นที่เก็บข้อมูล svn หรือกับ "reintegrating" กิ่งไม้และเช่นนั้น?) และนี่อาจกระตุ้นให้พวกเขาเล็กน้อย

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

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

การกระทำที่อธิบายในแง่ของโครงสร้าง

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

ฉันกำลังพูดถึงadd, commitร่วมกับไดเร็กทอรี่การทำงานในพื้นที่และสเตจ (ตรวจสอบให้แน่ใจว่าพวกเขาเข้าใจว่าไดเร็กตอรี่การทำงานนั้นไม่เหมือนกับพื้นที่การจัดเตรียมซึ่งไม่เหมือนกับที่เก็บ).

เมื่อพวกเขาเข้าใจว่าคำสั่งเหล่านี้เพียงแค่ปลูกต้นไม้ (ซึ่งในขั้นตอนนี้ประกอบด้วย3ประเภทคือ - blobs, ต้นไม้, การกระทำ, ไม่เพียง แต่กระทำ) คุณสามารถทำสิ่งแรกgit pushและgit pull(ในโหมดกรอไปข้างหน้า! ) เพื่อแสดงให้เขารู้ว่าgitเป็นอักษรเท่านั้นผลักดันวัตถุรอบที่แฮชที่มีจริงๆเพียง hashes เนื้อหาที่คุณสามารถคัดลอกสิ่งนี้รอบกับคำสั่งคัดลอกไฟล์ระบบและอื่น ๆ

เห็นได้ชัดว่าอยู่ห่างจากตัวเลือกที่ไม่จำเป็นของคำสั่งเหล่านี้เรากำลังพูดถึงgit add hello.txtที่นี่

สาขา

โปรดทราบว่าการแตกแขนงนั้นยากสำหรับsvnคนโดยเฉพาะเนื่องจากมีความแตกต่างอย่างสิ้นเชิง svnรูปแบบมากง่ายต่อการมองเห็นภาพที่มีพื้นเป็นอะไรที่ต้องเห็นภาพ - มันอยู่ในมุมมองธรรมดา gitรุ่นไม่มาก ตรวจสอบให้แน่ใจว่าพวกเขารู้ตัวตั้งแต่เริ่มต้นว่ากิ่งไม้และแท็กเป็นเพียง "โน้ตติดหนึบ" ชี้ไปที่อื่นและไม่ได้มีอยู่จริงในแง่ของประวัติศาสตร์ที่คงที่และไม่เปลี่ยนรูป

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

หากพวกเขามีสิ่งนั้นคุณสามารถอธิบายได้ว่าgit pullเป็นgit fetch && git mergeอย่างไร วิธีที่เก็บข้อมูลทั้งหมดมีวัตถุเดียวกันอย่างแท้จริง ( git fetchเกือบจะเหมือนกับการคัดลอกเนื้อหาไปด้วยscpภายในไดเรกทอรีวัตถุ git) และอื่น ๆ

อาจเป็นไปได้ว่าถ้าถึงตอนนี้คุณยังไม่สามารถกระตุ้นความสนใจได้คุณก็สามารถยอมแพ้ได้ แต่ถ้าพวกเขาจัดการเพื่อให้ห่างไกลพวกเขาก็มีเครื่องมือทางจิตใจทุกอย่างที่พวกเขาควรมี กลัวว่าจะเกี่ยวข้องอีกต่อไป ส่วนที่เหลือ (เวิร์กโฟลว์คอมไพล์ ... ) ควรลงเนินแล้ว

คำสุดท้าย

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

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

ฉันต้องการที่จะนำคุณไปนี้รายการบล็อกโดยโจ Spolsky

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

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

คำแนะนำส่วนตัวของฉันคือการเริ่มอธิบายคำสั่ง:

• git เพิ่ม <files>
• คอมไพล์
• git pull
• git push
• สถานะคอมไพล์

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

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

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

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

เริ่มง่ายๆ

คุณบอกว่าคุณเลือก Gitflow เป็นมาตรฐานสำหรับการจัดการสาขา สิ่งนี้ทำให้ฉันเป็นความผิดพลาดครั้งใหญ่ที่สุดของคุณ

หากต้องการอ้างอิงGitflow ถือว่าเป็นอันตราย :

สาขาทั้งหมดเหล่านี้ที่ใช้บังคับให้ GitFlow มีชุดของกฎที่ซับซ้อนซึ่งอธิบายถึงวิธีการโต้ตอบ กฎเหล่านี้ประกอบกับประวัติที่จับต้องไม่ได้ทำให้การใช้ GitFlow ในชีวิตประจำวันเป็นเรื่องยากสำหรับนักพัฒนา

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

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

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

• โคลน
• ดึง
• สาขา
• ผสาน
• ผูกมัด
• ดัน
• ความรู้เกี่ยวกับวิธีการ.gitignoreทำงาน
• อาจจะแท็ก

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

ค่อยๆเพิ่มความรู้

จากที่นี่คุณสามารถค่อยๆให้ความรู้เกี่ยวกับการใช้งานขั้นสูงขึ้นเล็กน้อย

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

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

จากนั้นเลือกมาตรฐานการแยกสาขา

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

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

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

นี่เป็นทางเลือกสองทางสำหรับ Gitflow ที่ทีมของคุณสามารถพิจารณาได้:

• OneFlow
• คุณสมบัติเวิร์กโฟลว์สาขา
• เวิร์กโฟลว์ส่วนกลาง

ดูที่พวกเขาและ Gitflow ชั่งน้ำหนักพวกเขากับกรณีการใช้งานของคุณและเลือกหนึ่งที่เหมาะกับ

ฉันพบว่า stackoverflow มีประโยชน์อย่างมากในขณะที่ฉันเริ่มใช้คำศัพท์ Git เป็นครั้งแรก คำถามเช่นคำถามเหล่านี้มีประโยชน์มากสำหรับฉัน (ส่วนใหญ่เป็นเพราะความรัดกุมของพวกเขา) และฉันทำให้พวกเขาเปิดในแท็บในช่วงสองสามสัปดาห์แรกที่ฉันใช้มัน อาจพิมพ์คำตอบสองสามฉบับด้วยตัวหนา? โดยเฉพาะแผนภาพบนอันแรก

อะไรคือความแตกต่างระหว่าง“ การคอมไพล์คอมไพล์” และ“ การคอมไพล์พุช”?

อะไรคือความแตกต่างระหว่าง 'git pull' และ 'git fetch'?

ฉันยังพบว่าภาพที่แสดงถึงลำตัวนั้นมีประโยชน์อย่างน่าอัศจรรย์ แต่คุณก็ครอบคลุมสิ่งนั้นด้วย SourceTree

_{นอกจากนี้บิตนี้อาจเป็นความคิดเห็น แต่ฉันไม่มีตัวแทน: ฉันเป็นหนึ่งในที่ปรึกษาระดับจูเนียร์ที่กล่าวถึงในคำถาม ก่อนที่ฉันจะเริ่มฉันมีความคิดว่าระบบควบคุมแหล่งที่มาคืออะไรและฉันแหย่ SVN สองครั้ง Gusdor ให้เครดิตมากกว่าที่ฉันสมควรได้รับ ทีมงานทั้งหมดมีการฝึกอบรม Git พิเศษที่มีคุณภาพสูงของเล่นและเวลาในการเล่น ปัญหาไม่ได้อยู่กับคำสั่งของ Gusdor ฉันหวังว่าจะมีทางเลือกที่ดีในการทำเช่นนี้เพื่อให้ฉันสามารถคั่นหน้ามันอย่างหนักและเรียนรู้เพิ่มเติม}

ซื้อหนังสือ

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

สิ่งที่ช่วยฉันได้คือหนังสือที่อธิบายอย่างชัดเจนว่าเกิดอะไรขึ้น แต่ที่สำคัญกว่านั้นคือ Git แตกต่างจากระบบควบคุมแหล่งข้อมูลใด ๆ ที่ฉันเคยใช้มาก่อน ตอนนี้ฉันชอบ Git มากกว่าตัวเลือกอื่น ๆ

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

การเดาที่ดีที่สุดสำหรับการแนะนำหนังสือคือ:

Pro Git โดย Scott Chacon (ลิงก์ของ Amazon เพื่อความสะดวก ... ซื้อจากใครก็ได้ที่คุณต้องการ: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

หมายเหตุ : ไม่ได้ซื้อหนังสืออ้างอิงสำหรับ Git ที่จะไม่ช่วยเลย

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

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

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

ฉันกำลังเล่นกับการแนะนำgitว่าฉันอยู่ที่ไหน (จาก TFS) ดังนั้นคำถามของคุณจึงตรงเวลากับฉัน

ในPeoplewareวิทยานิพนธ์พื้นฐานของหนังสือเล่มนี้คือ:

ปัญหาที่สำคัญของการทำงานของเรามีไม่มากเทคโนโลยีเป็นสังคมวิทยาในธรรมชาติ

ฉันนำเรื่องนี้ขึ้นมาเพราะพวกเราไม่ใช่ปัญหาทางเทคนิค gitในขณะที่ป้านเล็กน้อยอาจจะไม่เกินความสามารถของคุณหรือ devs อาวุโสของฉันจนกว่าพวกเขาจะโง่มาก *

ลองดูจากมุมมองของผู้คนในฐานะคนไม่ใช่เครื่องจักรด้านเทคนิค:

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

นั่นอาจเป็นสาเหตุที่รุ่นน้องใช้มันได้ดีกว่า - บางทีพวกเขาอาจจะยังไม่ติดsvnและgitเป็นโอกาสของพวกเขาที่จะทำมัน ^

ผู้อาวุโสแม้ว่าจะระมัดระวังค่าใช้จ่ายโอกาส - ถ้าพวกเขาเรียนรู้gitพวกเขาจะไม่:

• การเรียนรู้ React / Angular / Swift / Blockchain / Kotlin (สิ่งอื่น ๆ ที่พวกเขารู้สึกว่าควรจะเรียนรู้)
• การทำ DIY / การขว้าง / การแล่นเรือใบ / บทกวี / glockenspiel / อะไรก็ตามที่พวกเขาต้องการทำ
• ใช้เวลากับลูกญาติ / เพื่อน / คนอื่น ๆ

• การนำเสนอ "สิ่งใหม่ที่ยิ่งใหญ่" นี้ - มีกำหนดส่งงบประมาณ ฯลฯ พวกเขาอาจกังวลเกี่ยวกับเรื่องนี้

  "ฉันต้องทำตามข้างต้นทั้งหมดทำไมฉันต้องใช้git เมื่อเรามีการควบคุมแหล่งที่มาอยู่แล้ว?"

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

ดึงร้องขอ? เช็คอินเม็ดเล็ก ๆ ? กระจายแหล่งที่มา? งา?

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

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

โชคดี.

ฉันคิดว่านี่เป็นคำถามวิศวกรรมซอฟต์แวร์ที่น้อยกว่าและมีคำถามทางจิตวิทยามากกว่า Algorithms to Live By: The Computer Science of Humand Decisionsฉันต้องการที่จะอ้างถึง ในนั้นผู้เขียนจะเข้าสู่หัวข้อของการสำรวจ / ใช้ประโยชน์จากการแลกเปลี่ยน โดยปกติแล้วมนุษย์จะต้องผ่านขั้นตอนของการสำรวจและจากนั้นผ่านขั้นตอนของการใช้ประโยชน์จากสิ่งที่พวกเขาสำรวจ มีทฤษฎีทางคณิตศาสตร์ที่เป็นของแข็งอยู่เบื้องหลังเหตุใดจึงเป็นเช่นนี้เพื่อให้ได้ประโยชน์สูงสุดจากบางสิ่งในช่วงเวลาหนึ่ง

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

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

กลยุทธ์ที่ดีที่สุดของพวกเขาคือการใช้ประโยชน์จาก SVN เพราะพวกเขาได้ทำการสำรวจและพบว่านี่เป็นสิ่งที่ดีที่สุดซึ่งพวกเขาใช้ประโยชน์จากตอนนี้

นี่คือจิตวิทยาขั้นพื้นฐานของมนุษย์และหลายร้อยพันปีของการเพิ่มประสิทธิภาพเชิงวิวัฒนาการที่คุณต่อสู้

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

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

ต่อไปคือการดูปัญหาที่ Git ทำได้ดีกว่า SVN เพื่อให้ทีมของคุณเรียนรู้คุณต้องกระตุ้นให้พวกเขาเห็นว่าทำไมคอมไพล์ถึงดีกว่า

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

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

มันเป็นสิ่งใหม่ที่จะเรียนรู้และมีความคล้ายคลึงกันมากพอที่จะทำให้เกิดความสับสน แต่ในปี 2560 DCVS นั้นเป็นทักษะที่สำคัญมากสำหรับนักพัฒนาทุกคน

บอกพวกเขาว่าไม่ต้องกังวล

ใน Git เมื่องานได้รับมอบหมายมันแทบจะเป็นไปไม่ได้ที่จะสูญเสีย งานเดียวที่คุณสูญเสียได้ง่ายคืองานที่ยังไม่ได้ทำ

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

จากนั้นสร้างความประทับใจให้แก่พวกเขากฎง่ายๆข้อนี้เมื่อสงสัย พวกเขาสามารถสำรองการกระทำในภายหลังได้ (แม้จะมาจากระยะไกล!)

อย่าใช้ GUI

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

รหัสโปรแกรมคู่

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

Git ปลอดภัยแล้ว

มีคนพูดคุยเกี่ยวกับการมี "สถานที่ที่ปลอดภัยในการเล่น" แต่ Git นั้นเป็นที่ที่ปลอดภัย มีเพียงสองกรณีที่เกิดขึ้นเป็นประจำทุกวันซึ่งง่ายต่อการสูญเสียงาน:

• รหัสปราศจากข้อผูกมัด
• การใช้ GUI

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

ผมจะแนะนำให้ดูที่Gitless มันเป็น wrapper over git ที่ทำให้เวิร์กโฟลว์พื้นฐานง่ายขึ้นมาก (ไม่จำเป็นต้องกังวลเกี่ยวกับพื้นที่จัดเตรียมสาขาเก็บสำเนาทำงานของตนเองไว้ใช้งานง่ายขึ้นgit rebaseจัดการกับgl fuseฯลฯ ) ในขณะที่ยังคงเป็นแหล่งเก็บข้อมูล git พื้นฐานสำหรับการทำงานร่วมกัน หรือถ้าคุณต้องการทำสิ่งผิดปกติ นอกจากนี้ข้อความยังเป็นมิตรต่อผู้เริ่มหัดอีกเล็กน้อย และคำสั่งนั้นอยู่ใกล้พอที่จะคอมไพล์ให้ทำหน้าที่เป็นสเต็ปปิ้งได้หากพวกเขาจำเป็นต้องใช้ระบบโดยไม่ต้องมีความคิดมากกับมันด้วยเหตุผลใดก็ตาม

ฉันพยายามบันทึกพื้นฐานของวิธีใช้บรรทัดคำสั่งของ git มันยังคงสับสน - ทั้งตัวฉันเอง (ผู้ที่เคยมีประสบการณ์ใช้ Perforce และ Source Safe) และสำหรับโปรแกรมเมอร์ที่ชอบแบบเก่า ๆ "เพียงแค่ซิปไฟล์ที่เกี่ยวข้อง" กระบวนทัศน์ มันน่าเป็นห่วงที่เครื่องมือทึบแสงจะดัดแปลงเนื้อหาของไดเรกทอรีการทำงานของฉันและมักจะต้องเถียงกับเครื่องมือเพื่อรวมการเปลี่ยนแปลงเฉพาะในไดเรกทอรีการทำงานของฉัน

แต่ฉันใช้การอ้อมสองแบบ

• ฉันใช้ GitKraken เพื่อให้เห็นประวัติของสาขาของฉันและ GUI ที่ซ่อนคำสั่งบรรทัดคำสั่ง GitKraken จัดการการโต้ตอบระหว่างที่เก็บข้อมูลระยะไกล "ที่มา" และสิ่งที่ git คิดว่าเป็นไดเรกทอรีการทำงานในท้องถิ่นของฉัน

• ฉันยังเก็บไดเรกทอรีการทำงานในท้องถิ่นของ "จริง" ที่แยกจากสิ่งที่ git คิดว่าเป็นไดเรกทอรีการทำงานในท้องถิ่นของฉัน ฉันซิงค์ไดเรกทอรีการทำงานทั้งสองนี้ด้วยตนเองซึ่งทำให้ฉันรู้สึกสบายใจมากขึ้นว่าการเปลี่ยนแปลงใด ๆ ในไดเรกทอรีการทำงานของฉันเป็นสิ่งที่ฉันตั้งใจจะมี

ฉันสามารถทำอะไรได้บ้างเพื่อช่วยให้พนักงานเหล่านี้เรียนรู้ Git?

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

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

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

มีโอกาสมากที่นักพัฒนาที่มีประสบการณ์ทำงานในหลาย บริษัท ที่มี

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

ดังนั้นทันทีที่บางคนบอกฉันว่าเครื่องมือที่ดีในการแยกความคิดของฉันบอกกับฉัน

ฝ่ายบริหารไม่ต้องการตัดสินใจว่า บริษัท จะไปทางไหนและอยากให้ฉันเสียชีวิตโดยรวมงานของฉันเข้ากับสาขาต่าง ๆ 101 สาขารวมทั้งต้องทดสอบซอฟต์แวร์รุ่นต่างๆ 101 ครั้ง

นอกจากนี้แนวคิดที่ว่าคนสองคนจะทำงานกับไฟล์เดียวกันในเวลาเดียวกันคือ“ ดี” ไม่เป็นที่ยอมรับของใครบางคนที่มีประสบการณ์ในการดำเนินโครงการที่ดีดังนั้นการส่งเสริม Git เป็นเครื่องมือในการทำเช่นนั้นจึงไม่น่าจะได้รับประสบการณ์ นักพัฒนาที่ชื่นชอบคุณ

ทุกครั้งที่ฉันดูประวัติใน Git มันยากมากที่จะเห็นว่าทำไมโค้ดถึงเปลี่ยนไปเนื่องจาก 50% หรือมากกว่านั้นของประวัติศาสตร์ถูกรวมเข้าด้วยกันซึ่งมีเหตุผลไม่ควรเปิดเผยต่อสาธารณะและพวกเขากลายเป็นไร้ความหมายทันทีที่รหัสออกจากนักพัฒนา เครื่อง

แต่ฉันชอบที่จะทำงานที่ไหน:

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

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

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

ฉันคาดหวังว่า Kiln ( http://www.fogcreek.com/fogbugz/devhub ) หรือแม้แต่ GitHub ที่ใช้เวิร์กโฟลว์ "คำขอดึง" จะช่วยให้นักพัฒนาที่มีประสบการณ์มีความสุขเช่นไม่เริ่มต้นด้วยระดับต่ำเริ่มต้นด้วยการปรับปรุง กระบวนการ.