第5回テックヒルズ『Go to Git !』～さらばSVN～ 番外編 - ぱと隊長日誌
昨日の『第5回テックヒルズ『Go to Git !』～さらばSVN～ レポート』 http://taityo-diary.hatenablog.jp/entry/2013/03/23/154425 の続きで後日談というか、番外編というか、Twitterや直接お話を伺ったことをまとめます。直接お話を伺ったことも基本的にはtweetしているので、それをまとめる形にします。 ◆ブランチの使いどころ @jo7ueb ブランチはどんな場面で活用しますか？— ぱと (@pato_taityo) 2013年3月22日 @pato_taityo 機能追加とかは間違いなくブランチ切ります．失敗して偉いことになったとしても，えいやっと戻ることができて心理的な障壁が下がると思います．あと，特定の作業に関するコードを集中させられるってのも美味しいと思います．— Neppo Telewisteria (@jo7ue
【業界注目】CROOZ主催の勉強会“テックヒルズ”が5度目の開催 今回のテーマは？【開発者専用】 | ファミ通App【スマホゲーム情報サイト】
2013年3月22日、CROOZが主催する“第5回テックヒル ズ”が、都内の六本木ヒルズ内アカデミーヒルズで行われた。次世代技術の可能性を追求する開発者向けの技術勉強会として、CROOZが昨年から定期的に実施しているこのイベント。これまで、 “全文検索＆検索を利用したサービスの使命、利用プロダクト、事例紹介”、“「ネイティブアプリ」vs「Webアプリ」これからのアプリケーション開発の トレンド”、“2012..Flashの終焉!? ～Flashの今後を見抜く～”、“UI、UXの衝撃”といった、そのときそのときの旬な開発技術をテーマに、ゲスト見識者を招いてのプレゼン、パネルディスカッションが行われている。 ★前回の第4回テックヒルズのレポート記事はこちら そして、“Go to Git！ ～さらばSVN～”と題した今回のテックヒルズのテーマは、近年ウェブ業界で注目を集め、多くの技術者に認知され
gitレポジトリをhttpで公開する
Original Setting up a git repository which can be pushed into and pulled from over HTTP(S). まだ試しちゃい無いんですが、gitレポジトリをhttpで公開したくなった場合にどうすればいいのかについて。 何が必要か Apache ウェブサーバをもっていること Apache の設定ファイルを編集できること 設定ファイルは /etc/httpd にあるか、 Apache のドキュメントを参照してください。 Debianの場合: /etc/apache2 下にあるファイルを編集できる必要がある。 Apache を再起動できること 'apachectl --graceful' とするかもしれません。 もし、そうしない場合、 Apache を停止して、再起動してください。 注意してください、これによりあなたのサー
Git
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
危なくないgitこと、うちのチームのgit戦略草案(ver. 1)
この記事は更新された版があります 2012/11/16: いただいたフィードバックをもとに、version 2を書きました。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常用しているような環境です。 gitは、以下のように使えば安全です。 mergeに相当する操作をしない rebaseに相当する操作をしない …悪い冗談。極端な話ですね。しかし、「merge/rebaseの回数を減らせば、トラブルが起こる確率を減らすことができる」というのは事実です。 そこで、GitHub(Enterprise)の利用を前提に、こう
必殺！Github導入に向けて上司を説得する時に使える資料まとめ · DQNEO日記
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか？ 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である（ｷﾘｯ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します！ (Piece of Cakeさんを追加しました。） (サイボウズさんを追加しました。） これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 ＼（サイボウズ）／ ＼（ペイパーボーイ）／ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
git cherryでブランチ間のコミットのdiffを。色もつけて - ( ꒪⌓꒪) ゆるよろ日記
git cherryで、ブランチ・ツリー間のコミットのdiffを見ることができる。 git cherry [-v] [<upstream> [<head> [<limit>]]] デフォルトでは、upsteamに無いコミットは"+"で、逆にheadになくてupstreamにあるコミットは"-"で表示される。それとsha1のみ。味もそっけもない。 "git cherry -v"で、コミットログもでる。 これでも充分だけど、もっとdiffっぽく色付けたり、Autherや日付表示したりしたい。のでこんなalias書いた # colorized cheery -v cch= "!f() { git cherry -v "$@" | awk '{ if($1 == \"+\"){ color = \"green\" } if($1 == \"-\"){ color = \"red\" } cmd =
最近の git の使い方について - tomykaira makes love with codes
先日の #shibuyarb の懇親会ですこし話したら、わりと食い付いてもらえたので、 knowledge worth spreading だと感じた。git の設定を中心に共有する。 ワークフロー @kyon_mm さんの Continuous Commit の熱心な信奉者である。 Continuous commit とは continuous integration, continuous delivery とおなじように、開発中のコミットを自動化する試みである。 continuous commit という言葉はなくても、おなじようなことを自分でやっているひとは多そうだ。 continuous commit は大量のコミットログを残すので、これを整理する作業はけっこう負荷が大きくなる。 最近はこのあたりを改善している。似たようなワークフローを採っている人には役にたつと思う。 コミットを
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
アリスとボブのGitシリーズが本になりました！ - ザリガニが見ていた...。
サポート情報を追記しました。 アリスとボブのGitシリーズとは、4年前の2008年9月5日から始まる以下の一連の日記です。 アリスとボブになりきってgitをちゃんと理解したい！ - ザリガニが見ていた...。 アリスとボブのコラボレーション、gitをちゃんと理解したい！ - ザリガニが見ていた...。 アリスとボブのサーバー、git pushをちゃんと理解したい！ - ザリガニが見ていた...。 アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい！ - ザリガニが見ていた...。 これらの日記は、最近になってもじわじわブックマークされ続けている隠れた人気記事です。（ありがたいことです、感謝） 上記の日記がベースとなって、書籍化のお話を頂き、半年かけて執筆しました。（超スローペースです） アリスとボブのGit入門レッスン（Amazonへのリンク） アリスとボブのGi
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Paperboy's engineer evaluation system その後 - Gosuke Miyashita
Paperboy's engineer evaluation system で書いた、ペパボの技術者評価制度、2回目の評価が完了しました。 前回は、 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、結果（通過 or 不通過）、評価ポイント、今後期待すること、を評価者が追記し、git push する。 といった流れで、今回も基本的には同じ流れなのですが、2. の部分のやり方
メモ 【git】gitの練習【githug】
「githug」でgitの基本操作を算数ドリルみたいに学ぼう！で紹介されていたgitの練習ツールgithugを試してみました。 インストール環境 githugはgemでインストールするため、Rubyをインストールしている必要があります。自分の環境は以下のようになっています。 ruby -v ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32] gem -v 1.7.2 インストール 下記コマンドを実行します。 gem install githug 以下、インストールされたものです。これらのriとRDocもインストールされました。 Successfully installed diff-lcs-1.1.3 Successfully installed grit-2.3.0 Successfully installed githug-0.2
Gistで遊んでみる - 日々常々
GitHubにはコードの断片を管理したり人に見せたりブログに貼付けたりするのに便利なGistってのがあります。 通常の使い方では、ブラウザで貼付けたりとかすると思うのですが、GistもGitのリモートリポジトリなので、クライアントから使う事も出来ます。 ……ってのはGistにも普通に書いてるんですけどね。 Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. とりあえずやってみます。 色々やってみる まず適当に作ります。 GitHubはお金払わないとプライベートなリポジトリは作れないのですが、Gistだ
10 things I hate about Git
Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt. 1. Complex information model The i
ワンランク上のGit使いになるために手元に置いておきたい「Gitポケットリファレンス」 - Glide Note
Gitポケットリファレンス 下記3つはいずれもcommitの修正ですが、違いが分からない人は Gitポケットリファレンスを読むことをオススメします。(答えはGitポケットリファレンスに書いてあります。) 以前書いたとおり社内SubversionリポジトリをGitHubへの移行中で GitHubへの本格移行する前に、「運用ルール決め」と「意識合わせ」の意味で 社内のインフラ系エンジニア向けに「Git、GitHub講習会」と銘打って勉強会を開催。 個人的にはGitHubも活用してて、Git自体も理解しているつもりだったんですが、 人に説明していると、理解があやふやな点が結構あることがわかったので、 先日発売されて、周りの評判も上々なGitポケットリファレンスを購入。 Gitの概念について説明している書籍は多数発売されていますが、本書はGitの一つ一つのコマンドについて 見やすく説明されているの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitのsubmoduleに変更を加えるとdiffが生じるのを無視する - Qiita
Git でマージ済みのブランチを一括削除する - Qiita
http://blog.inouetakuya.info/entry/20120826/1345979787
続続・イラストでわかるgit入門の入門：checkoutをする
