はじめに Github上でこれまでちゃんとしたPR(Pull Request)したことなかったので、DCO(Developer Certificate of Origin)チェックで全てのログにSigned-off-byが必要という点を理解していなくて、困った時のログです。 --amend --signoff すればいいんだと思ったものの プロジェクトのコミッターから、「レビューする前にSigned-off-byを加えて欲しいな。まぁsquashしてもいいかも。」というメッセージが届いたので、PR画面を開いたところ、DCOチェックに失敗していて、その詳細説明には次の手順が書かれていました。 ## 最初に読めとあったリンク先に、gh prしなさいとあったのでこれを実行 $ gh pr checkout 2084 ## DCOのエラー画面には次のコマンドが表示されていた $ git commit --amend --no-edit --signoff $ git push --force-with-lease origin 20210413_anonymous_bind ## 20210413_anonymous_bind は自分で作成したbranchの名前 直前の変更を取り消してSigned-off-byを加えるのかぁ、と思ってそのまま実行したものの、これを実行してもうまくいかず、気がつけばこんな感じのコミットログになっていました。 PRしたブランチのログ commit 703c1556176fdf89bf819dd6a0118aabe291caad (HEAD -> 20210413_anonymous_bind, origin/20210413_anonymous_bind) Merge: 66779fff b79308e9 Author: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> Date: Wed Apr 14 00:15:06 2021 +0900 Merge branch '20210413_anonymous_bind' of github.com:YasuhiroABE/dex into 20210413_anonymous_bind Signed-off-by: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> commit 66779fffcab1f3663fa57e3bab9d23e01c1f1c30 Author: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> Date: Wed Apr 14 00:02:27 2021 +0900 add the anonymousBind configuration parameter and to use the UnauthenticatedBind function. Signed-off-by: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> commit b79308e9feda775f8b5e3469894e03a9d2ca704e Author: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> Date: Wed Apr 14 00:02:27 2021 +0900 add the anonymousBind configuration parameter and to use the UnauthenticatedBind function. commit b79d9a84bc0c35e13a9d5141e95b641af0f81c8f (origin/master, origin/HEAD, master) Merge: c7549cce 03db3093 Author: Márk Sági-Kazár <sagikazarmark@users.noreply.github.com> Date: Thu Apr 8 17:50:52 2021 +0200 いろいろドキュメントを調べて、この時点で全てのログにsigned-off-byがないといけないのだと知りました。 確かに最初のコミットログ SHA1:b79308e9 にはsigned-off-byがありません。 調べてみると、いくらか不要なコミットを取り消しつつ、signoffするにはいくつか方法があるものの、今回はrebaseがシンプルに思えたので、次の方法を採用しました。 $ mkdir dex.signoff $ rsync -av dex dex.signoff/ $ cd dex.signoff/dex $ git rebase --signoff HEAD^^ 実際にはrsyncで作業用ディレクトリ全体のコピーを作成して、問題ないことを確認してからpushしています。 これで SHA1:b79308e9 自体がなくなって、ハッシュ値は新しくなっていますが、冗長なログは消えて、最初のメッセージにSigned-off-byが付いたログになりました。 rebase実行後のログ commit 6e845f2c90c0b1d200e1e016014970e9cf037c15 (HEAD -> 20210413_anonymous_bind, origin/20210413_anonymous_bind) Author: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> Date: Wed Apr 14 00:02:27 2021 +0900 add the anonymousBind configuration parameter and to use the UnauthenticatedBind function. Signed-off-by: Yasuhiro ABE <yasu-abe@u-aizu.ac.jp> commit b79d9a84bc0c35e13a9d5141e95b641af0f81c8f (origin/master, origin/HEAD, master) Merge: c7549cce 03db3093 Author: Márk Sági-Kazár <sagikazarmark@users.noreply.github.com> Date: Thu Apr 8 17:50:52 2021 +0200 Merge pull request #2072 from dexidp/dependency-updates ここから $ git commit --force-with-lease ... を実行して無事にDCOのエラーはなくなりました。 以上

