Alternatif untuk Kontrol Versi Profesional [ditutup]

57

Kami bekerja sama dengan beberapa bukan programmer (penulis) yang perlu berkontribusi ke salah satu proyek kami.

Sekarang mereka hanya tidak menyukai gagasan untuk menggunakan Git (atau apa pun juga) untuk versi yang mengontrol pekerjaan mereka. Saya pikir ini adalah karena mereka hanya tidak merasa berguna untuk membungkus kepala mereka di sekitar konsep memutar kontrol versi. (ketika saya pertama kali memperkenalkan mereka ke percabangan dan penggabungan - mereka tampak seperti saya menyinggung mereka.)

Sekarang, kita tidak dalam posisi untuk mendidik mereka atau meyakinkan mereka untuk menggunakannya. Kami hanya berusaha mencari alternatif agar kami mendapatkan semua versi pekerjaan mereka (yang kami butuhkan) - dan mereka mendapatkan alur kerja yang mudah dan berkonsentrasi pada apa yang mereka lakukan.

Saya telah datang dengan beberapa ide ...

  • beri tahu mereka untuk menyimpan pekerjaan mereka sebagai file terpisah setiap kali mereka membuat perubahan non-sepele, dan kemudian gunakan diff di pihak kita untuk hanya melacak perubahan.
  • menulis sebuah program (dengan Python) yang mengimplementasikan "tonggak" di CSSEdit dalam beberapa cara.

Tentang proyek:

Ini adalah sistem pemrosesan bahasa alami (ditulis dalam C + Python). Kami telah merekrut beberapa penulis untuk menyiapkan input untuk sistem dalam berbagai bahasa. Dan seiring kami mengembangkan perangkat lunak, kami membutuhkan para penulis itu untuk membuat perubahan pada masukan mereka (artikel). Terkadang perubahannya sangat kecil (satu atau dua kata), dan lain kali besar.

Alasan kita perlu mengontrol versi perubahan itu adalah karena setiap perubahan kecil / besar pada input memiliki potensi untuk mengubah output sistem secara dramatis.

programming-practices version-control teamwork treecoder
sumber
15
@ rwong - atau wiki dengan versi, itu juga bisa berfungsi.
Joris Timmermans
4
Menambah komentar @MadKeithV, bagaimana dengan wiki bertenaga git? github.com/github/gollum - Beberapa perubahan pada alur kerja akan dilakukan, Anda mencoba menjembatani dua tim. Sudahkah Anda menjelajahi alat mereka saat ini? Ada kemungkinan kecil mereka mendukung semacam kontrol versi dan penulis Anda tidak pernah repot-repot untuk mencari tahu ..
yannis
20
Ini sangat sederhana. Jika Anda akan membayar orang-orang ini, beri tahu mereka bahwa mereka dapat menggunakan alat Anda dan dibayar, atau jika mereka menolak untuk menggunakan alat Anda tidak dibayar. Jalan tengah apa pun akan berarti lebih banyak pekerjaan di pihak Anda, karena itu membutuhkan uang, itu menyeimbangkan untuk menemukan sekelompok orang yang akan bekerja dengan alat Anda.
Ramhound
4
Fossil adalah VCS menarik yang hadir dengan Wiki versi juga. Kami menggunakannya sebagai cara untuk menjaga agar dokumen tetap terbaru, tetapi Anda dapat menggunakannya untuk "versi" hal-hal seperti ini.
Ben Brocka
34
MENGAPA Anda mencoba memperkenalkan cabang dan bergabung dengan non-teknisi? Anda ingin pekerjaan mereka versi, baik. Anda dapat memberi tahu mereka bagaimana Anda ingin menyimpannya. Anda ingin mereka menangani cabang dan penggabungan, Anda akan keluar dari ujung yang dalam. Anda seharusnya memberi mereka sesuatu yang baik dan mudah, seperti Tortoise *, dan menghindari memberi tahu mereka apa pun yang sebenarnya tidak mereka butuhkan.
David Thornley

Jawaban:

102

ketika saya pertama kali memperkenalkan mereka ke percabangan dan penggabungan - mereka tampak seperti saya menyinggung mereka

Ini mungkin karena percabangan dan penggabungan adalah konsep-konsep canggih, dan jauh lebih tidak berguna daripada sekadar melacak perubahan.

