githubで2段階認証を設定したらpushできなくなった - Qiita
$ ssh -T git@github.com Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts. Hi myoan! You've successfully authenticated, but GitHub does not provide shell access. Username for 'https://github.com': myoan Password for 'https://myoan@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/myoan/repository.git/' しかも、
develop ブランチなんてオワコン
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
zshでgitの状態（編集有り / 未commit / 未push）を表示する - 寄り道ばかりの お勉強日記★
情報元 基本、 (zsh版)pushし忘れないようにプロンプトに表示するようにした - ゆろよろ日記 のまんまです。 表示イメージ testという名前のブランチにいるので右のほうに「@test」と出ている 次に vi .vimrc とファイルを編集したので「@test-」というように「-」で編集した（unstageな）ファイルがあることを示す 次に git add .vimrc で編集したファイルをステージングすると「@test+」というように「+」でステージングされたファイルがあることを示す 最後に git commit でステージングされたファイルをコミットすると「@test?」というように「?」で未pushのコミットがあることを示す というようにします。 事前準備 zshのバージョンが 4.3.10 以降である必要がありますので、古いようでしたら事前にupdateが必要です。 .zs
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
Git に関する良記事 - あどけない話
適宜追加します。 Pro Git 僕が読んだ Git の書籍の中では、一番分かりやすいと思いました。日本語版の書籍はありませんが、オンライン版が翻訳されています。 Pro Git 図解 Git Git の初心者が動作を理解するのにおススメ。 図解 Git こわくない git ブランチとマージの考え方がよく分かるスライド(@methaneさんから教えて頂きました)。 こわくない git あなたの知らないGit Tips 書籍には載ってない Tips の解説。知らないと損するかも。 あなたの知らないGit Tips ワークフロー、あるいはブランチング チームでブランチを使う際の取り決め。自分のチームで一から議論するより、すでにあるものを参考にしましょう。 git-flow github-flow Github Enterprise Github Enterprise は、企業内に設置して使うこ
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
GitHubのnew Page Generatorがヤバい - すぎゃーん日記
Instantly Beautiful Project Pages · GitHub プロジェクトページから、ボタン一発でオサレなプロジェクトページが作れるようになった。やばい。これはやばい。 試しに自分のdotfilesで作ってみた。 dotfiles by sugyan デザイン選択するだけで、サクっとこんなのが出来ちゃう。ヤバい。まじヤバい。 最初から結構種類があるし、どれもイカしていてカッコイイ。 今まで作った全リポジトリのProject Pageをコレ使って勢いで作ってみたくなっちゃうし、コレを有効活用するためにもっとツールとかライブラリとか書こう！って気になる。 GitHubすげーーー！
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Gitのベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
jekyllで作る簡単GitHub Pages - T.I.D.
jekyll（ジキル）は、テンプレートを使って静的な Web サイトを構築するための Ruby プログラム。 通常はローカルに jekyll をインストールするが、GitHub Pages では必ずしも必要ないという話。 通常の手順 こちら に基本的な手順の説明。 ローカルな Ruby 環境に jekyll をインストール する jekyll に必要な テンプレートファイル群 を構成し、_config.yml や テンプレートファイル を設定する YAML で記述した先頭ブロックの レイアウトとタイトル に続けて、 HTML、Markdown、textile のいずれかの記法を使って記事を書く jekyll で HTML ページを生成し（jekyll --server --auto）、ローカルで確認（http://0.0.0.0:4000/）、デプロイ（_site に生成されたページ群を
GitHub Pagesホスティングサービス（ほぼ）完全活用ガイド | ゆっくりと…
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでやらかした時に使える19個の奥義 - Qiita
Homebrewで入れたgit,zshを優先的に利用する - Glide Note
GTUG Girls原稿
http://papix.hateblo.jp/entry/2013/05/22/032747
いつやるの？Git入門
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
