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

ฉันมีการสนทนาเมื่อเร็ว ๆ นี้กับผู้คนที่ต่อต้านกลยุทธ์การปฏิเสธของฟีเจอร์บั๊กใน GIT ดูเหมือนว่าจะเป็นรูปแบบที่ได้รับการยอมรับให้ใช้ rebase เฉพาะสำหรับสาขาในพื้นที่ของเอกชน แต่ไม่เคยใช้เมื่อมีหลายคนทำงานในฟีเจอร์และสาขาเดียวกันตามที่เรียกว่า "Golden Rule of Rebasing" (เช่นอธิบายที่นี่: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview ) ฉันแค่แปลกใจที่มีมติในเรื่องนี้ ฉันทำงานเป็นเวลา 3 ปีด้วยกลยุทธ์การรีบูทเต็มรูปแบบโดยมีนักพัฒนาซอฟต์แวร์ประมาณ 20 คนที่ทำงานเพื่อหาและคาดเดาว่ามันทำงานได้อย่างไร กระบวนการนั้นเป็นพื้น: คุณสร้างสาขาฟีเจอร์ของคุณเรียกมันว่า "myfeature" และผลักมันไปที่ต้นกำเนิด / myfeature คนอื่นอาจตรวจสอบและทำงานกับมัน บางครั้งคุณอาจทำการรีบูตจากต้นแบบ: จาก "myfeature", ต้นกำเนิด git rebase / master ; จากนั้นใช่คุณต้องผลักดันมัน เกิดอะไรขึ้นเมื่อคนอื่น ๆ ต้องการที่จะผลักดันการกระทำของพวกเขา? พวกเขาเพียงแค่ rebase มัน: คอมไพล์ rebase ต้นกำเนิด / …

22 git 

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

22 version-control  git  solo-development 

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

22 git  code-reviews  branching 

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

22 version-control  git  svn 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา มีอ่านฉัน geek โค่นล้มทำไมฉันจึงควรพิจารณาหรือไม่พิจารณา Mercurial หรือ Git หรือ DVCS ฉันมีคำถามติดตามที่เกี่ยวข้อง ฉันอ่านคำถามนั้นและอ่านลิงก์และวิดีโอที่แนะนำและฉันเห็นประโยชน์ แต่ฉันไม่เห็นภาพรวมผู้คนที่กำลังพูดถึง ทีมงานของเรามีนักพัฒนา 8-10 คนที่ทำงานบนฐานรหัสขนาดใหญ่หนึ่งโครงการซึ่งประกอบด้วย 60 โครงการ เราใช้การโค่นล้มและมีลำตัวหลัก เมื่อนักพัฒนาเริ่มกรณี Fogbugz ใหม่พวกเขาสร้างสาขา svn ทำผลงานในสาขาและเมื่อพวกเขาทำเสร็จพวกเขารวมกลับไปที่ลำต้น บางครั้งพวกเขาอาจอยู่ในสาขาเป็นเวลานานและรวมลำตัวกับสาขาเพื่อรับการเปลี่ยนแปลง เมื่อฉันดู Linus พูดคุยเกี่ยวกับผู้คนที่สร้างสาขาและไม่เคยทำมันอีกครั้งนั่นไม่ใช่พวกเราเลย เราอาจสร้างสาขา 50-100 สาขาต่อสัปดาห์โดยไม่มีปัญหา ความท้าทายที่ยิ่งใหญ่ที่สุดคือการรวมกัน แต่เราก็ทำได้ดีเช่นกัน ฉันมักจะรวมกับกรณี Fogbugz & เช็คอินมากกว่ารากทั้งหมดของสาขา เราไม่เคยทำงานจากระยะไกลและเราไม่เคยแยกสาขาออกจากกัน หากคุณเป็นเพียงคนเดียวที่ทำงานในส่วนของฐานรหัสแล้วการผสานไปยังลำต้นจะราบรื่น หากมีคนอื่นแก้ไขโค้ดในส่วนเดียวกันการผสานอาจทำให้ยุ่งและคุณอาจต้องทำการผ่าตัด ความขัดแย้งเป็นความขัดแย้งฉันไม่เห็นว่าระบบใดสามารถทำให้ถูกต้องได้ตลอดเวลาเว้นแต่ว่าฉลาดพอที่จะเข้าใจรหัส หลังจากสร้างสาขาการชำระเงินไฟล์ 60k + ต่อไปนี้ใช้เวลาสักครู่ …

22 git  svn  mercurial  dvcs 

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

22 git  refactoring  branching  gitflow 

