Git - 特定ファイルのコミットを取り消してまるっと前の状態へ戻したいとき

前回コミットした中に含まれていた、ある特定のファイルについて、それだけまるっと前のバージョンへ戻したいなと思ったら。


1. そのファイルのコミット履歴を確認

git log -p [ファイルパス]

差分などが表示される詳細なログのうち、戻したいバージョンのコミット番号だけ確認してコピーしておく。


2. コミット番号を指定して、そのファイルを指定したコミット時点まで戻す

git checkout [コミット番号] [ファイルパス]

Git - gulpのパッケージをgitで共有したくなかったら

gulp、そしてgulpで利用するパッケージだけで、かなりディレクトリ容量が膨らむ。
これをgitで共有するのは嫌だなあと思って試行錯誤。

とりあえず、グローバルとローカルの両方にgulpをインストールするのではなく、グローバルだけにできないかと思ったが、逆（ローカルのみインストールする）はあっても、グローバルのみで動かす設定は発見できず。

gulp.jsのフローを見る限り、ローカルへのインストールは必須のようだし。

if (!env.modulePath) {
    gutil.log(
      chalk.red('Local gulp not found in'),
      chalk.magenta(tildify(env.cwd))
    );
    gutil.log(chalk.red('Try running: npm install gulp'));
    process.exit(1);
  }

このフローの通り、ローカルにgulpがインストールされていないと、gulpの実行はできない。

[13:20:52] Local gulp not found in ~/git/プロジェクト名
[13:20:52] Try running: npm install gulp

gulpが、グローバルとローカルとの、両方でインストールが必須なのには構造的な理由がある。

グローバルにインストールされたgulpは、ローカルにインストールされたgulpを実行するためのもの。このグローバルとローカルの2つのモジュールの中身は完全に同じもので、まったく同じモジュールをグローバルとローカルにインストールすることになる。

gulpコマンドが実行されると、gulp.jsのrequireで、ローカルのgulpがインポートされる。

そして、実際の処理（gulpfile.jsに書かれたタスク）はrequireされたローカルのgulpモジュールが全て行う。つまり、gulpは、自分自身が自分自身と同じモジュールをrequireして使うという仕組みで動いている。


では、ローカルへのインストールは仕方がないとしても、gitで共有したくない問題はどうにかできないかと思ったら、

gitなどでプロジェクト共有している場合、この node_modules を共有していると結構重かったりしますし、 package.json が共有されていたらあとで $ npm install をしたら必要なものが入ってくるため、 node_modules のディレクトリの共有は不要です。

Node.js 製の タスクランナー gulp.js を使ってみる - HAM MEDIA MEMO


ハッ！その手があったか！思わずポンと手を打ってしまった。


.gitignoreでnode_modulesをignoreすればいいじゃないですか。


gitからクローンした際は、npm installすればパッケージはインストールされるんだし。


ですよねぇ。これって常識だったのかしら。


追記

.gitignoreのサンプルは以下。一行だけだけれど。

/node_modules/

上記内容をプロジェクト直下にファイル名「.gitignore」で保存。
「node_modules」の前の/で、プロジェクトと同階層であることを明示。
「node_modules」の後の/で、ディレクトリであることを明示。

つまり、「/node_modules/」で、プロジェクト直下のnode_modulesディレクトリを無視する、という設定になる。

GitHubでプルリクエストがマージされた後にすること

GitHubで初めてプルリクエストを送ってみました(・∀・)

少しでも、fork元のリポジトリに貢献できるって嬉しいですね。初めての快感です。

送ったプルリクエストは早速マージしてもらったのですが、その後、自分の作業用ブランチやforkした後の自分のリポジトリって、どのように処置したらいいの？と戸惑いました。次回またそうならないために忘備録としてメモ。

1. ローカルのmasterへcheckout

変更作業を開始する前の、forkしてきた初期のステータスを参照している段階へ戻ります。

$ git checkout master

2. ローカルの作業用ブランチを削除

必要なくなったローカルの作業用ブランチを削除します。なんやかんや聞かれても面倒なので、-Dオプションを付けて、強制的に削除してしまいます。

$ git branch -D fixTypo

必要ないブランチが複数ある場合は、それぞれ削除していきます。

ローカルにある、プルリクエストを送るために使ったブランチも、削除します。

3. プルリクエスト済みのGitHub上にあるリモートブランチを削除

$ git push origin :fixTypo

4. ローカルでfork元のリポジトリからプル

ここから先はSourceTreeで作業しました。

fork元のリポジトリからプルを実行します。

プルする時に「プルする元のリポジトリ」をGitHub上の自分のリポジトリではなく、fork元のリポジトリを指します。そのために、プルダウンをクリックして、「カスタム」を選択して、パスを変更します。

単に変更内容を吸いたいだけなので、「マージしてコミットする」などのチェックボックスは全てオフにしておく方が無難です。

fork元は、自分が送ったプルリクエストをマージして更新済みなので、プルが済むと、自分が編集を始める前の状態との差分が出てきます。

5. GitHub上の自分のリモートリポジトリへプッシュ

ローカルのmasterへプルした、最新のfork元のリポジトリの内容を、リモートのGitHub上の自分のリポジトリへプッシュします。

これで、fork元のリポジトリの状態と、GitHub上の自分のリポジトリの状態とが一致します。

もう、このリポジトリはwatchしないなという場合は、リポジトリを削除してもいいと思いますが、なにかしらまだチェックしておきたいかもという場合は、自分のリポジトリが古いバージョンをさしたままにならないようにプルしておくといいと思います。