背景 結構な頻度でGitの環境構築するので備忘録として... 本題 Git,GitHub ・下記をメインに参考に進める 新しいMacでGitHubのSSH接続をするまでの環境構築手順 - Qiita ・SSHに関しては下記の記事がお気に入りです お前らのSSH Keysの作り方は間違っている - Qiita Sourcetree 下記を参考に進める MacでのSourcetreeセットアップとGitHub連携とプルリクエスト作成までの手順 - Qiita .gitignore 下記で言語・FWごとにgitignoreを生成可能 gitignore.io 以上となります！記事を書いてくださった皆さんありがとうございました！

fatal: Not a git repository (or any parent up to mount parent /home/foobar) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). みたいな出力があれば以下の方法で解決できます。 bar.gitを開こうとしていたという前提だと、 $ mkdir bar $ cd bar $ git init $ git remote add origin git@github.com:foo/bar.git で解決されます。 お試しあれ。 appendix: GIT_DISCOVERY_ACROSS_FILESYSTEM not set https://stackoverflow.com/questions/16853624/git-discovery-across-filesystem-not-set/17975161#17975161

※勉強メモです。 バージョン管理の一連の流れ 1.リポジトリの作成(初期化) ~/environmen下にフォルダを作成・移動 git initリポジトリ作成 2.ファイルの変更 git status状況確認(変更ﾌｧｲﾙ赤に) 3.ファイルの変更箇所のステージ git add ファイル名ファイル選択 (アスタリスクで全選択) git status状況確認(緑になる) 4.コミット git commit -m "コメント" git logコミット履歴確認 差分の確認git diff ・GitHubへリポジトリを反映させる流れ 1.GitHubにリモートリポジトリを作成する GitHubにログインし、New repositoryで作成 2.ローカルリポジトリにリモートリポジトリを登録する git remote add origin https://github.com/ユーザ名/リポジトリ名.git git remote -vリモリポの確認 3.ローカルリポジトリのブランチ名を変更する git branch -M main 4.登録したリモートリポジトリへプッシュする git push origin main 5.GitHubのリモートリポジトリにプッシュされたか確認する GitHubにて確認

