นักพัฒนาแอปพลิเคชันมืออาชีพใช้ระบบควบคุมเวอร์ชันเช่น GIT และ Subversion อย่างไร


10

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

แอปพลิเคชันของฉันไม่ใหญ่มากและฉันยังไม่ได้ทำงานเป็นทีมพวกเขาจะช่วยฉันได้มากหรือไม่

มีคำถามในเว็บไซต์นี้เกี่ยวกับวิธีการใช้เครื่องมือ แต่ฉันต้องการการสนับสนุนเริ่มต้น


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

คำตอบ:


13

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

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

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

นี่คือภาพรวมที่ดีของกฎง่ายๆสำหรับการควบคุมแหล่งที่มาโดยทั่วไป: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

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


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

5

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

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

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

นี่เป็นแหล่งข้อมูลที่มีประโยชน์บางประการ:

เริ่มต้นใช้งาน Subversion และ Tortoise SVN ด้วย Visual Studio และ. NET

การควบคุมเวอร์ชันด้วยการโค่นล้ม


1
ไม่ให้ +1 เพราะการเรียนรู้การโค่นล้มเป็นระบบแรกนั้นเป็นสิ่งที่ตรงกันข้ามในทุกวันนี้เมื่อทุกคนเปลี่ยนไปใช้ระบบแบบกระจาย
Jan Hudec

3

แบบฝึกหัดสำหรับผู้เริ่มต้น

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

SVN

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

การควบคุมแหล่งที่มาระดับมืออาชีพตอบสนองความต้องการระดับมืออาชีพ

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

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

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

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

ขออภัยที่เดินเล่นหวังว่าสิ่งนี้จะช่วยคุณในการเข้าถึงการใช้ตัวควบคุมแหล่งที่มา


0

ทีมของฉันใช้ระบบควบคุมเวอร์ชันทีมที่ปลูกเอง (น่าเศร้าที่ Git ยังไม่สามารถใช้งานได้กับไฟล์ต้นฉบับ "ดั้งเดิม" ของ IBM i) แต่โดยส่วนตัวเมื่อฉันดึงซอร์สจากระบบนั้นฉันใช้ Git ในระหว่างการพัฒนาจนกระทั่งโครงการเสร็จและตรวจสอบกลับเข้าสู่ ทีม VCS

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

Git ได้ปรับปรุงวิธีการพัฒนาของฉัน


'ดูเหมือนว่า Git จะยังใช้งานไม่ได้กับไฟล์ต้นฉบับ "ดั้งเดิม" ของ IBM i) - Git ควรทำงานกับไฟล์ใดก็ได้ มีปัญหาอะไรที่นี่
Marnen Laibow-Koser

@ MarnenLaibow-Koser ผู้พัฒนา IBM i ส่วนใหญ่ทำงานกับไฟล์ต้นฉบับด้วยสิ่งที่เราอาจเรียกว่าระบบไฟล์ดั้งเดิม (ดั้งเดิม) QSYS โดยที่ไฟล์ต้นฉบับมีรูปแบบความยาวคงที่ในตัว แต่ละบรรทัดเริ่มต้นด้วยหมายเลขลำดับ 6 หลักวันที่เปลี่ยน 6 หลักจากนั้นบรรทัดข้อความรหัสต้นฉบับ ลำดับและวันที่เปลี่ยนอาจเปลี่ยนแปลงได้แม้ว่าซอร์สโค้ดบนบรรทัดจะไม่เปลี่ยนแปลง โซลูชั่นอาจได้รับการพัฒนาขึ้นเร็ว ๆ นี้ IBM & อื่น ๆ สนับสนุน git บน IBM i และไม่ควรมีปัญหากับซอร์สในไฟล์สตรีม "ปกติ" ในระบบไฟล์ IFS อื่น ๆ บน IBM i
WarrenT

โอ้พระเจ้าฉันจำได้อย่างชัดเจนว่าจากการพัฒนา AS / 400 เมื่อ 20 ปีก่อน แต่ไม่มีเหตุผลฉันคิดว่า Git จะไม่ทำงานกับไฟล์ดังกล่าว คุณอาจต้องเขียนโปรแกรมควบคุมการผสานที่ลดจำนวนบรรทัด แต่ก็ควรทำง่าย (ฉันสงสัยว่าเป็นสิ่งที่ IBM ทำ ... )
Marnen Laibow-Koser

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

คุณสามารถสร้าง Git clean / smudge filter เพื่อคืนค่าวันที่จาก Git blame :)
Marnen Laibow-Koser
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.