「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。Read less
天下一gitconfig大会(サイボウズ社内git勉強会@2012/11/20)の@teppeisの資料です。 ぎっとぎとにしてやんよ GistDeck gistでmarkdown書いたらbookmarkletでプレゼンになるよ。 ↓これをBookmarkに登録してこのページで実行してみよー! javascript:(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.setAttribute(%27src%27,%27https://raw.github.com/teppeis/gistdeck/fix/gistdeck.js%27)%3Bdocument.getElementsByTagName(%27head%27)%5B0%5D.appendChild(s)%3B%7D)()%3B 複数行のcodeとかが微
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました! > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった!という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
主催の皆様素晴らしいイベントの提供本当にありがとうございました。 まさかの2連覇ですが、@fujiwaraの恐ろしさを再認識するとともに、@typesterのチート性能を見せつけられた感があります。 まずは個人的な反省点から 去年よりかは大分成長しているつもりだったのに、@fujiwaraとの力関係が何もかわっていなかったことに衝撃 @typester(Redis期)がRedis使ってくることはわかっていたのに、競技中に brew install redisとかやってるのはダサすぎ ということで、isucon2を振り返ります。 事前準備 事前にIRCチャンネルを作っておいてnopate botを呼んでおいたくらい。カヤックから別チームも出ていたので、お互いのチャンネルには入らないという紳士協定。 去年の経験から、revサーバーに直接gitリポジトリを作れれば捗ることは分かっていたので、その
必殺!Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル(?)な GitHub を利用しています。(GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。) ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。(で
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか? 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である(キリッ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します! (Piece of Cakeさんを追加しました。) (サイボウズさんを追加しました。) これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 \(サイボウズ)/ \(ペイパーボーイ)/ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
リポジトリだけじゃ終わらないGitHubの魅力に迫る Gitリポジトリの「GitHub」が最近注目を浴びています。Gitを使っていなくても、ほとんどの人は名前くらいは聞いたことがある人は多いと思います。今年の3月に、あるサンプルアプリのソースコードがGitHubに公開されたというニュースが話題になり、GitHubの知名度が日本でも高まりました。なぜ話題になったかというと、そのサンプルアプリが日本のダンスグループ「Perfume」が踊っている姿のモーションキャプチャデータを使ったものだったのです。 Gitは強力なツールですが、Gitというキーワードが先行しているので、GitHubのことを「Gitリポジトリが使えるWebサービス」くらいにしか感じてない人も見掛けます。 しかし、一昔前は貧弱だったGitHubのIssue(チケット)機能も最近のバージョンでは大幅に強化され、GitHubは情報共有
こんにちは、chatiiです。ちょっとまじめに記事書きます。 FuelPHPでけっこう(chatiiとしては)規模の大きい案件がきたので、開発環境をキチっと決めたいと思いました。その中で、今まで手作業でやりつつ、「これ自動化できるだろ」っていうところがあり、今回うまくいったのでご紹介。ちなみに、今回はFuelPHPは関係ないです。 開発会社さんから見たら普通のことなんだろうなぁ。野良プログラマーPHPerだからせけんしらず。 環境・条件 ソースコード管理はGitHub ひとりなのに!ひとりなのに! LAMP構成 開発マシンにはXAMPP/MAMPを入れる。Linuxの場合はyum/aptで取得。 サーバーは 本番サーバー(www.hoge.com) テストサーバー (hoge.dev.example.com) テストサーバーは他人がアクセスできないようにね 他のプロジェクトもテストします
英語でこの記事を読む(Reading in English) ・4/5 追記: 好きなプロジェクトのコードが読めるPocketCodeをリリースしました。 クリスマスも当然の如く開発充なはむへいです! 僕と同じくクリエイティブで孤独なXデイを過ごす500万人のエンジニアを応援する為に 『CodeLibrary』というOSS(オープンソースソフトウェア)のコードをスマフォ上で読めるアンドロイドアプリをリリースしました! きっかけ 「OSSも読まないエンジニアって...」という記事を読んで、慌ててコードリーディングを始める 移動中にSNSを見る時間を、コードリーディングに充てたい スマフォでソーシャルにコードリーディングが出来るプラットフォームを作ろう! ベータ版ができたから公開するお^^ ←イマココ どんなアプリ? ちょっとした空き時間に、スマートフォン上でソースコードが読める、アンドロイド
あまりにも男性にモテないまま歳を取ってしまい、 結婚しないで人生終わるかも?!という危機感を感じ、 人生のパートナーを募集します。m(_ _)m パートナーの条件 1.たばこを吸わない人(必須) 2.アルコールを飲んでも性格が変わらない人(必須) 3.中学、高校、大学時代の友人と現在も交流が続いている人が5人以上いる人 (Facebookを含む) 4.職場並びに仕事関係者以外で1年以上付き合いのある友人が20人以上いる人(Facebookを含む) 5.ご近所の人(老若男女)と30分以上楽しく会話ができる人 6.小学生以下の子供と一緒に遊ぶことが好きな人 7.野菜と納豆が好きな人 8.外国人と気さくに20分以上話せる人(日本語でもOK) 9.問題があっても他人のせいにしない人 10.レジャーの計画(旅行、趣味)を立てて実行に移すことができる人 11.大金持ち、美男美女、芸能人、著名人を
Hashです。ミームの人と呼ばれていた時期が俺にもありました。現在、株式会社ジモティーでエンジニアをやってます。公私ともにidで呼ばれ、本名を忘れがちなのが最近の悩みですが、別に悩んでいません。 ジモティーのエンジニアは5人で、基本的にまんべんなく仕事をやるもののある程度得意不得意があって、僕はインフラというかサーバの世話をすることが多いです(諸般の事情により名刺にはインターフェイスエンジニアと記載されているのですが…)。 そこで今回は「ジモティーを支える技術」と題して、ジモティーの使っている技術をざっくり紹介したいと思います。まぁタイトル使いたかっただけじゃね感あります。 Rails3 Ruby on Rails 3でWebアプリケーションを開発しています。 ウェブサービスとして見たときジモティーはいわば今風の「掲示板」で、トリッキーな作りは少ないためRailsとの相性は良いのではない
GitLabはRuby/Ruby on Railsで作られたGitHubクローンです。 GitHubは有料でプライベートリポジトリが持てますが、それでもセキュリティ上の理由でリポジトリを外だしできないケースはあるかと思います。そんなときに使ってみたいのがGitLab、GitHubクローンです。 ログイン必須になります。 ログインした後の画面です。登録済のプロジェクトが一覧表示されます。 一つのプロジェクトを閲覧しています。ソースツリーが出ます。ソースツリーは右へ右へスライドして表示されます。GitHubに似ています。 ソースコードハイライターも内蔵されています。rawでファイルをダウンロードできます。 タグやブランチを切り替えることもできます。 コミット履歴一覧です。 コミット詳細ではDiffが確認できます。 コミットに対するコメントも確認できます。 チーム設定です。複数人でのコラボレーシ
RubyDropはRuby製のオープンソース・ソフトウェア。個人的にDropboxはとても便利に使っている。これなしの生活は考えられないくらい便利だ。有料であれば50GBまで使えるが、無料版の2GBでは物足りないと感じる人も多いだろう。だがお金は払いたくないという人もいるだろう。 サーバ起動中 そこで考えたいのが自分だけのDropbox構築だ。重要なのは自動的に同期されるシステムであること、バージョン管理されること、複数のコンピュータ間でデータが同じ状態に保てることだろう。それらを実現するのがRubyDropだ。 RubyDropはRuby1.9系で動作するソフトウェアだ。簡単に言えば、特定のフォルダに関してRubyDropが監視を行う。そして変更があると内容をリモートのGitリポジトリにアップデートする。Gitリポジトリ側で変更があれば、Pullする仕組みだ。 自動的に同期されている G
今年に入ってから、急速にGitが注目を浴びています。Google Trendsを見ると、Subversion、Mercurialなどに比べると圧倒的にGitの人気が高いのがわかります(図1)。 図1 Google TrendsによるGit(青)、Mercurial(赤)、Subversion(橙)の検索数 しかしながら、Gitを利用する人の意見は2つに分かれています。 A.わかりにくい B.すごく便利だ なぜこのようなに印象が二分されてしまうのでしょうか? 本稿では、「Gitに潜む光と闇」と称してこれらの意見に対して考察していくことにします。 Gitはわかりにくい? Gitがわかりにくいと思う人は、どうしてそう感じるのでしょうか。そのあたりのおおよその事情は下記のようなことだと考えられます。 (1)Subversionとコマンド体系が少し違う バージョン管理ツールとして、Su
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス(原文)に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く