it-swarm-id.com

Memulai dengan Subversion, Git, atau Sistem Kontrol Versi yang serupa untuk menjaga Sejarah File saya?

Saya menyadari ini mungkin pertanyaan yang luas di permukaan, tetapi saya sedang mencari contoh spesifik pengaturan/alur kerja yang digunakan orang untuk menyimpan riwayat versi file yang diedit di situs WordPress. Misalnya, ketika mengembangkan situs (dan bahkan setelah itu langsung), saya sering membuat perubahan pada file CSS dan PHP, tetapi saya tidak memiliki cara yang bagus untuk kembali ke versi file-file yang lebih lama. Untuk tujuan saya, membuat perubahan pada instalasi pengembangan lokal dan kemudian menyalin perubahan itu ke situs langsung sering kali lebih banyak masalah daripada yang saya inginkan. Adakah saran tentang cara memulai menggunakan alat versi untuk melacak pengeditan ke file di situs langsung?

31
Travis Northcutt

Saya tidak yakin seberapa banyak yang Anda ketahui tentang menggunakan kontrol versi, tetapi saya baru-baru ini beralih dari SVN ke GIT dan merasa hebat!

Meskipun itu tergantung pada Anda situs server hidup telah menginstal GIT (atau akan membiarkan Anda). Saya memiliki pengaturan GIT di server langsung juga, menjalankan cabang bernama sesuatu seperti production. Setiap kali saya selesai menerapkan/memperbaiki sesuatu secara lokal, saya menggabungkannya ke cabang production, kemudian SSH ke server situs langsung dan menarik perubahan. Ketukan menyeret file melalui FTP ketika Anda tidak pernah tahu apakah Anda menimpa perubahan, dll.

Saya akan merekomendasikan meluangkan waktu untuk melakukan aquatinted dengan GIT (jika Anda belum melakukannya), saya merasa jauh lebih mudah dan lebih mudah daripada SVN ketika harus mengubah/menambahkan banyak file (dan tidak seperti SVN itu tidak membuat bodoh folder .svn di mana-mana ).

Begitu:

Tentu, saya menggunakan Mac, maaf jika tidak ada yang berlaku.

Editor Kode: Coda Menginstal GIT melalui Ports (menggunakan Porticus) Git: GitX

Jika saya membuat semuanya baru, saya akan melakukan:

  1. Pasang Coda

  2. Instal Porticus (yang mengharuskan Anda untuk menginstal Ports, tetapi ada informasi di halaman itu)

  3. Setelah Anda menginstal Porticus, buka saja, cari "git-core" dan Instal itu.

  4. Unduh dan Instal GitX 7-5

  5. Ada panduan yang baik tentang pengaturan repo git di sini , tetapi pada dasarnya: 1. Buka Terminal. 2. cd ke tempat Anda ingin situs Anda berada. $: mkdir mysite && cd mysite 3. $: git init dan hanya itu! Jika Anda menambahkan file ke folder ini maka lanjutkan ke langkah berikutnya

  6. Setelah Anda menyiapkan repositori GIT secara lokal (artikel di atas) maka jika Anda membuka direktori itu di GitX Anda akan dapat melakukan hal-hal dll.

Pengaturan semuanya di server bisa sedikit rumit, saya punya MediaTemple dan akun Dreamhost yang keduanya memiliki GIT di luar kotak. Tautan di 5. memberi tahu Anda cara menambahkan repo jarak jauh, apakah Anda tidak perlu melakukannya sampai Anda ingin membawa situs langsung Anda ke dalam persamaan. Saya akan merekomendasikan agar semuanya berfungsi secara lokal terlebih dahulu (tidak seperti SVN, GIT tidak memerlukan repositori jarak jauh, sehingga Anda dapat meningkatkan semuanya pada mesin Anda untuk saat ini)

14
Joe Hoyle

Saya menggunakan SVN untuk kontrol versi dengan semuanya yang saya lakukan dalam pengembangan WordPress. Saya sebenarnya memulai dengan cara ini karena saya membutuhkan SVN untuk pengembangan plug-in ... begitu saya mulai di sana, itu adalah ekstensi alami untuk terus menggunakan SVN untuk tema dan skrip khusus di situs klien.

Pengaya

