WordPress dan Alur Kerja Git

Saya tahu pertanyaan ini telah ditanyakan ribuan kali, tetapi saya benar-benar mencoba mencari cara untuk mendapatkan yang terbaik dari Git ketika bekerja dengan WordPress.

Saya telah menjelajahi web dan membaca puluhan artikel, semua yang sepertinya membahas topik tersebut secara singkat. Inilah beberapa yang paling terkenal yang pernah saya baca baru-baru ini.

- Versi Mengontrol WordPress

- Mengelola Penyebaran Tema WordPress dengan Git

- Kelola tema WordPress khusus Anda menggunakan git, bukan FTP

Saat ini, alur kerja saya terlihat seperti ini.

• Instal WordPress secara lokal
• Kembangkan Tema
• Ekspor Database WordPress dari server lokal
• Impor Database WordPress ke server jarak jauh
• Unggah file dan tema WordPress melalui FTP
• Klien melakukan perubahan
• Unduh file dan tema WordPress melalui FTP dan ekspor Database WordPress dari server jarak jauh
• Ganti file secara lokal
• Buat perubahan pengembangan
• Unggah kembali melalui FTP, ekspor dan impor basis data ke server jauh

Saya menyadari bahwa Git dapat merampingkan proses ini. Tampaknya cara terbaik untuk melakukan ini adalah memiliki file .gitignore yang mengabaikan direktori tertentu yang tidak perlu dilacak, serta memiliki file wp-config.php lokal dan remote.

Tetapi bagaimana Anda menangani basis data? Klien biasanya akan melakukan perubahan (posting / halaman / plugin). Apakah saya masih perlu mengekspor dari basis data jauh dan mengimpor kembali di server lokal saya?

Dapatkah seseorang menyarankan alur kerja terbaik untuk saya di sini? Dan menuntun saya melalui langkah-langkah.

Juga, saya mungkin ingin menggunakan Bitbucket sebagai repo pribadi dengan mereka gratis, tidak seperti GitHub.

Bantuan apa pun akan dihargai.

Terima kasih sebelumnya!

Saya salah satu pengembang WP Migrate DB Pro , dan ingin menjawab pertanyaan @ Ennui:

"Apakah kamu tahu kalau skrip db url replace yang dijalankannya mempertimbangkan string serial?"

Ya, itu menangani data serial. Sebenarnya, itulah alasan utama saya mengembangkan versi gratis dari plugin ini pada tahun 2009. :)

Sayangnya saya hanya memiliki reputasi 41, jadi saya tidak bisa membalas komentar @n Ennui. Maaf untuk itu.

Saya membatasi pemungutan suara untuk menutup ini sebagai "tidak konstruktif" karena tampaknya merupakan hal yang akan mendorong debat dan opini daripada jawaban. Tapi...

Itu bukan seperti apa aliran pekerjaan saya, dan itu membuat pendekatan saya (dan jawaban) berbeda dari sebagian besar sisa jawaban sejauh ini.

1. Instal WordPress secara lokal
   1. Ini diklon dari repo telanjang Git lokal yang berisi rilis stabil terbaru.
   2. Saya juga menyimpan salinan lokal dari rilis terbaru beberapa plugin yang hampir selalu saya instal.
2. Bangun tema dan semua plugin yang diperlukan
3. Unggah ke server pementasan publik
   1. Klien diberi akses tetapi tidak dapat mengubah kode dan memberi tahu bahwa pengeditan basis data tidak akan ditransfer ke situs produksi.
   2. Ini berarti bahwa tidak ada alasan untuk mengunduh kode kembali ke server pengembangan.
   3. Dan tidak ada alasan untuk menyinkronkan ulang basis data lokal
4. Buat perubahan pada situs lokal berdasarkan staf kami dan umpan balik klien.
5. Unggah perubahan
6. Ulangi seperlunya (tetapi dengan meningkatnya resistensi :))
7. Jika kami menyediakan konten, yang tidak selalu demikian, kami (bukan klien) akan membersihkan database pada server pementasan dan mengunggah konten.
8. Menyebarkan dengan mengunggah kode lokal ke situs produksi.
9. Jika kami telah membuat konten, konten diekspor dari situs pementasan melalui alat ekspor vanila dan diimpor ke situs produksi.
   1. Ini adalah satu-satunya waktu saya harus memindahkan database, dan itu dilakukan dengan alat yang cukup standar. Saya akan menggunakan URL Pembaruan Velvet Blues untuk membersihkan basis data jika diperlukan.
10. Debug
11. Tamat

Pada dasarnya, saya menjauhkan klien dari barang-barang saya sebanyak mungkin sampai kami menyerahkan situs.

Kode bergerak satu arah - dari lokal ke panggung atau produksi. Tidak pernah bergerak sebaliknya. Itu menghilangkan beberapa langkah Anda dan memberi saya ketenangan pikiran. Saya tidak ingin disalahkan karena mengutak-atik klien dalam kode saya dan saya tidak ingin mengimpor beberapa file yang diretas, yang merupakan kemungkinan yang tidak nol.

Dan basis data hanya bergerak sekali, jika sama sekali, yang sangat mengurangi masalah. Jadi saya kira saya mengelola masalah "pemindahan basis data" dengan mengurangi atau menghapus kebutuhan untuk memindahkan basis data. Ini juga mengurangi masalah korupsi basis data yang dapat muncul dan mengurangi kemungkinan mengimpor peretasan.

Benar, saya harus mengkonfigurasi situs produksi - permalinks, menu, dll - tetapi itu memaksa saya untuk bekerja di situs produksi jadi saya menganggapnya semacam debugging. Ini membantu saya memastikan bahwa semuanya berjalan di lokasi produksi seperti seharusnya.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Saya belum mencoba ini sendiri (belum), tetapi klaim untuk menyebarkan semuanya - termasuk DB.

Ada juga tutorial untuk diikuti: Tutorial bagian 1 | bagian 2

Lihatlah tumpukan batuan dasar . Ini menggunakan komposer untuk mengelola versi Wordpress dan plugin pihak ketiga, dan juga termasuk capistrano untuk penyebaran, dan gelandangan / memungkinkan untuk menyiapkan server termasuk server virtual lokal untuk pengembangan.

Saya baru-baru ini melakukan banyak pengujian mengenai hal ini dan di sini adalah alur kerja yang saya gunakan, yang tidak cukup banyak apa yang Anda minta:

• Saya menggunakan wp-cli untuk mengelola inti wordpress dan memperbarui wordpress.
• Saya menggunakan komposer bersama dengan http://wpackagist.org untuk mengelola plugin dan dependensi tema.
• Saya menggunakan git dan meletakkan file inti wp di .gitignore. Jadi sebagian besar file tema wp-config.php dan child ada di git.

Saya tidak terbiasa dengan alat migrasi db tetapi akan menjadi tambahan yang bagus untuk alur kerja ini.

Berikut ini rincian lengkap tentang alur kerja http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Mengenai database "kloning", saya menggunakan WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

Ini adalah layanan berbayar, tetapi tidak memerlukan biaya banyak, dan dengan mudah memungkinkan Anda untuk menarik atau mendorong basis data Anda dari pengembang Anda ke server langsung Anda dan sebaliknya. Itu mengubah URL dan segala sesuatu yang perlu diubah di jalan.