会社で説明したのでブログにもまとめておきます。 tl;dr gitには three dot diff と two dot diff がある compare画面のデフォルトだとthree dot diffが表示される three dot diffは共通祖先からのコミットが全て表示されるモード (base側にコミットが積まれてもdiffが変わらないのでPR review時に便利) two dot diffは先頭同士のdiffを表示するモード(純粋に２つのブランチを比較するモード) 問題 あるブランチをマージする際に、意図しないコミットがdiffとして表示されることがあります。 典型的にはcherry-pick済みのcommitの内容が表示され、「すでに反映済みなのにな・・？」という疑問につながることが多いでしょう。 実際それぞれのブランチで該当ファイルを開くと全く同じ内容になっているのにもかか
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
先日、下記の記事がバズりました。(Git-itを紹介くださりありがとうございます!) www.softantenna.com この記事がバズる中で書かれたコメントを見ていると、こんなツール使わなくても仕事で使えば覚えられるのでは、といったニュアンスのコメントが散見されました。もしかしたら Git-it の位置づけと、それを補完するイベントの存在が知られてないのかなと思い、ちょっとブログに書いておこうと思った次第です。 Git-it ってなに？ Git-it は GitHubber の Jessica Lord が作った初心者向けの Git 練習アプリです*1。大元をたどると node.js コミュニティの手による Workshop アプリに端を発するみたいですが。これは Git に触ったことがない方向けの練習ツールで、特に、エンジニアじゃない方に向けてデザインされています。デザイナーであっ
次回以降の流れは？（2016/04/11 0時 追記） マンガでわかるGitの構成は、ざっくり下記の構成を考えています。 最初の一歩： Gitとはなんぞや？ 第一フェーズ： １人で使ってみる 第二フェーズ： 複数人で使ってみる 第三フェーズ： 実務上でのハウツー（応用） これは、まだ私が頭の中で考えているだけの仮段階のものですので、細部はみなさんからのコメント・需要を拝見しながら変更していくと思われます。 ちなみに、はてブコメントで要望の多かった「SVNとGitの違い」 → こちらのマンガ化はやってみたいですね。 #マンガでわかるGit 全体の構成（仮）考えるの楽しい♫ Gitってそもそも何？メリットは？ ↓ 一人でGit😃 ↓ 複数人でGit😃😃 の流れで考えています。 はじめてコミット、チェックアウトしたときの感動といったら！ pic.twitter.com/uyCl1zAxAF
Is there a shortcut to tell Git to push the current tracking branch to origin? Note: I know that I can change the default push behavior, but I am looking for an ad-hoc solution that does not change the default behavior. For example, suppose I am on branch feature/123-sandbox-tests I would be using git push origin feature/123-sandbox-tests which is tedious. I am looking for a shortcut, something li
github の pull-request を clone する設定をいつも思い出せなくて、毎回ググってるので alias を書いた。 Checkout github pull requests locally Here's fetch : 1 git fetch From github.com:gittip/www.gittip.com * [new ref] refs/pull/100/head -> o... https://gist.github.com/piscisaureus/3342247 $ git config --global alias.pr-setup "config --add remote.origin.fetch +refs/pull/*/head:refs/remotes/origin/pr/*" とすれば alias がインストールされるので、以後は pu
git fetch の裏側でどんな通信が行われてリモートリポジトリの内容が取得できるのか調べたのでまとめる。もともとは git の HTTP や SSH といったプロトコルでどのように実現されているか、というところに興味があった。Git v2.7.1 を基にしている。 事前準備 pack プロトコル pkt-line フォーマット Reference discovery Packfile negotiation Packfile の送受信 packfile への圧縮・packfile からの展開 各種トランスポートの実装 file トランスポート ssh トランスポート git トランスポート http(s) トランスポート まとめ 参考資料 事前準備 手を動かしてプロトコルを理解できるよう、gist の小さなリポジトリ を使う。適当なディレクトリ下に bare リポジトリとして clon
出張の帰りのフライトが10時間以上あったので簡単なツールをつくってみました． 余談ですが Windows PC しかなかったので，Windows PC + golang + gVim で書いてみました．Go 言語は標準ライブラリだけでもぐりぐり書けてなかなか良いですね．久々の Windows でのコーディングでしたが特に問題ありませんでした． GitHub の issue/PR テンプレート機能 最近 issue / PR のテンプレート機能が実装されたみたいです．リポジトリ直下か .github ディレクトリのどちらかに ISSUE_TEMPLATE.md および PULL_REQUEST_TEMPLATE.md を置いておくと，issue や PR 作成時にそのテンプレートが入力フォームにデフォルトでセットされます． Issue and Pull Request templates -
Webやソフトウェアの開発現場でソースコードなどの変更履歴を記録するバージョン管理システム「Git」。これをモチーフにしたユニークなRPG「ギットクエスト」が登場しました。PCやスマホのWebブラウザから無料でプレイできます。 ギットクエスト サブバー村に巨大なドラゴンの姿をした敵「並行開発」が襲ってくるところから冒険がスタート。あっけなく敗れてしまったレベル1のプログラマーである主人公は、「Subversionでは限界」と言われ、Gitを学ぶためにGit学園へと向かいます。のっけからRPGの雰囲気に似合わない専門用語がガンガン飛び出すシュールな世界観がさく裂しています。 巨大なドラゴン「並行開発」が出現 とんでもなく強い サブバー村の「Subversion」では限界らしくGitを学ぶことに Git学園でのチュートリアルや登場人物たちとの会話では、妙に本格的なGitの知識が学べます。それら
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
このエントリは はてなデベロッパーアドベントカレンダーの21日目のエントリです。 developer.hatenastaff.com id:motemen さん作のリポジトリ管理ツールであるところの ghq を最近ようやく使い始めたところ大変便利だったのですが、いかんせん手元の~/work/や~/hobby/にはすでにgit cloneしたリポジトリが山ほど転がっています。今回、それをghq管理下のディレクトリにさっと移してghqライフをスタートさせた話をします。 ghq ghq そのものについての説明は作者のid:motemenさんのエントリが詳しいので、そちらをご参照ください。 motemen.hatenablog.com 代表的な使い方は↓こういう感じで、まぁだいたいどういうことかわかっていただけるのではないかと思います。 [asato@praline01 ~]$ ghq get g
すればすぐ何もなかったことにできます。 が！そこで気付かずに GitHub へ git push してしまった！こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、__パスワードの書き換えやトークンの無効化__を施しましょう。 （この時点でもう何もなかったことになってない気がする） git の履歴から該当のファイルを消す git reset と git filter-branch 2つの方法があります。 git reset (2015-12-29
最近では、プロジェクトの修正もフォークの作成同様、簡単になりました。フォークを作成する際に作業するプロジェクトの完全な遠隔コピーをあっという間に作れるように、変更したいファイルを選択し、編集するを押して修正をコミットする事で、プロジェクト修正が行えます。 仮に、自分がプルリクエスト (以下、PR と表記) の受け取り側である場合はどうなるのでしょうか？優れた Web UI があれば助かりますし、多くの場合はそれで済みます。ボタン操作 1 つで承認、マージ、どちらも完了します。 しかし、常にそうはいきません！プルリクエスト (PR) に含まれている変更点をローカルでダウンロードして、テストをいくつか実行し、起きた内容を把握するために自身の IDE における見え方を確認しなくてはならない事もよくあります。 同僚あるいはコントリビューターのプルリクエストをダウンロードする際のステップ、即ち fe
Can't wait for the next live course to get started with Git and GitHub? If so, we have an on-demand training option designed just for you. GitHub for Developers is a self-paced course that distills best practices and documentation into a focused series of interactive lessons and covers the two most important things you need to know: Using Git to confidently manage your source code Using GitHub to
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手！) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
