もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
gitでpush前のcommitの一覧をリスト記法で取得する - $shibayu36->blog;
github上でコードレビューをされた時、あるコメントに対する変更点を列挙して、「こういうふうに直しました」と言いたい時がある。こういう時にpush前のcommitをリスト記法で貼り付けたい。 なんか出来ないかなと思ったら、以下のようにしたら出来た。 $ git log @{u}..HEAD --format="- %H %s" - 2b237548bcd779abd3f15d413b3540f4c8699cd2 perlで使っていないモジュールを検出してくれる - 998d3198bf96ab545f315005128342e124941bc4 fix - 3434242410997a2be106b3596b810539c5fce0f4 IntelliJの起動ショートカット - ae0ab4f3397587282b87ed3de8754e971bd0c8c6 gopath - 8f8a2
複数のremoteにgit pushしたい - ふり返る暇なんて無いね
git remote set-url --add ${remote} して上げれば良い。 # git clone git@github.com:masasuzu/p5-Acme-LoveLive.git cd p5-Acme-LoveLive git remote set-url --add origin git@bitbucket.org:masasuzu/p5-acme-lovelive.git # git push この例だとgithubとbitbucket両方にpushするようになっているが、githubと社内のgitサーバ両方同期したいときにどうすれば良いのかなーと調べて出てきた一つの答えがこれ。 定期的にcronで同期させるとタイムラグがあるのに対して、こっちだとリアルタイムに同期出来るのが利点かな。ただ、cloneした後にこの設定忘れると、社内のミラーレポジトリが古いままにな
--force は有害だという考え; git の --force-with-lease を理解する / Atlassian Japan
Git の push --force は有害です。何故ならローカルの内容を無条件にリモートレポジトリを上書きしてしまい、チームメンバーがその間にプッシュしていた変更を上書きてしまうからです。しかし、これには改善策があります。強制プッシュがどうしても必要ではあるけれど、他人の作業を上書きしないようにしたいときは --force-with-lease というオプションを利用します。 Git の push --force は共有レポジトリにプッシュされた他の変更を破壊する可能性があるので、利用すべきではないことは良く知られています。常に完全に失われることにならなくても (もし変更が他人のワーキングツリーに存在していればマージすることは可能です)、これは無分別な対処であり、最悪の場合は大きな損害を招きます。何故なら --force というオプションはブランチの先頭をローカルの履歴に設定し、これまで
git svn 環境でのリポジトリ再配置 ( svn switch --relocate に代わる何か ) - do_aki's log
Subversion リポジトリの場所が変わった場合、 svn switch --relocate 旧リポジトリ 新リポジトリ というコマンドで、リポジトリの再配置ができるのだけど、 Subversion リポジトリを git svn を使って管理している場合はどうすればいいのか分からなかったので調べてみた。 コマンドは存在しない google 先生にお伺いを立ててみたところ、 [git][svn]git-svn使用時におけるsvnリポジトリの移行 ( http://d.hatena.ne.jp/walf443/20090811/1250005053 ) git svn での switch のやりかた ( http://d.hatena.ne.jp/naga_sawa/20110306/1299422744 ) というのは見つけた。どうやら、 svn switch --relocate に
受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)
会社で受託開発していて、gitを使った開発フローを考えることになった。 ニアショアに開発をお願いしていて、ニアショアからの受け入れタイミングが何回かあるから、それにあわせてブランチをわけている。 どういうフローで進めているかと、一番最後にやってみて思ったことを書いた。 どういうフローでやっているか リポジトリの構成 下記モジュールを用意した。 parent core entity common web batch tools ニアショアにて開発するモジュールは『common』、『web』、『batch』で、 アーキにて開発するモジュールは『parent』、『core』、『entity』。 ブランチ ブランチはこんな感じで分けている。 ちなみに、ソース管理はgitBucketを使った。 masterブランチ … リリース可能な状態の資源のみを管理する。結合テスト実施時は、本ブランチから資源を
Gitの便利な-pオプション四兄弟 - エンジニアをリングする
この記事はGit Advent Calendar 2014の6日目の記事です！ （更新がお昼になってしまいました、ごめんなさい＞＜） みなさん！ Gitの-pオプション使ってますか？ 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します！ 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね！ 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
Linusが2週間でgitを作った話。 - 未来のいつか/hyoshiokの日記
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
とうとう Git 2.0 が現実のものに。便利な機能満載 | Atlassian Japan 公式ブログ | アトラシアン株式会社
長い間待たれてきた git のメジャーバージョンアップがリリースされました。Changelog に目を通し、素晴らしい機能を見つけられることに興奮しています。過去の git リリースの情報をおさらいしたい場合は、バージョンアップのたびにその情報を特集してきた私の過去記事をご覧ください: 1.8.2、1.8.3、1.8.4、1.8.5、1.9。 このブログ記事では、今回のバージョンアップの一部しか取り扱うことしかできません。変更とバグ修正の完全リストをご希望の場合は、Changelog の完全版をご覧ください。 デフォルト設定一部変更: ユーザビリティの改善と混乱を解消 まず最初に、互換性に影響する変更を見ていきましょう。複数の変更がありますが、これらのアップデートは、初心者にとどまらず多くの人々を悩ませてきた誤解を解決するもので歓迎できると思います。これらの変更は、.gitconfig を
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
AWSアクセスキーをgitに誤って登録しないようにする | DevelopersIO
はじめに Gitはとても便利ですが、GitHub上で不適切に公開されている秘密鍵を使ってAWSに不正アクセスする事例が発生 というようにAWSアクセスキー、シークレットキーを誤って登録してしまうととても恐いことになります。利用者側で気をつけられるようにGitのフックをつくってみましたので報告します。 Git フックとは? Gitにはフックというなにかの操作の前後にスクリプトを実行できるような仕組みがあります。これを使うことにします。コミットの前に気づければよいのでpre-commitを使うことにします。サンプルファイルが .git/hooks/pre-commit.sampleにありますが、今回はシンプルにしたいので、.git/hooks/pre-commitをスクラッチで作ります。 アクセスキー混入防止フック とてもシンプルです。git diffをしてその中に KEYという行があり、さら
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
GitHub で Pull Request を Merge したらコードが消えた話
会社で使ってる GitHub のプライベートリポジトリで master ブランチに対して出てる Pull Request を Merge したらコードが消えるという珍事があった。ファイルを削除する commit とかないにもかかわらず、全消しされてしまった。ちなみに同じ Merge を手もとでやるとコードが消えたりはせずちゃんと Merge された。極めて謎な現象だった。 master ブランチが空になるとデプロイができなくなって不都合があるので（ Webistrano 上でデプロイするとき master ブランチからしかデプロイできないようなレシピになってる）、コードが消滅したブランチを bukkowaremaster にリネームして手もとで Merge したブランチを force push してしのいだ。 GitHub に問い合わせてみたところ、ぬるい感じの一次返信が来たので原因教えて
[Git] HEADの代わりに@が使えるようになったＹＯ！ · DQNEO日記
Git 1.8.5から、HEADと書くかわりに@が使えるようになったようです。 Instead of typing four capital letters "HEAD", you can say "@" now, e.g. "git log @". https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.5.txt 試してみた git log $ git log -1 @ commit db9bdfbeb044f73a01f6325f4ad61413666a2ce0 Author: Junio C Hamano <gitster@*****.***> Date: Fri Oct 18 13:53:05 2013 -0700 Update draft release notes to 1.8.5 Signed-of
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Release Git for Windows 2.5.0 · git-for-windows/git
Multiple SSH keys for different github accounts
『Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう』へのコメント
