自分流ローカルでのgitの使い方 | Webシステム開発／教育ソリューションのタイムインターメディア
他人の開発画面、覗いてみた事ありますか。 覗いてみた事が無い方は、是非見せてもらってください。意外と面白いですよ。 gitのコミットの仕方ひとつとっても、人によって全く違うんだなと思うはずです。 git使いが10人いれば、使い方も10通りなんだなと、他人のコンソール覗きこむたびに感じます。 私の場合、プロジェクトが数ヶ月から半年に一度変わる（または並行して複数のプロジェクトに入る)という事が多く、いろんなgit使いの方に触れる 機会が多いです。 コンソール上でgitを操作する人、SourceTreeやEclipseプラグイン等のGUIツールで操作する人、git rebaseを多様する人、全くしない人、コミットグラフが綺麗な人、汚い人（そもそもあんまりこだわりを持っていない人?)、コミットメッセージを日本語で書く人、英語で書く人。。。 私は、「git pull」というコマンドを使う事はほぼ無
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
transitive.info - git log 使い方
git log 使い方 コミットログを表示する git log とするとページャが起動して（設定による） コミットログが表示される。 パッチ形式のコミットログを表示する コミットログと変更点のパッチ形式を表示するには「-p」オプションを使う。 git log -p コミットログとファイルの変更の状態を表示する git log --stat とすると diffstat が表示される。また、 git log --name-status とすると変更されたファイルの名前とステータスが表示される。 コミットログを指定した数だけ表示する たとえば、最近のコミットログを 5 つだけ表示するには「-<num>」か「-n」オプションを使って git log -5 git log -n 5 とする。 特定の範囲のコミットログを表示する 「<since>..<until>」で指定する。 たとえば、 git l
fugitive.vim が便利すぎたのでメモ - 反省はしても後悔はしない
Vim から Git を操作するプラグインとしては、今まで git.vim を使っていたんですが、fugitive.vim のほうが便利だったので乗り換えました。 詳しい説明はここ VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; ここでは、自分が特に便利だと思った機能を書きます。 git add -p をグラフィカルに行う git add -p を使うと、複数の変更箇所のうちどの変更をコミットに含めるかを選ぶことができますが、fugitive の :Gdiff を使うとこれをグラフィカルに行うことができます。 :Gdiff コマンドはインデックスとワークツリーの状態の差分を vim の diff で表示します。 こんな感じ たとえば、スタイルシートの設定（上のほうの差分）はコミットに含めたいけど、クラス属性の付与（下の
Gitを一人で使うときのメモ - minus9d's diary
Mac, Linux, CygwinなどのCUIからGitを使う時の個人用メモ。 準備 Gitの設定を行う。 $ git config --global user.name "Your Name" $ git config --global user.email your_email_address@example.com $ git config --global core.editor emacs $ git config --global color.ui autoとすると、設定が~/.gitconfigに書き込まれる。 リポジトリを作る バージョン管理したいディレクトリに移動し $ git initとすればOK。自動的に.git/ディレクトリが作られる。やっぱりバージョン管理したくなくなったときは、.git/ディレクトリを消せばよい。 コミットする git addして次のコミットに
git 1.8.2 リリースノートを眺めて、新機能把握と設定を追加 | Act as Professional
世の中はGoogleリーダーで盛り上がってる中、Livedoor Readerに移行した@HIROCASTERでございませう。 そんななか、ひっそりと git 1.8.2 がリリースされました。 リリースノートを眺めていたら知らない機能があったので書いておきます。 git check-ignore * “git check-ignore” command to help debugging .gitignore files has been added. 1.8.2からの新機能です。 .gitignore ファイルに記述されてい内容と実際のファイルが該当するかチェックできます。 例えば .gitignore ファイルに /tmpと書いたとします。 $ git check-ignore -v ./tmp .gitignore:1:/tmp ./tmpのように1行目の設定に該当して、exclu
git-flow cheatsheet
About git-flow are a set of git extensions to provide high-level repository operations for Vincent Driessen's branching model. more ★ ★ ★ This cheatsheet shows the basic usage and effect of git-flow operations ★ ★ ★ Basic tips Git flow provides excellent command line help and output. Read it carefully to see what's happening... The macOS/Windows Client Sourcetree is an excellent git gui and provid
Git 1.8.3 について知っておくべきこと | Atlassian Japan 公式ブログ | アトラシアン株式会社
あなたが git をコマンドラインで使っていようと、SourceTree などのツールから使っていようと; また、コードを Bitbucket にホスティングしていようと、Stash で会社のファイアウォール内側にホスティングしていようと、もしあなたが私のようであれば git がリリースされたときはいつでもパーティーをするでしょう – ウィンク –。 Git ユーザーにとってスムーズなアップグレード方法 git 1.8.3 がリリースされました。もちろん、これは最新バージョンへのアップグレードを意味しています。これは比較的、簡単であるべきです: もし OSX 上で homebrew を使用している場合は単に brew update && brew upgrade git とタイプするだけ (OSX 上で .gitignore を解析中に、直前に発見されたバグにより、 homebrew はア
transitive.info - Home
Recent Entries 2024/04/27 Ubuntu 24.04 のインストール & 設定 2023/11/04 WZR-600DHP2 への OpenWRT のインストールと設定 2023/11/02 scrcpy で Android の画面を Ubuntu に表示する 2023/10/29 Ubuntu 24.04 で PT3 を Mirakurun と EPGStation で使う 2023/07/15 LIFEBOOK WU-X/H1 での Ubuntu 23.04 と Windows 11 のデュアルブートと設定 2022/11/22 Ubuntu 22.04 に Mattermost をインストールする ページ一覧へ Archives 2024 (1) 2023 (4) 2022 (7) 2021 (5) 2020 (5) 2019 (6) 2018 (7) 201
iPad miniで持ち歩けるコーディング環境を作る
iPad mini + Cellularを朝一番から並んで買いました！軽くてLTEでネットが使えるということで、外に持ち歩き端末としてはApple史上最高な端末です。 しかし、私は出かけるときには常にコードを書ける環境を持って歩きたいので、結局MacbookProかAirを持って出かけることになってしまいます。 最近、MBP15に代えたのでちょっと持ち歩きが厳しいなと思っていたので、この際iPad miniでコードを書く環境を構築することにしました。 まずはキーボード。前に買ってあったrapoo E-6300をBluetoothで接続してみます。一発でつながったし、サイズ感も良い感じです。 蓋になる形のキーボードも出ているようですが、とりあえずE-6300で問題なさげ。 次にメインとなるエディタです。iPadでソースコードを書くのに適していて、Dropboxに対応しているエディタといえば、
僕たちが行き着いた、シンプルで簡潔なGitの運用方法 - テクノロジーと広義のデザイン！
Gitを使い始めて１年以上たちます。最近、Gitを使ったプロジェクト運用方法が自分なりに固まってきたので公開します。かなりシンプルなので、ある程度Gitに慣れていれば十分に運用可能だと思います。 僕たちが理想とするヒストリーGitを使った開発の成果物、それは開発のヒストリー（履歴）そのものです。このヒストリーが論理的に正しく、かつ、簡潔で理解しやすいものを目指すというのが大方針となります。その方針のなか、現時点で僕たちが理想だと考えているのが、以下の図のような履歴がリモートブランチに残ることです。このヒストリーには２タイプのブランチが存在します。 リリースブランチ … 次期リリースバージョンに向けて進んで行くブランチ。チケット１枚について１つのコミットが良い。 フィーチャーブランチ … チケット１枚について１つ切られるブランチ。機能を実装する際に小刻みにコミットしたログが残っているため、後
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
git rebaseのメモ - unpushの日記
ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
transitive.info - git stash 使い方
git stash 使い方 現在のワークツリーを一時的に保存する 現在のブランチのワークツリーを一時的に保存するには stash を利用する。 git stash save とするか、save を省略して git stash とする。 このとき、stash にメッセージをつけるには git stash save "message" とする。 stash に保存されている状態の一覧を見る git stash list で stash に保存されている状態のリストを見ることができる。 stash@{0}: WIP on master: 1c2aadc "COMMIT_MESSAGE" stash@{1}: WIP on master: 1c2aadc "COMMIT_MESSAGE" stash@{?} とブランチ、親コミットが表示される。 stash に保存されている状態に戻し、stash
gitで一度行った変更をなかったことにする方法4つ | Webシステム開発／教育ソリューションのタイムインターメディア
gitでは様々な方法でコミットログを書き換えることができます。 その一例として一度行った変更をなかったことにする方法を4つ紹介します。 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。 $ $EDITOR $ git commit -am 'foo' $ $EDITOR $ git commit -am 'bar' $ $EDITOR $ git commit -am 'baz' のように適当な区切りでコミットして行ったものの、 結局全部要らないからなかったことにしたいということはままあります。 解答1: git reset –hard HEAD~{n} コミットしたもの全てを歴史から消し去りたい場合は git reset --hard を使います。 この例の場合は3回のコミットを全てなかったことにしたいので、 以下のコマンドで消し去ることができ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
layer8.sh
http://blog.inouetakuya.info/entry/20120826/1345979787
bayashi.jp