約10人のドキュメントチームが最近SVNからGitに移行しました。SVNでは、誰もがマスターに取り組んでいました。これは私がずっと嫌っていたモデルですが、その変化をもたらすことはできませんでした。Gitへの移行の一環として、それを修正することに同意しましたが、まだそれを行うことはできません（任意のブランチからのビルドを許可するビルドの変更を待機しています）。一方、誰もがマスターに取り組んでいます。はい、私はこれがひどいことを知っています、信じてください。

SVNを使用していたときよりも多くのしゃっくりが見られますが、その一部はGitの2段階モデル​​（ローカルおよびリモート）に起因しています。コミットすることはできてもプッシュできない場合や、保留中のローカル変更と競合してプルする場合があります。昨日、誰かがマージを間違えて最近の変更をなんとかしました-マージが間違っていました。（彼は彼が何をしたかを正確に伝えることができませんでした。彼はGUIを使用しているため、シェルの履歴を調べることはできません。）

最も熟練したGitユーザーとして（読みます：以前に使用しましたが、非常に複雑なものではありません）、私はポリシーを設定し、ツールを教え、混乱をクリーンアップします。ブランチでの開発に切り替えることができるようになるまで、ツールを使用して、共有されたアクティブなマスターのエラーが発生しにくいようにする方法にどのような変更を加えることができますか？

チームはWindowsでTortoise Gitを使用しています。以前Tortoise SVNを使用していたため、Tortoise Gitを使用しています。（私は個人的にCygwinの下のコマンドラインをいくつかの操作に使用していますが、チームはGUIが必要であることを明確にしました。これを使用します。）

Tortoise Gitには「Commit＆Push」という単一の操作があり、常にそれを行うように指示しました。しかし、それはアトミックではありません-コミット（結局ローカル）はうまく機能するが、プッシュは（競合やネットワークの問題などのために）うまくいかないことがあります。その場合、あいまいなエラーが発生します。私は、彼らが持っている場合のBitbucketはコミットログをチェックするためにそれらを言ったいかなる彼らがプッシュする、それが表示されない場合、コミット最近の疑問をして。（そして、それが問題である場合は競合を解決するか、何をすべきかわからない場合は助けを求めます。）

チームはすでに「早期かつ頻繁にプルする」という良い習慣を持っています。しかし、プルは競合を引き起こす可能性があるようですが、これは新しいと思いますか？新しくない場合は、SVNよりはるかに頻繁です。Gitがプルする方法（マージではなくリベース）を変更できると聞いたことがありますが、そこでのトレードオフ（または環境でそれを行う方法）について十分に理解していません。

サーバーはBitBucketです（Githubではありません）。私はリポジトリを完全に管理できますが、より一般的にはサーバー上で管理しません。いずれも変更できません。

ソースファイルはXMLです。グラフィックファイルもあります。これは、マージできないことを誰もが知っていますが、衝突はほとんどありません。マージの競合は、グラフィックではなくXMLファイルから発生します。

Gitの使用にどのような変更を加えると、チームで共有マスターがよりスムーズになり、レビュー済みのテスト検証済みのプルリクエストで機能ブランチを使用できるようになりますか？

これまでのところ、SourceTreeは概念を学習するのに最適なIDEでした。これは、各ステージにあるすべての関連するダイアログとオプションを表示するためです。

• 最新のものであることを確認するために、マスターから引き出します
• ファイルを修正する
• 変更をコミットします（ローカルのみ）
• マスターから再度プルします（これにより競合が発生します）
• 競合が解決されるまですべてのファイルを編集します。つまり、ファイルはコミットしたい適切な状態になります（生ファイルには<<<<< HEADおよび>>>>マスターメッセージはありません）
• マージの変更をコミットする
• 押す

誰もがこのレシピに従えば、彼らは大丈夫なはずです。

誰かがより大きな変更または中央の変更を行うたびに、他のユーザーにローカルでコミットしてマスターからプルするように通知するので、後であまり多くの競合が発生せず、最初の人はまだ一緒に競合を解決します。