Git เก็บวัตถุ (Blobs, trees) ไว้ใน.git/objects/โฟลเดอร์ แต่ละวัตถุสามารถอ้างอิงได้โดยแฮช SHA1 ที่คำนวณจากเนื้อหาของวัตถุ อย่างไรก็ตามวัตถุจะไม่ถูกเก็บไว้ใน.git/objects/โฟลเดอร์โดยตรง แต่ละวัตถุจะถูกเก็บไว้ในโฟลเดอร์ที่ขึ้นต้นด้วยคำนำหน้าของแฮช SHA1 ดังนั้นวัตถุที่มีแฮชb7e23ec29af22b0b4e41da31e868d57226121c84จะถูกเก็บไว้ที่.git/objects/b7/e23ec29af22b0b4e41da31e868d57226121c84 เหตุใด Git จึงแบ่งการจัดเก็บวัตถุด้วยวิธีนี้ ทรัพยากรที่ฉันสามารถหาเช่นหน้า internals Git ของใน Git-SCM, เท่านั้นอธิบายวิธีการที่ไม่ว่าทำไม

21 git  hashing  file-systems 

โครงการของเรามีขนาดประมาณ 11GB, 10 แห่งเป็นข้อมูลไบนารี่ (.png ภาพ) ดังนั้นการดำเนินการgit diffหรือgit statusใช้เวลานานกว่าหนึ่งนาที dataโชคดีที่ไฟล์ข้อมูลทั้งหมดจะถูกแยกออกไปไว้ในโฟลเดอร์ที่มีชื่อที่ยอดเยี่ยม การมอบหมายคือ "หลีกเลี่ยงการบีบอัดการกระจายและการดำเนินการอื่น ๆ ที่มีราคาแพงในไฟล์ไบนารี" ถือว่าเป็นการแยกโครงการออกเป็นสอง repos จากนั้นdataจะเป็น repo ภายนอกที่ถูกตรวจสอบโดย repo ซอร์สโค้ดหลัก มีการตัดสินใจแล้วว่าค่าใช้จ่ายในการรักษา repos นั้นจะมากเกินไปโดยเฉพาะอย่างยิ่งสำหรับศิลปินที่ทำงานกับไฟล์ข้อมูล อย่างชัดเจนบอกคอมไพล์ไฟล์เหล่านั้นเป็นไบนารี , ไม่รวมไฟล์จาก diffsได้รับการพิจารณา แต่ผู้ที่ดูเหมือนเพียงบางส่วนเพื่อแก้คำถาม ฉันรู้สึกว่าคุณลักษณะคอมไพล์เป็นวิธีแก้ปัญหา แต่อย่างไร หรือมีสถาปัตยกรรมที่ดีกว่า repo เสาหิน?

21 git  binary 

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

21 git  github 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา เราเป็นทีมเล็ก ๆ ของนักพัฒนาเว็บที่ใช้การโค่นล้ม แต่ในไม่ช้าเรากำลังเปลี่ยนไปใช้ GitHub ฉันกำลังดูเวิร์กโฟลว์ Github ประเภทต่างๆและเราไม่แน่ใจว่าแนวคิดการฟอร์กทั้งหมดใน GitHub สำหรับนักพัฒนาแต่ละคนนั้นเป็นความคิดที่ดีสำหรับเราหรือไม่ หากเราใช้ส้อมฉันเข้าใจว่านักพัฒนาแต่ละคนจะมีที่เก็บข้อมูลระยะไกลและพื้นที่ส่วนตัวของเขาเอง ฉันกังวลว่ามันจะทำการผลักดันการเปลี่ยนแปลงอย่างหนักและซับซ้อนเกินไป นอกจากนี้ความกังวลที่ใหญ่ที่สุดของฉันคือมันจะบังคับให้นักพัฒนาแต่ละคนมี 2 รีโมท: กำเนิด (ซึ่งเป็นทางแยกระยะไกล) และอัปสตรีม (ซึ่งใช้ในการ "ซิงค์" การเปลี่ยนแปลงจากพื้นที่เก็บข้อมูลหลัก) ไม่แน่ใจว่ามันเป็นวิธีง่าย ๆ ในการทำสิ่งต่าง ๆ หรือไม่ สิ่งนี้คล้ายกับเวิร์กโฟลว์ที่อธิบายไว้ที่นี่: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow ถ้าเราไม่ใช้ส้อมเราอาจจะทำได้ดีโดยใช้ repo ส่วนกลางที่สร้างสาขาสำหรับแต่ละงานที่เรากำลังทำอยู่และรวมมันเข้าไปในสาขาการพัฒนาบนพื้นที่เก็บข้อมูลเดียวกัน หมายความว่าเราจะไม่สามารถ จำกัด การรวมสาขาและอาจยุ่งเล็กน้อยที่จะมีสาขาจำนวนมากในพื้นที่เก็บข้อมูลส่วนกลาง มีคำแนะนำใดบ้างจากทีมที่ลองใช้ทั้งสองขั้นตอน?

