Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
どうも、まるさ@maruuusa83です~。 mixiさんが開催するgitに関する(!)イベント、Git Challenge 2015に参加してまいりました! gitの競技イベントって珍しいですよね。言われてみれば確かに問題たくさん作れそうな気がする。 alpha.mixi.co.jp 参加のきっかけ git便利!git最高!みんなgit使おうぜ!!!!! とか言ってる割に、まだ仕事しているわけでもないので大真面目にgitを使ったプロジェクトの経験がありません・・・。 「後輩にgitを勧める本書いたりしてるくせにそんなハンパでどうするんじゃ!!!!」 ということでgit challengeに参加して心をすり減らそう、新しいgitの世界を見つけよう、ということで参加させて頂くことにしました。 実際の競技 GitHubから問題となるリポジトリをcloneしてきてギコギコ修正してpushする、と
http://commit-m.minamijoyo.com/:titele という有名OSSのコミットメッセージを検索できるサービスがあって、英語のコミットメッセージを書くときに「あれ? これどういう風に書けばいいんダー」ってときに例文を検索できて捗る。 commit-m.minamijoyo.com が、自分の場合はコミットメッセージ書くときはvim とか git commit -m とかからなのでCLIで検索できたらより捗るかと思ってGolangで書いた。 APIとかは無いようなのでクロールしてる。 GoQuery 使えばこの手のクローラーが一瞬でかけるのでよさがある。 github.com go get github.com/yuroyoro/gommit-m で入れた後に gommit-m keyword [page] で検索できる。
この記事は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に新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
!やねん、いつも忘れてまうねん。 Quick reference for tig keybindings: [-] status bindings External commands: 'C' `git commit` [-] branch bindings External commands: 'C' `git checkout %(branch)` [-] main bindings External commands: 'C' `git cherry-pick %(commit)` [-] generic bindings View switching 'm' view-main Show main view 'd' view-diff Show diff view 'l' view-log Show log view 't' view-tree Show tree view 'f'
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
インターネットには、Git submodule を使っては いけない という記事が飛び交っています。私はこれらの記事が言うほどひどいものとは思っていませんが、そういった主張が大方正しいことは認めます。以前の投稿でも説明しましたが、submodule は利用価値のあるユースケースは少なく、逆にいくつもの欠点があります。 では、これに代わるものはあるのでしょうか? 答えは「ある」です。Git の利用は続けつつ、プロジェクトにおけるソフトウェアの依存関係を追跡することができるツールが (少なくとも) 二つあります : git subtree google repo この記事では、git subtree に注目し、完全とまではいえないもののそれが git submodule の問題を解決するものであることを説明しようと思います。 実例としていつもの私のユースケースを取り上げます。自分の dotfi
ファイル編集がコンフリクトした場合 下記はよくある(忌々しい)コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか? vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。(Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・) gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
使用言語に応じた .gitignore ファイルを簡単生成 .gitignore ファイルとは git リポジトリで index に入れたくないファイル(またはフォルダ)を定義するファイルのことですが、この .gitignore を毎回書くのって面倒ですよね。もちろん自動生成してくれるフレームワークや IDE もありますし、GitHub のようにリポジトリ作成時にデフォルトで作ってくれるサービスもあります。 とはいっても自分で作るときもあると思います。そんなとき役立つツールが「gitignore.io」です。このツールを使うとコマンド一行で .gitignore ファイルを生成することができます。といっても URL を叩くだけなんですけどね。 まずはインストールしましょう。Mac OS X の場合は以下のコマンドでインストールできます。 echo "function gi() { curl
この記事はGit Advent Calendar 2013の12日目の記事です. 前日は@sonotsさんのgit current-branch, git fetch-pulls, git pull-dry-run など git alias ネタでした. gitはコマンドを実行するとき,まずgit --exec-pathのパスの中からコマンドを探し,なければユーザーのPATHの中からコマンドを探して実行します. そのためPATHの通った場所にgit-コマンド名という実行ファイルを置くだけでユーザーが自由にサブコマンドを作れる便利な仕組みとなっています. ということで,pythonでgitのサブコマンドを作ってみました. git-ls-date ton1517/git-ls-date このサブコマンドはファイルを最初にコミットした日付と最後にコミットした日付(とそのハッシュ)を表示するコマン
皆さんzsh使ってますか。 oh-my-zsh使ってますか。 oh-my-zshはzshの便利ツール的なものですが、これ自体の説明はしません。ぐぐったら山ほど出てくると思います。 このエントリで紹介したいのは、このoh-my-zshのgit pluginを入れた時に設定されるaliasです。 git pluginは.zshrcにplugins=(git)と書いてからoh-my-zsh.shを読み込んだら使うことが出来ます。 oh-my-zshのzshrcテンプレにplugins=(git)と書いてあるからそのままにしてあるけど結局何が変わるのか分からないっていう人多いんじゃないでしょうか。僕はそうでした。 で、git pluginを入れると何が起こるかというと、gitのaliasとfunctionが読み込まれます。 具体的にはこれらが読み込まれます。 https://github.com/
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか?これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか?それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか?( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる
stash workspace index local repository upstream repository status Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the workspace and the index file, and paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く