非プログラマー（つまり、デザイナー）にバージョン管理を使用させる簡単な方法は？
開発中、Web開発中などにバージョン管理をチームに関与させる主な方法は何ですか？
私はそれなしで仕事をすることを拒否します。つまり、プロジェクトに関係する誰もがそれを使わなければなりません。ただの練習です。
TowerのようなGUIは役に立ちましたが、その概念は怒り（「私の仕事ではありません！」）の態度、臆病さ、またはまったく使用せず（FTPを使用して、たとえば、バージョン管理を回避するなど）のいずれかで満たされています。 ）。
編集：私は画像/ PSDを意味するだけではないことを少し明確にすべきでした。
私は開発者とデザイナーの両方のチームで働いており、全員がバージョン管理を使用しています。デザイナーにとって、それはひどいです。
ファイル共有/バックアップは常にバージョン管理と同じです
あなたが言う時：
私はそれなしで仕事をすることを拒否します。つまり、プロジェクトに関係する誰もがそれを使わなければなりません。それはただ良い習慣です。
バイナリデータでバージョン管理を使用する場合の落とし穴に注意する必要があります。
- 上書き：2人の設計者が同じファイルで作業している場合、2番目にコミットすると、最初の変更が現在のバージョンとして上書きされます。これを防ぐ唯一の方法は、誰がどのファイルに対して何をしているのかについてのロックまたは継続的なコミュニケーションであり、どちらもチームのワークフローを妨げることがあります。
- マージ：ツール支援のマージはバイナリデータには存在しません。手動でのマージは苦痛であり、大量のエラーが発生しやすい傾向があります。
Repository bloating： VCシステムは、テキストファイルの変更された行のみを保存します。ファイル全体がVCシステムとは異なるため、これはバイナリデータでは不可能です。これは、10KBのテキストファイルの20バージョンは20KBしか使用できない場合があるが、1MBファイルの20バージョンはおそらく20MB近くを占めることを意味します。中規模の設計チームは、数十のバイナリファイルに多くのリビジョンを簡単に生成できます。 IT部門はすぐにストレージ要件を嫌い、場合によってはVCサーバーのメモリ/ CPUを増やすことさえあります。
あなたや他の開発者は、バイナリファイルを回避するために非常に優れたリポジトリ構成を設定しない限り、チェックアウトまたは更新にかかる時間をすぐに嫌う可能性もあります。
メリットの削減：1）過去のバージョンの内容を確認する簡単な方法がない2）とにかく簡単にマージできないため、デザイナーがバイナリファイルの以前のバージョンに戻ることはほとんどありません。最も重要なのは、3）それらがそのように機能しないことです。これらは、プロダクションファイル自体にまだ役立つ可能性があるグラフィックの代替バージョンを構築するために使用されます。
コードについては、絶対にVCを使用する必要があり、それを要求するのは正しいことです。
しかし、everyoneも使用している必要があることを前提とすることを確認する必要がありますだけでなく、それが優れたプラクティスかどうかデザイナー向け（ただし、バックアップは）。 Webサイト/アプリケーションで必要な最終的なグラフィックアセットをVCに保存する必要がありますが、プロダクションファイルの場合は、適切なソリューションではない可能性があります。
私はそれなしで仕事をすることを拒否します。つまり、プロジェクトに関係する誰もがそれを使わなければなりません。それはただ良い習慣です。
それは素晴らしい仕事です。すぐに「私の仕事ではありません！」 :-)
賛同を得るための最良の方法は、TortoiseGitやTortoiseSVNなどを使用して、バージョン管理をエクスプローラーに統合することです（Windowsを想定）。バージョン管理のパラダイムに慣れていない場合、実際のメリットを確認するには時間がかかります。亀は、少なくともVCSをマウスで操作することを簡単にします。必要なのは、単純な「右クリック->チェックイン」だけです。
このため、TortoiseGitでファイルを閉じるたびに透過的なバージョン管理を実装することを検討してきました。誰かに作業用のブランチを与え、すべての書き込み/クローズがコミット操作になる場合、開発者はいつか、リポジトリ全体の一貫性を気にせずにブランチをマージでき、彼らはバージョン管理について知らなくても、彼らがしていることをするビジネス。
監査ドキュメントの膨大なセットでこれと同じ問題があり、バージョン管理を行うことができません。そのため、同じドキュメントの50のバージョンが浮かんでいて、すべて微妙に異なっています。
これにアプローチする方法は、ビルドシステムをセットアップすることです（-- Hudson のように）、ビルドソースを取得するバージョン管理システムと、それがartefactsのみであるプロジェクトルールにするビルドシステムによって提供されますはテストチームに渡され、最終的に顧客サイトに展開されます。
プロジェクトプロセスに関する限り、ビルドに由来しないものはすべて開発者専用であることを明確にしてください。誰かの作品がビルドに受け入れられない限り、存在しないかもしれません。
利点を説明します。
- 全員が作業を共有して中央の場所にアクセスできるようにすることで、時間を節約する方法を説明します。
- デザイナがプロジェクトのさまざまな部分で同時に作業し、マージして戻す方法を説明します。
- テストまたはトラブルシューティングのために、古いバージョンのアプリケーションにタグを付けて構築する方法を説明します。
- 実験用のデザインをいじくり回して、プロジェクトを更新し、必要がない場合は変更を維持しないようにする方法を説明します。
- 彼らが時間の経過とともに何が起こったかをどのようにして確認できるかを彼らに示します。
バージョン管理についての「私の仕事ではない」とは、プログラマーでない人の正気の態度です。
Dropboxが同期用またはTime Machineがバックアップ用であるのと同じくらいシンプルで目に見えないバージョン管理システムを構築します。
うまくいくはずです。チェックアウトなし、コミットなし。ファイルをプロジェクトフォルダに配置するだけです。
私は新しいウェブサイトの女性でTortoiseHG/Mercurialを使用していますが、問題はありません。チェックアウトがないことは非常にシンプルになり、実際にファイルが同期されていることを確認しなければならない人にすべての圧力をかけます。それは「もう1つやること」のようには見えませんが、「ウェブサイトをデモするつもりなので、ピーターに変更の再同期を依頼する必要があります。」それは問題ありません。
Mercurialの使用経験はありませんでした。VSSを使用しており、Webサイトのソース管理のためにVSSを使用することを望んでいませんでした。私は一度試してみましたが、その時それを使いたくないと誰も責めません。
亀*のクローンの使用を言うでしょう、それはそれが得るより簡単です。または、IDEなどのバージョンコントロールを統合します。