Flash開発でのgitの使用

私はずっと前にこの記事を書き始めましたが、彼らは私より先に進みました（8。

主なアイデアは、兄弟フラッシャーにgitの操作方法を説明することでした。 この記事では、gitの明らかな利点を列挙するだけでなく、個人的な経験を説明しようとしました。 したがって、すべての人に役立ちます。



まず、追加と修正に満足します。 そしてもちろん問題。

gitとは

gitは分散バージョン管理システムです。 中央リポジトリが必要ないため（これは保持しておくと便利です）、ブランチでの作業が簡単な点でSVNとは異なります。 最初は、 この記事を読んだ後、自分の仕事で試してみることにしました。



私の会社では、クライアントの開発をgitに移すことができましたが、まだ後悔していません。 時々、どのバージョン管理システムが優れているかという論争に出くわしますが、なぜ私はまだgitが好きなのかを説明しなければなりません。

なぜgit

私たちは皆、バージョン管理システムを使用することが重要であることを理解しています。 日常使用のgitは非常に優れていることが証明されており、多くの問題を解決することができました。 主な利点と「チップ」を提供します。

1. 配布
   
   次のように記述するだけで、ローカルフォルダーにリポジトリを作成できます。
2. 安定した顧客を持つ
   
   分岐のない開発プロセスは次のようになります：バージョン...開発...バージョン...開発...
   
   バグやリリースを修正できる安定版の可用性は常に保証されていないことがわかります。 より正確には、現在のバージョンの開発が完了した後にのみ、特定のキャッチされたバグを修正できることがわかります。 gitの単純なブランチを使用すると、以前のリリースのバージョンをいつでも取得して、進行中の開発を妨げることなくそれを操作できます。 バグを別のブランチで修正し、以前のリリースと現在の開発に残してください。
3. 使いやすさ
   
   gitはすべてのデータを1つのディレクトリに保存し、どこでも.svnフォルダーを生成しません。 1つのチームまたはクライアントで数回クリックするだけで、プロジェクトをあるブランチから別のブランチに切り替えることができます。 この場合、プロジェクトフォルダーの内容は、選択したブランチに対応する新しいものに置き換えられます。 ブランチごとに、新しいフォルダーやプロジェクトを作成する必要はありません。 ほとんどの場合、Flash Builderはすべてのクラスを更新し、依存関係を再コンパイルします。
4. 中央ストレージへの永続的な接続は必要ありません
   
   先ほど言ったように、すべてのコミットはローカルに保存され、直接リポジトリにプッシュされたときにのみ一般的なリポジトリの一部になります。 想像することは困難ですが、インターネットにアクセスできないことが判明することもありますが、作業が必要です。 または、通常どおり、作業リポジトリへのVPNの構成を忘れていました。 コミットの速度とローカルコピーを完全に制御できるという感覚は心強いものです。
5. 便利な部分コミット
   
   コミットの直前に、 git add
   
   
   
   を使用して入力されるファイルにマークが付けられます。 同時に、ファイル全体ではなく、別のコミットでファイルの変更の一部を行うことができます。
6. 変更を非表示にする機能。
   
   gitには興味深い機会があります-コミットされていないファイルを非表示（隠し）にしてから再び取得します。 この方法で変更を転送または一時的にロールバックすると便利な場合があります。たとえば、ブランチの切り替えを忘れがちです。
7. グラフィカルクライアントの可用性。
   
   git用のグラフィカルクライアントの選択肢はそれほど多くありません。 SmartGit GUIクライアントが最も好きでした。 クロスプラットフォームであり、非営利目的での使用は無料です。 必要なすべての機能がありますが、それでも時々、Terminalに入り、いくつかのgitコマンドを実行する必要があります。 それらを整理するのはいいでしょう。 TortoiseGit for Windowsがあります。Macでは、しばらくGitXを使用していましたが、SmartGitよりもずっと悪くなりました。 Eclipse（つまり、Flash Builder）には、長い間好きではなかったEGitプラグインがあります。 特に更新されたばかりなので、再度それに戻る必要があります。 おそらくこれはクライアント機能ではなく、gitディストリビューションの一部ですが、それにもかかわらず、ブランチの別のクールな表示に言及したいと思います。 複雑なプロジェクトでは、ニューヨークの地下鉄の地図のように見えます。 私はそのような抽象的な写真が大好きです。

TODOまたはその他の確認事項

当社は公式にsvnを使用しているため、git-svnをインストールしてgitリポジトリとsvnコピーを結合することはありませんでしたが、もう我慢できませんでした。 最終的には誰もがgitに切り替えて、これが不要になることを願っています。



それまでの間、アクセス制御付きのプロジェクトを保存するための興味深いオプションとしてGitHubを提供しました。 しかし、ご覧のとおり、企業秘密などがあります（ただし、コードは左右に盗まれ、それなしで盗まれます）。 私自身は個人的なプロジェクトに使用しています。 便利に。

