คำถามติดแท็ก version-control

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

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

19
การควบคุมเวอร์ชันเมื่อใดมีขนาดใหญ่เกินไป? [ปิด]
ฉันเคยได้ยินในหลาย ๆ ที่ "อย่าทำสิ่งที่ต้องทำมากมาย" แต่ฉันไม่เคยเข้าใจสิ่งใดที่กระทำ "ตัวใหญ่" มันมีขนาดใหญ่หรือไม่ถ้าคุณทำงานกับไฟล์หลายไฟล์ คุณควรทำงานหลายโครงการในคราวเดียว สำหรับฉันฉันมีปัญหาในการพยายามทำ "ความมุ่งมั่นเล็ก ๆ " เนื่องจากฉันลืมหรือสร้างสิ่งที่สร้างสิ่งอื่นที่สร้างอย่างอื่น จากนั้นคุณก็จบลงด้วยสิ่งต่างๆดังนี้: ทำคิวขาออกที่กำหนดเอง Bot - เขตข้อมูลใหม่ msgQueue ซึ่งไม่มีอะไรมากไปกว่า SingleThreadExecutor -sendMsg บล็อกจนกว่าข้อความจะถูกส่งและเพิ่มรอระหว่างเมื่อข้อความได้รับ ส่ง -adminExist ปรับปรุงสาย (ดูตัวควบคุม) - ลบเรียกร้องให้ sendMessage ตัวควบคุม - เขตข้อมูลใหม่ msgWait หมายถึงเวลาในการรอระหว่างข้อความ - เริ่มต้นปลั๊กอินบริการย้ายไปที่ reloadPlugins -adminExists ย้ายจากเซิร์ฟเวอร์เนื่องจากผู้ดูแลระบบส่วนกลาง ตรวจสอบที่ช่อง เซิร์ฟเวอร์และระดับโลก ผู้ดูแลระบบ - เมธอดใหม่ getServer และ getChannel ที่รับค่า Admin …

9
กระทำ / ตรวจสอบในรหัสทุกวันเป็นแนวปฏิบัติที่ดีหรือไม่?
ฉันได้อ่านบันทึกของมาร์ตินฟาวเลอร์เกี่ยวกับการบูรณาการอย่างต่อเนื่องและเขาระบุว่าต้องเป็น "ทุกคนมุ่งมั่นที่จะทำการฉีดทุกวัน" ฉันไม่ชอบที่จะส่งรหัสเว้นแต่ส่วนที่ฉันกำลังทำอยู่นั้นสมบูรณ์และในทางปฏิบัติฉันยอมรับรหัสของฉันทุกสามวัน: หนึ่งวันเพื่อตรวจสอบ / ทำซ้ำงานและทำการเปลี่ยนแปลงเบื้องต้นวันที่สองเพื่อดำเนินการเปลี่ยนแปลงให้เสร็จสมบูรณ์ และวันที่สามเพื่อเขียนแบบทดสอบและทำความสะอาด ^ สำหรับการส่ง ฉันจะไม่รู้สึกสะดวกสบายที่จะส่งรหัสเร็วกว่านี้ ตอนนี้ฉันดึงการเปลี่ยนแปลงจากที่เก็บและรวมพวกเขาในพื้นที่โดยปกติวันละสองครั้ง แต่ฉันไม่ได้กระทำที่มักจะเว้นแต่ว่าฉันจะสามารถแกะงานชิ้นเล็ก ๆ คำถาม:การกระทำทุกวันเป็นวิธีที่ดีที่ฉันควรเปลี่ยนเวิร์กโฟลว์ของฉันเพื่อรองรับหรือไม่แนะนำให้ทำ? แก้ไข:ฉันเดาว่าฉันควรจะชี้แจงว่าฉันหมายถึง "กระทำ" ในความหมายของ CVS (aka "push") เนื่องจากเป็นไปได้ว่าสิ่งที่ Fowler จะมีความหมายในปี 2549 เมื่อเขาเขียนสิ่งนี้ ^ คำสั่งซื้อนั้นมีความอิสระมากขึ้นและขึ้นอยู่กับงานนั้นประเด็นของฉันคือเพื่อแสดงช่วงเวลาและกิจกรรมไม่ใช่ลำดับที่แน่นอน

