It has been archived by the owner. It is now read-only. 日本語翻訳に関するメモ Git や GitHub の便利な使い方をまとめたられた GitHub cheat sheet の日本語訳です。 もっと分かりやすくしたいので翻訳に関するダメ出しは歓迎です。 レポジトリ
![Git・Githubに隠された便利な機能](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)
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
これまで 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 これはあくまで ”モデル” な
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Ryan Dahl氏(Node.jsのひと)のビデオを見ていたら、最後にサンプルコードをgistコマンドで鮮やかにGistに公開する様子が大変かっこよかったので、gist.gemをインストールした。 $ gem install gist $ gist hello.js https://gist.github.com/960284 Gistの認証情報は、以下のように環境変数でも設定できるし、 $ export GITHUB_USER=juno $ export GITHUB_TOKEN=mysecretgithubtoken すでにGitHubを常用していて以下のようにgit-config(1)でユーザー名が設定されていれば、たぶん何も設定しないでOK。 $ git config --global github.user juno
■ 「Permission denied (publickey).」と言われてGitHubが使えなくなった場合の対処法 もう10日前になるのだが、自宅のマシンでGitHubからpullしようとしたら、 % git pull Permission denied (publickey). と言われるようになってしまった。他のマシンからは問題なくpush/pullともにできるので、このマシンだけの問題なんだが、忙しかったこともあり、今日になってやっと対応。分散VCSだとどこで作業しても同じだから、危機感薄いなー(笑)。 で、GitHubにそのものずばりのドキュメントがある。ヘルプのTroubleshooting SSH issuesなのだが、ようするに「鍵を作り直せ」という乱暴なことが書いてある。おまえ、sshの鍵をそうホイホイと作り直していられるかっての*1。 こういうことが堂々と書いてあるの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く