คำถามติดแท็ก git

หมายเหตุ: คำถามของฉันมุ่งเน้นที่ปัญหาเฉพาะของฉัน (ซึ่งเกี่ยวข้องกับ Liferay) แต่ฉันหวังว่ามันจะมีประโยชน์สำหรับทุกคนที่ต้องการบำรุงรักษาโครงการเดียวกันในคอมไพล์รุ่นต่างๆ ผมทำงานใน บริษัท ที่เขียนจำนวนมากของปลั๊กอินสำหรับLiferay พอร์ทัล ปลั๊กอินเหล่านี้ (พอร์ตเล็ต, ธีม ฯลฯ ) โดยปกติจะสามารถใช้ซ้ำได้และแน่นอนควรได้รับการอัปเดตสำหรับพอร์ทัลเวอร์ชันใหม่ อย่างไรก็ตามเป็นเรื่องปกติที่จะต้องย้ายข้อมูลให้เราบอกว่าพอร์ตเล็ตเป็นเวอร์ชันใหม่ของ Liferay และเพื่อรักษาเวอร์ชันก่อนหน้า นอกจากนี้บ่อยครั้งที่เราต้องสร้างการปรับแต่งที่เฉพาะเจาะจงมากสำหรับลูกค้าบางรายซึ่งไม่สมเหตุสมผลที่จะเพิ่มใน "เวอร์ชันหลัก" ข้อกำหนดเหล่านี้ทำให้งานของเราซับซ้อน แต่โชคดีที่เราสามารถสันนิษฐานได้ว่ามีความเรียบง่าย ตัวอย่างเช่นปลั๊กอินมีการอัปเดตบ่อยครั้งโดยโปรแกรมเมอร์เพียงหนึ่งคนในแต่ละครั้ง มันเป็นเรื่องยากมากที่จะมีการเพิ่มคุณสมบัติสองอย่างขึ้นไปในปลั๊กอินในเวลาเดียวกัน ขณะนี้เรากำลังย้ายไปGitorious เราพยายามที่จะเข้าใจรูปแบบการแตกแขนงสำหรับสถานการณ์ดังกล่าว โมเดลของฉัน สิ่งที่ฉันเสนอคือ: แต่ละปลั๊กอินจะมีพื้นที่เก็บข้อมูลของตัวเองใน Gitorious ภายในโครงการ ตัวอย่างเช่นพอร์ตเล็ตสำหรับแสดงลูกแมวจะมีkittens-portletพื้นที่เก็บข้อมูลภายในliferay-portletsโครงการ เมื่อสร้างปลั๊กอินใหม่ให้สร้างขึ้นที่สาขาที่มีชื่อตามเวอร์ชัน Liferay (ตัวอย่างเช่นlf5.2) ทุกครั้งที่มีการปรับปรุงจะทำบนปลั๊กอิน, อัพเดทได้รับการอนุมัติและนำไปใช้ในการผลิต, การติดแท็กปลั๊กอินที่มีรุ่น (ตัวอย่างเช่นlf5.2v1, lf5.2v2ฯลฯ .) * ทุกครั้งที่มีการย้ายปลั๊กอินไปยัง Liferay เวอร์ชันใหม่เราจะทำการแยกสาขาเวอร์ชันล่าสุด (การสร้างเช่นสาขาlf6.0) lf6.0v1เมื่อในการผลิตหัวของสาขาใหม่จะได้รับแท็กเช่น ทุกครั้งที่เราต้องปรับแต่งปลั๊กอินในแบบเฉพาะลูกค้าเราสร้างสาขาที่มีชื่อลูกค้า (ตัวอย่างเช่นเราจะสร้างสาขาlf5.2clientcorpสำหรับลูกค้าของเรา "ClientCorp …

13 version-control  git  branching 

ฉันพยายามที่จะใช้เวลาให้มากที่สุดเท่าที่จะทำได้ในGitHubทุกวันนี้(แม้ฉันจะเป็นคนเดียวในทีมที่ทำงาน)ก็รู้สึกได้ว่ามันจะเป็นอย่างไรสำหรับแอพพลิเคชั่นขององค์กรในโลกแห่งความเป็นจริง หนึ่งคำถามที่ฉันมีคือการควบคุมรุ่น สมมติว่าเราเริ่มโครงการ จากนั้นสมาชิกในทีมสร้างสาขาและพัฒนาที่นั่น เมื่อเราพร้อมสำหรับการผลิตเรารวมสาขาทั้งหมดกับmasterสาขา 1.0ในตอนท้ายเราไปอยู่กับรุ่น ตอนนี้เวอร์ชัน1.0นั้นเผยแพร่แล้วและเรามีปัญหาบางอย่างที่ยื่นสำหรับเวอร์ชันของซอฟต์แวร์นั้น เราต้องการเริ่มพัฒนาเวอร์ชัน1.1เพื่อแก้ไขปัญหาเหล่านั้นที่เราได้แนะนำโดยเร่งโครงการ ตอนนี้คำถามคือ: เราจะควบคุมการควบคุมเวอร์ชันได้อย่างไร? เราควรจะสร้างสาขาใหม่v1.0และเก็บรุ่น1.0ของซอฟต์แวร์ไว้ที่นั่นและพัฒนาในบางสาขา (หรือไม่) รวมเข้าด้วยmasterกันใช้งานกับเวอร์ชัน1.1หรือไม่ มีการประชุมที่นั่นสำหรับสถานการณ์แบบนั้นเหรอ?

13 project-management  git  github  svn 

ที่เกี่ยวข้อง: คอมไพล์ทุกคนควรออกจากโครงการในสถานะการทำงานหรือไม่ สมมติว่าฉันทำสิ่งต่อไปนี้ในพื้นที่: ปรับเปลี่ยนสกีมาฐานข้อมูลทำให้แอปพลิเคชันหยุดทำงาน อัปเดตแอปพลิเคชันเพื่อให้เข้ากันได้กับสคีมาฐานข้อมูลอีกครั้ง ตราบใดที่ฉันผลักทั้งสองกระทำmasterยังคงอยู่ในสภาพการทำงาน อย่างไรก็ตามเวอร์ชันทางประวัติศาสตร์เสีย ฉันรู้ว่าฉันสามารถใช้git rebase -iในการสควอชคอมมิชชันด้วยกัน อย่างไรก็ตามการกระทำที่เกิดขึ้นจะมีขนาดใหญ่และอธิบายน้อยกว่า หากฉันต้องการค้นหาประวัติการส่งมอบเพื่อหาสาเหตุที่ฉันเปลี่ยนบางสิ่งบางอย่างฉันควรค้นหาคำสั่งดั้งเดิมที่แสดงสิ่งที่ฉันทำและทำไม คำถามของฉันคือ: มีใครประสบปัญหาบ้างหรือไม่เนื่องจากความผูกพันทางประวัติศาสตร์ที่แตกสลายในเจ้านาย? ถ้าเป็นเช่นนั้นมีวิธีง่ายๆในการหลีกเลี่ยงปัญหาดังกล่าวหรือไม่โดยไม่ละทิ้งบุคคลที่ส่งข้อความและเปลี่ยนแปลง?

13 git  dvcs 

ปัจจุบัน บริษัท ของฉันมี Visual Studio solation ใน repo SVN ที่จัดเป็นดังนี้: SolutionFolder (~3.5 GB) |-> SolutionName.sln |-> .. Some source code folders... (~250 MB) |-> ThirdParty (~3 GB) |-> Tools | -> Tool1 | -> Tool2 Tool1 และ Tool2 เป็นบิลด์อิสระ (มีโซลูชันของตัวเอง) แต่สร้างไฟล์ปฏิบัติการที่ใช้ในบิลด์หลัก โฟลเดอร์ ThirdParty มีการขึ้นต่อกันทั้งหมดของโครงการรวมถึงไฟล์. lib ขนาด 100+ MB ที่รวบรวมไว้ล่วงหน้าและไลบรารี่ขนาดใหญ่เช่นบูสต์ มันสะดวกที่จะมีทุกอย่างใน …

13 version-control  git 

ดังนั้นจินตนาการต่อไปนี้เกิดขึ้น (และเราทุกคนใช้ SourceTree): พวกเราทุกคนล้วนทำงานจากแหล่งกำเนิด / พัฒนา ฉันไปพักผ่อนวันหยุดเป็นเวลาหนึ่งสัปดาห์ เพื่อนร่วมงานของฉันทำงานในพื้นที่หลายวันที่ผ่านมาโดยไม่ต้องผสานแหล่งกำเนิด / พัฒนากลับไปที่สาขาพัฒนาท้องถิ่นของเขา เขาพยายามที่จะผลักดันได้รับการบอกว่าเขาจะต้องรวมก่อนแล้วจึงดึง เขาได้รับความขัดแย้งหยุดการคอมมิทอัตโนมัติหลังจากดำเนินการต่อ สมมติว่า Git เป็นเหมือน SVN เพื่อนร่วมงานของฉันจะทิ้งไฟล์ "ใหม่" ในสำเนาการทำงานของเขาและจากนั้นคอมมิวนิตี้ผสาน - เช็ดไฟล์ "ใหม่" เหล่านั้นจากหัวต้นทาง / พัฒนา การทำงานสัปดาห์ที่มีค่าของการพัฒนาดำเนินต่อไป ฉันกลับมาจากวันหยุดและพบว่างานของฉันหายไปหลายวัน พวกเราทุกคนใหม่มากสำหรับ Git (นี่เป็นโครงการแรกของเราที่ใช้มัน) แต่สิ่งที่ฉันทำเพื่อแก้ไขคือ: เปลี่ยนชื่อ "พัฒนา" เป็น "develop_old" ผสาน develop_old เข้ากับสาขาใหม่ "develop_new" รีเซ็ตสาขา develop_new เป็นคอมมิชชันล่าสุดก่อนการผสานที่ไม่ดี เชอร์รี่เลือกแต่ละการกระทำตั้งแต่นั้นมาแก้ไขความขัดแย้งด้วยตนเอง กด develop_old และ develop_new ไปยังจุดเริ่มต้น เมื่อถึงจุดนี้ develop_new …

13 git 

โดยปกติเมื่อฉันเขียนโปรแกรมฉันมีงานที่ชัดเจนก่อนหน้าฉัน แต่พบสิ่งที่น่ารำคาญที่ฉันต้องการทำความสะอาดเมื่อฉันไป ที่นี่ฉันเห็นสามตัวเลือก: ทำในภายหลัง (อาจลืม / ต้องใช้เวลาในการเพิ่มตั๋ว) ทำทันทีและส่งมอบงานของฉันในปัจจุบัน (ไม่ชัดเจน) ทำทันทีและกระทำแยกต่างหาก (ต้องค้นหาอาจทำผิดพลาดและไปที่ตัวเลือก # 2 โดยไม่ได้ตั้งใจ) นี่อาจเป็นพื้นฐานค่อนข้าง แต่มีวิธีใดบ้างที่จะหลีกเลี่ยงสิ่งนี้โดยใช้ svn / git / other?

12 version-control  git  svn  workflows 

ขณะนี้เราอยู่ในสถานการณ์ต่อไปนี้ที่สาขาฟีเจอร์ได้รับการแยกสาขาสำหรับฟีเจอร์ย่อย (เช่นทำงานบนแบ็กเอนด์และส่วนหน้าสำหรับฟีเจอร์เดียวกัน): o | o development |\ | o feature-a | | | o | |\ | | o feature-a-sub | | | | | | | \ | o merged feature-a into feature-a-sub | / o feature-a-sub merged into development | | | o feature-a with future work on …

12 git  branching 

นานมาแล้วทีมเล็ก ๆ ของนักพัฒนาเว็บที่ฉันทำงานด้วยเริ่มใช้ git เพื่อการพัฒนาเว็บ ย้อนกลับไปเราเพิ่งมุ่งมั่นที่จะจัดเตรียมหรือเป็นผู้เชี่ยวชาญโดยตรงจากนั้นจึงรวมเข้าด้วยกันระหว่างสองรายการนี้บ่อยครั้ง มันดีกว่าไม่มีอะไร แต่มันก็เป็นระเบียบ เมื่อไม่นานมานี้เราได้นำขั้นตอนการทำงานของ gitflow มาใช้ ในขณะที่มันดีกว่าความสับสนวุ่นวายที่เกิดขึ้นก่อนหน้านี้ดูเหมือนว่าจะค่อนข้างยุ่งยากและปล่อยวาง / เหตุการณ์สำคัญมากเกินไป เพื่อน devs ของฉันมักจะขอให้ฉันชี้แจงว่ามันควรจะทำงานอย่างไรและสิ่งที่ควรผสานและไม่ควร โดยทั่วไปดูเหมือนว่าจะไม่เหมาะสมสำหรับงานพัฒนาเว็บไซต์ที่เรากำลังปรับใช้โค้ดบ่อยครั้งและไม่มีการติดตามเหตุการณ์สำคัญที่เฉพาะเจาะจงสำหรับการเปิดตัว เกี่ยวกับข้อเสนอแนะที่ผ่านมาเพื่อนผมได้เริ่มมองหาที่GitHub ไหล การอ่านโพสต์ของสก็อตต์ชาคอนตรงจุดปวดอย่างสมบูรณ์แบบด้วยสิ่งนี้: ดังนั้นทำไมเราไม่ใช้ git-flow ที่ GitHub? ปัญหาหลักคือเราปรับใช้ตลอดเวลา กระบวนการ git-flow นั้นถูกออกแบบมาเพื่อ“ ปล่อย” เราไม่มี“ รีลีส” เพราะเราปรับใช้กับการผลิตทุกวัน - บ่อยครั้งต่อวัน FWIW ฉันได้ดูที่เวิร์กโฟลว์รอบนี้บนเว็บไซต์ของ Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch อย่างไรก็ตามพวกเขาดูเหมือนตัวเลือกที่ไม่ดีสำหรับการพัฒนาเว็บในทีมเล็ก ๆ และมุ่งเน้นไปที่การเผยแพร่แอปพลิเคชันที่สำคัญไม่ใช่การเผยแพร่ประจำวัน เป็นคำถามเกี่ยวกับ SE ที่ขอให้เปรียบเทียบ git-flow กับ github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -ไหล …

12 web-development  git  gitflow 

ฉันกำลังตั้งค่าเซิร์ฟเวอร์ GitLab ใน บริษัท ของฉันและตอนนี้ฉันกำลังเพิ่ม GitLab CI ลงไป ก่อนที่จะเริ่มงานนี้ฉันต้องการที่จะเข้าใจว่ามีข้อเสียใด ๆ ที่รันนักวิ่งของฉันบนเซิร์ฟเวอร์เดียวกับที่ใช้โดย GitLab และ GitLab CI ฉันอ่านว่ามีข้อกังวลด้านความปลอดภัย แต่เราใช้ภายในเท่านั้นดังนั้นฉันจึงไม่คิดว่านี่จะเป็นปัญหา ฉันพลาดอะไรไปรึเปล่า?

12 git  continuous-integration  gitlab 

เพื่อนร่วมงานและฉันได้ผลัดกันโต้วาที / อภิปรายปัญหา / ข้อดีของการรวมรุ่นที่ได้มาจากที่เก็บ git ปัจจุบันในรหัสของเราเมื่อใดก็ตามที่มันสร้าง เราคิดว่าข้อดีคือ: ไม่จำเป็นต้องกังวลเกี่ยวกับข้อผิดพลาดของมนุษย์ในการอัปเดตหมายเลขเวอร์ชัน การตรวจสอบย้อนกลับระหว่างสิ่งที่เราพบในอุปกรณ์และซอร์สโค้ดที่ได้มาจาก ปัญหาที่เกิดขึ้น (สำหรับเรา) รวมถึง: ระบบสร้าง IDE ที่ได้รับ (เช่น MPLABX) สามารถทำให้ยากที่จะทราบว่าจะใส่ hooks ประเภทนี้ไว้ในที่ใด (และมันสามารถจบลงด้วยการทำวิเศษสุด ๆ ในตอนท้าย) ทำงานได้มากขึ้นในการรวมสิ่งนี้เข้ากับ build สคริปต์ / makefiles การเชื่อมต่อกับแนวทางการสร้างเฉพาะ (เช่นถ้าบุคคลหนึ่งสร้างด้วย XCode และ MPLABX อื่น ๆ ) อาจสร้างความประหลาดใจแบบดาวน์สตรีม ดังนั้นเราอยากรู้ว่าที่คนอื่นมีที่ดินในการอภิปรายนี้ มันง่ายมากที่การอภิปรายจะกลายเป็นเรื่องเล็ก มีผู้คนมากมายที่ยืนหยัดในระบบอัตโนมัติตั้งแต่ต้นจนจบแขวนจำนวนงานที่ต้องทำล่วงหน้าและการมีเพศสัมพันธ์ที่สร้างขึ้น และมีอีกหลายคนที่อยู่อีกด้านหนึ่งของการถกเถียงซึ่งเพิ่งทำสิ่งที่ง่ายที่สุดที่ทำงานและอยู่กับความเสี่ยง มีคำตอบที่ให้เหตุผลที่ดีที่สุดที่จะลงจอดบน?

12 c  git  builds  build-system 

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

12 git  branching 

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

12 project-management  programming-practices  version-control  git  workflows 

เป็นวิธีที่ต้องการทำต่อไปนี้ด้วยคอมไพล์ maven และเจนกินส์คืออะไร: ฉันกำลังพัฒนาแอปพลิเคชันซึ่งฉันต้องการรักษาสาขา "dev" และ "release" ฉันต้องการเจนกินส์เพื่อสร้างทั้งสอง อาจเป็นไปได้ว่าการเผยแพร่สิ่งประดิษฐ์จะมีรุ่นเช่น 1.5.2 และ dev-builds จะเป็น 0.0.1-SNAPSHOTs ฉันไม่ต้องการไฟล์ pom.xml 2 ไฟล์ ฉันดูโปรไฟล์ แต่ดูเหมือนว่าพวกเขาจะไม่สามารถเปลี่ยนเวอร์ชันสิ่งประดิษฐ์ได้ วิธีหนึ่งที่ฉันสามารถดูได้คือการเพิ่ม 'ตัวระบุ' ลงในการทดสอบสร้าง แน่นอนฉันสามารถเปลี่ยนชื่อไฟล์ได้เนื่องจากข้อมูลสิ่งประดิษฐ์จริงในเรื่องนี้ไม่สำคัญเพราะแอปเป็นแบบสแตนด์อโลน สิ่งที่จะเป็นวิธีที่ต้องการในการทำเช่นนี้? หรือคุณจะทำอย่างไร

12 git  workflows  versioning  jenkins  maven 

เรามีครอบครัวของแอพทั้งหมดมีฐานเดียวกัน จนถึงตอนนี้ฉันได้พัฒนาฐานนี้และเวิร์กโฟลว์ Git นั้นง่ายมาก: การพัฒนาจะทำในdevelopสาขา คุณสมบัติใหม่ได้รับการพัฒนาในname-of-the-featureสาขา การเผยแพร่จะทำในrelease-**สาขา จนถึงขณะนี้รหัสยังคงเหมือนเดิมสำหรับทุกแอปในตระกูล สมมติว่าฐานที่พวกเขาแชร์เสร็จสมบูรณ์แล้วและจากนี้ไปโค้ดจะแตกต่างกันไปสำหรับแอพทุกตัว ฉันไม่แน่ใจว่าฉันจะจัดการกับคอมไพล์ได้อย่างไรและแอพหลายตัวที่มีฐานเดียวกัน แต่ละคนควรมีโครงการคอมไพล์ของตัวเองหรือไม่? พวกเขาควรจะอยู่ในโครงการเดียวกัน แต่แต่ละคนในสาขาของตัวเอง ? ประเด็นก็คือ: ถ้าฉันวางมันลงในโครงการที่แยกต่างหากการดัดแปลงทุกอย่างที่ทำในฐานของแอพจะต้องทำซ้ำกับฉันในแต่ละแอพ ฉันไม่คุ้นเคยกับgitมาก แต่ถ้าฉันเก็บแต่ละโครงการไว้ในสาขาคุณจะสามารถผสานการดัดแปลงพื้นฐานกับแต่ละแอพได้หรือไม่ มีใครเคยประสบสถานการณ์เช่นนี้บ้างไหม? ฉันไม่แน่ใจว่าจะดำเนินการต่อไปอย่างไร ขอบคุณ! แก้ไข เมื่อฉันพูดรุ่นฉันไม่ได้หมายความว่าเหมือนหมายเลขรุ่น จริงๆแล้วมันเป็นแอพที่แตกต่างกันที่ใช้ฐานเดียวกัน

12 git 

จากความเข้าใจของฉัน SVN คือ 'ง่ายต่อการแตกสาขา ยากที่จะรวม ' ทำไมถึงเป็นอย่างนั้น? มีวิธีแตกต่างกันอย่างไร?

12 git  svn  mercurial  dvcs