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の便利な-pオプション四兄弟 - エンジニアをリングする
この記事は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に新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
git submoduleの更新 - rochefort's blog
2017.8.31 追記 この記事は間違っています。正しくは下記でした。 git submoduleの更新方法を勘違いしていた 昔書いた記事を参考にしてくださった方がいて、 でも「git submodule updateで更新できないよ」と。 gitのsubmoduleだけを最新版にしたい場合のコマンドメモ - Reinvention of the Wheel 私自身もgit submodule updateで更新できると思ってました。 というか、一度も更新処理試してなかった。 結論から言うと これでOKでした。foreach便利。 $ git submodule foreach 'git pull origin master' $ git submodule update ですが、no branch になってしまってるsubmoduleがあったので、pullするのはこっちの方がいいかもし
Pro Git: 6.4 Git のさまざまなツール - 歴史の書き換え
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Tracサーバで複数のgitリポジトリを管理 - syuu1228's blog
Tracには0.12から１つのTracインスタンスで複数リポジトリを管理する機能が入っている（MultipleRepositorySupport – The Trac Project）。 これを使って複数のgitリポジトリを管理できるようにしてみた。 git pluginを入れる gitを有効にするにはGitPlugin – Trac Hacks - Plugins Macros etc.を入れる必要がある。 # easy_install http://github.com/hvr/trac-git-plugin/tarball/master こんだけ。 trac.iniの設定 git pluginの有効化 [components] # for plugin version 0.11.0.1+ tracext.git.* = enabled git pluginの詳細設定 git_binの
git/コミットログを修正する方法 - TOBY SOFT wiki
はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理？) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ！しまった！"refs #(チケット番号)"つけるの忘れてた！ # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット
git rebaseって超便利じゃね？ - Seasons.NET
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね？ 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします： $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
github使い方まとめ - bugfix
ブランチを切ってみたところ， リモートレポジトリへのコミットのやり方が分からなかったので， 概略的なgitの構造を書き留めつつまとめつつ． この記事を書くにあたって試したgitのバージョンは1.6.0.2 まずは：こんな感じ？ 用語確認 master: ローカルレポジトリのmasterブランチ(ローカルのメインのブランチ？) origin: リモートレポジトリのoriginブランチ(リモートのメインのブランチ？) (つまり，git@github.com:pneu/***.gitのことかな？) この２つはよく使うから，それぞれ最初からエイリアスになっているってことかな？ cloneして，レポジトリ名が確定した後は上の２つのエイリアスが使える． それ以前に使った場合は分からない．やってない． chatレポジトリをcloneした後は，その作業領域では origin = git@github.co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitで複数のコミットを1つにまとめる | Webシステム開発／教育ソリューションのタイムインターメディア
Gitでリモートの共有リポジトリにあるブランチを消す時のメモ - longkey1's blog