タグ

gitに関するaki77のブックマーク (386)

  • コミットメッセージの先頭に絵文字いれるのが流行ってんだろうか | そんなこと覚えてない

    Atom Editor の Contributringをみてみると、「コミットメッセージの先頭に関係ある絵文字をいれろ」的なことが書いてある。 Git Commit Message - contributing - Atom :lipstick: when improving the format/structure of the code :racehorse: when improving performance :non-potable_water: when plugging memory leaks :memo: when writing docs :penguin: when fixing something on Linux :apple: when fixing something on Mac OS :checkered_flag: when fixing somethi

  • GitHubでの”Merge pull request”の弊害 | POSTD

    私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション (寄与貢献)を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時

    GitHubでの”Merge pull request”の弊害 | POSTD
  • githubへ100MB超のファイルのあるrepositoryを移行する - RAKSUL TechBlog

    ラクスルの利根川です。 ラクスルも最近の多くのテック系企業のようにソースコードの管理にgithubを使っています。 ラクスルがgithubに来るまで raksul.com をオープンして間もない2011年10月からソースコードの管理をgitにて行っておりましたが、2013年12月に「コードレビューとかプルリク運用とかそろそろしたいよね」とgitlabを使用していました。 ただ、過去の1万以上のcommitのせいか、当社だとgitlabの挙動が正直安定していなかった(が、その修正にpull requestを送る程の余力は無い)のもあり、当社でもgithubにてソースコードを管理することになりました。 githubへ移行する時 1.Sign UPする githubの価格表に記載がありますが、当社の場合は10 private repositories で足りるので、bronzeをsign upし

    githubへ100MB超のファイルのあるrepositoryを移行する - RAKSUL TechBlog
  • Atom Flight Manual

    aki77
    aki77 2014/06/28
    『Atomatigit is inspired by the magit emacs package.』
  • GitのhookでCtagsを実行する | SanRin舎

    Ctagsを使って、クラス名や関数名のインデックスを記述したtagsファイルを作っておくと、vimでキーワード上にカーソルをおいて、<C-]>を打つと、そのキーワードが定義された場所に飛んでくれて便利。 しかし、新たにキーワードが増えるたびにctagsを手動で実行するは面倒なのでGitのhookを使うことにする。 また、複数のプロジェクトがあるとき、各プロジェクトごとにtagsファイルを分けておくと、余計な候補が出なくてよいが、うまくやらないとプロジェクトを変えるたびに:set tagsでtagsファイルの指定を変更なくてはならないし、tagsファイルをGitのディレクトリ以下に置くと、.gitignoreで無視してやらなくてはならなかったりするので、その辺を解決させる。 まぁ、vimプラグインで有名なtpopeのtbaggery – Effortless Ctags with Git

    GitのhookでCtagsを実行する | SanRin舎
    aki77
    aki77 2014/06/27
    hook
  • git使ってて便利だった拡張3つ。 - from scratch

    gitを今の開発でガッツリ使うようになってすげー便利だと思った拡張を3つ紹介します。 もうね、これらなしではgit使えない。せっかくなので、導入方法と一緒に簡単な使い方も紹介します。 git-completion gitの補完ツール。 コマンドラインに現在のブランチ名が出る。だけじゃなくて、タブで補完までしてくれる。 導入方法 以下の方法でスクリプトをダウンロードしてきます。 $ mkdir -p /usr/local/git/contrib/completion/; cd /usr/local/git/contrib/completion/ $ curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash > git-completion.bash $ curl https://raw.

    aki77
    aki77 2014/06/22
  • とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社

    長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を

    とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
    aki77
    aki77 2014/06/09
  • ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば

    以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。(前は zsh だったのでなんだかなーと思ってた。) そもそも何をするツールか GitHubGoogle Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート(デフォルトで ~/.ghq)以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->

    ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
  • sedで一括置換 - Qiita

    Gitで管理しているファイルの中でこの文字列を全部ガガガっと書き換えたいという時に使うと便利なコマンド。

    sedで一括置換 - Qiita
    aki77
    aki77 2014/06/05
  • ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog

    GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる

    ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
    aki77
    aki77 2014/06/04
  • 2014年、春のGit事情 - fujimuradaisuke's blog

    なんとなく最近どんな感じで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 バージョン管理しているファイルのファイルパスを表

    2014年、春のGit事情 - fujimuradaisuke's blog
    aki77
    aki77 2014/06/03
  • 「Git 2.0」リリース | OSDN Magazine

    Git開発チームは5月28日、オープンソースの分散型バージョン管理システム「Git 2.0」をリリースした。git pushがデフォルトでsimpleになるなど、後方互換性に影響する変更も多数含まれている。 GitLinuxカーネル開発におけるソースコード管理のために開発された分散型バージョン管理システム。2005年にバージョン1.0がリリースされ、現在では多くのソフトウェア開発プロジェクトで利用されている。Linuxのほか、WindowsMac OS Xといったプラットフォームでも利用可能。 Git 2.0では後方互換性が失われている変更点も含まれており、その1つとして「git push」コマンドの挙動変更がある。従来のgit pushにおけるデフォルト動作は「matching」と呼ばれるもので、すべてのローカルブランチが自動的にpush先リポジトリに送信されていた。しかしGit 2

    「Git 2.0」リリース | OSDN Magazine
    aki77
    aki77 2014/05/31
  • SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA

    SourceTreeの使い方 - 初心者が習得すべき基操作(diff, stash, tag, revert, cherry-pick) GitクライアントのSourceTreeソースツリーは無料で使えるGitアプリケーションとして人気があります。「SourceTreeの基的な使い方はバッチリ! だけど、まだまだ使っていない機能があるなぁ」なんて人も多いのではないでしょうか? そんな人へオススメの知っておくと便利な機能を5つ紹介します。 ※記事は2020年現在のmacOS 10.15、SourceTree 3で解説しています。Windows版のSourceTreeでも同じ手順で利用できます。 はじめに - SourceTreeとは? SourceTreeはGit / MercurialのGUIクライアントで、Atlassian社から無償で提供されています。WindowsmacOS

    SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA
  • Gitで最初のコミットをどうにかする - tmtms のメモ

    最初のコミットの内容を変更したい Gitで最初のコミットの内容を変更したいと思って git rebase -i <最初のコミット> とやっても、最初のコミットは出てきません。 % git log --oneline 4f4f42c 二番目のコミット 9d4876c 最初のコミット % git rebase -i 9d4876c pick 4f4f42c 二番目のコミット このような場合は git rebase -i --root を指定すると良いようです。 % git rebase -i --root pick 9d4876c 最初のコミット pick 4f4f42c 二番目のコミット 最初のコミットの前に別のコミットを入れたい さっきと同様に git rebase -i --root で開いて、最初のコミットを edit にします。 % git rebase -i --root edit

    Gitで最初のコミットをどうにかする - tmtms のメモ
    aki77
    aki77 2014/05/29
  • 巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社

    git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

    巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
    aki77
    aki77 2014/05/28
  • AWSアクセスキーをgitに誤って登録しないようにする | DevelopersIO

    はじめに Gitはとても便利ですが、GitHub上で不適切に公開されている秘密鍵を使ってAWSに不正アクセスする事例が発生 というようにAWSアクセスキー、シークレットキーを誤って登録してしまうととても恐いことになります。利用者側で気をつけられるようにGitのフックをつくってみましたので報告します。 Git フックとは? Gitにはフックというなにかの操作の前後にスクリプトを実行できるような仕組みがあります。これを使うことにします。コミットの前に気づければよいのでpre-commitを使うことにします。サンプルファイルが .git/hooks/pre-commit.sampleにありますが、今回はシンプルにしたいので、.git/hooks/pre-commitをスクラッチで作ります。 アクセスキー混入防止フック とてもシンプルです。git diffをしてその中に KEYという行があり、さら

    AWSアクセスキーをgitに誤って登録しないようにする | DevelopersIO
  • Atomのコード読みまくったので、git-grepの結果へジャンプできる拡張を作ってみた - mizchi's blog

    ここしばらく気が狂ったようにGithubのAtomのコードを読んでた。 コードリーディングの成果はここに貼ってる。まだ更新するかもしれない atom-reading.md で、大体のコードを読んだのはいいとしてなんか作らないと勿体無い気がしたので、エディタ内でgit-grepの結果見てジャンプできるやつ作った。 mizchi/atom-git-grep 自分で作っといてなんだけどくっそ便利だと思う。Sublimeで作りたかった。 プラグインの作り方の大雑把な概要 nodeのモジュール使って、普通のブラウザっぽいUIを組む。基パーツはatom側に揃ってるので継承して使う。 必要なインスタンスはだいたいatom変数以下に入ってる。shift+cmd+I でデバッガ開いて叩きまくるとだいたい察することができる。 プラグインのスケルトン生成 shift+cmd+p でコマンドパレット出して、 P

    Atomのコード読みまくったので、git-grepの結果へジャンプできる拡張を作ってみた - mizchi's blog
    aki77
    aki77 2014/05/11
  • git-prune-remote-branch が gem になりました - @kyanny's blog

    以前 git-prune-remote-branch というものを作ったのですが(どういうものかはリンク先参照)、 あれ、git-prune-remote-branchってgemになってないんだっけ。— 北市真 (@KitaitiMakoto) May 2, 2014 というリクエストがあり、 @KitaitiMakoto あ、 gem にし終わったら教えてください— Kensuke Nagae (@kyanny) May 2, 2014 と丸投げしてみたら、 おれがやんのかw— 北市真 (@KitaitiMakoto) May 2, 2014 という流れのあと、 Gemify by KitaitiMakoto · Pull Request #2 · kyanny/git-prune-remote-branch https://github.com/kyanny/git-prune-rem

    git-prune-remote-branch が gem になりました - @kyanny's blog
    aki77
    aki77 2014/05/04
  • もう巨大なデータをgitignoreしなくていい! ~git-mediaの使い方~ - 3度の飯と最新技術

    はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ

    もう巨大なデータをgitignoreしなくていい! ~git-mediaの使い方~ - 3度の飯と最新技術
    aki77
    aki77 2014/04/15
  • Git初心者が絶対に覚えておくべきコマンド - idesaku blog

    Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる!massageじゃない、messageだ!マッサージを作ってどうする! 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi

    Git初心者が絶対に覚えておくべきコマンド - idesaku blog