An error occurred when getting the results, please click here to try again or modify your search criteria.
There are a few specific things we’ve done at GitHub to help our maintainability and reliability of our Ruby apps. Focusing on improving documentation, optimizing the first-run experience, splitting out our API as Sinatra apps, and being careful about how we ship impacting infrastructure changes has helped us out dramatically. Slides
Delivering deploymentsUsing the Deployments REST API, you can build custom tooling that interacts with your server and a third-party app. Using the REST API to interact with checksYou can use the REST API to build GitHub Apps that run powerful checks against code changes in a repository. You can create apps that perform continuous integration, code linting, or code scanning services and provide de
今，フォークしたリポジトリのリモートブランチだけがある． $ git remote origin本家のリモートリポジトリの短縮名を登録する． $ git remote add github git://github.com/D-Programming-Language/dmd.git本家の更新をローカルで反映させる． $ git pull --rebase github masterフォークしたリモートリポジトリをpullしてからpushして本家に追随させる． $ git pull origin master $ git push origin master 自分のコミットを常に一番最後のコミットにしておきたいなら まず，ここで説明することは，他の人と共有しているリポジトリではやるべきではない． それを踏まえた上で，自分のコミットを常に一番最後のコミットにしておきたいならば --force
Redmine のリポジトリブラウザから git リポジトリを参照する場合、 ローカルのリポジトリしか参照できない。 そのため、github のリポジトリを直接参照することはできない。 はてな のように cron を使って同期してもよいのだが id:mzp に github のリポジトリと Redmine のリポジトリを 同期するプラグインがあることを教えてもらったので その設定方法をメモ。 条件として、Redmine が外部からアクセスできる必要がある。 できない人は SSD Cloud Hosting & Linux Servers - Linode とかを借るといいと思う。 環境 Redmine: 1.0.0 git: 1.5.4.3 redmine_github_hook プラグイン: Rev.b3ce0cdd4252fd54f8d0404795327b62112b15a0 red
7月11日、fluxflexはこれまでベータ版として運営していたクラウドホスティングサービス「fluxflex」のインターフェースを一新し、正式版を公開した。fluxflexはAmazonの提供するAmazon Web Services（AWS）のEC2を利用してホスティングするサービス。 fluxflexはEC2の持つスケール、従量課金といったメリットをそのままに、従来のコマンドに加えてウェブインターフェースを提供し、インフラ技術者以外でも柔軟にEC2を利用できるようにしたものだ。 ベータ版で試用した際は、アカウントを作成するだけでEC2のホスティングが完了し、ウェブに公開されるサーバが立ち上がった。レンタルサーバをセットアップしたことがある人なら、それよりも簡単で驚くはずだ。 そして今回、何よりも特筆すべきは「GitHubインポート機能」だろう。fluxflexが「世界初」と語るこの機
GitHub, Inc.のmojomboことTom Preston-Werner氏が2008年の12月に書き上げてそのままお蔵入りにしていた、「GitHubの1年目から学んだ10の教訓」というエントリが公開された。 Ten Lessons from GitHub's First Year 10の教訓は以下の通り。詳細は元エントリをご覧ください。 早く始める (Start Early) 顧客に合わせる (Adapt to Your Customers) 楽しむ (Have Fun) Twitterに注意をはらう (Pay attenton to Twitter) 意のままにデプロイする (Deploy at Will!) オフィスはいらない (You Don't Need an Office) オープンソースを通じて雇う (Hire Through Open Source) チームを信じる
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
■ [git][github][tDiary] master ブランチで pull request していいのは小学生までってこともない GitHubへpull requestする際のベストプラクティス - hnwの日記を読んで感じたこと。 このエントリではmasterブランチで pull request していいのは小学生までと言われているけど、少なくとも tDiary ではどうでも良いからパッチ送れとしか思わないなあ。 具体的には master ブランチで作業したものを pull request しても別にコードの内容に問題がなければがんがん取り込むし、コンフリクトがひどかったり、なんじゃこりゃというのは差し戻すのでパッチを投げる側は気にする必要はない。繰り返すけど、Gitのお作法よりもコードの内容の方が重要ってことを頭に置いた方が良い。 もちろん、件の記事のようにちゃんと Git を
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
最近ホントにRubyの人々の間でgit流行ってますよね。私はdarcsっこなのですが、これだけ周囲で流行られるとさすがに危機感を感じます。しかも最近はgithubやらgitouriousやらのやたらと便利なサイトが出現し、ましてRubyForgeまでもがgitを採用とのことですから、これはもうなんとかしておきたいところです。というわけで、今更ながらgitを覚える口実として、とっても便利なgithubを使ってみることにしました。 http://github.com/ そこでせっかくですからgithubの使い方をメモしておこうと思います。これを読んで皆さんも一緒にgithubで遊びませんか？ そもそもgithubとは何モノ？ github はgitレポジトリを公開してくれるサイトです。出来ることは大体のところ次のような事です。 作者はレポジトリを作成して公開できます 他の人はレポジトリをフォー
昨日ひさびさにgithubを触り、followしている方のプロジェクトを見ていたら、ソースを落としたくなりました。 前提：単純にソースを見たい、プロジェクトを追いかけたいというだけならば、watchしてcloneすればOKです が、何を間違えたか、ついforkを押してしまい、めでたく自分のプロジェクト一覧に人様のプロジェクト（をforkしたやつ）が追加されました。。。 あわてて消そうにも、消し方わかんねー って事で一晩放置していたのですが、今見たらあっさり見つかりました。 という訳で以下手順 自分がforkしたプロジェクトのトップに移動( ex : ttp://github.com/masartz/hoge/tree/master ) グローバルメニューの「admin」をクリック Administrationの「Delete This Repository…」をクリック 「Delete R
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
gitとgithub 職場ではsvnで特に困っていないし、gitは難しいと聞いていたため、gitとgithubはずっと敬遠していた。 しかし、そろそろgithubを避けてもいられなくなってきたので（今更）gitの導入とgithubの登録を行った。 githubについては、オフィシャルの説明とチュートリアル（help.github）がとても丁寧なので、想像以上に簡単だった。 ただ、gitそのものは聞いていた通り理解に時間がかかりそう。 サインアップから設定まで https://github.com/ 最上段の「日本語にしますか？」でYesをクリック。右上の「料金・登録」→画面が変わって「無料アカウントの作成」。 ユーザ名、メールアドレス、パスワードのみで登録ができる。 その後は「Set up git」の通りで特に詰まることは無かった。 ・gitのダウンロード（※1） ・sshの設定 ・nam
Git % ./configure --without-tcltk % make % sudo make install % git config --global user.email higepon@xxxx.com 初期設定 % mkdir spon % git init % git add ./tools.mosh.sls % git commit -m 'first commit' % git remote add origin git@github.com:higepon/spon.git % git push origin master 変更と反映 # ファイルを変更して % git commit -a % git push origin master 共同編集 github のプロジェクトの編集で Collaborator にメンバー追加すると共同編集できる。 higepo
Gitという分散リポジトリシステムを使い始めました。 これ自体は、MacだとMacPorts使えば楽に入ってくるのですが、 まぁローカルで管理していてもあんまりうまみがない。 せっかくならば、外にソースを公開して、みんなでいじくりまくれる リポジトリを構築したほうが良い。 そこで便利なのが、githubというサービスです。 簡単に言えば、gitのリポジトリを作成＆管理する為のサービスです。 自分でサーバーたてて管理するコストが減る為かなり楽です。 Free版だと、１００ＭＢまでという制限がありますが、まぁ普通に使う分には、 問題ない容量でしょう。登録してある言語は、Rubyが多く、ＬＬな人達からの 人気の高さが伺えます。 まずは、アカウントを作っておきます。 これは、github.comに行き、好きなアカウントを作成してください。 特にアバターの設定は、ちとはまるので、私のこのエントリーを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
