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のデフォルトブランチ名
gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体から
.gitignoreを作ってくれるgiboが便利すぎる - hnwの日記
gitignore-boilerplates（長いので以後giboと呼びます）という便利なツールを紹介します。これは.gitignoreのひな形を作ってくれるものです。 https://github.com/simonwhitaker/gitignore-boilerplates もう少し詳しく説明すると、giboは様々なOS・エディタ・言語・フレームワークなどに特化したファイルの情報を利用して、複数環境を考慮した.gitignoreを作ってくれます。 .gitignoreに入れたいファイルは環境ごとに変わってくるわけですが、各人がcommitしたくないファイルの存在に気づくたびにチマチマ.gitignoreに追記していくのって本当に無駄だと思うんですよね。giboはそれを自動化してくれるというわけです。 例えば、WindowsとMacOSXの2環境、Emacsとvimの2エディタを使う人
zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita
zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下
「こわくない 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 & GitHub & kintone でウルトラハッピー！ - Cybozu Inside Out | サイボウズエンジニアのブログ
６歳と３歳の娘がいる山本泰宇（@ymmt2005）です。こんにちは。 いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺！Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。 サイボウズでも Git と GitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて（涙） 出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツー
それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています
こんにちはこんにちは。一昨日、さくら VPS に Git をインストールするエントリーを書きましたが、実はバージョン管理は etckeeper にもお世話になっています。 etckeeper というのは、Git 等のバージョン管理ツールを用いて、/etc 以下をほぼ自動的に管理してくれる有り難いツールです。下記のタイミングで自動的にコミットしてくれます。手動で任意のタイミングでコミットすることもできます。 -yum コマンド実行の前後 -日付が新しくなったとき << 以下、さくら VPS（CentOS 5.5 -64bit）で etckeeper を使えるようになるまでの手順をまとめてみましたので、よろしければ参考にしてください。 *目次 Git のインストール etckeeper のダウンロード etckeeper の設定ファイルの編集 etckeeper のインストール etckeep
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
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スクリプトを置く
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
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 で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
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
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のリポジトリ内かどうか判定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-submv作った - Humanity