誰もがフローを理解できるように多くの時間を費やしてください。そうしないと、しばらくの間、実際にマスターブランチをねじ込みながら快適に感じるかもしれません。たとえば、「リモートの代わりに私のファイルを使用」他の人によって行われたすべての変更をアウト。

Gitは習得が難しいシステムです。特にSvnで育った場合は、忍耐強く適切に習得する時間を与えてください。新規ユーザーの場合、混乱を解消するために1日を過ごすことができますが、これは正常です。;）

他の誰かと同じブランチで作業しているとき、覚えておくべき3つの主なものがあります。

• 自分が何をしているのか本当にわかってい--forceない限り、絶対に使用しないでください。
• いずれかcommitまたはstash前に進行中の作業pull。
• 通常、pull前に行くと簡単になりますpush。

それとは別に、分散バージョン管理では、「公式」リポジトリがブランチを使用するかどうかは問題ではないことを指摘します。これは、個々のユーザーがローカルリポジトリで何をするかにはまったく関係ありません。私の会社がまったく別の中央VCSを使用していたとき、以前はgitを使用してローカルブランチを取得していました。彼らが機能のためにローカルブランチを作成し、ローカルmasterにマージミスをした場合、reflogや他の魔法に入らずに修正するのがはるかに簡単です。

みんながgitを学ぶのに1日かかることはありますか？

専門家を使用するコンピューターは、新しいツールを学ぶことを本当に期待されるべきであり、VCSで多くの間違いを犯す可能性はありますが、使用されるように設計されたツールを使用する必要があります。

これを導入する最善の方法は、変更を行う（できるだけ短くする）ときにすべての人が自分のブランチで作業し、完了したらリベースしてからマスターにマージすることです。これは、現在の作業方法からそれほどかけ離れておらず、より複雑な操作を行うのに十分な自信を感じるまで慣れる簡単なワークフローを導入します。

私はウィンドウを使用しませんが、Tortoiseが基本的にgitをそれらから隠し、それがSVNであるふりをしている場合、Tortoiseはおそらく間違ったツールです。

時々、あなたがしていることは変えなければなりません。

最大の問題は、全員がマスターに取り組んでいるということです。これはコード開発では一般的ではなく、あなたのケースでも間違ったモデルになる可能性があります。それを変更できる場合、変更を別々のブランチで行うことを要求/要求することで、より良い形になります。ブランチを使用すると、次のことができます。

• 直接プッシュmasterを許可しないことを強制します。
• Bitbucketを使用して、プルリクエストを作成し、マージする前に少なくとも1つの承認を得るようにします。これにより、誰かが変更を見ていることが保証され、ユーザーがデスクトップ上に持っているものではなく、リモートバージョンのコードとの競合が表示されるため、マージ自体の痛みも軽減されます。これにより、コミットは成功したがプッシュは失敗したシナリオが防止されます。
• マージする前に、リポジトリに対して「ビルド」を実行します。私はそれがドキュメントレポであることを理解していますが、このビルドからビルドできるスペルチェック、法的スクレイピング、または自動翻訳（STRING_DEFをcsvファイルにエクスポート）さえあるかもしれません。またはそうでないかもしれません、あなたの仕事に依存します。
• 人々が複数の異なることを同時により簡単に行えるようにします。はい、これはスタッシュでも行うことができますが、少し厄介で、何かを使用していないことがわかります。

分岐を使用できない場合merge-and-pushは、いくつかの問題点を自動化できるスクリプトの作成を検討してください。たぶん、ユーザーがマスターに遅れていないことを確認し、フェッチとプルを実行してから、マージを（おそらくで--no-commit --no-ff）試行します。

マージをやり直すことができることを強調する

自明かもしれませんが、以前のSVNユーザーは、マージを複数回解決しようとすることに気付かないかもしれません。これにより、受信するヘルプフラグの数を減らすことができます。

