ทำไม Git ถึงได้โฆษณาเกินจริง …ในขณะที่คนอื่นทำไม่ได้? [ปิด]

ในช่วงไม่กี่ปีที่ผ่านมาการโฆษณารอบ ๆ Git เพิ่มขึ้นอย่างมาก ทุกคนรู้เกี่ยวกับ Git ไม่มีใครรู้เกี่ยวกับทางเลือก

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

จุดสำคัญของโพสต์นี้คือพยายามทำความเข้าใจปรากฏการณ์นี้ให้ดีขึ้น

Git มาได้อย่างไรส่วนหนึ่งของเค้ก? พวกเขาใช้การตลาดที่ดีกว่าอย่างใด? เป็นเพราะชุมชนของมันมีมากขึ้น ... อะแฮ่ม ... "verbose"? เป็นเพราะชื่อ "Linus" หรือไม่? เป็นเพราะภาพลักษณ์ที่เกินบรรยายหรือไม่?

ความคิดเห็นของคุณคืออะไร

ฉันเชื่อว่าการบริการเช่นGitHubหรือGitoriousเป็นปัจจัยสำคัญ เป็นสิ่งสำคัญสำหรับคนที่พวกเขาสามารถโฮสต์สิ่งของของพวกเขาที่ไหนสักแห่งและโดยเฉพาะ GitHub เป็นบริการที่ยอดเยี่ยมสำหรับสิ่งนั้น

สำหรับ Mercurial ไม่มีบริการดังกล่าวเมื่อ DVCS ได้รับความนิยม (อย่างน้อยฉันก็ไม่ทราบ) คุณมีBitbucketตอนนี้และอาจเป็นคนอื่น ๆ แต่ GitHub เคยอยู่ที่นั่นมานานแล้วมันเป็นที่รู้จักกันดีและมันก็ดีขึ้นเรื่อย ๆ

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

ฉันจะพูดเกี่ยวกับประวัติศาสตร์

GitและMercurialถูกสร้างขึ้นพร้อมกันเพื่อแก้ไขปัญหาเดียวกัน ย้อนกลับไปในสมัยนั้นเคอร์เนล Linux ถูกบังคับให้หยุดการใช้BitKeeperซึ่งเป็น SCM แบบกระจายซึ่งเป็นกรรมสิทธิ์ซึ่งถูกใช้งานมา 3 ปี เหตุผลของเรื่องนี้คือ Larry McVoy ซีอีโอของ BitMover บริษัท หลัง BitKeeper หยุดให้ซอฟต์แวร์ของเขาฟรีสำหรับนักพัฒนา Linux เพราะคนในชุมชน Linux ได้ทำการออกแบบวิศวกรรมย้อนกลับ

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

หลังจากการพัฒนาโครงการเหล่านี้แยกกัน Matt Mackall ได้นำเสนอ SCM ขั้นสูงของเขาและทำการเปรียบเทียบกับ Git (ซึ่งมีอายุเพียงไม่กี่สัปดาห์) Linus พิจารณาใช้มันแทน Gitสำหรับการพัฒนาเคอร์เนล แต่ลดลงคิดเมื่อเขาตระหนักว่าMercurial ใช้ Changesets เพื่อเข้าสู่ระบบการปรับเปลี่ยนแก้ไข เขากลัวว่าใกล้เกินไปกับวิธีการทำงานของ BitKeeper และแน่นอนว่าเขาไม่ต้องการอะไรที่จะทำให้ใครบางคนพูดว่า "พวกเขาสร้าง BitKeeper clone"

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

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

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

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

ในทางตรงกันข้าม SCM แบบกระจายเป็นผู้ชนะที่ชัดเจน ฉันไม่เห็น SCM ที่ไม่ได้ใช้กันอย่างแพร่หลายมากมาย

Linus Torvalds

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

ส่วนตัวฉันยังคงใช้การโค่นล้ม แต่นั่นมาจากความชอบมากกว่ายูทิลิตี้

จุดเจ็บปวดปกติกับระบบการควบคุมเวอร์ชันเป็นสาขาการควบรวม

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

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