Jadi mengapa tidak menjelaskan "komit" (simpan) dan "perbarui" saja? Dua konsep yang sangat sederhana . Saya yakin Anda bisa menjelaskannya dalam waktu kurang dari 10 menit.

Jika Anda benar-benar ingin menggunakan cabang terpisah dan hal-hal seperti itu, Anda dapat melakukannya sendiri tanpa melibatkan mereka.

Thomas Bonini
sumber
20
+1. Untuk tujuan mereka, menjaga sejarah garis lurus adalah gagasan yang radikal dan mengubah permainan. Saya pikir tidak mungkin seorang penulis akan benar-benar membutuhkan percabangan dan penggabungan, dan jika mereka melakukannya, mereka akan membutuhkan tangan dev untuk dipegang ketika mereka berhasil.
Dan Ray
7
@ Bill, apakah Anda benar-benar mencoba bergabung dengan git? Saya pikir ini bekerja dengan sangat baik, jauh lebih baik daripada dengan SVN. (Tapi saya tidak menganjurkan menggunakan penggabungan di tempat yang tidak diperlukan.)
svick
10
@ Bill K Jujur, ini terdengar seperti Anda perlu melakukan penangkapan setelah 20 tahun di SVN (jika genap). Bercabang dan menggabungkan mungkin benar-benar tidak masuk akal untuk para penulis ini, tapi saya tidak yakin bagaimana Anda berhasil memprogram selama 20 tahun tanpa pernah melakukan percabangan pada repo. Ada begitu banyak kasus di mana cabang adalah praktik yang baik dan memudahkan hidup Anda; pada kenyataannya, secara buta menolak konsep tersebut menunjukkan penilaian yang buruk (IMHO). Dalam SVN, bercabang itu menyakitkan, tetapi dengan git segalanya menjadi sangat mudah. Bantulah diri Anda sendiri, lewati ego Anda, dan investasikan satu sore untuk mempelajari dasar-dasar git. Anda tidak akan menyesalinya, berjanji!
Robin
6
@ user606723: TortoiseSVN dan TortoiseGIT menawarkan integrasi shell windows.
Roy Tinker
6
Saya cukup yakin bahwa mencoba mengajarkan Git tentang percabangan dan penggabungan dengan non-teknologi adalah pelanggaran hak asasi manusia.
Steve Bennett
69

Pendekatan yang agak tidak lazim hanya menggunakan Dropbox . Mintalah penulis menyimpan file di direktori dropbox dan Anda mendapatkan versi dan cadangan secara gratis. Plus pada dasarnya tidak ada kurva belajar untuk penulis.

Untuk git, sepertinya pada akhirnya Anda akan memberikan versi cabang yang benar kepada penulis, jadi masukkan saja repo git di dropbox dan pegang percabangan dan penggabungan untuk para penulis.

Oliver
sumber
21
Saya akan menyarankan hal yang sama. Tidak ada alasan mengapa Anda juga tidak dapat membuat folder di Dropbox sebagai git repo (mereka tidak perlu tahu) dan melakukan komitmen berkala (misalnya setiap hari). Dengan begitu Anda mendapatkan semua hal-hal git yang bagus (diff, log, membagi dua, dll) secara gratis.
Simon Whitaker
4
Pastikan Anda menggunakan versi berbayar, karena versi gratis hanya menyimpan versi selama ~ 30 hari jika saya ingat dengan benar.
DMan
5
Saya hanya dapat -1 jawaban yang menyarankan layanan eksternal, memperkenalkan satu titik kegagalan, dan menempatkan data Anda pada belas kasihan pengganggu potensial, ketika ada begitu banyak perangkat lunak yang berguna disarankan dalam jawaban lain di sini dan pihak-pihak yang terlibat disajikan secara eksplisit. sebagai programmer yang mampu.
sam hocevar
4
@ Davidvidhorn: Anda belum pernah mendengar masalah keamanan aktual dengan Dropbox ???
sam hocevar
3
@ Sam Hocevar: Oke, sekarang sudah. Itu adalah empat jam kerentanan, yang tentu saja tidak baik, tetapi tidak berarti itu adalah ide yang buruk. Sekali lagi, itu tergantung pada seberapa sensitif penulisan itu, dan jika peluang kecil itu bisa dilihat oleh orang luar dapat diterima. (Ini jelas tidak layak untuk catatan medis, tetapi saya tidak punya keraguan untuk meninggalkan fiksi buruk dan proyek perangkat lunak yang belum selesai di sana.)
David Thornley
28