SVNで作業をしているとき、trunk変更はコミットされていない状態で行われます。その後、あなたはsvn update。その時点で、あなたの変更は他の人々の変更と永久に混ざります。元に戻す方法がなかったため（afaik）、手動ですべてを確認し、レポジトリが良好な状態であることを望みました。マージをやり直すだけで、本当に快適になります。

gitに移行しても、人々は同じ考え方をします。多くの意図しないエラーにつながります。

幸いなことにgitを使用すると、特にローカルコミットを行うことができるため、戻ることができます。（コマンドラインでこれがどのように表現されるかについては後で説明します）

ただし、これはツールによって異なります。プルをやり直すことは、多くのGUIで単一のボタンとして公開されるものではありませんが、おそらく可能です。cygwinを使用するのが好きです。私の同僚はsourcetreeを使用しています。BitBucketを使用しているため、同じ会社Atlassianによって管理されているため、GUIとして使用するのは理にかなっています。いくつかのより緊密な統合があると思う。

プルについて

マージpullは人を台無しにすることだとあなたは正しいと思います。Aは、pull実際にgit fetch続くサーバーからの変更、取得したgit merge origin/<branchname>あなたのローカルブランチにリモートの変更をマージ*を。（https://git-scm.com/docs/git-pull）

要するに、すべての標準マージコマンドはプルで動作します。そのマージに競合がある場合は、で中止できますgit merge --abort。マージする前に戻る必要があります。その後、git pullまたはでもう一度試すことができますgit merge origin/<branchname>。

同僚の選択したGUIツールを使用して上記の方法を何らかの方法で学習できれば、ほとんどの問題を解決できると思います。申し訳ありませんが、これ以上詳しくはできません。

*私は、起源が常にここにあるとは限らないことを理解しています。

git reflog問題の診断に使用

私は、あなたのように、GUIツールの誤用によって主に生じた問題を診断しなければなりません。これgit reflogは、リポジトリでのアクションの一貫した軌跡であるため、役立つことがあります。時々読むのは難しいけど。

代替案

状況は一時的なものであるため、展開するプロセスが整うまでSVNに戻ることができます。多くの場所で「一度gitを試してみましたが、うまくいきませんでした...」と言われ、実際にそれを取り戻すことはないので、私はこれを行うのをためらいます。

その他の一般的な移行問題

• 多くの場合、レポは使用できない状態であると確信して、レポを削除して再クローンします。通常、これはローカルとリモートの違いを追跡できなくなったことが原因です。GUIツールとCLIの両方がこれをうまく表示できません。CLIではgit log --decorate、違いを概観する最も簡単な方法を見つけます。しかし、マスターで物事が毛むくじゃらになったら（たとえば）git reset --hard origin/master

多くのオープンソースチームが採用している1つの可能なメカニズムは、フォークモデルを使用することです-https ://www.atlassian.com/git/tutorials/comparing-workflows （フォークgitワークフローを議論するときは必ず明確に宣言してください） ）。

この場合、各開発者またはサブチームは、デフォルトのリモートに加えて「アップストリーム」オリジンを設定するために、BitBucketからチェックアウトするリポジトリの独自のフォークを持ち、「アップストリームをフェッチする」ことを覚えておく必要があります定期的に「リモート/アップストリーム/マスターをマージ」します。

ビルドツールが別のプロジェクト、つまりフォークのマスターを指す可能性があるため、ビルドメカニズムの問題を解決する可能性があります。

その後、ほとんどの人から直接マスタープロジェクトにプッシュする機能を削除し、レビューと承認の役割を持つ小さなチームを作ることができます。https://www.atlassian.com/git/tutorials/making-a-pull-requestを参照してください

-ちょうど約あらゆる望ましいチェックをプッシュする前に行われることを確保する上に読み込むための場所は、フックのGitブックセクションにあるhttps://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - pre-commitおよびpre-pushフックを使用して、提案されたコミットでいくつかのテストを実行して作業が有効であることを確認するなどのことを行うことができます。それら。

