tigから git rebase -i したらいろいろ捗った - くりにっき
git dtコマンド - razokulover publog を見て自分もgitのコマンドをカスタマイズしてるのを思い出したので普段よく使っているのを紹介します。 対象者 作業途中はtmpコミットをたくさん作って、最後に git rebase -i でコミットを整えている人 前置き gitのタイプ数を減らす gitコマンドを使う時に毎回 git と3文字タイプするのは時間の無駄なのでエイリアスつけるのをおすすめします ~/.bash_profile とか ~/.bashrc 辺りに下記を書きます。 alias g='git' これで g だけでgitコマンドが使えます git-now iwata/git-now tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ 最速でtmpコミットするためのコマンド。Macなら brew install git-
GitのHEAD^ HEAD~やらダブルドット トリプルドットやら
こんにちは。monipla facebookを担当している佐藤（ま）です。 アライドでは「大佐」と呼ばれております。 最近Gitの操作にも慣れてきましたが、SourceTreeは未だ手放せません。 さて今回は、関連性はありませんが「HEAD^ HEAD~」と「ダブルドット/トリプルドット」について書いていきたいと思います。個人的に最初少しとっつきにくかったので。 HEAD^とHEAD~ まず、HEADとは「今いるブランチの最新コミット」のことですね。 つまり「git show HEAD」とすれば最新のコミット情報が見れることになります。 なのでHEADを起点にすればわざわざハッシュを指定しなくてもコミットログを見ることができます。
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
gitのリモートブランチを使って作業を行う流れのメモ - 那由多屋 開発日誌
こんにちは加藤です。 分散バージョン管理システムのgitを本格的（？）に使い始めて1ヶ月くらいが経ちました。けれども未だに迷うことがあるため、リモートブランチを使った作業について簡単にまとめておきます。 想定環境 マシンA、マシンBで編集作業を行い、それらからアクセス可能な場所に連携用のリポジトリがある環境と想定します。 また、マシンA、マシンBでは既に連携用リポジトリをcloneしており、remotes/originが設定されていると想定します。 $ git clone <連携用リポジトリ> マシンAでの作業 なんらかの作業をすることを思い立ったら、作業用のブランチを切ります。今回はworkingブランチとします。 $ git checkout -b working $ git branch master * working 各種作業を行います。 $ git status $ git a
Gitで不適切なコミットメッセージを削除した公開リポジトリを作る - 2012-01-05 - ククログ
分散バージョン管理システムのGitには様々なサブコマンドがありますが、その中の1つである git filter-branch を使用すると、過去のコミットを完全に無かった事にしてしまうなどの強力なコミット履歴の編集が可能となります。大きなリポジトリの特定のディレクトリ以下の内容をコミット履歴付きで別の小さなリポジトリとして取り出したり、ファイルの中に書かれていた生のパスワードを履歴の中から消去したり、というのはよく紹介される例です。 このエントリでは別の例として、コミットメッセージだけを後からまとめて修正する手順をご紹介しましょう。 元々非公開なプロジェクトとして開発を進めていたものを、公開リポジトリに移動したいとなると、やはり機密情報は完全に取り除いておく必要があります。リポジトリに格納されているファイルそのものの内容の編集方法については上記の例で解説されていますが、それ以外の場合として
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Gitをバックエンドに使ったプログラマ向きWiki - Gitit - Masatomo Nakano Blog
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
git addとgit commitのundo方法(ver.2) - 西尾泰和のはてなダイアリー
チートシート作りの練習としてとりあえずaddとcommitで何が起きて、各段階でのundo方法がなんなのかを図にしてみた(注:間違いがあるので最後まで読んでね) 縦3つでセットで1つの時点だってのがわかりにくいのでもうちょっと縦幅を縮めた方がいいのかもなぁ？ あ、あと下の一番右だけ省略されているHEADを明示してみたけど、そこを明示するなら右から二番目も明示すべきだし、それをやると長過ぎてうっとうしいからやっぱ両方省略した方がいいかな。 p.s. 左端のgit rm Aはgit rm --cached Aの間違い。ここでgit resetではダメなのは、この時点ではまだinitial commitができていないから。 git resetにを指定できるのは--hardや--softの付いていない時だけだった…。checkoutを使うのがよさそう。thanks id:Yuichirou ! v
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) | Webシステム開発／教育ソリューションのタイムインターメディア
gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma
gitで誤ったブランチに対して行った変更を正しいブランチに移す(stash編) | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) では一度コミットしてしまった変更を別のブランチへ付け変える方法について紹介しました。 この例では誤ったブランチに対して一度コミットしてしまいましたが、 コミットする前に誤ったブランチで作業していたことに気付くこともよくあります。 例えば以下のような状態です: $ git branch master * topic-y $ git branch topic-x master $ $EDITOR # git checkout topic-x を忘れて作業してしまった。 $ git status # On branch topic-y # Changed but not updated: # (use "git add <file>..." to update what will be commit
Gitとかで変更があった時に自動でrevert-bufferする - Kentaro Kuribayashi's blog
EmacsとGitとを用いて開発してる際、たとえばgit checkoutした後、実際のファイルとバッファが不整合な状態になって、revert-bufferしないまま保存しようとすると「ファイルが変更されてるけど、どうすんの?」とかいわれて鬱陶しい。しかも、auto-save-buffers-enhancedしてたりすると、それが延々とまらなくなって、ものすごく大変なことになったりする。 いままでいちいちrevert-bufferしてたのだけど、明らかにあほっぽいなと思ったので、どうにかならないか調べてみたところ、こんな感じでauto-revert-modeを使ってやるとよさそう。なんらかのvcの管理下にあるかどうかを`vc-backend'で調べるのは、もっとちゃんとしたやりかたがありそうだけど。 ;; ↓こいつをnon-nilにしておくと、vcsによる変更もチェックしてくれる (set
zsh のプロンプトに、各種 VCS のブランチ名表示と、git の変更を表示 - 旧札幌市西区
zsh の prompt に、svn やら git やらのブランチ名を表示し、git のときだけ変更点を(詳し目に)表示する zshrc の設定を、いろんなものを参考に書きました。 コードは最後の方にあります。 こんなかんじになる ブランチ名を右側に表示 git add した直後 変更があるとき untracked なファイルがあるとき 組み合わさっているとき ファイルの削除・リネーム、unmerged なファイルの場合の表示もある。割愛。 参考にさせてもらったところ 基本的には id:mollifier さんの、zsh で Git の作業コピーに変更があるかどうかをプロンプトに表示する方法 - mollifier delta blogを参考に、zsh の vcs_info を使っています。上の例がゴテゴテしていると感じる方は、リンク先のほうがスッキリしていてよいでしょう。 調べているうち
図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
transitive.info - git blame 使い方
git blame 使い方 ファイルの各行がどのコミットのものか調べる file.txt に対して git blame file.txt とすると、 各行毎にコミットのハッシュ値、著者、時間が表示される。 git blame の出力を変更する -f コミットのファイル名を表示する -s 著者とタイムスタンプを表示しない -l ハッシュ値を短縮しないで表示する 行番号で指定した範囲の各行がどのコミットのものか調べる 「-L」オプションで範囲を指定できる。 行番号で指定するには数字を二つコンマで区切って指定する。 また、「+」と「-」を使ってオフセットを指定できる。 git blame -L 5 file.txt git blame -L ,5 file.txt git blame -L 5,10 file.txt git blame -L 5,+3 file.txt git blame -L
Git で過去にさかのぼってタグ付けする (git tag) - 肉とビールとパンケーキ by @sotarok
もうだいぶ歴史を進めて開発進めてたんだけど、そういやあのプロトタイプが動いたときタグうっときゃよかったなーなどと思ったんだけど、意外と情報がなかったからメモ。 git-flow 使って、develop で開発進めてたりして、リモート/ローカルで push/pull も頻繁にしてるリポジトリ。現存するのは、develop, master のみ、だいぶ昔に feature/hoge からマージした段階に戻って master にマージしてタグ付けしたい、みたいな要望（割とあるよね？あるよね？ $ git log --all --graphとか見ながら、コミットオブジェクトのハッシュ確認。例えば、「38fef39」が対象のコミットだとする。 そのハッシュをチェックアウト。 $ git checkout 38fef39 Note: checking out '38fef39'. You are in
gitoliteを入れてみた(on Debian 6.0 squeeze) - ただのにっき(2011-04-22)
■ gitoliteを入れてみた(on Debian 6.0 squeeze) 最近、仕事でメンテしてるサイトに標準でjQueryが入ったせいか、JavaScriptを書く仕事が急に増えた。つーかおれ、このプロジェクトでは別にプログラマってわけじゃないんだけど(笑)。 で、チョロっと書くつもりだったスクリプトが思わず大きくなってしまい、「これはバージョン管理しないとまずいだろ」という感じになったので、開発環境にgitを入れようかと(泥縄にもほどがある)。後々のことを考えてリポジトリ管理ツール経由でいれておこうと思い、いまイケてるツールは何か(Twitterで)聞いてみたらgitoliteを勧められた。gitosisはもうイケてないらしい。流れの早い業界だなー。 そして開発サーバがDebian lennyだったのでまずはsqueezeにあげるところから始まり(squeezeにはgitolit
Tower Git Client - Tower — The most powerful Git client for Mac and Windows
Version 11.0 was released on May 7, 2024 Version 7.0 was released on May 7, 2024 Read Blog Post Release Notes Git Made Easy Drag and Drop • Undo everything • A unique Conflict Wizard • File history • Extensive documentation • Great customer support Learn More All of Git's Power (And None of the Pain) Pull Requests • Single-line staging • Interactive Rebase • Submodules • Git LFS • Git-Flow • File
[間違いを訂正].gitignoreでディレクトリの中身だけをignoreする書き方 - Hello, world! - s21g
secondlifeさんのご指摘の通り、 この方法ではうまくいかない事がわかりました。 代案を探してみたところ、 とりあえず以下のようにすることで目的を果たせるようです。 空ディレクトリとしたいディレクトリ（例えばtmp/）の中に.gitignoreファイルを置く tmp/をROOTの.gitignoreファイルの中でignoreする git add tmp/.gitignoreをする。 .gitignoreファイル自体は含まれてしまいますが、 実用上は問題なさそうですね。 しかし、完全な方法は無いものか･･･。 See Also 空ディレクトリに.gitignoreを log/やtmp/ディレクトリの中身はignoreしたいけれど、ディレクトリそのものの存在はリポジトリに含めたい場合は、以下のように.gitignoreを書けば良いみたいです。 .gitignore
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
