If I run git stash -u, I can stash untracked files. However, said untracked files don't show up at all with git stash show stash@{0}. Is there any way to show untracked stashed files without applying the stash?
コミット履歴が無駄に多く,黒歴史のある Git リポジトリで開発をする場合,初回の git clone が非常に遅いという問題がある.コミット数に依存せずに素早く落とせる方法を探していて,最近(今さら...!) git clone の --depth オプションのことを知った.用途によっては非常に便利なので,まとめておこうと思う. 前提 現時点で公開されている最新バージョンの Git 2.12.1 を前提にしている.Git は今もまだ機能が増えているため,定期的にバージョンアップしておくと良いと思う.Mac なら brew upgrade git でサクッと最新バージョンになる. $ git --version git version 2.12.1 git clone --depth とは git clone で --depth オプションを使うと,指定したコミット数で刈り取ることができる
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .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 このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
ProductMore contributions on your profileEarning green squares on your contribution graph means celebrating the work you do in open source and public projects. Starting today, you can also celebrate the work you do in… Earning green squares on your contribution graph means celebrating the work you do in open source and public projects. Starting today, you can also celebrate the work you do in priv
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
TL;DR version: now there is a good way of using Dropbox as a true Git remote: git-remote-dropbox. We keep all of our files in Dropbox. Wouldn’t it be great if we could keep our code there too? I have two different demands for storage space: To have files distributed around computers and have them synchronized in multiple places To use git to formally control version of individual files, and use a
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 (これ以降の記事中のリモートは全てoriginとします。) このコロンは何?? リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか? 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
対応バージョン この記事の内容は、少なくともGitのバージョン2.19.1までは対応している。 もし最新のGitで新しい動きがあれば随時更新する。 基本 .gitignoreを使うと無視する(Gitのトラッキングの対象外とする)ファイル or ディレクトリを指定できる。 .gitignoreは複数のディレクトリに置くことができる。 深い階層の.gitignoreに書かれた指定の方が優先順位が高い。(後に解釈される) .gitignore内の記述は上の行から順に以下のように解釈される。 /を含まない行(fileなど) .gitignore以下の全サブディレクトリ下にあるこの名前のファイル or ディレクトリを無視する 末尾以外にのみ/を含む行(/file, /path/to/file, path/to/fileなど) .gitignoreが置いてあるディレクトリをカレントディレクトリとする相
Table of Contents: Parameters for better logging git log --oneline --graphLog actual changes in a file git log -p filenameOnly Log changes for some specific lines in file git log -L 1,1:some-file.txtLog changes not yet merged to the parent branch git log --no-merges master..Extract a file from another branch git show some-branch:some-file.jsSome notes on rebasing git pull --rebaseRemember the bran
This hint is especially useful if you have two Maven projects — a parent project and a child project depending on it — on which you want to develop concurrently. The directory structure will look like this: The most important part in the child project’s POM is assigning the parent project to the subfolder parent instead of using an installed artifact: What we have now, is a combination of two proj
'git inject' is a git alias (see code at the bottom). It is similar to 'git commit --amend', but it allows you to 'inject' your changes into commits further back in history (using 'rebase').If you're as pedantic as I am about the git history you're about to push into master (as far as I can control it, I strive to keep each commit conceptually coherent), you'll often come to a situation where you
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
ときどき間違うので。 大雑把に言うと、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 rebase パート1の続きです。 fixed(コメントは変更せずにコミットをまとめる) fixed は squash と同じく1つ前のコミットとまとめる機能がありますが squash と違うのはコメントはそのままにするということです。 squash と同じ説明になりますが 70b3379 の メソッド名のタイポ修正 を何事もなかったかのようにしたい時は cce19c9 とまとめてしまいます。いつものように [kengo@tkengo-mac] $ git rebase -i cce19c9~1 こうして pick cce19c9 通信用のクラスの実装とテストの追加 fixed 70b3379 メソッド名のタイポ修正 pick aebf22c テストが落ちてたので修正 とします。すると squash の場合はこの後にコメントを入力する画面が出て来ましたが fixed の場合はそれが
git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く