ฉันอยู่ในสถานการณ์เมื่อประมาณหนึ่งปีที่แล้วซึ่งฉันต้องเลือกระหว่าง hg และ git และการรวมกันข้างต้นเป็นปัจจัยสำคัญอย่างหนึ่งในการเลือก git อย่างที่สองก็คือองค์กร Eclipse เปลี่ยนไปเป็นคอมไพล์ดังนั้นเครื่องมือ Eclipse นั้นคาดว่าจะดีสำหรับโครงการ Java เมื่อมีการเปิดตัว Eclipse 3.7 สิ่งนี้ก็เกิดขึ้น พวกเราอาจจะเร็วประมาณ 6-9 เดือน

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

แก้ไข: หมายเหตุฉันไม่ได้บอกว่ามีสิ่งใดที่ Mercurial ไม่สามารถทำได้เพียงแค่นั้นสำหรับ Java ที่มี Eclipse - ซึ่งเป็นจุดสนใจหลักของเรา - กลไกตลาดกำลังแข็งแกร่งที่สุดสำหรับ git แม้ใน Windows และเราต้องยืนบนไหล่ ของผู้อื่นไม่ใช่เท้าของพวกเขา

แทนที่จะพูดว่าทำไมคอมไพล์หรือ Mercurial ดีกว่าและบอกเหตุผลเดียวที่มันเป็นที่นิยมฉันจะมุ่งเน้นไปที่ชุมชน

ดังที่ฉันได้เน้นไว้ก่อนหน้านี้ชุมชน Git ดังและหยิ่งผยอง ส่วนใหญ่จะปกป้องโปรแกรมที่มีค่าของพวกเขาอย่างจริงจัง สงคราม Git vs Mercurial ส่วนใหญ่ที่ฉันเคยเห็นมานั้นเริ่มต้นโดยผู้คนที่สงสัยว่าทำไมทุกคนบนโลกไม่ได้ใช้คอมไพล์ศักดิ์สิทธิ์ เว็บไซต์เช่นWhygitisbetterthanx.comยังแสดงความเย่อหยิ่งนี้ในการแนะนำซึ่งเขียนขึ้นเพื่อล่อเหยื่อคนอื่น ๆ

ฉันไม่ได้บอกว่าทุกคนเป็นแบบนี้ แต่ส่วนใหญ่เวลาที่ฉันพบคน git เว็บไซต์ pro-git และบล็อก pro-git ฉันรู้สึกว่า git ถูกผลักคอของฉันแทนที่จะเสนอ DVCS ที่ทำงานได้ ระบบ.

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

ฉันไม่คิดว่า Mercurial นั้นมีรายละเอียดต่ำโดยเฉพาะ Kiln สร้างขึ้นบน Hg & ได้รับการสนับสนุนอย่างดีใน IDEs เช่น Eclipse & Netbeans มาระยะหนึ่งแล้ว

นักพัฒนาส่วนใหญ่ที่ฉันพูดถึงดูเหมือนจะชอบ Hg เพราะการสนับสนุน Windows ที่ดีกว่า ถ้าเราเป็นนักพัฒนาลีนุกซ์อาจเป็นอีกเรื่องหนึ่ง

คุณยังขาด "Bazaar" ซึ่งเป็น "DVCS ที่ถูกลืม" ของจริง

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

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

1. มันมีประสิทธิภาพมาก
2. มันสนุกที่จะใช้ (ในรูปแบบของนักวิทยาศาสตร์คอมพิวเตอร์ที่เฉพาะเจาะจงมาก ๆ )

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

มีสามปัจจัยในการทำงานที่นี่ "สื่อเบต้าเกินบรรยาย" "เวลาถูกต้อง" และ "ติดตามผู้นำ"

Beta Geek Media

มีหลายช่องทางที่จะพูดคุยเกี่ยวกับ "กิจกรรมที่เกินบรรยาย" แน่นอนว่าพวกเขาจะครอบคลุมลักษณะที่ปรากฏของระบบควบคุมเวอร์ชันใหม่ แต่พวกเขาก็ครอบคลุมคอมไพล์มากขึ้น ทำไม? เนื่องจาก Linus Torvalds เขียนขึ้นในตอนแรกโต้แย้งเกี่ยวกับเรื่องนี้ต่อสาธารณะและใช้เป็นวิธีการแก้ปัญหาที่ได้รับการเผยแพร่อย่างดีของเขาด้วย bitkeeper อย่างมีประสิทธิภาพทุกครั้งที่มีสงครามไฟบน lkml สื่อเบต้าเกินบรรยายจะเขียนบทความเกี่ยวกับมัน การอภิปราย Git เริ่มต้นที่ lkml ดังนั้นจึงมีความครอบคลุมมากกว่าทางเลือกอื่น และเบต้าแววที่อ่าน slashdot เหมือนมันเป็นวาไรตี้กินมันขึ้นมา ผลลัพธ์ที่ดีที่สุดคือคอมไพล์มีบทความมากกว่า Mercurial ถึงสิบเท่า

