Google、「Cloud Source Repositories」正式公開。Gitベースのソースコード管理ツール、5ユーザー、50GBまで無料Cloud Soruce Repositriesは、Google Cloud Platform上でホストされるGitリポジトリ。プライベートなGitレポジトリをいくつでも持つことができます。 ソースエディタ機能も備わっており、レポジトリの内容のディレクトリ表示、ファイルのコンテンツ表示、2つのソースファイルを開いて差分を表示することなどが可能。
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を使ったローカルリポジトリの統一的・効率的な管理について - 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のお作法に、他の言語のリポジトリも含め、すべてあわせる
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは 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 で複数のリポジトリをまとめたり、逆に切り出したりする - Qiita
~/repo1/subdir に ~/repo2 を入れる あるリポジトリのサブディレクトリに別のリポジトリの中身を入れたいとき。たとえば、あるリポジトリのサブディレクトリを切り出して別のリポジトリとして管理しているものを、元のリポジトリに合流させたいとき。 cd ~/repo1 git remote add repo2 ~/repo2 git fetch repo2 # サブディレクトリの内容に repo2 の内容をマージする # （repo2 と内容が似ているサブディレクトリを自動で判別） git merge -s subtree repo2/master # ↑でうまくいかないときにはパスを指定する↓ git merge -X subtree=subdir repo2/master # そもそも ~/repo1/subdir が存在しないときには↓ git read-tree --p
[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/61bcac80a1da9fdcc62997a7502b04ccd6936e47/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJTIwLmdpdGlnbm9yZSVFMyU4MSVBRSVFNCVCQiU5NSVFNiVBNyU5OCVFOCVBOSVCMyVFOCVBNyVBMyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MGNmOWFiNjA3ZWI2ZGJiYmE3YzNjOWUzZjA4MzYyNzY%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MWI2YjM3NTQ2NWU2MzcxNDBlNWEzZjNkY2NjMTI2MTQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd88115df7ea0f316615170ac01433804)
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
git でメールアドレスやら名前やらを間違えて commit してしまったときの修正方法 - ..たれろぐ..
ネット上で複数のアカウントやら人格やらを使い分けてる git 使いの方必見。 git でメールアドレスやら名前やらを間違えて commit してしまったときの修正のやり方。 きげんよく開発＆コミットをしてきてふとコミットログを確認すると、 D:\ToaruGitNoRepository>git log -2 commit d104bc235464568b95bf18b00e00583b90a8ccbb Author: foo Date: Tue Jan 4 17:48:40 2011 +0900 新環境に合わせて環境変数設定用のbatファイルを更新 commit e566fc3bde92333b1e60f9cb508cbd13ba4f0cbe Author: hogehoge Date: Tue Jan 4 17:20:44 2011 +0900 関連ファイルの再配置 「やっべ！裏アカウン
「Git 2.8」リリース、「CRLF」改行コードへの対応強化や細かい機能追加などを含む | OSDN Magazine
オープンソースの分散型バージョン管理ソフトウェアGitの開発チームは3月28日、最新版となる「Git 2.8.0」をリリースした。Git for Windowsプロジェクトでの成果物が取り込まれているほか、細かい機能強化が多数加えられている。 Git 2.8は1月に公開されたGit 2.7に続く最新版。この間、74人の開発者から532のコミットがあったという。このうち22人は新規の貢献者とのことだ。大きな仕様変更や新機能はなく、使い勝手の向上に繋がる細かな修正がメインのリリースとなっている。 「git push」コマンドでは、「–delete」オプションと同じ挙動をする「-d」オプションが追加された。これにより、「git branch」コマンドなどと同様に「-d」オプションでリモートリポジトリ内のブランチ等の削除が可能になる。 設定関連では、プロクシに対する認証方法を設定する設定変数「ht
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
gitで管理しないファイルを無視させる .gitignore - misc - @OMAKASE
.gitignore とは名前からも分かるように git で無視するファイルを指定するファイルです。 .gitignore は通常トップディレクトリに置きますが git ではディレクトリのみを管理しないためルートディレクトリ下のサブディレクトリなどにも置く事が可能です。 .gitignoreで指定できる書式 ハッシュ記号で始まる行はコメントとして扱われる 空行は無視される ! マークで始まる行は残りのパターンを否定します スラッシュ/で終わる場合はディレクトリのみを表す スラッシュ/で始まる場合はルートディレクトリからを表す どこにもスラッシュ/が無い場合はシェルのglobパターンとしてファイル名のベース部分にマッチするか検査される 複数マッチするパターンがある場合は最後にマッチするものが優先される 設定できる.gitignoreパターン色々 *~ ファイル名の最後に ~ がある全てのファ
Tig の表示方法あれこれ - Qiita
Tig の表示方法あれこれ このエントリーはGitアドベントカレンダーの十一日目です。十日目は kyanny さんの「Git における SSH オプション指定方法あれこれ」でした。タイトルは、パクr...リスペクトしました！ Tigとは？ Tig は ncurses ベースの Git のためのテキストユーザインタフェースです。 Gitリポジトリ内の変更内容を、Vimライクな操作で高速に閲覧することができます。 インストール Mac なら Homebrew か MacPorts でインストールできます。 あとはこちらで。 基本的な使い方 Git レポジトリ内で tig コマンドを打つと、カレントブランチの変更履歴が表示されます。 h でヘルプが見られるので、ビューの切り替え方法などの操作方法を調べることができます。 本題 tig コマンドに引数を渡す事で、開き方を変えることができます。 特定
CUI な Git ブラウザ tig を入れてみた - Born Too Late
Git をなかなか使いこなせずにいる私ですが、これはいい ! コンソールから使える git ブラウザ、tig が超便利 Vim に近い操作感で使えるのが Vim 使いには非常に嬉しいところです。以下で、インストール方法と基本操作について紹介します。 インストール インストールは、まずソースコードからやってみたのですが、パッケージが存在することに気づいたので、 aptitude で入れ直しました。 sudo aptitude install tig はい、簡単ですね。 起動する カレントディレクトリを Git のワークツリーに移動して、 tig コマンドを実行します。 $ cd /path/to/work-tree $ tig ヘルプを表示する: h 何はともあれ、わからないことがあればとりあえず h を押してヘルプを調べましょう。 カーソルの移動: j, k Vim ユーザなら、何の問題も
Git 作業における commit と push の頻度について - Qiita
注意 この記事は、2014年に投稿されたものです。 時代は変わっても運用におけるベースは大きくは変わっていませんが、投稿としては古い内容ですのでご注意下さい。 未だにストックなど多くいただきますので注意事項として、追記させていだきます。 以下本文です。 はい、今更かもしれませんが。俺としてはGitを扱う上で結構重要だと思っている commitやpushの頻度 について書きたいと思います。はじめに断っておきますが技術的なテクとかの話ではないです。ほとんどが 言われてみれば当たり前じゃん 程度の内容だと思って下さい。 ですが、flowとか運用方法 とか gitを使いこなすちょっとしたテク なんかより重要だと思っているのは俺だけでしょうか...？ どの単位でコミットしたりプッシュしていますか？ みなさん、どのような単位でコミットしたりするようにしていますか？未だに 適当にやってる みたいな人がい
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git logでコミットの差分の中身で絞り込む - Qiita
コミュニケーションツールとしての Git & GitHub
GitHub GITチートシート