Kazuho Oku @kazuho バージョン管理システムの目的は変更履歴を管理することなんだから、git rebase とか履歴を改変するコマンドは言うまでもなくダークサイド 2012-11-09 16:58:32
git merge or rebase, ff or no-ff
Kazuho Oku @kazuho バージョン管理システムの目的は変更履歴を管理することなんだから、git rebase とか履歴を改変するコマンドは言うまでもなくダークサイド 2012-11-09 16:58:32
「こわくない 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リポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
Gitリポジトリ運用の最適解 - chulip.org
続編のような物(2012/11/21追加) 掲題の件について最近調べたことをまとめることにします。 はじめに タイトルだいぶ誇張していますが、結論から言うとマージコミットを発生させないGitの使い方です。 マージコミットが悪という言葉を最近よく目にしていたのですが下記リンク先の説明でしっくり来ました。 マージコミットの分割が１本線の履歴の分割よりも困難となる理由 そのためマージコミットが発生しないような使い方を目指します。 また、A successful Git branching modelを実現するためのgit-flowというもののありますが今回は触れません。 (ちなみにA successful Git branching modelではマージコミットは必ず残すことを推奨しています) Non-Fast-Forwordマージでの利点はブランチでの作業履歴が残ることと認識しています。 Fa
いざという時のためのgit reflog - Qiita
Git Advent Calendar / Jun. 29日目の記事です．28日目は@uasiさんの「どこでも使える git diff と git apply」でした． 「間違ってマージしていないブランチを消した」「reset --hard HEAD^*で戻しすぎた」ということがたまにある． しかしgit reflogを使うと(GCされていなければ)過去のあらゆるコミット履歴を見ることができ，git logやgit branchでは辿り着けない時点まで戻すことができる． $ git reset --hard HEAD^^ # HEAD^と指定するつもりが間違えた! $ git reflog f5cb888 HEAD@{0}: head^^: updating HEAD b0b8073 HEAD@{1}: merge @{-1}: Merge made by the 'recursive'
IT業界で高く評価される10のソフトスキル
現代のITプロフェッショナルには技術的な専門知識とソフトスキルの双方が要求される。このようなことはずっと昔から言われ続けている。しかし、そういったソフトなスキルに対するニーズはどんどん膨らみ続けているのである。 IT技術のスキルとしてどういったものが必要になるのかは、企業によって異なっている。しかし、ほとんどのIT企業に共通するニーズがある。それがソフトスキルというわけだ。こういったニーズが求めらるのは今に始まった話ではない。30年ほど前にも、企業のIT部門は文系の学生を採用し、ビジネスアナリストやシステムアナリストへと育成することで、プログラマーとエンドユーザーの間に横たわる「コミュニケーションギャップ」を埋めようとしていた。また、最高情報責任者（CIO）の経歴を見てみると、ほぼ半数が文系出身となっている。 では、現代の企業がITプロフェッショナルに求めるソフトスキルとは、どういったもの
ert-expectations: 新世代ユニットテストフレームワーク in Emacs Lisp - http://rubikitch.com/に移転しました
お久しぶりです。 世の中はすっかりEmacs24になってきたようですね。 本日、el-expectations.elの後継となるert-expectations.elをリリースしたのでお知らせします。 el-expectations.elは現役で使っているのですが、テストが失敗したときのレポート機能が弱くて不便に思っていました。 Emacs24ではユニットテストフレームワークのERTが標準添付になったことにより、ERTを内部で呼び出すことでその問題を克服しました。 基本的な使い方はel-expectationsと変わりません。 ERTについて学んでなくても今すぐ使えます。 M-x install-elisp-from-emacswiki ert-expectations.el M-x install-elisp-from-emacswiki el-mock.el あるいは M-x auto
mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog
こんにちは。年末と年度末になるとブログを書きたくなる運用部アプリ運用グループの清水です。 気づけば前回の記事から3ヶ月が経過してしまいました… 今回は、ビルド&Kernel編と題して、Fedora 17向けにおこなったパッケージのビルドや、KernelのConfig、TCP周りの変更点について紹介したいと思います。 パッケージのビルド OSが大幅にバージョンアップすると、依存しているライブラリに大きな変更が入ったり、RPMの仕様変更もあるため、Fedora 8時代のパッケージのリビルドなど、多くのRPMパッケージを作りなおさなければなりません。 mixiでは、Fedora標準パッケージとは別に150個以上のパッケージを、 configureなどビルドオプションを変える Fedoraで提供されないパッケージを作る ディストリビューションに依存しない構成のパッケージを作る(あとで紹介するPer
株式会社ミクシィを退職し、株式会社クロコスに入社しました。 - (」・ω・)」うー!(/・ω・)/にゃー!
新年度ですね。4/2ですね。エイプリルフール終わりましたね。 もう既にご存じの方も多いかと思いますが、3/31をもって前職のミクシィを退職し、4/1よりクロコスにJoinすることになりました。 そして今日いきなりセキュリティカード忘れて遅刻しましたごめんなさい。 クロコスへの入社について 株式会社クロコスは、ソーシャルメディア上でのオンラインマーケティングの企画やツール提供、活用支援などを主要事業とする会社です。 日本初のFacebook認定マーケティングデベロッパーでもあり、マーケティング支援ツールの他にも色々なFacebookアプリなども展開しています。 おそらく、自分とクロコスの前身であるnequalの関係について知っている人からすると、あんまり驚きもない話かもしれません。 色々と自分の中でも考えるところは多かったのですが、最終的に決断したのは、楽しい方を選ぼう・人生の最後で後悔しな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
page moved