15
ฉันจะโน้มน้าวให้โปรแกรมเมอร์คาวบอยใช้การควบคุมแหล่งที่มาได้อย่างไร
อัพเดท ฉันทำงานกับทีม devs เล็ก ๆ 4 คน พวกเขามีการควบคุมแหล่งที่ใช้ทั้งหมด ส่วนใหญ่ไม่สามารถควบคุมแหล่งที่มาและเลือกที่จะไม่ใช้แทน ฉันเชื่อมั่นอย่างยิ่งว่าการควบคุมแหล่งข้อมูลเป็นส่วนที่จำเป็นในการพัฒนาวิชาชีพ ปัญหาต่าง ๆ ทำให้ยากต่อการโน้มน้าวใจให้ใช้ตัวควบคุมแหล่งที่มา: ทีมที่ไม่ได้ใช้ในการใช้TFS ฉันมีการฝึกอบรม 2 ครั้ง แต่ได้รับการจัดสรรเพียง 1 ชั่วโมงเท่านั้นซึ่งไม่เพียงพอ สมาชิกในทีมปรับเปลี่ยนรหัสบนเซิร์ฟเวอร์โดยตรง สิ่งนี้จะทำให้รหัสไม่ซิงค์กัน ต้องการการเปรียบเทียบเพื่อให้แน่ใจว่าคุณกำลังทำงานกับรหัสล่าสุด และปัญหาการรวมที่ซับซ้อนเกิดขึ้น การประเมินเวลาที่นักพัฒนาซอฟต์แวร์นำเสนอไม่รวมเวลาที่ต้องใช้ในการแก้ไขปัญหาเหล่านี้ ดังนั้นถ้าฉันบอกว่าไม่ใช่จะใช้เวลานานกว่า 10 เท่า ... ฉันต้องอธิบายปัญหาเหล่านี้อย่างต่อเนื่องและเสี่ยงตัวเองเพราะตอนนี้ผู้บริหารอาจมองฉันว่า "ช้า" ฟิสิคัลไฟล์บนเซิร์ฟเวอร์แตกต่างกันในวิธีที่ไม่รู้จักมากกว่า ~ 100 ไฟล์ การผสานต้องการความรู้เกี่ยวกับโครงการในมือและดังนั้นความร่วมมือของนักพัฒนาซอฟต์แวร์ซึ่งฉันไม่สามารถทำได้ โครงการอื่น ๆ หลุดออกจากกัน นักพัฒนายังคงมีความไม่ไว้วางใจในการควบคุมแหล่งที่มาและทำให้เกิดปัญหาโดยไม่ได้ใช้ตัวควบคุมแหล่งที่มา นักพัฒนาให้เหตุผลว่าการใช้การควบคุมแหล่งที่มานั้นสิ้นเปลืองเพราะการผสานนั้นเกิดข้อผิดพลาดได้ง่ายและยาก นี่เป็นจุดที่ยากที่จะโต้แย้งเนื่องจากเมื่อการควบคุมแหล่งที่มานั้นไม่ถูกต้องใช้อย่างไม่ถูกต้องและการควบคุมแหล่งที่มาข้ามอย่างต่อเนื่องมันเป็นข้อผิดพลาดได้ง่ายแน่นอน ดังนั้นหลักฐาน "พูดเพื่อตัวเอง" ในมุมมองของพวกเขา นักพัฒนายืนยันว่าการปรับเปลี่ยนรหัสเซิร์ฟเวอร์โดยตรงการเลี่ยง TFS จะช่วยประหยัดเวลา นี่เป็นเรื่องยากที่จะโต้แย้ง เนื่องจากการรวมที่จำเป็นในการซิงโครไนซ์รหัสที่จะเริ่มต้นนั้นใช้เวลานาน …

