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

บริบท ทีมงานวิศวกร 8 คนของฉันกำลังเปลี่ยนไปใช้ Git (จากการโค่นล้ม) สำหรับเรื่องใหญ่ต่อไปของเรา เรามีวิศวกรที่มีประสบการณ์มากขึ้นและพบว่ามันยากที่จะรับ Git ฉันถูกถามคำถามเล็กน้อยเหมือนกันทั้งๆที่มีคู่มือผู้ใช้กิจกรรมการฝึกอบรมและการประชุมไวท์บอร์ด เรามีที่ปรึกษาจูเนียร์สองคนที่หยิบทุกอย่างขึ้นมาภายในสองสามวันและมันส่องแสงในประเด็น นี่ไม่ใช่รูปแบบที่ จำกัด อยู่ที่ Git แต่เป็นผลให้มองเห็นได้ คำถาม ฉันไม่รู้สึกว่าเป็นประโยชน์กับวิศวกรที่ไม่สามารถ / ไม่เรียนรู้โดยเฉพาะอย่างยิ่งพนักงานที่มีระดับอาวุโสที่เรามีที่นี่ อย่างไรก็ตามฉันต้องการให้ทีมประสบความสำเร็จและสร้างผลิตภัณฑ์ที่ยอดเยี่ยม เราใช้แบบจำลอง Git Flow ที่ส่วนกลางและฉันรู้สึกว่าคำศัพท์ใหม่ทั้งหมดทำให้พวกเขางงงัน ฉันสามารถทำอะไรได้บ้างเพื่อช่วยให้พนักงานเหล่านี้เรียนรู้ Git? Sourcetreeเป็นลูกค้าที่ใช้งานโดยทีมงานทั้งหมด

68 git  gitflow 

เมื่อเร็ว ๆ นี้เรามีปัญหาซึ่งคุณสมบัติสำหรับ webapp ของเรา (การลงทะเบียนอัตโนมัติ) ถูกเลื่อนออกไปโดยผู้บริหารเพราะพวกเขารู้สึกว่าการเริ่มต้นนั้น "หนาว" เกินไป แต่พวกเขาต้องการคุณสมบัติอื่น ๆ ทั้งหมดที่เรากำลังทำอยู่ ปัญหาคือฟังก์ชั่นนี้ได้รับการผสานเข้ากับการพัฒนาเมื่อเสร็จสิ้นพร้อมกับคุณสมบัติอื่น ๆ ทั้งหมดที่เราคาดว่าจะมีการถ่ายทอดสดในรุ่นถัดไปดังนั้นเราจึงไม่สามารถผสาน dev -> test -> master เหมือนที่เราทำ เราจะหลีกเลี่ยงปัญหานี้ได้อย่างไร?

53 project-management  git  gitflow 

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

43 code-quality  git  code-reviews  github  gitflow 

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

30 git  workflows  branching  gitflow 

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

25 version-control  git  gitflow 

เราเป็นทีมใหญ่ (นักพัฒนา 10-12 คนและ 4 คน) ทำงานหลายโครงการด้วยที่เก็บ git เดียวกัน มันเป็นบริการเว็บแบ็กเอนด์ในฤดูใบไม้ผลิตาม เรากำลังมองหาการแยกทางและใช้กลยุทธ์ที่ดี นอกจากนี้เรายังมีทีมงาน qa ที่ทำให้มั่นใจว่าคุณสมบัติของเราทำงานได้ตามที่คาดไว้ (ปราศจากข้อบกพร่องในระดับหนึ่ง) หลังจากอ่านบทความไม่กี่ฉันรู้สึกว่าแบบจำลองGitflowทำงานได้ดีสำหรับเรา ที่นี่คำถามของฉันมา ทีม QA ของเราควรทดสอบคุณสมบัติของเราที่ไหน? พวกเขาควรทดสอบสาขาคุณลักษณะที่พวกเขาจะเพิ่มข้อผิดพลาดและนักพัฒนาจะแก้ไขและเมื่อผ่านการทดสอบ QA เรารวมการพัฒนา และ QA จะทำการทดสอบจำนวนเต็มอีกครั้งในสาขาที่กำลังพัฒนา เราควรรวมคุณสมบัติทั้งหมด (หลังการทดสอบหน่วยและการทดสอบพื้นฐานจากผู้พัฒนา) เพื่อพัฒนาสาขาและให้ทดสอบ qa จากที่นั่น การแก้ไขและการทดสอบทั้งหมดจะเกิดขึ้นในการพัฒนาเช่นกัน ฉันอยากรู้ว่าวิธีการใดที่ทำงานได้ดีสำหรับผู้อื่น

23 testing  git  branching  qa  gitflow 

เราใช้GitHub ไหลในโครงการของเราและส่วนใหญ่เวลาที่เราเปิดสาขาคุณลักษณะใหม่จากต้นแบบ , ทำงานบางอย่างมีเปิด PR ตรวจสอบรหัสและการผสานกลับเข้าไปในต้นแบบ feature-branch-Aแต่การทำงานในปัจจุบันของฉันขึ้นอยู่กับปัญหาที่กำลังทำงานอยู่ในการควบคุม มันเป็นโคเชอร์ที่จะสร้างสาขาของฉันจากสาขาอื่นหรือต่อต้านวิญญาณของ GitHub Flow หรือไม่? ทางเลือกอื่นคือการยึดสาขาของฉันไว้ที่หลักและผสานการเปลี่ยนแปลงจากfeature-branch-A(บ่อยครั้ง) ต้องการตัวเลือกใดในโฟลว์ GitHub?

