การใช้ Git Stash เป็นเวิร์กโฟลว์เป็น antipattern หรือไม่

ฉันเพิ่งดูว่าฉันและทีมของฉันใช้ Git อย่างไรและเวิร์กโฟลว์ของเราทำงานอย่างไร ขณะนี้เราใช้เวิร์กโฟลว์คุณลักษณะสาขาซึ่งดูเหมือนจะทำงานได้ดี

ผมเคยเห็นบางคนยังเกี่ยวกับการใช้ทีมงานของเราขึ้นอยู่กับขั้นตอนการทำงานที่ซ่อนคอมไพล์ เวิร์กโฟลว์มีลักษณะดังนี้:

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

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

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

การใช้ git stash เป็นประจำจะถือว่าเป็นรูปแบบการต่อต้านหรือไม่ ถ้าเป็นเช่นนั้นมีปัญหาอะไรบ้างที่อาจเกิดขึ้นได้ ถ้าไม่ได้รับประโยชน์อะไรบ้าง?

จากหนังสือ Git SCM :

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

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

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

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

จริงๆแล้วมันทำให้เรื่องนี้แย่ลง:

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

เกี่ยวกับการยอมรับรหัส "แตก"

ในขณะที่ต่อไปนี้เป็นความเห็นฉันได้มาจากความคิดเห็นนี้จากประสบการณ์

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

1. สร้างสาขาใหม่
2. แฮ็คแฮ็คแฮ็ค
3. ส่งมอบรหัสที่ใช้งานไม่ได้
4. ขัดรหัสและทำให้มันใช้งานได้
5. ยอมรับรหัสการทำงาน
6. Rebase และ Squash
7. ทดสอบ
8. ดันเมื่อผ่านการทดสอบ

สำหรับ OP แล้วเธรดข้อความ Linux kernal นี้อาจเป็นที่สนใจเพราะมันฟังดูเหมือนสมาชิกบางคนในทีมของ OP กำลังใช้ Git ในลักษณะที่คล้ายกัน

@RibaldEddie กล่าวในความคิดเห็นด้านล่าง:

ก่อนอื่นการซ่อนไม่ได้อยู่นอก "เวิร์กโฟลว์การแตกแขนง" เนื่องจากที่เก็บซ่อนใต้กิ่งนั้นเป็นเพียงอีกสาขาหนึ่ง

(มีความเสี่ยงที่จะเกิดความโกรธแค้นของหลาย ๆ คน)

ไลนัสกล่าวว่า:

ด้วย "git stash" คุณสามารถมีหลายสิ่งที่แตกต่างกันได้เช่นกัน แต่พวกเขาไม่ได้จัดคิวซึ่งกันและกัน - มันเป็นเพียงแพตช์อิสระที่คุณสุ่มเก็บเพราะมันไม่สะดวกในบางจุด

สิ่งที่ฉันคิดว่า @RibaldEddie พยายามที่จะพูดคือคุณสามารถใช้git stashในเวิร์กโฟลว์สาขาคุณลักษณะ - และนี่คือความจริง มันไม่ใช่การใช้git stashสิ่งที่เป็นปัญหา git stashมันคือการรวมกันของการกระทำที่จะโทและการใช้ นี่คือรูปแบบการต่อต้าน

ชี้แจง git rebase

จากความคิดเห็นของ @ RibaldEddie:

การรีบูตเป็นมากขึ้นเช่นการคัดลอกและยิ่งแย่ลงแก้ไขประวัติมุ่งมั่น

(เหมืองเน้น)

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

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

มีเธรดเคอร์เนล Linux อีกอันที่น่าสนใจเกี่ยวกับประวัติการคอมมิท

อีกครั้งจาก Linus:

ฉันต้องการประวัติที่สะอาด แต่นั่นหมายถึง (ก) ประวัติที่สะอาดและ (ข)