เวลาถูกต้อง

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

ตามผู้นำ

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

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Bazaar : Ubuntu, Emacs

Git มีโปรเจ็กต์ที่ "ใช้งานมาก" มากขึ้นดังนั้นผู้คนจึงคุ้นเคยกับคอมไพล์มากขึ้น

มันเป็นเพียงการเสริมแรง hype Git ได้รับความนิยมสูงสุดดังนั้นจึงได้รับการเผยแพร่มากที่สุดซึ่งนำไปสู่การได้รับความนิยมมากขึ้น

Git, Hg และ Bzr ล้วนแล้วแต่เป็นระบบ DVCS ที่ดีเลิศ แต่มีคนจำนวนหนึ่งที่น่ากลัวถือเอา DVCS กับ Git และคิดว่าคุณสมบัติที่น่ารักของ DVCS นั้นไม่เหมือนใครกับ Git ดังนั้นพวกเขาจึงใช้ Git และแนะนำ Git และพูดสิ่งต่าง ๆ เช่น "Git นั้นดีกว่าเพราะมันสามารถทำการรวมของปลาหมึกยักษ์" (Bazaar สามารถทำได้) หรือ "Git นั้นดีกว่าเพราะมันถูกแจกจ่าย" (เช่นDVCS ใด ๆดังนั้นชื่อ ) หรือ "Git ดีกว่าเพราะทำให้การแยกและการรวมทำได้ง่าย" (อีกครั้งนี่เป็นความจริงของ DVCS ทุกตัว)

น่าเศร้าเพราะฉันรู้สึกว่าทางเลือกมีให้เลือกมากมายเช่นกันและฉันอยากให้คนเลือก Git เพื่อจุดแข็งที่เป็นเอกลักษณ์มากกว่าเพียงเพราะพวกเขาคิดว่า DVCS == Git

เมื่อมีคนค้นพบว่า DVCS'es ฉลาดเพียงใดโดยชี้ไปที่ DVCS เฉพาะหนึ่งพวกเขามักจะไม่ไปบอกคนอื่นว่า "เฮ้ DVCS'es นั้นยอดเยี่ยมมากคุณควรใช้มัน" แต่เป็น "DVCS ที่ฉันเรียนรู้เกี่ยวกับ DVCS'es จากนั้นยอดเยี่ยมคุณควรใช้มัน "

Github Github เป็นผู้บุกเบิกการเข้ารหัสทางสังคม มันเปลี่ยนการควบคุมเวอร์ชันเป็นแพลตฟอร์มโซเชียลที่ดึงดูดความสนใจได้มากและเห็นได้ชัดว่ามันรองรับ Git โซเชียลมีเดีย = การยอมรับที่มากขึ้น Bitbucket กำลังได้รับความนิยมแม้ว่าจะได้รับฟีเจอร์ใหม่ ๆ มากมายทำให้มันเป็นคู่แข่งที่มีแนวโน้ม :)

ในความเป็นจริงฉันคิดว่าโฆษณานี้เกี่ยวข้องกับ DSVCs ทั้งหมด

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

ฉันสงสัยว่า Mercurial จะใช้อย่างกว้างขวางบ่อยครั้งเท่า git อาจจะมากกว่านี้ (Microsoft และ บริษัท ใหญ่อื่น ๆ ใช้งานตอนนี้) แต่คนที่ใช้ Mercurial มักต้องการ DSVC ที่พวกเขาสามารถเข้าใจได้อย่างรวดเร็วไม่ใช่สิ่งที่ยึดถือศาสนา ดังนั้นพวกเขาจึงเป็นแกนนำในการสนทนาน้อยที่สุดและมีปฏิกิริยาโต้ตอบกันมากกว่าเชิงรุกเช่นผู้ใช้คอมไพล์บางคน

