サイバーエージェントのGitHub活用 ～ 導入から運用体制、開発フロー、勉強会による現場への普及活動まで
また、Organization[1]の数も360を超え[2]、リポジトリ数もOrganizationのものだけでも2000近く作られています[3]。 新規のプロジェクトは基本的にGitを利用しており、既存プロジェクトもほとんどがSubversion（以下SVN）などからGitに移行しました。 本記事では、Ameba事業本部がどのようにGitを組織内に普及させていったか、その運用体制、現場でどのように利用されているのかをご紹介します。 [1] 複数アカウントをまとめるグループ機能です。リポジトリは個人単位だけでなく、Organization単位で作ることもできます。 [2] プロジェクト単位で1つのOrganizationを用意しています。 [3] 個人アカウントで作成したり、他からforkしたリポジトリは除いた数です。 GitHub Enterprise導入への道のり GHE導入以前の標準
GitHubのmasterを壊しちゃったらなる早でやってみたいこと - Qiita
概要 GitHubで管理しているブランチ（特にmasterとか）を git push -f origin などしちゃってｱｯｰした場合、やってみると幸せになれるかもしれない手順です。 http://www.objectpartners.com/2014/02/11/recovering-a-commit-from-githubs-reflog/ のパクリです。 まずやること 落ち着く GitではすべてのコミットはSHA1ハッシュで一意に管理され、たとえブランチを上書きしてもGCされるまで消えることはありません。 特に、GitHubではすべてのコミットが保存されているので落ち着いて上書き前のコミットを探しましょう。 次にやること 以下の手順に従って、git push -f で上書きされる直前のコミットを特定して復元し、master に戻します。 GitHub APIのトークンを取得する ここ
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
WebデザイナーもGit使うといいよって話 | Cherry Pie Web
※この記事では「Webデザイナー」は、「ノンプログラマ」の意味で使っています。 psd、ai などの材料データの管理ではなく、サーバーにアップするファイルの管理の話です。 サルでもわかるといわれても、やっぱりわからない・・・ Web制作をやっている人は、少なからずバージョン管理システムの話を聞いたことがあると思います。 特にGit（ギット）っていうのは、内容まで知らなくても名前くらいは聞いたことがありますよね。 で、ネット上ではバージョン管理システムのメリットに関するブログ記事なんかもたくさんあって、変更履歴をたどれるとか、複数人で同じファイルを修正したりといった時のトラブルに対応できるとか、なんか便利そうだなーとは思っていたわけですが、ずーっと導入は見送ってきました。 その理由は・・・ 「Git入門」とか書いてある記事を読んでも導入方法が書いてあるだけで、実際に使うシチュエーションが思い
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 の使い方 - Gosuke Miyashita
必殺！Github導入に向けて上司を説得する時に使える資料まとめ - DQNEO起業日記 でペパボも取り上げて頂いたので、ペパボでの GitHub の使い方について、少し詳しく書いてみます。 開発での利用 これは普通の使い方ですね。なので省略。 GitHub Enterprise は利用していない 金額的な面で GitHub Enterprise の利用は厳しいため、GitHub Enterprise ではなく、ノーマル（？）な GitHub を利用しています。（GitHub Enterprise にすると、現在のコストの 8 〜 9 倍ぐらいになってしまう。） ここはセキュリティ面とのバランスが難しいところではありますが… とはいえ、GitHub に何かあってソースコードが流出した場合に影響の大きさが懸念されるサービスについては、GitHub を利用しない、といった判断もしています。（で
Git の Web インターフェース比較 - Qiita
普通に管理するよりも何かしら見やすいインターフェースを使った方が便利なので比較。 GitHub 多数のサービスと連携できるので便利。数百単位でプライベートリポジトリを持ちたい場合は下記オープンソースのものを使った方がいいかも。 Gitorious 多機能であるのにも関わらず、オープンソースで利用できる。きれいで使いやすいインターフェース、GitHubでいうところの PUll Request に当たる Merge Request 機能まである。チームごとにメンバーやできたり、プロジェクトごとにリポジトリを管理できるので、大きな組織で使いたい場合に良い。Issues はない。インストールはかなり面倒。 GitLab 最近公開されたオープンソースのインターフェース。かなり良くまとまっている。Gitorious ほど大きくないのでインストールもそこまで難しくない（と思う）。コミットも多いので、これ
プロキシ経由でgithubにpull&pushする - 豆無日記
(2009/07/13追記)勘違いしていた部分や、今までできなかったことを修正・補足しました。 (2011/03/09追記)ときどきこっちの記事に引っかかる人もいるようでなんか申し訳ないので追記。今はGithub側でhttps経由でのpushにも対応してるのでこのバッドノウハウは不要です。http://d.hatena.ne.jp/nobeans/20100423/1271983544 やりたいこと 自分の管理管轄外にあるプロキシに閉じ込められた環境からgithubへつなげたい。pullだけじゃなくpushもしたい。 方針 以下の2つのサイトの折衷案みたいな方法でうまくいきました。 gitをHTTP Proxy経由で利用したい場合の対処法 - RX-7乗りの適当な日々 http://d.hatena.ne.jp/rx7/20080703/p1 cl.pocari.org - connect
GitHubにプロキシ経由でpushする(Windows環境) - wadahiroの日記
簡単そうで意外と簡単にできない。ググると色んな方法があるようで、それが混乱の元となっているように感じます。さらに、LinuxとWindowsという環境の違いもあるし。 GitHub自体はHTTPSに対応しているようなんですが、どうもうちの環境だとNGみたいです。なので将来的には、下記のHTTPプロキシの設定だけでいいかも。 git config http.proxy http://my.proxy.url:80 認証プロキシだとこうかな。 git config http.proxy http://user:pass@my.proxy.url:80 これでうまくいく幸せな人は、以降の話は不要なので無視してください。 残念ながら私はうまくいかなかった環境でした。で、とりあえずHTTPSはあきらめ、SSH経由でのpushでうまくいきました。参考にしたサイトはここです。 必要なもの msysgit
ウノウラボ Unoh Labs: 秘伝のペケペケrcをつぎたす仕事
こんにちは。murahashi です。 秘伝のペケペケrcの継ぎ足し方―あるいはbashrc, vimrc, screenrc それぞれについて別の場所のファイルを読み込む方法、再読み込みする方法―をまとめました。 どこかからコピペしてきたドットファイルを継ぎ足し継ぎ足しで自分に合わせた設定をつくり、それをいろんなところに持ちまわっている人は多いと思います。どうせならということで github や bitbucket や coderepos に公開している人もいるでしょう。 私も dotfiles という1ディレクトリにファイルをまとめて github にpush、使いたい場所でgit cloneして ~/dotfiles/.bashrc へのシンボリックリンクを ~/.bashrc に置いて「やったー」と喜んでいました。 ただ、この方法だとサーバの環境によって変えたい部分が出てきたとき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git-flowでもgithub flowでもない、Git本家推奨のワークフロー
GitHub Flow (Japanese translation)