Sejujurnya jawabannya ada dalam suntingan Anda: "Kami telah merekrut beberapa penulis" - kadang-kadang Anda hanya harus berpikiran berdarah ... mereka ingin uang Anda, mereka harus melakukan apa yang Anda inginkan asalkan apa yang Anda inginkan tidak masuk akal.

Argumen yang Anda buat adalah argumen yang telah Anda ajukan - kita harus dapat melakukan X, Y dan Z untuk membuat produk berfungsi - dan untuk melakukan ini, kami ingin Anda melakukannya. Kami akan mendukung yang kami bisa, tetapi agar ini berhasil (dan karena itu agar terus berlanjut sebagai aliran pendapatan untuk Anda, penulis) ini harus terjadi.

Saya cenderung setuju bahwa solusi berbasis Wiki yang tepat tampaknya akan menjadi pasangan yang baik - tetapi tantangannya di sini adalah bagaimana menemukan kompromi antara alur kerja mereka dan persyaratan Anda.

Saya akan mengulangi poin utama - agar proyek Anda sukses, Anda perlu artikel untuk diversi sehingga orang yang mengerjakan artikel harus bermain dengan seperangkat aturan yang disepakati, jika ini tidak terjadi, Anda akan mendapatkan dibakar dan dengan ekstensi demikian juga para penulis.

Murph
sumber
Saya sangat setuju dengan anda. Tapi Anda lihat ada sesuatu yang disebut "manajemen" antara kami (tim programmer) dan para penulis. Manajemen merekrut para penulis, dan menyuruh kami bekerja bersama mereka. Fakta bahwa mereka enggan mempelajari kontrol Versi adalah sesuatu yang manajemen lihat sebagai masalah perlu "disesuaikan" antara kami (tim) dan mereka (programmer).
treecoder
1
Saya agak menebak ... tetapi kemudian Anda harus membuat kasus Anda ke manajemen, dan itu kasus yang sama. Mereka benar bahwa itu adalah sesuatu yang perlu "disesuaikan" (pilihan kata yang menarik) - tetapi kompromi adalah hal dua arah, Anda harus memberi mereka sesuatu yang dapat mereka kerjakan, mereka harus bekerja dengannya.
Murph
Yay - downvote tanpa penjelasan, selalu seperti itu.
Murph
2
@greengit Masalah yang perlu "disesuaikan" antara tim adalah bagian dari tujuan manajemen. Mendelegasikan tanggung jawab kepada satu tim adalah malas, atau mungkin petunjuk bahwa manajemen akan lebih memilih pendekatan tim itu. Jadi saya sarankan Anda menyarankan untuk mengelola solusi yang lebih masuk akal bagi Anda, dan biarkan mereka khawatir tentang hal lain.
yannis
3
Saya memiliki kecenderungan untuk menyajikan "penyesuaian" ini kepada manajemen dalam bentuk anggaran untuk perubahan yang diajukan. "Tentu, kita bisa menghindari penggunaan mereka (git, ...). Kita perlu menyewa seorang sekretaris untuk melakukannya untuk mereka. Masuk di sini dan aku akan memulai wawancara pada hari Senin."
BRPocock
18

Saya harus berurusan dengan situasi yang sama seperti ini sebelumnya. Pada akhirnya kami hanya menunjuk satu pengembang (saya) sebagai titik kontrol versi kontak untuk pihak ke-3.

Pihak ketiga akan mengirimi saya file zip file proyek mereka setiap hari dan saya akan melakukan checkin untuk mereka. Saya menyiapkan ruang kerja proyek terpisah dan akun svn untuk mereka dan akan membuka ritsleting file ke ruang kerja itu menimpa apa yang ada di sana dan kemudian melakukan checkin di bawah akun itu.

Itu bukan hal yang paling menyenangkan untuk dilakukan setiap hari, tetapi kadang-kadang lebih penting untuk menyelesaikan pekerjaan saja.

Satu plus adalah bahwa hal itu membantu saya meninjau pekerjaan mereka untuk memastikan mereka tidak memeriksa kode dan data yang buruk yang akan merusak build.