Gitの仕組み Gitは差分ではなくスナップショットとして保存している（高速化が目的）。コミットを辿る事で以前の状態に戻せる ローカルは3つのエリアに分かれている ワークツリー（ファイルを変更する作業場） ステージ（コミットする準備） リポジトリ（スナップショットを記録） Gitのデータ構造（データの管理の仕方） ・リポジトリに「圧縮ファイル」「ツリーファイル」「コミットファイル」を作成する事でデータ保存をしている。 Gitではこれらのファイルを「Gitオブジェクト」と呼ぶ。Gitオブジェクトは「.git/objects」ディレクトリの下に保存される。 ・コミットが直前のコミットを持つことで変更履歴を辿ることができる ・Gitの本質はデータを圧縮して、スナップショットで保存している ・Gitのコマンドは、そのデータに対して色々な操作をしている blobオブジェクト（圧縮ファイル） ステージングする時に作成されるファイル。 ファイルの中身を圧縮したもの。実際はハッシュIDで表す。 圧縮ファイルは構造や名前を持たない treeオブジェクト（ツリーファイル） コミットする時に作成されるファイル。 ファイル名と圧縮ファイルを組み合わせを保存するもの 厳密にはツリーファイルの中にツリーファイルが追加されている ツリーファイルは圧縮ファイルに構造を与えるためのもの commitオブジェクト（コミットファイル） いつ、誰が、何を、何のために変更したかを記録する コミットした時点でのtreeが保存されている 親コミットを保存している(parnet) 作成者、日付、メールアドレス、コミットメッセージが記録される ローカルリポジトリの新規作成 $ git init　　　　#.gitディレクトリが作成される .gitディレクトリの中身 ・リポジトリ（圧縮ファイル、ツリーファイル、コミットファイル） ・インデックスファイル ・設定ファイル 他の人が既に作成しているプロジェクトから始める場合（GitHub上のプロジェクト） 1.Gitリポジトリのコピーを作成 $ git clone リポジトリ名（GitHub上のURL） リモートからローカルに複製 ワークツリー　→ 　ファイルを複製 リポジトリ　→　.gitを複製 2.変更をステージに追加する $ git add　ファイル名 $ git add ディレクトリ名 $ git add . 圧縮ファイルA（リポジトリ） index.htmlhファイル内容を圧縮したもの インデックス（ステージ） index.html 圧縮ファイルA 3.変更を記録する（コミット） $ git commit $ git commit -m "メッセージ" $ git commit -v　　　　　　　　＃変更差分を表示できる コミットメッセージの書き方 １行目　変更内容の要約 ２行目　空行 ３行目　変更した理由 変更内容の要点と理由を１行で簡潔に書く 4.現在の変更状況を確認する $ git status 変更途中のファイルなどを間違ってあげないように、どのファイルが変更されたのか確認してからコミットやステージに追加する癖をつける 5.何を変更したのか確認する $ git diff　　　　　＃git add前の差分（ワークツリー⇆ステージ） $ git diff ファル名　＃個別ファイル index.html　⇆　インデックス $ git diff --staged　＃git add後の差分（ステージ⇆リポジトリ） インデックス　⇆　ツリー１　＋　コミット１ コミットやステージに追加する前にどんな変更したかを確認してから追加する癖をつける 6.変更履歴を確認する $ git log $ git log --oneline　＃１行で表示する $ git log -p ファイル名　＃フィアルの変更差分を表示 $ git log -n コミット数　＃表示するコミット数を指定 履歴は最新の順から表示する 7.ファイルの削除を記録する ワークツリーとリポジトリからも削除 $ git rm ファイル名　　　　　＃ファイルごと削除 $ git rm -r ディレクトリ　　　＃ディレクトリごと削除 リポジトリのみ削除 $ git rm --cached ファイル名　＃ファイルを残したい時 元の状態に戻したい $ git reset HEAD ファイル名 $ git checkout ファイル名 8.ファイルの移動/変更を記録する $ git mv 旧ファイル名　新ファイル名 9.GitHubにプッシュする（コミットをリモートリポジトリに上げる） リモートリポジトリを新規登録 $ git remote add origin GitHub上のリポジトリ（URL） リモtーリポジトリへ送信 $ git push リモート名　ブランチ名 $ git push origin master $ git push -u origin master　　＃-u：次回以降git pushのみで送信できるオプション 10.コマンドにエイリアスをつける（コマンドを簡略化する） $ git config --global alias.ci commit　＃ciコマンドに変換 $ git config --global alias.st status　　＃stコマンドに変換 $ git config --global alias.br branch　　＃brコマンドに変換 $ git config --global alias.co checkout　＃coコマンドに変換 git configは設定を変更するコマンド --globalをつけるとP C全体の設定になる ~/.gitconfig ~/.config/git/config --gloabalをつけないと特定のプロジェクトでしか使えない 今の自分のプロジェクト/.git/config 11.バージョン管理したくないファイルを無視するやり方 バージョン管理したくないファイル パスワードなどの機密情報 チームの開発で必要のないファイル（自動生成されるファイルやキャッシュなど） .gitignoreファイルを作成、記述で指定する ＃から始まる行はコメントとみなされ無視される 指定したファイルを除外（index.html） ルートディレクトリを指定（/root.html） ディレクトリ以下を除外（dir/） /以外の文字列にマッチ（/*/*.css） .gitignoreファイル自体はコミットしても問題ない 12.変更を元に戻す ワークツリーのファイルを元の状態に戻す（ワークツリー←ステージ） $ git checkout -- ファイル名 $ git checkout -- ディレクトリ名 4 git checkout -- . 　　　　　　　　＃全変更を取り消す . ファイル全てを指定 --　ブランチ名とファイル名が被った時に、どちらを指しているかGitがわからなくなるのを避けるために明示する ステージの内容をワークツリーと同じにする作業が行われている ステージに追加した変更を元に戻す（ステージ←リポジトリ） $ git reset HEAD ファイル名 $ git reset HEAD ディレクトリ名 $ git reset HEAD . ステージの変更を取り消すのみで、ワークツリーには影響を与えない 内部ではリポジトリから最新のコミット情報を引っ張りステージを上書きする HEAD　今いるブランチの最新のコミットを明示する reset　リセット、上書きすると明示する 直前のコミットをやり直す $ git commit --amend 注意！　リモートリポジトリにpushしたコミットはやり直したらダメ！ このコマンドの有効範囲はcommitする前のデータであることが条件！ 例） リポジトリ（コミットした） やり直したい ワークツリーで修正 ステージに追加（$ git add） 直前のコミットを修正（$ git commit --amend） 13.リモートの情報を確認する $ git remote　　＃リモート名を表示 $ git remote -v　＃対応するURLを表示 設定しているリモートリポジトリの情報を表示する 14.リモートリポジトリの新規追加 $ git remote add リモート名 リモートURL リモート名は省略して追加できる 15.リモートから情報を取得する $ git fetch リモート名 リモートリポジトリ　→　ローカルリポジトリ(remotes/リモート名/ブランチ名) ワークツリーには反映されない（$ git merge で反映できる） 備考） $ git branch -a 取得した情報（ブランチ）を確認できる $ git checkout remotes/リモート名/ブランチ名 ブランチ名を指定してワークツリーを切り替える $ git merge リモート名/ブランチ名 統合したいブランチ名に移動してからブランチ名を取得して実行 git fetchがおすすめ 16.リモートから情報を取得する（pull) $ git pull リモート名 ブランチ名 $ git pull リモートリポジトリ　→　ローカルリポジトリ　→　ワークツリー pullの注意点！ pullは、現在いるブランチに対してマージまでを一括まで行うコマンド。謝って別のブランチを上書きする危険性がる。 17.リモートの情報を詳しく確認する $ git remote show リモート名 表示される情報 ・fetchとpushのURL ・リモートブランチ ・git pullの挙動 ・git pushの挙動 18.リモートを変更・削除する 変更 $ git remote nename 旧リモート名 新リモート名 削除 $ git remote rm リモート名 19.ブランチとマージ ブランチ 並行しながら複数機能を開発するためのもの ブランチの仕組み Gitのデータの持ち方：リポジト　→　圧縮ファイルA、ツリー１、コミット１ コミット　→　スナップショットを記録している スナップショットを時系列順に記録している コミットごとに直前の親コミットを記録している ブランチとはコミットを指したポインタ HEAD　＝　自分が今作業しているブランチのこと ブランチの中身 最新のコミットIDが格納 HEADの中身 ブランチ名を格納 ブランチを新規作成 $ git branch ブランチ名 ブランチの一覧を表示する $ git branch $ git branch -a　＃全てのブランチを表示 ブランチを切り替える $ git checkout 既存のブランチ名 $ git checkout -b 新ブランチ名　＃-b: ブランチを新規作成して切り替える 変更履歴をマージする $ git merge ブランチ名 $ git merge リモート名/ブランチ名 マージには３種類ある Fast Forward: 早送りになるマージ Auto Merge: 基本的なマージ コンフリクト: 同じファイルの同じ行に対して異なる編集を行なった時 どちらを優先していいかわからない時にコンフリクトが発生する 例） <<<<<<<<HEAD HEADの変更部分が表示 ============= 別のブランチの変更部分が表示 >>>>>>>>>他ブランチ名 コンフリクト関連の事故が起きにくい運用ルール 複数人で同じファイルを変更しない pullやmergeする前に変更中の状態をなくしておく（commitやstashをする） pullする時はpullするブランチに移動してからpullする コンフリクトしても慌てない ブランチ名を変更したい $ git branch -m ブランチ名 ブランチを削除したい $ git branch -d ブランチ名　＃マージされていない変更が残っている場合は削除されない $ git branch -D ブランチ名　＃強制削除する ブランチを利用した開発の流れ masterブランチ　→　リリース用ブランチ 開発　→　トピックブランチを作成して進める リモートブランチとは リモートのブランチ GitHubを利用した開発手順 プルリクエスト 自分の変更したコードをリポジトリに取り込んでもらえるように依頼する機能 プルリクエストの流れ ワークツリー　→　ローカルリポジトリ 1 masterブランチを最新に更新 ($ git pull リモート名 ブランチ名) 2 ブランチを作成($ git checkout -b 新ブランチ名) 3 ファイルを変更($ git add ファイル名) 4 変更をコミット($ git commit) ローカル　→　リモートリポジトリ（GitHub) 5 GitHubへプッシュ($ git push リモート名 ブランチ名) 6 プルリクエストを送る (GitHub上でリクエストを指定) 7 コードレビューをお願い(GitHub上でコードレビューを指定) 8 プルリクエストをマージ 9 ブランチの削除 GitHub Flowの流れ GitHub社のワークフロー master -> branch -> プルリクエスト ->master… 1 masterブランチからブランチを作成 2 ファイルを変更しコミット 3 同名のブランチをGitHubへプッシュ 4 プルリクエストを送る 5 コードレビューしmasterブランチにマージ 6 masterブランチをデプロイ GitHub Flowを実践する上でのポイント（ 開発フローをシンプルに保ちたい） masterブランチは常にデプロイできる状態に保つ 新開発はmasterブランチから新しいブランチを作成してスタート 作成した新しいブランチ上で作業しコミットする 定期的にpushする masterにマージするためにプルリクエストを使う 必ずレビューを受ける masterブランチにマージしたらすぐにデプロイする （テストとデプロイ作業は自動化） リベースで変更履歴を修正する リベースとは 変更を統合する際に、履歴（分岐）を綺麗に整えるために使うもの。 $ git rebase ブランチ名 ブランチの起点となるコミットを別のコミットに移動する マージとの違い リベース：　分岐したコミットを残さずにポインタごと移動する マージ：　分岐したコミットを残したまま新コミットを生成 リベースの注意点 GitHubにプッシュしたコミットをリベースするのはNG！ 強制的に上書きしてしまう$git push -fはもちろん絶対NG！ マージかリベースかの考え方 マージ メリット：コンフリクトの解決が比較的簡単 デメリット：マージコミットがたくさんあると履歴が複雑化する 結論：作業の履歴を残したい時はマージ リベース メリット：履歴をきれいに保つことができる デメリット：コンフリクトの解決が若干面倒（各コミットに解消が必要） 結論：履歴をきれいにしたい場合はリベース 結論 プッシュしていないローカルの変更　→ 　リベース プッシュしているローカルの変更　→ マージ コンフリクトしそう（チーム開発やプルリクエストで判断）　→　マージ プルの設定をリベースに変更する プルのマージ型 $ git pull リモート名 ブランチ名 マージコミットが残るからマージした記録を残したい場合に使う プルのリベース型 $ git pull --rebase リモート名 ブランチ名 マージコミットが残らないからGitHubの内容を取得したい時だけに--rebaseを使う リベースで変更履歴を修正する コミットをきれいに整えてからPushしたい時は履歴を書き換える ※GitHubni Pushしていないコミットに限られる 直前のコミットをやり直す $ git commit --amend リモートリポジトリにPushしたコミットはやり直したらダメ！ 複数のコミットをやり直す ①-I によって対話的リベースモードになる $ git rebase -i コミットID $ git rebase -i HEAD~3 HEAD = 最新のコミット HEAD~1 = HEAD^2　＝　HEADの親コミット #表示（HEAD~3までを指定部分） pick gh21f6d ヘッダー修正 pick 193054e ファイル追加 pick 84gha0d README修正 コミットエディッターで表示される 履歴は古い順に表示される ②やり直したいcommitをeditする edit gh21f6d ヘッダー修正 ③やり直しを実行 $ git commit --amend ④次のコミットへ進む（リベース完了） $ git rebase --continue コミットを並び替える、削除する $ git rebase -i HEAD~3 #表示 pick gh21f6d ヘッダー修正 pick 193054e ファイル追加 pick 84gha0d README修正 コミットエディッタ ①84gha0dのコミット（行）を消す ②193054eを先に適用する（手動） コミットをまとめる $ git rebase -I HEAD~3 コミットエディッタ squash 193054e ファイル追加 squash 84gha0d README修正 コミットを分割 $ git rebase -I HEAD~3 #表示 pick gh21f6d ヘッダー修正 pick 193054e ファイル追加 edit 84gha0d READMEとindex修正 $ git reset HEAD^　　　　#コミットを取り消してステージしていない状態まで戻す $ git add README $ git commit -m 'README修正' $ git add index.html $ git commit -m 'index.html修正' $ git rebase --continue タグの一覧 $ git tag　＃全てのタグを表示する $ git tag -l "201705"　＃パターンを指定してタグを表示 コミットを参照し易くするためのもの。わかりやすい名前をつけるのがタグ。 リリースポイントに使う。 タグを作成する 注釈付き版(annotated) $ git tag -a タグ名 -m "メッセージ" -aオプション：注釈付き 名前、コメント、署名をつけられる 軽量版（lightweight） $ git tag タグ名 $ git tag タグ名 コミット名　＃後からタグをつける 名前のみつけられる タグのデータ表示する $ git show タグ名 タグのデータと関連づけられたコミットを表示する #表示 タグ付けした人の情報 タグ付けした日時 注釈メッセージ コミット タグをリモートリポジトリに送信するやり方 $ git push リモート名 タグ名 $ git push リモート名 --tags　＃タグを一斉送信する --tagsオプション：ローカルにあってリモートに存在しないタグを送信する 作業を一時避難する 作業が途中でコミットしたくないけど、別のブランチで作業しないといけない時に使う。 $ git stash $ git stash save stashという場所に一時保管する。 一時避難した作業を確認する $ git stash list 非難した作業を復元する $ git stash apply　　　　＃最新の作業を復元する $ git stash apply --index　＃ステージの状況も復元する $git stash apply スタッシュ名　＃特定の作業を復元する スタッシュ名はgit stash listで確認できる 一時避難した行を削除する $ git stash drop　＃最新の作業を削除する $ git stash drop スタッシュ名　＃特定の作業を削除する $ git stash clear　＃全作業を削除する 参考元 もう怖くないGit！チーム開発で必要なGitを完全マスター/山浦清透

