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

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

1. ไฟล์ว่างเปล่า?
2. รหัสสำเร็จรูป?
3. คุณสมบัติแรก?
4. เมื่อถึงจุดอื่น?

นอกจากนี้สาเหตุที่ต้องเช็คอิน ณ จุดใดจุดหนึ่ง?

คุณควรกระทำทันทีที่คุณมี "หน่วย" ที่สมเหตุสมผล

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

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

เท่าที่ฉันกังวล Repo การควบคุมแหล่งที่มาของคุณเป็นส่วนหนึ่งของการตั้งค่าโครงการขั้นพื้นฐานดังนั้นฉันยอมรับทันทีหลังจากที่ฉันสร้างโครงการที่ว่างเปล่าของฉัน

เมื่อวาน

... ในอีกทางหนึ่งถ้าคุณไม่สามารถเดินทางข้ามเวลาได้ ...
(บางทีรถของคุณไม่สามารถไปถึง 88mph หรือตัวเก็บประจุฟลักซ์ของคุณเพิ่งหมดไป)

ตอนนี้

โครงการใหม่ควรจะเกิดขึ้นในจุดที่เลือดมันบ้าไปแล้วและระบบ DVCS ร่วมสมัยเพิ่งลบข้อแก้ตัวที่เป็นไปได้ทั้งหมดเพื่อหลีกเลี่ยงการกระทำ : git init . ; git add * ; git commit -m initial-commitตอนนี้ก่อนที่มันจะสายเกินไป

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

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

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

โดยส่วนตัวแล้วการคอมมิทครั้งแรกของฉันมักจะมีไฟล์. gitignore (หรือเทียบเท่า) ที่มีตัวกรองบางอย่างที่ฉันรู้ว่าจะต้องใช้เช่น* .py [co]สำหรับโค้ด Python การตั้งค่าโครงการพื้นฐานและ / หรือต้นแบบแรกที่ง่ายที่สุดคือสิ่งที่ตามมา

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

• บทนำ
• รายละเอียดโครงการ
• โครงสร้างโครงการ
• ข้อกำหนดการเข้ารหัส
• คำแนะนำเกี่ยวกับวิธีการ:
  • สร้าง
  • ทดสอบ
  • ปรับใช้
• ปัญหาที่พบและวิธีแก้ปัญหา
• รายการสิ่งที่ต้องทำ
• เงื่อนไขการใช้บริการ

การฝึกฝนการอัปเดต README ก่อนที่จะทำการเปลี่ยนแปลงในโครงการนั้นเรียกว่าReadme Driven Developmentและช่วยให้คุณคิดผ่านการเปลี่ยนแปลงก่อนที่จะลงทุนเวลาในการเปลี่ยนแปลงเหล่านั้น

ใครก็ตามที่ต้องการมีส่วนร่วมหรือใช้ซอฟต์แวร์นี้จะเริ่มต้นด้วย README

หากคุณทำงานที่คุณไม่ต้องการเสียมันควรจะอยู่ในระบบควบคุมแหล่งที่มาของคุณ

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

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

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

ไม่แน่ใจว่ามันถูกกล่าวถึง

แต่ให้แน่ใจว่าสิ่งที่คุณกระทำวิ่ง / คอมไพล์! ดังนั้นจึงไม่มีข้อผิดพลาดทางไวยากรณ์ ฯลฯ

ไม่มีอะไรน่าผิดหวังไปกว่ารหัสชำระเงินที่เสีย

มุมมองอื่น ๆ ที่เกี่ยวข้องกับการทดสอบซอฟต์แวร์ (TDD approach) จะเกิดขึ้นทันทีที่คุณมีกรณีทดสอบใหม่เป็นสีเขียว นี่หมายความว่าคุณมีรหัส "หน่วย" ใหม่ที่สมบูรณ์

ก่อนที่คุณจะทำอะไรโง่ ๆ

