タグ

gitに関するrskyのブックマーク (15)

  • Latest topics > GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - outsider reflex

    Latest topics > GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行まんがでわかるLinux シス管系女子の試し読みが可能! « ポジショントークに騙されないようにしたいし、狭い視野でポジショントークじみた極論を言うよりも、メリットとデメリット両方を把握した上でソフトランディングを図っていきたい Main Chromiumのコミットメッセージの「よりinclusiveにする」とはどういう意味か、GitHubがしている事の何がキナ臭いのか » GitHubに多数ある自分のリポジトリのデフォルトブランチをmasterからtrunkに切り替えた - Jun 12, 2020 Gitのデフォルトブランチ

    rsky
    rsky 2020/06/12
    “「枝(branches)」に対する「幹(trunk)」という名前付けはメタファとして理に適っていると、自分としては素直に思える。”
  • gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋

    ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル体から

    gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
  • .gitignoreを作ってくれるgiboが便利すぎる - hnwの日記

    gitignore-boilerplates(長いので以後giboと呼びます)という便利なツールを紹介します。これは.gitignoreのひな形を作ってくれるものです。 https://github.com/simonwhitaker/gitignore-boilerplates もう少し詳しく説明すると、giboは様々なOS・エディタ・言語・フレームワークなどに特化したファイルの情報を利用して、複数環境を考慮した.gitignoreを作ってくれます。 .gitignoreに入れたいファイルは環境ごとに変わってくるわけですが、各人がcommitしたくないファイルの存在に気づくたびにチマチマ.gitignoreに追記していくのって当に無駄だと思うんですよね。giboはそれを自動化してくれるというわけです。 例えば、WindowsMacOSXの2環境、Emacsとvimの2エディタを使う人

    .gitignoreを作ってくれるgiboが便利すぎる - hnwの日記
    rsky
    rsky 2012/12/21
  • zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita

    zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下

    zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita
    rsky
    rsky 2012/12/11
  • 「こわくない Git」というスライドを発表しました - kotas.tech

    社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です! こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ? A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。

    「こわくない Git」というスライドを発表しました - kotas.tech
    rsky
    rsky 2012/11/22
    とても良い資料
  • Git & GitHub & kintone でウルトラハッピー! - Cybozu Inside Out | サイボウズエンジニアのブログ

    6歳と3歳の娘がいる山泰宇(@ymmt2005)です。こんにちは。 いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺!Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。 サイボウズでも GitGitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて(涙) 出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツー

    Git & GitHub & kintone でウルトラハッピー! - Cybozu Inside Out | サイボウズエンジニアのブログ
    rsky
    rsky 2012/11/02
    “継続的なデリバリーには、安定ブランチはひとつだけがいい”
  • それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています

    こんにちはこんにちは。一昨日、さくら VPS に Git をインストールするエントリーを書きましたが、実はバージョン管理は etckeeper にもお世話になっています。 etckeeper というのは、Git 等のバージョン管理ツールを用いて、/etc 以下をほぼ自動的に管理してくれる有り難いツールです。下記のタイミングで自動的にコミットしてくれます。手動で任意のタイミングでコミットすることもできます。 -yum コマンド実行の前後 -日付が新しくなったとき << 以下、さくら VPS(CentOS 5.5 -64bit)で etckeeper を使えるようになるまでの手順をまとめてみましたので、よろしければ参考にしてください。 *目次 Git のインストール etckeeper のダウンロード etckeeper の設定ファイルの編集 etckeeper のインストール etckeep

    それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています
  • コミットメッセージの書き方 - 2012-02-21 - ククログ

    はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常

    コミットメッセージの書き方 - 2012-02-21 - ククログ
    rsky
    rsky 2012/02/22
    Gitスタイル
  • ikachanでgitのpushをIRCチャンネルに通知する (追記アリ) - id:anatooのブログ

    gitのpushがあるたびに、コミットをIRCで通知するようにする。 まずikachanサーバを立てる 適当なサーバにikachanをインストールする。ikachanはIRCにメッセージを通知するためのサーバで、これを設置することで、シェルスクリプトなどから簡単にIRCにメッセージをポストできる。 例えば、以下の様にcurlコマンドを叩くだけでIRCに通知できるようになる。 $ curl -F channel=\#catalyst-ja http://localhost:4979/join $ curl -F channel=\#catalyst-ja -F message=hoge! http://localhost:4979/noticegitのコミットにかかわらずちょっとした通知をガンガンIRCチャンネルに通知できるので便利です。 pushされるリポジトリにhookスクリプトを置く

    ikachanでgitのpushをIRCチャンネルに通知する (追記アリ) - id:anatooのブログ
    rsky
    rsky 2012/01/26
    ikachan
  • GitHubへpull requestする際のベストプラクティス - hnwの日記

    みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、

    GitHubへpull requestする際のベストプラクティス - hnwの日記
    rsky
    rsky 2011/05/28
  • git-submv作った - Humanity

    gittools/git-submv at master · tyru/gittools · GitHub submoduleをリネームするのが面倒で作った。 $ git submv {src} {dest}みたいにして使う。 $ git submv {src} {dest} {dest-url}みたいにしてsubmoduleのURLを再設定したりもできる。 同じリポジトリにあるgit-subrmも必要。 リポジトリに普通にPATH通せば動くはず。

    git-submv作った - Humanity
    rsky
    rsky 2011/05/27
    submoduleをリネーム
  • git rebaseのメモ - unpushの日記

    ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる(適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない) 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C

    git rebaseのメモ - unpushの日記
  • Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering

    こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います: ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ

    Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
  • A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind

    git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日語のがたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful

    A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
  • gitのブランチ名をRPROMPTに表示する - walf443's blog

    ググってみると色々あったのですが、あまりシンプルなのがなかったので調べつつやってみました git name-rev HEAD --name-only みたいなものがあるだろうなとは思いつつ、コマンドが多くてなかなか見つかりませんでした。 _set_env_git_current_branch() { GIT_CURRENT_BRANCH=$( git name-rev HEAD --name-only ) &> /dev/null } _update_rprompt () { RPROMPT=$GIT_CURRENT_BRANCH } precmd() { _set_env_git_current_branch _update_rprompt } chpwd() { _set_env_git_current_branch _update_rprompt } gitのリポジトリ内かどうか判定

    gitのブランチ名をRPROMPTに表示する - walf443's blog
    rsky
    rsky 2009/10/17
    git name-rev HEAD --name-only → git symbolic-ref HEAD
  • 1