- 投稿日:2020-06-24T23:53:51+09:00
初心者なりに勉強のためgitをまとめてみた
はじめに
この記事は基本的にこの公式ページで公開されている本をベースに筆者が解釈して書いています。もっと詳しく知りたい方はそちらを参照してください。
gitの概念
・gitのデータの考え方
他のバージョン管理ツール -> ファイル毎に差分を記録していく
git -> 全てのファイルの状態をまとめてスナップショット的に記録する
参照元・3つのステージ
<各ステージについて>
- working directory = 普段作業する場所
- staging area(index) = 次にコミットされるファイルが保存されてるgitディレクトリ
- .git directory(repository) = プロジェクトのメタデータがある場所(gitの最重要部)<作業の流れ>
1. 作業ディレクトリでファイルを編集
2. 編集したファイルのスナップショットをステージングエリアに追加$ git add filename3.コミットする(ステージングエリアにあるファイルを永久保持するスナップショットとしてgitディレクトリに保存する)
$ git commit -m "message"gitリポジトリ作成
主に2つ方法があります。
1. 既存のディレクトリでgitを初期化して作成$ cd /好きな/ディレクトリ $ git init
- githubでリポジトリを作成してcloneする githubアカウントを持ってない人は作ってください。 github上で新しいリポジトリを作成する。 clone or downloadをクリックしてそこにあるURLをコピー
$ git clone copied_URLgit基本操作
基本サイクル
基本的にいつもやることは、
(0). gitの状態確認
(1). ファイル編集
(2). ステージングエリアに保存(git add)
(3). コミットする(git commit)(1)->(2)->(3)->(1)...の繰り返しかと思います。
その後、
(4)どれかのブランチにpush
という流れ(だと理解している)。(0). gitの状態を確認します。
$ git statusすると,
- 自分が今どこのbranchにいるのか?
- Changes to be committed (次にコミットされる変更)
- Changes not staged for commit(まだステージングエリアにない変更)
などが分かります。
慣れていないうちは定期的にこのコマンドを使ってgitの状態を確認するといいと思います!(1). ファイル編集
エディターで何か編集する。
(2). 編集したファイルをステージングエリアに!
$ git add filename(3). ステージングエリアにある変更をコミットする
git commit -m "message"addとcommitを一緒に行うコマンドもあります。
$ git commit -a -m 'some messages'作業のやり直し!
誰でも間違うことはあります。
- 追加すべきファイルを追加せずコミットしてしまった or コミットメッセージを間違えた
以下のようにすると、最終的なコミットは一つになる。
$ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend
- ステージしたファイルを取り消したい
$ git reset HEAD unstaged_file
- ファイル変更の取り消し これは個人的に一番使いそう。 色々変えてみたけど、全然うまくいかなかったので最初の状態に戻したい時です。
$ git checkout -- filenameこれで直近のコミット状態に戻れます。
複数人でのリモート作業
gitは複数人で開発するのが普通ですよね。
リモートで作業する時の基本を簡単にまとめてみました。
イメージは以下のようになっています。
- どのリモートサーバーを設定したか確認
$ git remote -v
- fetchとmergeとpullの違い
fetch: リモートにある情報をローカルリポジトリに持ってくるだけ(作業ディレクトリのファイルは変わらない)
merge: ローカルリポジトリの情報を作業ディレクトリのファイルに反映
pull: fetch+mergeの作業を同時に行う$ git fetch remote_name #originなど $ git pull origin branch_name
- リモートへpush
git push remote_name branch_name
でできる。
注意:
このpushは自分のローカル状態を最新にしてから、他に誰もリモートにpushしていない時しかできません。他の人がpushしていた場合には、一度pullしてローカル環境で調整してからでないとpushできない!branchとは?
樹形図みたい感じでぼんやりと概念ではわかっていたつもりなのですが、自分は全く分かっていませんでした。
branch=ポインタです!!!
これを理解したらかなりスッキリしました。笑
まずブランチを理解するためには、gitがどうやってスナップショットを記録しているかを知る必要があります。
例えば、3つのファイルをaddしてcommitしたとする以下のような5つのオブジェクトがgitリポジトリに生成されます。コミットオブジェクトに編集者情報やツリーオブジェクト(真ん中の青いファイル)へのポインタ、そしてそのツリーオブジェクトにメタデータ(黄色の3つ)へのポインタが保存されています。
参照元コミットを複数回行うと、新しいコミットに一つ前のコミットへのポインタが格納されます。
ここでブランチとは複数あるコミットの中でいずれかを指すポインタになります!
それでは、最初masterしかない状態から新しいブランチを作成すると何が起こっているのかを図で見てみましょう。以下の作業を行います。
1. masterにコミット
2. testブランチを作成して移動
3. testブランチにコミット
4. 再びmasterに戻ってコミット最後に分岐したことが分かります。
また、ブランチがただポインタとして動いていることも理解できると思います。
HEADとは、自分が今どのブランチで作業しているかを示すポインタになります。つまり、gitはHEADというポインタを使ってどのブランチにコミットするか判断していることになりますね。
ここで注意です!!
gitでブランチを切り替えると、もちろん作業ディレクトリのファイルが変更されます。そのため、ブランチを切り替える前にファイルを変更したままにすると切り替えると怒られます。なので、ブランチを切り替える時は、ちゃんと変更を今いるブランチにコミットしてから切り替えましょう!ブランチの使い方(よくある例)
これも解説しようかと思いましたが、参考の本の該当箇所を読んでいただくのが一番分かりやすいと思ったのでリンクだけ残しておきますね。
・ ブランチとマージの基本<-これは必ず読むべき
・リモートブランチのことをより深く理解できる<-ブランチの概念が分かっていればすんなり
・ 共同開発の流れ<-さらっと読むだけ
git command集
基本操作
- 最新状態にアップデート(pull=fetch+merge)]
$ git pull origin master
- fetch: リモートの最新状態をローカルに持ってくる(ローカルのファイルには反映しない)
$ git fetch origin remote_branch_name
- merge: ローカルにあるリモートの最新状態(origin/master)をリモートのファイルに反映
$ git merge origin/master
- ファイル追加
$ git add filename
- コミットする
$ git commit -m “comment”
- ローカル->リモートのmasterにpush
$ git checkout master $ git push origin master
- ローカルのあるブランチ->リモートのあるブランチにpush
$ git push origin <local branch name>:<remote branch name> or $ git push origin HEAD:<remote branch name>
- (ローカル)別ブランチのファイルを持ってくる
$ git chekout <brach name> <file name>
- (ローカル)別ブランチのディレクトリを持ってくる
$ git chekout <brach name> <directory name>状態確認全般
- git状態の確認
$ git status
- 変更したけどまだステージしてない内容を確認
$ git diff
- ステージされた内容を確認
$ git diff --staged
- コミット履歴の確認
git logオプションで
-p
をつけると、反映された変更点を表示できる。これ便利。branch操作
- branch情報を見る
$ git branch -a
- branch 作成(新しくローカルで作る場合)
$ git branch new_branch_name
- branch 作成(リモートのブランチをローカルに持ってくる)
- 新しいブランチをまずローカルに作成
$ git branch local_new_branch_name origin/branch_name
- 新しいブランチに移動してpullする
$ git checkout local_new_branch_name $ git pull origin branch_name
- branchの紐付けを確認する
$ git branch -vv
- ローカルのbranchを削除
$ git branch -D <branch name>訂正・削除
- ローカルのファイル削除(正確には、ステージングエリアから削除し、コミットする+作業ディレクトリからも削除する)
$ git rm filename
- gitの中でファイル名変更
$ git mv file_from file_to
- リモートの状態に強制的に戻したい時
$ git fetch origin $ git reset --hard origin/master
- リモートのブランチを削除(リモートにあるポインタを削除するだけ)
git push origin --delete branch_name
- リモートで削除されたブランチをローカルに反映させる
$ git remote prune origin
- 投稿日:2020-06-24T23:08:07+09:00
Git コマンドなど色々
忘れた時の自分用
※常時編集します。
新規リポジトリ作成からGithubへのpushまで
$ git init #リポジトリを新規に作成(既に存在するリポジトリをサイド初期化) $ git add -A #オプションをつけることでまとめて登録できる $ git commit -m "Initial commit" #最低一回はコッミトしないとpushできない $ git remote add origin <github.url> #リポジトリの紐付け $ git push -u origin master #リモートリポジトリにpush補足
$ git add
$ git addは、指定したファイルをインデックスに登録してコミット対象にするコマンド。$ git add <file> $ git add text.txt
$ git add -u
と$ git add -A
と$ git add .
オプションを付けることで、まとめて登録することができる。git add -u (git add --update)
バージョン管理されていて、変更があったすべてのファイルがaddされる
変更されたファイル、削除されたファイルがaddされる
バージョン管理されていないファイルはaddされない
新しく作られたファイルはaddされないgit add -A (git add --all)
変更があったすべてのファイルがaddされる
変更されたファイル、削除されたファイル、新しく作られたファイル、すべてがaddされるgit add .
カレントディレクトリ以下の、変更があったすべてのファイルがaddされる
カレントディレクトリ以下の、変更されたファイル、削除されたファイル、新しく作られたファイル、すべてがaddされる-u は --set-upstreamの省略
このオプションをつけるとローカルリポジトリの現在のブランチの上流をorigin master に規定したことにる。
このオプションをつけると、次からは git push だけで上記のコマンドと同じことを実施できる。さらに、git pull だけでも git pull origin master と同じ意味になる。originとは
リモートリポジトリのアクセス先に対してGitがデフォルトでつける名前のこと。ざっくりコマンド一覧
ローカルのリポジトリの内容をリモートのリポジトリに送り込む
$ git pushリモートのリポジトリの内容をローカルのリポジトリに取り込む
$ git fetchリモートのリポジトリの内容をローカルのリポジトリに取り込み、次に、現在のローカルのブランチに対して、それに対応するリモートのブランチをマージする
$ git pullローカルの変更を確認する
$ git statusリモートとローカルのファイルの差分を抽出する
$ git diff <ファイル名>commitの変更履歴をみる
$ git logリモートにプッシュ
$ git push origin <ブランチ名>addの取り消し
$ git reset HEAD <ファイル名>commitの取り消し
$ git reset --hard HEAD^commitの打ち消し
$ git revert <コミットのハッシュ値>ローカルでブランチを作成
$ git branch <ブランチ名>ローカルでブランチを切り替え
$ git checkout <ブランチ名>ローカルのブランチをリモートに反映
$ git push -u origin <ローカルのブランチ名>ブランチをマージする
$ git merge <ブランチ名>ブランチとリポジトリの相関図
リモート追跡ブランチ (remote-tracking branch)」と「上流ブランチ (upstream branch)」
リモート追跡ブランチは「ローカルリポジトリにあって、他のリポジトリの状態を追跡するブランチ」のこと
上流ブランチは「引数なしで git pull したとき対象になるブランチ」のこと上の図でいうと、origin/masterはローカルブランチmasterの上流ブランチ
マージコンクリフトの解決方法
マージコンクリフトには2種類の場合がある。
1、同じファイルの同じ行の競合
2、削除したファイルと編集されたファイルの競合同じファイルの同じ行の競合
例えば、config/routes.rbを編集してマージした際、$git merge <ブランチ名> Auto-merging config/routes.rb CONFLICT (content): Merge conflict in config/routes.rb Automatic merge failed; fix conflicts and then commit the result.表示されている通り、自動マージが失敗したので、競合を修正してから手動でコミットしてください。と言われる。
以下のコマンドでどのファイルを編集すればいいか確認。$git stutas On branch develop Your branch is up to date with 'origin/develop'. You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Changes to be committed: new file: app/assets/javascripts/reviews.coffee ~ 省略 ~ #これらのファイルはコンフリクト起こさずに自動マージできたファイル new file: spec/views/reviews/show.html.slim_spec.rb Unmerged paths: (use "git add <file>..." to mark resolution) both modified: config/routes.rb #このファイルを修正する対象ファイルを開くと、コンクリフトを起こしている部分は以下のように表示される
<<<<<<< HEAD root to: 'static_pages#top' | root to: 'static_pages#home' | #作業ブランチでの変更内容 resources :static_pages | | # get 'static_pages/top' | # get 'static_pages/home' | ======= root to: 'reviews#index' | #マージしたブランチでの変更内容 resources :reviews | >>>>>>> feature/branch end今回は作業ブランチでの変更内容は全部消して問題なかったので削除
編集したファイルをステージングする(これをしないとGitがコンクリフトを解消したことに気づけない)$git add config/routes.rb
$git status
でUnmerged paths:
の警告が消えているのを確認
ファイルはChanges to be committed:
の一覧に追加されている
そして、コッミトしてプッシュすれば完了!$git commit -m "コンフリクト解消" $git push origin developGit GraphというVScodeの拡張機能
Gitのコミットグラフをみれる拡張機能。慣れないうちはコミットグラフが常に可視化されているのは心強い。(はちゃめちゃなコッミトの仕方の防止に繋がる)
- 投稿日:2020-06-24T22:48:12+09:00
Git(GitHub)のmasterブランチをmainブランチに改名する
こんな人におすすめ
- BLM運動を受けて
master
という言葉を絶対にやめたいと思った(昔から思っていた)人master
って言葉がよくわからないので言い換えたい人master
以外のブランチを改名したい人など
使うリポジトリ
初回コミットしかしていないほぼ真っさらな状態、ですがたくさんのコミットログがあっても適用可能なはずです。注意
GitHubではデフォルトブランチの削除が許可されていないため、
master
ブランチを改名するときは手順3でデフォルトブランチを確実に変更してください。手順1 ローカルブランチを改名
ブランチを改名する# git branch -m (変更前のブランチ名) 変更後のブランチ名 git branch -m master main
-m
は--move
、ブランチを移動する、すなわち改名するためのオプションです。
なお、現在チェックアウトしているブランチの名前を変える時は変更前のブランチ名
は省略可能です。手順2 改名後のブランチをpush
ブランチをpushする# git push -u origin 変更後のブランチ名 git push -u origin main
GitHubにmain
ブランチをpushする操作です。新しくmain
ブランチを作成したので、-u
(--set-upstream
)オプションで上流ブランチを設定します。このオプションを忘れたまま改名後にブランチを明示しないgit push
を実行するとエラーが発生します。手順3 GitHubで既定のブランチを変更する
※
master
ブランチ以外を変更するときにはこの操作は必要ありません。
リポジトリのSettings
→左メニューBranches
→Default branch
のところで、master
となっているところをmain
に変更して、Update
を押します。
モーダルにも書かれる通り、Pull RequestやCloneに悪影響が出る可能性があります。
default
がmain
に移りました。手順4 masterブランチの削除
GitHubのブランチ一覧を表示、ゴミ箱のマークを押して削除、もしくはコマンドラインでリモートのmasterブランチを削除する# git push origin :変更前のブランチ名 git push origin :master
を実行しても削除可能です。
master
ブランチが消えました。
コミットが1回しかされていないため分かりにくいですが、コミットログが正常に引き継がれています。参考記事
- 投稿日:2020-06-24T17:22:18+09:00
Git alias 便利なコマンド
LINUXの勉強していた時に 「alias」 という存在を知ったが今まで全く恩恵に預かってなかった。ここに来てようやくGitにもaliasとやらを使えるということを知ったので、やり方・登録したaliasを記録
そもそもaliasってなんやねん
色々と長いコマンドをフルネームで呼ぶのがめんどいから代わりにあだ名的なのを勝手につけて、短い名前で呼んでしまえ!!!的な機能のこと。
例えば、「パブロ=ディエーゴ=ホセー=フランシスコ・デ・パウラ=ホアン・ネポムセーノ=マリーア・デ・ロス・レメディオス=クリスピーン=クリスピアーノ=デ・ラ・サンティシマ・トリニダード=ルイス・イ・ピカソ」っていちいち毎回長い名前で呼ぶのはめんどいよね???
(マルクス=アウレリウス=アントニヌスより長いだ、、、と、、、?!)そこでaliasという機能を使って、「パブロ・ピカソ」と単純な名前で呼び出そう!という感じ。
alias
であだ名をつけてやろう私自身まだgitに使い慣れていませんが、以下のコマンドはよく使います。
git checkout
git branch
git commit
git status
こやつらをaliasを使ってあだ名をつけてやるにはこんな感じにコマンドを実行
checkout
をco
と名付ける$ git config --global alias.co checkout
branch
をbr
と名付ける$ git config --global alias.br branch
commit
をci
と名付ける$ git config --global alias.ci commit
status
をst
と名付ける$ git config --global alias.st statusちなみに、名前は自分が分かりやすいようにしたらオッケー。
なんなら「う○こ」みたいでもいいと思う(ごめんなさい)
そうすることで上から順に$ git co$ git br$ git ci$ git stと実行してやることができます〜。
ピカソの本名並に長いコマンドに使ってあげる
$ git log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white)— %an%C(reset)%C(bold green)%d%C(reset)' --abbrev-commit --date=relative --allこんな感じの馬鹿みたいに長いコマンドに対して使うのが効果的なんやねー。
ちなみに上のコマンドはgitの履歴グラフがカラーで表示されるんだよ♬補足
vimで設定ファイルを開いてやって、設定を直接入力することもできるよ。
(vimはマウスを一切使わないエディターのことでっせ。使い慣れたら多分モテる気がするけど、きっと幻想)$ vim ~/.gitconfiggitconfig.[alias] co = checkout br = branch ci = commit st = status log-color = log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white)— %an%C(reset)%C(bold green)%d%C(reset)' --abbrev-commit --date=relative --allまとめ
ショートカットがこの世を幸せにしてくる気がする。
- 投稿日:2020-06-24T12:58:19+09:00
git global コマンド削除方法
alias.st=status alias.cob=checkout -b alias.co=checkout alias.ss=status alias.br=branch alias.com=commit -m編集、更新 $ git config キー名 設定値 #ローカルリポジトリに設定 $ git config --global キー名 設定値 #全てのローカルリポジトリに設定 削除 $ git config --unset キー名$ git config --global --unset alias.st $ git config --global --unset alias.cob $ git config --global --unset alias.co $ git config --global --unset alias.ss $ git config --global --unset alias.br $ git config --global --unset alias.com