クラスメートで仕事を始める前に、バージョン管理システムの使い方を知っていたと思いました。 しかし、そこで彼らは
gitドキュメントへのリンクをくれました。 この本は際限なく読むことができますが、私の意見では、gitの使用を開始するためにはまったく役に立ちません。 これは問題ではない、とあなたは言います、そしてあなたは絶対に正しいでしょう。 同じハブに、gitの使用方法に関する記事がたくさんあります。 しかし、数日前、私の友人から、理解できない瞬間を説明してほしいと頼まれました。 「日常業務でgitを使用するための10の簡単な手順」というトピックで、別のチートシートを共有する方法と共有したい方法を説明しました。 それほど小さくはないことがわかったので、とりあえず作業中のプロジェクトでgitを使用する方法を書き、それから別の人のプロジェクトに変更を加えたい場合はどうすればよいかを書きます。
gitの認証を構成する方法については説明しません。私の知る限り、sshキーを設定するか、ユーザー名/パスワードを使用してグローバルまたはローカルgit設定に入力できます。 githubでアカウントを開始すると、すべてのことが書かれていると思います。 個人的には、Linuxを使用しており、github用のpub / priv sshキーを構成しています。 Windowsでは、通常cygwinを使用し、そこで同じsshキーを使用しました。
その他。 何らかの不明な理由により、IDEを使用してgitを操作することはほとんどありません。 IDEを使用する場合、どのバージョン管理システムを使用するかは問題ではないと思います。
プロジェクトを操作する10の手順
gitを使用している会社で働いている場合の対処方法を書きたいと思います。 原則として、行うタスクごとに、個別のブランチ(ブランチ)を開始し、タスク管理システムのタスクの名前(たとえば、JIRAのタスクの名前)で呼び出し、タスクを完了して他の従業員がコード検証手順を渡す必要があります。ブランチを共通のコードと組み合わせます。
- プロジェクトのローカルコピーを作成する
githubの場合、project_urlは、プロジェクトページの緑色のボタン「クローンまたはダウンロード」をクリックして見つけることができます。
- ローカルコピーの更新-他の参加者がこのスレッドに加えた変更の読み込み
注-gitは更新する場所がわからないことを誓います自分でデフォルト設定でブランチを作成した場合、gitはブランチの更新元を正確に知らないと言いますが、オプションを推測して提案します。 彼のチップを使用してください。
注-競合が発生しましたローカルでファイルを変更し、updateがそれらを変更した場合、gitは愚かにプルを許可しません。 ここでgit stash / git pull / git shash popを使用できます。
変更を加えてコミットするとします。 2つのオプションがあります-変更と削除されたものが競合しない場合、gitは別の追加のコミットを作成し、この新しく作成されたコミットのメッセージを編集することを提案します。
競合がある場合は、そうします。
競合するファイルを確認(両方変更)
、編集、追加
コミットする
- 現在のブランチの名前、ローカルで変更されたファイル、共有サーバーに送信しなかったコミットを確認します。
- ローカルの変更をすべて破棄します。 慎重に適用し、足で撃つことができます。
注:最新のIDEはファイルの変更履歴をローカルに保存するため、大したことはありません。 撃て。
- 通常、JIRAのタスクの名前でブランチを作成します。 注:ブランチは現在のブランチから作成されます(前の段落を参照)。したがって、原則として、最初にmasterブランチに切り替える必要があります。 変更されたファイルがある場合、それは大丈夫です-それらはどこにも行かないでしょう。
マスターブランチに切り替えます。
新しいブランチを作成します。
- 友だちが見ているブランチに変更を加える場合は、最初にアップグレードしてから、彼のブランチに切り替える必要があります
- 他の参加者がメインブランチに加えた変更を定期的に吸い込み、後で不整合の問題が発生しないようにします
- ローカルに変更を加えた後、それらはいわゆる「コミット」でなければなりません。 gitはローカルバージョンに変更を加え(新しいコミットを作成)、サーバーには何も送信しないことに注意してください。 サーバーに送信する別のコマンドがあります。 個人的には、IDEのコメディーです。 しかし、あなたは手でそれを行うことができます。
コミットしたいファイルをgitに伝えます:
またはすべてのファイルを一度に
コミット:
- サーバー上のリポジトリにファイルを送信します
注-gitは送信先がわからないことを誓います-パラグラフ2の注を参照してください。
注-gitはファイルが更新されないことを誓います通常、gitサーバーの設定では、誰かがブランチに変更を投稿した場合、変更を投稿できません。 したがって、ブランチのステータスを更新する必要があります-ポイント2を参照してください。
- レビューの変更を他のメンバーに送信します。 これはUIのことで、gitとは関係ありません。 たとえば、githubでは、UIのブランチに移動してプルリクエスト(PR)を作成するだけです。
- 変更をメインブランチにマージします。 いくつかのオプションがあります。 デフォルトでは、gitは単にすべてのコミットを共有ブランチに埋め込みます。 つまり、誰もが、骨の折れる日々の労働の結果を失わないように、組み立てられていないビルド、落下テスト、およびあなたが行った夜のコミットを修正しようとするあなたの不条理な試みを見るでしょう。 これはあなたが露出狂なら良いことですが、原則としてすべてのコミットを1つにまとめて、1つのコミットだけで共通のブランチに埋め込む(いわゆるスカッシュコミット)ことをお勧めします。間違って、変更をロールバックします。 したがって、スカッシュを行うことをお勧めします。
github ui magic
githubインターフェースには緑のスカッシュ&コミットボタンがあります。 UIを使用して、ブランチに移動し、プルリクエスト(PR)を作成し、PRインターフェイスで[squash&commit]を選択して押します。
スカッシュコミット
メインブランチ(マスター)に移動します
更新しました
スカッシュコミットを行う
。 ブランチからのすべての変更はローカルとして表示されますが、すでにメインブランチに表示されます。 積み上げているものを見ます。 変更の表示-アイテム3.コミット-アイテム8、サーバーへの送信-アイテム9。メインブランチではなくスカッシュコミットを行うことができますが、新しいブランチを作成し、その中でスカッシュコミットを行い、メインブランチでマージを行います(次の段落を参照)。
併合する
この場合のコミットは1つにまとまりません。 メインブランチ(マスター)に移動します
更新しました
、通常のコミットを行います
、サーバーに送信-ポイント9。
リベース
ブランチをリベースし、たとえば、すべてのコミットを1つにまとめることができます。
個人的に、私はしませんすべてのコミットを選択し、自分のもの(マスターから追加されたもの)から分離するための魔法が必要であり、ここでリベース中にマスターからプルされたコミットの変更に遭遇する可能性があります。 ウィザードから変更をプルするたびにリベースできます。 お茶として同じブランチで一緒に作業してリベースすると、競合の可能性が高くなるので、私もそれをしません。
注:
- 共通のコードを持つブランチは通常、マスターと呼ばれます。
- ローカルの変更をすべて隠すことができます-git stashコマンドを参照してください。
- 他のブランチからブランチにコミットを適用できます-git cherry-pickを参照してください。
- 魔法。 リベース いくつかのコミットを1つに接着するか、コミットをローカルブランチからリストの一番上に移動します-後で簡単に接着できるように-git rebase