Git と GitHub について勉強メモ
Git
コミットは変更点を記録すること
プログラムの変更履歴を追うときにはコミットメッセージを読むためコミットがきれいに行われていると他人は履歴を追いやすい
どのコミットに戻りたいかを指定する時 →「コミットハッシュ」や「ハッシュ値」はコミットに対して固有の一つが割り当てられる → それを指定
リポジトリ
- ローカルリポジトリ
- リモートリポジトリ
ブランチに分けて作業を行う
マージするときに複数のチームが同じファイルの同じ部分を編集していた場合は「コンフリクト」という機能によって変更の衝突が起こる前に気づかせてもらうことができる。
git config の設定に関して
設定を消去したい時は...
git config --glibal **--unset** 設定項目名
とすればよい。
標準ブランチ名の設定
Windows を使っている人は標準で master に設定されているが、Windows 以外の OS を使っている人は、以下のようにして標準ブランチ名を設定する。
git config --global init.defaultBranch master
ローカルリポジトリの操作においての基本的なコマンド
リポジトリの作成
git init：ローカルリポジトリを作成
コミットの作成
git add：ステージングエリアに変更を登録
git commit：コミットの作成
git rm：Git 管理下のファイルやディレクトリを消去する
コミットメッセージについて https://git-scm.com/docs/git-commit#_discussion
状態の確認
git status：ローカルリポジトリ内の状況を確認
git diff：各エリアの差分を確認する
git log：コミットの履歴を確認する
状態の復元
git checkout：ワーキングツリーの変更を取り消す(移動のコマンドではなかったのか？)
git reset：ステージングエリアに追加した変更をワーキングツリーへ戻す
※ワーキングツリーとは...
Git で管理されている実際に作業を行うディレクトリ
git diff コマンドについて
git diff：ワーキングツリー内とステージングエリアの差
git diff ブランチ名ブランチでコミット後にそのブランチでの差を見れる
git diff --cached：ステージングエリアと Git ディレクトリの差
が確認できる
コミットされるのは git add コマンドでステージングエリアに登録した時点でのファイル
ステージングした後の変更は含まれていない →git add コマンドをもう一度使う必要がある。
ローカルリポジトリでの操作の取り消し
git checkout：ワーキングツリーでの変更の取り消し → ファイルの状態が直前のコミットまたは直前のステージングエリアへの登録までもどる
※厳密にはステージングエリアの状態まで戻す。
ファイルをいろいろ変更したけど直前のコミットまで戻したい場合。
git checkout -- ファイル名
パラメータにブランチ名を指定するとブランチを切り替えることもできる。
取り消せないケース
- ファイルを新しく作成した場合 → ファイルを新規作成したときはそのまま残ってしまう
- ファイル名を変更した場合 → 変更前のファイルと変更後のファイルの両方が残ってしまう
git reset：ステージングエリアへの変更の取り消し → ファイルの状態はそのままでステージングエリアへの登録だけを取り消し
git restore と git switch について
git checkout はワーキングツリーの変更を取り消す、特定のコミットにワーキングツリーの状態を切り替える、ブランチの作成、ブランチの切り替えなど機能が多い
↓
より分かりやすい役割分担のために導入されたのが git restore と git switch。
git restore：ワーキングツリーやステージングエリアの変更を取り消せる
git switch：ブランチの切り替え
ステージングエリアの登録を取り消す
git reset HEAD ファイル名
ここでの HEAD は最後にローカルリポジトリでコミットした状態を意味している →
ステージングエリアの状態を最後のコミットと同じ状態にリセットするという意味
git の管理下にあるファイルの消去
git rm コマンドを用いて Git で管理しているファイルやディレクトリを消去できる
このコマンドによって、ワーキングツリーから指定のものを消去してその状態をステージングエリアへ登録できる。
その他の方法でファイルやディレクトリを消去した場合は、ファイルを消去した状態をステージングする必要がある。
ディレクトリを消去するときは-rオプションが必要になる → ディレクトリの中身まで消去するオプション
git rm ファイルパス
git rm -r ディレクトリパス
改行コードの警告
git addコマンドを行う際に
warning: LF will be replaced by CRLF と表示されることがある。
Git をインストールしたときの改行コードの設定が影響している。
改行コードを LF で設定したファイルが CRLF で保存されることがあると警告。
変更されたくない場合は
git configコマンドで、core.autocrlfをfalseにする必要がある。
改行コードの警告について https://qiita.com/WebEngrChild/items/133484ca79fc90a207d5
.gitignore
ワーキングツリー内にこのファイルを指定してファイル名や指定の拡張子を中に記載すればそれに当てはまるファイルを無視できる。
Windows ではThumbs.db、MacOS では.DS_Storeは除外するようにする。
gitignore テンプレート https://github.com/github/gitignore
.gitignore の効果は.gitignore を作成したディレクトリ以下に影響する。
git logで過去のコミットの履歴が確認できる。
・コミットハッシュ
・コミットをした人の情報
・コミット日時
の順で表示される。
-pオプションでgit diffコマンドの時のような差分を確認できる
GitHub
公開鍵の設定
SSH Key を作成する
デバイスごとにひとつずつ作成した。
ssh-keygen -t ed25519 -C "mail address"
Enter file in ehich to save the key と表示されたらエンターキーを押す
この時表示される絶対パスが鍵の保存場所
パスワードの作成(流れに乗って)
.ssh/"name".pub の ssh key をコピーして
GitHub の Setting→SSH and GPG keys→New SSH Key→ タイトルを入力して公開鍵を張り付ける →Add SSH Key
上手く設定できたことを確認するために
ssh -T git@github.com
パスワード
Hi NAME! You've successfully authenticated と表示されたら設定完了
WSL から Github を使いたい場合この設定が必要？
git remoteでリモートリポジトリの設定などが確認できる。-vオプションなど
branch の作成
git branch ブランチ名で作成
git branchで現在どのブランチにいるか確認
git statusでも現在どのブランチにいるかが確認できる
git checkout 移動先ブランチコマンドでブランチを切り替える
push
git push プッシュ先のリモートリポジトリの名前 プッシュするブランチ名
e.g. git push origin branch-name
プルリクエストの作成
変更内容の欄はマークダウンを用いての作成が可能
ここで使われる略語に LGTM(Looks Good To Me)というものがある。プルリクエストの内容を承諾する意味合いを持っている。
Merge について
- Create a merge commit：枝分かれしたブランチの先がベースブランチに合成される
- Squash and merge：枝分かれしたトピックブランチをひとつにまとめる
- Rebase and merge：ベースブランチの最新のコミットの直後にブランチの枝分かれ元を合成する
pics #git merge
※Squash や Rebase は履歴の書き換えを行うため、GitHun の「いつでも過去の状態に戻せる」という特徴を失う可能性がある。
リモートからローカルに
- pull：取得内容がリポジトリ、さらにワーキングツリーにまで反映される
git pull プル先のリモートリポジトリ名 プルするブランチ名 - fetch：ローカルリポジトリまでの取得にとどまる
git fetch フェッチ先のリモートリポジトリ名
リモートリポジトリにしかない時は fetch を使用できる。fetch してから checkout で移動する。
About github workflow
Creating and deleting branches within your repository
Changing the default branch
If the branch you want to delete is associated with an open pull request, you must merge or close the pull request before deleting the branch.
merge コマンド
別のブランチの最新情報を取り込む。
情報を更新するだけでブランチはそれぞれ分かれたまま編集を続けることができる。
この Merge は情報を最新の状態に更新しているだけでブランチを完全に Merge しているわけではないんですよね？
はい、その通りです。git merge コマンドを使用すると、あるブランチから別のブランチへ変更を取り込みますが、これはブランチを"消去"するわけではありません。マージ操作は、指定されたブランチの変更を現在のブランチに統合するだけで、マージ元のブランチはそのまま残ります。
例えば、feature ブランチから main ブランチへマージする場合、feature ブランチの変更は main ブランチに取り込まれますが、feature ブランチ自体は削除されずに残ります。マージ後も feature ブランチで作業を続けることができ、必要に応じて再度 main ブランチ（または他のブランチ）にマージすることが可能です。
マージ操作により、複数のブランチで行われた変更を統合して、ソフトウェア開発のプロセスでコードの整合性を保つことができます。しかし、ブランチを完全に統合して一つにするわけではなく、あくまで変更内容をマージする操作です。ブランチを削除したい場合は、別途 git branch -d ブランチ名 コマンドを使用してブランチを削除する必要があります。
ブランチの消去
ローカルリポジトリ
マージ済みのブランチの消去
git branch --delete ブランチ名またはgit branch -d ブランチ名
マージの状況にかかわらずブランチを消去
git branch -D ブランチ名
リモートリポジトリ
ブランチの消去
git push --delete origin ブランチ名またはgit push origin :sessions-info
コンフリクト発生時において
警告文
- both modified：
- deleted by them：them はマージ先のブランチを指す
- added by you：you はマージ元である現在使用中のブランチを指す
コンフリクトが起こるとコードファイルには以下のように表示される
<<<<<<< HEAD
<td>編集後</td>
=======
<td>ハロー<td>
<td>編集前</td>
>>>>>>> master
<<<<<<< HEAD 使用中のブランチによる変更の開始地点
<td>編集後</td>
======= 二つのブランチの変更の境目
<td>ハロー<td>
<td>編集前</td>
>>>>>>> master マージ元のmasterブランチによる変更の終了地点
コンフリクトが起こっているファイルを編集してコンフリクトを解消したらもう一度コミットする。
コンフリクトにより失敗したマージは解消してコミットを行うまで、マージしている最中(マージ未完了)のままとみなされる
この時のコミットはgit commitのようにパラメータがいらない
remote ripository の追加
git remote add origin URL
README.md に画像を挿入する方法
記事を参考に行った
README.md にロゴを挿入する方法
記事を参考行った。
条件を選択し、MarkDown 形式の URL？を作成し、README.md に張り付けるだけ！
直前のコミットメッセージを修正する
git commit --amend -m "Commit message"
SSH キーを変更する
プッシュやクローン時に求められる SSH パスワードを変更する
ssh-keygen -p -f ~/.ssh/プライベートキーファイル名