22 git  github  gitflow 

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

22 git  refactoring  branching  gitflow 

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

20 git  github  gitflow 

ผมมีโครงการที่มีการแตกแขนงคอมไพล์รูปแบบที่ประมาณดังนี้ว่าnvie ของคอมไพล์ไหล สาขาที่วางจำหน่ายของเรามีชื่ออยู่ในรูปแบบของSemVerเช่นv1.5.2 เมื่อสาขาย่อยได้รับไฟสีเขียวเพื่อการผลิตเราจะปิดสาขาโดยรวมมันเข้ากับต้นแบบใช้แท็กแล้วลบสาขา เมื่อเราลบสาขาที่วางจำหน่ายทันทีเราได้ใช้ตัวระบุเดียวกันสำหรับการติดแท็กสาขาเช่น v1.5.2 นี่คือคำสั่งที่เราใช้ปิดสาขาที่วางจำหน่าย: $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags …

20 version-control  git  branching  gitflow 

เราเป็นองค์กรที่ประกอบด้วยนักพัฒนาประมาณ 200 คนที่ทำงานอย่างต่อเนื่องในผลิตภัณฑ์เดียว (ใช้ Git revision control) ซึ่งมีการวางแผนที่จะวางจำหน่ายในวันที่กำหนด เนื่องจากนักพัฒนาจำนวนมากเรากำลังพยายามสร้างทีม "ข้ามหน้าที่" ที่มีนักพัฒนาประมาณ 10 คนในแต่ละทีมส่งผลให้มีทีมพัฒนาประมาณ 20 ทีมในองค์กร เนื่องจากเราต้องการรักษา "มาตรฐานสูง" อย่างต่อเนื่อง (หมายถึงเมื่อนักพัฒนาทำการดึงผลิตภัณฑ์อย่างน้อยควรจะสามารถคอมไพล์ได้ ฯลฯ ) ของผลิตภัณฑ์ในที่เก็บหลักเราจึงต้องการใช้ประตูคุณภาพบางประเภท ฉันไม่แน่ใจว่าจะตอบคำถามได้อย่างไร แต่ฉันสงสัยว่าฉันจะได้รับคำแนะนำเกี่ยวกับวิธีการพัฒนาสำหรับกลุ่มนักพัฒนาขนาดใหญ่เช่นนั้นที่ทำงานกับผลิตภัณฑ์เดียวหรือไม่ ในความเห็นของเราปลายด้านหนึ่งของสเปกตรัมคือการอนุญาตให้นักพัฒนาแต่ละคนส่งโดยตรงไปยังแหล่งเก็บข้อมูลหลักอย่างไรก็ตามเรากลัวว่าเนื่องจากผู้พัฒนาจำนวนมาก / มุ่งมั่นที่ "พื้นที่เก็บข้อมูลหลัก" อาจอยู่ในช่วงที่ขาดเนื่องจาก ถึงเราไม่สามารถมี "ประตูคุณภาพ" สำหรับการกระทำแต่ละอย่างได้ ปลายอีกด้านของสเปกตรัมอาจเป็นเช่นนั้น (เราคิดว่า Linus Torvalds / Linux ทำ) โครงสร้างต้นไม้หรือปิรามิดซึ่ง "คลังเก็บหลัก" มีแหล่งดึงสามแหล่งสามแห่งนี้มีแหล่งดึงที่เชื่อถือได้ ฯลฯ อย่างไรก็ตามเรารู้สึกว่าด้วยโครงสร้างเช่นการเปลี่ยนแปลงนั้นมีสายโซ่ยาวที่จะปีนขึ้นไปเพื่อเข้ามาใน "พื้นที่เก็บข้อมูลหลัก" นอกจากนี้หากเกิดข้อขัดแย้งในการผสานปัญหาจะเกิดกับผู้พัฒนารายอื่นมากกว่า "ผู้พัฒนาดั้งเดิม" จากข้อมูลพื้นฐานและความคิดเห็นทั้งหมดที่ระบุไว้เราจะเรียนรู้และอ่านวิธีการพัฒนาที่แนะนำสำหรับนักพัฒนาจำนวนมากได้อย่างไร องค์กรขนาดใหญ่ (Microsoft, …

19 agile  workflows  software  development-methodologies  gitflow 

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

18 git  github  gitflow 

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

18 git  workflows  gitflow 

ทีมของเราเพิ่งเปลี่ยนจาก FogBugz & Kiln / Mercurial เป็น Jira & Stash / Git เรากำลังใช้โมเดล Git Flow สำหรับการแยกสาขาเพิ่มสาขาย่อยย่อยออกจากสาขาคุณลักษณะ (เกี่ยวข้องกับงานย่อย Jira ของคุณสมบัติ Jira) เรากำลังใช้ Stash เพื่อกำหนดผู้ตรวจสอบเมื่อเราสร้างคำขอดึงเพื่อรวมกลับเข้าไปในสาขาหลัก (โดยปกติจะพัฒนา แต่สำหรับงานย่อยกลับเข้าไปในสาขาคุณลักษณะ) ปัญหาที่เราพบคือแม้ว่าจะมีการวางแผนที่ดีที่สุดและพังทลายของกรณีคุณสมบัติเมื่อนักพัฒนาหลายคนทำงานร่วมกันในคุณสมบัติเดียวกันพูดบน front-end และ back-end หากพวกเขากำลังทำงานบนรหัสพึ่งพาซึ่งกันและกัน ในสาขาแยกต่างหากผู้พัฒนารายหนึ่งจะปิดกั้นอีกฝ่าย เราพยายามดึงระหว่างสาขาของกันและกันขณะที่เราพัฒนา นอกจากนี้เรายังพยายามสร้างการรวมสาขาในพื้นที่นักพัฒนาซอฟต์แวร์แต่ละคนสามารถดึงจากหลาย ๆ สาขาเพื่อทดสอบการรวมระบบที่พัฒนาขึ้น ในที่สุดและสิ่งนี้ดูเหมือนว่าจะทำงานได้ดีที่สุดสำหรับเราถึงแม้ว่าจะมีค่าใช้จ่ายเพิ่มขึ้นอีกเล็กน้อยเราได้ลองสร้างสาขาการรวมออกจากสาขาคุณลักษณะทันทีที่ค้างคาว เมื่อสาขาย่อยของภารกิจย่อย (ไม่อยู่ในสาขาฟีเจอร์) พร้อมสำหรับการร้องขอการดึงและการตรวจสอบโค้ดเรายังรวมการเปลี่ยนแปลงที่กำหนดไว้ในสาขาการรวมคุณลักษณะนี้ด้วยตนเอง จากนั้นผู้พัฒนาที่สนใจทุกคนสามารถดึงจากสาขาการรวมเข้ากับสาขาย่อยย่อยอื่น ๆ นี่เป็นการป้องกันไม่ให้ใครก็ตามที่รอสาขาที่พวกเขาต้องพึ่งพาเพื่อตรวจสอบรหัส ฉันรู้ว่านี่ไม่จำเป็นต้องเป็นปัญหา Git - มันเกี่ยวกับการทำงานกับการพึ่งพาซึ่งกันและกันของรหัสในหลายสาขาผสมผสานกับกระบวนการทำงานและวัฒนธรรมของเราเอง หากเราไม่มีนโยบายการตรวจสอบรหัสที่เข้มงวดสำหรับการพัฒนา (สาขาการรวมที่แท้จริง) นักพัฒนา 1 …

17 git  workflows  branching  jira  gitflow 

ปัญหานี้ระบุว่า: จากความเข้าใจของฉันที่วางแท็กในสาขาที่วางจำหน่ายก่อนที่จะรวม (และไม่ได้อยู่ในสาขาหลัก) ในความเป็นจริงสิ่งที่ถูกต้องที่จะทำมันสามารถพบได้โดย git อธิบาย - แท็กจากสาขาพัฒนาเช่นกัน ดู # 374 ในขณะที่โพสต์อื่น : ฉันบังเอิญติดตั้งเวอร์ชั่น 0.4.2 ล่วงหน้าผ่าน homebrew วันนี้และรู้สึกสับสนกับวิธีการติดแท็กที่ใช้งานในเวอร์ชันนั้น ก่อนหน้านี้ (เวอร์ชั่น 0.4.1) แท็กถูกสร้างขึ้นในสาขาหลักหลังจากสาขาย่อยได้รับการรวมเข้าด้วยกัน ตอนนี้ดูเหมือนว่าแท็กจะถูกสร้างขึ้นในการกระทำครั้งสุดท้ายของสาขาที่วางจำหน่ายซึ่งดูเหมือนจะไม่ใช่ความคิดที่ดีสำหรับฉัน โดยเฉพาะอย่างยิ่งถ้าคุณมีระบบการสร้างที่อาศัยแท็ก git และสร้างรุ่นที่วางจำหน่ายหาก HEAD เป็นคอมมิทที่ติดแท็กและเวอร์ชันการพัฒนาหากหนึ่งในคอมมิชชันต่อไปนี้ ใครช่วยอธิบายตรรกะที่อยู่เบื้องหลังการเปลี่ยนแปลงนี้ให้ฉันได้ไหม และด้วยความเคารพต่อ semantic versioning ฉันไม่คิดว่ามันจะเป็นเวอร์ชั่นที่ชนกันในระดับ patch! ในทีมของเราเรามีและมีการพูดคุยกันหลายครั้งเกี่ยวกับเรื่องนี้ บางคนระบุว่าจะต้องสร้างแท็กจากสาขาหลักในขณะที่บางสาขาต้องการสาขาย่อย ตามภาพ gitflow: ดูเหมือนว่าแท็กจะถูกวางไว้บนต้นแบบ

16 gitflow