間違って別のブランチで実装を始めちゃった時にgit stashで別ブランチに編集中のソースを移動する - setoya-blog
Git - Stashingの手抜き翻訳かつ、勝手に構成や説明の流れを変えたものです。 間違ってmasterブランチなどで実装を始めたのに途中で気づいて、開発用のdevelopmentブランチにその書きかけのソースをコミットすることなく持って行きたいときは、git stashを使う。 書きかけだとgit statusとしたときに色々でるはず。 $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) #
さっきの取り消したい！って時のGitコマンドまとめ - Qiita
ありがちなgitの失敗とその修正コマンドをまとめました。(´﹃｀) masterブランチで作業を始めてしまった！ Σ(llﾟ艸ﾟll) git stash をすると、stashリストに書きかけのソースが退避して登録される。 なので、git statusとしても"nothing got commit"となり、変更が隠される。 ちなみにstashはこっそりしまう、という意味。 git stash list とすると、退避されているソースのリストが表示される。 コードを持っていきたいブランチに切り替えて、 git stash apply とすると、最後にstashされたものがそのブランチで反映される。 直前のソースではなく、特定のstashしたソースを指定したい場合は、 git stash apply stash@{[git stash listで確認した番号]}とすると、適用できる。 べつにm
もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術
はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
