Dynamic badges Show metrics for your project. We've got badges for hundreds of services.
Dynamic badges Show metrics for your project. We've got badges for hundreds of services.
例えば、個人ではGithub、会社ではGHEのアカウントを持っているなどの場合、同じマシンでアカウント(コミッター名)を使い分ける方法。 単純に、--globalを付けなければリポジトリ単位で設定できるので、使用頻度が高い方を--globalで設定し、もう一方はリポジトリ単位で設定する。 ファイルでいうと、--globalをつけるとhomeの設定~/.gitconfigに、つけないとそのリポジトリ内の設定./.git/configに書かれるということになる。 メインのアカウント(~/.gitconfig) git config --global user.name "メインアカウントのユーザ名" git config --global user.email "メインアカウントのメールアドレス"
すでにGitとgithubアカウント(以降メインアカウントとする)を設定済みという前提で別のgithubアカウント(以降サブアカウントとする)を設定したいという場合があります。例えば仕事用のgithubアカウントとは別にプライベート用のアカウントに接続したい、案件毎に接続先を変える必要があるなどでしょうか。 すでに色々なブログで書かれていますが、具体的な手順を社内のあるメンバーに共有する必要があったので設定の手順をメモとして残しておきたいと思います。 github以外に接続する場合でも基本的には同じ手順になります。 まだgithubの設定を行っていないという方はこちらの「Set up git」の手順を進めてください。SSH Keyの生成はこちら「Generating SSH Keys」です。 また、そもそもGitって何?という方はこちら「サルでもわかるGit入門」をどうぞ。 この記事の解説
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
意外と知らない人がいるようなのでブログに書いておきます。 GitHub のアドレスのあとに .keys を付けるとその人の SSH 公開鍵が表示される。 たとえば id774 さんの公開鍵であれば https://github.com/id774.keys を参照すれば良い。 ぜひ自分のアカウントで試してみて欲しい。 新規に用意するサーバーの ~/.ssh/authorized_keys に上記アドレスを wget したものを置いて適切なパーミッションを設定しておけばすぐに公開鍵認証ができるというわけである。 もうそろそろ公開鍵をメールで送ってくれとかいう文化が滅亡して GitHub から勝手に公開鍵を持っていくのが常識な世界になってほしい。
こんにちは、chatiiです。ちょっとまじめに記事書きます。 FuelPHPでけっこう(chatiiとしては)規模の大きい案件がきたので、開発環境をキチっと決めたいと思いました。その中で、今まで手作業でやりつつ、「これ自動化できるだろ」っていうところがあり、今回うまくいったのでご紹介。ちなみに、今回はFuelPHPは関係ないです。 開発会社さんから見たら普通のことなんだろうなぁ。野良プログラマーPHPerだからせけんしらず。 環境・条件 ソースコード管理はGitHub ひとりなのに!ひとりなのに! LAMP構成 開発マシンにはXAMPP/MAMPを入れる。Linuxの場合はyum/aptで取得。 サーバーは 本番サーバー(www.hoge.com) テストサーバー (hoge.dev.example.com) テストサーバーは他人がアクセスできないようにね 他のプロジェクトもテストします
時々、興味本位で他の方のプロジェクトにforkを刺したりするのですが、そのまま放置されていて知らない間に本家の方でバージョンが上がっていたりして、自分のリポジトリが古いままって事があります。gitの事を全く知らなかった頃、やり方が分からなくて結局removeしてしまったりしたのですが、やっと更新方法が分かったのでmemo書きです。 仮にhogeさんのfugaプロジェクトをgithub内でforkしたとしましょう。 そして、hogeさんがpushして、本家の方は最新版、ところが自分のfork刺したやつは古いまま、という状況です。 この場合、次のようにすることで最新版にすることが出来ます。 git pull git@github.com:hoge/fuga.git master git push まあ、よくよく考えてみればごく当たり前なのかもしれませんが(^^;;;。 というか、刺しっぱなしに
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Eclipse上でPDTを使ってFuelPHPのプロジェクトをGit管理したかったので、EGit で github を使えるようにしてみました。 参考にさせていただいたサイトはこちら。 FuelPHPってなんじゃ?(Git管理編) Eclipse、PDT、FuelPHP は既に使える状態になっているものとします。 まずはEclipseからGitを使えるように、EGit をインストールします。 Eclipse の Helpメニュー -> Install New Software でダイアログを開きます。EGitのダウンロード用URLはデフォルトで登録されているので、--All Available Sites-- の中から Co
以前FuelPHPのインストールと簡単なアプリの作成を行いましたが、 今回はFuelPHPを使ったアプリケーションを自分の管理するGitマスターリポジトリに登録してみたいと思います。 前回のGitlabのプロジェクト登録編では、すでにリポジトリに一度pushしました。そのように未取得の変更がマスタリポジトリ上に存在する場合はマージしてからpushする必要があります。その説明は別の機会にするとして、今回はリポジトリがまだ空の状態という想定で行います。 まずはoilコマンドで適当にプロジェクトを作成します。 oil create bookstore cd bookstore/ oil createコマンドはFuelPHPを含めたアプリケーションひな形をGithubからcloneするので、Githubのgit管理下にあるため、まず.gitから始まるファイルを削除します。 rm -rf .git*
いろんなBlog巡回してると、どこもかしこもgit, gitなのでアカウントだけ作って放置してたgithubで昔に書いたちょこちょこしたコードをコミットしてみました。 github/katsuma katsuma / mt-delicious-bookmark-counter katsuma / flickr-gadget katsuma / sbm-comment さすがにはじめてのgitは戸惑うことばかりだったので、メモを残しておきたいと思います。 gitのインストール 作業OSはMac OSXです。ソースからもインストールできますが、管理しやすいようにMac portsでインストールしてしまいます。 sudo port -d sync # 同期 port search git # cogito, git-core, stgit, cgitあたりがあるはず. git-coreを選択 p
最近ソース管理にGitを使うプロジェクトがかなり増えてきました。ソース管理はSVNで十分と思っているユーザもプロジェクトの方針としてGitになった場合、最低限の操作を覚えないと作業に支障をきたしてしまいます。その際にコマンドラインで操作しても良いのですが、今までSVNでSubversiveとかSubclipseなどを使ってきたEclipseユーザは、EclipseからGitを操作したいところです。 そこでEGitを使おうと思ってもEGit自体はそこそこ歴史がある割に意外と情報が少なくて困ってしまった人もいるのではないでしょうか?。 今回はプロジェクトで使うに当たって、最低限知っておけばどうにかなりそうな操作をまとめてみることにしました。構成としては利用者側としてGitを利用することを想定してみました。実際、作業して順番とは違うのでファイルに一部矛盾するところがありますが気にしないでください
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く