บาซ่าไม่ได้พูดถึงเรื่องนี้มากนักเพราะมีโครงการขนาดใหญ่เพียงไม่กี่แห่งเท่านั้นที่ใช้งานได้และไม่มี บริษัท ใหญ่อื่นใดที่รู้จัก Canonical มาใช้ เปรียบเทียบกับ Google (git, mercurial, svn) และโครงการโอเพนซอร์สขนาดใหญ่และคุณสามารถดูได้ว่าทำไมมันถึงไม่พูดถึง ฟอสซิลเป็นอีกหนึ่งที่น่าสนใจสำหรับโพรงของ devs ดังนั้นฉันคิดว่ามันเป็นเรื่องปกติและเป็นเรื่องที่ดีสำหรับพวกเขาที่จะได้ยินโดยเฉพาะผู้ที่ค้นหาคุณลักษณะที่พวกเขามีให้ (เช่น wiki ฝังตัวการติดตามปัญหาและฟอรัม)

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

นอกจากนี้ Google Code Hosting และ SourceForge อนุญาตทั้ง git และ mercurial ดังนั้นจึงกลายเป็นตัวเลือกเฉพาะโครงการมากกว่าเมื่อคุณเลือก git เนื่องจากคุณสมบัติของ GitHub

ไม่มีสงครามที่แท้จริงเครื่องมือที่น่าสนใจมากมาย

ฉันรู้ว่ามีคำตอบมากมายสำหรับคำถามนี้อยู่แล้ว แต่ฉันรู้สึกว่าฉันสามารถเพิ่มมุมมองอีกเล็กน้อย

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

1. มีฟังก์ชั่นมากมายที่มีคุณสมบัติที่ควรเป็นส่วนหนึ่งของ VCS หลักไม่ใช่ สิ่งต่าง ๆ เช่นความสามารถในการแบ่งออกเป็นสองส่วนของประวัติศาสตร์การรันเอาต์พุตแบบยาวผ่านเพจเจอร์หรือมีกิ่ง“ colocated” (เช่นที่เก็บแบบ git-git) ถูกจัดให้เป็นปลั๊กอิน
2. ปลั๊กอินจำนวนมากไม่ได้มีเสถียรภาพทั้งหมด ตัวอย่างเช่นฟังก์ชั่นสาขา colocated ดูเหมือนจะทำงานได้ไม่ดีในฝั่งเซิร์ฟเวอร์ (อย่างน้อยฉันไม่เคยได้รับมันไปใช้งานได้มันมีแนวโน้มที่จะเกิดข้อผิดพลาดโดยบอกว่าสาขาที่เส้นทางที่กำหนดไม่มีอยู่ ตรงหน้าคุณและคุณสามารถเห็นเลือด)
3. มันไม่มีการดำเนินการ "โคลน" คุณดึงกิ่งทีละครั้ง คุณต้องทำงานพิเศษหากคุณต้องการมีที่เก็บเพื่อให้คุณสามารถดึงสาขาใหม่ได้อย่างมีประสิทธิภาพ
4. สำหรับบางโครงการมันช้าอย่างเจ็บปวด ลองใช้“ bzr branch lp: mysql” บางครั้ง
5. มันขาดการสนับสนุนที่แข็งแกร่งสำหรับ hooks; คุณสามารถเขียนปลั๊กอิน bzr ที่มี hooks แต่ไม่มีวิธีมาตรฐานในการมีสคริปต์เบ็ดโดยพลการ

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

1. git clone เป็นการดำเนินการที่ค่อนข้างเร็วและให้ข้อมูลเกี่ยวกับสาขาทั้งหมดที่มีอยู่ในที่เก็บที่คุณโคลน
2. การเพิ่มที่เก็บข้อมูลระยะไกลเพิ่มเติมนั้นไม่เจ็บปวดดังนั้นคุณจึงสามารถติดตามที่เก็บข้อมูลที่แตกต่างกันจำนวนมากที่มีหลายสาขาได้หากต้องการ
3. Pro Gitหนังสือพร้อมใช้งานออนไลน์และในหลายรูปแบบรวมทั้งเพื่ออ่าน eBook อุปกรณ์และมันไม่ได้เป็นเรื่องยากในการอ่าน
4. git ดูเหมือนจะขยายได้ง่ายกว่าบาซ่าและคุณไม่จำเป็นต้องใช้ API ตัวใดตัวหนึ่งในการทำเช่นนั้น (หมายเหตุ: นี่เป็นทั้งส่วนกลับและข้อเสีย)
5. git มีการแบ่งเป็นสองส่วนในตัวและฉันไม่สามารถกดดันยูทิลิตี้ของฟีเจอร์นั้นได้เพียงพอ
6. GitHub ค่อนข้างดี
7. gitosisระบบยังเป็นสิ่งที่ดีมาก ฉันไม่แน่ใจด้วยซ้ำว่าจะใช้สิ่งใดนอกจากปลั๊กอินใน Bazaar และฉันไม่สามารถจินตนาการได้ว่ามันจะมีประสิทธิภาพใกล้เคียงกับที่ใด

