コミットを取り消したい Node.jsでプロジェクトを始めようと思ってたら間違えて、node_modules一式もコミットしてしまった。 ヤバイヤバイ、と思ってコミットを取り消そうと思う。
zsh: no matches found: HEAD^と出たときの解決策 - Qiita
コミットを取り消したい Node.jsでプロジェクトを始めようと思ってたら間違えて、node_modules一式もコミットしてしまった。 ヤバイヤバイ、と思ってコミットを取り消そうと思う。
コミットログテンプレートにIssue番号を自動で入れる - Qiita
手元で直した修正がgithubのissueに上がっている事をうっかり忘れて、コミットログに参照を書かずコミットしてしまうことがよくありましたが、ブランチにissue番号を予め入れておくというこの記事のアイデアのおかげでミスはほぼなくなりました。 導入にあたって、git-flowの作るブランチに対応できるように修正を加えました。 #!/bin/sh if [ "$2" == "" ] ; then mv $1 $1.tmp echo "refs #`git branch | grep "*" | awk '{print $2}' | sed -e 's/.*([1-9][0-9]*).*/\1/'`" > $1 cat $1.tmp >> $1 fi 元記事では、23_issue_nameのようにブランチの先頭にissue番号を入れるようになっていましたが単に数字を持ってくるようにしています
Gitでファイルの特定行の変更履歴を追う - Qiita
> git log -L 1,10:Gemfile commit d9acf7548943f4c60be50ee43b54ce638d4d0d3a Author: kmagai Date: Sun Apr 24 18:01:22 2016 +0900 hoge -- a/Gemfile ++ b/Gemfile ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── @@ -1,6 +1,5 @@ source 'https://rubyge
大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog
ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり
Git の core.autocrlf 設定してる?
プログラムのソースコードのバージョンを管理する為に, Git を使っている方たくさんおられると思います. 僕も使ってます. 他の人とコラボレートしたことがない僕が言うのもなんですが他の人たちとコラボレートする際には .gitconfig ファイルに設定しておいたほうがいい項目があるようです. それは core.autocrlf というものです. これはソースコードの各行末の見えない文字 EOL をコントロールする為の設定です. Mac, Linux を使っている人だったら EOL は LF となります. Windows を使っている人だったら CRLF となります. このように使う OS によって使われる EOL が異なるので, 他の人たちとコラボレートするときに何も設定していないと問題になるようです. 僕は Mac を使っているので次のように設定しました. core.autocrlf=i
Conventional Commits
Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0-beta.4 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with
Git LFS で大きいサイズのバイナリファイルも Git で管理する 🚀 - Qiita
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
[git]マージ時のコンフリクトで片側の変更だけ適用する方法 - Qiita
２つのブランチをマージした際にコンフリクトしたとして、どちらかだけを全面的に適用したい場合はどうするか。 以下のように、checkout --ours と checkout --theirs を使い分ければ良い。 # ２つのブランチ間でコンフリクトしているファイル fileA.txt と fileB.txt があるとする # fileA.txt を現在チェックアウトしているブランチ側の対応に合わせる場合 $ git checkout --ours fileA.txt $ git add fileA.txt # add を忘れずに # fileB.txt をマージさせたブランチ側に合わせる場合 $ git checkout --theirs fileB.txt $ git add fileB.txt $ git commit Register as a new user and use Qi
![[git]マージ時のコンフリクトで片側の変更だけ適用する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2effa206ac1407952bbfa4f3eceeb99dfc08f40c/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCZ2l0JTVEJUUzJTgzJTlFJUUzJTgzJUJDJUUzJTgyJUI4JUU2JTk5JTgyJUUzJTgxJUFFJUUzJTgyJUIzJUUzJTgzJUIzJUUzJTgzJTk1JUUzJTgzJUFBJUUzJTgyJUFGJUUzJTgzJTg4JUUzJTgxJUE3JUU3JTg5JTg3JUU1JTgxJUI0JUUzJTgxJUFFJUU1JUE0JTg5JUU2JTlCJUI0JUUzJTgxJUEwJUUzJTgxJTkxJUU5JTgxJUE5JUU3JTk0JUE4JUUzJTgxJTk5JUUzJTgyJThCJUU2JTk2JUI5JUU2JUIzJTk1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yM2E0NWQ1NWY4OGNjMmJkMmY5MGEwOWVjNDk5OTA3Zg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbmFudGVra290YWkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWNiOTkyYjk4YjNkZGQwOWVkMTEzNTAxYTdlZmEyODQy%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D86e5296afa3a927e9fd9ccbe7aa2c1ab)
github の プルリクエスト をコマンドから直接開く - Qiita
先日以下の記事で git blame でプルリクエストを簡単に見つける方法が紹介されていました。 Kazuho's Weblog: git blameでプルリクエストの番号を表示する 運用のフェーズが始まり、新しいチームにメンバーがジョインする時など過去の経緯を調べることが必要になることがあります。こういうときにコミットログやプルリクエストを見るというのはよくあると思います。 上記の記事でプルリクエストの番号を調査したあと簡単にプルリクエストを開く方法を紹介します。 前提 hub コマンドをインストールしておきます。 github/hub: hub helps you win at git. git alias に設定し実行する git の alias を設定のため以下のコマンド実行 $ git config --global alias.openpr '!f() { hub browse
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
Takuto Wada on Twitter: "コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした"
コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした
OSSメンテに便利なgitエイリアス「git pr」 - Qiita
会社の人に教えてもらった便利なエイリアスを紹介しておきます。多分出典はこれで、作者と思われるgnarf氏に感謝です。 このエイリアスはプルリクエストを管理するためのもので、主にコードレビューやOSSのメンテナンスをする人に需要があると思われます。 インストール 次の.gitconfigをコピーするかadd-pr-alias.shを実行してください。 # for github remotes [alias] pr = "!f() { git fetch -fu ${2:-$(git remote |grep ^upstream || echo origin)} refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f" pr-clean = "!git for-each-ref refs/heads/pr/* --format='%(refnam
Git Subtree 事始め - Qiita
もうそろそろいい加減git subtreeも使いこなせないとまずいな、と思っていたところなので とりあえずわかる範囲で調べてまとめてみた。 git subtree とは何か git subtreeは外部のリポジトリを現在のリポジトリに取り込むための機能です。 リボジトリ in リポジトリとなるとgit submoduleだったり、 npmとかcomposerみたいな依存管理ライブラリみたいなものを連想するかも知れませんが、 subtreeの挙動はちょっと違います。 一般的な依存管理ライブラリや、git submodule では、 特殊なファイルに 取り込み元リポジトリを記載して管理するという、 取り込み元と、取り込み先を明確に区別しての管理を行うのですが、 subtree では、 「取り込み元と取り込み先のコミット履歴を完全に結合する」 という動き方をするみたいです。 使い方 とりあえずフ
github/gitignore at master - GitHub
A collection of .gitignore templates This is GitHub’s collection of .gitignore file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files. For more information about how .gitignore files work, and how to use them, the following resources are a great place to start: The Ignoring Files chapter of the Pr
チームで共有しておきたい！オススメ githooks まとめ - Qiita
はじめに githooksをうまく使うことで、lintによる規約チェックやコミットメッセージのフォーマット確認など、チームメンバー全員のコード品質を担保したり、作業の漏れを防ぐことが出来ます。 というわけで、今回はチームメンバー全体で共有しておきたい、オススメのgithooksをまとめてみたいと思います。 注意点 基本的にbash前提で書いているので、 #!/bin/bash をgithooksの各ファイルの1行目に書いておいてください。 また、githooksは実行権限がないと動きません。 なので、ファイルを作った後は必ず権限を付与してあげてください。 vi .git/hooks/pre-commit chmod +x .git/hooks/pre-commit vi .git/hooks/commit-msg chmod +x .git/hooks/commit-msg それと、hoo
忘れやすい人のための git diff チートシート - Qiita
git diff は色んな場面で本当によく使うんですが、できることが多いだけに全然覚えられずに毎回調べてしまいます。 なので、場面ごとに使えるコマンドを一覧でまとめてみました。 先にワークツリーとインデックス【Gitの基本】- サルでもわかるGit入門を読んでおくと、ここに書いてある diff について理解しやすいと思います。 git pull する前にリモートとの変更点を見る git pull をする前にローカルの最新コミットと pull 先のリモートリポジトリとの変更点が見たいときはこのコマンドで見れます。 ここでいうリモート名は origin とかそういうやつです。 git push する前にリモートとの変更点を見る 上記のコマンドは、こんな感じで逆にもできます。
gitのpre-push hookでmasterブランチにpushする際にプロンプトで確認するようにする - Qiita
会社のGitを使っているときに、自分のブランチで作業しているつもりが間違ってmasterブランチで作業しており、気づかずにpushしそうになって肝を冷やしたことがあるので、masterにpushする際はプロンプトで確認するようにした。 環境 Mac OS X Yosemite 10.10.5 Git 2.11.1 gitテンプレートディレクトリを作成 特定のレポジトリではなく、PC上で扱う全てのレポジトリのコミットをhookするため、グローバルの.gitテンプレートディレクトリを準備する。 （なお、特定のレポジトリでだけhookしたい場合は、以下で作るpre-pushファイルをレポジトリの.git/hooks/におけばよい）
Commit Hash から、該当 Pull Request を見つける方法 - Qiita
git blameなどを使用して、変更を加えたcommit sha hashだけわかった時、git show daced1d3のようにすれば、そのコミットの変更内容を見れます。ですが、本当は内容よりその変更を加えたPull Requestを知りたいことありますよね？ そんなコミットからプルリクエストを探したい時に使えるgit aliasコマンドを紹介します。 git showpr Pull Requestをマージしているコミットログを見つけます。 show pull request => showpr としてますが、名前は好きにつけてください。 .gitconfigのalias設定 [alias] showpr = !"f() { git log --merges --oneline --reverse --ancestry-path $1...master | grep 'Merge p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bash script to typecheck project on TypeScript file changes
GitHub - marionebl/commitlint: Moved to https://github.com/conventional-changelog/commitlint