インストールとセットアップ

ギット。 Mac / Linux





まず、git自体をインストールする必要があります。 Linuxoidは間違いなく自分でそれを理解しますが、ほとんどの場合、すでにインストールされています。 Macwareは、 公式Webサイトから配布キットをダウンロードするか、 MacPortsからインストールできます。 MacPortsのインストール方法も理解するのは難しくありません。



MacPortsで、ターミナルを開いて入力します。

sudo port

ほとんどの場合、管理者アカウントからは何もインストールできないので、sudoを呼び出してパスワードを入力します。 さらに、どのリポジトリがgitで始まるかを調べます。

list git*

このようなものが画面に表示されます。

git-core @1.7.2.1 devel/git-core

GitX @0.7.1 devel/GitX

GitXは、すでに書いたGUIクライアントです。 git-coreに興味があります。 それをインストールするには、あなたが書く必要があります

install git-core

コンソールでgit --version



と入力すると、インストールを確認できます。



リモートリポジトリにアクセスするには、SSHキーが必要です。 Macで生成しても問題ありません。



ギット。 窓



Windowsにはmsysgitポートがあります。 最新バージョンをダウンロードしてインストールします。

Gitは最初はWindowsとは無関係です。 これにはいくつかの問題があるかもしれません。 たとえば、しばらくの間、リモートリポジトリで動作させることができませんでした。 SSHキーを誓いました。 この問題を解決してくれたGitHubに感謝します。 したがって、Puttyを使用してキーを生成しようとしないでください。 正しいキーを生成するには、次が必要です。

1. スタート->プログラム-> GitからGit Bashコンソールを起動します
2. ssh-keygen -t rsa -C "your@email.com"
   
   
   
   を実行してキーを生成します

GUIクライアント



次に、お気に入りのSmartGitを配置します。 クロスプラットフォームであることは非常に素晴らしいことです。



SmartGitのインストール中に、.gitconfigファイルが見つからない場合は、コミットに関する情報で使用される名前と電子メールを要求します。



改行



異なるオペレーティングシステムのgitリポジトリを使用する場合、遅かれ早かれ（より早く） 改行の問題が発生します。 コミュニティはコンセンサスを得ていませんが、GitHub は次の設定を推奨しています。

1. リポジトリの作成は、Windowsマシンからではなく、
2. LinuxおよびMacでは、core.autocrlfをinputに設定します
3. Windowsでは、core.autocrlfをtrueに設定します

これは、 git config --global core.autocrlf true



によって、または.gitconfigを編集することによって行われます。 そこに追加する必要があります

[core]

autocrlf = true

これらの設定により、MacユーザーはLF改行を使用してリポジトリにLFをコミットし、Windowsユーザーは通常のCRLFを使用しますが、LFをコミットします。



改行をすぐに設定しない場合、プッシュするたびに、ほとんどのファイルは変更されたものとしてマークされますが、変更はありません。 同時に、そのようなファイルは時々表示されるため、手動で元に戻す必要があります。 誰かがこれで何ができるか知っているなら教えてください？

既存のプロジェクトの翻訳

この方法では、SVN履歴が完全に失われることを前提としています。 最初から、いわば、ゼロから。



.svnフォルダーを削除するには、 svn export



プロジェクトを作成します。 または、プロジェクトのルートで、 find ./ -name ".svn" | xargs rm -Rf



実行しfind ./ -name ".svn" | xargs rm -Rf



find ./ -name ".svn" | xargs rm -Rf







プロジェクトが複数の個別のFlash Builderサブプロジェクトで構成されている場合、サブプロジェクトごとに個別のプロジェクトではなく、1つのフォルダーにすぐに転送して、その中に1つのgitリポジトリーを作成するのが理にかなっています。 将来的には、過去のどこかに各サブプロジェクトの適切な状態を探すのではなく、プロジェクト全体のバージョンをマークする方が簡単になります。 プロジェクトフォルダーを転送する場合は、Flash Builderプロジェクトから削除することをお勧めします（もちろん、ディレクトリのコンテンツを削除せずに）。



将来のgitリポジトリがあるディレクトリで、次の内容の.gitignoreファイルをすぐに作成することをお勧めします。

bin

bin-debug

bin-release

これは、コンパイルされたプロジェクトバイナリをリポジトリに含めないようにgitに指示します。



次に、SmartGitを起動し、[既存を開く]または[新しいローカルGit作業ツリーを作成する]を選択して、プロジェクトでフォルダーを指定します。 SmartGitは新しいリポジトリを作成します。