Alan Barber
sumber
+1 Jika itu mungkin, itu akan menjadi "masalah terpecahkan!" untuk kita. Itu bukan karena kami adalah perusahaan kecil dan saya tidak berpikir menyarankan untuk menyisihkan satu pengembang sebagian atau hanya untuk tugas ini akan mengembalikan senyum kepada saya dari manajemen (idiot). Sungguh, saya merasa tentang manajemen kami seperti itu.
treecoder
2
@ Grengeng - Jika Anda menyarankan ini adalah satu-satunya solusi yang Anda rasa akan berhasil, maka biaya akan memaksa manajemen untuk mempekerjakan orang yang berbeda, yang akan bekerja dengan alat Anda. Tentu saja Anda dapat menjelaskan kepada manajemen bahwa solusi APAPUN kecuali kontrol versi AKAN MENGHASILKAN UANG baik Anda mengatasi masalah (dan menyelesaikannya) yang diciptakan oleh pekerjaan sekitar atau menghabiskan waktu ekstra untuk mencoba mencegah masalah (kecuali Anda mengabaikan kedua poin kunci tersebut) , masalah akan terjadi, sebenarnya mereka akan terjadi tidak peduli apa).
Ramhound
3
@ Grengeng Jelas itu akan tergantung pada apa yang semua terlibat dalam proses Anda, tetapi dalam kasus saya butuh waktu kurang dari 5 menit sehari untuk memilih kembali file pihak ke-3. Itu adalah solusi saya untuk mengurangi buang-buang waktu mencoba mengembangkan proses dan melatih pihak ke-3 di atasnya.
Alan Barber
Seharusnya tidak sesulit itu. Satu orang adalah antarmuka dari penulis ke sistem kontrol versi. Mereka tahu untuk menyerahkan semua perubahan mereka kepadanya. Seharusnya tidak membawanya lebih dari satu atau dua menit untuk menjatuhkan perubahan mereka di tempat dan melakukan mereka.
Dan Ray
@ Grengeng - Ini akan menjadi jawaban saya. Ya, butuh waktu untuk melakukan pekerjaan yang bermanfaat. Menulis sistem khusus (yang tampaknya ingin Anda lakukan) akan membutuhkan lebih banyak waktu. Dan para penulis masih akan mengeluh.
Mike Baranczak
18

SparkleShare adalah dropbox-clone berbasis git, saya pikir itu sesuai dengan kebutuhan Anda.

SparkleShare membuat folder khusus di komputer Anda. Anda dapat menambahkan folder yang di-host (atau "proyek") dari jarak jauh ke folder ini. Proyek-proyek ini akan secara otomatis disinkronkan dengan host dan semua rekan Anda ketika seseorang menambahkan, menghapus, atau mengedit file.

... inilah beberapa contoh dari apa yang dilakukannya dengan baik dan kurang baik dengan wajah tersenyum:

Bagus

  • Sering mengubah file proyek, seperti teks, dokumen kantor, dan gambar
  • Melacak dan menyinkronkan file yang diedit oleh banyak orang
  • Mengembalikan file ke titik mana pun dalam riwayatnya
  • Mencegah memata-matai file Anda di server menggunakan enkripsi

Tidak begitu bagus

  • Cadangan komputer lengkap
  • Menyimpan koleksi foto atau musik Anda
  • File biner besar yang sering berubah, seperti proyek pengeditan video ...

Pembaruan (November 2015) : Proyek ini tampaknya ditinggalkan (rilis terakhir dari April 2014).

agas
sumber
Sangat menjanjikan, tapi mungkin agak tidak dewasa. Saya pasti akan mengawasi ini.
Zsolt Török
13

Jika Anda dapat memberikan ruang kerja siap dengan transparan VCS-penggunaan, mereka akan menggunakan VCS. Jangan mengajari non-programmer untuk menggunakan VCS dengan cara programmer

Temukan saja editor dengan dukungan VCS tertanam, konfigurasikan, dan tampilkan langkah mudah tambahan dalam karya mereka.

Sebagai contoh - Editplus tahu tentang Subversion, memiliki kemampuan untuk melakukan operasi dasar SVN di dalam jendela editor. Editplus terbaru bahkan dapat menggunakan TortoiseGIT untuk Integrasi Git

