It has been archived by the owner. It is now read-only. 日本語翻訳に関するメモ Git や GitHub の便利な使い方をまとめたられた GitHub cheat sheet の日本語訳です。 もっと分かりやすくしたいので翻訳に関するダメ出しは歓迎です。 レポジトリ
![Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet(日本語訳) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a8b2deba06a8b00a3e114b0f65eaccf58e91e7f0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9R2l0JUUzJTgzJUJCR2l0SHViJUUzJTgxJUFCJUU5JTlBJUEwJUUzJTgxJTk1JUUzJTgyJThDJUUzJTgxJTlGJUU0JUJFJUJGJUU1JTg4JUE5JUUzJTgxJUFBJUU2JUE5JTlGJUU4JTgzJUJEJTIwJTdDJTIwR2l0SHViJTIwQ2hlYXQlMjBTaGVldCVFRiVCQyU4OCVFNiU5NyVBNSVFNiU5QyVBQyVFOCVBQSU5RSVFOCVBOCVCMyVFRiVCQyU4OSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9Mzc0YmRmZjU4MDJmM2I0ZDcwMTI2YTJjNGZmN2I4ZjE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB1bmJhYmVsJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wMzM0NzY1NzFmOGQwMmJhOTk4NzM5OWViNzM4YWU5OA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Ddf91349feb13ddc5b04ea0213e01f21e)
気づくと1週間経っている恐怖(´ω`) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム(現在は3人)で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
GitHub や GHE を使って多人数で開発していると,プルリクエストを横断して試す必要が頻繁に発生すると思います. プルリクエストを次々に試したり,#30 と #31 をマージした結果を試したい!なんてケースもあるのではないでしょうか. GitHub では git ls-remote すれば分かるように,プルリクエストの番号と対応したブランチがリモートに存在しているので,これを取得してみます. .git/config に追記(あるいは git remote add とかで適当に) [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ(丸投げ): https://gist.github.com/3342247 git fe
GitHubで人気レポジトリのランキングが公開されているようなので全解説してみました. どれも素晴らしいものばかり! あなたのプログラミングライフを快適にしてくれるライブラリがきっと見つかるはず!! rails rails 9835 watching Ruby on Rails. 説明不要だよね! フルスタックWebフレームワーク jquery jquery 8710 watching JavaScriptライブラリ.これも説明いらないよね! node joyent 8572 watching 旧名node.js.昔の名前の方が通りがいいです.JavaScriptエンジンのV8用のノンブロッキングIOな何か.主にWebサーバ/アプリケーションに使われる. html5-boilerplate paulirish 6998 watching HTML5とかのテンプレート集.ただし公式ページのデ
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Gitという分散リポジトリシステムを使い始めました。 これ自体は、MacだとMacPorts使えば楽に入ってくるのですが、 まぁローカルで管理していてもあんまりうまみがない。 せっかくならば、外にソースを公開して、みんなでいじくりまくれる リポジトリを構築したほうが良い。 そこで便利なのが、githubというサービスです。 簡単に言えば、gitのリポジトリを作成&管理する為のサービスです。 自分でサーバーたてて管理するコストが減る為かなり楽です。 Free版だと、100MBまでという制限がありますが、まぁ普通に使う分には、 問題ない容量でしょう。登録してある言語は、Rubyが多く、LLな人達からの 人気の高さが伺えます。 まずは、アカウントを作っておきます。 これは、github.comに行き、好きなアカウントを作成してください。 特にアバターの設定は、ちとはまるので、私のこのエントリーを
Github API (version 2)のメモ。主に情報取得系のAPIについて。 概要 ドキュメント http://develop.github.com/ フォーマットにxml,yaml,jsonを指定できる。以下ではXMLを指定する。ブラウザで見やすいので。 http://github.com/api/v2/:format (URLのベース) 取得系のURLパターン。 ID不要 repos/search/キーワード …… リポジトリ検索 repos/show/ユーザ …… ユーザのリポジトリ一覧 repos/show/ユーザ/リポジトリ …… リポジトリ情報 commits/list/ユーザ/リポジトリ/ブランチ …… 最近のコミット(コミットID、ルートツリーIDが得られる) commits/list/ユーザ/リポジトリ/ブランチ/パス …… 最近のコミット (コミットID、ルート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く