Git ควรใช้สำหรับเอกสารและการจัดการโครงการหรือไม่ รหัสควรอยู่ในที่เก็บแยกต่างหากหรือไม่?

68

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

นี่คือบทสรุปของคำถามของฉัน:

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

ขอบคุณสำหรับคำติชมจนถึงตอนนี้!

git version-control project-management

— EmpireJones
แหล่งที่มา

อ่าโอเค ... ขอบคุณสำหรับการชี้แจง ฉันไม่เห็นว่าทำไมมันจึงเป็นปัญหา แต่ฉันไม่มีประสบการณ์ส่วนตัวกับ GIT (เพียงความเข้าใจในเชิงทฤษฎี) ดังนั้นฉันจะให้ใครสักคนที่มีประสบการณ์ตรงมากขึ้นตอบคำถามนั้น

— Flimzy

1

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

— Tim Post

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

— Rig

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

เกี่ยวข้อง: ส่วนของโครงการของคุณควรอยู่ในการควบคุมรหัสที่มา?

— ริ้น

53

เราจัดเก็บเอกสารใน SVN ตลอดเวลา ในความเป็นจริงคู่มือผู้ใช้ทั้งหมดของเราเขียนเป็น LaTeX และเก็บไว้ใน SVN เราเลือก LaTeX เป็นพิเศษเพราะเป็นภาษาที่ใช้ข้อความและง่ายต่อการแสดงความแตกต่างของบรรทัดต่อบรรทัด

นอกจากนี้เรายังจัดเก็บไฟล์ที่ไม่มีการจัดรูปแบบข้อความเช่นไฟล์ Microsoft Office .doc, สเปรดชีต, ไฟล์. zip ฯลฯ เมื่อจำเป็น ... แต่ข้อดีบางประการของ RCS จะหายไปเมื่อคุณไม่เห็นการเพิ่มขึ้น diffs

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

— Flimzy
แหล่งที่มา

11

หากคุณเป็นร้านค้าของ Microsoft TortoiseSVN รองรับการใช้งาน MS Office แบบบรรทัดต่อบรรทัด

— Phil

2

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

— Kai Inkinen

โอ้และเป็นครั้งแรกที่ฉันได้ยินเกี่ยวกับ TortoiseSVN และไฟล์ doc ดังนั้น +1 สำหรับสิ่งนั้น สงสัยว่ามันจะจบลงที่ Tortoise [AnyDVCS] ทุกเวลาในอนาคต

— Kai Inkinen

@Phil: TortoiseSVN ทำสิ่งนี้ได้อย่างไร วิวเวอร์ doc-diff รวมกับไคลเอนต์ SVN หรือสามารถใช้แยกกันได้หรือไม่?

— Flimzy

1

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

— Tikhon Jelvis

22

มันขึ้นอยู่กับรูปแบบที่คุณใช้สำหรับเอกสาร ถ้ามันเป็นข้อความตามสิ่งที่ดีทั้งหมด

Git ยังสามารถเก็บเนื้อหาไบนารีและคุณสามารถติดตามการแก้ไขได้ แต่เอาต์พุต diff จะไม่สมเหตุสมผล

นอกจากนี้ยังเป็นไปได้ที่จะจัดเก็บเอกสารในโค้ดของตัวเองเช่น perldoc pod, java ยังมีรูปแบบ / คำอธิบายประกอบสำหรับสิ่งนี้

— cstamas
แหล่งที่มา

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

— Sverre Rabbelier

ฉันว่า Word ย้ายรูปแบบของพวกเขาออกจากไบนารีเป็น XML

— cledoux

3

@ karategeek6 รูปแบบ 'XML' ของ Word ไม่สามารถอ่านได้โดยมนุษย์ และข้อความหนึ่งบรรทัดไม่สอดคล้องกับ XML บรรทัดเดียวของ Word แม้แต่ในการประมาณ ดังนั้นมันอาจเป็นเลขฐานสอง

คุณสามารถสั่งให้ Word บันทึกผลลัพธ์ของคุณใน XML ที่ไม่บีบอัดได้ เลือกSave Asแล้วเลือกแทนการเริ่มต้นWord XML Document (*.xml) Word Document (*.docx)XML นั้นค่อนข้างซับซ้อนดังนั้นจึงไม่รับประกันว่าการเปลี่ยนแปลงจะสามารถอ่านได้ง่าย แต่อย่างน้อยก็จะไม่เป็นแบบไบนารี

— Kyralessa

> แต่เอาท์พุท diff จะไม่สมเหตุสมผล ในกรณีที่แตกต่างกันเราสามารถเปิดแก้ไขเอกสารได้ 2 ฉบับโดยเปรียบเทียบกันและด้วยสายตาของเรา :)

— Luke

14

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

6

เฉพาะในกรณีที่เอกสารอยู่ในรูปแบบข้อความ Blob ไบนารีไม่ได้รับประโยชน์เต็มที่จากการควบคุมเวอร์ชัน

2

@ ThorbjørnRavnAndersen: ถึงอย่างนั้นถ้าคุณไม่มีระบบ version-specific, มันคงดีกว่าถ้าเก็บไฟล์ไบนารีไว้ใน Git แทนที่จะเป็นของพวกมันเอง

— Tikhon Jelvis

@TikhonJelvis ฉันไม่ได้ถามว่ามันเป็นความคิดที่ดีที่จะใส่ไฟล์ไบนารีในคอมไพล์ - ถ้ามันเป็นสิ่งประดิษฐ์ดั้งเดิมมันเป็น อย่างไรก็ตามพยายามเรียกใช้ "git diff" บนเอกสาร Word

