紹介の代わりに
こんにちは、将来のシニア ソフトウェア エンジニアです。Git の基本
Git はコードの分散バージョン管理システムです。なぜそれが必要なのでしょうか? 分散チームには、何らかの作業管理システムが必要です。時間の経過とともに発生する変化を追跡するために必要です。つまり、どのファイルがどのように変更されたかを段階的に確認します。これは、1 つのタスク内で何が行われたかを分析する場合に特に重要です。これにより、前に戻ることが可能になります。状況を想像してみましょう。動作するコードがあり、すべてが良好でしたが、何かを改善し、ここで微調整し、あそこで微調整することにしました。すべて問題ありませんでしたが、この改善により機能の半分が壊れ、作業できなくなりました。それで、次は何でしょうか？ギーターがなければ、人は何時間も座って、すべてが元々どのようであったかを思い出さなければなりません。それで、コミットにロールバックするだけで完了です。あるいは、2 人の開発者が同時にコードを変更した場合はどうなるでしょうか? Git がなければ、次のようになります。オリジナルからコードをコピーし、必要なことを実行しました。その瞬間が来て、両方ともメイン フォルダーに変更を追加したいと考えます。この状況ではどうすればよいでしょうか? この作業にかかる時間を見積もる勇気さえありません。Gitを使えばそのような問題は全くありません。Gitのインストール
コンピューターに Git をインストールしましょう。人それぞれOSが異なると思いますので、いくつかのケースに分けて説明してみます。Windows 用のインストール
いつものように、exe ファイルをダウンロードして実行する必要があります。ここではすべてが簡単です。最初の Google リンクをクリックしてインストールするだけです。作業には、提供されている bash コンソールを使用します。Windows で作業するには、Git Bash を実行する必要があります。スタート メニューでは次のようになります。
これはすでに作業できるコンソールです。git を開くたびにプロジェクトのあるフォルダーに移動しないようにするには、フォルダーを右クリックして、必要なパスを含むコンソールを開きます。 
Linux 用のインストール
git は元々 Linux カーネルを開発するために作成されたツールであるため、通常、git はすでにインストールされ、Linux ディストリビューションに含まれています。しかし、それが存在しない状況もあります。これを確認するには、ターミナルを開いて「git --version」と入力する必要があります。明確な答えがある場合は、何もインストールする必要はありません。ターミナルを開いてインストールします。私は Ubuntu で作業しているので、Ubuntu に何を書けばよいかを説明できます: sudo apt-get install git。これで、どのターミナルでも Git を使用できるようになります。macOS へのインストール
ここでも、最初に Git がすでに存在するかどうかを確認する必要があります (Linux の場合と同様、上記を参照)。そうでない場合は、最新バージョンをダウンロードするのが最も簡単な方法です。XCode がインストールされている場合は、Git も自動的にインストールされます。Gitのセットアップ
git には、作業を実行するためのユーザー設定があります。これは合理的であり、必要なことです。コミットが作成されると、Git はまさにこの情報を Author フィールドに取得するからです。すべてのプロジェクトにユーザー名とパスワードを設定するには、次のコマンドを入力する必要があります。
git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com
git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.comちょっとした理論...
話題を逸らさないように、メッセージにいくつかの新しい言葉や行動を追加することをお勧めします。そうしないと、話すことが何もなくなってしまいます。もちろん、これは専門用語と英語のコピーですので、英語で意味を追加します。どのような言葉や行動でしょうか？- git リポジトリ;
- コミット（コミット）;
- 支店;
- マージ;
- 紛争。
- 引く;
- 押す;
- 一部のファイル (.gitignore) を無視する方法。
Git の状態
ギータには、理解して記憶する必要があるいくつかの状態があります。- 追跡されていない;
- 変更されました。
- 準備された（演出された）。
- 関与する。
それはどういう意味ですか？
これらは、コードのファイルが配置されている状態です。つまり、彼らの人生の道は通常次のようになります。- 作成されてもリポジトリに追加されていないファイルは、追跡されていない状態になります。
- Git リポジトリに既に追加されているファイルに変更を加えます。これらのファイルは変更された状態になります。
- 変更したファイルから必要なものだけ (またはすべて) を選択し (たとえば、コンパイルされたクラスは必要ありません)、変更を加えたこれらのクラスはステージングされた状態になります。
- ステージングされた状態で準備されたファイルからコミットが作成され、Git リポジトリに入れられます。この後、ステージングされた状態は空になります。ただし、変更されたものにはまだ何かが含まれている可能性があります。
コミットとは何ですか
コミットはバージョン管理の主要なオブジェクトです。これには、そのコミット以降のすべての変更が含まれています。コミットは、単一リンクされたリストのように相互にリンクされます。つまり、最初のコミットがあります。2 番目のコミットが作成されると、(2 番目の) コミットは最初のコミットの後に来ることがわかります。このようにして、情報を追跡することができます。コミットには、メタデータと呼ばれる独自の情報もあります。- それを見つけることができる一意のコミット識別子。
- それを作成したコミット作成者の名前。
- コミット作成日。
- このコミット中に何が行われたかを説明するコメント。
支店とは
ブランチはコミットへのポインタです。コミットはどのコミットがその前にあったかを知っているため、ブランチがコミットを指す場合、以前のすべてのコミットもそのコミットを参照します。これに基づいて、同じコミットを指すブランチはいくつでも存在できると言えます。作業はブランチ上で行われるため、新しいコミットが作成されると、ブランチはポインタを新しいコミットに移動します。
Git を始める
ローカル リポジトリまたはリモート リポジトリでのみ作業できます。必要なコマンドを実行するには、ローカル リポジトリのみを使用できます。すべての情報は、プロジェクトのローカルの .git フォルダーにのみ保存されます。リモートについて話す場合、すべての情報はリモート サーバー上のどこかに保存されます。プロジェクトのコピーのみがローカルに保存され、その変更はリモート リポジトリにプッシュ (git Push) できます。ここでは、コンソールでの git の操作についてさらに説明します。もちろん、いくつかのグラフィカル ソリューション (Intellij IDEA など) を使用することもできますが、まず、どのようなコマンドが発生しているのか、そしてその意味を理解する必要があります。ローカル リポジトリでの Git の操作
次に、記事を読みながら私が行ったすべての手順に従うことをお勧めします。これにより、内容の理解と記憶力が向上します。どうぞよろしく :) ローカル リポジトリを作成するには、次のように記述する必要があります。
git init
これにより、コンソールがある場所に .git フォルダーが作成されます。.git は、Git リポジトリに関するすべての情報を保存するフォルダーです。削除する必要はありません ;) 次に、ファイルがこのプロジェクトに追加され、そのステータスが「未追跡」になります。現在の作業ステータスを確認するには、次のように書きます。
git status
私たちは master ブランチにいますが、別のブランチに移動するまで、すべてがそのまま残ります。こうすることで、どのファイルが変更されたがまだステージング状態に追加されていないのかを確認できます。これらをステージングされた状態に追加するには、 git add を記述する必要があります。ここにはいくつかのオプションがある場合があります。たとえば、次のとおりです。
- git add -A - ステージングされた状態からすべてのファイルを追加します。
- git add 。— このフォルダーのすべてのファイルとすべての内部ファイルを追加します。基本的には前のものと同じです。
- git add <filename> - 特定のファイルのみを追加します。ここでは、正規表現を使用して、いくつかのパターンに従って追加できます。たとえば、 git add *.java: これは、拡張子が java のファイルのみを追加する必要があることを意味します。
git add *.txt
git status
このことから、正規表現が正しく機能し、test_resource.txt がステージングされた状態になっていることがわかります。そして最後に、最後の段階 (ローカル リポジトリの場合、リモート リポジトリの場合はもう 1 つあります ;)) - コミットして新しいコミットを作成します。
git commit -m “all txt files were added to the project”
次に、ブランチのコミット履歴を確認するための優れたコマンドがあります。使ってみましょう:
git log
ここでは、転送したテキストとともに最初のコミットが表示されていることがすでにわかります。渡すテキストは、このコミット中に何が行われたかを可能な限り正確に定義する必要があることを理解することが非常に重要です。これは将来何度も役立ちます。まだ眠りに就いていない好奇心旺盛な読者は、「GitTest.java ファイルはどうなったの?」と言うかもしれません。これで次のことがわかります。
git status
ご覧のとおり、追跡されていない状態のままで翼の中で待機しています。それともプロジェクトにまったく追加したくないのでしょうか? しばしばそれは起こります。次に、さらに面白くするために、テキスト ファイル test_resource.txt を変更してみましょう。そこにテキストを追加してステータスを確認してみましょう。
git status
ここでは、追跡されていない状態と変更された状態の 2 つの状態の違いがはっきりとわかります。GitTest.java は追跡されていない状態で、test_resource.txt は変更された状態です。すでに変更された状態のファイルがあるので、それらに加えられた変更を確認できます。これは次のコマンドを使用して実行できます。
git diff
つまり、テキスト ファイルに hello world! を追加したことがここではっきりとわかります。テキスト ファイルに変更を追加してコミットします。
git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”
git log
ご覧のとおり、すでに 2 つのコミットがあります。同様に、GitTest.java を追加します。コメントはありません。コマンドだけです。
git add GitTest.java
git commit -m “added GitTest.java”
git status
.gitignore の操作
リポジトリにはソース コードのみを保存し、他には何も保存しないことは明らかです。他に何があるでしょうか？少なくとも、開発環境を作成するコンパイル済みのクラスやファイル。Git がそれらを無視するには、特別なファイルを作成する必要があります。これを行います。プロジェクトのルートに .gitignore というファイルを作成します。このファイルの各行は無視するパターンになります。この例では、 gitignore は次のようになります。
```
*.class
target/
*.iml
.idea/
```- 最初の行は、.class 拡張子を持つすべてのファイルを無視します。
- 2 行目は、ターゲット フォルダーとそこに含まれるすべてのものを無視することです。
- 3 行目は、.iml 拡張子を持つすべてのファイルを無視します。
- 4 行目は、.idea フォルダーを無視することです。
git status
明らかに、(git add -A を使用する場合) コンパイル済みクラスをプロジェクトに誤って追加することは望ましくありません。これを行うには、.gitignore ファイルを作成し、前に説明したものをすべて追加します。 
次に、新しいコミットでプロジェクトに gitignore を追加しましょう。
git add .gitignore
git commit -m “added .gitignore file”
git status
すべてが明らかです) Git 無視 +1)
ブランチなどの操作
もちろん、1 つの支店で働くのは 1 人にとっては不便ですし、チームに複数人がいる場合は不可能です。これには支店があります。前に述べたように、ブランチは単にコミットへの移動ポインタです。このパートでは、さまざまなブランチでの作業、つまりあるブランチから別のブランチに変更をマージする方法、どのような競合が発生するかなどを見ていきます。リポジトリ内のすべてのブランチのリストを表示し、どのブランチにいるかを理解するには、次のように記述する必要があります。
git branch -a
master ブランチが 1 つだけあり、その前のアスタリスクがそのブランチ上にあることを示していることがわかります。ちなみに、どのブランチにいるかを確認するには、ステータスチェック (git status) を使用することもできます。次に、ブランチを作成するためのオプションがいくつかあります (おそらく他にもあるので、私はこれらを使用しています)。
- 現在のブランチに基づいて新しいブランチを作成します (99% の場合)。
- 特定のコミットに基づいてブランチを作成します (1%)。
特定のコミットに基づいてブランチを作成する
一意のコミット識別子に依存します。それを見つけるには、次のように書きます。
git log
「added hello world...」というコメントを付けてコミットを強調表示しました。一意の識別子「6c44e53d06228f888f2f454d3cb8c1c976dd73f8」が付いています。このコミットから始まる開発ブランチを作成したいと思います。このために、私は次のように書きます。
git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8
git status
git log
それは本当です。コミットが 2 つあることが判明しました。ところで、興味深い点です。このブランチにはまだ .gitignore ファイルがないため、コンパイルされたファイル (GitTest.class) は追跡されていない状態で強調表示されています。ここで、次のように記述してブランチを再度修正できます。
git branch -a
マスターと開発の 2 つのブランチがあり、現在は開発中であることがわかります。
現在のブランチに基づいてブランチを作成する
ブランチを作成する 2 番目の方法は、別のブランチ上に構築することです。master ブランチに基づいてブランチを作成したいので、最初にそれに切り替える必要があり、次のステップでは新しいブランチを作成します。見てみよう：- git checkout master - master ブランチに移動します。
- git status - マスター上にあるかどうかを確認します。
ここでは、master ブランチに移動し、gitignore がここですでに動作しており、コンパイルされたクラスが追跡されていないように表示されなくなっていることがわかります。次に、master ブランチに基づいて新しいブランチを作成します。
git checkout -b feature/update-txt-files
このブランチがマスターと同じではないことに疑問がある場合は、git ログを書き込み、すべてのコミットを確認することで簡単に確認できます。それらは 4 つあるはずです。
競合を解決する
競合とは何かを理解する前に、あるブランチを別のブランチにマージ (マージ) することについて説明する必要があります。この図は、あるブランチが別のブランチにマージされるときのプロセスを示しています。
つまり、メイン ブランチが存在します。ある時点で、そこから二次的なものが作成され、そこで変更が発生します。作業が完了したら、あるブランチを別のブランチにマージする必要があります。さまざまな機能については説明しません。この記事の枠組み内での理解のみを伝えたいので、詳細は必要に応じて自分で調べてください。したがって、この例では、feature/update-txt-files ブランチを作成しました。支店名に書いてありますので本文を更新させていただきます。 
ここで、この件に関して新しいコミットを作成する必要があります。
git add *.txt
git commit -m “updated txt files”
git log
ここで、feature/update-txt-files ブランチをマスターにマージする場合は、マスターに移動して git merge feature/update-txt-files を記述する必要があります。
git checkout master
git merge feature/update-txt-files
git log
その結果、master ブランチにも、feature/update-txt-files に追加されたコミットが含まれるようになりました。この機能は、機能ブランチを削除できるように追加されました。これを行うには、次のように書きます。
git branch -D feature/update-txt-files
git checkout -b feature/add-header
... делаем изменения в файле
git add *.txt
git commit -m “added header to txt”
master ブランチに移動し、feature ブランチと同じ行にあるこのテキスト ファイルも更新します。
git checkout master
… обновor test_resource.txt
git add test_resource.txt
git commit -m “added master header to txt”
git merge feature/add-header
ここでは、Git がこのコードをマージする方法を独自に決定できず、まず競合を解決してからコミットする必要があることがわかります。OK、競合を含むファイルをテキスト エディターで開いて見てみましょう。
ここで git が何をしたかを理解するには、どこに何を書いたかを覚えて比較する必要があります。
- 「<<<<<<< HEAD」と「=======」の間は、master ブランチのこの行にあったマスターの変更です。
- 「=======」と「>>>>>>>> feature/add-header」の間には、feature/add-header ブランチに加えられた変更があります。
変更のステータスを見てみましょう。説明は少し異なります。変更された状態はありませんが、マージされていません。したがって、安全に 5 番目の状態を追加できます...しかし、これは不要だと思います。見てみましょう:
git status
私たちは、これは別の、珍しいケースであると確信していました。続けましょう：
git add *.txt
説明では、 git commit の記述のみを推奨していることがわかります。私たちは聞いて書きます：
git commit
以上です。これが私たちのやり方です。コンソール内の競合を解決しました。もちろん、開発環境では、これをもう少し簡単に行うことができます。たとえば、Intellij IDEA では、すべてが適切にセットアップされているため、必要なアクションをすべて実行できます。しかし、開発環境は内部で多くのことを行っており、そこで何が起こっているのか正確に理解できないことがよくあります。そして、理解がないと、問題が発生する可能性があります。
リモートリポジトリの操作
最後のステップでは、リモート リポジトリを操作するために必要なさらにいくつかのコマンドを理解します。すでに述べたように、リモート リポジトリは、リポジトリが保存され、そこからクローンを作成できる場所です。リモートリポジトリにはどのような種類がありますか? たくさんの例があります:-
GitHub は、リポジトリと共同開発のための最大のリポジトリです。以前の記事でも説明しました。私の Github アカウント
を購読してください。私は仕事中に研究している分野でよくそこで作品を展示しています。 -
GitLabは、オープンソースのWebベースのDevOpsライフサイクル ツールで、独自の Wiki、問題追跡システム、CI/CD パイプライン、その他の機能を備えたGit用のコードリポジトリ管理システムを提供します。 Microsoft が GitHub を買収したというニュースの後、一部の開発者は自分の作業を GitLab で複製しました。
-
BitBucket は、Mercurial および Git バージョン管理システムに基づいて、プロジェクトとその共同開発をホスティングするための Web サービスです。かつては、無料のプライベート リポジトリがあるという点で、GitHub よりも大きな利点がありました。昨年、GitHub もこの機能を誰でも無料で利用できるようにしました。
-
等々…
git clone https://github.com/romankh3/git-demo
git pull
私たちの場合、リモートでは何も変わっていないので、答えは「すでに最新です」です。ただし、リモート リポジトリに変更を加えた場合、ローカル リポジトリはプル後に更新されます。そして最後のコマンドは、データをリモート リポジトリにプッシュすることです。ローカルで何かを実行し、それをリモート リポジトリに転送したい場合は、まずローカルで新しいコミットを作成する必要があります。これを行うには、テキスト ファイルに何か他のものを追加しましょう。 
これは私たちにとって一般的なことです。この件についてコミットを作成します。
git add test_resource.txt
git commit -m “prepated txt for pushing”
git push
私が言いたかったのはそれだけです。ご清聴ありがとうございました。私の GitHub アカウントを購読してください。そこでは、私が研究したり仕事で使用したりしたさまざまなクールなサンプル プロジェクトを投稿しています。
役立つリンク
- Git に関する公式ドキュメントはロシア語です。参考書としてオススメします。
- ギット
GO TO FULL VERSION