ผู้คนสามารถ (และอาจจะควร) ลดต้นไม้ส่วนตัวของพวกเขา (งานของตัวเอง) นั่นคือการทำความสะอาด แต่อย่าใช้รหัสของคนอื่น นั่นคือ "ทำลายประวัติศาสตร์"

ดังนั้นส่วนประวัติศาสตร์จึงค่อนข้างง่าย มีกฎหลักเพียงข้อเดียวเท่านั้นและการชี้แจงเล็กน้อยหนึ่งข้อ:

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

  ขอให้สังเกตว่านี้จริงๆเป็นเรื่องเกี่ยวกับคนอื่น ๆประวัติศาสตร์ชนชาติอื่น ๆ ไม่เกี่ยวกับรหัส หากพวกเขาส่งข้อมูลให้คุณเป็นแพตช์ที่ส่งทางอีเมลและคุณใช้กับ "git am -s" แสดงว่าเป็นรหัสของพวกเขา แต่เป็น ประวัติของคุณ

  ดังนั้นคุณสามารถก้าวต่อไปในสิ่งที่ "git rebase" บนมันแม้ว่าคุณจะไม่ได้เขียนโค้ดตราบใดที่คอมมิทเองก็เป็นคนส่วนตัวของคุณ

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

  ดังนั้นการชี้แจงเล็ก ๆ น้อย ๆ ก็คือมันไม่ได้เกี่ยวกับ "ความมุ่งมั่นของคุณ" แต่ยังเกี่ยวกับความเป็นส่วนตัวกับต้นไม้ของคุณและคุณยังไม่ได้ผลักมันออกมาและประกาศออกมา

...

ตอนนี้ส่วน "สะอาด" ค่อนข้างละเอียดกว่านี้เล็กน้อยแม้ว่ากฎข้อแรกจะค่อนข้างชัดเจนและใช้งานง่าย:

• เก็บประวัติของคุณเองให้อ่านได้

  บางคนทำสิ่งนี้โดยการทำสิ่งต่างๆในหัวก่อนไม่ใช่การทำผิดพลาด แต่นั่นหายากมากและสำหรับพวกเราที่เหลือเราใช้ "git rebase" ฯลฯ ในขณะที่เราทำงานกับปัญหาของเรา

  ดังนั้น "git rebase" จึงไม่ผิด แต่มันก็ถูกต้องถ้ามันเป็นต้นไม้คอมไพล์ของคุณเองมาก

• อย่าเปิดเผยอึของคุณ

  ซึ่งหมายความว่าหากคุณยังอยู่ในช่วง "git rebase" คุณจะไม่ดันออกมา หากยังไม่พร้อมคุณส่งแพตช์ไปรอบ ๆ หรือใช้ต้นไม้ git ส่วนตัว (เช่นเดียวกับ "การแทนที่ชุดข้อมูลแก้ไข") ซึ่งคุณไม่ได้บอกต่อสาธารณชนในวงกว้างเกี่ยวกับ

(เน้นที่เหมือง)

ข้อสรุป

ในตอนท้าย OP มีนักพัฒนาบางคนทำสิ่งนี้:

git checkout master
(edit files)
git commit -am "..."
(edit files)
git stash
git pull
git stash (pop|apply)

มีสองปัญหาที่นี่:

1. นักพัฒนามุ่งมั่นที่จะต้นแบบ ล็อคสิ่งนี้ลงทันที จริงๆนี่เป็นปัญหาที่ใหญ่ที่สุด
2. นักพัฒนาซอฟต์แวร์กำลังใช้งานgit stashและใช้งานgit pullต้นแบบอย่างต่อเนื่องเมื่อพวกเขาควรใช้สาขาคุณลักษณะ

ไม่มีอะไรผิดปกติกับการใช้งานgit stash- โดยเฉพาะอย่างยิ่งก่อนการดึง - แต่การใช้git stashในลักษณะนี้เป็นรูปแบบการต่อต้านเมื่อมีเวิร์กโฟลว์ที่ดีขึ้นใน Git