Gitって何が便利なのか Gitとはバージョン管理システムのことである。 最新のファイルが分からなくなるのを防ぐ 誰が、いつ、何のために変更したのかを残せる Gitの仕組み 変更履歴を時系列順にメッセージを残して記録できる 誰が、いつ、何のために変更したのかを遡れる 開発の流れ 1.ファイルの変更をする 2.個人リポジトリに変更履歴を記録(commit) 3.共有リポジトリに変更を共有(push) 複数人での開発の流れ 1.情報を取得する(pull) 2.開発の流れ（変更→commit→push) GitHubとは Gitリポジトリのホスティングサービス（コードを預ける場所を提供） ソーシャルコーディングの場でもあり、オープンソースの開発がしやすくなった経緯がある GitHubの特徴 プルリクエストによる複数人開発がしやすい（コードレビューがしやすい）。他のチームのソフトウェアが見える事。 プルリクエストとは 変更を上げる際にリクエストを送り、取り込みの可否を依頼、修正改善の確認をするもの Gitリポジトリのホスティングサービス Bitbucket（個人開発向き） 非公開リポジトリも無料作成 公開不可のプロジェクト向き 人数制限あり、２〜３人までなら無料 GitHub 非公開リポジトリは有料 公開リポジトリは無料 Gitのバージョン確認 $ git version 初期設定 $ git config --global user.name "GitHubのユーザー名" $ git config --gloabal user.email GitHub登録時のメールアドレス GitHubにリモートリポジトリを作成 $ git remote add origin https://github.com/~.git(リモートリポジトリのURL) ローカルリポジトリの新規作成 $ git init .gitディレクトリが作成。ここでバージョン管理を行う 基本的なワークフロー 1.ファイルの変更をステージングエリアへ追加 $ git add ファイル名　＃個別ファイルの追加 $ git add . ＃全てのファイルを追加 2.ローカルリポジトリにコミット $ git commit ＃一つの作業に１コミット推奨 3.リモートリポジトリにプッシュ $ git push -u origin master origin　リモートリポジトリのデフォルト名 master　ローカルリポジトリのデフォルトのブランチ名 ステージングエリアとは 複数ファイルを変更した時にコミットするファイルを選択するためのもの コミットメッセージの書き方 １行目：　変更内容の要約 ２行目：　空行 ３行目：　変更した理由 リポジトリの状態を確認 $ git status 赤字：　変更されたファイル 緑字：　ステージングエリアにあるファイル 変更差分の表示 ＄Git Commit -v コミットの履歴を確認 $ git log 削除したファイルをステージングエリアに追加 $ git rm ファイル名 コミットの変更履歴を確認 $ git log --oneline 　　　#１行で表示する $ git log -p ファイル名　＃ファイルの差分を表示する 4 git log -n 3 　　　　　＃表示するログ数を指定 commit　ハッシュ値 Author 　書いた人の名前とメールアドレス Date　変更した日付 ここにコミットメッセージが表示 変更差分を確認 $ git diff　　　　＃ステージとの差分 $ git diff HEAD　#ステージとコミットの差分 differenceの略 バージョン管理をしたくないファイルをGitの管理から外す .gitignoreファイルに指定する 自動生成されるファイル パスワードが記載されているファイルなど .gitignoreファイルの書き方 #から始まる行はコメントとみなされるため無視される 指定したファイルを除外　　index.html ルートディレクトリを指定　/root.html ディレクトリ以下を除外　dir/ 既にコミットしている場合 $ git rm ファイル名　　　　＃ファイルも一緒に削除 $ git rm -r ディレクトリ名　＃ディレクトリも一緒に削除 $ git rm --cached ファイル名　＃ファイルは残す（gitの管理だけ外す） 元の状態に戻す $ git reset HEAD ファイル名 $ git checkout ファイル名 参考元 Git: 初めてのGitとGitHub/山浦清透

