基礎編
管理ファイルの状態
状態として3段階、リモート含めると4段階ある。
| 状態 | 内容 |
|---|---|
| WorkingTreeの状態 | ローカルで変更したのみ |
| Index済み状態、Staging | 変更リストにのった状態(addした状態) |
| Commiting状態 | リポジトリにCommitして、変更バージョンが記録された状態 |
| Push済み状態 | リモートリポジトリにも変更バージョンを反映・記録した状態 |
リビジョン番号：ハッシュ値
Gitはリビジョンを連番ではなく、ハッシュ値で管理する。複数人作業やブランチなどで連番の管理はできないため。
よく使うハッシュ値には別名がついている。
HEAD
- 最新のCommitの「状態」(LocalRepositoryの状態)を表す
- ^か~をつけることで「直前のコミット」という意味になる
- 省略して「@」でもいい。(HEAD=@)
- 最新のコミットに対するハッシュ値の別名
ORIG_HEAD
- 最新の1つ手前のコミットに対するハッシュ値の別名
- reset の reset(resetの取り消し)などで使う
用語・概念
stage, staging(ステージング)
- ローカルの変更をcommitに含めるようにindex指示すること
リポジトリ名 : 代表例 origin
- サーバーURLの別名。URL直接指定でもOK。それを省略しているだけ。
ブランチ名 : 代表例 master
- ブランチ名。ローカルにも、リモートにもブランチはあるので、実際には master:master がフル名らしい。
- (ローカルのmasterブランチを、リモートのmasterブランチへ) ということ
git push
-
どこのリモートサーバーへ、どのローカルブランチを、コミットするか指定する必要があるので
-
git push origin master となる、つまり
git push [リポジトリ名] [ブランチ名] -
基本は以下のときに、push先が自動決定される
-
リモートを clone したとき、
-
リモートブランチからローカルブランチへチェックアウトしたとき
git reset
- ステージングされた変更を戻す
git checkout
- ブランチの切替。どのブランチを使うか。
- その結果として？ローカルの変更を取り消す、ことにも使う。
Gitの始め方・最初の手順
- バージョン管理したいファイルを作成
- 管理したいディレクトリで
$ git init（gitリポジトリ作成。つまりgitの準備） $ git add .でIndex(ステージング)$ git commit -m "ファイル追加"でメッセージ付きコミット
Git・GitHubのユーザー管理
Gitは環境(主にPC)ごとに、ユーザーを作成。コミットすると、そのユーザーとしてコミットしたことになる(コミット履歴にユーザー名が残る)。
ユーザー設定コマンド
$ git config
Gitのコマンドテーブル一覧
状態確認系
| コマンド | 用途 |
|---|---|
| git status | ファイル状態全般確認。何がStagingかとか |
| git log -2 | Commit履歴 最新2件の確認 |
| git log -2 –stat | Commit履歴 最新2件 + 変更ファイル表示 |
変更の登録・管理
| コマンド | 用途 |
|---|---|
| git add . | ローカルファイルをすべてIndex化(ステージング) |
| git commit -m “message” | コメント付きコミット |
| git stash | 変更退避 |
用途別でのコマンド一覧テーブル
| コマンド | 用途 |
|---|---|
| 状態を確認する | git status |
| Commit履歴の確認 | git log -2 |
参考サイト
- よく使うGitコマンド一覧
- 上記サイトからひとまず自分がよく使うものをピックアップして写経↓
確認コマンド
-
何も変更されないので安心の、初期は何度も叩いたほうがいいコマンド
-
git status
-
ファイル状態全般確認。何がStagingかとか
-
git log -2
-
Commit履歴 最新2件
-
git log -2 –stat
-
Commit履歴 最新2件 + 変更ファイル表示
-
git log –oneline
-
簡易的に各コミットを1行で表示 : よく使う
変更
-
git add .
-
WorkTreeファイル(ローカルファイル)をすべてaddでStaging
-
git commit -m “message”
-
コメント付けて Commit
-
git commit -F- <<EOM
-
複数行コメントで Commit
-
git commit –amend
-
直前のコミットを編集
-
git stash
-
変更退避
取り消し
-
変更をなかったことにする(履歴含めて消す) : git reset
-
変更をもとに戻す更新をする(履歴は残る) : git revert
-
git reset ではリモート側まで取り消すことはできない(単純には。)
-
リモート側も戻すなら、revert して push するのが一番シンプルそう
-
git reset –[mode] [commit] が基本
-
mode
-
[mode]が、hard、mixed、softで、WorkingTree、Staging、Commit(HEAD)のどこまでを戻すかが変わる
-
hard : WorkingTree、Staging、Commitを対象にする
-
mixed : Statging、Commit を対象にする
-
soft : Commit を対象にする
-
modeは引数省略時は –mixed (公式ドキュメント(https://git-scm.com/docs/git-reset))
-
※リモート側を含めて取り消すようなOptionはない
-
commitの指定
-
commitは HEAD^ だとそのCommit内容自体を指し、HEADだとそのバージョン自体を指す
-
HEAD^^ だと2つ前までのコミットを指す
-
reset HEAD^ : 直前のCommitを取り消す(1つ前のCommitバージョンに戻す)
-
reset HEAD : HEADのバージョンに戻す(なのでhardならIndexとWorkTreeの変更を取り消す、ことになる)
-
なので例えば、reset –soft HEAD は特に意味をなさない(LocalRepositoryを最新のCommitにする、なので)
-
git reset
-
IndexをWorkingTreeに戻す(Staging(add)の取り消し)
-
つまり実際には git reset –mixed HEAD と同じ意味
-
(HEADに戻すのでCommitの取り消しは発生せず、Stagingを戻すだけ)
-
git reset –hard HEAD^
-
Commit(HEAD)、Staging(Index)、WorkingTreeすべてについて1つバージョンを戻す(ローカル含め全変更を戻す)
-
git reset –mixed (引数省略の git reset と同じ)
-
Commit(HEAD)、Staging(Index)を戻す(ローカルに変更は残る)
-
git reset –soft HEAD^
-
Commit(HEAD)を戻す(Local Repository上のバージョンが1つ戻るのみ)
-
git reset HEAD
-
fileをHEADの状態に戻すので、fileのStagingを取り消すのと同じ
-
git reset [–mode] ORIG_HEAD
-
直前のresetを取り消す
-
git revert [commit_id]
-
特定のcommitを取り消す
Revert
- push までしてる場合も、ローカルでまずcommitを revertした stageを作って、それを commit, pushして戻す
- GitLensなら、changelistごとの右クリックで、revert を選べる
- Rebaseは Revertの履歴すら残さず、なかったことにする
- 参考 https://qiita.com/Mount/items/afe0c414edb5bf3473b5#revert-commit
Branch(ブランチ)
-
git branch [ブランチ名]
-
ブランチの作成
-
git switch [ブランチ名]
-
ブランチに切り替え
-
git switch -C [ブランチ名]
-
ブランチの作成と切り替え(=git branch + git switch)
GitHubとの連携
認証方法①：https
GitHubのリポジトリURLをリモート接続先として設定する方法。
基本的にはなにか操作をする際に、GitHubのユーザー名とパスワードが求められる。
リモートの登録から、pushまでのコマンドは以下。
git remote add origin https://github.com/prog-log/GameDev.git
git branch -M main
git push -u origin main
認証方法②：ssh
SSH(ローカルで秘密鍵・公開鍵を生成してGitHubに公開鍵を登録することで認証する)による認証方法。
sshのほうがパスワード入力等が不要なので、都度ごとの手順も楽かつパスワードの漏洩などの心配もない(httpsは暗号化されているので基本問題ないが。)ので、こちらのほうが主に使われる。
リモートの登録から、pushまでのコマンドは以下。
git remote add origin git@github.com:prog-log/GameDev.git
git branch -M main
git push -u origin main
Visual Studioでのリモートリポジトリ管理 : https
Visual Studio(以降VS)では、VS上でGitHubアカウントのサインイン登録を行うことでGitHubリモートリポジトリにアクセス可能。
つまりはhttpsによる認証を、VSがユーザー名とパスワードを管理することで、スムーズに連携可能。
楽だが、代わりに別アカウントのGitHubリポジトリに接続するのはできない（複数ユーザー名・パスワード管理ができないため）。
複数リモートリポジトリに接続する場合、sshの接続先を設定し、sshコマンドがPATHに通っていればやれる？
画像
コメント