@ user1249: คุณสามารถ "ส่งออก" 2 การแก้ไขไปยังเดสก์ทอปพูด my_docs_rev15.docx และ my_docs_rev14.docx แล้วเปิดด้านข้างและเปรียบเทียบด้วยตาและสมองของคุณไม่ว่ามันยาก :)

— ลุค

14

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

— Ma99uS
แหล่งที่มา

3

ใช่กว้างยาว "ตำแหน่งเดียวกัน" เป็นหนึ่งในส่วนสำคัญของคำถามนี้!

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

— quick_now

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

— bdsl

9

ใน บริษัท ที่ฉันทำงานเราใส่เอกสารไว้ใน SVN อย่างไรก็ตามหลังจากความขัดแย้งเล็กน้อยและความต้องการในการแบ่งปันเราตัดสินใจย้ายไปที่ Mediawiki

ตอนแรกมันเป็น trac หลังจากนั้นก็ย้ายไปที่ Mediawiki ทำให้มันเป็นเรื่องง่ายกว่าที่จะใช้ ...

ปัญหาหลักของ SVN คือการแบ่งปันเพราะเรามีระบบการอนุญาตสำหรับ SVN

— confiq
แหล่งที่มา

2

คุณไม่ได้หมายถึง Mediawiki เครื่องมือวิกิที่ Wikipedia ใช้หรือไม่

@Martijn ฉันจะคิดอย่างนั้น

— Teo Klestrup Röijezon

@Martijn: ใช่แก้ไขแล้ว

— confiq

ฉันอยากจะติดกับวิกิมากกว่าที่จะส่งไฟล์จำนวนมากที่ไม่ได้ไปที่ SCM แต่ก็เป็นเรื่องที่ต้องทำด้วยความชอบส่วนตัว มีอีกมากมายที่คุณสามารถทำได้ ฉันชอบ Foswiki และแม่แบบที่ใช้เว็บไซต์ / โครงการเป็นหลัก ดีใจที่มีคนชี้ไปที่จะใช้วิกิเนื่องจากปัญหา :) +1

— Oeufcoque Penteano

9

การมีมากกว่าซอร์สโค้ดในที่เก็บเป็นสิ่งที่ดีมาก

มันจัดกลุ่มทรัพยากรทั้งหมดของคุณเข้าด้วยกันและเปลี่ยนโครงการให้กลายเป็นเอนทิตีที่แน่นหนาและเป็นศูนย์กลางแทนที่จะรวบรวมไฟล์ที่กระจัดกระจาย ผู้ร่วมให้ข้อมูล / พนักงานรู้ว่าจะค้นหาทุกสิ่งได้ที่ไหนแทนที่จะส่ง"ฉันจะเปลี่ยนเอกสารสำหรับคุณสมบัติ x ได้อย่างไร" อีเมล

คุณจะต้องการจัดระเบียบสิ่งต่าง ๆ มีระบบการแยกsrcจากจากimages docsคุณสามารถเพิ่ม a .gitignoreลงในไดเรกทอรีเพื่อทำให้ที่เก็บและประวัติการเก็บข้อมูลสะอาดเสมอ เนื่องจาก Git กระทำตามไฟล์ * คุณสามารถแยกการเปลี่ยนแปลงแหล่งที่มาจากการเปลี่ยนแปลงเอกสารตามที่คุณต้องการ
ดังที่คนอื่น ๆ พูดกัน Git นั้นยอดเยี่ยมสำหรับการทำเวอร์ชันเอกสารตราบใดที่มันเป็นข้อความ
ฉันเห็นด้วยอย่างสมบูรณ์; ควรจัดทำเอกสารเวอร์ชันด้านขวาของโค้ด

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

* สิ่งนี้ไม่ถูกต้องนักเนื่องจากมีวิธีการระบุบางส่วนของไฟล์ที่จะคอมมิท ( ตัวอย่างหนึ่ง )

— Tyler Wayne
แหล่งที่มา

4

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

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

— Eelke Blok
แหล่งที่มา

สาขาที่แตกต่างกับโครงสร้างไดเรกทอรีที่แตกต่างกันอย่างสิ้นเชิงมีกลิ่นรหัสที่ไม่ดีมาก ฉันจะทิ้งทุกอย่างไว้ใน repo เดียวทำให้ผู้มีส่วนร่วมง่ายต่อการเพิ่มรหัสและเอกสารประกอบ ในความเป็นจริงการเขียนโปรแกรมความรู้ (Google ที่!) ต้องการมัน

— tbc0

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

— tbc0

1

ฉันใช้วิกิสำหรับเอกสารภายใน ... รับการแก้ไขพร้อมการเข้าถึงที่โดดเด่น / การแก้ไขที่ง่าย เมื่อเอกสารไม่ตรงกันให้อัพเดททันทีและที่นั่น สำหรับเอกสารประกอบสำหรับผู้ใช้ให้พิจารณาเครื่องมือระดับมืออาชีพเช่นMadcap Flareพวกเขาใช้ภาษา XML สำหรับการแชร์เขียนและแปลงเอกสาร

— Michael Brown
แหล่งที่มา

-1

ในรหัสความคิดมักจะแยกจากกันทีละบรรทัด ฉันมักจะเขียนเอกสารด้วยคำว่า soft line wraps เมื่อฉันส่งไฟล์เหล่านี้บรรทัดจะยาวทั้งย่อหน้า git diffนั่นคือไม่ได้มีประโยชน์มากที่จะอ่านใน นั่นเป็นปัญหาที่ฉันพยายามแก้ไขเมื่อฉันค้นหา Google และพบหน้านี้ ขอขอบคุณที่อาร์เน่ Hartherzgit diff --word-diffสำหรับการแนะนำให้ฉันไป คุณอาจจะชอบgit diff --color-wordsมากขึ้น

— tbc0
แหล่งที่มา