Sunting : menemukan solusi alternatif beberapa arah: EasySVN , yang, jika dikonfigurasikan dengan benar, memantau copy pekerjaan dan melakukan autocommit dan automerge, memungkinkan untuk menggunakan alat authoring apa pun untuk pengguna akhir dan format dokumen apa pun

Malas Badger
sumber
11

Bagaimana dengan pengaturan WebDAV ?

Ini akan secara otomatis menangani sejarah versi garis lurus untuk mereka. Yang harus mereka lakukan adalah terhubung ke server seolah-olah itu drive jaringan dan setiap penyimpanan akan menjadi komit.

Malfist
sumber
+1 untuk WebDAV. Benar-benar tidak memikirkan opsi itu. Seberapa sulit menurut Anda akan menggunakan dan memelihara server WebDAV (+ workflow)
treecoder
Ini sangat sederhana, Anda mengatur apache, subversi, repo. Kemudian Anda menginstal modul apache dan mengkonfigurasinya dan Anda sudah selesai.
Malfist
-1 karena "otomatis" bukan kata.
dreftymac
4
@dreftymac en.wikipedia.org/wiki/Hair-splitting
SplinterReality
1
Mungkin, Anda dapat membuat jawaban ini lebih eksplisit: Mengatur Subversion + Apache + WebDAV di server dan me-mount berbagi WebDAV dari klien yang bukan pengembang. Beri tahu pengguna untuk menyimpan bahwa mereka bekerja di berbagi WebDAV setidaknya sekali sehari.
Jan
7

Google Documents

Google Documents dapat melakukan apa yang Anda inginkan. File > See Revision Historyakan memungkinkan Anda melacak perubahan.

Anda juga punya masalah menyerahkan file bolak-balik diurus secara gratis; cukup bagikan dokumen di antara semua orang.

Akhirnya, mudah digunakan; para penulis bahkan tidak perlu tahu bahwa ada versi yang terjadi.

Nathan Long
sumber
6

OS Agnostik

Tulis program Python yang dapat Anda seret dan jatuhkan file, program itu kemudian dapat melakukan git adddan git commitdan apa yang tidak dan mereka tidak pernah harus menghadapinya.

atau

Gunakan sistem file berbasis WebDav Anda dapat memasang di mesin mereka dan meminta server melakukan githal - hal secara transparan.

OSX / Linux

Tulis sebuah plugin FUSE berbasis Python yang mengambil file-file tersebut dan berkomitmen untuk git. Kemudian mereka bisa membuka dan menyimpan dari sistem file yang dipasang secara transparan. Ada beberapa SEKERING untuk sumber daya Windows , tetapi mereka mungkin bahkan tidak layak untuk dibodohi.

Windows

Anda mungkin dapat menulis beberapa kode untuk menggunakan Driver Filter FileSystem untuk melakukan githal - hal secara transparan .

pengguna7519
sumber
5

Ah, kegembiraan yang bukan coders mucking. Saya sarankan agar lingkungan git / mercurial diatur untuk mereka. Katakan pada mereka untuk menyimpan semuanya dalam format yang bisa ditangani oleh repo. Dengan tortoisegit atau tortoisehg , mereka tidak perlu tahu bagaimana repo bekerja. Mereka hanya memeriksa apakah mereka memiliki tanda seru di direktori proyek mereka, klik kanan file yang menyinggung, dan klik komit. Ketikkan sinopsis perubahan (itu adalah penulis, bukan?) Dan Anda selesai!

Langkah ekstra dalam alur kerja untuk mereka, tetapi tidak ada yang terkait dengan penggabungan / percabangan / hal-hal keren. Lingkungan pra dibangun sudah diatur untuk berada di cabang penulis, sehingga mereka tidak melihat kode. Minta skrip otomatis disinkronkan setiap hari. Kemudian, setelah mereka terbiasa melakukan, Anda dapat menunjukkan kepada mereka fitur tambahan. Kemampuan untuk melihat apa yang berubah ketika sangat berguna sehingga mereka tidak akan bisa melakukannya tanpanya, begitu Anda menyelinap ke dalam alur kerja mereka.