21 git  github 

Git library ใดที่ดีที่สุดใน Ruby ที่จะใช้ Git, Grit, Rugged, Other? ความเป็นมา: ฉันเป็นผู้ดูแลปัจจุบันของTicGit-ngซึ่งเป็นระบบจำหน่ายตั๋วออฟไลน์ที่สร้างขึ้นบน git และฉันได้อ่านและได้ยินซ้ำแล้วซ้ำอีกว่า Grit เป็นสิ่งที่ฉันควรใช้เพราะมันแทนที่อัญมณี Git แต่ ดูเหมือนว่าจะไม่มีเอกสารหรือขาดคุณสมบัติเนื่องจากตัวฉันและคนอื่น ๆ ล้มเหลวในการพยายามเปลี่ยนจาก Git ที่เลิกใช้แล้ว แต่ใช้งานได้ไปเป็นอัญมณี Grit รุ่นใหม่

21 ruby  git 

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

21 git  code-reviews 

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

20 git  github  gitflow 

เมื่อทำงานกับคอมไพล์ในทีมที่ใช้ฟีเจอร์บรานช์ฉันมักจะพบว่ามันยากที่จะเข้าใจโครงสร้างสาขาในประวัติศาสตร์ ตัวอย่าง: สมมติว่ามีฟีเจอร์ branch / make-coffeeฟีเจอร์และการแก้ไขข้อผิดพลาดยังคงดำเนินต่อไปบนมาสเตอร์ขนานกับฟีเจอร์ branch ประวัติอาจมีลักษณะเช่นนี้: * merge feature/make-coffee |\ | * small bugfix | | * | fix bug #1234 | | | * add milk and sugar | | * | improve comments | | * | fix bug #9434 | | | * make coffe …

20 git  branching 

ฉันอยู่ในขั้นตอนการตั้งค่าบัญชี GitHub โดยมีแผนที่จะสร้างห้องสมุดคู่หนึ่งที่ฉันพัฒนาขึ้นเพื่อเป็นส่วนหนึ่งของโครงการ iOS ล่าสุดบางโครงการที่สามารถใช้งานได้ฟรีสำหรับผู้พัฒนา iOS คนอื่น ๆ ปัจจุบันฉันไม่มีการสำรองข้อมูลนอกสถานที่สำหรับรหัสส่วนใหญ่ของฉันดังนั้นในตอนแรกฉันคิดว่าฉันจะอัปโหลดโครงการส่วนตัวทั้งหมดของฉันหรืออย่างน้อยโครงการ iOS ทั้งหมดของฉันไปยังที่เก็บส่วนตัวที่โฮสต์โดย GitHub . แต่ฉันมีจำนวนมากของโครงการนั่งรอบหลายแห่งซึ่งเป็นธรรมที่มีมูลค่าต่ำ (เช่นดัดแปลงมาจากหนังสือและเขียนขึ้นสำหรับประสบการณ์การเรียนรู้) GitHub ไม่เพียงเรียกเก็บจากที่เก็บข้อมูลส่วนตัว แต่ดูเหมือนว่าจะไม่มีวิธีการจัดระเบียบที่เก็บตามลำดับชั้น มีบางอย่างที่ฉันขาดหายไปซึ่งจะทำให้ฉันสามารถใช้พื้นที่เก็บข้อมูล git กับลำดับชั้นและตรวจสอบชิ้นส่วนตามที่ฉันต้องการ / ทำงานกับพวกเขาวิธีที่ฉันทำกับ SVN ในปัจจุบัน? GitHub (หรือคู่แข่งเช่น BitBucket) มีคุณสมบัติบางอย่างขององค์กรโครงการที่ฉันขาดหายไปหรือไม่? หากไม่เป็นเช่นนั้น "วิธี Git" ที่เป็นที่ยอมรับโดยทั่วไปในการจัดการกับสถานการณ์นี้ (ยกเลิกโครงการที่ไม่ได้มีไว้สำหรับเผยแพร่ให้เก็บออฟไลน์รวมพวกมันเข้าด้วยกัน ฯลฯ )? เท่าที่ฉันสามารถบอกได้ตัวเลือกของฉันคือ: ใส่ไลบรารี่บน GitHub แล้วดำเนินการโฮสต์ SVN ของฉันต่อไปสำหรับโครงการอื่น ๆ ทั้งหมดใช้โซลูชันที่ไม่ใช่ VCS สำหรับการสำรองข้อมูลนอกไซต์ (blech) ใส่ไลบรารีและซอฟต์แวร์ที่ฉันวางแผนจะวางจำหน่ายบน GitHub (ในฐานะที่เป็นรัฐและเอกชนตามลำดับ) …

20 version-control  git  github