GitHub - isotai/git-tips: 最もよく使われるgitの小技と裏技You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
git ちょっと前のコミットで間違ってファイルをコミットしてたので取り消したい - かもメモ
プロジェクトの初期の段階で構造をガラッと代えたりして、ちょっと経ってから間違ってコミットしたくないファイルをコミットしちゃってた事に気づいたりして、このファイルコミットしてないことにしたい...とか結構やらかしてしまうタイプです。 不要なファイルの削除コミットをしても良いのですが、他に影響が出なそうならgit rebaseで履歴を改変してしまう方が、ミスってたのがバレにくいのでステキですw (チームプロジェクトの時はやりすぎると怒られるかも) 個人的にgit rebaseちょっと苦手意識があったので、今回やらかしたのを機にメモ。 コミットの履歴をみる $ git log --oneline このコマンドで直近のコミットの履歴が表示されます。 例えば下のような感じのコミット履歴があるとします。 $ git log --oneline 17ff46a エラー時に猫を出力 da4da17 明石さ
Git Subtree 事始め - Qiita
もうそろそろいい加減git subtreeも使いこなせないとまずいな、と思っていたところなので とりあえずわかる範囲で調べてまとめてみた。 git subtree とは何か git subtreeは外部のリポジトリを現在のリポジトリに取り込むための機能です。 リボジトリ in リポジトリとなるとgit submoduleだったり、 npmとかcomposerみたいな依存管理ライブラリみたいなものを連想するかも知れませんが、 subtreeの挙動はちょっと違います。 一般的な依存管理ライブラリや、git submodule では、 特殊なファイルに 取り込み元リポジトリを記載して管理するという、 取り込み元と、取り込み先を明確に区別しての管理を行うのですが、 subtree では、 「取り込み元と取り込み先のコミット履歴を完全に結合する」 という動き方をするみたいです。 使い方 とりあえずフ
Meld
Meld Visual diff and merge tool Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems. Meld helps you review code changes and understand patches. It might even help you to figure out what's going on in that merge you keep avoiding. File comparison
ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。（前は zsh だったのでなんだかなーと思ってた。） そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート（デフォルトで ~/.ghq）以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
Gitでリモートブランチとローカルブランチの差分を表示する - Pistolfly
まず、リモートブランチを最新に更新しておく。 $ git fetch $ git svn fetch # git-svnでSubversionレポジトリをリモートリポジトリに持つ場合 リモートブランチを確認。 $ git branch -a * master remotes/origin/master remotes/svn/tags/RELEASE_20101022 remotes/svn/tags/RELEASE_20101025 remotes/svn/trunk 現在のローカルブランチとリモートブランチの差分を表示。 $ git diff remotes/origin/master 現在のローカルブランチとリモートブランチの差分を表示（簡易表示） $ git diff --name-status remotes/origin/master 現在のローカルブランチとリモートブランチの
ローカル作業でのgitリポジトリ管理とコーディング環境の話 - すずけんメモ
gitを改めてちゃんと使おうという人がまわりで増えてきたのでメモとして貼っておく。 現状の設定はこんな感じ。1年くらい変わってなかった。 https://github.com/suzuken/dotfiles/blob/cbf8e7168c96029d535d69f981337d23aacfa51c/gitconfig 特にaliasまわりは普段つかっているのであげておく。 [alias] # http://oli.jp/2012/git-powerup/ # http://blog.blindgaenger.net/advanced_git_aliases.html alias = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\\t => \\2/' | sort b = b
façadeでGitのようなサブコマンドをディスパッチする - Kentaro Kuribayashi's blog
Gitには、git fooと実行すると、$PATH内のgit-fooを実行するというサブコマンドの機能がある。そのため、その規約に則りさえすれば、Gitのサブコマンドをいろんな言語で書けるというメリットがある。それを簡単に実現するために、façadeというごく単純なライブラリを書いた。 使い方 これを使うと以下のように書くだけで、コマンド名がyour-commandだったとして、your-command foo bar bazと実行すると、your-command-foo bar bazという呼び出しに変わる。 package main import ( "github.com/pepabo/facade" ) func main() { facade.Run() } なぜ作ったか ある目的に利用するツール群があるとして(たとえばEC2を操作するような各種コマンド群)、以下のような問題を解
Gitつらい - 恋しい日々
GUIクライアントを使っている人にGitの扱い方を教える機会というのがここ数年たびたびあって，最初のうちはGUIアプリわからんし，，，とかいってぽーいとぶん投げていた．途中から良くないなと思いGUIアプリとかも見ながらやってたんだけど，いろいろつらい． どういうことかというと，Gitってソース管理の複雑性を解決しないまま，そのまま複雑なソフトウェアとして落とし込んでいて，使う側に学習を強いるアーキテクチャだと思っていて，根本的にはこれがつらい．ソフトウェア書いてるとソースコードの管理が簡単じゃ無い問題なのわかってるから，使い方覚えるモチベーションもあると思うけど，ソフトウェア書いてない人たちが使おうとすると，なぜ複雑なのかを覚えたり学んだりするところからになる．これは通常であれば完全に無駄なコストで，ノーメリットであると言える．もちろんそういうのすっ飛ばしてコマンドだけ教えても良いのだけれ
Gitとかわかんなくても死なないです
さいきんスクリプトわからなかったりPhotoshopしか使えなかったりするデザイナー死ぬみたいに物騒な意見を表明する人がいたり、それにおびえたりしているひとを見かけますね。SNSで。 私思うのですが、今現在わからないことって、今現在は覚える必要がないことじゃないでしょうか。人間、やらなきゃならないときこそやれるようになりますから。 つまり、今すぐやらなくてもいいようなことがやれないことでおびえたり、悩んだりしなくていいと思います。 あと、いわゆる「叱り系記事」とか「脅し口調」は、昔から出版社があえてつかう、入門者に向けた「売り文句」の典型です。だから、そういう記事を書く人はおそらく自分自身が人にgitとかPhotoshop以外の作業手段なりをセミナーとかで教えることをなりわいとしているのでしょう。だから、そういうふうに怖がらせて自分自身のナレッジの必要性を伝えているのですね。営業トークかー
安全なMergeを行う開発フロー | DevelopersIO
渡辺です。 スノーボードでのスピン（回転）では、フロントサイド（前回り）は視界に向けて回るので比較的に簡単です。 ところが、バックサイド（背中周り）は非常に難しいと感じます。 これは見えない方向への回転なので見えないためであり、恐怖心が原因です。 解らないのは怖いことです。 解ってしまえば意外と簡単だったりします。 「幽霊の正体見たり枯れ尾花」とは良く言ったものですね。 Git（バージョン管理）のMergeも同様です。 Mergeの正体を理解し、恐怖心をなくしましょう。 最後の最後は気合いで手動Merge はじめにお断りしますが、Mergeを理解したとしても、手動でMergeする作業がなくなるわけではありません。 そして、手動でMergeするときは、最終的に気合いでMergeする以外の方法はありません（笑） しかし、Mergeを理解しConflict（競合）が発生しにくい運用を行うことで、
Gitlet
Gitlet is an implemention of Git in JavaScript. Over the last six years, I've become better at using Git for version control. But my conceptions of the index, the working copy, the object graph and remotes have just grown fuzzier. Sometimes, I can only understand something by implementing it. So, I wrote Gitlet, my own version of Git. I pored over tutorials. I read articles about internals. I trie
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git Explained: Proper Team Etiquette
GitHub - jesseduffield/lazygit: simple terminal UI for git commands
ギットクエスト
GitHub - tpope/vim-fugitive: fugitive.vim: A Git wrapper so awesome, it should be illegal
http://blog.inouetakuya.info/entry/20130731/1375279746
Gitでやらかした時に使える19個の奥義 - Qiita
How to ZFS · GitBook (Legacy)