リストですぐに.gitignoreファイルを見つけて選択し、[ステージ]ボタンと[コミット]ボタンをクリックする必要があります。 最初のコミットメッセージを「初期コミット」のようなものにします。 現在、ディレクトリの現在の状態を上書きすると、.gitignoreに記載されているすべてのファイルが消えます。 それらは必要ありません。 コミットウィンドウで他のすべてのファイル（ステージ、コミット）を選択し、[上記のコミットを修正...]チェックボックスをオンにします。これにより、新しいコミットの代わりに、現在の変更を最後の変更に追加します（CRLFはLFで置き換えられる多くのメッセージが表示される場合があります...設定に従ってgitを実行すると、リポジトリに追加されるファイルの行末が正しいLFに変更されます）。



おめでとうございます、これであなた自身のgitリポジトリができました。



正しい改行設定を設定する前に突然リポジトリを作成した場合は、 GitHubの指示に従って次のスクリプトを実行します。

# Remove everything from the index

$ git rm --cached -r .







＃削除されたすべてのファイルをインデックスに再追加します

＃「警告：<file>のCRLFはLFに置き換えられます」のような多くのメッセージが表示されます。

$ git diff --cached --name-only -z | xargs -0 git add



＃コミット

$ git commit -m "CRLFを修正"



＃Unix / Mac OSXクローンでこれを行う場合、オプションで削除

＃作業ツリーを開き、正しい行末ですべてを再チェックアウトします。

$ git ls-files -z | xargs -0 rm

$ git checkout。

Flash Builderからプロジェクトを削除した場合、今度は（File-> Import-> Flash Builder Projectを使用して）プロジェクトを再度追加し、すべてが機能することを確認します。 プロジェクトを1つのフォルダーに転送した場合、たとえば、インポートパスや構成でいくつかの変更を行う必要があります。 変更を行った後、それらをコミットすることを忘れないでください。

プロジェクトで作業する

この記事をまだ読んでいない場合は、今すぐ実行することをお勧めします。これは、以下で説明するgitでプロジェクトを操作するプロセスがほぼ完全に採用されているためです。 この記事を書いている時点で、私はまだMail.ruで働いており、Flashでソーシャルゲームクライアントを書いています。 したがって、いくつかの詳細。



gitを使用するため、その主要機能であるブランチを完全に使用します。 したがって、私のすべてのプロジェクトは、さまざまな機能を持つブランチのセットと、それらを使用するために厳密に定義されたアルゴリズムで構成されています。

• master-メインブランチには、現在オンラインになっているリリースバージョンのみが含まれます。 それらは、記入日でタグ付けされます。 有益なバージョン番号をほとんど拒否しました。 戦闘サーバーで突然何かが故障した場合、問題なくマスターに切り替えて、そこからブランチを作成し、バグを修正して保留します（後で同じバグを修正しないように別のブランチを追加します）
• 開発はメインの開発ブランチです。 開発の安定状態を反映しており、将来的にはリリースされてマスターに保持されます。
• dev- * -個々の機能のブランチ。 それらの多くはローカルであり、メインリポジトリには入りません。 彼らはゲームの特定の新機能を開発しています。 1回または2回のコミットで非常に小さな変更になることもあれば、1か月以上に及ぶ巨大なパッチになることもあります。
• fix- * -緊急修正のローカルブランチ。 通常、マスターから表示されますが、開発からはあまり表示されません。 すぐに適切な場所に移動してください。
• releaseは、マスターにマージされて削除される一時的なリリースブランチです。 適切なタイミングで、developでブランチを作成し、必要な変更を行ってから入力します。

操作アルゴリズムは次のとおりです。

• ほとんどすべての変更に対して、独自の開発ブランチがセットアップされます。これらは最終的に開発されるか、不要なものとして削除されます。
• 多かれ少なかれ大きな変更のブランチは中央リポジトリに移動し、小さな変更は通常、開発者とともにローカルに残ります。
• 行われた変更を見ることで、大きな機能のマージを制御しようとしています。 この段階でgovnokodを遮断することは非常に便利です。
• リリースの準備で、リリースブランチが作成され、マスターにマージされます。 たとえば、「このリリースでは、機能がまだ準備されていないため、このボタンを非表示にする必要があります」など、必要のない一時的な変更を行います。 この段階では、大きなバグを持たないほうがよいでしょう。なぜなら、これらのバグを修正した別のブランチを作成し、絶えず切り替えてリリースする必要があるからです。
• 記入後、リリースはマスターにマージされ、削除されます。 マスターの現在の状態には、記入日がタグ付けされます。
• 開発は継続しています。

したがって、現在のオンラインバージョンのソースが常にあり、そこで変更をすばやく行うことができます。 各開発者は自分のビジネスで忙しく、無菌の中央リポジトリで無菌実験を汚しません。 同時に、コミットの履歴は記録され続けますが、必要に応じていつでも記録できます。

私が遭遇した問題