สำหรับพวกเราที่ไม่มีพลังเวทย์มนตร์นั่นหมายถึงน้อยและบ่อยครั้ง

หากคุณทำงานด้วยตัวเองทำทุกครั้งที่คุณดื่มหรืออะไรก็ตาม

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

ประมาณ 2 ~ 3 ชั่วโมงในโครงการ

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

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

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

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

มีหลายคนตอบแล้ว "ทันที" และฉันเห็นด้วย 100% ฉันชอบข้อเสนอแนะของ Xion เพื่อเริ่มต้นด้วยรูปแบบการเพิกเฉยของ VCS (เช่น.gitignoreหรือเทียบเท่า)

ฉันคิดว่ามันตกลงกันค่อนข้างมากว่าไม่มีข้อเสียสำหรับการผูกมัด แต่เนิ่น ๆ ฉันต้องการเพิ่ม Upsides:

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

มันอาจขึ้นอยู่กับ VCS ที่คุณใช้

ด้วย Git ฉันจะทำไดเรกทอรีว่างเปล่า (หรือด้วยไฟล์ README เกือบจะว่างเปล่า) ประเด็นคือฉันสามารถย้อนกลับและตั้งค่าสาขาของฉันกลับสู่สถานะว่างเปล่าหากฉันต้องการเริ่มต้นใหม่อย่างสมบูรณ์ในขณะที่ฉันยังอยู่ในช่วงต้นของกระบวนการพัฒนา (ก่อนที่จะผลักดันอัปสตรีม) ฉันจะยอมรับไฟล์ "ที่สร้างขึ้น" ของฉัน (เช่นโซลูชัน visual studio) จากนั้นเมื่อฉันเขียนโปรแกรมจริงฉันจะเริ่มมอบหมายแต่ละหน่วยตามปกติ

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

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

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

ฉันกำลังใช้ Tortoise / SVN ในที่ทำงาน

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

ฉันยังมีสคริปต์ที่ทำหน้าที่โปรเจ็กต์ของฉันโดยอัตโนมัติทุก ๆ 10 นาทีไปยัง repo สำรองในกรณีที่ฉันลืมส่งด้วยตนเอง ลองเรียกมันว่าบัฟเฟอร์การเลิกทำการสำรองข้อมูลบนคลาวด์ของฉัน

เช็คอิน (aka. push ) โครงการไปยัง repo ของทีมเมื่อคุณต้องการให้ทีมของคุณเห็นรหัสของคุณ ซึ่งน่าจะเป็นสิ่งที่ก่อนที่ทีมของคุณพร้อมที่จะมองเห็นรหัสของคุณหากคุณเป็นเช่นฉัน

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

ฉันได้อ่านบทความทั้งหมดแล้วและฉันคิดว่าเรามีวิธีแก้ปัญหาที่ดีอยู่แล้ว แต่ฉันต้องการแบ่งปันวิธีการของฉันกับคุณ

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

ขอบคุณ

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

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

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

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

โดยปกติฉันจะเช็คอินเมื่อใดก็ตามที่ฉันเพิ่มสิ่งใหม่ ๆ แต่พยายามแยกสิ่งต่าง ๆ ในการกระทำที่ไม่ต่อเนื่อง

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

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

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

โดยปกติเมื่อฉันเริ่มเพิ่มรหัสสำเร็จรูป (เช่นเพิ่มเว็บแอปใหม่ในเว็บไซต์ django) ฉันยอมรับการดำเนินการทุกอย่างที่ฉันทำ

ถ้าฉันทำตามบทช่วยสอนเพื่อสร้าง / เขียนรหัสฉันใช้ชื่อขั้นตอนในบทช่วยสอนเพื่อส่งข้อความ ด้วยวิธีนี้ฉันสามารถแก้ไขความแตกต่างและดูว่าขั้นตอนการสอนทำอะไรในภายหลัง

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

มันจะขึ้นอยู่กับว่าการเพิ่มเนื้อหานั้นยากเพียงใด:

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

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