Spencer Rathbun
sumber
5
Satu hal yang saya sadari adalah bahwa semua (YMMV) penulis non-teknis hanya menganggap karya mereka sebelumnya tidak berguna, begitu mereka melakukan perubahan. Mereka pikir karya yang diperbarui (artikel atau apa pun yang mereka tulis) adalah yang terbaik, dan bodoh untuk mempertahankan versi sebelumnya. Meskipun dalam kasus kami, kami setidaknya telah berhasil menjelaskan kepada mereka mengapa kami juga membutuhkan sejarah.
treecoder
@ Greeng mungkin. Jika Anda menunjukkan bagaimana Anda mengakomodasi mereka untuk manajemen, bagaimana langkah sederhana dan mudah ini membantu Anda, dan bagaimana ini menghemat / menghasilkan uang perusahaan, maka mereka harus tetap melakukannya. Bisnis didorong oleh garis bawah, jadi beri tahu bos bahwa ini mengintegrasikan penulis ke dalam pipa teknis dan menghemat uang pada biaya integrasi, cadangan (Anda mendukung repo, kan?), Dan informasi yang lewat.
Spencer Rathbun
+1 Kami juga telah mengatur koordinator proyek dan staf layanan pelanggan kami untuk menggunakan TortoiseSVN. Setelah penjelasan awal (dan membantu mereka dengan inital checkout), mereka tidak memiliki masalah dalam melakukan perubahan versi mereka (kebanyakan dokumen kantor dan gambar mockup). Mereka bahkan suka bahwa mereka secara otomatis mendapatkan versi terbaru jika seorang kolega mengubah sesuatu.
sleske
3

Bagaimana dengan Share Point? Saya tahu itu tidak populer di dunia pengembangan tetapi jika penulis Anda menggunakan Windows sebagai OS, itu akan bekerja dengan baik dan mereka tidak akan benar-benar tahu bahwa mereka menggunakan kontrol versi (Nilai tambah besar untuk pekerjaan saya).

Solusi ini juga menjaga mereka dari berurusan dengan apa pun yang akan membuat mereka takut, karena tampaknya mereka tidak senang dengan hal-hal baru.

JustinDoesWork
sumber
Memberi +1 karena inilah yang sudah dilakukan tim kami, dan berhasil.
sq33G
Saya lebih suka bekerja dengan sistem kontrol versi yang tepat untuk SharePoint, di mana beberapa dokumentasi perusahaan kami berada, karena mengunggah versi baru ke SharePoint membutuhkan lebih banyak pekerjaan.
Chris Morgan
2

Bisakah Anda mengatur alat yang memonitor sistem file di mana penulis menyimpan file mereka dan melakukan itu melakukan komit otomatis setiap kali mereka membuat menyimpan?

Jika Anda meletakkannya di jaringan berbagi Anda bisa melakukan semua konfigurasi tanpa melibatkan mereka sama sekali; tetapi setiap kali mereka menyediakan versi terbaru untuk digunakan tim Anda, itu akan ditambahkan ke git untuk Anda.

Dan Neely
sumber
1

Apakah Anda melihat Plastik SCM. Mereka berusaha membuatnya lebih mudah untuk digunakan

Jika Anda hanya ingin cadangan berversi, Anda dapat menggunakan Dropbox atau Anda dapat mengatur layanan cadangan Windows. Atau Anda dapat menginstal Crashplan atau produk serupa lainnya.

Amala
sumber
+1 untuk mengarahkan saya ke penawaran komersial baru di ranah DVCS
Roland Tepp
1

Untuk Mercurial DVCS, ada antarmuka pengguna yang disebut EasyMercurial , yang tujuannya dinyatakan secara eksplisit untuk memberikan pandangan sederhana tentang operasi kontrol versi dasar.

EasyMercurial dimaksudkan untuk:

  • sederhana untuk mengajar dan mempelajari indikasi keadaan repositori yang sebenarnya, menggunakan representasi grafik sejarah
    • dekat dengan alur kerja command-line normal untuk Mercurial konsisten di seluruh platform

Kami tidak berusaha menghasilkan klien Mercurial "terbaik" untuk satu tujuan apa pun. Kami secara aktif mendorong pengguna untuk pindah ke klien lain saat kebutuhan mereka berkembang. Tujuannya hanya untuk menyediakan sesuatu yang dapat diakses oleh pemula dalam kelompok proyek kecil yang bekerja dengan repositori jarak jauh bersama.

Saya akan merekomendasikan mencobanya.

Laurens Holst
sumber
1

