開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita
はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 本稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git logの
GitのSSH鍵認証で毎回パスワードを要求される - Qiita
// SSH鍵をssh-agentに登録 $ ssh-add /Users/user_name/.ssh/id_rsa // 上記パス（~/.ssh/id_rsa）の場合、下記でも登録可能 $ ssh-add -K // 登録されていることを確認する $ ssh-add -l
[git]複数のcommitをまとめてcherry-pickする - dackdive's blog
ちょいメモ。 別ブランチのコミットを他のブランチにも適用するときに便利な cherry-pick コマンドですが、 複数のコミットをまとめて cherry-pick してしまいたい時がたまにあります。 そんなとき $ git cherry-pick [cherry-pick の始点となるコミット]..[cherry-pick の終点となるコミット] というように、A..B という指定のしかたでコミット A からコミット B までの一連のコミットを cherry-pick することが可能です。 が、注意点として、始点となるコミットは 実際に cherry-pick したいコミットの１つ前 を選ぶ必要があります。 以下、例。 $ git branch -a * master $ git log commit 63ca256a5f806c8b237c3ff5c872debc0be12359 Au
![[git]複数のcommitをまとめてcherry-pickする - dackdive's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/523741ba2b15fba1e1841803e8cbeda1ce6467cd/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712615374%2F6653812171399935971%2F1645799777)
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
Vim からいい感じに tig blame する - pockestrap
TL;DR git blame しない人は読まなくていい。 nnoremap <F3> :silent! !tig blame +<C-r>=line('.')<CR> %<CR>:redraw!<CR> .gvimrc では nnoremap <F3> :silent! !sakura -x 'tig blame +<C-r>=line('.')<CR> %'<CR> sakura は適当なターミナルエミュレータの名前に置き換える。 <F3> は完全に趣味なので、適当なキーに割り当てればいいと思う。 欲求 以前は普段 git blame を行うのに tpope/vim-fugitive を使用していた。 ただ、blame 以外に fugitive を一切使っていなかったのでもやもや感があった。できればプラグインへの依存は少なくしたい。 そんな折、tig blame が便利だという情報を得
fish shell を使いたい人生だった | DevelopersIO
2019年4月15日: fisher version 3.2.8にアップデートしました。これに伴い、もともと記事内で記載していた fisher install コマンドを 、fisher add に変更しました ずっとbashを使っていました。zsh、興味はありましたが、プラグインのための設定を書くのがなんとなく大変そうだという理由で、敬遠していました。そこに fish shell （以下 fish） が手を差し伸べてくれたのです。結論から書くと、bash と同程度の設定ファイルの記述量で、ディレクトリ間の移動やコマンド履歴の呼び出しといった利便性は飛躍的に向上しました。そして見た目が良い。入れて損はありません。 想定読者 Mac で bash を使っている方。 バージョン情報 ソフトウェア バージョン どこまでやるか このたぐいの作業、はじめるとキリがありません。調べるうちにさらに便利な
Tig で Git を自由自在に操作するための .tigrc 設定例 - Qiita
本記事は Git Advent Calendar 2016 の12日目です。執筆者は sfus です。 はじめに Tig は軽量でグラフィカルな ncurses ベースのテキストユーザインタフェース Git クライアントです。ターミナル上で Git GUI クライアントのような表示・操作を行うことができる便利なツールです。 本記事では既に Tig を利用している方向けに、より便利になる設定をご紹介します。 （Tig に詳しくない方は次の記事が詳しいと思います） tigでgitをもっと便利に！ addやcommitも - Qiita カスタマイズ tig を起動して h を押せばキーバインド一覧が表示されますが、デフォルトのキーバインドは最低限度のものしか設定されていません。 ユーザは ~/.tigrc に設定を書くことで Tig の表示やキーバインド設定をカスタマイズすることができます。
fugitive.vim と tig による git 生活 - 藻ログ
GWの出だしから熱を出して寝込んでいて，そういえば普段 fugitive.vim と tig をあんまりちゃんと使い分けてないなとぼんやり考えた. fugitive.vim GitHub - tpope/vim-fugitive: fugitive.vim: a Git wrapper so awesome, it should be illegal vim から git を呼べるようにするラッパープラグイン． dein.vim で以下のように入れている． [[plugins]] repo = "tpope/vim-fugitive" hook_add = 'source ~/.config/nvim/userautoload/plugins/plugins-vim-fugitive.vim' dein については以下を参照. dein.vimにお引越し - 藻ログ 使い方は :h fug
[Git] 10分で使いはじめるTig（コミット操作を早くする） - Qiita
はじめに 私は普段 Tig（てぃぐ）を使っているのですが、どうも Tig の知名度は意外と低いようです。そして噂に聞いて使い始めても、とっつきづらいなどの理由でやめちゃう人も多いようです。 しかし、最初の壁さえ乗り越えてしまえば、Tigは便利なGitツールとして自身のツールボックスに加えられると思います。 実際に私の経験として、同僚に10分くらいで Tig のインストールから基本操作をレクチャーをしたところ 「Tigめっちゃ便利や・・・！」 という感想を頂いたこともあります。 概要 本記事では、Tigを使うモチベーションからインストール、まず覚えるべき「コミット操作」について書いています。 すなわち私が同僚にしたレクチャーの追体験です。 ターミナルにテーマを設定しているため、スクリーンショットがお使いの環境と異なる方が多いと思いますがご容赦ください モチベーション Gitのコミット操作（ス
![[Git] 10分で使いはじめるTig（コミット操作を早くする） - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/42982da11a850f206388076511af5a47577b13c2/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJTIwMTAlRTUlODglODYlRTMlODElQTclRTQlQkQlQkYlRTMlODElODQlRTMlODElQUYlRTMlODElOTglRTMlODIlODElRTMlODIlOEJUaWclRUYlQkMlODglRTMlODIlQjMlRTMlODMlOUYlRTMlODMlODMlRTMlODMlODglRTYlOTMlOEQlRTQlQkQlOUMlRTMlODIlOTIlRTYlOTclQTklRTMlODElOEYlRTMlODElOTklRTMlODIlOEIlRUYlQkMlODkmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWIzMTY1MjBjNjE1MDU3MDBkYzMxM2I1NTc4NGQzNmMw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBZdXN1a2VIb3NvbnVtYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZWYzODk2N2FkZTQ2MzQzOGU3YTQzMDgxZmMxYmU3ZTg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D108e86eb2f5552a71bda3460d4b9952f)
git のチカラで未知の言語でもオムニ補完 - Qiita
デモ オムニ補完とは？ オムニ補完は vim 界隈でわりとよく耳にする言葉ですが、IDE よろしくメソッド名などをいい感じに補完する機能です。 Emacs でも perl の変数名とかメソッド名をいい感じに補完してくれるperl-completion.el とか、 C/C++ の IDE モドキ CEDET などがあります。 auto-complete.el に最初から入っている CSS の補完も、プロパティ名によって補完候補を変えてくれたりかなりオシャレです。 なにをやったの？ オムニ補完は便利なのですが、エディタがその言語のことを良く知っているか、あるいは言語処理系側がいい感じに補完候補を探してエディタに報告してくれる機能を持っていないと基本的には実装できません。なので、言語ごとに別々のプラグインを入れるのが普通で、設定のほうはわりと面倒です。 そこで今回は git の力を借りて、言語
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
綺麗なpull requestを送るための3つのポイント - Qiita
これはGit Advent Calendar / Jun.20日目の記事です。前回は、fukajunさんの変更を一時的に退避！キメろgit stashでした。 この記事ではgithubでpull requestを送る時に私が気をつけていることを共有したいと思います。 私が気をつけていることは次の3つです。 masterにコミットしない 簡潔なコミットメッセージを書く コミットを1つにまとめる この話の前提 以降では、次の2つのリモートリポジトリが登録されている前提で説明します。 upstream: fork元のリポジトリ origin: upstreamからforkされた自分のリポジトリ masterにコミットしない 修正作業は必ず新しいブランチを作ってから行ない、masterブランチはあくまでupstreamの更新を取り込むためだけに使って下さい。 このルールを守らないでpull req
git fetchの理解からgit mergeとpullの役割 - Qiita
gitを使い始めるとcommit, push, pullなどはある程度理解出来るようになりますが、fetchってなんだ？ってなりますよね。 あまり馴染みにくいのは、pullがfetchとmergeの両方を組み合わせたコマンドだからなんですね。 fetchとは gitの場合、リポジトリはリモートとローカルの２ヶ所あります。fetchとはリモートリポジトリから最新情報をローカルリポジトリに持ってくるコマンドです。 fetchをしても、pullのようにファイルが更新されるわけではありません。 あくまでもローカルリポジトリが更新されるだけです。 もっと詳しくいうと、例えばmasterブランチを使っているのであれば、 origin/masterが更新されるということです。 masterとorigin/masterの違い masterは、例えばローカルのファイルを更新してコミットする場合にはmaste
はらへり日記 - Git開発でmasterの内容を開発ブランチに反映させる方法
Git開発を行っていると、こんなことありませんか。 origin/masterブランチからhogeブランチを切る hogeの実装をゴリゴリ行ってる間にorigin/masterブランチがどんどん更新されていく 自分が編集してたファイルがmasterで更新されてた＼(^o^)／ origin/masterを一回merge、コンフリクトを直してPull Requestを送る あるあるですよね。 そしてrebaseを知らない頃の僕は以下の方法で解決していました。 % git checkout master % git pull origin master % git checkout hoge % git merge master (ここでコンフリクトが出て怒られる) (bot modifiedステータスのファイルを修正、コミット) % git push origin hoge ここでやっとPu
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Programming.log, [Git][fish] commitしたら「error: There was a problem...
GitHub - airblade/vim-gitgutter: A Vim plugin which shows git diff markers in the sign column and stages/previews/undoes hunks and partial hunks.
コードレビューを支える技術
自分がEmacs でよく使うコマンド、キーバインド、モード - Qiita
git-grepで常に行番号を表示する - Qiita
