git configをプロジェクトによって使い分ける - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Git2.9のキレイなdiffを出すためのconfig - Qiita
Git 2.9 has been released https://github.com/blog/2188-git-2-9-has-been-released 昨日キレイなDIFFが出せるgit2.9がリリースされました。 homebrewで brew upgrade git な感じでアップグレードすれば2.9は入るのですが、 このキレイなDIFFは標準では有効になってないので、記事にあるとおりに設定を行いましょう。 だいたい以下のような感じのコマンドうてばいいと思います。 下準備：diff-highlightにPATHを通す まぁ通さずに直接読んでもいいんですが、通しておきましょう。 homebrewでいれるとdiff-highlightさんは↓あたりにいるのでPATHを通しておきましょう。 export PATH=$PATH:/usr/local/Cellar/git/2.9.0/s
ghq, peco, hubで快適Gitライフを手に入れよう！ - Qiita
はじめに peco, hubは前から使っててghqは存在は知りながらも「別にリポジトリ管理は必要ないかなー」と思ってたのですが、管理するリポジトリ数が増えてきて面倒になってきたので試しに入れてみたらかなり良かったので紹介したいと思います ghq, peco, hubとは？ ghq ghqは上でも軽く書いたようにリポジトリ管理ツールになります。 例えばgit cloneの代わりにghq get <repository URL>とコマンドを打つとghqルートディレクトリ（デフォルトでは~/.ghq）以下にリポジトリがcloneされ、 ghq listでghqルートディレクトリ以下のGitリポジトリ一覧を表示、 ghq look <project>で指定したリポジトリに移動する、といったように使います。 peco pecoは文章で説明するのは難しいのですが、CLI上で例えばps auxなどのよう
ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。（前は zsh だったのでなんだかなーと思ってた。） そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート（デフォルトで ~/.ghq）以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
GitHubで使われている実用英語コメント集 - Qiita
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Jenkins PipelineでGitリポジトリにpushする - GeekFactory
JenkinsのジョブでGitリポジトリにブランチやタグをpushしたい場合があります。Jenkinsfileでどのように実装するか調べてみました。 実装例 お急ぎの方は下記のコードを参考にしてください。 def userRemoteConfig = scm.userRemoteConfigs.head() withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: userRemoteConfig.credentialsId, usernameVariable: 'GIT_USER', passwordVariable: 'GIT_PASSWORD']]) { def url = userRemoteConfig.url.replace('://', "://${env.GIT_USER}:${env.
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
Git 別のリポジトリを履歴を残したまま取り込みたい - かもメモ
Gitで別々に作ってたリポジトリをコミットログを残したまま1つにしてしまいたい時のめも。 例えばkankore_repoとkuchikukan_repoという2つのリポジトリが別々にあったとします。 これらを別々のリポジトリで管理するのが大変になってきたのでkankore_repo内の'destroyer'ディレクトリに kuchikukan_repoで管理していた全てをコミットログを残したまま入れてしまいたい。そんな感じです。 図で書くと /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git /kuchikukan # kuchikukan_repo リポジトリのあるディレクトリ |--- .git これを ↓ のような感じにしたいのです！ /kankore # kankore_repo リポジトリのあるディレクトリ |--- .git |--
[Git] .gitignoreの仕様詳解 - Qiita
対応バージョン この記事の内容は、少なくともGitのバージョン2.19.1までは対応している。 もし最新のGitで新しい動きがあれば随時更新する。 基本 .gitignoreを使うと無視する（Gitのトラッキングの対象外とする）ファイル or ディレクトリを指定できる。 .gitignoreは複数のディレクトリに置くことができる。 深い階層の.gitignoreに書かれた指定の方が優先順位が高い。（後に解釈される） .gitignore内の記述は上の行から順に以下のように解釈される。 /を含まない行（fileなど） .gitignore以下の全サブディレクトリ下にあるこの名前のファイル or ディレクトリを無視する 末尾以外にのみ/を含む行（/file, /path/to/file, path/to/fileなど） .gitignoreが置いてあるディレクトリをカレントディレクトリとする相
![[Git] .gitignoreの仕様詳解 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2a04ab07b13d19d2c325ad2107adf968e241eda0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMTA2NzYwJTJGcHJvZmlsZS1pbWFnZXMlMkYxNDczNzEwMDM1P2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZmbT1wbmczMiZzPTI3NjczNjgwMTYxNjQ0M2FjMTg0NmQyYTMwY2Q0ZGM5%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Da20672cbe4ba9aa0bb37457861a3f85f%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCR2l0JTVEJTIwLmdpdGlnbm9yZSVFMyU4MSVBRSVFNCVCQiU5NSVFNiVBNyU5OCVFOCVBOSVCMyVFOCVBNyVBMyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTkyYmE1YmEwOWQ2N2RkZjE5ZDY3ZmFhNzViOWE4NjU5%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWRhNGM0OWVkMWE1MzMzMWU2YTYwYjMyZmQ3N2E1NjZh%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Dd0ab91f14b79c60c2ded46a11f180c3c)
gitignoreまとめ - maeharinの日記
Gitで無視ファイルを細かく設定する際にはまったので、メモ ヘルプ こまったら、これで $ man gitignore web版 前提 まずは前提を抑えておかないと、はまる 既にトラックされたファイルはgitignoreが効かない $ git init $ touch hoge.txt $ git add hoge.txt # トラックされた後に $ vim .gitignore # 無視設定しても hoge.txt $ git status # 効かない 既にトラックされたファイルを無視対象にしたければ、git rm --cached $ git rm --cached hoge.txt # 上記のトラックされたファイルをインデックスから削除すれば（ワークツリーはそのまま） $ git status #gitignoreが効く # もしhoge.txtをcommit済みの場合 $ git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google、「Cloud Source Repositories」正式公開。Gitベースのソースコード管理ツール、5ユーザー、50GBまで無料
GitHubユーザーのためのhubコマンド - Qiita
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ChangeLog を支える英語
git logでコミットの差分の中身で絞り込む - Qiita
Git で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
