We tried to load scripts but something went wrong. Please make sure that your network settings allow you to download scripts from the following domain: https://id-frontend.prod-east.frontend.public.atl-paas.net
1) Gitlab was chosen as an alternative to GitHub Enterprise due to its web UI, pull request functionality, and the fact that it could be maintained by GREE Tech's 80 Ruby engineers. 2) The company transitioned from Subversion to Gitlab by using git-svn to allow cross commits between the two systems during a period of combined use. 3) The speaker felt pull requests promoted a better development cul
HubFlowとは HubFlow: GitFlow For GitHub HubFlowはGitHubリポジトリでGitFlowを便利に使うためのGitコマンド拡張です. gitflowをforkして開発されています.datasift/gitflow · GitHub 今の時点では,大幅に便利になるというものではない感じです. git hfのようにサブコマンドhfを用いたコマンド体系なので,gitflowと併用できます. さらに,gitflowを利用している既存のリポジトリに対してもgit hf initで上書きすれば使えます. 使い方 なんか新しい図が出てますが,流れはGitFlowとほとんど変わりません. リモートブランチとfork元のブランチに対する操作が用意されていないGitFlowに対して,HubFlowでは用意されているという点が異なります. 便利になったところ git hf
これまで CVS や Subversion ではなかなか敷居の高かった「ブランチを切って作業する」というワークフローが、分散型バージョン管理、とくに Git の登場でとても手軽に取り入れやすくなりました。 Git のブランチを活用するためのワークフローとして有名なものに git-flow と呼ばれているモデルがあります。正しい名称は「A successful Git branching model」で、git-flow はこのモデルの導入を補助してくれる Git 拡張の名称だそうです。 A successful Git branching model(@oshow さんによる日本語訳) git-flow の解説~導入までは以下の記事に詳しく書かれています。 git-flow によるブランチの管理 - O'Reilly Japan Community Blog これはあくまで ”モデル” な
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
さくらのVPS+Jenkins+github+rails3の続編。 ゴールは、githubにpushすると、さくらのVPSで動いているJenkinsがgithubから最新ソースひっぱってRobolectricのテストかけた上に、apkを作るところまで。 プロジェクトの作成 mavenプロジェクトにしてみた。 ユーザーの作成 以前作ったやつで兼用。 SSH key コレも兼用しようと思ったらダメだった。1リポジトリにつき1keyだそうで。 https://help.github.com/articles/error-key-already-in-use Once a key has been attached to one repo as a deploy key, it cannot be used on another repo. If you're running into this
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20~60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
Egisonの学び方 Egisonは,Hackageから配布されている日本発のオリジナルプログラミング言語です. 本記事ではこのプログラミング言語Egisonをこれから知りたいという方のためにどういう情報があるかまとめて紹介したいと思います. - まずはインストール Hackageを使って配布しているので,Haskellユーザの方なら, $ cabal update $ cabal install egison とシェルでコマンドを打つだけでインストールすることができます. Gitをインストールしているなら, $ git clone git@github.com:egisatoshi/egison2 とすれば,ソースコードも手に入ります. - エディタの設定 Egisonプログラムを書いたり読んだりするにはエディタのEgisonモードが飛鳥です. 開発者が用意したEgison-modeと,
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
*本ブログは Bitbucket Blog を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。 *原文 : 2012 年 10 月 9 日、Justen Stepka 投稿 “Introducing the Redesigned Bitbucket“ ここ Bitbucket 本部にとって大きな一日でした。Bitbucket チームは真新しく再設計された Bitbucket のベールをはがしました。この大きなリリースの目標は、Bitbucket のウェブエクスペリエンスを一から見直し、再構築することでした。本日、新しい Bitbucket を紹介できることに興奮しています。さらに速く、簡単で、これまでにないほど美しい Bitbucket です。 新しい UI をご覧ください スピード、明瞭さ、発見のしやすさを念頭に置き、すべてのページを最適化しました。もっとも重要
GitHub - rbenv/rbenv: Groom your app’s Ruby environmentを使ってRuby環境を構築しました。Rubyは実質初めてなので、二の足を踏んだりよく分からず調べてばかりで、なかなか先に進まなかったりもしたけど、ようやく基本的な要素を把握出来た感じ。そんななので、細かく書きすぎてて若干くどいかもしれない。 rbenvのインストール $ cd ~ $ git clone git://github.com/sstephenson/rbenv.git .rbenv $ vi .bashrc #rbenv export PATH="$HOME/.rbenv/bin:$PATH" eval "$(rbenv init -)" rbenv自体はこれでインストール完了。 ここで、Terminalを開きなおす等して、.barhrcを読み込ませる。 ruby-bu
Windowsでは秀丸一途だったのですが、Macになり「テキストエディタはどれが良いかなぁ」と色々試している最中のSANTAでございます。 さて、本日のニュースに【Mac OS X向けテキストエディタ「TextMate 2」、オープンソース化される】なんて物が流れてきました。 TextMateは日本語に弱いという情報を見かけていたので試していなかったのですが、かなり人気もあるようでちょっと気になる存在ではありました。 そんな中オープンソース化のニュース。 これは何というグッドタイミング!さっそく試してみよう!と言う事で、『オープンソース化されたTextMateさんをビルドしてみた時の手順』をメモしておきたいと思います。 手探りでやっていたので間違っているところ、変な部分あるかも・・・ 準備 今回の手順ではHomebrewが必要になってくる場面がありますので、事前にインストールしておきましょ
Bazaar のホスティングサイトとして、 Launchpad があります。これはプロジェクトをまたぐ Issue Tracker やオンラインの翻訳システムが含まれており、 Ubuntu の開発に大活躍しています。 しかし、 Launchpad は github や BitBucket とは異なり、ユーザー主体ではなくプロジェクト主体になっています。ユーザーディレクトリ配下にブランチを作ることも可能なのですが、それだとマージリクエストなどの管理ができないので、本当に他人に使ってもらいたいならまずプロジェクトを作るところから始めないといけなくて面倒です。 その他にも、 Ubuntu の開発には Launchpad の機能が必要なんだろうけど、個人ユーザーには github の機能のほうが魅力的という場面がよくあります。 Launchpad で満足していたとしても、 github で開発され
Les Sociétés Civiles de Placement Immobilier (SCPI) se sont imposées comme une solution d'investissement de choix, attirant un nombre croissant d'investisseurs en quête de diversification et de rendements potentiellement plus élevés. Dans un contexte économique en constante évolution, où les investisseurs cherchent à optimiser leur portefeuille tout en minimisant les risques, les SCPI représentent
英語でこの記事を読む(Reading in English) ・4/5 追記: 好きなプロジェクトのコードが読めるPocketCodeをリリースしました。 クリスマスも当然の如く開発充なはむへいです! 僕と同じくクリエイティブで孤独なXデイを過ごす500万人のエンジニアを応援する為に 『CodeLibrary』というOSS(オープンソースソフトウェア)のコードをスマフォ上で読めるアンドロイドアプリをリリースしました! きっかけ 「OSSも読まないエンジニアって...」という記事を読んで、慌ててコードリーディングを始める 移動中にSNSを見る時間を、コードリーディングに充てたい スマフォでソーシャルにコードリーディングが出来るプラットフォームを作ろう! ベータ版ができたから公開するお^^ ←イマココ どんなアプリ? ちょっとした空き時間に、スマートフォン上でソースコードが読める、アンドロイド
gitによるバージョン管理 バージョン管理システムはつかってますか? 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な1日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 (マークアップ) されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown (略して GFM) という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 (もちろん GitHub 初心者です!) の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ (レンダリング) を気にして
gitとgithub 職場ではsvnで特に困っていないし、gitは難しいと聞いていたため、gitとgithubはずっと敬遠していた。 しかし、そろそろgithubを避けてもいられなくなってきたので(今更)gitの導入とgithubの登録を行った。 githubについては、オフィシャルの説明とチュートリアル(help.github)がとても丁寧なので、想像以上に簡単だった。 ただ、gitそのものは聞いていた通り理解に時間がかかりそう。 サインアップから設定まで https://github.com/ 最上段の「日本語にしますか?」でYesをクリック。右上の「料金・登録」→画面が変わって「無料アカウントの作成」。 ユーザ名、メールアドレス、パスワードのみで登録ができる。 その後は「Set up git」の通りで特に詰まることは無かった。 ・gitのダウンロード(※1) ・sshの設定 ・nam
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く