アップストリームのフェッチ/マージとフックの両方がTortoiseGitで利用可能です。

これは直感に反するように聞こえますが、私に聞いてください：

gitの実験を開始するように奨励します

gitの興味深い点の1つは、ローカル操作を完全に安全にすることが驚くほど簡単であることです。私が最初にgitを使い始めたとき、自分がやっていることの1つは、何かを間違えた場合に備えて、ディレクトリ全体をバックアップとして圧縮することでした。私はこの後が膨大その場しのぎで、実際にあなたの仕事を保護するために必要なることはほとんどありませんことを発見し、それがあることの美徳がある非常に安全で、非常にシンプルに、あなたがやっている一体で何を知らなくても、どのように試してみたいコマンドが判明します。これをしているときに避けなければならない唯一のことはpush。何もプッシュしない場合、これはあなたが望むものを試すための100％安全な方法です。

ものを試すことへの恐怖は、gitを学ぶ上で最大の障害の1つです。それはあなたに与えますので、それは困難なのようなものだすべてのものの上に多くの制御を。現実には、毎日の使用のほとんどでいくつかの非常に安全な操作に固執することができますが、それらのコマンドを見つけるには多少の探索が必要です。

彼らに安全感を与えることにより、彼らは自分で物事を行う方法を見つけようとするはるかに喜んでいるでしょう。そして、彼らは彼らのために働くローカルマシン上で個人的なワークフローを見つけるためにはるかに力を与えられます。そして、誰もがローカルで同じことをしていなければ、彼らがプッシュするもので標準を順守している限り、それは問題ありません。操作を行う前にレポ全体を圧縮して、そのように感じさせる場合は、問題ありません。彼らは、物事を行うときや物事を試みるときに、物事を行うより良い方法を手に入れることができます。何かを試して、それが何をするのかを見始めるためにあなた自身を得るための何か。

これは、トレーニングに価値がないという意味ではありません。それどころか、トレーニングは機能やパターン、規範を紹介するのに役立ちます。しかし、それは座って、実際に代わるものではありませんやって、あなたの毎日の仕事で何かを。gitとSVNのどちらも、クラスに移動するだけで、すべてのことを知っているわけではありません。それらを使用して問題を解決し、問題に精通し、どの機能がどの問題に適しているかを知る必要があります。

gitの内と外を学ぶことをやめさせないでください

私は何もプッシュしないことに言及しましたが、それは実際にあなたが教えてきたものの1つに反します：常に「コミットしてプッシュする」ことです。私はあなたに彼らにこれをするように言うのをやめ、反対のことを始めるように言うべきだと信じています。Gitには、基本的に変更が可能な5つの「場所」があります。

• ディスク上で、コミットされていません
• ステージングされたがコミットされていない
• でローカルコミット
• 地元の隠れ家で
• リモートリポジトリ（コミットとタグのみが異なるリポジトリ間でプッシュおよびプルされる）

単一のステップですべてを引き出してプッシュするように促すのではなく、これらの5つの異なる場所を活用するように奨励します。以下を奨励します。

• コミットする前に変更をフェッチします。

• 作る決定フェッチされた変更を処理する方法を。オプションは次のとおりです。

  • ローカルの変更をコミットし、取得した変更の上にリベースします。
  • ローカルの変更をコミットし、取得した変更をマージします。

  • 変更を隠し、マージしてから、競合を隠して解決します。

    他にもありますが、ここでは説明しません。プルは文字通り単なるフェッチとマージであることに注意してください。彼らのようなものではありません。それがある彼ら。（--rebase変更を渡すと、fetch + mergeからfetch + rebaseにプルされます。）

• 変更をステージングしてからレビューします。
• ステージングされた変更をコミットしてから、コミットを確認します。
• 個別に押します。

これにより、すべての人に公開される前に作業を確認するようになります。つまり、間違いをより早く見つけることができます。彼らはコミットを見て、「待って、それは私が望んでいたものではない」と考え、SVNとは異なり、プッシュする前に戻ってやり直すことができます。