忙しい人へ git -c 'versionsort.suffix=-' ls-remote --tags --sort='v:refname' https://chromium.googlesource.com/chromium/src これでタグとコミットハッシュの両方が出るので、適切にこねくり回せばバージョン一覧が出る。 背景 youtube-dlには、UA偽装のためにChromeのバージョン一覧を持っています。ですが、見て頂いても分かる通り、バージョンが68〜76?と非常に古いのです。1 Windows版のChromeであれば自動更新機能があり、この機能によって古いバージョンのChromeは比較的早く置き換えられていきます。それを考えれば、今更60番台のChromeのUAが来たら即ブロックされかねません。こういったこともあり、バージョン一覧を新しいものに交換しようと考えました。 やったこと 最初、Chromiumのリポジトリをcloneしようとしたのですが、リポジトリ全部cloneすると23 GBにもなります。大きすぎます。2 cloneすればgit tag -lで全部列挙できますが、大きすぎるので諦めました。 結論 少し調べていると、cloneしないでtag一覧を取得する方法がありました。 こんなコマンドになります。 git -c 'versionsort.suffix=-' ls-remote --tags --sort='v:refname' https://chromium.googlesource.com/chromium/src というかこれってgit ls-remoteで出来たんですね... 出力の一例は次のようになります。 $ git -c 'versionsort.suffix=-' ls-remote --tags --sort='v:refname' https://chromium.googlesource.com/chromium/src 05197078e4761dde56f8dc8884050bf862344425 refs/tags/3.0.195.25 75894f416826f37475ca17e92f5853b0f84ac3ee refs/tags/3.0.195.27 各行がtag一個を指しており、コミットハッシュ\tタグ参照名の形式で表示されます。3 これを適切に解析すれば、23 GBを消費すること無くtag一覧を取得できます。 確かにバージョンは古いですが、これらのChromeが必要という訳ではありません。よって、これを原因として何らかの脆弱性に直結するようなことはありません。 ↩ GitHub Actionsで自動化したい場合、GitHub-hosted runnerでは入り切りません。 ↩ このため、出力をそのままTSVとして使うことも可能です。知らんけど。 ↩