3
พื้นที่เก็บข้อมูลของ Google เป็นอย่างไร
ฉันได้ยินมาว่า Google มีที่เก็บข้อมูลส่วนตัวขนาดใหญ่ (ภายใน) ของรหัสทั้งหมดและพนักงานของพวกเขาสามารถเข้าถึงได้เพื่อที่ว่าเมื่อพวกเขากำลังพัฒนาสิ่งที่พวกเขาไม่จำเป็นต้องบูรณาการล้อ ฉันต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับมัน! มีใครที่นี่จาก Google ที่สามารถอธิบายได้ในรายละเอียดเพิ่มเติมอีกเล็กน้อยหรือคุณรู้เพิ่มเติมเกี่ยวกับมันบ้างไหม? ฉันสนใจที่จะรู้ว่าส่วนใหญ่เกี่ยวกับวิธีการจัดระเบียบและวิธีที่ทำให้พนักงานสามารถค้นหาบางสิ่งบางอย่างในฐานข้อมูลขนาดยักษ์ได้อย่างง่ายดาย

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

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

17
ทางเลือกในการควบคุมเวอร์ชันมืออาชีพ [ปิด]
เรากำลังร่วมมือกับโปรแกรมเมอร์ (นักเขียน) ที่ไม่ใช่คนที่ต้องการมีส่วนร่วมในโครงการของเรา ตอนนี้พวกเขาไม่ชอบแนวคิดของการใช้ Git (หรืออะไรก็ตามสำหรับเรื่องนั้น) สำหรับเวอร์ชันที่ควบคุมการทำงานของพวกเขา ฉันคิดว่าเป็นเช่นนี้เพราะพวกเขาไม่คิดว่ามันจะคุ้มค่าที่จะห่อหุ้มแนวคิดที่บิดเบี้ยวของการควบคุมเวอร์ชัน (เมื่อฉันแนะนำพวกเขาให้รู้จักกับการแตกแขนงและรวมเข้าด้วยกัน - พวกเขาดูเหมือนว่าฉันจะทำให้พวกเขาขุ่นเคือง) ตอนนี้เราไม่อยู่ในฐานะที่จะให้การศึกษาแก่พวกเขาหรือโน้มน้าวให้พวกเขาใช้มัน เราแค่พยายามหาทางเลือกอื่นเพื่อให้เราได้งานทั้งหมด (ซึ่งเป็นสิ่งที่เราต้องการ) - และพวกเขาได้รับขั้นตอนการทำงานที่ง่ายและมีสมาธิกับสิ่งที่พวกเขาทำ ฉันได้ไอเดียมา ... บอกให้พวกเขาบันทึกงานของพวกเขาเป็นไฟล์แยกต่างหากทุกครั้งที่พวกเขาทำการเปลี่ยนแปลงที่ไม่สำคัญและจากนั้นใช้ diff ด้านข้างของเราเพื่อติดตามการเปลี่ยนแปลง เขียนโปรแกรม (ใน Python) ที่ใช้ "เหตุการณ์สำคัญ" ใน CSSEdit อย่างใด เกี่ยวกับโครงการ: เป็นระบบประมวลผลภาษาธรรมชาติ (เขียนด้วย C + Python) เราได้จ้างนักเขียนเพื่อเตรียมอินพุตสำหรับระบบในภาษาต่างๆ และเมื่อเราพัฒนาซอฟต์แวร์เราต้องการนักเขียนเหล่านั้นเพื่อทำการเปลี่ยนแปลงอินพุต (บทความ) บางครั้งการเปลี่ยนแปลงมีขนาดเล็กมาก (คำหนึ่งหรือสองคำ) และบางครั้งใหญ่ เหตุผลที่เราจำเป็นต้องควบคุมเวอร์ชันการเปลี่ยนแปลงเหล่านั้นก็เพราะว่าการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ / ใหญ่ในอินพุทนั้นมีศักยภาพที่จะเปลี่ยนเอาต์พุตของระบบได้อย่างมาก

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

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

