git stash [ja.nishimotz.com]
$ git stash save 戻すのは git stash pop で。 どうやら stash はリモートに push されないらしい： http://stackoverflow.com/questions/1550378/is-it-possible-to-push-a-git-stash-to-a-remote-repository 変更を stash に移動 $ git stash save 番号を確認 $ git stash list スタッシュ stash@{0} に保存されていることを確認する。 新しいブランチを作りstashの内容をそこに移す $ git stash branch ブランチ名 stash@{0} 変更はまだ新しいブランチにコミットされていないのでコミットする $ git commit -am "コメント"
いざというとき覚えておきたいgitコマンドまとめ - Qiita
まだあわてるような時間ではございません。 インデックス 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し 2.そろそろブランチを整理しなきゃ! -- ブランチの名称変更と削除 3.間違ってコミットしちゃった! -- コミットを取り消す3つのリセット 4.別のブランチをプッシュしちゃった! -- リモートブランチのリセットと削除 5.コミットの順番を間違えちゃった! -- コミットログの並べ替えと削除 6.コミット細かすぎィ! -- コミットログの統合と編集 7.あのコミットさえあれば…! -- 他のブランチのコミットを適用する 8.やばい!ハードリセットしたら消えちゃった! -- 過去の状態の復元 9.masterにマージ後にバグ発生!どうする!? -- コミットを打ち消すコミット 1.コミットメッセージを間違えちゃった! -- 直前のコミットのやり直し エディタが
Git ブランチから自動的に Jenkins ジョブを作る - kotas.tech
Jenkins の Git プラグインは標準で複数ブランチのビルドに対応してるんですが、1つのジョブで全部のブランチをビルドするので [成功 (master)] → [失敗 (branchA)] → [成功 (master)] → [失敗 (branchA)]みたいな感じでブランチごとの成功/失敗がわかりづらく、IRC に通知出してると FAILED! → Yippie! → FAILED! → Yippie! …とうるさい感じで残念です。 というわけで軽くググったところ、引っかかった↓を導入します。 Jenkins "Build Per Branch" by entagen インストール まずはドキュメントに書かれている通り、Jenkins にプラグインをいくつかインストール。 Git Plugin - Jenkins - Jenkins Wiki Gradle Plugin - Jen
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
RedmineRepositories - Redmine
1.3 or higher required. Doesn't support Ruby Bindings for Subversion. Subversion 1.7.0 and 1.7.1 contains bugs (#9541) Note 1 : the appropriate binaries must be installed on the same host as Redmine. For example, if you want to access Subversion repositories in Redmine, you'll have to install the svn binaries on the Redmine host. Note 2 : the appropriate binaries must be reachable by Redmine : 2 o
gitにでかいバイナリファイルを入れるとどうなるか - 西尾泰和のはてなダイアリー
ふと気になったのでgitにでかいバイナリファイルを入れたらどうなるのか調べてみた。 自分の発表が録画された112メガのaviファイルを実験対象に使う。 cp まずはgitを使わない普通のcpの時間を測っておく。 real 0m0.744s user 0m0.001s sys 0m0.179s git add git addにはコピーの10倍以上の時間がかかる。 real 0m9.339s user 0m7.989s sys 0m0.490s git commit git commitには意外と時間が掛からなかった。 real 0m0.055s user 0m0.002s sys 0m0.031s git clone 先ほど動画ファイルをcommitしたリポジトリをcloneしてみる。単純なファイルコピーに比べると3倍弱時間がかかる。 real 0m1.943s user 0m0.932s
gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体から
ブランチ名 + 作業状態 + stash数 をzshのプロンプトに表示 - Qiita
# git stash count function git_prompt_stash_count { local COUNT=$(git stash list 2>/dev/null | wc -l | tr -d ' ') if [ "$COUNT" -gt 0 ]; then echo " ($COUNT)" fi } setopt prompt_subst autoload -Uz VCS_INFO_get_data_git; VCS_INFO_get_data_git 2> /dev/null function rprompt-git-current-branch { local name st color action if [[ "$PWD" =~ '/\.git(/.*)?$' ]]; then return fi name=$(basename "`git symboli
Git だろうと Mercurial だろうと、ブランチ名をzshのプロンプトにスマートに表示する方法 - mollifier delta blog
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
Git管理下のemacsでELPAから複数のファイルを大量に削除した時の操作 | Acid Note
emacs24 から同梱されたパッケージ管理システムの ELPA を使うと elisp 管理が劇的に楽になります。 M-x list-packagesとするとインストール可能な elisp のリストが出てきて、そこから簡単に、インストール，アップグレード，アンインストール等が出来ちゃいます。特に便利なのがアップグレードで、リスト画面で U を叩くと、 こんな感じでアップグレード可能なリストをチェックしてくれます。ここで x を叩くと最新版を一式ダウンロードした上で、古い elisp の削除まで一通りやってくれて便利過ぎます。 ただ、設定ファイルを Git で管理している場合少し面倒で、ELPA でアップグレードした後に git statusすると、 と、勝手にファイル削除すんな的な事言われます。Git からファイルを削除する時は git rmとかしてGitの管理下からもファイルを削除してや
gitで一部のディレクトリだけチェックアウトする - Qiita
$ git clone リポジトリURL hoge $ cd hoge $ git config core.sparsecheckout true $ echo "hoge.txt" > .git/info/sparse-checkout $ git read-tree -m -u HEAD こうするとワーキングディレクトリ下はhoge.txtファイルだけチェックアウトされる様になるらしい。 これまで制作部スタッフにhtmlファイルを編集してもらうのに社内共有フォルダでファイルの受け渡しをしていたんだけど、この機能を使ったらもう少しスマートにならないかなと考え中。 gitスキルのない制作部スタッフにいきなり今日からgit運用にします。ってのは、ハードル高すぎるので、gitアクセスは当面、技術部スタッフが代行するとして共有フォルダにsparse checkoutで制作部スタッフが編集してよい
git-gutter.el - naoyaのはてなダイアリー
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
Gitでコンフリクトした時のための備忘録 - アジャイルSEを目指すブログ
コンフリクトしたときに便利そうなので、備忘録を残しておく Gitのコマンド コンフリクトしているファイルの一覧を表示する。 $ git ls-files -u [<path>] ファイルの状態(コンフリクト含む)を表示する。 -s でshort-format で特定のディレクトリのファイル一覧を表示できる $ git status [<path>] 手動で直す方法 修正後にaddが必要 $ vi <path> (手動でコンフリクトを直す) $ git add <path> mergetool でマージする方法 -y でデフォルトのマージツールが実行する で1つずつ指定できる $ git mergetool -y [<path>] をHEADと同じ状態にする。 修正後にaddが必要 $ git checkout --ours [<path>] $ git add <path> をマージで指定
git reset についてもまとめてみる - murankの日記
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
愛知県の社会福祉法人 清凉会は、老人ホーム・デイサービス・特別養護老人ホーム・保育園などを運営しております。
ABOUT SEIRYOU GROUP 清凉グループについて 清凉グループでは、「あふれる笑顔～慈悲の心で～」を経営理念として掲げ、 地域における介護・保育ニーズにお応えすべく、複数の施設を運営しております。 今後も地域の皆様の生活に寄り添う場所として、個々の施設と連携し、よりよいサービスを追求していく所存です。 清凉グループからのお知らせinformation
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hudson/Jenkins Git build all branches
便利なGit Tools
fetch と pullの違い - Qiita
Git - ブランチとマージの基本
Git clone with custom SSH using GIT_SSH error