- 投稿日：2020-03-05T23:40:14+09:00
Windowsのパスワードを変更した時にgitの認証が通らなくなった
Windowsのパスワードを変更して、gitの認証が通らなくなって困りました。
$ git pull remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/ko-flavor/atcoder-java.git/'コントロールパネル > ユーザー アカウント > 資格情報マネージャー
編集したい資格情報の右側の↓をクリック。
編集から、パスワードを入力して、保存。
これで解決しました！
- 投稿日：2020-03-05T21:27:14+09:00
ざっくりgitコマンド
タイトル通りで自分用のメモ書きなのでいずれ追記したり、体系的にまとめていきたいと思います。
ブランチを削除する
$ git branch -d ブランチ名ブランチを強制削除
$ git branch -D ブランチ名リベース
git rebase ブランチ名リモートで削除されているブランチをローカルでも削除する
$ git fetch --prune対象のローカルブランチをリモートブランチに強制プッシュ
$ git push -f origin ローカルブランチ:リモートブランチworking directory内の変更を破棄（元に戻す）
$ git checkout -- ファイル名ブランチ一覧にコミットメッセージなどの詳細を加えて表示
$ git branch -v $ git branch -vv※ -vv オプションの方がリモートブランチ情報などより詳細な情報になる
コミットしていない内容を一時退避(変更内容をコミットしないとブランチ変更できないのでそういう時に使う)
$ git stash一時退避した内容(stash)を戻す
$ git stash pop stash@{0}※
stash@{0}は適宜変更
- 投稿日：2020-03-05T16:59:37+09:00
[git] 複数のリモートリポジトリを扱う&サブモジュール&複数のリモートリポジトリのサブモジュール
複数のリモートリポジトリを扱うための説明です．
さらにサブモジュールの扱い方も説明し，サブモジュールのリモートリポジトリを複数にする方法までまとめます．GitHub＋GitLabなどにしてサーバーダウンに備えましょう！
複数のリモートリポジトリを登録，同時にpushする
GitHub＋GitLabとか，サーバーダウン対策にもなると思います．次のコマンドを1回だけ操作すると
.git/configが追加されます．git remote set-url origin --add (2つめのリモートリポジトリのurl)fetchしてくるリポジトリ
上記の方法でやると，
.git/configが[remote "origin"] url = git@(1つめのリモートリポジトリのurl):username/hoge.git fetch = +refs/heads/*:refs/remotes/origin/* url = git@(2つめのリモートリポジトリのurl):username/hoge.gitのようになるが，この順番に注意．
$ git remote -v origin git@(1つめのリモートリポジトリのurl):username/hoge.git (fetch) origin git@(1つめのリモートリポジトリのurl):username/hoge.git (push) origin git@(2つめのリモートリポジトリのurl):username/hoge.git (push)1つめの方をfetchしてくるようになっている．remote-tracking branchの設定に起因？
リポジトリ内に別のリポジトリ
リポジトリ内で別のリポジトリを管理したいとき．特定のcommitを参照できます．
- リポジトリにサブモジュールを追加する
git submodule add (リモートリポジトリのurl) (必要ならディレクトリ名)
.gitmodulesにそのサブモジュールの情報が入ります．別のローカルリポジトリで，追加済みのサブモジュールを追加する
git submodule update -i
- リポジトリ内のサブモジュールを全てmergeする 大元のリポジトリでgit pullするとサブモジュールのリポジトリもfetchのみされるので，それを全て一括mergeしたい場合
git submodule foreach git merge- サブモジュールを最新のブランチにする（全てgit pullする）
git submodule foreach git pull origin master(参考)
-- https://qiita.com/sotarok/items/0d525e568a6088f6f6bb
-- https://qiita.com/kinpira/items/3309eb2e5a9a422199e9submoduleで複数のリモートリポジトリ
同様にsubmoduleのリポジトリ内で
git remote set-url origin --add (2つめのリモートリポジトリのurl)してやればよい．（大元のリポジトリの）
.git/modules/hoge/configに.git/configと同様の情報がある．
- 投稿日：2020-03-05T14:32:50+09:00
gitでたまに使うコマンド
概要
git関連でたまに使うコマンドリンクをまとめて見られるようにメモ
ブランチ一括削除
https://qiita.com/satoshi03/items/c53aab17f3270477e33a
//while git branch | grep <文字列> | while read branch ; do git branch -d ${branch} ; done ; //xarges git branch | grep <文字列> | xargs git branch -d特定コミット抽出して反映(cherry-pick)
https://qiita.com/ta__ho/items/8204a22a53b02ee0817e
https://img.atwikiimg.com/www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/git-cherry-pick.html//-nを付けるとstageの状態で止まる git cherry-pick -n <コミットID> //マージコミットを抽出したい場合 git cherry-pick -n -m 1 <コミットID>別リモートリポジトリを同じremote内に追加
https://qiita.com/chihiro/items/d018599ef13c35781412
・別リモートリポジトリを追加した時点でcherry-pickで別リポジトリから抽出は可能
・チェックアウトした別リモートリポジトリのブランチをマージすることも可能//同じ場所にリモートリポジトリを追加。ローカル名は何でもいい。origin_testとか。 git remote add <ローカル名> <url> git fetch <ローカル名> //追加したリモートリポジトリからブランチチェックアウト git checkout -b <任意のブランチ名> <ローカル名>/<抽出したいブランチ>submodule削除・再追加
http://takaaki-kasai-tech.blogspot.com/2014/02/how-to-remove-git-submodule-using-each-version.html
https://qiita.com/kinpira/items/3309eb2e5a9a422199e9※git バージョンが1.8.5以上の場合。
$ git submodule deinit path/to/submodule $ git rm path/to/submodule $ rm -rf path/to/submodule $ git submodule add 【リポジトリURL】 【追加したいディレクトリ】 //具体例 $ git submodule deinit -f aaa/bbb $ git rm aaa/bbb $ git submodule add https://git.git aaa/bbb※git バージョンが1.8.3未満は以下を個別に削除する必要がある。
//削除するサブモジュールの場所。 .git/config .gitmodules //git rm でサブモジュールパス削除 .git/modules/aaa/bbb //rm -rf で直接サブモジュールパス削除コンフリクト一方修正
https://qiita.com/nantekkotai/items/2ed17c3d774211d234a4
//現在ブランチの修正に変更 $ git checkout --ours AAAA.txt //マージする側ブランチの修正に変更 $ git checkout --theirs fileB.txt //実行後はaddする $ git add <ファイル名>コミット打ち消し・修正・取消
https://qiita.com/kansiho/items/2bacecdb95d752cb38b7
https://qiita.com/ritukiii/items/74ee3274c3f218511a0c
https://qiita.com/chihiro/items/2fa827d0eac98109e7ee・reset
・amend
・revert
・【危険】push -f//ローカル上で修正残して直前コミット取消 git reset --soft HEAD^ //ローカル上で修正含めて直前コミット取消 git reset --hard HEAD^ //ローカル上でコミット直後に再度直前コミットのソース修正・コメント修正等をして、同じコミットにしたい場合 git commit --amend //取り消した内容を残してコミットする git revert <commit> //戻したい位置までコミット戻してリモート強制更新 git reset --hard <commit_id> git push origin HEAD --force差分抽出
//[1]取得ソースの branch名/hashtag/tag名 //[2]ベースのbranch名/hashtag/tag名 //[3]変更あるbranch名/hashtag/tag名 git archive [１] `git diff --name-only [２] [３] --diff-filter=ACMR` -o [zipファイル名].zipstage から Unmerged paths,Untracked filesに戻す・削除
https://qiita.com/rch1223/items/9377446c3d010d91399b
※戻す方法は上記にいろいろ載ってる
https://qiita.com/k0uh0t/items/ae885bf2d5e05614b80f//stage から Unmerged paths git reset <ファイル名> git reset . //変更前に戻す git reset HEAD <ファイル名> //gitから削除 git rm -rf フルパス //Untracked filesのディレクトリ含めた削除 git clean -fdコンフィグ関連
・文字コード設定とか
https://nekonenene.hatenablog.com/entry/2015/04/18/210706
・git logが見やすくなる
https://blog.toshimaru.net/git-log-graph/
・git for windows改行関連
https://qiita.com/uggds/items/00a1974ec4f115616580
- 投稿日：2020-03-05T01:52:35+09:00
【Git】Gitよく使うコマンド個人メモ
ディレクトリ毎回打ち込むのめんどくさ
ターミナルで上矢印キー押したらシャットダウンしても前回のコマンド辿れる
リポジトリ作成からPushまで
cd <任意のディレクトリ> git init git remote add origin <リモートのURL> git add . git commit -m "Commit Message" git push -u origin master今どんな状態か確認
git statusブランチ作成してリモートに登録
git checkout -b <任意のブランチ名> git push -u origin <任意のブランチ名>ブランチ削除
git branch -D <任意のブランチ名> //ローカル削除 git push --delete origin <任意のブランチ名> //リモート削除 git fetch -p //GUI上で削除したリモートをローカルに反映コミットのコメント修正
git commit --amend -m "新しいコメント"ローカルでごちゃごちゃいじったものを元に戻す
git checkout .過去のごちゃごちゃした履歴を見る
git reflog //qで閉じる過去のコミットの履歴を見る
git log --oneline過去のコミットの状態まで戻る
git reset --hard <commit ID> //hardだとそのコミット自体も消える特定のブランチを指定してクローン
git clone -b ブランチ名 リポジトリのアドレス
- 投稿日：2020-03-05T01:23:34+09:00
Gitに慣れていない人がよくハマるパターンと対処法まとめ
はじめに
Gitって難しいですよね。本当に！
プログラミング歴1年弱の自分がチーム開発に加わる様になってに一番不安なのはGitの扱いです。
ミスにビクビクしながら、日々を過ごしています。そんな僕が初学者達が現場でうま〜く立ち回れる様に、Gitに慣れていない人がよくハマるパターンと対処法をまとめました。参考になれば幸いです。
作業ブランチ間違えて作業しちゃった！！パターン
これは僕が一番やっちゃうやつです！
作業している途中や、git statusしている辺りでブランチを間違えていた事に気がつきます！対処法
1 git stash -u 一旦、作業していた分を退避する 2 git checkout 正しいブランチ名 正しいブランチに切り替える 3 git stash pop 退避していた分を正しいブランチの方に持ってくる作業中に他の作業が差し込みで入った時なども、git stashで一旦退避させる事でブランチの切り替えが可能になります！
commitメッセージを記入し忘れたー！パターン
これは
git commitした後、ボーッとしててcommitメッセージを書き忘れたり、commitメッセージを書き間違えた時ですね。対処法
これは簡単です！
git commit --amend -m 修正後のcommitメッセージ
git add .でいらんファイルまでステージングしちゃったー！パターン本当は
git add .ではなく、git status→git add ファイル名で1ファイルずつステージングしていくべきなのですが、自分は一度にcommitするファイルが多い為、git add .を好んで使います。そうすると、なぜかステージング済にpackage.json君などの変更しちゃいけない子が行ってしまう時があります。そんな時の対処法はこちらです。
対処法
# ファイル名を指定して戻したい時 git reset ファイル名 #git addした全てのファイルを戻したい時 git reset .いらない追跡対象外のファイルがなぜかたくさんあって、このままだとcommitできねえー！！パターン
多分、pathの設定ミスによって起きるんだと思いますが、、
追跡対象外のファイルが大量に変更済エリアに雪崩れ込んでくることがあります。そんな時の一時的な対処法です。
対処法
# カレントディレクトリ内の追跡対象外のファイルを確認する git clean -n # カレントディレクトリ内の追跡対象外のファイルを削除 git clean -fこれで邪魔なファイル達は消えてくれるので、commitが進められます。
プルリクを送る先を間違えたーー！パターン
これは正確にはGitじゃなくて、Githubでのミスなのですがご愛嬌。
Githubからプルリクエストを送る時にdevelopに送りたいのに間違えてmasterに送っちゃったー！レビュアーの人に見られる！！的な場合の対処法ですね。対処法
1 Githubで対象のプルリク のページに行きます。
2 下記の画像の右上のEditの所をクリックして完了です！
3 下記の画像の様に、送り先のブランチを切り替えて、右上のSaveを押します。
プルリクエストのLGTMぐらいカッコ良く出してええ！！パターン
これまた正確にはGitではありませんが、プルリクのレビュアーをする際にただテキストでOKやLGTMを出すだけでは味気ないですよね。
あまり開発で貢献できない分、コミュニケーションでチームを盛り上げて行きたい！そんな時の対処法はこちらです。対処法
LGTMの画像を作って送りましょう。
https://lgtm.fun/プルリクを出した人が乃木坂のファンならこちらを送り
最近鬼滅の刃を見た様ならこちらを送りましょう！
まとめ
とはいえ、今回書いたハマるパターンといってもうっかりミスがほとんどです！普段から確認を怠らない姿勢でGitを扱う事が一番の対処法だと思います。
補足(2020/3/7追記)
コメントにありましたが、常にシェルのpropmtにブランチやステータスを表示できるみたいです。
うっかりミスが多い人は参考にして下さい。
http://tm.root-n.com/unix:command:git:bash_prompt
- 投稿日：2020-03-05T00:59:56+09:00
【GitHub】開発中ブランチを安全に退避させてプルリクを作成するまでのタイムアタック【Pull Request】
素早くプルリクを出そう
エンジニアたるもの、自分が書いたコードがマージされて初めて仕事です。
マージされる前には、 プルリクエスト(プルリク)を出す必要があります。最近、プルリクを結構な頻度で投げられるようになったので、ちょっと数えてみました。
大体、一ヶ月で75プルリク、１営業日あたり3.75個のプルリクを出していました。この背景にあるのは、プルリクを早く作るためのコツを習得したことにあると考えています。
というのも、プルリクは差分を作る作業以外に、変更点を確認したり、プッシュしてからブラウザを開いてプルリクを作成したり、意外に雑用が多いです。
この面倒な作業をいかに早くできるようになるかのタイムアタックです。この記事では、素早くプルリクを出すコツを習得したような気になっている私が、私のやり方をかなり正直に伝えます。
ただし、差分の中身や、レビューにかかる時間は計算に入れていません。プルリクにまつわるコード修正以外の作業の時間を最小化することを目指しています。
よっしゃ！修正箇所発見！
あなたは
my-branchで絶賛開発中だとします。
origin/masterで修正が必要な箇所が見つかりました。
あなたがその修正をすることになりました。しかし、開発中ブランチをどうしましょう。。
一旦開発ブランチの変更を退避して、ブランチを変える必要があります。
修正後、my-branchに戻ってくる未来を信じましょう。
git status開発中ブランチの変更ファイルを確認するプルリクだけでなく、gitを扱うものとして、
git statusは一番使うコマンドと言っても間違いではありません。
実際、私が一回のプルリクでgit statusは10~20回は軽く打つと思います。
HEADコミット、ここではmy-branchのコミットから変更されたファイル一覧が出力されます。$ git status -sbこの
-sbオプションは、ブランチを表示した上でシンプルな表記にしてくれるため、git status -sbをエイリアスにすると良いです。
git stash開発中ファイルを退避
git stashで差分のあるファイルを一時保存します。$ git stash新しく追加したファイルはトラッキングされてないので
git addしてからgit stashしておきましょう。
git switchmasterブランチに移動続いて、プルリクを出すターゲットとなるブランチに移動します。ここでは、
masterです。$ git switch master
git pullmasterブランチを最新版にアップデートこの
masterブランチは最新版とは限りません。移動した瞬間、次のコマンドで最新版にします。
普通の使い方をしていれば、Fast-forwadでシンプルにコミットがくっついてきます。$ git pull
git switch -cmasterから新しくブランチを生やす最新版のmasterブランチから、プルリクのための修正ブランチを生やします。
git checkout -bでやっているのはちょっとナウくないですね。$ git switch -c pr1-fix-handler-errorgit switchとrestoreの役割と機能について などを参考にしてください。
プルリクを出す
さて、ここまでで およそ30秒くらい を目指しましょう。
続いては、実際にファイルを修正します。ただし、今回は修正の中身自体には興味がないのでスキップします。
修正が終わったあと、コミット・プッシュし、プルリクを作るところまでやってみます。
git diffで修正内容の差分を見る修正した内容が本当に正しいかは、差分を見て確認しましょう。
問題なければ、修正作業は終了です。$ git diff origin/master
git addステージング領域に上げる
git statusで変更されたファイル一覧を見ながら、コミットするファイルをステージングに上げていきます。$ git add handler.go
git statusで変更されたファイルが限られている場合、時間短縮のために以下のコマンドを使ってもよいです。$ git add .よくおかしなファイルがコミットされるから一個ずつ上げることを推奨することがあります。
しかし、私の持論として、問題はgit addではなく、その手前の段階のgit statusでの確認不足にあると考えられます。
git commitコミットメッセージは、プルリクのdescriptionを書くさて、ついにコミットです。
git commit -m "commit-message"は便利ですが、ここでは単純に以下のコマンドを使います。$ git commitこのコマンドを打つと、エディタが起動します。そして、次のような入力画面が現れます。
- 一行目 プルリクのタイトル
- 二行目は空行
- 三行目以降 プルリクのdescription
を書いていきます。
重要なことは、ここで 人に見せる意識でメッセージを残す ことです。1 ↲ 2 ; Please enter the commit message for your changes. Lines starting↲ 3 ; with ';' will be ignored, and an empty message aborts the commit.↲ 4 ;↲ 5 ; On branch master↲ 6 ; Your branch is up to date with 'origin/master'.↲ 7 ;↲ 8 ; Changes to be committed:↲ 9 ;»------new file: handler.go↲ 10 ;↲↲コミットしたあとに、コミットメッセージを修正したいときや、別ファイルもコミットに加えたいときは
--amendで一個前のコミットを上書きできます。$ git commit --amend
git rebase最新版のmasterにコミットをつなぎ直すさて、あなたは素早く修正したつもりでしたが、思いの外masterブランチの開発速度が早く、コミットが進んでしまっていたようです。
場合によっては、プッシュするとコンフリクトしてしまうかもしれません。こんなときは、まず
git fetchでorigin/masterをアップデートしたあと、git rebaseでコミットを最新版のorigin/masterにつけ直します。$ git fetch $ git rebase origin/master
git pushリモートリポジトリにブランチを作る最新版の
origin/masterから一つだけコミットが伸びたブランチが出来上がりました。
これをリモートリポジトリにプッシュします。$ git push
hub pull-requestプルリクを出す無事にブランチはプッシュできました。ここでGitHubを開くようではタイムアタックで勝ち上がることはできません。
hubコマンドで、まずプルリクを作ります。
以下のコマンドを実行すると、コミットメッセージが並んだ入力画面が開きます。あなたがさきほど頑張って書いておいたコミットメッセージはそのままプルリクのタイトルと説明文にすることができます。
入力画面を閉じると、プルリクが実際に作られます。$ hub pull-request -a zawawahoge$ hub pull-request -a zawawahoge https://github.com/your-organization/your-repo/pull/123プルリクのURLが出力されました。
上記のコマンドでレビュアーも指定できるのですが、私はまずGUIで確認してからGitHub上で指定するようにしています。
GiｔHubの差分は見やすいので、自分自身のミスも発見しやすくなります。大丈夫そうだと思ったら、思い切ってレビュアーを設定しましょう！
プルリクの修正
親切なチームメンバーの方々が、コメントを残してくれました。
少なからず変更点がありました。面倒臭がらず直していきます。
git merge最新版のmasterをマージする修正の前に、最新版の
origin/masterをマージしておきましょう。$ git merge origin/master $ git add . $ git commit -m "simple message" $ git push
rebaseコミット履歴をきれいにする修正の結果、
fixやtrivial changeみたいなコミットがたくさんついてしまうことありますよね。
こういうときは、思い切ってgit rebaseしてorigin/masterからのコミットをすべて書き換えることもあります。
一個だけコミットを修正したいときはgit commit --amendも有効です。$ git rebase origin/master -i $ git push -fまたは
$ git commit --amend $ git push -f
rebaseした場合は、git push -fでforce pushしないとプッシュできません。なぜなら、コミット履歴がごっそり書き換わっているからです。
用法と用量を守ってforce pushしましょう。GitHub上でのレビュー後の修正コミットもわからなくなるので、マージする直前なんかにやるといいです。
re-reviewしてもらったあと、ついに approve いただきましたー！
プルリクのマージ
マージは気持ちが良いものです。
approveされたら、堂々とマージしましょう。
バグが起きたら、リバートするなり、再度修正プルリクを出しましょう。squash mergeでプルリクを一つのコミットに潰す
GitHubでリポジトリの設定を変えると、プルリクのコミット履歴を一つにまとめてマージしてくれるsquash mergeがあります。
チームと相談して、merge commitがいるかどうか議論してからsquash mergeの導入を検討すると良いです。前の開発ブランチに戻る
git stash popで元のブランチでの開発環境を復活させるもう忘れかけていた最初のブランチ・・・。
名前も忘れちゃったけど、ちょっと思い出してみるとmy-branchでした。$ git switch first-branch $ git stash popようやく、元の開発環境に完全に戻ることができました。
まとめ
長くなりましたが、いかがでしたでしょうか？
最近もくもくと一人でタイムアタックしているのですが、誰にも認識されずやっててつまらない気がしたので、いっそ外部公開しようと思って記事にしてみました。参考になれば幸いです。
面白かったと思ってもらえたらいいねしてもらえると嬉しいです！
Twitter(zawawahoge)もやってますので、フォローしてくれると泣いて喜びます。
（おまけ） エイリアス大公開
５個くらいしか登録してないですが、あると便利なエイリアス紹介しておきます。
完全に自己流なのでご注意。alias gf='git fetch' alias gs='git status -sb' alias gd='git diff' alias gw='git switch' alias gp='git pull'
- 投稿日：2020-03-05T00:59:56+09:00
【GitHub】開発中ブランチを安全に退避させてプルリクを作成するまでに使うGitコマンド紹介【Pull Request】
素早くプルリクを出そう
エンジニアたるもの、自分が書いたコードがマージされて初めて仕事です。
マージされる前には、 プルリクエスト(プルリク)を出す必要があります。最近、プルリクを結構な頻度で投げられるようになったので、ちょっと数えてみました。
大体、一ヶ月で75プルリク、１営業日あたり3.75個のプルリクを出していました。この背景にあるのは、プルリクを早く作るためのコツを習得したことにあると考えています。
というのも、プルリクは差分を作る作業以外に、変更点を確認したり、プッシュしてからブラウザを開いてプルリクを作成したり、意外に雑用が多いです。
この面倒な作業をいかに早くできるようになるかのタイムアタックです。この記事では、素早くプルリクを出すコツを習得したような気になっている私が、私のやり方をかなり正直に伝えます。
ただし、差分の中身や、レビューにかかる時間は計算に入れていません。プルリクにまつわるコード修正以外の作業の時間を最小化することを目指しています。
よっしゃ！修正箇所発見！
あなたは
my-branchで絶賛開発中だとします。
origin/masterで修正が必要な箇所が見つかりました。
あなたがその修正をすることになりました。しかし、開発中ブランチをどうしましょう。。
一旦開発ブランチの変更を退避して、ブランチを変える必要があります。
修正後、my-branchに戻ってくる未来を信じましょう。
git status開発中ブランチの変更ファイルを確認するプルリクだけでなく、gitを扱うものとして、
git statusは一番使うコマンドと言っても間違いではありません。
実際、私が一回のプルリクでgit statusは10~20回は軽く打つと思います。
HEADコミット、ここではmy-branchのコミットから変更されたファイル一覧が出力されます。$ git status -sbこの
-sbオプションは、ブランチを表示した上でシンプルな表記にしてくれるため、git status -sbをエイリアスにすると良いです。
git stash開発中ファイルを退避
git stashで差分のあるファイルを一時保存します。$ git stash新しく追加したファイルはトラッキングされてないので
git addしてからgit stashしておきましょう。
git switchmasterブランチに移動続いて、プルリクを出すターゲットとなるブランチに移動します。ここでは、
masterです。$ git switch master
git pullmasterブランチを最新版にアップデートこの
masterブランチは最新版とは限りません。移動した瞬間、次のコマンドで最新版にします。
普通の使い方をしていれば、Fast-forwadでシンプルにコミットがくっついてきます。$ git pull
git switch -cmasterから新しくブランチを生やす最新版のmasterブランチから、プルリクのための修正ブランチを生やします。
git checkout -bでやっているのはちょっとナウくないですね。$ git switch -c pr1-fix-handler-errorgit switchとrestoreの役割と機能について などを参考にしてください。
プルリクを出す
さて、ここまでで およそ30秒くらい を目指しましょう。
続いては、実際にファイルを修正します。ただし、今回は修正の中身自体には興味がないのでスキップします。
修正が終わったあと、コミット・プッシュし、プルリクを作るところまでやってみます。
git diffで修正内容の差分を見る修正した内容が本当に正しいかは、差分を見て確認しましょう。
問題なければ、修正作業は終了です。$ git diff origin/master
git addステージング領域に上げる
git statusで変更されたファイル一覧を見ながら、コミットするファイルをステージングに上げていきます。$ git add handler.go
git statusで変更されたファイルが限られている場合、時間短縮のために以下のコマンドを使ってもよいです。$ git add .よくおかしなファイルがコミットされるから一個ずつ上げることを推奨することがあります。
しかし、私の持論として、問題はgit addではなく、その手前の段階のgit statusでの確認不足にあると考えられます。
git commitコミットメッセージは、プルリクのdescriptionを書くさて、ついにコミットです。
git commit -m "commit-message"は便利ですが、ここでは単純に以下のコマンドを使います。$ git commitこのコマンドを打つと、エディタが起動します。そして、次のような入力画面が現れます。
- 一行目 プルリクのタイトル
- 二行目は空行
- 三行目以降 プルリクのdescription
を書いていきます。
重要なことは、ここで 人に見せる意識でメッセージを残す ことです。1 ↲ 2 ; Please enter the commit message for your changes. Lines starting↲ 3 ; with ';' will be ignored, and an empty message aborts the commit.↲ 4 ;↲ 5 ; On branch master↲ 6 ; Your branch is up to date with 'origin/master'.↲ 7 ;↲ 8 ; Changes to be committed:↲ 9 ;»------new file: handler.go↲ 10 ;↲↲コミットしたあとに、コミットメッセージを修正したいときや、別ファイルもコミットに加えたいときは
--amendで一個前のコミットを上書きできます。$ git commit --amend
git rebase最新版のmasterにコミットをつなぎ直すさて、あなたは素早く修正したつもりでしたが、思いの外masterブランチの開発速度が早く、コミットが進んでしまっていたようです。
場合によっては、プッシュするとコンフリクトしてしまうかもしれません。こんなときは、まず
git fetchでorigin/masterをアップデートしたあと、git rebaseでコミットを最新版のorigin/masterにつけ直します。$ git fetch $ git rebase origin/master
git pushリモートリポジトリにブランチを作る最新版の
origin/masterから一つだけコミットが伸びたブランチが出来上がりました。
これをリモートリポジトリにプッシュします。$ git push
hub pull-requestプルリクを出す無事にブランチはプッシュできました。ここでGitHubを開くようではタイムアタックで勝ち上がることはできません。
hubコマンドで、まずプルリクを作ります。
以下のコマンドを実行すると、コミットメッセージが並んだ入力画面が開きます。あなたがさきほど頑張って書いておいたコミットメッセージはそのままプルリクのタイトルと説明文にすることができます。
入力画面を閉じると、プルリクが実際に作られます。$ hub pull-request -a zawawahoge$ hub pull-request -a zawawahoge https://github.com/your-organization/your-repo/pull/123プルリクのURLが出力されました。
上記のコマンドでレビュアーも指定できるのですが、私はまずGUIで確認してからGitHub上で指定するようにしています。
GiｔHubの差分は見やすいので、自分自身のミスも発見しやすくなります。大丈夫そうだと思ったら、思い切ってレビュアーを設定しましょう！
プルリクの修正
親切なチームメンバーの方々が、コメントを残してくれました。
少なからず変更点がありました。面倒臭がらず直していきます。
git merge最新版のmasterをマージする修正の前に、最新版の
origin/masterをマージしておきましょう。$ git merge origin/master $ git add . $ git commit -m "simple message" $ git push
rebaseコミット履歴をきれいにする修正の結果、
fixやtrivial changeみたいなコミットがたくさんついてしまうことありますよね。
こういうときは、思い切ってgit rebaseしてorigin/masterからのコミットをすべて書き換えることもあります。
一個だけコミットを修正したいときはgit commit --amendも有効です。$ git rebase origin/master -i $ git push -fまたは
$ git commit --amend $ git push -f
rebaseした場合は、git push -fでforce pushしないとプッシュできません。なぜなら、コミット履歴がごっそり書き換わっているからです。
用法と用量を守ってforce pushしましょう。GitHub上でのレビュー後の修正コミットもわからなくなるので、マージする直前なんかにやるといいです。
re-reviewしてもらったあと、ついに approve いただきましたー！
プルリクのマージ
マージは気持ちが良いものです。
approveされたら、堂々とマージしましょう。
バグが起きたら、リバートするなり、再度修正プルリクを出しましょう。squash mergeでプルリクを一つのコミットに潰す
GitHubでリポジトリの設定を変えると、プルリクのコミット履歴を一つにまとめてマージしてくれるsquash mergeがあります。
チームと相談して、merge commitがいるかどうか議論してからsquash mergeの導入を検討すると良いです。前の開発ブランチに戻る
git stash popで元のブランチでの開発環境を復活させるもう忘れかけていた最初のブランチ・・・。
名前も忘れちゃったけど、ちょっと思い出してみるとmy-branchでした。$ git switch first-branch $ git stash popようやく、元の開発環境に完全に戻ることができました。
まとめ
長くなりましたが、いかがでしたでしょうか？
最近もくもくと一人でタイムアタックしているのですが、誰にも認識されずやっててつまらない気がしたので、いっそ外部公開しようと思って記事にしてみました。参考になれば幸いです。
面白かったと思ってもらえたらいいねしてもらえると嬉しいです！
Twitter(zawawahoge)もやってますので、フォローしてくれると泣いて喜びます。
（おまけ） エイリアス大公開
５個くらいしか登録してないですが、あると便利なエイリアス紹介しておきます。
完全に自己流なのでご注意。alias gf='git fetch' alias gs='git status -sb' alias gd='git diff' alias gw='git switch' alias gp='git pull'
- 投稿日：2020-03-05T00:59:56+09:00
素早くプルリクを出すコツ
素早くプルリクを出そう
エンジニアたるもの、自分が書いたコードがマージされて初めて仕事です。
マージされる前には、 プルリクエスト(プルリク)を出す必要があります。最近、プルリクを結構な頻度で投げられるようになったので、ちょっと数えてみました。
大体、一ヶ月で75プルリク、１営業日あたり3.75個のプルリクを出していました。この背景にあるのは、プルリクを早く作るためのコツを習得したことにあると考えています。
というのも、プルリクは差分を作る作業以外に、変更点を確認したり、プッシュしてからブラウザを開いてプルリクを作成したり、意外に雑用が多いです。
この面倒な作業をいかに早くできるようになるかのタイムアタックです。この記事では、素早くプルリクを出すコツを習得したような気になっている私が、私のやり方をかなり正直に伝えます。
ただし、差分の中身や、レビューにかかる時間は計算に入れていません。プルリクにまつわるコード修正以外の作業の時間を最小化することを目指しています。
よっしゃ！修正箇所発見！
あなたは
my-branchで絶賛開発中だとします。
origin/masterで修正が必要な箇所が見つかりました。
あなたがその修正をすることになりました。しかし、開発中ブランチをどうしましょう。。
一旦開発ブランチの変更を退避して、ブランチを変える必要があります。
修正後、my-branchに戻ってくる未来を信じましょう。
git status開発中ブランチの変更ファイルを確認するプルリクだけでなく、gitを扱うものとして、
git statusは一番使うコマンドと言っても間違いではありません。
実際、私が一回のプルリクでgit statusは10~20回は軽く打つと思います。
HEADコミット、ここではmy-branchのコミットから変更されたファイル一覧が出力されます。$ git status -sbこの
-sbオプションは、ブランチを表示した上でシンプルな表記にしてくれるため、git status -sbをエイリアスにすると良いです。
git stash開発中ファイルを退避
git stashで差分のあるファイルを一時保存します。$ git stash新しく追加したファイルはトラッキングされてないので
git addしてからgit stashしておきましょう。
git switchmasterブランチに移動続いて、プルリクを出すターゲットとなるブランチに移動します。ここでは、
masterです。$ git switch master
git pullmasterブランチを最新版にアップデートこの
masterブランチは最新版とは限りません。移動した瞬間、次のコマンドで最新版にします。
普通の使い方をしていれば、Fast-forwadでシンプルにコミットがくっついてきます。$ git pull
git switch -cmasterから新しくブランチを生やす最新版のmasterブランチから、プルリクのための修正ブランチを生やします。
git checkout -bでやっているのはちょっとナウくないですね。$ git switch -c pr1-fix-handler-errorgit switchとrestoreの役割と機能について などを参考にしてください。
プルリクを出す
さて、ここまでで およそ30秒くらい を目指しましょう。
続いては、実際にファイルを修正します。ただし、今回は修正の中身自体には興味がないのでスキップします。
修正が終わったあと、コミット・プッシュし、プルリクを作るところまでやってみます。
git diffで修正内容の差分を見る修正した内容が本当に正しいかは、差分を見て確認しましょう。
問題なければ、修正作業は終了です。$ git diff origin/master
git addステージング領域に上げる
git statusで変更されたファイル一覧を見ながら、コミットするファイルをステージングに上げていきます。$ git add handler.go
git statusで変更されたファイルが限られている場合、時間短縮のために以下のコマンドを使ってもよいです。$ git add .よくおかしなファイルがコミットされるから一個ずつ上げることを推奨することがあります。
しかし、私の持論として、問題はgit addではなく、その手前の段階のgit statusでの確認不足にあると考えられます。
git commitコミットメッセージは、プルリクのdescriptionを書くさて、ついにコミットです。
git commit -m "commit-message"は便利ですが、ここでは単純に以下のコマンドを使います。$ git commitこのコマンドを打つと、エディタが起動します。そして、次のような入力画面が現れます。
- 一行目 プルリクのタイトル
- 二行目は空行
- 三行目以降 プルリクのdescription
を書いていきます。
重要なことは、ここで 人に見せる意識でメッセージを残す ことです。1 ↲ 2 ; Please enter the commit message for your changes. Lines starting↲ 3 ; with ';' will be ignored, and an empty message aborts the commit.↲ 4 ;↲ 5 ; On branch master↲ 6 ; Your branch is up to date with 'origin/master'.↲ 7 ;↲ 8 ; Changes to be committed:↲ 9 ;»------new file: handler.go↲ 10 ;↲↲コミットしたあとに、コミットメッセージを修正したいときや、別ファイルもコミットに加えたいときは
--amendで一個前のコミットを上書きできます。$ git commit --amend
git rebase最新版のmasterにコミットをつなぎ直すさて、あなたは素早く修正したつもりでしたが、思いの外masterブランチの開発速度が早く、コミットが進んでしまっていたようです。
場合によっては、プッシュするとコンフリクトしてしまうかもしれません。こんなときは、まず
git fetchでorigin/masterをアップデートしたあと、git rebaseでコミットを最新版のorigin/masterにつけ直します。$ git fetch $ git rebase origin/master
git pushリモートリポジトリにブランチを作る最新版の
origin/masterから一つだけコミットが伸びたブランチが出来上がりました。
これをリモートリポジトリにプッシュします。$ git push
hub pull-requestプルリクを出す無事にブランチはプッシュできました。ここでGitHubを開くようではタイムアタックで勝ち上がることはできません。
hubコマンドで、まずプルリクを作ります。
以下のコマンドを実行すると、コミットメッセージが並んだ入力画面が開きます。あなたがさきほど頑張って書いておいたコミットメッセージはそのままプルリクのタイトルと説明文にすることができます。
入力画面を閉じると、プルリクが実際に作られます。$ hub pull-request -a zawawahoge$ hub pull-request -a zawawahoge https://github.com/your-organization/your-repo/pull/123プルリクのURLが出力されました。
上記のコマンドでレビュアーも指定できるのですが、私はまずGUIで確認してからGitHub上で指定するようにしています。
GiｔHubの差分は見やすいので、自分自身のミスも発見しやすくなります。大丈夫そうだと思ったら、思い切ってレビュアーを設定しましょう！
プルリクの修正
親切なチームメンバーの方々が、コメントを残してくれました。
少なからず変更点がありました。面倒臭がらず直していきます。
git merge最新版のmasterをマージする修正の前に、最新版の
origin/masterをマージしておきましょう。$ git merge origin/master $ git add . $ git commit -m "simple message" $ git push
rebaseコミット履歴をきれいにする修正の結果、
fixやtrivial changeみたいなコミットがたくさんついてしまうことありますよね。
こういうときは、思い切ってgit rebaseしてorigin/masterからのコミットをすべて書き換えることもあります。
一個だけコミットを修正したいときはgit commit --amendも有効です。$ git rebase origin/master -i $ git push -fまたは
$ git commit --amend $ git push -f
rebaseした場合は、git push -fでforce pushしないとプッシュできません。なぜなら、コミット履歴がごっそり書き換わっているからです。
用法と用量を守ってforce pushしましょう。GitHub上でのレビュー後の修正コミットもわからなくなるので、マージする直前なんかにやるといいです。
re-reviewしてもらったあと、ついに approve いただきましたー！
プルリクのマージ
マージは気持ちが良いものです。
approveされたら、堂々とマージしましょう。
バグが起きたら、リバートするなり、再度修正プルリクを出しましょう。squash mergeでプルリクを一つのコミットに潰す
GitHubでリポジトリの設定を変えると、プルリクのコミット履歴を一つにまとめてマージしてくれるsquash mergeがあります。
チームと相談して、merge commitがいるかどうか議論してからsquash mergeの導入を検討すると良いです。前の開発ブランチに戻る
git stash popで元のブランチでの開発環境を復活させるもう忘れかけていた最初のブランチ・・・。
名前も忘れちゃったけど、ちょっと思い出してみるとmy-branchでした。$ git switch first-branch $ git stash popようやく、元の開発環境に完全に戻ることができました。
まとめ
長くなりましたが、いかがでしたでしょうか？
最近もくもくと一人でタイムアタックしているのですが、誰にも認識されずやっててつまらない気がしたので、いっそ外部公開しようと思って記事にしてみました。参考になれば幸いです。
面白かったと思ってもらえたらいいねしてもらえると嬉しいです！
Twitter(zawawahoge)もやってますので、フォローしてくれると泣いて喜びます。
（おまけ） エイリアス大公開
５個くらいしか登録してないですが、あると便利なエイリアス紹介しておきます。
完全に自己流なのでご注意。alias gf='git fetch' alias gs='git status -sb' alias gd='git diff' alias gw='git switch' alias gp='git pull'