Gitの基本概念
Gitとは Gitはオープンソースの分散バージョン管理システムです。小規模なプロジェクトから大規模なプロジェクトまで、迅速かつ効率的にバージョン管理を行うことができます。特徴: プロジェクトが大規模で複雑であればあるほど、共同開発者が多ければ多いほど、Gitの高いパフォーマンスと高い可用性を反映することができます！
Gitの特徴 Gitが高速で効率的なのは、次の2つの特徴があるからです：
1. 差分を比較する代わりにスナップショットを直接記録する 2. ほぼすべての操作をローカルで行うSVNにおける差分の比較 伝統的なバージョン管理システムは差分をベースとしており、ベースファイルの集合と、各ファイルに蓄積された差分を時間経過とともに保存します。
GitのレコードのスナップショットGitのスナップショットは、バックアップと同様に、ファイルの元のバージョンに基づいたファイルの新しいコピーです。効率化のために、Gitはファイルが変更されていない場合はもはや再保存せず、代わりに保存されたファイルを指すリンクを保持するだけです。Git スナップショット デメリット 多くのディスクスペースを占有する Git スナップショット メリット 各バージョンはファイルの完全なスナップショットであるため、バージョン間の切り替えが非常に高速。機能 時間のためのスペース、ほとんどすべての操作はローカルファイルとリソースにアクセスするだけでよく、一般的にネットワーク上の他のコンピューターからの情報は必要ありません 機能
- ネットワークから切断しても、プロジェクトをローカルでバージョン管理できます。
- ネットワーク接続後、ローカルで変更したレコードをクラウドサーバーに同期するだけです。
Gitの3つの領域Gitで管理されるプロジェクトには、ワークスペース、ステージング・エリア、Gitリポジトリの3つの領域があります。
ギットの3つの状態
- Modified modifiedは、ファイルが変更されたが、変更結果がステージング・エリアに置かれていないことを意味します。
- staged stagedとは、変更されたファイルの現在のバージョンが、次のコミットリストに含まれるようにマークされることを意味します。
- コミット済みとは、ファイルがローカルの Git リポジトリに安全に保存されていることを意味します：
- ワークスペースのファイルがまだステージングエリアに置かれておらず、変更されている場合は変更済みです。
- ファイルが変更されてステージングエリアに置かれた場合は、ステージされた状態です。
- Git リポジトリに特定のバージョンのファイルがある場合は、コミットされた状態です。
基本的なGitのワークフローは以下の通りです：
1. ワークスペース内のファイルを修正する 2. 次回コミットする変更をステージする 3. 更新をコミットし、ステージングエリアにあるファイルを探し、スナップショットを Git リポジトリに永久保存する。ユーザー情報の設定Git をインストールしたら最初にすべきことのひとつが、ユーザー名とメールアドレスの設定です。なぜなら、Git はこの基本情報を使って、プロジェクトをバージョン管理するときに誰が作業しているのかを追跡するからです：
git config --global user.name "yourname" git config --global user.email "yourname@MSN.com"注 --globalオプションを使用した場合、コマンドは1回実行するだけで永続的に有効になります。
コンフィギュレーション情報の確認Gitのグローバル・コンフィギュレーション情報を素早く表示するには、このターミナル・コマンドを押します：
# すべてのグローバル設定項目を表示する git config --list --global # 指定したグローバル設定項目を表示する git config user.name git config user.emailヘルプ
# git configコマンドのクイックガイド git config -hGit リポジトリを取得する二つの方法① バージョン管理されていないローカルディレクトリを Git リポジトリに変換する② 他のサーバーから既存の Git リポジトリをクローンするこの二つの方法で、自分のコンピューター上で使える Git リポジトリを手に入れることができます。
既存のディレクトリでリポジトリを初期化する1. プロジェクトファイルがあるディレクトリでターミナルを開きます 2. git init コマンドを実行してファイルを初期化します 3. ワークスペース内のファイルの状態を、大きく 2 つに分類します。
最初はファイルは追跡されておらず、git status を使うと Untracked files の下に表示されていることがわかります。
合理的な方法でファイルの状態を表示
# ファイルの状態をコンパクトに表示する git status -s // ショートカットは、ファイルの先頭に赤い ? で始めることだ。** git status --short // ファイルの色は赤 ```Gitでホストする必要がある場合は、git add 'librarian.html'というコマンドを使ってください。
git add '書籍管理.html'git status を使ってステータスを確認すると、index.html ファイルが一番下に表示されます。# ファイルの状態をコンパクトに表示する git status -s //この場合は新しいコミット、つまり最初のコミットである。 git status --short // ファイルの色は緑ステージングエリアにファイルができたので、git commit -m コマンドでファイルを Git リポジトリにコミットします。
mオプションの後には現在のコミットメッセージが続きます。
git commit -m " index.html "コミット後のステータスの確認 git status
On branch master nothing to commit working tree clean //ワークスペース内のすべてのファイルが「未修正」の状態にあり、コミットする必要のあるファイルがないことを証明する。コミットされたファイルに変更を加える 現在、librarian.html ファイルは Git によって追跡されており、ワークスペースと Git リポジトリの librarian.html の内容は同じままです。ワークスペースの librarian.html の内容を変更したら、もう一度 git status コマンドと git status -s コマンドを実行します。
`書籍管理.html` `Changes not staged for commit` この行の下にある は、追跡しているファイルの内容が変更されたが、まだステージングエリアに置かれていないことを示す。注 ステージングエリアに配置されていない変更されたファイルには、その前に赤い M マークが付きます。
変更されたファイルのステージング 現在、ワークスペース内の library.html ファイルが変更されています。 この変更をステージングしたい場合は、git add コマンドを再度実行する必要があります。このコマンドは、主に次の 3 つの効果を持つ多機能なコマンドです：
1. 新しいファイルの追跡を開始する 2. トラックされたファイルや変更されたファイルをステージする 3. 競合するファイルを解決済みとしてマークするファイルのステータスを見る`書籍管理.html` `changes to be commited` は、変更されたファイルがキャッシュに保存されていることを示す。 liteの場合は前面が緑色になる。M保留書類の提出
もう一度実行する `git commit -m "コミットメッセージ"` を指定すると、ステージングエリアの `書籍管理.html` スナップショット `Git` リポジトリにある変更の撤回
git checkout -- 書籍管理.html // ファイルがステージングされていないときに // このコマンドは、キャッシュに入っている場合は動作しない。キャッシュされたコンテンツの取り消し
git reset HEAD 書籍管理.html. //ステージングエリアのファイルを元に戻す git reset HEAD . //キャッシュ内のすべてのファイルを元に戻すGit の標準的なワークフローは、ワークスペース → ステージングエリア → Git リポジトリというものです。しかし、それでは少し面倒なこともあります。そこで、ステージングエリアを省略して変更を直接 Git リポジトリにコミットすることで、ワークスペース → Git リポジトリというワークフローを単純化することができます。Git には、ステージングエリアの使用を省略する方法が用意されています。コミット時に git commit -a オプションを指定すると、Git は自動的にすべての追跡済みファイルをステージングしてまとめてコミットします：
git commit -a -m "ログ情報"ファイルを削除する Git リポジトリからファイルを削除する方法はふたつあります：
- 対応するファイルを Git リポジトリとワークスペースの両方から削除します。
- 指定したファイルだけを Git リポジトリから削除し、対応するファイルはワークスペースに残します。
git commit -a -m "ログメッセージ"ファイルを無視
Git に入れたくないファイルや、追跡されていないファイルのリストに表示させたくないファイルは常に存在します。 このような場合は、.gitignore という設定ファイルを作成し、無視したいファイルのマッチパターンを列挙します。
.gitignoreファイルのフォーマットは以下のように標準化されています：
# Git リポジトリとワークスペースを同時に削除する ライブラリ管理.js git rm -f index.js # Git リポジトリからのみ削除する index.cssただしライブラリはワークスペースに残す.css git rm --cached 書籍管理.cssアスタリスク * は、0個以上の任意の文字にマッチします。
[abc] は、角括弧内にリストされた文字のいずれかにマッチします。
クエスチョンマーク ?任意の1文字にのみマッチ
2つのアスタリスク ** は、任意の中間ディレクトリにマッチすることを意味します。
角括弧内の2文字をダッシュで区切ると、その2文字以内はすべてマッチすることになります。
.gitignore ファイルの例
1. **# **はコメント 2. **/ **はディレクトリ 3. **/ **再帰を防ぐ **! **は逆を意味する 指定したバージョンにフォールバックする **glob **ファイルとフォルダのマッチング投稿履歴を見る
#すべてを無視する.a *.a # を無視した場合でも .aファイルにフォールバックするが、すべてのlib.a lib.a # カレントディレクトリの TODO ファイルを無視する。subdir/TODO /TODO #任意のディレクトリにある bulid という名前のフォルダを無視する。 bulid/ # doc/notes.txt を無視せずにdoc/server/arr.txt doc/*.txt # doc/ディレクトリとそのすべてのサブディレクトリにフォールバックする .pdf doc/**/*.pdf指定バージョンへのフォールバック
# すべてのコミットを時系列に並べ、最新のコミットを先頭に表示する。 git log # 直近の 2 つのコミットだけが表示されるので、好きなように数字を記入することができる。 git log -2 # 直近の 2 つのコミットを一行で表示する git log -2 --pretty=oneline # 直近の 2 つのコミットを一行で表示し、出力フォーマットをカスタマイズする # &h コミットの省略形ハッシュ %an 作者名 %ar 作者のリビジョンログ %s コミットの説明 git log -2 --pretty=format:"%h | %an | %ar | %s"