もちろん、すべてがあなたが思うほど完璧ではありません。 啓発への道で、私はまだ熊手に触れる必要がありました。 おそらく、この情報は誰かに役立つでしょう。

1. 管理者の抵抗
   
   優れたSVNがあるように見えるため、別のバージョン管理システムが必要な理由を何度か説明しようとしました。 管理者は、gitをネットワーク上のリソースへの権利の分配とアクセス制御の既存のシステムに統合するのが難しいと不満を述べました。 このビジネスは動揺せず、「中央リポジトリをローカルに保持する」必要がありました。
2. 同僚のトレーニング
   
   同僚は、新しいバージョン管理システムに切り替えることを強制し、通常のSVNとの違いを理解し、新しいソフトウェアの使用方法を学ぶ必要がありました。 実際には複雑なことはありませんが、その後の継続的な問題に備える必要があります。
3. 行折り返しの問題
   
   私はすでに上記の問題とその解決策について書きましたが、しばらくの間私の脳を具体的に実行したため、「問題」セクションにそれについて書くことができませんでした。 ブランチが1つしかない場合は、プロジェクトの最初に改行を修正することが非常に重要です。 その後、それはしっかりした頭痛に変わります。
4. wから手...
   
   Unixライクなシステムとコマンドラインに関しては、ここで私の手は間違った場所からはっきりと成長します。 しばらくの間、Macの中央リポジトリであったため、最初からすべてを正しく設定しなかったという事実に関連する次の問題に常に直面していました。ロックされたファイルとファイル所有者。彼らは根そのものから抜け出すことすら望まなかった。 Googleはディレクトリ内のファイルを再帰的に解凍するスクリプトを促しましたが、仲間の開発者から私にプッシュされた後、一部のファイルは誰の所有権も渡さず、リポジトリが完全に機能しなくなりました。 sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/


   
   
   
   ように、毎回ディレクトリを再帰的に設定するsudo chmod -R 777 /users/valyard/Work/work/Panda/.git/





sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/


   
   
   
   
   
   最後に、私はすべてのプロジェクトでこれら2つのことを行うスクリプトを作成し、時々実行しました。
5. リポジトリに行くものとしないものを詳しく見てみましょう
   
   もちろん、コンパイルされたバイナリとグラフィカルアセットをすぐに.gitignoreに追加する必要があります。 私たちのプロジェクトには、ジャンクを組み立てるためのantスクリプトがあり、それはマシンによって若干異なります。 おそらくそれも追加する価値がありましたが、Windows用とポピー用の2つの異なるスクリプトを作成しました。
6. 迷惑なプロジェクトファイル
   
   何らかの理由で、プロジェクトメタデータ内のFlash Builderは、役に立たないが、変更を表示するときに迷惑なgitを煩わせるよりも、行の半分を上から下に移動する義務があると見なします。 しかし、それでも、プロジェクトファイルのコミットは悪い考えとは考えていません。
7. WindowsでSSHキーを生成する問題
8. コンソールのフラッシャーが嫌い
   
   結局のところ、フラッシャーはコンソールで動作することを好みません。 また、GUIクライアントはgit機能のごく一部しか提供しません。 ある種の操作をより複雑にするために、コマンドラインに登らなければならない場合があります。

役に立つヒント

最後にいくつかの言葉。

1. gitとsvnの違いを理解してください。
2. これを当局に届けようとしてください。
3. メインgitリポジトリを正しく構成できる人を見つけます。
4. それでも、チームで同じIDEを使用するように試みてから、プロジェクトファイルをコミットできます。
5. プロジェクトをいくつかのリポジトリに分割します。
6. コミットとマージをより頻繁に行いますが、gitのようなクールなツールでさえ、2か月のコミット履歴を持つ2つのブランチを自動的にマージすることはできません。 手動でボタンを突く必要があります。
7. 私の間違いを繰り返さないでください。
8. gitをscる人の話を聞かないでください。

便利なリンク

• Mac OSにGitパブリックサーバーをインストールする
• 私たちが取り組んでいる設計モデル
• 有用なリソース
• Great Pro Git Book
• SmartGitは私のお気に入りのGUIクライアントです
• Habréに関するすばらしい記事とそこからの優れたガイド

まとめ

しかし、それでも、すべての短所は巨大なプラスによってブロックされました。 プロジェクトをgitに転送したために、お尻で自分にキスをする準備ができていたときもありました（もちろん、私はお尻にキスをするのではなく、プロジェクトをgitに転送したい）！

PSの質問。

1. メインブランチ（マスター）との合併をどのように、また誰が制御しますか。また、そのような操作を実行する権限を制限するメカニズムはありますか？
   
   プロジェクトのメインフラッシャーを制御します。 私のプロジェクトではそれをしています。 gitレベルでは、利用可能な操作に違いがあるかどうかはわかりません。