私たちは、プロジェクトの1つに貢献する必要のある非プログラマー(ライター)とチームを組んでいます。
現在、彼らは、Git(またはそのことについては何か)を使用して作業をバージョン管理するという考えを好んでいません。これは、バージョン管理のねじれた概念に頭を抱えるだけの価値がないためだと思います。 (私が最初にそれらをブランチとマージに紹介したとき-彼らは私がそれらを怒らせているように見えました。)
現在、私たちは彼らを教育したり、それを使用するように説得したりする立場にはありません。すべての作業をバージョン管理するために代替案を見つけようとしているだけです(これが私たちに必要なことです)。ワークフローが簡単になり、作業に集中できます。
いくつかのアイデアを思いついた...
プロジェクトについて:
これは自然言語処理システムです(C + Pythonで記述)。さまざまな言語でシステムの入力を準備するために、何人かのライターを雇いました。ソフトウェアを進化させるにつれ、それらのライターが入力(記事)を変更する必要があります。変化が非常に小さい(Wordまたは2つ)場合もあれば、大きい場合もあります。
これらの変更をバージョン管理する必要がある理由は、入力のすべての小さな/大きな変更がシステムの出力を劇的に変更する可能性があるためです。
私が最初にそれらをブランチとマージに紹介したとき、彼らは私がそれらを怒らせているように見えました
これはおそらく、分岐とマージが高度な概念であり、単に変更を追跡するよりもはるかに有用性が低いためです。
では、「コミット」(保存)と「更新」だけを説明してはどうでしょうか。 2つのreally simpleの概念。 10分足らずで説明できると思います。
本当に別のブランチやそのようなものを使用したい場合は、それらに関与せずに自分でその部分を行うことができます。
どちらかといえば非正統的なアプローチは、単に Dropbox を使用することです。作成者にファイルをDropboxディレクトリに保存してもらい、バージョン管理とバックアップを無料で入手できます。加えて、基本的に著者のための学習曲線はありません。
Gitの場合、結局のところ、とにかく正しいブランチバージョンを作成者に提供することになるので、ドロップボックスにgitリポジトリを配置して、作成者のブランチとマージを処理します。
正直に答えはあなたの編集にあります:「私たちはいくつかの作家を雇いました」-時々あなたは血の気になる必要があります...彼らはあなたが望むことを提供するために彼らがしなければならないお金を望んでいますあなた無理はありません。
あなたがする議論はあなたがすでに進んでいる議論です-私たちは製品を機能させるためにX、Y、Zを行うことができる必要があります-そしてこれを行うために私たちはあなたにそれをする必要があります。私たちはできる限り支援しますが、これが機能するためには(そしてそれがあなたのための収入の流れとして継続するためには)、これは起こらなければなりません。
私は、適切なWikiベースのソリューションが適切であるように思われることに同意する傾向がありますが、ここでの課題は、ワークフローと要件の間の妥協点を見つける方法です。
重要なポイントを繰り返します。プロジェクトを成功させるには、記事をバージョン付けする必要があります。したがって、記事に取り組んでいる人は、これが起こらなければ、合意された一連のルールに従ってプレイする必要があります。 will書き込みが行われ、拡張機能によって書き込みが行われます。
以前にもこのような状況に対処しなければなりませんでした。最後に、1人の開発者(私)をサードパーティのバージョン管理連絡先として指定しました。
サードパーティからプロジェクトファイルのZipファイルが毎日メールで送られてきて、チェックインを行います。個別のプロジェクトワークスペースとsvnアカウントをセットアップし、ファイルをそのワークスペースに解凍してそこにあったものを上書きし、そのアカウントでチェックインを実行します。
毎日やるのは楽しいことではありませんでしたが、仕事を終わらせることの方が重要な場合もあります。
プラス点の1つは、ビルドを壊す不正なコードやデータをチェックインしていないことを確認するために作業を確認するのに役立ちました。
SparkleShare はgitベースのドロップボックスクローンです。ニーズに合っていると思います。
SparkleShareはコンピューター上に特別なフォルダーを作成します。このフォルダーには、リモートでホストされるフォルダー(または「プロジェクト」)を追加できます。これらのプロジェクトは、誰かがファイルを追加、削除、または編集したときに、ホストとすべてのピアと自動的に同期されます。
...ここでは、スマイリーフェイスでうまくいく、またはうまくいかない例をいくつか示します。
すごい
- テキスト、Officeドキュメント、画像などの頻繁に変更されるプロジェクトファイル
- 複数の人が編集したファイルの追跡と同期
- ファイルをその履歴の任意の時点に戻す
- 暗号化を使用してサーバー上のファイルのスパイを防止する
あまり良くない
- コンピュータ全体のバックアップ
- 写真や音楽のコレクションを保存する
- ビデオ編集プロジェクトのように、頻繁に変更される大きなバイナリファイル...
更新(2015年11月):プロジェクトは中止されたようです(2014年4月からの最後のリリース)。
準備済みワークスペースにtransparentVCS使用法を提供できる場合、それらはVCSを使用します。プログラマの方法でVCSを使用するように非プログラマに教えないでください
VCSサポートを組み込んだエディターを見つけて設定し、追加の簡単な手順を作業に表示します。
ほんの一例-EditplusはSubversionを知っており、エディターウィンドウ内で基本的なSVN操作を実行できます。最新のEditplusはTortoiseGITをGit統合に使用することもできます
Edit:何らかの代替ソリューションが見つかりました: EasySVN 、適切に構成されているため、作業コピーを監視して自動コミットを実行し、自動マージ、任意のオーサリングツールの使用を許可エンドユーザーと任意のドキュメントの形式
WebDAV の設定についてはどうですか?
それらの自動バージョン管理履歴を自動的に処理します。彼らがしなければならないのは、あたかもそれがネットワークドライブであるかのようにサーバーに接続し、すべての保存がコミットされることです。
Googleドキュメントはあなたが望むことをするかもしれません。 File > See Revision History
を使用すると、変更を追跡できます。
また、無料でファイルをやり取りするという問題もあります。全員でドキュメントを共有するだけです。
最後に、それは使いやすいです。ライターは、バージョン管理が行われていることを知る必要さえありません。
OS不可知論者
Pythonプログラムを記述し、ファイルをドラッグアンドドロップして、そのプログラムでgit add
およびgit commit
そして何がそうでなくて、彼らはそれに対処する必要はありません。
または
自分のマシンにマウントできるWebDavベースのファイルシステムを使用し、サーバーにgit
を透過的に実行させます。
OSX/Linux
PythonベースのFuseプラグインを記述します。その後、マウントされたファイルシステムから透過的に開いて保存できます。いくつかあります Fuse for Windows resources しかし、彼らはおそらく騙す価値はありません。
Windows
FileSystem Filter Drivers を使用してgit
を透過的に実行するためのコードを書くことができます。
ああ、プログラマー以外の人のうんざりする喜び。 git/Mercurial環境をセットアップすることをお勧めします。リポジトリが処理できる形式ですべてを保存するように伝えます。 tortoisegit または tortoisehg を使用すると、リポジトリがどのように機能するかを知る必要はありません。プロジェクトディレクトリに感嘆符があるかどうかを確認し、問題のファイルを右クリックして、[コミット]をクリックします。変更の概要を入力します(彼らは作家ですよね?)。
それらのワークフローの追加のステップですが、マージ/ブランチ/クールなものについては何もありません。事前に構築された環境はすでにライターブランチにあるように設定されているため、コードは表示されません。スクリプトで毎日それらを自動同期します。後で、それらがコミットに慣れた後、それらに追加の機能を表示できます。何が変更されたのかを確認できる機能は非常に便利なので、いったんワークフローに忍び込んだら、それなしでは何ができないのでしょう。
共有ポイントはどうですか?私はそれが開発の世界では一般的ではないことを知っていますが、ライターがWindowsをOSとして使用している場合、それはうまく機能し、バージョン管理を使用していることを実際には認識しません(私の仕事の大きなプラス)。
また、このソリューションは、彼らが新しいものを巧みに操っているように思われるので、彼らが多くの人を怖がらせるであろう何かに対処するのを防ぎます。
ライターがファイルを保存しているファイルシステムを監視し、保存するたびに自動コミットするツールをセットアップできますか?
これをネットワーク共有に配置すると、構成をまったく行わずにすべての構成を実行できます。しかし、彼らがあなたのチームが使用するために更新されたバージョンを提供するたびに、それはあなたのためにgitに追加されます。
あなたはプラスチックSCMを見ましたか?彼らはそれを使いやすくしようとしています
バージョン化されたバックアップが必要な場合は、Dropboxを使用するか、Windowsバックアップサービスをセットアップできます。または、Crashplanまたは他の同様の製品をインストールできます。
Mercurial DVCSには、 EasyMercurial と呼ばれるユーザーインターフェイスがあり、その明確な目標は、基本的なバージョン管理操作の簡単なビューを提供することです。
EasyMercurialは以下のことを目的としています。
- 履歴グラフ表現を使用して、実際のリポジトリの状態を示すこと、および学習することは簡単です
- プラットフォーム間で一貫したMercurialの通常のコマンドラインワークフローに認識できるほど近い
私たちは、特定の目的のために「最高の」Mercurialクライアントを作成することを試みていません。ユーザーのニーズの変化に応じて、他のクライアントに移ることを積極的に推奨しています。目的は、共有リモートリポジトリを使用する小規模なプロジェクトグループの初心者がアクセスできるものを提供することです。
私はそれを試してみることをお勧めします。
私はプログラマー以外の人と何度も作業しなければなりませんでした(ほとんどがグラフィックアーティストで、作家がアーティストとしてワークファイルを管理する方法がほとんどない場合は、うーん...楽しみです... 。)。 3つの可能なアプローチがあります。
個人的には、オプション3がよい方法だと思います。これは、ファイルを配信してチェックインする必要がある人にとっては多少の苦痛と苛立ちを意味しますが、他のどのオプションよりもはるかに少ないものです。
また、プログラマーではないユーザーが、考えられる古いファイル名のファイルを提供することにも注意してください。命名規則は彼らにとって奇妙に異質です。 「Picture」などと呼ばれるファイルを提供し、それを伝えると、「Picture_Final」と呼ばれるファイルが提供されます。このファイルには約3つの障害しかありません。これを指摘すると、「Picture_NewFinal」、そして(運が良ければ)「Picture_NewFinal2」という別のファイルが作成されます。ただし、この時点で、それらは歴史的発展の感覚を捨てて「Spanner Icon」と呼ぶ可能性があります。事」。
繰り返しになりますが、命名規則を適用することもできます。つまり、すべてのファイルの呼び出し先を事前にに指示するか、送信されたファイルのスクランブル解除と名前の変更に何時間も費やすことができます。ここで、とにかくあなた自身の正気のためにスプレッドシートが欲しいと言うので、彼らにそれをフォローさせるようにしてください:彼らが従わないときも驚かないでください。
お役に立てば幸いです-楽しんでください!
2人が同時に同じターゲットで作業する必要がある可能性があり、テキストファイルですべての作業を処理できる場合は、共有googleドキュメントを試してみます。
それは素晴らしいマルチエディター/コラボレーション機能を備えています-私が今まで見た中で最高です。また、フルバージョンであり、テキストファイルとしてエクスポートできます。
しかし、これらはかなり大きな2つの場合です。
通常どおりファイルを保存して、フォルダーで作業できるようにします。
1日に1回(または1週間など)、そのフォルダーの内容をbackup_dd_mm_yyyyにコピーします。ほとんどのシステムソースコードは、最近の利用可能なスペースを考えると、取るに足らない量のスペースを占有します。
コピーは、あなた、彼ら、第三者、ツールまたはスクリプトのいずれかによって行うことができます。
これは、損失を1日に制限し、履歴を与え、それらに対して透過的です。
どちらの当事者にとっても完璧ではありませんが、中立を狙う答えです。