変更がどこにあるかを理解するという考えに慣れたら、ステップをスキップして特定の操作を組み合わせるタイミングの決定を開始できます（フェッチ+マージが必要であることが既にわかっているためプルするタイミング、またはそのコミット＆プッシュオプションをクリックするタイミング） 。

これは実際、SVNに対するgitの大きな利点の1つであり、gitはこの使用パターンを念頭に置いて設計されています。対照的に、SVNは中央リポジトリを想定しているため、gitのツールが同じワークフロー用に最適化されていなくても当然です。SVNでは、コミットが間違っている場合、唯一の本当の手段は、ミスを取り消す新しいコミットです。

これを実行すると、実際には次の戦略に自然につながります。

地元の支店を使用するように奨励する

ローカルブランチは、実際に共有ファイルで作業する際の多くの問題を緩和します。私は自分のブランチで必要なすべての変更を行うことができますが、プッシュしていないので、誰にも影響しません。時間が来たら、同じマージとリベースの戦略をすべて使用できますが、より簡単です：

• ローカルブランチをリベースすることができます。これにより、ブランチをマージするのが簡単になります。
• masterでプレーンマージ（新しいコミットの作成）を使用して、ローカルブランチの変更をそこに取り込むことができます。
• 私のブランチが救い出すには面倒すぎると思うなら、ローカルブランチ全体をマスター上の単一のコミットにスカッシュマージできます。

ローカルブランチを使用することは、体系的なブランチ戦略を理解するための良い出発点でもあります。ユーザーが自分の分岐のニーズをよりよく理解するのに役立ちます。そのため、誰もが聞いたことがあるためにGitflowをドロップするだけでなく、ニーズとチームの現在の理解/スキルレベルに基づいて戦略を選択できます。

概要

要するに、gitはSVNではなく、そのように扱うことはできません。必要がある：

• 安全な実験を奨励することにより、恐怖を排除します。
• gitがどのように異なるかを理解してもらい、通常のワークフローがどのように変化するかを確認してください。
• 問題をより簡単に解決できるよう、利用可能な機能を理解してもらいます。

これにより、一連の標準の実装を開始できるようになるまで、より良いgitの使用を徐々に取り入れることができます。

特定の機能

短期的には、次のアイデアが役立つ場合があります。

リベース

あなたはリベースについて言及しましたが、あなたは質問でそれを本当に理解していないと言いました。だからここに私のアドバイスがあります：私が今説明したことを試してみてください。誰かがいくつかの変更をプッシュしている間に、いくつかの変更をローカルで行います。ローカルで変更をコミットします。リポジトリディレクトリをバックアップとして圧縮します。他の人の変更を取得します。リベースコマンドを実行して、コミットがどうなるか見てみましょう！無限のブログ投稿を読んだり、リベースとその使用方法または使用方法に関するトレーニングを受けたりすることができますが、実際の動作を確認するための代替手段はありません。だから、してみてくださいそれを。

merge.ff=only

これは個人的な好みの問題になりますが、競合の処理にすでに問題があると述べたので、少なくとも一時的にはお勧めします。私がお勧めの設定merge.ffにonly：

git config --global merge.ff only

「ff」は「早送り」の略です。早送りマージとは、gitが異なるコミットからの変更を結合する必要がない場合です。グラフの直線に沿って、ブランチのポインタを新しいコミットに移動するだけです。

これが実際に行うことは、gitが自動的にマージコミットを作成しようとするのを防ぐことです。したがって、ローカルで何かをコミットしてから、他の誰かの変更をプルすると、マージコミットを作成するのではなく（潜在的にユーザーに競合を処理させる）、マージは失敗します。実際、gitはaのみを実行しfetchます。ローカルコミットがない場合、マージは正常に進行します。

