git add を実行あとで修正していなかった部分に気づいてしまった場合や、 「git add .」で間違って.swpとかのバックアップファイルがステージングに入ってしまった場合に、 git addをキャンセルする方法です。 コマンドの構文 ファイルをキャンセルする場合 git rm --cached ファイル名 ディレクトリをキャンセルする場合 git rm -r --cached ディレクトリ名 git rmは、Working Tree (作業コピー)と index からファイルを削除するコマンドですが、 --cachedを指定する事で、 indexからのみファイルを削除する事ができます。 http://blog.s21g.com/articles/960 指定する、ファイル名やディレクトリ名にはワイルドカード(*.swp等)が使用できます。 間違って要らないファイルをgit addし

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

gitのお話。 masterブランチで作業しているとおもいきや、いつの間にか無名ブランチ*1に迷い込んでしましました。 $ git branch -l * masterしかし、無名ブランチにいるとはつゆ知らず、作業して、addしてcommitして、さあ、pull --rebaseしようとしたら、できない。 masterブランチに切り替えます。 $ git checkout master $ git branch -l * masterだがしかし、masterブランチに移動したら、先ほどまで作業していたlogが消えてしましましたよ。(あたりまえですな) こんな時は、.git/log/HEADを見ましょう*2。.git/log/HEADには、ローカルレポジトリ*3のコミットログとメッセージとハッシュ値が平文で格納されています。そして、このハッシュ値を元にmergeしたりブランチを切ればいいわけ

2014年6月1日（日⁠）⁠、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ─⁠─ Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ─⁠─ Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「⁠GitHubを利用した開発の世界を知る」「⁠GitHubを（利用｜活用）する違いを

Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51

変更をコミットせずに一時的に保存する例のやつが git stash系のコマンドなわけですが、 git stashの続き - by shigemk2 stashした変更の中身を見るには、 git stash show stash@\{0\} -p とすればいい。 色付きで表示したいなら、 git stash show stash@\{0\} -p --color とするとなおよし。

概要 皆さん、Gitは使いこなせていますか？ Gitをしっかりと理解するためには、コマンドを覚えるだけでは不十分です。 Gitがどのような仕組みで動作し、各コマンドの裏で行われている内容を理解することが非常に重要となります。 初めてGitに触れる方はもちろん、より深くGitを理解したい方も、一緒にGitを勉強しませんか？ 対象者 どなたでも 経験の浅い方大歓迎 前提 ワークショップ形式となりますので、Gitコマンドが実行できる環境をご準備ください。 講師 松下 雅和 @matsukaz 渋谷で働くエンジニア。DevLOVEスタッフ。 【著書】Git逆引き入門 開催場所について 開催場所の21Cafeは 3階 です。お気をつけください。 もし迷われた場合は （渋谷駅の南口あたりまで戻る） 246に出て、 坂を上っていただき、 セブンイレブンとみずほを通り過ぎ 次の小道を右に入ってください。

$ git add -pという、ひとつのファイルから分割して部分的にcommitできる便利なオプションがあって、最近commitをもうちょっとこまめに分けようと心がけるようになってからたびたび使うのだけど、そうすると欲が出てきて、もう少し細かく分割してくれたらなあと思うことがたまにある。git add -p もうちょっと細かくわけてくれたらいいのにとたまに思う— TAE ✅ (@ken_c_lo) February 16, 2013 @ken_c_lo 確か「git add -p」した後に「y」とか「n」で取り込むところを選ぶ時に「s」をやると、さらに小さい単位に分割してくれた気がします。最近やってないので若干怪しいですが。。— 松本 瞬／Shun Matsumoto (@shu_0115) February 16, 2013 @ken_c_lo だいたいこんな感じだったと思います。→ b

Germán Laullón PadillaSoftware Engineer in Madrid, Spain I am a software engineer currently living in Madrid, Spain. My interests range from photography to technology. I am also interested in programming, innovation, and video games. You can click the button above to view my portfolio. If you’d like to get in touch, feel free to say hello through any of the social links below.

ハックガールズ from PuzzleGirls プログラミングができるアイドル「ハックガールズ」。リアル脱出ゲームのSCRAP公式アイドル「パズルガールズ」のメンバー、堤沙也・濱ヶ崎美季による、派生ユニット。 デビュー曲「おしえて！恋のプロトコル」。

morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと

はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ

複数のリポジトリがあった時に、それをまとめた親レポジトリを作り、各レポジトリをサブディレクトリとしてまとめてしまう方法。 ファイルとして保存するだけじゃなく、ちゃんとコミットHistoryも保存される。一つにまとめたものを後で切り出すこともできる。 これでリポジトリ数の削減が可能になるので、GithubのPrivateリポジトリ数の上限などにお悩みの人は是非お試しを。現在、頻繁に使っているものをまとめてしまうのはおすすめしないが、古い使われてないものを歴史ごとアーカイブするのには持ってこいだと思う。 以下では、 $ACCOUNT = githubのアカウント名 $REPO = サブディレクトリに移したいレポジトリ名 $ARCHIVE = 複数リポジトリをまとめておくアーカイブ用親リポジトリの名前 とする。 複数リポジトリをまとめたアーカイブ用gitリポジトリをローカルに作成 mkdir $

merge済みのブランチがいつまでも環境に居座っていると精神衛生上よろしくないのでこまめに消す派なのですが，いちいち手作業でやるのもダルいしコマンド一発ですべてを片付けたいというのが人情と言うものなので，最近ではゴリッとスクリプトを書いてそれを使っています． ここにも同じものを置いてあります． シェル力が低いので，正直これが良いやり方なのかどうかはわかっていませんが，とりあえず動いていて便利なので記した次第．

なんとなく最近どんな感じで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 バージョン管理しているファイルのファイルパスを表

いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打