Apa pendekatan kanonik untuk menggunakan hak VCS sejak masih bayi proyek?


9

Latar Belakang

Saya telah menggunakan VCS (terutama git) di masa lalu untuk mengelola banyak proyek yang ada dan bekerja dengan baik. Biasanya dengan proyek yang ada, saya akan memeriksa setiap perubahan yang saya buat pada kode yang mengoptimalkan atau mengubah fungsi keseluruhan (Anda tahu apa yang saya maksud, dalam langkah-langkah yang sesuai, tidak setiap baris tunggal yang saya ubah).

Masalah

Satu hal yang belum banyak saya lakukan adalah menciptakan proyek baru. Saya sedang dalam proses memulai proyek baru saya sendiri yang mungkin akan tumbuh cukup besar, tetapi saya menemukan bahwa ada banyak yang harus dilakukan dan banyak perubahan dalam beberapa hari / jam / minggu / periode pertama sampai sampai produk benar-benar berfungsi dalam bentuk paling dasar.

Apakah ada gunanya saya memeriksa setiap langkah proses seperti yang saya lakukan dengan proyek yang ada? Saya tidak melanggar proyek dengan perubahan yang saya buat karena belum berfungsi. Saat ini saya hanya menggunakan VCS sebagai cadangan pada akhir setiap hari, ketika saya meninggalkan komputer.

Beberapa komit pertama saya adalah hal-hal seperti "Struktur direktori dasar di tempat" dan "Tabel DB dibuat". Bagaimana saya harus menggunakan VCS ketika memulai proyek baru?


Judul Anda dapat diubah menjadi pertanyaan DAN jawabannya: "Apa pendekatan kanonik untuk menggunakan VCS? Hak dari masa kanak-kanak proyek" atau memang "Apa pendekatan kanonik untuk menggunakan hak VCS? Dari masa kanak-kanak proyek"
AakashM

1
Judul telah diedit sejak saya memulai pertanyaan. Sementara saya bisa melihat apa yang Anda katakan, itu bukan pertanyaan atau jawaban untuk pertanyaan yang saya ajukan - atau setidaknya tidak dalam interpretasi itu.
Anonim

@ Anonim-: Saya menulis ulang judul Anda karena itu dalam bentuk pertanyaan yang dianggap tidak konstruktif. Semoga Anda tidak keberatan, saya melakukan ini dalam upaya untuk mencegahnya ditutup lebih awal. Maaf kalau itu membuatmu bingung.
haylem

@haylem - Tidak masalah, saya setuju dengan Anda sepenuhnya! Saya menghargai Anda mencoba untuk menjaga pertanyaan saya terbuka - yang mana sekarang kami memiliki jawaban yang pasti. :)
Anonim

Tutorial singkat (sangat!) Di Git -> try.github.com/levels/1/challenges/1
MathAttack

Jawaban:


13

Mulai Sederhana

git init

Check-In Awal, Check-In Sering

Lakukan saja apa yang biasanya Anda lakukan dengan proyek apa pun: "check in" untuk setiap rangkaian perubahan yang terkait dengan tugas atau kelompok tindakan tertentu. Jika Anda menggunakan pelacak masalah, maka lakukan perubahan yang terkait dengan tugas setiap kali dalam kondisi stabil (lihat pertanyaan SO ini tentang seberapa sering melakukan ). Ini mungkin tidak dalam keadaan selesai, hanya yang stabil, di mana perangkat lunak tidak gagal untuk menjalankan atau situs gagal untuk dirender. Seperti yang dikatakan Jeff Atwood dalam jabatannya:

Jika kode tidak dicek ke kontrol sumber, maka tidak ada. [...]

Saya tidak menyarankan pengembang memeriksa kode rusak - tetapi saya juga berpendapat bahwa ada perbedaan besar antara kode rusak dan kode tidak lengkap.

Berkomitmen Sering, Sempurna Nanti, Publikasikan Sekali

Jika produk bahkan tidak dekat dengan kondisi yang bisa diterapkan, maka teruslah memeriksa perubahan sesuai keinginan Anda, menggunakan penilaian yang baik dan akal sehat untuk mengelompokkannya. Anda tidak perlu melakukan perubahan setiap baris file tunggal satu per satu, tetapi melakukan semuanya sebagai potongan besar akan membuat Anda lebih sulit untuk mengembalikan jika perlu.

Pada akhirnya, VCS Anda ada di sini untuk membantu Anda . Jadi bantu VCS Anda untuk membantu Anda !!

Jangan Terlalu Berpikir

Komitmen pertama Anda baik-baik saja. Jangan terlalu memikirkannya. Yang paling penting adalah mereka check-in. Jika Anda melihat semua proyek open-source yang ada secara online yang dimulai dari awal dan bukan dari basis kode yang ada, mereka memiliki revisi pertama yang mirip dengan:

menciptakan struktur direktori (yay!)

Jadikan itu Kebiasaan

Di akhir setiap hari, cobalah untuk membuat log dari apa yang telah Anda lakukan berdasarkan pada kom-log Anda. Jika output yang Anda peroleh git shortlogdan git logTIDAK terlihat memuaskan dan bermanfaat , namun Anda telah melakukan banyak upaya dalam proyek pada siang hari dan memeriksa perubahan itu, maka Anda mungkin tidak melakukannya dengan benar .

  • git shortlogharus dibaca seperti ikhtisar luas tentang apa yang telah Anda lakukan.
  • git logharus membaca seperti sejarah DAN kisah proyek Anda.

Ini adalah pedoman yang baik, dan saya akan menekankan "Don't Overthink It" (tentu saja itu berlaku untuk mengikuti pedoman juga ... :) - keluar dari sana dan hanya melakukannya adalah cara terbaik untuk belajar, dan orang-orang segera mendapatkan perasaan yang baik untuk gaya penggunaan apa yang paling cocok untuk mereka dan proyek mereka.
snogglethorpe

3

Apa yang Anda lakukan adalah pendekatan yang tepat.

Anda menggunakan kontrol sumber sejak hari pertama - ini akan memastikan bahwa Anda memiliki semua yang Anda butuhkan dalam kontrol sumber dan tidak ada titik di mana Anda dapat mengatakan:

Saya harus menggunakan kontrol sumber tetapi akan memakan waktu terlalu lama untuk memeriksa semua hal ini untuk pertama kalinya.

Ini adalah rintangan utama bagi orang-orang yang datang terlambat ke kontrol sumber karena mereka kemudian berpikir itu "terlalu sulit" untuk digunakan. Dengan memulai lebih awal dan melakukan perubahan sering kali Anda telah mengurangi rintangan itu menjadi langkah kecil dan siapa pun yang bergabung dengan Anda dalam proyek ini akan dapat langsung bekerja.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.