初書：2021/03/29 前書き gitを使ってgithubと連携する機会がついに来てしまったので、最低限使うに当たってやったことをメモ。 前提 ・gitの大体の動き（ステージとかコミットとか…）は理解してる 連携 githubとssh接続するためのもの。 注意：これがないと接続出来ないのだが、この記事を書くまでに端末を再起動し、ターミナルのログが消えていたので、 他のサイトを見ながら% history 1で確認しているので、ここは他のサイトを見た方がいいかもしれない。 まずは/Users/xxxxxxx/に移動し、.sshディレクトリが存在するか確認する 存在していない場合は、% mkdir .ssh/で作成し、% cd .ssh/で入る。 その後、sshのキーを作成する (※既に.sshディレクトリが存在する場合は以下は飛ばす。また他のキーを使用したい場合は他のサイトを参考にすること) % ssh-keygen これで、id_rsaとid_rsa.pubファイルが作成されるので、id_rsa.pubファイルの中身をコピー 次にgithubへログインし、設定画面へ SSH and GPG keysという画面へいき、右上のNew SSH Keyをクリック Titleは自分がわかりやすい内容に Keyには先ほどコピーしたものをペーストし、Add SHH Key 再びターミナルに戻り、% ssh -T git@github.comを実行。 % ssh -T git@github.com Hi xxxxxxx! You've successfully authenticated, but GitHub does not provide shell access. このように表示されれば完了。 注意箇所ここまで 既にあるgithubのリポジドリをcloneする cloneしたいリポジドリのページへ行き、右上のコードからcloneのsshを選択 git@github.com:から始まる文字列をコピー ターミナルに戻り、以下を実行 % git clone コピーした文字列 これで、リポジドリのcloneをローカルにDLすることができた。 自身の情報を設定する 複数人で作業する場合は誰がどのコミットをしたかをメモする必要がある。 まあ1人でもgitを使う場合はメモしないといけないが。 なのでその登録をする % git config --local core.editor "code -w" % git config --local user.name "NAME" % git config --local user.email "email" --localはそのディレクトリのgitにのみ影響する設定 端末の設定を変える場合は--localを--globalに変更する １行ずつ説明 １つ目はメインエディタの設定。codeはvscode。 ちなみに-wは付けないと後々面倒な事になるのであらかじめ指定しておく。 git - Aborting commit due to empty commit message - Stack Overflow ２つ目は名前。"NAME"は自身の名前に変更する ３つ目はメールアドレス。"email"は自身のメールアドレスに変更する 変更をcommitする commitする前に、まずはリポジドリの中身を更新する必要がある。 % git pull origin main ちなみにpullって何？というのはこの辺を参考にした。 【初心者向け】git fetch、git merge、git pullの違いについて - Qiita 次にステージング（git add）を行う。 % git add -A 後ろの-Aはオプションで、全ての変更・追加・削除をステージングする。 一部だけを指定する場合は、-Aのところをファイル名にすればいい。 git add -u と git add -A と git add . の違い | note.nkmk.me ステージングが終われば次はコミットする。 % git commit このあとconfig core.editorで指定したエディタでCOMMIT_EDITMSGが開くので、コミットメッセージを記述。 一々開くのが面倒な場合は、-m "message"をオプションでつけると、message部分がコミットメッセージとして記述される。 最後に今回はgithubで共有しているので、github側にコミットを送信する。 % git push origin main 終わりに VSCode使ってると拡張機能使った方が直感的でわかりやすい気がしなくもないが、 マウスカーソルを触らなくても扱える点では覚えておいて損しないかもしれない。。。。 参考サイト GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ - Qiita