これにより、ユーザーはさまざまなコミットを確認してから、それらのマージを試行し、それらの組み合わせを最適に処理する方法を決定することができます。リベースするか、マージを続行する（git merge --no-ff構成をバイパスするために使用する）か、変更のマージを今のところ先送りして後で処理することもできます。この小さなスピードバンプは、チームがマージに関して誤った決定を下すのを防ぐのに役立つと思います。マージの処理が改善されたら、チームにオフにすることができます。

私は会社でまったく同じSVN-> gitの経験を経験しました。私の経験から、唯一の解決策は時間です。人々にツールに慣れさせ、間違いを犯させ、修正方法を見せましょう。あなたのベロシティはしばらく苦しみ、人々は仕事を失い、誰もが少し手に負えなくなりますが、それはあなたのVCSと同じくらい根本的なものを変える性質です。

そうは言っても、移行期間の早い段階で、TortoiseGitは助けではなく障害であるという意見を持つすべての人に同意します。...

開発者に1週間コマンドライン（git bashまたはposh-git）を使用するよう強制するという（かなり抜本的な）決定を下しましたが、それはgitが実際にどのように動作し、SVNとどのように異なるのかを理解するのに驚かされました。抜本的に聞こえるかもしれませんが、単にgitモデルの理解を深めるために試してみることをお勧めします-そして、いったんそれを理解したら、同僚はgitで好きなGUIファサードを使用できるようになります。

最後の注意：gitがどのように機能するかをすぐに理解する同僚が何人かいるでしょう。後者のグループでは、神秘的な呪文を教えて、自分のコードがローカルマシンからサーバーに届くようにして、全員が見えるようにする必要があります。

さて、最近、次のワークフローを適用して、masterブランチを見つけ出さないようにしました。

1）全員が独自のブランチを使用します。これは、最初はマスターブランチからのコピーです。

マスターブランチに「master」、自分のブランチに「my_master」という名前を付けましょう。

マスターからブランチを作成したばかりなので、まったく同じです。私は自分のブランチで新しい機能の作業を開始し、完了したら次のことを行います。

私のブランチでは、今コーディングを終えました

git add . && git commit -m "Message" && git push

マスターブランチに戻る

git checkout master

最新でない場合はプルします

git pull

自分のブランチに戻る

git checkout my_master

最新のマスターを自分のブランチにマージする

git merge master

競合とマージを修正する

すべてをもう一度テストする

すべてが自分のブランチでマージおよび修正されたら、プッシュします

git push

マスターブランチに戻る

git checkout master

ブランチとマージ

git merge my_master

以前のマージで自分のブランチで競合が解決されるため、競合は発生しません

プッシュマスター

git push

全員がこれに従うと、masterブランチはクリーンになります。

そのため、TFSからgitに切り替え、古い考え方を保持したチームがあります。操作の一般的な規則は、ほぼ同じです。

はい、これは全員がマスターで作業することを意味します。これはそれほど悪くありません。TFSまたはSVNに慣れているチームは、これが最も自然だと思うでしょう。

これを可能な限り簡単にするための一般的な手順：

1. やるgit stash && git pull --rebase && git stash pop毎朝
2. 早く、頻繁にコミットします（すぐにプッシュする必要はありません。少なくともこのgitの利点を早期に活用できます）。

3. プッシュするには、次のループを実行します。

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

誰もがマスターに取り組んでいる場合、あなたができることは何もありません。物事は必然的に台無しになります。

顧客に送信される完成品にはmasterを使用する必要があります。進行中の開発には開発を使用する必要があり、誰も開発にプッシュできないようにする必要があります。標準では、全員がdevから分岐し、変更を加え、ローカルからサーバー上のブランチにプッシュし、プッシュ要求を発行します。次に、誰かが変更をレビューし、開発にマージします。

競合を避けるために、誰もがプッシュする前に開発を自分のブランチにマージし、その段階で競合を解決します（したがって、ローカルで1人の開発者のみに影響します）。開発にマージすると競合が発生する場合、それはマージされません。開発者は開発を再びブランチにマージし、再びサーバーにプッシュしてから、再度レビューされます。

たとえば、sourcetreeを使用して、苦労せずにこの作業を行うことができます。