Alur kerja server produksi / pementasan Git


108

Saat ini website saya (server produksi) sudah memiliki banyak kode di dalamnya. Dan sekarang saya ingin mulai menggunakan Git untuk proyek saya dan menyiapkan server pementasan untuk tim saya. Adakah yang bisa memberi saya nasihat?

Inilah gambaran di benak saya:

        Production        - Production server which already have codes
            ↑             
         Staging          - New staging server, will install Trac too
         ↗↙ ↖↘          
  Developer1  Developer2  - Local development 

Pertanyaan saya adalah, bagaimana saya harus memulai?

Berikut beberapa langkah dalam pikiran saya:

  1. lakukan git initdi server produksi (apakah ini aman?)
  2. clone repo dari produksi ke server pementasan
  3. pengembang clonerepo dari pementasan ke mesin lokal mereka
  4. push file ke server pementasan setelah selesai diubah
  5. bila pementasan sudah siap, pushsemuanya untuk produksi

Apakah alur kerja ini masuk akal, atau ada cara yang lebih baik untuk melakukannya?

Bagaimana jika saya hanya ingin mengubah satu file?

Apakah origin / master ada hubungannya dengan proses ini ?? Siapa asalnya? apakah saya akan memiliki banyak asal ??

Juga, kapan harus digunakan pengembang branchdalam kasus ini?

Jawaban:


59

Lebih baik menggunakan cabang master hanya untuk cabang Produksi dan pengembangan untuk Pementasan. Setiap pengembang harus membuat cabang lokal untuk menambahkan fitur baru dan kemudian menggabungkannya dengan cabang pengembangan. Jika Anda baru mengenal git, coba gunakan - http://github.com/nvie/gitflow Ada juga gambar bagus yang menjelaskan model percabangan git - http://nvie.com/posts/a-successful-git- percabangan-model /


Ini jawaban yang lebih baik. Saya tidak terlalu paham dengan konsep percabangan Git.
kayue

@bU. Apakah Anda memiliki tautan ke beberapa sumber daya yang menjelaskan cabang pengembangan -> dorong ke sistem pementasan dan cabang master -> dorong ke server produksi secara lebih detail? Artikel yang luar biasa Model percabangan Git yang sukses tidak menyebutkan bagian itu meskipun ia menyebutkan konsep percabangan dan pembuatan versi yang sangat baik.
Edgar Alloro

19

Saran Anda terlihat oke, tapi saya tidak akan membiarkan pengembang mendorong langsung ke server pementasan. Sebaliknya, integrator harus dengan hati-hati meninjau cabang dan memasukkannya ke dalam cabang utama (atau cabang pengembangan jika Anda menggunakan model aliran git seperti yang disarankan oleh bUg.) * Orang yang sama akan mendorong ke server pementasan.

* Integrator : " Orang yang cukup sentral yang bertindak sebagai integrator dalam proyek grup menerima perubahan yang dibuat oleh orang lain, meninjau dan mengintegrasikannya dan menerbitkan hasilnya untuk digunakan orang lain ... "


1. lakukan git init di server produksi (apakah ini aman?)

Ya itu aman, tetapi Anda tentu saja harus mengatur izin yang sangat ketat pada repo ini. Saya mungkin akan memulai dengan curlmemasukkan seluruh situs web ke disk lokal, jika saya belum memilikinya.

2. mengkloning repo dari produksi ke server pementasan

Anda mungkin harus memiliki repo "pusat" yang terpisah dari produksi dan server pementasan. Yang itu bisa dikloning dan didorong sesuai kebutuhan.

3. pengembang mengkloning repo dari staging ke mesin lokal mereka

4. mendorong file ke server pementasan setelah selesai mengubah

5. ketika pementasan siap, dorong semuanya ke produksi

Ganti "pementasan" dengan "pusat" dan saya pikir Anda baik-baik saja, tetapi masalah yang lebih besar adalah bagaimana Anda akan bekerja dengan cabang dan penggabungan, seperti yang ditunjukkan oleh bUg.


10
1: Untuk membuat repo Git aman dalam produksi, pastikan untuk menambahkan file .htaccess dengan "Tolak Semua" di dalamnya.
kayue

2
2: Repo "Central" Felixyz mengacu pada repo telanjang. Gunakan perintah --bare untuk membuat repo telanjang.
kayue

1
@keyue 1: Bahkan lebih baik, tambahkan RedirectMatch 404 /\.gitke .htaccess produksi Anda untuk melindungi folder .gitignore , .gitattributes , dan .git Anda .
Leo
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.