Karena plug-in sudah di-host di server WordPress, saya hanya memeriksa plug-in langsung ke direktori /wp-content/plugins/ instalasi WordPress lokal saya (saya menjalankan WAMP pada kotak pengembangan saya). Lalu saya membuat perubahan pada salinan lokal saya dan, ketika sudah siap untuk showtime, komit ke repositori. Ini adalah proses yang lancar di sana, tanpa mengunggah/mengunduh dan verifikasi instan bahwa perubahan saya berhasil.

Tema

Tema agak berbeda, terutama ketika membangun untuk klien. Saya membuat repositori lokal (saya memiliki partisi R pada hard drive saya khusus untuk keperluan ini) dan memeriksa repositori kosong langsung ke direktori /wp-content/themes saya. Lalu saya membuat perubahan sesuai kebutuhan dan mengembangkan sampai siap, melakukan revisi saat saya pergi.

Ketika saya siap untuk mempublikasikan tema ke server produksi klien, saya mengekspor repositori, Zip itu, dan menggunakan Tema asli >> Tambah fungsionalitas baru di WordPress. Ini berfungsi dengan plug-in khusus (yang tidak di-host oleh WordPress) juga.

Alat

Seperti yang saya katakan, saya menggunakan WAMP di mesin lokal saya untuk menjalankan instalasi pengembangan WordPress. Ini berfungsi dengan baik di kotak saya dan memungkinkan saya untuk menjalankan banyak contoh WordPress yang saya butuhkan untuk proyek tertentu.

Untuk SVN, saya menggunakan Tortoise SVN . Ini gratis, sangat mudah digunakan, dan terintegrasi dengan struktur file dan perintah Windows. Memperbarui, melakukan, dan mengekspor semua klik kanan sederhana, pilih operasi perintah. Menggunakan "Ekspor" memungkinkan Anda untuk mengirim seluruh folder (tanpa .svn folder yang mengganggu) secara langsung ke lokasi mana pun pilihan Anda - Saya sering mengekspor ke desktop. Zip folder juga merupakan operasi klik kanan, dan WordPress menangani unggahan.

Mentransfer file secara manual dapat merepotkan, terutama jika Anda terus mengubah satu file tetapi tidak semuanya. Jika Anda memilih FTP alih-alih seluruh direktori dengan "overwrite all" yang dipilih, jauh lebih mudah untuk mengganti file lama (dan Anda tidak harus melacak mana yang berubah dan mana yang tidak). Ini seperti instalasi WordPress 5-menit yang lama dulu - cukup ganti semuanya dengan versi baru.

8
EAMann

Secara pribadi, saya pikir ini adalah latihan yang menyenangkan untuk menginstal SVN/GIT dan mengelolanya, tetapi jika Anda dapat mengayunkan $ 15 per bulan, Beanstalk bernilai setiap sen. Mereka mengelola seluruh server untuk Anda. http://beanstalkapp.com/ Alat penyebaran FTP luar biasa. Milik saya secara otomatis menyebarkan versi ke server pementasan saya ketika saya komit misalnya

Cara lain untuk mendapatkan versi file pribadi adalah dengan menggunakan drop box. Setiap kali Anda menyimpan file ke dalam dropbox, ia melacak versi tersebut, dan Anda dapat mengembalikannya ke versi sebelumnya nanti .. Anda dan pengembang lain, atau grup dapat membagikan folder kotak drop. Memang ini tidak melakukan trunk, penggabungan, dll, tetapi itu membuatnya sangat mudah bagi tim yang didistribusikan untuk bekerja di satu situs web. Anda tidak bisa benar-benar bekerja pada file yang sama persis sekaligus.

Kami menyimpan salinan kerja SVN kami di dropbox, lalu saya komit file ketika waktunya menulis. Desainer saya tidak akan melakukan file atau berurusan dengan SVN, Jadi ini komprimise.

Saya lebih suka SVN karena saya tidak perlu semua trunking yang sangat bagus untuk GIT dan ada alat GUI yang lebih baik yang tersedia dari SVN.

3
Andrew

Saya suka Aptana , Subversionnya terintegrasi dan Anda dapat terhubung ke server dengan ftp/sftp dengan mudah dan mendorong file ke atas, fitur hebat lainnya yang itu adalah bahwa jika Anda membuat proyek php baru dan memasukkan folder WordPress "keseluruhan" (dengan wp-admin, wp-include) Anda mendapatkan penyelesaian kode dalam file tema Anda.

Dalam pengaturan saya, repo bersifat lokal.

