songmu @songmu feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど Kazunori Otani @katzchang Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。
ブランチ選択面倒ですよね git branch して、あるいは git branch --remote してブランチ一覧を確認 ブランチ名をコピーして、remoteブランチだったら remotes/origin/ などのプレフィックスを外して git checkout そんなゴニョゴニョは peco に任せましょう。 前提条件 peco コマンドがインストールされていること tr, grep , sed, xargs などのunixでは標準的なコマンドが使える環境であること alias に設定するコマンド コマンドの詳細 git branch --all remoteブランチも含めすべてのブランチを出力（ただし、 git fetch していないなどでremoteブランチの情報が同期されていないと表示されません） tr -d '* ' * と (半角スペース)を削除します grep -v -
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
上期も終わり開発中のgitリポジトリの情報を採取して遊んでいました。Qiitaでコミット数や総追加行数、総削除行数を取得するワンライナーについての投稿があり活用させて頂いています。ありがたい...! リンク先のワンライナーでコミット数は正確に計れるのですが、総追加行数と総削除行数がなにかおかしい。なぜか総追加行数が非常に多く計算されていました。 というわけで原因を調べてみました。 原因1. 1ファイルのみの変更の時にgrepがスルーされる 1ファイルのみの変更の場合、以下のような出力になります。 $ git log --shortstat --oneline --no-merges f86f749 Insert open graph meta tag contents when adding a link item refs #29 1 file changed, 67 insertion
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
こんにちは．エンジニアの研修が始まって一週間，便利ツールに溺れながら必死に使いこなそうとしているきたけーです． 研修でRails tutorialをやっているのですが，ちょくちょくGitでブランチを切る機会があります．どのブランチにいるか忘れて「git branch」しまくってるので，zshのプロンプトに表示することにしました． # VCSの情報を取得するzshの便利関数 vcs_infoを使う autoload -Uz vcs_info # 表示フォーマットの指定 # %b ブランチ情報 # %a アクション名(mergeなど) zstyle ':vcs_info:*' formats '[%b]' zstyle ':vcs_info:*' actionformats '[%b|%a]' precmd () { psvar=() LANG=en_US.UTF-8 vcs_info [[
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
GitBucketとは GitBucketはたけぞうさんという方が開発されているGitHubのクローンアプリです。 Scalaで書かれており、驚くほど簡単に導入することができるのが特徴です。 OSSのGitHubクローンといえばGitLabがメジャーですが構築の手順が複雑かつ面倒なため、 使い始める前に構築段階で挫折した経験のある人も多いのではないでしょうか。 対するGitBucketはwarファイルを実行するだけという手軽さです、素敵!! より詳しいレビューはこのあたりを参照してください。 背景 とあるクラウド環境にGitBucketを導入する機会があり、 せっかくなので vagrant + ansible で導入を自動化するplaybookを書いてみました。 以下のクラウドプラットフォームで導入検証をしました。 AWS DigitalOcean したごしらえ Case: AWS vag
追記(2014/05/25) 調べた情報が古かったみたいで、GitLabも今は1〜5分でインストールできるらしい。 GitBucketがとても手軽なのは変わらないけど、GitLabのほうが高機能ではある。 GitHubクローンのGitLabを５分でインストールした - アルパカDiary GitHubクローンのGitLabを1分で使えるようにする - Webtech Walker 開発用Gitサーバが先日の社内インフラダウンで巻き添えになって､ 業務にむっちゃ影響が出た｡ で､これを機にクラウド上にGitを移行しようと､ GitHubやらBitBucketやら調べてたんだけど､ どうもうちの会社の運用のままだと､ リポジトリ数やユーザ数が多くて結構なお値段が掛かりそうなことがわかった｡ 業務上全部プライベートリポジトリにしないといけないし､欲を言えばユーザもリポジトリも数制限かけられたくな
こんばんは。今回、gitを使ってPhotoshopで扱うPSDファイルの変更を自動的にステージング・コミットし、バージョン管理を行えるスクリプト「psdwatcher」を開発しました。 発端 発端は僕のfacebookのつぶやきからでした。 このつぶやきに、ある方が返信をくれまして、その会話の中で「psdファイルをgitで管理する」というアイデアが思い浮かびました。 これですね。 このアイデアが浮かんでから、約3日くらいでpsdwatcherのベータ版を作成しました。 そして、コマンドオプションの動作やCPUの負荷などを総合考慮して、昨日正式にpsdwatcherをリリースしました。 Open Source alice1017/psdwatcher - You can watch the change log of psd file using git. インストール インストールは、ロー
社内やオープンソースのプロジェクトに並行して参加していると、gitconfig の user.name や user.email をリポジトリごとに切り替えたくなることがある。リポジトリを作るたびに git config user.name "My Name" すればいいのだが、 user.name が存在しないか空文字列だと環境変数 NAME の値を暗黙的に使う仕様になっているため、設定をうっかり忘れてしまうとなかなか気づけない。名前やメールアドレスを間違えたまま何度もコミットしてしまうと修正が厄介である。 Git 2.8以上 最近の Git で設定忘れを未然に防ぐには git config --global user.useConfigOnly true を実行する。これを設定するとユーザー情報について環境変数を暗黙に参照することがなくなる。グローバルな gitconfig で use
When you run git log --decorate --pretty=oneline the output will have entries like (HEAD, refs/published/master, master) with coloration. I also have the following in my gitconfig: [color "branch"] current = yellow reverse local = yellow remote = green How do you replicate those colors when doing a custom format like the following? git log --decorate --stat --graph --pretty=format:"%d %Cgreen%h%Cr
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
photo by Nat W 研究室のB4が院試バトルを終えて、いざ卒研！となるこの時節、1人でも無駄な悲しみを背負う人が少なくなるようにと、去年（研究室でGithub勉強会をしました。）に引き続き、研究室Github勉強会をしました。 資料 どんなことしたのかは、資料を流し見れば薄ぼんやりわかるはず。もうすこし統一感のある資料にしたかったですね。 背景とか 僕がいる研究室では、人間とコンピュータの親和融合から発展する幸福的世界観を目指しています。ざっくばらんに言うと、人間に使いやすいコンピュータだとか、生活を少し幸せにするソフトウェア的手法だとかを研究しています。 こういった人間が密接に関わる研究だと、ユーザビリティ評価とかやります。おなじソフトだけど、少しずつ条件がちがうプロトタイプをたくさん作って、比較実験をします。これに加えて、 プロトタイプ→ユーザビリティ評価→改善→ユーザビリテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く