เรื่องสั้นสั้น: ฉันเคยใช้ bzr มานานมากแล้ว แต่คอมไพล์ก็พิสูจน์ให้ฉันเห็นได้อย่างรวดเร็ว

การใช้คอมไพล์คุณมักจะอยู่ในไดเรกทอรีท้องถิ่นเดียวกันเสมอเมื่อคุณทำการพัฒนาและทำgit checkout branchnameเพื่อสลับระหว่างสาขา (ฉันใช้สาขาฟีเจอร์ "เบา" ตลอดเวลาดังนั้นนี่เป็นคุณสมบัติที่สำคัญมากสำหรับฉัน)

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

ฉันเชื่อว่าคุณสามารถทำสิ่งเดียวกันใน Mercurial เช่นเดียวกับ git แต่ด้วยเหตุผลบางอย่างเอกสาร Mercurial (ที่ฉันได้อ่าน) แสดงการแตกแขนงโดยการสร้างโคลนที่เก็บ

(ฉันใช้คอมไพล์ทุกวันฉันมีประสบการณ์น้อยมากกับ Mercurial ฉันได้เล่นกับมันและทำตามบทเรียนบางอย่าง)

ฉันไม่รู้ว่ามีคนพูดจาโผงผางมากี่ครั้งแล้วในช่วงสองสามสัปดาห์ที่ผ่านมา แต่พวกเขาทั้งหมดคิดว่ามันเป็นความจริงที่ว่า Mercurial และ / หรือ Bazaar นั้นดีกว่า Git ดูเหมือนว่าการใช้งานจะเป็นธีมทั่วไป ใช่การเรียนรู้ Git นั้นยากอย่างน่าประหลาดใจหลังจากใช้ CVS และการโค่นล้ม แต่ ณ จุดนี้ฉันไม่ต้องการแลกเปลี่ยนกับ VCS อื่น ๆ เว้นแต่ว่ามันจะเป็นการเปลี่ยนกระบวนทัศน์ใหม่ และชี้ไปที่โต๊ะของคุณสมบัติเป็นไปที่จะบอกฉันน้อยมากเกี่ยวกับวิธีการที่มีความยืดหยุ่นขยายปลอดภัยหรือง่ายดายมันเป็น ตัวอย่างเช่นโดยค่าเริ่มต้น git-diffจะใช้สีและวิทยุติดตามตัว แน่ใจว่าฉันจะได้รับเหมือนกันdiff ... | colordiff | less -Rหรือบางสิ่งบางอย่าง แต่ควรจะชัดเจนว่าทำไมคนหนึ่งถึงเหนือกว่าคนอื่น

เพื่อความเป็นธรรมฉันคิดว่าผู้สนับสนุน git vs. mercurial มีจำนวนน้อยมากเมื่อเทียบกับผู้สนับสนุน git vs. centralized อย่างไรก็ตามเหตุผลสรุปง่าย ๆ :

Git คือการควบคุมเวอร์ชันสำหรับโปรแกรมเมอร์ Mercurial คือการควบคุมเวอร์ชันสำหรับองค์กร การรวมศูนย์เป็นความพยายามครั้งแรกในการคิดค้นการควบคุมเวอร์ชันโดยเฉพาะอย่างยิ่งการพิจารณาว่ามันถูกออกแบบมาก่อนการปฏิวัติคอมพิวเตอร์ส่วนบุคคล

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

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

ฉันไม่คิดว่ามันยุติธรรมที่จะพูดว่าคอมไพล์ได้รับความนิยมเนื่องจากโฆษณาหรือการรับรองของ Linus นั่นอาจเป็นสาเหตุของหลาย ๆ คนที่พยายามแต่พวกเขายึดติดกับมันและส่งเสริมเพราะมันทำงานได้ดีสำหรับพวกเขาบริสุทธิ์และเรียบง่าย