2
Amit

Anda meminta "tetapi saya sedang mencari contoh spesifik pengaturan/alur kerja yang digunakan orang untuk menyimpan riwayat versi file yang diedit di situs WordPress" tetapi Anda juga menyebutkan produk :)

Anda mendapatkan di atas sebagai jawaban daftar alat dan beberapa praktik terbaik tetapi saya akan fokus di sini di alur kerja: MEREKA BUKAN WORDPRESS SPESIFIK:

Tetapi untuk contoh umum/pengaturan/alur kerja:

Sebagai permulaan: ADA pola CM, begitu independen dari tooling. Google on CM Patterns, banyak buku di luar sana, bahkan komunitas wiki mis. http://www.cmcrossroads.com/forums .

Ada juga panduan tentang menyiapkan strategi streaming yang valid (strategi google stream), dll ...

Saya tidak berpikir ada sesuatu yang istimewa tentang penyebaran WordPress dibandingkan dengan CM Management termasuk pengembangan paralel pada pabrik besar Siebel, SAP, Informatica, Java dll. Ini benar-benar hampir default.

Apa yang hilang, saya pikir, adalah tidak ada yang menulis CMplan untuk pengembangan WordPress (belum) (IEEE). Setelah seseorang melakukan itu (alat independen). Persyaratannya bisa diisi, saya pikir, dengan alat apa pun.

Saya pikir alasan bahwa rencana tersebut belum ditulis adalah bahwa hampir semua implementasi WordPress masih dilakukan oleh 1 orang dengan pengaturan pengembangan-produksi yang sederhana sehingga tidak dengan beberapa pengembang/desainer dalam tahap membangun harus menggunakan versi berbeda yang sedang berjalan di lingkungan uji, misalnya.

rencana CMP dimulai dengan mengidentifikasi semua CI dengan kata lain: buat daftar semua jenis hadiah CI dalam implementasi WordPress termasuk aplikasi, plugin, database, dokumentasi, bantuan, konten, file konfigurasi, catatan rilis (!), dll. ..) Itu awal yang baik. Kemudian putuskan mana yang ingin Anda bawa di bawah CM.

Selanjutnya tentukan apa yang menyebabkan perubahan pada CI ini, mis. panggilan pelanggan untuk perbaikan bug, atau peningkatan yang diperlukan. Jika dilakukan dengan benar, ini mengarah pada situasi di mana Anda merasa semuanya terkendali.

Keputusan seperti menggabungkan kembali dari produksi ke pengembangan dan cara untuk mengatasinya adalah bagian dari bab itu (2 pola utama di sini) (meskipun tentu saja Anda harus mencoba meminimalkan hotfix ini).

Hanya kemudian mencari alat untuk melakukan CM di satu sisi (yang mencakup manajemen versi sebagai salah satu alat) dan mengubah alat manajemen di sisi lain (yang membuat Anda tetap waras).

Saya pikir itu adalah alur kerja terbaik untuk memulai sejak, sejauh yang saya googled, belum ada yang melakukannya. Saya pikir begitu orang pertama telah menulis Rencana CM WordPress (menurut IEEE) setiap orang WordPress lain di dunia dapat menyalin rencana itu dan membuat penyesuaian serta menerapkan pola dalam perangkat mereka.

Bukankah itu terlalu banyak pekerjaan/terlalu berat: tergantung apakah Anda memiliki perusahaan atau tidak: itu bisa menghemat waktu besar Anda suatu hari untuk memiliki rencana CM yang baik.

1
edelwater

Saya menggunakan Host bersama sehingga saya tidak dapat menginstal SVN atau yang seperti itu. Saya menggunakan Mercurial untuk mengontrol versi di mesin rumah saya. Saya menggunakan sinkronisasi FTP Beyond Compare untuk menjaga sinkronisasi folder lokal dan jarak jauh.

0
CAD bloke

saya menggunakan git. itu mudah. Anda hanya harus memahami perintah sederhana seperti clone, comit, Push, pull dan Anda siap untuk pergi. itulah dasarnya.

walaupun, jika Anda menggunakan git lebih seperti mengoordinasikan tim untuk mengerjakan suatu produk, maka itu adalah level lain. tetapi pada akhirnya, layak menggunakan git atau kontrol versi apa pun. sudah ada alasan ketika hal itu terjadi.

0
justjoe