พวกเขาใช้git stashปลาเฮอริ่งแดง มันไม่ใช่ปัญหา มุ่งมั่นที่จะเป็นปัญหาหลัก

โดยส่วนตัวแล้วฉันใช้stashสำหรับการขัดจังหวะระยะสั้นและไม่คาดคิดเช่นมีคนถามคำถามที่ต้องเปลี่ยนเป็นสาขาอื่น ฉันทำสิ่งนี้เพราะฉันลืมเกี่ยวกับการหยุดชะงักมาก่อนแล้วพวกเขาจะไม่ใช้อย่างหมดจด การคอมมิชชันแบบปกติบนฟีเจอร์บรานช์นั้นยากที่จะลืมและผสานได้ง่ายกว่าดังนั้นตอนนี้ฉันมักจะคอมมิทที่ใช้งานgit reset HEAD~1ไม่ได้

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

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

ที่ได้รับการกล่าวคำตอบของ @Greg Burghardt ข้างต้นเป็นที่นิยมมากเกินไปที่จะเรียกว่า git-flow หรือฟีเจอร์การทำงานของสาขา ฉันเคยสนับสนุนกลยุทธ์ที่คล้ายกัน แต่หลังจากตระหนักว่ามันเพิ่มความซับซ้อนที่ไม่จำเป็นและสร้างความปลอดภัยที่ผิดพลาดฉันไม่ทำอีกต่อไป นอกจากนี้ยังเป็นสิ่งที่ค้างไว้จากสมัยของระบบควบคุมเวอร์ชันที่ไม่มีการกระจายอำนาจเช่นการโค่นล้ม

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

อย่างไรก็ตามคำสั่ง rebase สามารถสร้างความเสียหายประวัติศาสตร์ของสาขาเมื่อมีความขัดแย้งผสานในหนึ่งในความมุ่งมั่นที่เล่นซ้ำ จากhttp://ryantablada.com/post/the-dangers-of-rebasing-a-branch

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

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

ตอนนี้วิศวกรหน้าของคุณออกไปเที่ยวพักผ่อนลาป่วยหรือใครจะรู้ ไม่มีใครสามารถคิดได้ว่ารหัสนั้นควรมีลักษณะอย่างไร!

Rebase ได้ฆ่าความสามารถของทีมในการดูประวัติเพื่อค้นหาสิ่งที่ผิดพลาดเพราะความขัดแย้งใด ๆ ที่เกิดขึ้นในสาขาย่อยจะถูกฆ่าและรหัสเดิมจะหายไปตลอดกาล

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

ยิ่งไปกว่านั้นโมเดลการแยกสาขาหลาย ๆ แบบสันนิษฐานว่าไม่มีสองสาขาใดที่สามารถมีการเปลี่ยนแปลงรหัสซึ่งกันและกันได้ เมื่อสิ่งนี้เกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ตอนนี้ผู้พัฒนาต้องเล่นปาหี่และสาขาอื่น ๆ เพื่อให้ทำงานได้อย่างมีประสิทธิภาพ

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

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

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

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

อย่างไรก็ตาม Git เชื่อมโยงกับเซิร์ฟเวอร์กลางเดียว มีนักพัฒนาทั้งหมดที่ทำcommit, pull(หรือrebaseถ้าคุณเป็นนั้น) pushตลอดเวลาสามารถทำให้รับประทานอาหารขนาดใหญ่

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

สำหรับสิ่งนี้git stashจะเป็นเครื่องมือที่เหมาะสมในการใช้

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

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

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

git stashไม่ใช่รูปแบบการต่อต้าน ใช้git stashเป็นทางเลือกที่แตกแขนงในขณะที่ทุกคนที่จะกระทำโทเป็นรูปแบบการป้องกัน - การ git stashแต่ไม่ได้เพราะ

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