GitLabにマージリクエストを送ってみました。 gitlab.com 以前の経験からGitLabの開発チームはGitHubはほぼ見てないことを知っていたのでGitLabから送ってみました。 catatsuy.hateblo.jp ちなみに上のエントリに出てくるGritが使われている箇所は現在ではすべてRuggedに書き換わっているので状況は変わっています。 マージリクエスト送った！ / “'created_at DESC' is performed twice (#825) | Merge Requests | http://t.co/LLbgkxK7A7 / GitLab Comm…” http://t.co/F91TCk67US— 健康診断@4/26 (@catatsuy) 2015年6月16日 GitLabの人たちはGitHub見てないのでちゃんとGitLabから送った— 健康診断
ここしばらく気が狂ったようにGithubのAtomのコードを読んでた。 コードリーディングの成果はここに貼ってる。まだ更新するかもしれない atom-reading.md で、大体のコードを読んだのはいいとしてなんか作らないと勿体無い気がしたので、エディタ内でgit-grepの結果見てジャンプできるやつ作った。 mizchi/atom-git-grep 自分で作っといてなんだけどくっそ便利だと思う。Sublimeで作りたかった。 プラグインの作り方の大雑把な概要 nodeのモジュール使って、普通のブラウザっぽいUIを組む。基本パーツはatom側に揃ってるので継承して使う。 必要なインスタンスはだいたいatom変数以下に入ってる。shift+cmd+I でデバッガ開いて叩きまくるとだいたい察することができる。 プラグインのスケルトン生成 shift+cmd+p でコマンドパレット出して、 P
なんとなく最近どんな感じで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 バージョン管理しているファイルのファイルパスを表
受疫情影响，所有客户下单前需与客服确认好送货事宜方可下单。近期中沙，轻体砖价格波动较大，各商家货源不稳定，请在下单水泥商品后在订单中备注您对沙子、轻体砖的需求，平台会寻找优质的卖家为您发货。
皆さん、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の差分を見てみるとこんな
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
誤解を恐れずに言えば、Gitとは一つの連想配列ストレージシステムです。 かっこよく言うと Key Value Storeです。 Gitがやっていることの本質は、あなたのコンテンツを圧縮してDBに保存し、あなたの要求に応じてDBから取り出して解凍する、ただそれだけです。 具体的には KVSでのsetにあたる命令がgit add,git commit KVSでのgetにあたる命令がgit checkout です。 そしてデータベースとは.git/object/ ディレクトリ配下にあるファイル群のことです。 さて今回はgit checkoutコマンドを使わずに低レイヤーなコマンドだけを使って同じことを実現してみましょう。 準備 新規レポジトリを作成して、"hello world"と書かれたファイルをコミットします。
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
8月22日、Gitリポジトリ管理ツール「GitLab 6.0」がリリースされた。グループ機能の強化が行われているほか、デザインなどの改良も行われた。また、本バージョンより有料のエンタープライズ版の提供も開始されている。 GitLabはRuby on Railsで実装されたGitリポジトリ管理ツール。Webブラウザでアクセスして利用するツールで、GUIでGitレポジトリの閲覧や操作を行える。高速、安全、安定性などを特徴とし、すでに1万以上の企業や組織が利用しているという。ライセンスはMIT License。 GitLab 6.0は、3月に公開されたバージョン5.0からのメジャーアップデートとなる。大きな新機能としては、グループ機能の強化がある。いままではグループはプロジェクトを管理するためのディレクトリでしかなかったが、本バージョンではグループにユーザーを追加することが可能になった。グループ
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
ライブラリやフレームワークなど、外部のリポジトリで管理されているソースコードをプロジェクトに取り込む際によく使われているgit submoduleを使わないほうが良いという論争が起こっています。それを受けてgit subtreeを使うべきであるというエントリがAtlassianのNicola Paolucci氏がブログに投稿しています。彼はまずgit submoduleを使うべきではないという話題が盛り上がっているという事で3つの記事を参照したあとに、git subtreeを使うべき理由と使用例を挙げています。それによるとgit subtreeを使うべき理由は以下のとおり。 ワークフローがシンプルなので管理が簡単。 古いバージョンのgitもサポートしている。(v1.5.2ですら。) サブプロジェクトのコードがcloneした直後に利用できる。 subtreeはユーザに新しい学習を要求しない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
