忘れやすい人のための git diff チートシート - Qiita
git diff は色んな場面で本当によく使うんですが、できることが多いだけに全然覚えられずに毎回調べてしまいます。 なので、場面ごとに使えるコマンドを一覧でまとめてみました。 先にワークツリーとインデックス【Gitの基本】- サルでもわかるGit入門を読んでおくと、ここに書いてある diff について理解しやすいと思います。 git pull する前にリモートとの変更点を見る git pull をする前にローカルの最新コミットと pull 先のリモートリポジトリとの変更点が見たいときはこのコマンドで見れます。 ここでいうリモート名は origin とかそういうやつです。 git push する前にリモートとの変更点を見る 上記のコマンドは、こんな感じで逆にもできます。
Gitで過去に削除したファイルを検索、復元させる方法
B! 17 0 1 0 Gitはバージョン管理システムなのでソースコードなどで 古い記述を残さないで消してしまっても後から簡単に見ることが出来るので 余計な記述をどんどん消していく事ができます。 一方消したファイルも履歴に残っていますが、 いざ探そうと思うとちょっと面倒だったりするので とりあえず残しておこう、とか思う事もあるかもしれません。 そんなことをせずにレポジトリを綺麗にしておくためにも、 過去に削除したファイルを簡単に検索、復元させられる様にしておこう、 という話し。 過去に削除したファイルの検索 過去に削除したファイルを復元する .gitconfigにaliasを書いて簡単に検索、復元出来る様にする まとめ 過去に削除したファイルの検索 git log --diff-filter=D --summary をすることで過去に削除したファイルを検索できます。 $ git log -
Git でローカルとリモート両方のブランチを削除する方法
Git でローカルとリモート両方のブランチを削除する方法 作成日 2018.08.13 Git ローカルブランチを削除する方法は割と馴染みがあるかもしれませんが, リモートブランチはどのように削除するのでしょうか? スタンダードな方法に加えて, 少し変わった方法も紹介します. Git のバージョンは 2.18.0 を前提にしています. ローカルブランチを削除する場合 ローカルブランチを削除する場合 git branch コマンドで削除することができます. マージされているブランチを削除する場合 現在チェックアウトしているブランチにマージされているローカルブランチは -d オプションで削除できます:
【git】マージしたけどやっぱりやめたい時のやり方4種類 - Qiita
20190501追記 わかりにくい文章を修正しました 「その3 パート1」の方法を追加しました 追記ここまで gitでマージ作業を始めたけど、もろもろの理由からやっぱりやめたいときのやり方3種類です。 その1 「マージしたらコンフリクトした。やっぱりやめよう。」 マージしたらコンフリクトした、コンフリクトするとは思わなかった、いったんやめよう、などといういうときです。 コンフリクトの編集をしていないときに限ります。
PHP-CS-FixerとGit フックで治安保持活動 - Qiita
こちらはJoolen Advent Calendar 2019 8日目の記事です。 カレンダーのURLはこちら Joolen Advent Calendar 2019 まえがき PHPを書いてるとコーディング規約とか守らない人出てきますよね。 私も気付かず破ってしまうことがあります。 それを防ぐためにPHP-CS-FixerとGitフックを利用して治安保持を目指します。 PHP-CS-Fixerとは コードの整形ツールと呼ばれるものです。 .php_cs.distという設定ファイルにルールを記述することで、コマンド一つでルールに沿ったコードに整形してくれます。 ルールはPHPの配列形式で設定します。 またFinderと呼ばれるものもあり、こちらを設定すると、整形して欲しくないファイルやディレクトリを指定できます。 例: return PhpCsFixer\Config::create()
[Git]コミットの取り消し、打ち消し、上書き - Qiita
を叩けばOK。 --softオプション：ワークディレクトリの内容はそのままでコミットだけを取り消したい場合に使用。 --hardオプション：コミット取り消した上でワークディレクトリの内容も書き換えたい場合に使用。 HEAD^：直前のコミットを意味する。 HEAD~{n} ：n個前のコミットを意味する。 HEAD^やHEAD~{n}の代わりにコミットのハッシュ値を書いても良い。 gitのv1.8.5からは、「HEAD」のエイリアスとして「＠」が用意されている。 HEAD~とHEAD^と@^は同じ意味。 HEAD^^^とHEAD~3とHEAD~~~とHEAD~{3}と@^^^は同じ意味。 ただしWindowsの場合はgit reset --soft "HEAD^"と、HEAD^を"で囲んでください。 git resetの詳細は、下記記事に詳しく書いているので、ぜひ参考にされてください。 ▼[g
![[Git]コミットの取り消し、打ち消し、上書き - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/da95903f8f4fb19ef9bd98812632bf19f6d8f660/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCR2l0JTVEJUUzJTgyJUIzJUUzJTgzJTlGJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgxJUFFJUU1JThGJTk2JUUzJTgyJThBJUU2JUI2JTg4JUUzJTgxJTk3JUUzJTgwJTgxJUU2JTg5JTkzJUUzJTgxJUExJUU2JUI2JTg4JUUzJTgxJTk3JUUzJTgwJTgxJUU0JUI4JThBJUU2JTlCJUI4JUUzJTgxJThEJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00NWE5NDU5NmIyMmExNDNjZGZmY2IyMTBhZjAzZDk4ZQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc2h1bnRhcm9fdGFtdXJhJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03NTIzZDczZGI1NzYyYzBhZWM5NjZlOGE1NGE3ODU5YQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Def0ad06ae63e693fb3e98fa4255fdc08)
git mergeで特定のファイルを取り込む - HPCメモ
別のブランチで修正したファイルの一部だけを取り込む必要があってぐぐってたんですが、なかなか同じシチュエーションの人が居ないようなので作業の記録を残しときます。 git mergeに特定のファイルを指定するようなオプションは無いので、ちょっと面倒ですがmerge -> 不要なファイルをreset ->commitという流れになります。 実際に使うコマンドはこんな感じです。 > git merge --no-commit -Xtheirs {mergeしたいブランチ名} > git reset HEAD {mergeしたくないファイル名} > git checkout {mergeしたくないファイル名} > git commit ぐぐるとcherry-pickでできるよ！みたいなことが書かれてるページもあったけど、cherry-pickはあくまで個別のコミットを適用するだけなので、mergeす
空のディレクトリを維持するための、 .gitkeep と .gitignore の使い分け - Qiita
空のディレクトリをコミットに含めたいときは、2つのやり方があります。.gitkeep を使う方法 と、 .gitignore をおいておく方法（例えばPHPのフレームワーク Laravel で用いられている方法）です。 空のディレクトリを保持する目的で使用する .gitignore は、たいていの場合、以下のような内容になっています。 使い分けの基準 .gitkeep と .gitignore は、「空のディレクトリにファイルが追加されたときに、そのファイルを Git での管理対象に含めたいか？」という基準で、使い分けられます。 含めたい場合は .gitkeep 、含めたくない場合は .gitignore を使います。 .gitkeep を使う基準と例 .gitkeepは、「デフォルトではファイルが存在しないけれど、ファイルが追加されたら、そのファイルを Git での管理対象にしたい」場合
GitのHEADとは何者なのか - Qiita
最初に なんとなくでも使用できるGitですが実はとても奥深く複雑な構造をしています。 そんなGitを使い始めた時ほぼ全員が思う「HEAD」とは何者なのか説明したいと思います。 また合わせて「Branchとは」「detached HEADとは」についても話します。 先に結論ファーストで話しますと 今自分が作業している場所を示すポインタ Branchとは 開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機能 detached HEADとは HEADがBranchを指していない状態のこと そして僕自身以前までブランチとはなにか聞かれた場合、下図のようなイメージを持っていました。 そしてこれは誤った認識です。 この記事はMake IT アドベントカレンダー9日目の記事として寄稿しています！ 明日は @wh1tecat が投稿する予定です。 楽しみですね（笑） Branchとは まずG
とりあえずの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 差分チェック
git pull実行時にローカルで未コミットの変更を保持する方法 | DevelopersIO
git pullを実行する際に、ローカルで未コミットの変更に対して、リモートの状態で上書きせず、ローカルでの変更を保持したい場合や、やっぱりリモートの変更で上書きしたくなった場合の対処方法についてのご紹介です。 こんにちは、CX事業本部の若槻です。 git pullを実行する際に、ローカルで未コミットの変更をリモートに反映させずローカルでだけ保持したい場合があります。 例えば、以下のようにhoge.txtの変更がローカルで行われていますが、この変更はリモートには反映したくないため、未コミットとしています。 $ cat hoge.txt ローカルでの変更 $ git fetch $ git diff remotes/origin/master diff --git a/hoge.txt b/hoge.txt index 48ee78d..e3130ae 100644 --- a/hoge.t
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
よいコミットメッセージを書くために心がけていること - くりにっき
よいコミットメッセージとはどういうものだろう？ - chiastolite’s blog に対するアンサーソングです chiastolite.hatenablog.com 必要であればWhyを補足するためのContextを書く 元エントリだとコミットメッセージの話だったけど僕はPRで実践してもいいと思います。*1 起点となるURLを明記する レビューで指摘されたのであればPRのコメントのURL issueのURL アプリケーションエラーであればSentryなどのエラートラッキングシステムのURL GitHub外のタスク管理ツール（例：redmineやBacklogやTrelloなど）に修正概要が書かれているのであればそのURL チャットのやり取りが起因ならSlackなどのパーマリンク 公式ドキュメントのURL CIがコケているのであればCIのビルドのURL チーム開発していればコミットやP
コミットメッセージを書くときに気をつけていること - アジャイルSEの憂鬱
コミットメッセージに関するブログを読んだので、自分がコミットメッセージを書くときに気にしてることを書いておく。 chiastolite.hatenablog.com sue445.hatenablog.com 基本的な話 まずは Gitのコミットメッセージの書き方 を読んでおく。 コミットメッセージは "将来の同僚のため" に書く 3ヶ月後にチームに入った人が理解できる内容 になっているのが理想。 チームメンバーが分かる内容で満足すると、暗黙的な業務知識に依存したコミットメッセージになっていることがあるので注意。 XXXを追加/変更/削除しました はダメ 油断するとこういうメッセージを書いてしまいがち。 git-diff の内容を日本語で書いただけだと意味がないので、コミットメッセージで付加価値がつくように気をつける。 コミットした後に見直す コミットした後、git show @ を実行し
git sparse checkout で clone せずに一部のサブディレクトリだけを pull/checkout する
Git は大変便利なのですが、 clone では基本的にすべてのディレクトリが同期されます。 不要なものを削除すればそれはそれで変更として追跡されてしまうので、一部のディレクトリだけを取得したい場合は sparse-checkout というテクニックを使います。 一旦 clone しない sparse checkout Git 特定のフォルダのみcloneする - Qiita 先人の情報によれば「とりあえず普通に clone する」という例が多いのですが、ファイル数が多い場合など、すべてを clone したくない場合もあります。 そのような場合は下記のようにして sparse checkout を有効にします。 空の Git リポジトリとして初期化 sparsecheckout を有効にする リモートリポジトリの URL を origin として登録 チェックアウトする対象のディレクトリを
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでよく使うコマンド一覧 - Qiita
git logのオプションと綺麗にツリー表示するためのエイリアス - Qiita
今さら聞けない人のためのGit超入門