7
มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะไม่ลบไฟล์ซ้ำซ้อนทันทีจาก VCS แต่ให้ทำเครื่องหมายว่า "จะถูกลบ" ด้วยความคิดเห็นก่อน?
ฉันต้องการทราบว่าวิธีจัดการกับไฟล์ต้นฉบับที่ต้องลบออกจากการควบคุมเวอร์ชันอาจถือได้ว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่ ฉันต้องการอธิบายให้คุณตามตัวอย่าง: เมื่อเร็ว ๆ นี้ฉันโกรธมากเพราะฉันต้องคัดแยกคลาส Java ในโปรแกรมที่มีรหัสตายโดยทั่วไป แต่มันไม่มีเอกสารและไม่ได้แสดงความคิดเห็นในคลาส Java เหล่านั้น แน่นอนว่าพวกเขาต้องถูกลบ แต่ก่อนที่ฉันจะลบสิ่งที่ซ้ำซ้อนฉันมี - บางคนอาจพูดว่าแปลก - นิสัย: ฉันจะไม่ลบไฟล์ที่ซ้ำซ้อนดังกล่าวทันทีผ่านทาง SVN-> ลบ (แทนที่ด้วยคำสั่งลบของระบบควบคุมเวอร์ชันที่คุณเลือก) แต่ให้ใส่ความคิดเห็นในไฟล์เหล่านั้นแทน (ฉันอ้างอิงทั้งที่หัวและท้ายกระดาษ) ว่าพวกเขากำลังจะไป ถูกลบ + ชื่อของฉัน + วันที่และ - ที่สำคัญกว่า - ทำไมพวกเขาถึงถูกลบ (ในกรณีของฉันเพราะพวกเขาตายรหัสสับสน) จากนั้นฉันบันทึกและส่งไปยังการควบคุมเวอร์ชัน ครั้งต่อไปเมื่อฉันต้องคอมมิต / เช็คอินบางอย่างในโปรเจ็กต์ถึง version control ฉันกด SVN-> Delete จากนั้นพวกมันก็จะถูกลบใน Version Control - ซึ่งแน่นอนว่ายังคงสามารถเรียกคืนผ่านการแก้ไขได้ ทำไมต้องทำเช่นนี้แทนที่จะลบออกทันที เหตุผลของฉันคือฉันต้องการมีเครื่องหมายอย่างชัดเจนอย่างน้อยที่สุดในการแก้ไขครั้งล่าสุดซึ่งมีไฟล์ที่ซ้ำซ้อนเหล่านั้นอยู่ทำไมพวกเขาจึงสมควรถูกลบ หากฉันลบทันทีพวกเขาจะถูกลบ …

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

8
ฉันควรคาดหวังให้ทีมของฉันมีความสามารถขั้นพื้นฐานมากกว่าด้วยระบบควบคุมแหล่งที่มาของเราหรือไม่?
บริษัท ของฉันเปลี่ยนจากการโค่นล้มเป็น Git เมื่อประมาณสามเดือนที่แล้ว เรามีการแจ้งล่วงหน้าหลายสัปดาห์ก่อนการเปลี่ยน เนื่องจากฉันไม่เคยใช้ Git มาก่อน (หรือ DVCS อื่น ๆ ) ฉันอ่านPro Gitและใช้เวลาเล็กน้อยหมุนที่เก็บของตัวเองและเล่นรอบ ๆ ดังนั้นเมื่อเราเปลี่ยนฉันจะสามารถทำงานด้วยความเจ็บปวดน้อยที่สุด ตอนนี้ฉันเป็น 'Git guy' โดยค่าเริ่มต้น ด้วยข้อยกเว้นบางประการทีมของฉันส่วนใหญ่ยังไม่รู้ว่า Git ทำงานอย่างไร ตัวอย่างเช่นพวกเขายังคงคิดว่ากิ่งเป็นสำเนาที่สมบูรณ์ของซอร์สโค้ดและถึงขั้นที่จะลอกแบบ repo ลงในหลาย ๆ โฟลเดอร์ (หนึ่งรายการต่อสาขา) โดยทั่วไปแล้วพวกเขามองว่า Git เป็นกล่องดำที่น่ากลัว กำหนดลักษณะพื้นฐานของการควบคุมแหล่งที่มาในการทำงานประจำวันของเรา (ไม่พูดถึงจำนวนเงินที่ไร้สาระของการใช้พลังงาน Git กำบังเรา) ผมมีความเห็นว่า dev ใด ๆ ที่ไม่ประสบความสำเร็จในระดับหนึ่งของความสามารถกับมันเป็นความรับผิด ฉันควรคาดหวังให้ทีมของฉันมีความเข้าใจอย่างน้อยเกี่ยวกับวิธีการทำงานของ Git ภายในและวิธีการใช้งานนอกเหนือจากการดำเนินการดึง / ผสาน / การกดพื้นฐานที่สุด? หรือฉันแค่ทำอะไรที่ไร้ค่า?

