はじめに 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 [ ブランチ名 ]
Git Bash にてgitコマンドの簡易的な操作方法を記す．
Git Bash
$ git config --global user.name "名前" // 名前の登録 $ git config --global user.email [ メールアドレス ] // メールアドレスの登録
user.name と user.email の値が上のコマンドで設定した値になっていることを確認する．
user.name
user.email
$ git config -l // 設定の確認
$ git clone [ 複製したいリポジトリのURL ]
基本的に以下のように手順を踏む．
$ git add [ ファイル名 ] // 特定のファイルをステージング $ git add . // すべてのファイルをステージング（非推奨） $ tig status // 十字キーでファイルを指定して u キーでステージング, q キーで戻る
$ git commit -m "コミットメッセージ" // ステージングされたファイルを登録
$ git push origin [ ブランチ名 ]
originはリモートリポジトリを指す．
origin
$ git pull origin [ ブランチ名 ]
コマンドの場合 ローカルの 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名を変更する必要があります。 ローカルの branch名変更します。 リモートの対象branchをbranch一覧から削除します。 ローカルbranchをプッシュします。 master Branch名の変更 リプレース、なおかつGitlabでのPrjectは既存のものを使用したため、masterの名前を変更しました…。他に良い方法が有ったかと思いますが、この方法しか思いつきませんでした。
Gitlabのみではできないので、あらかじめローカルのbranch名を変更する必要があります。
ローカルの branch名変更します。
リモートの対象branchをbranch一覧から削除します。
ローカルbranchをプッシュします。
リプレース、なおかつGitlabでのPrjectは既存のものを使用したため、masterの名前を変更しました…。他に良い方法が有ったかと思いますが、この方法しか思いつきませんでした。
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が『同じ所が変更されているよ！どっちが正しいの？』と言っている状態のこと とりあえずよく使われるのはこんな感じかと思います。 自分なりにまとめてみましたが他にもいろいろな用語があるのでまとめ次第追記していこうと思います。
Gitでは様々な用語が出てきます。結構頻繁にいろんな用語が出てきますのでその用語を簡単にまとめてみました。 用語の意味を理解してからいろいろな記事を見るとより理解が深まると思いますのでよかったら参考にしてください。
変更履歴の保管場所、過去のソースコードやファイルのデータベースの様なもの
専用サーバやGitHub等のサービス上にある複数人で共有するためのリポジトリ
自分の作業端末、ネットに繋がってなくても作業できる環境にあるリポジトリ
リモートリポジトリをローカルに複製することクローンすることでローカルリポジトリが作られる
gitの管理下に置かれた実際に作業するディレクトリのこと
リポジトリにコミットするためにコミットする対象を登録するところ
インデックスに対象を追加すること
インデックスに登録された変更をリポジトリに反映させるこ、ゲームで例えるとセーブ
変更履歴の保存場所。新たなブランチを作る（ブランチを切る）と変更履歴の保存場所を分岐させることができる。 ブランチを切ることによって何か変更を加えたい時にmasterブランチ（基本的にはプロジェクト等の本体になる部分）に影響を与えずに変更履歴を保存できる。
コミットの履歴やブランチの状態などを見やすくしたもの ↓こんな感じのやつです
各ブランチでの変更をまとめること、例えばブランチAをmasterにマージするとmasterにブランチAの変更が反映される ↓ツリーで見るとこんな感じになります
現在自分が作業している所を示すポインタ
ブランチを切り替える際などにヘッドを切り替えること
リモートリポジトリのことgitのコマンドを使う時にもよく出てきます
ローカルリポジトリにリモートリポジトリの特定のブランチをコピーすること
リモートリポジトリの状態をローカルリポジトリに反映すること リモートのmasterブランチをフェッチしてきてローカルのmasterブランチにマージという一連の流れをやってくれる
ローカルリポジトリの変更をリモートリポジトリに反映すること
マージやリモートリポジトリにプッシュする際に変更箇所等が重複した際に発生する現象のこと、gitが『同じ所が変更されているよ！どっちが正しいの？』と言っている状態のこと
とりあえずよく使われるのはこんな感じかと思います。 自分なりにまとめてみましたが他にもいろいろな用語があるのでまとめ次第追記していこうと思います。
事の起こり 編集途中のものを一旦 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
編集途中のものを一旦 stash した。それから rebase したりブランチを削除したりして最後にstashしたものを戻そう（stash pop）しようとら、stashしたものがない。stash list に何も出てこない。 stash した時のブランチを削除したから？
stash
rebase
stash pop
stash list
git fsck で追跡不能なリビジョンを表示する。
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
最近実務で初めてrebaseを使って「？？？？」となったので調べました。 以下の動画、記事が分かりやすかったです。 - Git MERGE vs REBASE - マージとリベース 具体例 今回は動画から引用してこのような場合を考えてみます。 m2まで作業が進んでいるmasterブランチからfeatureブランチへcheckout featureブランチでf1をコミット masterブランチにcheckoutしてm3をコミット 再度featureブランチにcheckoutしてf2をコミット ここまでの各ブランチのlog masterブランチのlog m3 m2 m1 featureブランチのlog f2 f1 m2 m1 merge vs rebase ここからfeatureブランチにて、masterブランチをmerge, rebaseするとそれぞれどうなるか見ていきます。 git merge masterのlog f2 m3 f1 m2 m1 git rebase masterのlog f2 f1 m3 m2 m1 mergeでは時系列に沿ってそのまま差分を統合しているのに対し、rebaseではfeatureブランチの先端がmasterで置き換えられています。 rebaseを用いるとコミット履歴がすっきりしますね。 rebaseのアンチパターン この記事から引用します。 リベースの特徴を理解できたら、次に最も重要なことは、実行してはいけないときを知ることです。git rebase の黄金律は、リベースを public ブランチでは決して使用しないことです。 masterブランチにて、自分の作業ブランチをrebaseしてしまうとmasterのコミット履歴が書き換えられてしまいます。 このように、他の人にも共有済みのブランチでrebaseは使わないように注意しましょう。
最近実務で初めてrebaseを使って「？？？？」となったので調べました。
以下の動画、記事が分かりやすかったです。 - Git MERGE vs REBASE - マージとリベース
今回は動画から引用してこのような場合を考えてみます。
m3 m2 m1
f2 f1 m2 m1
ここからfeatureブランチにて、masterブランチをmerge, rebaseするとそれぞれどうなるか見ていきます。
merge
git merge masterのlog
git merge master
f2 m3 f1 m2 m1
git rebase masterのlog
git rebase master
f2 f1 m3 m2 m1
mergeでは時系列に沿ってそのまま差分を統合しているのに対し、rebaseではfeatureブランチの先端がmasterで置き換えられています。 rebaseを用いるとコミット履歴がすっきりしますね。
この記事から引用します。
リベースの特徴を理解できたら、次に最も重要なことは、実行してはいけないときを知ることです。git rebase の黄金律は、リベースを public ブランチでは決して使用しないことです。
masterブランチにて、自分の作業ブランチをrebaseしてしまうとmasterのコミット履歴が書き換えられてしまいます。 このように、他の人にも共有済みのブランチでrebaseは使わないように注意しましょう。
マージまで 他のブランチをマージしたいブランチに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
他のブランチをマージしたいブランチに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
さーて今日から始めますよと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 ＼> |;;;;;;;;;;| ヾ;;;;;;;;! |;;;;;;;;;;| 〉;;;;;;|
さーて今日から始めますよとQiita投稿
プログラミングの知識をより深めるためにもアウトプットていきますよと 駆け出しのエンジニアなのでお手柔らかに?♂️
さて、そんな駆け出しエンジニアの初投稿の内容は！！！ gitignore
これなんとなくコミットさせたくないから〜的なこと認識でいたんです まあ一応そんな感じではあるのですが、ただどういうときに必要なのかいまいちピンときていなかったんですよね、、、
しかし！！！今日ここで！！！ なんとなくの認識から抜け出し、gitignoreを使う時はどういう時なのかを、
なんとなく！！！
わかるようにすることが目的です(なんとなくなんかい)
じゃあ本題やっていきますよと
まあ簡単いうとgitの管理下に置きたくないファイルの置き場所なんだとさ
以上のことを防止するためにも.gitignoreを使っているんです
ちなみに必要のないデータっていうのは、Mac使っている人なら .DS_Store というのが代表格ですかね どうも勝手に作成されてしまうみたいなんですよ
.DS_Store
こいつをgitの管理下に置かない様にするためにやることは簡単
これだけ。 .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 ＼> |;;;;;;;;;;| ヾ;;;;;;;;! |;;;;;;;;;;| 〉;;;;;;|
概要 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 -f filter-branchは過去のコミット全てを操作できてしまう強力なコマンドです。
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 -f
filter-branchは過去のコミット全てを操作できてしまう強力なコマンドです。
概要 git push がある日できなくなってしまいました。 自分の場合、GitHubアカウントを会社用(エンジニアアカウントとマスターアカウント)と個人用など複数使用していたためGitHub側の認証情報が切り替わっていてこの現象が起きているようでした。 本来、GitHubは規約で１つのアカウント使用することになっています。 なので、会社用アカウントを使用せず、個人アカウントで作業することで大抵は解決できます。 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
git push がある日できなくなってしまいました。
自分の場合、GitHubアカウントを会社用(エンジニアアカウントとマスターアカウント)と個人用など複数使用していたためGitHub側の認証情報が切り替わっていてこの現象が起きているようでした。
本来、GitHubは規約で１つのアカウント使用することになっています。 なので、会社用アカウントを使用せず、個人アカウントで作業することで大抵は解決できます。 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
