- 投稿日:2020-10-25T22:21:38+09:00
gitコマンド備忘録 (自分用)
はじめに
Git Bash
にてgitコマンドの簡易的な操作方法を記す.gitの設定
- ユーザ名とメールアドレスの登録
名前・メールアドレスの設定$ git config --global user.name "名前" // 名前の登録 $ git config --global user.email [ メールアドレス ] // メールアドレスの登録
- 設定が反映されているか確認する
user.name
とuser.email
の値が上のコマンドで設定した値になっていることを確認する.設定の確認$ git config -l // 設定の確認gitコマンド例
clone
- リモートリポジトリの複製をローカルにもってきたい時
クローン$ git clone [ 複製したいリポジトリのURL ]
add, commit, push
- ワーキングツリーの変更をリモートにアップしたい時
基本的に以下のように手順を踏む.
- ワーキングツリーの変更をステージング
- ローカルリポジトリに変更を登録
- リモートリポジトリにアップロード
ステージング(用途に合わせて以下の3つから1つ)$ git add [ ファイル名 ] // 特定のファイルをステージング $ git add . // すべてのファイルをステージング(非推奨) $ tig status // 十字キーでファイルを指定して u キーでステージング, q キーで戻るコミット$ git commit -m "コミットメッセージ" // ステージングされたファイルを登録プッシュ$ git push origin [ ブランチ名 ]
origin
はリモートリポジトリを指す.
pull
- リモートリポジトリの変更内容をローカルに取り込みたい時
プル$ git pull origin [ ブランチ名 ]
- 投稿日:2020-10-25T18:38:00+09:00
GitlabにおけるRemote Branch名の変更
コマンドの場合
- ローカルの branch名変更します。
- git branch -m [hoge] [hoge2]
- リモートの対象branchを削除します。二通りあります。
- git push origin :[hoge]
- git push --delete origin [hoge]
- ローカルbranchをプッシュします。
- git push origin [hoge]
TortoiseGit、Gitlabの場合
Gitlabのみではできないので、あらかじめローカルのbranch名を変更する必要があります。
master Branch名の変更
リプレース、なおかつGitlabでのPrjectは既存のものを使用したため、masterの名前を変更しました…。他に良い方法が有ったかと思いますが、この方法しか思いつきませんでした。
- 投稿日:2020-10-25T17:50:00+09:00
Gitで主に使う用語のまとめ
Gitでは様々な用語が出てきます。結構頻繁にいろんな用語が出てきますのでその用語を簡単にまとめてみました。
用語の意味を理解してからいろいろな記事を見るとより理解が深まると思いますのでよかったら参考にしてください。
リポジトリ
変更履歴の保管場所、過去のソースコードやファイルのデータベースの様なもの
リモートリポジトリ
専用サーバやGitHub等のサービス上にある複数人で共有するためのリポジトリ
ローカルリポジトリ
自分の作業端末、ネットに繋がってなくても作業できる環境にあるリポジトリ
クローン(clone)
リモートリポジトリをローカルに複製することクローンすることでローカルリポジトリが作られる
ワークツリー
gitの管理下に置かれた実際に作業するディレクトリのこと
インデックス(index)
リポジトリにコミットするためにコミットする対象を登録するところ
アド(add)
インデックスに対象を追加すること
コミット(commit)
インデックスに登録された変更をリポジトリに反映させるこ、ゲームで例えるとセーブ
ブランチ(branch)
変更履歴の保存場所。新たなブランチを作る(ブランチを切る)と変更履歴の保存場所を分岐させることができる。
ブランチを切ることによって何か変更を加えたい時にmasterブランチ(基本的にはプロジェクト等の本体になる部分)に影響を与えずに変更履歴を保存できる。ツリー(樹形図)orブランチツリー
コミットの履歴やブランチの状態などを見やすくしたもの
↓こんな感じのやつです
マージ(merge)
各ブランチでの変更をまとめること、例えばブランチAをmasterにマージするとmasterにブランチAの変更が反映される
↓ツリーで見るとこんな感じになります
ヘッド(HADE)
現在自分が作業している所を示すポインタ
チェックアウト(checkout)
ブランチを切り替える際などにヘッドを切り替えること
オリジン(origin)
リモートリポジトリのことgitのコマンドを使う時にもよく出てきます
フェッチ(fetch)
ローカルリポジトリにリモートリポジトリの特定のブランチをコピーすること
プル(pull)
リモートリポジトリの状態をローカルリポジトリに反映すること
リモートのmasterブランチをフェッチしてきてローカルのmasterブランチにマージという一連の流れをやってくれるプッシュ(push)
ローカルリポジトリの変更をリモートリポジトリに反映すること
コンフリクト(競合)
マージやリモートリポジトリにプッシュする際に変更箇所等が重複した際に発生する現象のこと、gitが『同じ所が変更されているよ!どっちが正しいの?』と言っている状態のこと
とりあえずよく使われるのはこんな感じかと思います。
自分なりにまとめてみましたが他にもいろいろな用語があるのでまとめ次第追記していこうと思います。
- 投稿日:2020-10-25T17:50:00+09:00
Gitで使う用語のまとめ
Gitでは様々な用語が出てきます。結構頻繁にいろんな用語が出てきますのでその用語を簡単にまとめてみました。
用語の意味を理解してからいろいろな記事を見るとより理解が深まると思いますのでよかったら参考にしてください。
リポジトリ
変更履歴の保管場所、過去のソースコードやファイルのデータベースの様なもの
リモートリポジトリ
専用サーバやGitHub等のサービス上にある複数人で共有するためのリポジトリ
ローカルリポジトリ
自分の作業端末、ネットに繋がってなくても作業できる環境にあるリポジトリ
クローン(clone)
リモートリポジトリをローカルに複製することクローンすることでローカルリポジトリが作られる
ワークツリー
gitの管理下に置かれた実際に作業するディレクトリのこと
インデックス(index)
リポジトリにコミットするためにコミットする対象を登録するところ
アド(add)
インデックスに対象を追加すること
コミット(commit)
インデックスに登録された変更をリポジトリに反映させるこ、ゲームで例えるとセーブ
ブランチ(branch)
変更履歴の保存場所。新たなブランチを作る(ブランチを切る)と変更履歴の保存場所を分岐させることができる。
ブランチを切ることによって何か変更を加えたい時にmasterブランチ(基本的にはプロジェクト等の本体になる部分)に影響を与えずに変更履歴を保存できる。ツリー(樹形図)orブランチツリー
コミットの履歴やブランチの状態などを見やすくしたもの
↓こんな感じのやつです
マージ(merge)
各ブランチでの変更をまとめること、例えばブランチAをmasterにマージするとmasterにブランチAの変更が反映される
↓ツリーで見るとこんな感じになります
ヘッド(HADE)
現在自分が作業している所を示すポインタ
チェックアウト(checkout)
ブランチを切り替える際などにヘッドを切り替えること
オリジン(origin)
リモートリポジトリのことgitのコマンドを使う時にもよく出てきます
フェッチ(fetch)
ローカルリポジトリにリモートリポジトリの特定のブランチをコピーすること
プル(pull)
リモートリポジトリの状態をローカルリポジトリに反映すること
リモートのmasterブランチをフェッチしてきてローカルのmasterブランチにマージという一連の流れをやってくれるプッシュ(push)
ローカルリポジトリの変更をリモートリポジトリに反映すること
コンフリクト(競合)
マージやリモートリポジトリにプッシュする際に変更箇所等が重複した際に発生する現象のこと、gitが『同じ所が変更されているよ!どっちが正しいの?』と言っている状態のこと
とりあえずよく使われるのはこんな感じかと思います。
自分なりにまとめてみましたが他にもいろいろな用語があるのでまとめ次第追記していこうと思います。
- 投稿日:2020-10-25T15:41:57+09:00
stashしたものが行方不明になった時やったこと
事の起こり
編集途中のものを一旦
stash
した。それからrebase
したりブランチを削除したりして最後にstashしたものを戻そう(stash pop
)しようとら、stashしたものがない。stash list
に何も出てこない。
stash
した時のブランチを削除したから?対応
git fsck
で追跡不能なリビジョンを表示する。$ git fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (3778/3778), done. dangling commit d8c140de7dbe0f0695790e94631f9f4c041ede54 dangling tag bb4efddf60954be66b6cfd7235d14bf2635264c2 dangling tag 6bf9af0329e00ab9661781147ca34e7b39070975"dangling 何とか" というのが追跡不能なリビジョンらしい。
これらのリビジョンのアーカイブを作る$ git archive --format=zip d8c140d -o rev_d8c140d.zip
$ git archive --format=zip bb4efdd -o rev_bb4efdd.zip
$ git archive --format=zip 6bf9af0 -o rev_6bf9af0.zip
で、そのアーカイブを展開してワークツリーと比較して(WinMergeを使った)差分から d8c140d が行方不明になっていたstashしたものらしいと判断した。
もっといい方法があるのかもしれないが、自分の頭ではこれが限界。参考ページ
誤って削除した git stash を戻す | deadwood
Gitを使いこなすための20のコマンド | OSDN Magazine
Git - git-fsck Documentation
- 投稿日:2020-10-25T11:26:32+09:00
rebase完全に理解した
最近実務で初めてrebaseを使って「????」となったので調べました。
以下の動画、記事が分かりやすかったです。
- Git MERGE vs REBASE
- マージとリベース具体例
今回は動画から引用してこのような場合を考えてみます。
- m2まで作業が進んでいるmasterブランチからfeatureブランチへcheckout
- featureブランチでf1をコミット
- masterブランチにcheckoutしてm3をコミット
- 再度featureブランチにcheckoutしてf2をコミット
ここまでの各ブランチのlog
masterブランチのlog
m3 m2 m1featureブランチのlog
f2 f1 m2 m1merge vs rebase
ここからfeatureブランチにて、masterブランチを
merge
,rebase
するとそれぞれどうなるか見ていきます。
git merge master
のlogf2 m3 f1 m2 m1
git rebase master
のlogf2 f1 m3 m2 m1
merge
では時系列に沿ってそのまま差分を統合しているのに対し、rebase
ではfeatureブランチの先端がmasterで置き換えられています。
rebase
を用いるとコミット履歴がすっきりしますね。rebaseのアンチパターン
この記事から引用します。
リベースの特徴を理解できたら、次に最も重要なことは、実行してはいけないときを知ることです。git rebase の黄金律は、リベースを public ブランチでは決して使用しないことです。
masterブランチにて、自分の作業ブランチをrebaseしてしまうとmasterのコミット履歴が書き換えられてしまいます。
このように、他の人にも共有済みのブランチでrebase
は使わないように注意しましょう。
- 投稿日:2020-10-25T11:05:06+09:00
oursとtheirsオプションを使ってコンフリ解消を便利にできる
マージまで
他のブランチをマージしたいブランチにcheckoutし、それを最新にする。
git checkout 他のブランチをマージしたいブランチ git pullコンフリ解消
コンフリの発生。
git merge マージしたいブランチ # コンフリする CONFLICT (content): Merge conflict in コンフリが発生しているファイル名どちらのブランチを優先するか、またファイル単位ではどちらの内容を優先するかがわかっている場合にはいちいちエディタでコードを確認するよりも以下の方法を使った方がコンフリを速く解決できる。
ブランチ単位でどちらの内容を優先すれば良いかが明白な場合
他のブランチをマージしたいブランチの内容を優先する場合
git merge -Xoursマージしたいブランチの内容を優先する場合
git merge -Xtheirs以上でマージが完了する。
ファイル単位でどちらの内容を優先すれば良いかが明白な場合
他のブランチをマージしたいブランチのファイルの内容を優先する場合
git checkout --ours ファイル名 git add ファイル名マージしたいブランチのファイルの内容を優先する場合
git checkout --theirs ファイル名 git add ファイル名優先するブランチやファイルを間違えた場合
# マージを最初からやり直す git merge --abort # マージ自体を取り消す git reset --hard ORIG_HEAD
- 投稿日:2020-10-25T03:27:20+09:00
gitignoreとは一体はなんぞや
さーて今日から始めますよとQiita投稿
プログラミングの知識をより深めるためにもアウトプットていきますよと
駆け出しのエンジニアなのでお手柔らかに?♂️さて、そんな駆け出しエンジニアの初投稿の内容は!!!
gitignoreこれなんとなくコミットさせたくないから〜的なこと認識でいたんです
まあ一応そんな感じではあるのですが、ただどういうときに必要なのかいまいちピンときていなかったんですよね、、、しかし!!!今日ここで!!!
なんとなくの認識から抜け出し、gitignoreを使う時はどういう時なのかを、なんとなく!!!
わかるようにすることが目的です(なんとなくなんかい)
じゃあ本題やっていきますよと
.gitignoreって何?
まあ簡単いうとgitの管理下に置きたくないファイルの置き場所なんだとさ
- 必要ないデータをコミットすると、他の人は必要なデータだけを探しにくくなる
- 環境変数とかをコミットすると、セキュリティちょいゆるくない??
以上のことを防止するためにも.gitignoreを使っているんです
ちなみに必要のないデータっていうのは、Mac使っている人なら
.DS_Store
というのが代表格ですかね
どうも勝手に作成されてしまうみたいなんですよじゃあどうすんの
こいつをgitの管理下に置かない様にするためにやることは簡単
.gitignore.DS_Storeこれだけ。
.gitignoreに.DS_Storeを記載するだけ。
ただただこれだけ。簡単ですね♪
管理したくないデータを記載するだけでいいんですもちろん、
"この拡張子を全部排除したい!"とか
"このディレクトリの一個だけは排除したくない!"とか
そういう要望にもある書き方をすれば、叶えてくれるんですこの書き方については再度編集するかまた新しい記事を投稿してみようと思います!
まあ最初の投稿はこんなとこで失礼しますm(_ _)m思ったより投稿内容考えるの大変。。。
でもまたアップし続けますよと
継続力、大事☺️
指摘箇所があったら優しく(ここ重要)教えてくださいねそりでぃは✋
記事投稿始めた俺…
止まるんじゃねぇぞ…rm1
〉 ク
j ̄l ,ャvァ,
j::::::l ミt 戔
j:::::::ト、_ 幺wv、「
t:::::::::::::::::`::⌒ヾニニト、
 ̄`ヾ:::::::::::;;;;;;;:::::;|;;;;;;;;::`ー、
゙Y::::;;;;;;;;;;;;;;;|;;;;;;;;;;|::::::!
ヾ::;;;;;;;;;;;;;;;|;;;;;;;;;;:!:::::|
/;;;;;;;;;;;;;;;;|;;;;;;;;;;;l::::::l
/::::;;;;;;;;;;;;;;|;;;;;;;;;;;jl:::::゙i
/:::::;;;;;;;;;;;;;;;ハ;;;;;;;;;;tl:::::::l
〈::::;;;;;;;;;;;;;;;;/;|;;゙、;;;;;;;゙l:::::::l
ヾ、__/;;;|;;;;;ヾ_」::::::〉
|;;;;;;;;;;;;;;|;;;;;;;;;;;;;;| l/え、
|;;;;;;;;;;;;;ハ;;;;;;;;;;;;;゙〈t!杉!
|;;;;;;;;;;;j ヾ;;;;;;;;;;;;゙、 ぐ
|;;;;;;;;;;;! ヾ;;;;;;;;;l \>
|;;;;;;;;;;| ヾ;;;;;;;;!
|;;;;;;;;;;| 〉;;;;;;|
- 投稿日:2020-10-25T01:39:02+09:00
GitHubアカウントをマージする方法
概要
GitHubアカウントを複数運用していたりして、もしなんらかの理由で片方のアカウントを削除してマージしたいなんて場面になった時に向けた記事です。
マージは引き継ぐ形で行います
基本的な引き継ぎとContributionsの引き継ぎ方法について記載します。1,基本的な引き継ぎ
基本的な部分は全て手作業による引き継ぎになります。
公式ドキュメントが参考になります。公式ドキュメント(複数のユーザーアカウントをマージする)
https://docs.github.com/ja/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/merging-multiple-user-accountsリポジトリのオーナーの変更は
Setting >>Transfer ownership
によって行うことが可能です。GitHub pagesなども引き継ぎたい場合は都度対応します。
2,Contributions(草)の引き継ぎ
GitHubのContributionsは登録しているemailと紐づいています。
そのため、過去のコミット全てのユーザー名とemailを上書きすることが可能です。
ただし、この方法はコミットが追加される(新たなコミットハッシュが生成される)ので、基本的に非推奨です。
PRを作成しても新しい差分が発生してしまうのでなんらかの特別な事情(そのリポジトリへのコントリビューションに思い入れがあるなど)がない限り捨ててしまうのが良いと思います。コマンド
これでHEAD以下の全ての過去のコミット履歴を上書きできます。
filter-branchとforce pushを使用するのでリスクは高いです。
何が起きるかはっきりしない、不明確な部分がある場合はgitに詳しい人に相談してから行うか決めてください。// コミットを変更する $git filter-branch --commit-filter ' if [ "$GIT_AUTHOR_NAME" = "<変更前の名前>" ]; then GIT_AUTHOR_NAME="<変更後の名前>"; GIT_AUTHOR_EMAIL="<変更後のメールアドレス>"; GIT_COMMITTER_NAME="<変更後の名前>"; GIT_COMMITTER_EMAIL="<変更後のメールアドレス>"; git commit-tree "$@"; else git commit-tree "$@"; fi' HEAD // masterへ force pushする $git push origin master -ffilter-branchは過去のコミット全てを操作できてしまう強力なコマンドです。
- 投稿日:2020-10-25T01:04:04+09:00
git pushでremote: Repository not foundと言われる場合の対処法
概要
git push がある日できなくなってしまいました。
自分の場合、GitHubアカウントを会社用(エンジニアアカウントとマスターアカウント)と個人用など複数使用していたためGitHub側の認証情報が切り替わっていてこの現象が起きているようでした。
本来、GitHubは規約で1つのアカウント使用することになっています。
なので、会社用アカウントを使用せず、個人アカウントで作業することで大抵は解決できます。
GitHubの規約
https://docs.github.com/en/free-pro-team@latest/github/site-policy/github-terms-of-serviceしかし、会社用のマスターアカウントでデータ管理をしていて、複数使わざるを得ない時や人もいるかと思います。もしおきた場合、その場合の対処方を記載します。
対処法
httpsではなく、SSHで接続することで解決できます。
その際にすでに作成したリモートリポジトリの登録を削除するコマンドは// すでに作成したリモートリポジトリの登録を削除する git remote rm originです。
SSH接続の仕方は
GitHub>プロフィールアイコン>settings>SSH and GPG Keys
で公開鍵を登録します。小さな事ですが、ある日できなくなるとびっくりしますね。
参考になりますと幸いです。補足:
GitHubの運用に関してZOZOテクノロジーズさんの記事がとても参考になりました。
こんな感じだと理想的なのだなと思います。
https://techblog.zozo.com/entry/github_sso#%E4%BC%9A%E7%A4%BE%E7%94%A8GitHub%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%92%E4%BD%BF%E3%81%84%E7%B6%9A%E3%81%91%E3%82%8B%E5%A0%B4%E5%90%88