การพัฒนา NetBSD ใช้ CVS และนั่นคือทั้งหมดที่สำคัญ

มันมีปลากะพงชื่อแหลมคมมากที่ให้ยืมตัวเองได้ดีสำหรับเล่น

เมื่อเร็ว ๆ นี้ฉันกำลังมองหาระบบควบคุมเวอร์ชันสำหรับโครงการส่วนบุคคลดังนั้นฉันจึงลองใช้พวกเขาเป็นกลุ่ม ฉันแทบไม่รู้หนังสือในบรรทัดคำสั่งและฉันได้ยินมาว่าถึงแม้จะมี GUIs อยู่ แต่ Git ก็ตั้งใจจะใช้ผ่านบรรทัดคำสั่งซึ่งทำให้ฉันค่อนข้างลังเล จริงๆแล้วมันเป็นเรื่องง่ายที่จะหยิบขึ้นมาและฉันก็สนุกกับมันจริงๆ การจัดทำเอกสารเป็นปัจจัยสำคัญในการนำเทคโนโลยีใหม่มาใช้และ Git มีเอกสารง่าย ๆ มากมายที่ชัดเจนและพร้อมใช้งาน ทางเลือกอื่น ๆ เช่น SVN และ Bazaar นั้นยอดเยี่ยมพวกเขาไม่ได้ทำให้ง่ายเหมือน Git Github ยังเป็นปัจจัยสำคัญเนื่องจากมันได้กลายเป็นศูนย์กลางของการเคลื่อนไหวโอเพนซอร์สในขณะนี้ การมีที่ตั้งส่วนกลาง (แดกดัน) เพื่อแลกเปลี่ยนรหัสและโครงการผ่านเป็นตัวเปลี่ยนเกมในตัวมันเอง

แค่ 2 ¢ของฉัน - ฉันเลือกคอมไพล์แทนทางเลือกเพราะมันเขียนด้วยภาษา C แทนที่จะเป็นภาษา radtool หรือภาษาระดับสูงทางวิชาการ ประโยชน์คือมันเร็วและมีประสิทธิภาพและฉันสามารถ RTFS จริง ๆ ถ้าฉันพบข้อบกพร่องหรือพฤติกรรมที่ฉันไม่สามารถอธิบายได้ นอกจากนี้ยังทำให้สามารถใช้กับสภาพแวดล้อมการพัฒนาที่มีโฮสต์ขนาดเล็กซึ่งไม่รวมล่ามขนาดใหญ่ / runtimes ซึ่งหมายความว่าฉันสามารถดึงจาก repo git และรวบรวมในระบบดังกล่าวโดยตรงแทนที่จะต้องดึงแหล่งข้อมูลล่าสุดที่อื่นและ rsync

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

ไม่ต้องพูดถึงตอนนี้ Apple มีส่วนเกี่ยวข้องกับการผลักดันเข้าสู่ชุมชน c วัตถุประสงค์หากคุณได้สร้างแอปพลิเคชั่นใหม่ใน Xcode 4 เมื่อเร็ว ๆ นี้คุณจะสังเกตเห็นว่ามันถามคุณโดยอัตโนมัติว่าคุณต้องการสร้าง Git repo หรือไม่

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

ฉันกำลังเปลี่ยนจาก hg (kiln) เป็น git (gitub) ฉันใช้เตาเผามาประมาณปีแล้ว สำหรับฉัน hg ไม่มีข้อเสีย ฉันสามารถทำทุกอย่างที่ฉันต้องทำ มันยอดเยี่ยมมาก

ทำไมฉันถึงใช้ตอนนี้?

ตอนนี้มีสามเหตุผลเท่านั้น

1. gitHub ให้บริการส่วนสำคัญที่ยอดเยี่ยม
2. gitHub นำเสนอคุณสมบัติทางสังคมที่ยอดเยี่ยม
3. ในขณะที่ทำการนำเสนอผลงานและเวิร์คช็อปฉันมักจะเผยแพร่ตัวอย่างของฉันใน hg และ git บน git ฉันมีผู้เยี่ยมชมมากกว่า hg ประมาณ 10 เท่า !!

ฉันคิดว่าอันที่สามเป็นสิ่งที่สำคัญที่สุด

Thorsten

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