fzf で git log を見ながらブランチ移動する
function select-git-switch() { target_br=$( git branch -a | fzf --exit-0 --layout=reverse --info=hidden --no-multi --preview-window="right,65%" --prompt="CHECKOUT BRANCH > " --preview="echo {} | tr -d ' *' | xargs git lgn --color=always" | head -n 1 | perl -pe "s/\s//g; s/\*//g; s/remotes\/origin\///g" ) if [ -n "$target_br" ]; then BUFFER="git switch $target_br" zle accept-line fi } zle -N select
Commitizenを使ってgitのコミットメッセージをしっかり書こう | DevelopersIO
はじめに gitのコミットメッセージを記述するとき、内容について悩むことが度々あります。 簡潔に要点をまとめて書きたいけどいちいち記述が面倒だったり、チームで書き方がバラバラだったり・・・ そして結局「fix bug」のひとことだけメッセージを記述するだけになったりします。 この記事ではそんなコミットメッセージを少しでも簡単に有用にするためのツールを紹介します。 Commitizen? コミットメッセージを簡単・簡潔に記述したいときに使えるのがCommitizenです。 Commitizenはインタラクティブにコミットメッセージを作成できるツールで、 このコミットのタイプ スコープ コミットのサマリー コミットの詳細 などについて対話的に記述していくことで、適切なコミットメッセージを作成できます。 ? Select the type of change that you're commit
~/.gitignore_global を指定するのをやめ、デフォルトの置き場に置こう
Gitで全てのリポジトリのignore指定を ~/.gitignore_global に置いている例はよく見られます。実際、この名前はGitが公式で公開している本 (Pro Git 2) (→日本語版) でも言及されています。 このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、 (...) ところがこれはややミスリーディングです。この部分は core.excludesfile 自体の説明にほかならないのでわざわざ設定を書き換えていますが、実はデフォルト値があります。これは gitignoreのマニュアル で説明されています。 Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is eith
【git stash】コミットはせずに変更を退避したいとき - Qiita
「とあるブランチで作業中だけど、いますぐやりたいことができた。作業がすごく中途半端だからコミットはしたくない。」 というときに、stashが使えます。 stashを使用すると、コミットしていない変更を退避することができます。 stashで現在の変更を退避して、今すぐやりたい作業をして、退避させていた変更を戻して作業を再開することができます。 変更を退避する コミットしていない変更がある状態で上記のコマンドを実行すると、変更した部分が退避されます。 ワーキングディレクトリ上は差分がない状態になります。 「コミットしていない変更」とは、addしたものもaddしていないものもどちらも含まれます。 -u は --include-untracked の略です。新規作成ファイル(追跡対象に含まれていないファイル)も退避することができます。 退避した作業の一覧を見る 以下のコマンドで退避した作業の一覧を
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
git で merge 用のブランチを作る利点
master ブランチから大きく fork したトピック・ブランチを master へマージする時のお話。 小さな変更 (数日分) ならまだしも、数週間・数か月近くブランチが分岐したままだと、merge はどこかで conflict する。そこで力技に走っている人を見かけたので、アドバイスした。 merge 専用のブランチを作りなさいよ。 $ git branch * big-change master 例えばこんな風に bag-change branch がある場合、直接、merge は行なわない (トラブルが起きないなら、直接 merge しても構わないと思うけど)。 $ git checkout master $ git merge big-change 代わりに一回 merge 用の branch を作ってそこで conflict 解消の作業を進める。 $ git checkout
バージョン管理したくない作業用スクリプトは「,」ディレクトリに入れるといい - Qiita
TL;DR: グローバルな gitignore に ,/ を追加して、作業用スクリプトを , ディレクトリに入れると便利。 ,/tmp_script.sh で実行できる。 Git リポジトリの中に一時的に使う作業用スクリプトを置いておきたいことがある。自分だけが使うものなのでコミットはしたくないが、いちいち .git/info/exclude に追加して無視させるのも面倒臭い。 今まで自分は、 tmp_script.sh~ や tmp_script.sh.bak など、グローバルな gitignore で無視されるファイル名にしていたが、これは不要なファイルと間違えて消してしまう危険がある。 ignored.tmp_script.sh は分かりやすいぶん長い。 _tmp_script.sh は悪くないが、コミットすべきファイルにもアンダースコアで始まるものがあって紛らわしい。 そこで、作業
Git の仕組み (2) - コミット・ブランチ・タグ - こせきの技術日記
Git の仕組みシリーズの2回目です。目次がここにあります。 前回の記事では、Git オブジェクトとリファレンスが大きなツリー構造になっていることを説明しました。 また、Git オブジェクトがどのように記録されているか、 ファイルツリーの変更がルート tree オブジェクトの ID に反映される仕組みなどを見てきました。 今回は commit オブジェクト、ブランチ、タグ、stash の仕組みについて説明します。 実際のデータが見たいときは、Git Object Browser にアクセスしてみてください。 5. commit オブジェクト 先に説明した通り、Git オブジェクトデータベースには、複数のファイルツリーを保存できます。 個々のファイルツリーは、最上位 (ルート) にある tree オブジェクトの ID で区別することができます。ファイルツリーは、大抵の場合、過去のファイルツリ
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
always testing: gitとJenkinsの連携(Windows7/64bit)
2011-03-28 gitとJenkinsの連携(Windows7/64bit) 絶対忘れそう（次にセットアップする際に同じ過ちを繰り返す可能性が高い）ので、メモる。 http://jenkins-ci.org/ Windows版のNative Packageを落としてインストール。 http://code.google.com/p/msysgit/ msysgitのFull Installerを落としてインストール。 ちなみに、この際、Windowsの環境変数PATHに、cygwinという文字列が含まれていると問題ありなので要注意（これで一日無駄にした）。 Jenkinsでジョブを作る。 Hudson氏の頃は、ジョブのワークスペースは、C:\Users\Hoge\.hudson\jobs\JobHogeに作られていたが、Jenkins氏はC:\Program Files
svn な人のための これだけ読めば (もしかしたら) わかる (かもしれない) git の考え方 - rinu's blog
はじめに svn を使っていたあなたが、さくっと git の考え方を理解できますように (*・人・*) git リポジトリのイメージ git リポジトリのイメージを絵にしてみました。 絵の中の登場人物について、このあと触れますー リポジトリ リポジトリは複数のファイルの変更履歴を記録する入れ物です。 リポジトリを使用するときは、どこかにある、誰かのリポジトリを、自分のマシンにまるっとクローンを作って使用します。 (対して svn はある時点でのファイルのみを、ローカルに持ちます) コミット(図の黄緑の四角いあいつ) ファイル達に変更を重ねていくと、変化したファイル達の状態が、リポジトリに保存されていきます。 このリポジトリへ変更した内容を保存することを「コミットする」といい、保存されたファイル達の、変化の履歴の1つ1つを「コミット」といいます。 それぞれのコミットは 「0abe...」 み
図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
Set up Git - GitHub Docs
Using Git To use Git on the command line, you will need to download, install, and configure Git on your computer. You can also install GitHub CLI to use GitHub from the command line. For more information, see "About GitHub CLI." If you want to work with Git locally, but do not want to use the command line, you can download and install the GitHub Desktop client. For more information, see "About Git
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
Private Gist の注意点 - Block Rockin’ Codes
最近書けてなかったから、ここらへんで大事な小ネタを。 以外と知らない人がいるようなので、書いておきます。 結論 Private Gist は URL を知ってれば誰でも見える。 Gist Github と Gist は普通に使ってる前提です。 使ってない人は読む必要ないです。 あと、前提読んで知ってたら読む必要ないです。 Private Gist は他人から見えない？ Gist って、作るとき Private と Public が選べますよね。 Public は全世界に公開されて、 Private は他には見えない。 という説明がされてるサイトもあるようです。 検証してみましょう。 Private Gist を作る。 自分の Gist に Private Gist を作りました。 以下の URL でアクセスできます。みなさんご覧下さい。 https://gist.github.com/15
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
layer8.sh
layer8.sh
こわくない Git