22
วิธีปฏิบัติที่ดีก่อนที่จะตรวจสอบในซอร์สโค้ดคืออะไร [ปิด]
ทีมของฉันใช้ Team Foundation Server สำหรับการควบคุมแหล่งที่มาและวันนี้ฉันแก้ไขข้อบกพร่องและแอปพลิเคชันทดสอบควันก่อนที่ฉันจะตรวจสอบ แต่ฉันลืมที่จะแสดงความคิดเห็นรหัสบางอย่าง (รหัสนี้ทำให้ UI แปลกเล็กน้อย) ฉันต้องการทราบวิธีปฏิบัติที่ดีก่อนที่จะตรวจสอบรหัสใน - ฉันไม่ต้องการทำผิดประเภทนี้อีกครั้ง

5
การบำรุงรักษาซอฟต์แวร์ที่แยกต่างหากสองรุ่นจาก Codebase เดียวกันในการควบคุมเวอร์ชัน
สมมติว่าฉันกำลังเขียนซอฟต์แวร์ / program / app / script รุ่นเดียวกันสองรุ่นและเก็บไว้ภายใต้การควบคุมเวอร์ชัน รุ่นแรกเป็นรุ่น "พื้นฐาน" ฟรีในขณะที่รุ่นที่สองเป็นรุ่น "พรีเมี่ยม" แบบชำระเงินซึ่งใช้รหัสฐานของรุ่นฟรีและขยายออกไปด้วยคุณสมบัติเพิ่มมูลค่าพิเศษ แพทช์แก้ไขหรือฟีเจอร์ใหม่ใด ๆ จำเป็นต้องหาวิธีแก้ไขในทั้งสองเวอร์ชัน ขณะนี้ฉันกำลังพิจารณาใช้masterและdevelopสาขาสำหรับ codebase หลัก (รุ่นฟรี) ด้านข้างmaster-premiumและdevelop-premiumสาขาสำหรับรุ่นที่จำหน่ายได้แล้ว เมื่อมีการเปลี่ยนแปลงในเวอร์ชั่นฟรีและรวมเข้ากับmasterสาขา (หลังจากการทดสอบอย่างละเอียดในdevelopหลักสูตร) ​​มันจะถูกคัดลอกไปยังdevelop-premiumสาขาผ่านcherry-pickคำสั่งสำหรับการทดสอบเพิ่มเติมแล้วรวมเข้าmaster-premiumด้วยกัน นี่เป็นเวิร์กโฟลว์ที่ดีที่สุดในการจัดการกับสถานการณ์นี้หรือไม่ มีปัญหาที่อาจเกิดขึ้นคำเตือนหรือข้อผิดพลาดที่ควรระวังหรือไม่? มีกลยุทธ์การแตกแขนงที่ดีกว่าสิ่งที่ฉันคิดไว้แล้วหรือไม่? ความคิดเห็นของคุณได้รับการชื่นชมอย่างมาก! PS นี่สำหรับสคริปต์ PHP ที่จัดเก็บใน Git แต่คำตอบควรใช้กับภาษาหรือ VCS ใด ๆ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.