20200624のGitに関する記事は5件です。

初心者なりに勉強のためgitをまとめてみた

はじめに

この記事は基本的にこの公式ページで公開されている本をベースに筆者が解釈して書いています。もっと詳しく知りたい方はそちらを参照してください。

gitの概念

・gitのデータの考え方

他のバージョン管理ツール -> ファイル毎に差分を記録していく
git -> 全てのファイルの状態をまとめてスナップショット的に記録する
Screen Shot 2020-06-22 at 22.21.52.png
参照元

・3つのステージ

<各ステージについて>
- working directory = 普段作業する場所
- staging area(index) = 次にコミットされるファイルが保存されてるgitディレクトリ
- .git directory(repository) = プロジェクトのメタデータがある場所(gitの最重要部)

Screen Shot 2020-06-22 at 22.27.15.png

<作業の流れ>
1. 作業ディレクトリでファイルを編集
2. 編集したファイルのスナップショットをステージングエリアに追加

$ git add filename

3.コミットする(ステージングエリアにあるファイルを永久保持するスナップショットとしてgitディレクトリに保存する)

$ git commit -m "message"

gitリポジトリ作成

主に2つ方法があります。
1. 既存のディレクトリでgitを初期化して作成

$ cd /好きな/ディレクトリ
$ git init
  1. githubでリポジトリを作成してcloneする githubアカウントを持ってない人は作ってください。 github上で新しいリポジトリを作成する。 clone or downloadをクリックしてそこにあるURLをコピー
$ git clone copied_URL

git基本操作

基本サイクル

基本的にいつもやることは、

(0). gitの状態確認
(1). ファイル編集
(2). ステージングエリアに保存(git add)
(3). コミットする(git commit)

(1)->(2)->(3)->(1)...の繰り返しかと思います。
その後、
(4)どれかのブランチにpush
という流れ(だと理解している)。

Screen Shot 2020-06-22 at 23.22.56.png

(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は複数人で開発するのが普通ですよね。
リモートで作業する時の基本を簡単にまとめてみました。
イメージは以下のようになっています。

Screen Shot 2020-06-23 at 21.12.12.png

  • どのリモートサーバーを設定したか確認
$ 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つ)へのポインタが保存されています。
Screen Shot 2020-06-23 at 22.25.58.png
参照元

コミットを複数回行うと、新しいコミットに一つ前のコミットへのポインタが格納されます。
Screen Shot 2020-06-23 at 22.34.29.png

ここでブランチとは複数あるコミットの中でいずれかを指すポインタになります!
それでは、最初masterしかない状態から新しいブランチを作成すると何が起こっているのかを図で見てみましょう。以下の作業を行います。
1. masterにコミット
2. testブランチを作成して移動
3. testブランチにコミット
4. 再びmasterに戻ってコミット

Screen Shot 2020-06-23 at 23.05.34.png

最後に分岐したことが分かります。
また、ブランチがただポインタとして動いていることも理解できると思います。
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 作成(リモートのブランチをローカルに持ってくる)
  1. 新しいブランチをまずローカルに作成
$ git branch local_new_branch_name origin/branch_name
  1. 新しいブランチに移動して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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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 <ブランチ名>

ブランチとリポジトリの相関図

image.png
リモート追跡ブランチ (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 statusUnmerged paths:の警告が消えているのを確認
ファイルはChanges to be committed:の一覧に追加されている
そして、コッミトしてプッシュすれば完了!

$git commit -m "コンフリクト解消"

$git push origin develop

Git GraphというVScodeの拡張機能

Gitのコミットグラフをみれる拡張機能。慣れないうちはコミットグラフが常に可視化されているのは心強い。(はちゃめちゃなコッミトの仕方の防止に繋がる)
image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git(GitHub)のmasterブランチをmainブランチに改名する

こんな人におすすめ

  • BLM運動を受けてmasterという言葉を絶対にやめたいと思った(昔から思っていた)人
  • masterって言葉がよくわからないので言い換えたい人
  • master以外のブランチを改名したい人

など

使うリポジトリ

image.png
初回コミットしかしていないほぼ真っさらな状態、ですがたくさんのコミットログがあっても適用可能なはずです。

注意

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

image.png
GitHubにmainブランチをpushする操作です。新しくmainブランチを作成したので、-u(--set-upstream)オプションで上流ブランチを設定します。このオプションを忘れたまま改名後にブランチを明示しないgit pushを実行するとエラーが発生します。

手順3 GitHubで既定のブランチを変更する

masterブランチ以外を変更するときにはこの操作は必要ありません。
リポジトリのSettings→左メニューBranchesDefault branchのところで、masterとなっているところをmainに変更して、Updateを押します。
モーダルにも書かれる通り、Pull RequestやCloneに悪影響が出る可能性があります。
image.png
defaultmainに移りました。

手順4 masterブランチの削除

image.png
GitHubのブランチ一覧を表示、ゴミ箱のマークを押して削除、もしくはコマンドラインで

リモートのmasterブランチを削除する
# git push origin :変更前のブランチ名
git push origin :master

を実行しても削除可能です。
image.png
masterブランチが消えました。
image.png
コミットが1回しかされていないため分かりにくいですが、コミットログが正常に引き継がれています。

参考記事

Git - Reference
Github、人種差別を連想させるコーディング用語の見直しへ | ギズモード・ジャパン

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Git alias 便利なコマンド

LINUXの勉強していた時に 「alias」 という存在を知ったが今まで全く恩恵に預かってなかった。ここに来てようやくGitにもaliasとやらを使えるということを知ったので、やり方・登録したaliasを記録

そもそもaliasってなんやねん

色々と長いコマンドをフルネームで呼ぶのがめんどいから代わりにあだ名的なのを勝手につけて、短い名前で呼んでしまえ!!!的な機能のこと。

例えば、「パブロ=ディエーゴ=ホセー=フランシスコ・デ・パウラ=ホアン・ネポムセーノ=マリーア・デ・ロス・レメディオス=クリスピーン=クリスピアーノ=デ・ラ・サンティシマ・トリニダード=ルイス・イ・ピカソ」っていちいち毎回長い名前で呼ぶのはめんどいよね???
(マルクス=アウレリウス=アントニヌスより長いだ、、、と、、、?!)

そこでaliasという機能を使って、「パブロ・ピカソ」と単純な名前で呼び出そう!という感じ。

aliasであだ名をつけてやろう

私自身まだgitに使い慣れていませんが、以下のコマンドはよく使います。
git checkout
git branch
git commit
git status

こやつらをaliasを使ってあだ名をつけてやるにはこんな感じにコマンドを実行

checkoutcoと名付ける

$ git config --global alias.co checkout

branchbrと名付ける

$ git config --global alias.br branch

commitciと名付ける

$ git config --global alias.ci commit

statusstと名付ける

$ 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 ~/.gitconfig
gitconfig.
[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

まとめ

ショートカットがこの世を幸せにしてくる気がする。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む