ฉันจะจัดการคอมมิท, ป้องกันความขัดแย้งของฟีเจอร์และจัดการการพึ่งพากับ VCS ได้อย่างไร?

9

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

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

ฉันอยากจะได้ยินประสบการณ์ของผู้อื่นและบางทีแนวปฏิบัติที่ดีที่สุดในการจัดการการควบคุมแหล่งที่มา

version-control

— Nickz
แหล่งที่มา

2

สำเนาซ้ำที่เป็นไปได้ของprogrammers.stackexchange.com/questions/5540/… , programmers.stackexchange.com/questions/15730/…

— Adam Lear

3

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

— Newtopian

1

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

— Manfred

กลยุทธ์การแยกการควบคุมแหล่งที่มาเป็นหัวข้อใหญ่ programmers.stackexchange.com/questions/107884/…

— gnat

@John - ฉันคิดว่า "ละเมิด" เป็นคำที่สะกดผิดสำหรับ "volatile"

— ChrisF

7

TFS? วิ่งไปที่เนินเขา! เลื่อนออกให้เร็วที่สุด มันทำสิ่งต่าง ๆ มากมาย แต่ไม่มีสิ่งใดที่ดีเท่าเครื่องมือพันธุ์ที่ดีที่สุด

แต่จริงจัง:

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

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

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

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

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

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

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

— Manfred
แหล่งที่มา

2

"TFS? Run for the hills!" - ฉันถูกล่อลวงให้สร้างบัญชีที่สองเพื่อให้ฉันลงคะแนนสองครั้งนี้

— Ant

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

— ไลโอเนล

1

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

— Manfred

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

— ไลโอเนล

4

ฉันสนับสนุนหนึ่งสาขาต่อคุณลักษณะเนื่องจากมันช่วยให้มีความยืดหยุ่นอย่างมากเมื่อตัดสินใจว่าคุณลักษณะใดที่จะจัดส่ง & ที่จะเลื่อนไป

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

— mcottle
แหล่งที่มา

2

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

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

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

— ลิโอเนล
แหล่งที่มา

2

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

— Trasplazio Garzuglio

@ marco-dinacci: สิ่งที่คุณพูดอาจจะถูกต้องหากคุณมีมากกว่าหนึ่งปล่อยไว้ตลอดเวลา อย่างไรก็ตามคุณไม่สนใจความจริงที่ว่าการแก้ไขข้อบกพร่องเหล่านั้นจะถูกรวมกลับเข้าไปในลำต้น รุ่นอื่น ๆ สามารถดึงการเปลี่ยนแปลงได้ เกี่ยวกับการแตกของลำตัว ก่อนที่คุณจะคอมมิตโค้ดลงใน trunk คุณควรตรวจสอบให้แน่ใจว่าคุณมีแหล่งข้อมูลล่าสุดทั้งหมดและการเปลี่ยนแปลงของคุณไม่ทำให้ trunk แตก หากมันเสียคุณไม่ควรกระทำจนกว่าจะได้รับการแก้ไข แน่นอนว่ามีข้อดีและข้อเสียของวิธีการที่แตกต่างกัน

— ไลโอเนล

1

ฉันไม่เคยใช้ TFS 2008/2010 แต่จากสิ่งที่ฉันได้อ่านในฟอรัมต่าง ๆ มีแง่ลบมากมายเกี่ยวกับการใช้ TFS สำหรับการควบคุมเวอร์ชัน สิ่งนี้ทำให้ฉันยังคงชัดเจนจาก TFS จนถึงตอนนี้

ตอนนี้ฉันใช้ SVN และ Git ฉันพบว่าทั้งคู่เหมาะสำหรับทีมเล็กหรือทีมชายเดี่ยว แต่ไม่แนะนำ SVN สำหรับทีมใหญ่เป็นการส่วนตัว

ฉันมีตาของฉันใน PlasticSCM สำหรับและจะพยายามที่ในอนาคตอันใกล้

ฉันขอโทษที่ไม่ตอบคำถามของคุณโดยเฉพาะจะมีการโพสต์ความคิดเห็นหากสิทธิ์ของฉันอนุญาตให้ฉัน

— ฆา
แหล่งที่มา

1

