GitHubダイスキー! ということで、知った時に「おっ!」と感じたGitHubに関する事項を選出してみました。 あなたに「おっ!」と思ってもらえたら幸せです。 1.入れておくと、意味を持つファイル名がある。 README.md README.mdは有名ですよね。リポジトリのトップにREADME.mdという名称でマークダウンを入れておくと、GitHubで解釈されて表示されます。 それ以外にも、あるのです。意味のあるファイル。 ISSUE_TEMPLATE.md トップか、.github/というフォルダにISSUE_TEMPLATE.mdという名のファイルを入れると、GitHubでIssueを作った時にこのファイルの内容が入ります。書くべき項目を羅列しておくとルール化できていいですよね。 それ以外にも PULL_REQUEST_TEMPLATE.md を入れておくと、Pull request
読みました わかばちゃんと学ぶ Git使い方入門 作者: 湊川あい,DQNEO出版社/メーカー: シーアンドアール研究所発売日: 2017/04/21メディア: Kindle版この商品を含むブログを見る 目次 CHAPTER 1 Gitって何? CHAPTER 2 個人でGitを使ってみよう CHAPTER 3 複数人でGitを使ってみよう CHAPTER 4 実用Git 〜 こんなときはどうすればいい? CHAPTER 5 Gitで広がる世界 読むモチベーション 普段から仕事などでgitは使っているので、今さらgitとは?のような話を学ぼうと思ったわけではなくて、本書の目次のCHAPTER 4「実用Git 〜 こんなときはどうすればいい?」が目当てでした。 というのも、基本的には必要に迫られて色々なコマンドを覚えてきたので体系的な(というか詳しい人の)「こういう時はこうする」という方法が
こんにちは、野口です。 git clone 時に、特定の秘密鍵を指定したい場面があり、どのように対応したかを紹介します。 通常の状態で git clone すると、 ~/.ssh/id_rsa の秘密鍵をみてくれます。例えば /tmp/ssh/id_rsa をみてほしい場合、どうすればよいでしょうか。 ~/.ssh/config で秘密鍵を指定する ~/.ssh/config に秘密鍵のパスを指定すれば良いです。 $ cat ~/.ssh/config Host github.com User git IdentityFile /tmp/ssh/id_rsa ただ config ファイルはいじりたくなかったので、他の方法を探してみました。すると、 GIT_SSH_COMMAND で指定する方法が見つかりました。 環境変数 GIT_SSH_COMMAND で秘密鍵を指定する $ GIT_SS
便利なソフトウェアを定期的に掘り起こすぞ活動です。 ghq は「GitHub repoのclone先を統一することでいろいろ便利にできるコマンド」で、github repoのclone先を、カレントディレクトリに依存せず ~/.ghq/github.com/$owner/$repo/ にします。 使い方: ghq get -p --shallow $URL peco は、テキストのリストをgrepしてそれに対してなにかコマンドを起動するみたいなやつで、ほかのツールと組み合わせて使います。 ghq + peco .zshrc などにエイリアスを作っておきます。 alias g='cd $(ghq list --full-path | peco)' alias b='hub browse $(ghq list | peco | cut -d "/" -f 2,3)' alias v='code
上記の例は patch を作成した時の階層と同じ階層で適用する場合。 -p オプションとは -p オプションは、パッチを適用するディレクトリのことを示している。 git diff コマンドで作成した patch ファイルだと、diff で表示される、変更ファイルのパスが、リポジトリ直下になる。 そのため、同じ階層にいる状態で patch を適用するときは -p0 オプションを使えば良い。 -p オプション使用例 man patch に書かれている -p の使用例が大変わかり易いので、以下翻訳しつつ引用する。 -p数字 または --strip=数字 オプションで使用する 別ディレクトリに存在するファイルにパッチを当てたいときに有効である。 以下の様なファイルの場合 /u/howard/src/blurfl/blurfl.c -p0 パス指定を変更しない /u/howard/src/blurf
Microsoft/GVFS : https://github.com/Microsoft/GVFS.git WindowsでのGitが余りにも遅いと言われるからか、MSがGit用の仮想ファイルシステムを作り始めてしまったようです。 簡単に言うと、GVFSを使ってCloneすると実際にはその時点では実際には何も落ちてきていなくて、必要なときに必要なファイルだけダウンロードするので、「遅い」ローカルファイルに多数のファイルが実施には無く、Gitコマンドとのやりとりは実際のファイルシステムでは無く、GVFSが受け持つので、Gitのチェックアウトやステータスコマンドのレスポンスが向上するという仕組みのようです。 この仕組みだけ読むと、ローカルでビルドしようとしたら全部のオブジェクトをダウンロードしてしまうので、結局いつも通りなのでは?と言おう疑問がわくのですが、どうなんですかね。ただ実際のところ
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
去年の失敗談から。まだ RubyGems にリリースされていない gem について、git オプションを使って以下のような指定をした。多少改変しているけれどだいたいこんな感じ。イメージは伝わると思う。 # Use therubyracer from GitHub until cowboyd/therubyracer#413 is released. # # therubyracerにRuby 2.4対応の以下のコミットが含まれたリリースがされたらgitオプションを削除できる。 # https://github.com/cowboyd/therubyracer/commit/f5966bb55a4b0434964d66ef765907d940b4c109 gem 'therubyracer', git: 'https://github.com/cowboyd/therubyracer', r
新機能作ったりする時、コード書くのに集中しすぎるとコミットする前にめっちゃ色々混ざったファイルができてしまったりして、最悪な感じになることが多い。 自分は割と細かい単位でコミットするようにしている(あとで戻せるように)ので、こうなってしまった時今まではチマチマと手動で消してaddして、commitして、undoしてみたいなことをやっていたが、ミスったりすると数時間分の作業が消える。 そういう時にはgit add -N (file path) すると、ファイルの存在だけindexに乗せることができるので、あとはgit add -pでパッチモードにしてがんばる。 そもそもちゃんと細かくコミットしろよって話でもある。
24 Pull Requests 達成した。 Happy Holidays に辿り着いた。明日も仕事だけどな。https://t.co/ugqnGm4mIC pic.twitter.com/xdIvzTyhQs— Koichi ITO (@koic) 2016年12月19日 内訳としては、Unify Fixnum and Bignum into Integer まわりの PR が多かったと思う。 いつも通り定番となっている ghq + gem-src で管理しているリポジトリ群を対象に対応していた。内訳で多かった PR の元としていた手順は以下。 自分の場合は rbenv global 2.4.0-dev としているので、だいたい Ruby 2.4.0 に向けた新しめの開発版を使っている前提。 手元にある ghq root 配下のリポジトリに対して The Silver Searcher
ターミナルから tig refs と打つと refs の一覧画面が表示されます。 さらに、refs の中から checkout したいものを選択し、 Shift + c を打つと、選択したものにチェックアウトすることができます。 大変便利な機能ですが、ローカルブランチだけでなくリモートブランチやタグも表示されてしまいますので、 ローカルブランチだけを見たい場合には表示される量が多すぎますし、 また、チェックアウト時には本当にチェックアウトをするか否かの確認の [Yy/Nn] を打たなければならず、確認を飛ばしたくなる場合もあるかと思います。 そこで、git のエイリアスとして、tig に倣い git refs を用意しました。 .gitconfig に [alias] refs = !git checkout $(git branch | peco | awk '{ print $NF }
-u, --set-upstream For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1). 全く何を言ってるのかわからない! 答え ネットで検索してみたら答えがわかった。 git push -u origin master とすると次回から git push だけで勝手に origin master で push してくれる。 ちなみに git push とかの マニュアルは全て man git-push とか man gi
初めまして。アジャイル事業部新人の @junk0612 です。 今回はエイリアスの話をします。 長いターミナル生活、みなさん少しでもタイプ数を減らそうと日々努力なさっていることと思います。 タイプ数の削減に一番簡単に効果をあげられるのがエイリアスですよね。 そこで、事業部のメンバーがよく使うエイリアス、おすすめエイリアスをまとめてご紹介します。 もし気になるものがありましたら、ぜひ日々の生活にお役立てください。 おすすめエイリアス アジャイル事業部では、ほとんどのプロジェクトで Ruby on Rails を使用している関係上、 bundler 系、git 系のエイリアスを設定している方は非常に多かったです。 alias be='bundle exec' alias bi='bundle install' alias bo='bundle open' alias bu='bundle up
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く