Git
リモートリポジトリをローカルに持ってくる
配置したい場所でgit clone githubのurl
git fetch --allで大体OK
CLIだけでリモートリポジトリ立てる時
githubで作るとコマンド出してくれる
https://scrapbox.io/files/61fd1c6054606e00234f760a.png
エラー出たらこの辺
コマンド一覧
変更したファイルをステージングにあげるとき
git add Rails/ docker-files/ tst/
変更ファイル全部なら、git add --all
ステージングに上げたファイルの確認 : git status
git commit -m "1行コミットメッセージ " or git commit "メッセージ"
git pushでOK
なるべくしっかり明示した方がいいgit push origin ブランチ名とかね
プルリクOKの後
git checkout main
git fetch origin
git merge origin/20220204_create_comments
code:git
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
% git merge origin/20220204_create_comments (git)-main Updating cb17688..acc19df
Fast-forward
Rails/app/controllers/comments_controller.rb | 24 ++++++++++++++++++++++++
Rails/app/views/boards/edit.html.erb | 1 +
Rails/app/views/comments/_comment.html.erb | 1 +
Rails/app/views/comments/edit.html.erb | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
Rails/config/routes.rb | 2 +-
5 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 Rails/app/views/comments/edit.html.erb
まあgit pullでもいいけど
Udemyの内容まとめ
必要そうなのだけピック
始めるとき
git init
initializeのこと
リポジトリ、インデックスファイル、設定ファイルが含まれる
gitのデータ保存方式
snapshot方式で保存している
snapshotで保存しているので、以前の情報に戻すことができる
gitのエリアと保存される仕組み
ワークツリー
ファイルを変更する作業場
ステージ
コミットする変更を準備する場所 git addのところ
変更をリポジトリにあげたい部分だけステージに上げるため、ここが実装されている
ステージには、ワークツリーの情報を圧縮したファイル(blobオブジェクト)が挙げられる
圧縮ファイルの名前はハッシュIDが保管される
またこの時、リポジトリにも圧縮ファイルの内容は入っている
リポジトリ
スナップショットを記録するための場所 git commit
圧縮ファイルの内容
ステージの情報（ツリーと呼ぶ）
それに付随する情報（コミット）が保管されている
コミットは、親コミットを持つことで変更履歴を辿れる
コミットについて
git commit
-v
変更、新規作成、削除、複数ファイルの変更などを参照できる
コミットやステージ追加の前にすること
どのファイルが変更されたか、当然確認する
git status
ワークツリー→ステージのもの、ステージ→リポジトリのものを比較してくれる
code:git
git status
On branch master
Your branch is up to date with 'origin/master'.
// コミットの方
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
// ステージの方
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.html
差分を見る
git diff
--staged
git addした後の変更を確認することができる
昔の変更をみる
git log
--oneline
１行で出す みやすいかも
-p ファイル名
そのファイル名の変更だけみれる
-n コミット数
表示する数を指定する
ファイルの削除を記録する
git rm ファイル名 / git rm -r ディレクトリ名
ファイルが要らなくなったときはこっち
git rm --cached ファイル名
ワークツリーには残したいけど、gitの記録だけ消したいときはこのコマンド
PWが書かれたファイルとか。
addではダメ
ファイルの移動を記録する
git mv 旧 新
mv
git rm 旧
git add 新
の作業を一括でできる
GittHubに新規追加する
git remote add origin https://github_no_url
originというショートカットで、URLのリモートリポジトリを登録する
URLがoriginというなまえで呼べるようになる
git push origin masterでpushする
-u
初回pushするとき、今後git pushで、origin masterが呼ばれるようになる
エイリアスをつける
code:git
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout
これでciと打てば、commitが呼ばれるようになる
--global
ローカル全体の環境設定をしている
なので特定のディレクトリで付けたエイリアスが、他のリポジトリでも機能する
良く使うの色々自分で設定しようかな
gitignoreファイルの書き方
/*/*.cssという表記
いずれかのディレクトリの中に入った先の、.cssファイル全てを除外する
dir/
ディレクトリそのものを除外
セクション4 変更を戻す
ファイルへの変更を取り消す
git checkout -- ファイル名 / git checkout -- ディレクトリ
git checkout -- .
全変更の取り消し
変更してたコードが不要になったよ、って時に使う
裏の動きとしては
ステージに元ファイルの情報が残っているので持ってくる
ワークツリーに反映させる
ステージに追加した情報を取り消す
git addした情報を戻したいときに使う。
git reset HEAD ファイル名 / git reset HEAD ディレクトリ名
git reset HEAD .で、全変更を取り消す。
裏の動きとしては
リポジトリに元ファイルの情報が入っているので持ってくる
ステージに反映させている
直前のコミットをやり直す
git commit --amend
こんなときに便利
コミットするときに特定のファイルを入れ忘れたとか
コミットメッセージを書き直したいときとか
リモートにプッシュしたコミットには適用しちゃダメ
別の誰かが取り込んでいた場合に不整合が生じることがある
裏の動きとしては
今のステージの内容をもとに、リポジトリに改めて反映させるという動き
セクション5 リモートとの連携
リモートの情報を表示する
git remote
-v
URLも出してくれる
code:git
git remote -v
origin git@github.com:skonishi1125/LearnGit.git (fetch)
origin git@github.com:skonishi1125/LearnGit.git (push)
// fetchする場合とpushする場合でリポジトリを使い分けることもできる
リモートを複数登録する
どんなときに使う
仕事用に１つと、自分の実験用にもう１つとかやりたいときに使うことがある。
git remote add 名 URL
code:git
git remote add sub git@github.com:skonishi1125/LearnGit_Sub.git
git remote -v
origin git@github.com:skonishi1125/LearnGit.git (fetch)
origin git@github.com:skonishi1125/LearnGit.git (push)
sub git@github.com:skonishi1125/LearnGit_Sub.git (fetch)
sub git@github.com:skonishi1125/LearnGit_Sub.git (push)
subという形で登録できた
リモートから情報を取得する(fetch)
git fetch リモート名
リモートリポジトリから、ローカルのリポジトリにだけ情報を反映させる。
ワークツリーには未反映。
反映させるときに使うのが、git merge
リモートから情報を取得する(pull)
リモートからマージまでを一括で行う
git pull origin master
git pullは上と同じ意味
フェッチとプルの使い分け
基本はフェッチがおすすめ
プルは挙動が結構特殊
例えばmasterにいるときに
git pull origin hogeをすると
masterに、hogeの情報がマージされてしまう
リモートの情報をもっと確認する
git remote show リモート名とか。
code:git
git remote show origin
* remote origin
Fetch URL: git@github.com:skonishi1125/LearnGit.git
Push URL: git@github.com:skonishi1125/LearnGit.git
HEAD branch: master
Remote branches:
007_task tracked
master tracked
stg_test_branch tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
リモートの変更と削除
変更
git remote rename 旧 新
削除
git remote rm 名前
セクション6 ブランチ
ブランチとは
コミットIDを記録したポインタ（シンボリックリンクみたいなもの）
HEAD
作業中ブランチへの示すポインタのこと
コミット←ブランチ←HEADという流れになってる
ブランチの基礎コマンド
git branch
ローカルのブランチを表示
-a
リモートの情報も含めて全て表示
git branch 名前
作成(移動はしない)
移動するときはgit checkout 名前
ファイルの変更を消すときのコマンドと一緒の名前。
あっちはちなみに、git checkout -- ファイル名
-bで作って移動もできる
変更をマージする
他の人の変更内容を自分のブランチに取り込む
git merge (リモート名/)ブランチ名
マージは3種類ある
Fast Foward
ブランチが枝分かれしていなかったときは、ブランチのポインタを前に進める
Auto Merge
枝分かれ開発の場合、新しいコミットを作ってそこをmasterが挿す
https://scrapbox.io/files/62580ff26c49dd001f85544f.png
コンフリクト
おなじみのやつ
コンフリクトを解決する
複数の人が同じ場所を編集したとき
コンフリクトしたHEADの内容、merge先ブランチの内容がファイルに記される
起きないようにするには
pull,mergeの前に変更中の情報をなくしておく（commit、スタッシュする）
pullするときはその名前のブランチに移動してからpullする
ブランチ名の変更と削除
git branch -m ブランチ名
作業中のブランチで実行する。
-m : move。自分の作業中のブランチをこっちの名前に移すよというイメージ
git branch -d 名前
-D にすると
masterにマージされていない変更が残っている場合は削除しない
かなり安全なコマンドと言われている
リベース
リベースとは
変更を統合する際に、履歴をきれいに整えるために使う
git rebase ブランチ名
ブランチ基点のコミットを別のコミットに変更する
要するにブランチで作業しているのが時間かかってて、masterが更新されたのに昔の状態のまま
それを最新のmaster状態にして作業を進めることができるようになる
https://scrapbox.io/files/625c17e0d8780e001d5c9923.png
git merge masterよりも、履歴がきれいに整えられている
ベースを新しいmasterに切り替えるから、リベースre baseだ
マージとの違い
マージは枝分かれして一箇所に集まるみたいな履歴になる
一直線で綺麗なのはリベース
マージとリベースどっちを使えばいい？
考え方次第
マージ
コンフリクトの解決が簡単
マージコミットがたくさんあると、履歴が複雑化する
リベース
履歴を綺麗
コンフリクトの解決が少し面倒
コミットそれぞれに解消が必要になる
プッシュしていないローカルの変更にはリベースを使う
プッシュした後はマージを使うようにする
コンフリクトしそうなら、マージする
など。
プルの型
マージ型
マージコミットが残るので、マージした記録が残る
fetch -> margeの流れ。
リベース型
git pull --rebase リモート名 ブランチ名
fetch -> rebaseの流れになる。
プルをリベース型に設定する
git config --global pull.rebase true
masterでpullするときだけなら、
git config branch.master.rebase true
複数のコミットをやり直す
git rebase -i コミットID
n個のコミットを戻す
git rebase -i HEAD~3
対話で話が進む
やり直したいコミットをpickからeditにする
editのコミットが
データ的にやり直したいなら、ここで修正して改めてステージングにあげる
git commit --amend でその後コミットメッセージを再度編集する
次のコミットへ進む（リベース完了) git rebase --continue
editがまだあれば再度この作業をする。もうなかったら終わり
他にもコミットの順番を変えたり、削除したりもできる。
気になれば調べてみると吉