Saya harus bekerja dengan non-programmer berkali-kali (kebanyakan seniman grafis, dan jika penulis Anda memiliki sedikit petunjuk bagaimana mengelola file kerja sebagai seniman maka Anda berada dalam untuk ... h'mmm .... menyenangkan .. .). Ada tiga pendekatan yang mungkin:

  1. Berpura-pura mereka adalah programmer, cobalah untuk mengajari mereka cara menggunakan kontrol versi. Ini tidak akan berhasil dan Anda akan terus bertengkar.
  2. Tuliskan mereka alat yang sangat sederhana yang hanya mengambil versi saat ini & menempelkannya di suatu tempat sehingga mereka dapat memundurkan ke file kemarin jika perlu. Ini mungkin, dan saya melakukan ini untuk tim pembuat DVD (membuat menu, grafik, segala macam hal) bertahun-tahun yang lalu dengan beberapa keberhasilan: alat yang saya tulis adalah pembungkus satu-klik untuk PkZip (Anda dapat melihat ini adalah beberapa waktu yang lalu) dan itu hanya zip direktori kerja dan menamai arsip untuk tanggal + waktu.
  3. Kendalikan apa yang mereka hasilkan sendiri. Jelaskan bahwa file-file mereka harus dikirim ke programmer dan hanya menjadi bagian dari proyek ketika programmer menerima file: programmer kemudian memeriksanya ke dalam kontrol versi dan konten dikelola secara profesional.

Secara pribadi saya pikir opsi 3 adalah cara untuk pergi. Ini berarti rasa sakit & iritasi bagi siapa pun yang harus mengambil pengiriman file dan memeriksanya, tetapi jauh lebih sedikit daripada opsi lain.

Saya juga akan mengatakan, perlu diketahui bahwa non-programmer akan mengirimkan file dengan nama file lama yang dapat Anda pikirkan. Konvensi penamaan anehnya asing bagi mereka. Mereka akan memberi Anda file yang disebut "Gambar" atau sesuatu dan kemudian ketika Anda memberi tahu mereka hal-hal yang salah dengan itu akan memberi Anda file yang disebut "Picture_Final", yang hanya memperbaiki sekitar 3 kesalahan. Ketika Anda menunjukkan ini, Anda akan mendapatkan file lain, yang disebut "Picture_NewFinal", dan kemudian (jika Anda beruntung) "Picture_NewFinal2", meskipun ada kemungkinan bahwa mereka pada saat ini akan membuang semua perkembangan sejarah dan menyebutnya "Spanner Icon benda".

Sekali lagi Anda dapat mencoba menegakkan konvensi penamaan, yang berarti memberi tahu mereka terlebih dahulu tentang apa setiap file yang akan dipanggil, atau Anda dapat menghabiskan waktu berjam-jam menguraikan & mengganti nama apa yang mereka kirim kepada Anda. Di sini saya akan mengatakan Anda ingin spreadsheet untuk kewarasan Anda sendiri, jadi cobalah membuat mereka untuk mengikutinya: hanya jangan terkejut ketika mereka tidak.

Semoga itu bisa membantu - bersenang-senanglah!

AAT
sumber
0

Jika ada kemungkinan bahwa keduanya harus bekerja pada target yang sama sekaligus DAN jika Anda dapat menangani semua pekerjaan mereka dalam file teks, saya akan mencoba berbagi google docs.

Ini memiliki kemampuan multi-editor / kolaborasi yang luar biasa - sejauh ini yang terbaik yang pernah saya lihat. Mereka juga versi lengkap dan dapat diekspor sebagai file teks.

Tapi itu adalah dua seandainya cukup besar.

Bill K
sumber
0

Biarkan mereka bekerja di folder, menyimpan file seperti biasa.

Sekali sehari (atau seminggu, dll) salin isi folder itu ke backup_dd_mm_yyyy Kebanyakan kode sumber sistem menempati jumlah ruang yang sepele mengingat ruang yang tersedia saat ini.

Salinan dapat dilakukan oleh Anda, mereka, pihak ketiga, alat atau skrip.

Ini membatasi kerugian hingga satu hari, memberikan sejarah, transparan bagi mereka.

Tidak sempurna untuk salah satu pihak tetapi jawaban yang berusaha untuk mencapai jalan tengah.

Michael Durrant
sumber