ฉันคิดว่า git ทำให้ซอฟต์แวร์การควบคุมแหล่งอื่น ๆ ทั้งหมดล้าสมัย การแตกแขนงและการผสานนั้นง่ายและถ้ามีปัญหามันก็จะถูกกักกัน แต่ปัญหามากมายจะถูกหลีกเลี่ยงโดยวิธีที่มันกระตุ้นให้เกิดการผูกมัดการแยกและการรวมกันบ่อยครั้งมาก ผู้ใช้แต่ละคนจะได้รับสำเนาเต็มรูปแบบของ repo (สามารถตัดได้ แต่ฉันทำงานกับรหัสฐานขนาดใหญ่มากและไม่เป็นปัญหา) ดังนั้นจึงมีการสำรองข้อมูลอัตโนมัติ Commits / push / pull นั้นรวดเร็วและสิ่งที่สำคัญที่สุดอย่างหนึ่งก็คือการแบ่งการเชื่อมต่อระหว่างชื่อไฟล์และการติดตาม ข้อมูลไฟล์รวมถึงชื่อและเส้นทางเป็นหยดข้อมูลที่อ้างอิงโดยโหนดต้นไม้ที่ไม่ขึ้นอยู่กับเส้นทาง สิ่งนี้ไม่เพียงปลอดภัยเท่านั้น แต่ยังมีปัญหา "ไม่เคยทำเช่นนั้น" ในบางสิ่งบางอย่างเช่น SVN ไม่ใช่ปัญหา สามารถใช้เป็นการกำหนดค่าฮับดั้งเดิมหรือเพียร์ทูเพียร์และการใช้เหล่านั้นสามารถผสมกันได้อย่างอิสระในการตั้งค่าเดียวกัน มันปลอดภัยด้วยการเข้ารหัสที่ไม่มีเอกสารแทรก และมันก็เร็วมาก

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

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

— kylben
แหล่งที่มา

1

Git ดีจริงๆ แต่ (เหมือนทุกอย่าง) มันไม่ใช่ทางออกที่ดีที่สุดสำหรับทุกคน & ทุกอย่าง programmers.stackexchange.com/questions/111633/…

— โกง

4

Git ทำให้ Mercurial ล้าสมัยไปในทางใด โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการพัฒนา Windows มันจะเป็นการดีกว่าถ้าจะบอกว่า DVCS ทำให้ VCS อื่นล้าสมัยมากกว่าการทิ้งระเบิดน้ำมันเบนซินและเริ่มสงครามศักดิ์สิทธิ์

— mcottle

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

— โกง

@ldigas: ในทางใดที่ git และ hg "suck" แย่กว่านี้ด้วยไฟล์ไบนารีมากกว่า svn ไม่สามารถติดตามการเปลี่ยนแปลงในไบนารีนอกเหนือจากความละเอียดต่อไฟล์พร้อมผลที่เกี่ยวข้องทั้งหมด นอกจากนี้พวกเขายังทำให้ svn ส่วนใหญ่ล้าสมัยด้วยการดูว่าสามารถทำอะไรได้บ้าง svn (นอกเหนือจากคุณสมบัติที่ไม่ชัดเจนบางอย่าง) และจากนั้นบางส่วน; คุณแค่ต้องตั้งค่าแบบนั้น เหตุผลที่ดีที่สุดสำหรับการใช้ svn ที่ฉันคิดได้ก็คือคุณใช้มันไปแล้วและการโยกย้ายจะเจ็บปวด / เสี่ยง / แพงเกินไป

— tdammers

@tdammers - ฉันไม่สนใจสนทนา trolling สำหรับจุดใด ๆ ข้างต้นลองใช้ google สักครู่แล้วคุณจะสะดุดกับสิ่งที่รวดเร็ว

— โกง

1

แนวทางปฏิบัติที่ดีบางข้อที่เราปฏิบัติตามและช่วยเหลือเราอย่างมาก:

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

2) ติดป้ายชื่อไฟล์ของคุณเป็นระยะหลังจากเหตุการณ์สำคัญเล็ก ๆ

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

— แฟรงคลิน
แหล่งที่มา

1

คุณจะจัดการ Checkins และป้องกันความขัดแย้งของคุณสมบัติและจัดการการพึ่งพากับการควบคุมแหล่งที่มาได้อย่างถูกต้องได้อย่างไร?

มันมาจาก POV ของฉันภารกิจสองปัจจัย: คุณต้องทำจากเทคนิค (ดี & ง่าย & กันกระสุน - แยก | รวม | ตรวจสอบ ฯลฯ ) และการจัดการ (การกำหนดนโยบายที่ดี "อะไร" "เมื่อ" "วิธี") ด้าน รหัสแยกสองหรือสามระดับใน ALM: บางอย่างเช่น "เสถียร" (ผ่านการทดสอบหน่วย), "ไม่เสถียร" (ทุกคุณสมบัติรวมเสร็จแล้ว แต่แอปเป็นผลิตภัณฑ์มีคำถามหลังการรวม / ใช่มันสามารถเกิดขึ้นได้ ) และ " กำลังดำเนินการ " วิธีนี้ผู้จัดการโครงการที่เหมาะสมสามารถลดการรบกวนการทำงานของนักพัฒนาแยกต่างหาก

TFS (ซึ่งฉันไม่ได้ใช้ใช้และจะไม่ใช้) มีปัญหา AFAIK ปัญหาพื้นฐานในการจัดการการควบคุมแหล่งที่มา ฉันเพียงแค่เชื่อมโยงที่นี่กับบางตำราของ James McKay:

— Lazy Badger
แหล่งที่มา

1

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

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

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

— แองเจโล
แหล่งที่มา