[Git] blameコマンドで特定の行がいつ変更されたのか調べて、バグの混入を見つける - YoheiM .NET
こんにちは、仕事でもプライベートでもGitにお世話になっている@yoheiMuneです。 今日は、git blameというコマンドを使って、特定の行がいつ誰のコミットで変更されたのかを調べる方法をブログに書きたいと思います。「これいつの間に追加されたんだろう〜」というのを調べるのに非常に便利です。 目次 git blameの使いどころ git blameを使うことで、各行ごとにそれが変更された最終コミットを知ることができます。その機能を利用することで以下のようなユースケースに対応できます。 この行バグってるんだけど、誰のいつのコミットで追加されたんだ？ このメソッドの引数がいつの間にか拡張されているんだけど、誰がどんな目的で拡張したんだろう？ こんな感じで、特定の行の実装内容が気になった時に、過去を遡ることができます。 git blameコマンド 基本編 早速ですがgit blameコマン
![[Git] blameコマンドで特定の行がいつ変更されたのか調べて、バグの混入を見つける - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/b69d8634399a6bc273b1d19577ba1f9e07532423/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F444.jpg)
【Git】過去のファイルを入手する方法メモ
やりたいこと ファイルをバックアップする用途としても Git を使用しております。 さて、いよいよ過去のファイルをちょっと見たい、という時がやってまいりました。 テキストではなくバイナリファイルなため (エクセルや PDF) ファイルを直接取り出したいのです。 はて？どうしたらよいかしら？ ポイント git checkout [commit] を使用して作業ディレクトリ全体を過去の状態に戻す。 Git の過去ファイルを取得する手順 git branch --contains=HEAD で現在のブランチを確認 git log で戻りたいコミットを確認 git checkout [commit] で、作業ディレクトリが指定したコミットの状態になる。 必要なファイルをコピーする。 git checkout [branch] で最初の元の状態に戻る。 おわりに 次のページが参考になりました。ありが
matzryo’s diary
まとめ キーボードが壊れたので新調した。 静電容量無節点方式のキーボードで、かつ、かわいいキーキャップを使いたかった。 キーボードはNiz Atom68を購入。キーキャップをMDA Big Boneに交換した。見た目がかわいく満足している。 経緯 (以下、購入までのグダグダした心情。あまり有益なことは書いていないと思う。私は他人のこういう心情を綴ったブログ記事を読むのが好きだ。同好の士のために記す。) 従来、REALFORCE 87USWを愛用していた。英語配列、静音、アイボリーのモデルだ。見た目は以下の通り。 アロマオイルをぶっかけてしまい、使い物にならなくなってしまった。 上記REALFORCEは気に入っていた。再度購入しようとも考えたのだが、REALFORCEは2017年にモデルチェンジしている。細かなデザインが私の好みではなかったので、他を検討することにした。 私の希望は以下の通り
Guitar - マルチプラットフォームで動作するGitクライアント MOONGIFT
Gitを全く使っていないという人は減っていると思いますが、その使い方は異なるでしょう。ターミナルでコマンドを打っている人が一番多いのではないでしょうか。GitHubの作っているクライアントを使っている人もいるでしょう。 シンプルなGitクライアントが欲しいと言う方はGuitarを使ってみてはいかがでしょう。 Guitarの使い方 ローカルのリポジトリを開いたところです。ログが可視化されます。 ファイルの差分も確認できます。 .gitignoreの編集もできます。 リモートの設定。 アプリケーション全体の設定です。 Guitarはシンプルなインタフェースで、必要な機能が絞り込まれています。Gitリポジトリを操作する上では十分な機能が揃っているでしょう。ターミナルを開いたり、ファイルをローカルで開いたりすることもできるので、Gitを使った開発のお供に良さそうです。 GuitarはC++製のオー
とりあえずのGitメモ - Qiita
git revert commit番号でcommit番号のgit commitを取り消します。 あとはgit add --all して git pull + git pushでrevertをpushして完了。 git checkout commit番号 ファイル名 でファイルを復元。コミット番号を入れない場合は自分が作業する前の最新の状態で復元。 commit の コメントから出るときはCtrl + C esc + :wqでvimから出る 何はなくともgit pullから git pull -> git add --all -> git commit -m'コメント' -> git push 差分チェック
リモートで消されたブランチが手元で残ってしまう件を解消する - Qiita
よそからcloneしてきたリポジトリでは、remotes/origin/xxxという名前でoriginのブランチが参照される。 だが、他の人がhogeブランチを削除してoriginにpushしても、既にそのブランチが手元にある人のローカルリポジトリからは普通にpullしても消えてくれない。 そういった既にリモートで削除されているブランチを消したい場合は、以下のどちらかの操作を実行すればちゃんと消えてくれる。 git fetchもしくはgit pullにpruneオプションをつける --pruneオプションをつけると、fetchやpullする際に自動的にリモートで削除されているリモートブランチを削除してくれる。
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
【git】git addを取り消す - tweeeetyのぶろぐ的めも
はじめに git addを取り消すメモ。 ほとんど手順メモ程度な感じ＋他記事で使うスニペット記事。 とはいえ、数あるgit便利コマンドの中で毎回使うものではないけど いざって時に役立つ、もしくは、困るのは取り消し系のコマンドですよね。 補足 他の取り消しもぱっと見たい自分用にまとめたので参考までに。 【git】add、commit、push、merge、pull request、merge pull requestの取り消し アジェンダ git resetでgit addを取り消す git rmでgit addを取り消す 1. git resetでgit addを取り消す git resetでgit addを取り消します。 addを取り消すというかステージングにあがっているものを取り消すといったほうが良いでしょうか。 addしたファイルを取り消す $ git reset HEAD [ファイ
git-checkout(1)
git checkout [-q] [-f] [-m] [<branch>] git checkout [-q] [-f] [-m] --detach [<branch>] git checkout [-q] [-f] [-m] [--detach] <commit> git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>… git checkout [-p|--patch] [<tree-ish>] [--] [<paths>…] ワーキングツリー内のファイルを、インデックスまたは指定したツリーの バージョンにマッチする内容に更新し
Gitプッシュでブランチごとにステージング環境生成or本番反映させる - Qiita
概要 「masterをプッシュで本番反映」をやっている記事はいくつかあったものの、ブランチごとに自動でステージング（テスト環境）が作られるような仕組みは見当たらなかったので書いてみる。 マージ未定の実験的なブランチをWeb上で確認したり、ローカル環境のないディレクターやデザイナーに作業ブランチの内容を確認してもらう際に役に立つはず。 Gitフック経由のサイト更新はFTPもサーバーへのログインも必要なく、ただpushするだけなので非常に便利だと思う。 ※以下、ある程度のサーバーサイドの知識を要する説明になっているので注意 最終的に実装する機能 masterをリモートリポジトリにpushすると、masterの内容が本番サイトであるhttp://プロジェクト名.com/に取り込まれる。 hogeというブランチを切ってプッシュすると、http://hoge.プロジェクト名.com/というhogeブ
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
git rebase -iの時に役立つプラグイン - Qiita
はじめに 以前、と言っても結構前ですが、タイトルにあるようなgit rebase -iの時に役に立つVimプラグインというのを作ったので、それを紹介したいと思います。 動機 僕の所属している開発チームでは、バージョン管理システムにgitを使用しています。 gitは広く知られている通り、分散バージョン管理システムと呼ばれているものの一つです。その特徴と言っていいのかわからないですが、gitを利用すると、手元でのソースコードの変更を、細かい単位でローカルのリポジトリにどんどんコミットしておき、それを適当なタイミングでコミット履歴を改変して内容を整理してから、チームで共有しているリポジトリに状態を同期させるようなことができます。 git rebaseとは、そのようにコミット履歴を改変するときに使用するコマンドです。 git rebaseコマンド、特に-iというオプションを付けたものは、コミットの
[Git] SourceTreeで競合を解決する方法 - Qiita
サンプルですが下の方(相手のコード)を適用したい場合は以下のとおりに実行します。 1. ファイルを右クリック 2. 競合解決にマウスをあてる 3. "相手の変更を使って解決"をクリック 結果は以下の通りです。 以上 SourceTreeで競合を解決する方法でした。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
![[Git] SourceTreeで競合を解決する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/c8e70839b5f26cab12f0c47798157b3f14087818/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCR2l0JTVEJTIwU291cmNlVHJlZSVFMyU4MSVBNyVFNyVBQiVCNiVFNSU5MCU4OCVFMyU4MiU5MiVFOCVBNyVBMyVFNiVCMSVCQSVFMyU4MSU5OSVFMyU4MiU4QiVFNiU5NiVCOSVFNiVCMyU5NSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZTA1MGYxMjYxNjZlZWJkYWZjZDYzZWE2OWU0YzBkMWI%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQweW1peWFtYWUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWE5MTJiNGVlZTAwYzAwMGJmNmI3YjEwYzZiMTJlMTkw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db080f37f1ee65444861edbeacf473063)
Git + Bitbucketで無料privateリポジトリ作る - Qiita
先日Githubから7$/月でprivateリポジトリ作り放題なプランが発表されたけど、それでもまだGithubでは無料でprivateリポジトリを作れないYO。 なのでとりあえずGitがよく分かっていない自分でもできたGit + Bitbucketで無料privateリポジトリを作成した際の備忘録。 あ、環境はWindows8.1でやりました。 ①Bitbucketでアカウント作り、個人アカウント or チームのリポジトリ作る https://bitbucket.org/ ②Git for windowsのダウンロード＆インストール https://git-for-windows.github.io/ ③プロキシ環境の場合は以下を参考にプロキシ設定を行う http://qiita.com/hidetzu/items/c2db95613ba594a2ef25 ④プロジェクトにしたいフォルダ
GitHubでマージ済のプルリクをrevertした後に引き続きrevertされたブランチで作業を続行したい時 - Qiita
GitHub上でプルリクをマージした後に、まだマージできる状態では無かったと気付きrevertする事ってありませんか？ その後に問題になるのが、revertしたのはいいけど、引き続きそのrevertされたブランチで作業してまたプルリクを発行したい。という状況です。 この時に何も考えずに普通に作業を続行してプルリクを発行した場合、revertされた分の変更が失われてしまいます。 結構でかい事故に繋がる場合があるので、この時の対処方法を書きたいと思います。 前提 以下の操作を行っている。 プルリクを発行 プルリクをマージ マージ済のコミットのrevertプルリクを発行 revertプルリクをマージ ここまでの操作はGitHub上ですんなり行える。 再度revertされたブランチのプルリクを発行してみる 普通の感覚だと、また差分が復活していると思うのでプルリクが発行できそうな気分になると思います
gitで間違ってmergeしてしまったものをrevertして再度mergeするとどうなるかを検証する。 - Qiita
gitで間違ってmergeしてしまったものをrevertして再度mergeするとどうなるかを検証する。Git シナリオ 開発中のhogehogeブランチで作業中、間違ってmasterにマージしてpushしてしまった！！ masterにマージした内容をリバート＆push masterブランチでは開発を進める hogehogeブランチでは開発を進める hogehogeブランチで開発が終わったので、プルリクして、masterにマージする 誤ってマージした分までの変更内容はどうなる！？ 前準備 github上でリポジトリの作成、ファイルの追加など。 $ git clone git@github.com:mapyo/merge-revert-test.git $ cd merge-revert-test $ vim test.txt → ファイルを編集 $ cat test.txt masterの最
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git の mergetool で vimdiff を指定して Vim でマージコンフリクトを解決してみた
ブランチ切って更新してマージするまでの流れ - Qiita
gitマージのコンフリクトで片方ブランチのファイル変更内容を採用
