普段、GitHubのrevertは一度マージして環境に入ったPRを何かしらの理由で外す時に使ってます。

revertのやり方は特に難しい話ではないと思うのですが、（過去にも記事にしてます）今回ちょっとイレギュラーなケースが起きたので、備忘録として記事にしました。

１週間ほど前にとある機能を実装して、無事にマージされたPRがあったのですが、テストが追いついてないからXX日のリリース対象から外したいのでrevertしてほしいとPMから言われる。

いつものようにrevertしようとしたら、こんなエラーメッセージが。。。

content may have changed since it was merged
マージされてから差分が出てるから自動でrevertは無理ですよって。。
実際このPRが入ってから別のPRが次々マージされてしまったのが原因。

通常のrevertはGitHub上で自動で簡単にできますが、revertによってコンフリクトが発生する場合はGitHub上ではできないらしいです・・・

今回はこうしたrevertによってコンフリクトが起きた場合に、コンフリクトを解消しつつ、revertする方法を紹介します。（他にもやり方色々あると思いますが、個人的にこれが一番シンプルでやりやすいと思いました。）

手順：

1) まず、Revert用に新しくブランチを切ります。（ブランチ名はrevert-hogeとかお好きなように）

2) ターミナルでコマンドを実行

git revert <commit hash>

このcommit hashはrevertするPRがマージされた時のcommit hashです。
PR見るのが一番確実。

すると、warning出ます、つまりコンフリクト解消してねって事です。

error: could not revert 98b44b2e6... コミットメッセージがここに出ます (#6007)
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

3) コンフリクト解消します。これは通常のコンフリクト解消と全く同じ。

コンフリクトしなかったファイル達は自動でStagingされます。
（revertなので、自分の書いたコードが消える逆の変更が入ります。）

4) いつものように、add, commitし、リモートにPushします。

5) プルリクを作れば、普段GitHub上で自動で作られるrevert PRと同じものが完成です。

あとはReview依頼出して、マージされたら完了。

というわけで、最初に見慣れないエラーが出て焦りましたが、意外とシンプルに解決できました。

revert自体普段そんなにやらないし、こういうたまにしかやらない事はドキュメント化しておかないと次同じ状況になった時に困るので、備忘録として記事にしました。

前提

• 私自身は学習歴約半年ほどの初学者です。
• 最近はGitコマンド操作に慣れるために、様々なツールでGit/GitHubについて学習しているので、アウトプットしてみようと思い執筆しました。

Gitよく使うコマンド集

# ローカルリポジトリを作成するコマンド
% git init

# リモートリポジトリからローカルリポジトリにコピーしてくるコマンド
% git clone [リポジトリの名前]

# ファイルの変更を確認するコマンド
% git status

# ファイルやディレクトリの変更をステージに追加するコマンド
% git add [ファイルの名前]or[ディレクトリの名前]

# すべての変更をステージに追加するコマンド
% git add .

# コミットするコマンド(コマンド入力後、ターミナルやエディターでメッセージを入力する必要がある)
% git commit

# コミットするコマンド
% git commit -m "[メッセージ]"

# ファイルを削除するコマンド
% git rm [ファイルの名前]

# ディレクトリを削除するコマンド
% git rm -r [ディレクトリの名前]

# リモートリポジトリのurlをoriginに割り当てるコマンド(git push origin masterが使える)
% git remote add origin https://github.com/ユーザー名/リポジトリ名.git

# リモートリポジトリのmasterブランチにpushするコマンド
% git push origin master

# 本来のpushするコマンド
% git push [リモートの名前] [ブランチの名前]

# リモートから変更情報を取ってくるコマンド
% git fetch [リモートの名前]

# 変更をマージ(統合)するコマンド
% git merge [リモートの名前/ブランチの名前]
% git merge [ブランチの名前]

# fetchとmergeを一緒に行うコマンド
% git pull [リモートの名前] [ブランチの名前]

# ブランチを新しく作成するコマンド
% git branch [作成したいブランチの名前]

# ブランチを切り替えるコマンド
% git checkout [ブランチの名前]

# ブランチの一覧を表示するコマンド
% git branch

# ブランチを削除するコマンド
% git branch -d [削除したいブランチの名前]

# 差分を確認するコマンド(後ろにファイル名等を指定できる)
% git diff

# ステージ追加後の差分を確認するコマンド
% git diff --staged

# ログを確認するコマンド
% git log

# 数字の分だけコミットを表示するコマンド
% git log -n [数字]

# ファイルやディレクトリの変更を取り消すコマンド
% git checkout -- [ファイルの名前]or[ディレクトリの名前]

# すべての変更を取り消すコマンド
% git checkout -- .

# git addでステージに追加したファイルやディレクトリの変更を取り消すコマンド
% git reset HEAD [ファイルの名前]or[ディレクトリの名前]

# git addでステージに追加したすべての変更を取り消すコマンド
% git reset HEAD .

# 直前のコミットをやり直すコマンド
% git commit --amend

まだまだいろんなコマンドがあるとは思いますが、個人的によく使うと感じたもの(実務未経験者という立場ではありますが）を列挙してみました。

以上です。ご覧いただきありがとうございました。

環境

• windows10
• gitbash

git bashの起動時のディレクトリ

目標「２の状態を１にしたい」

1

ユーザ名@DESKTOP-**** MINGW64 ~
$ pwd
/c/Users/ユーザ名

2

ユーザ名@DESKTOP-**** MINGW64 /
$ pwd
/

2の場合

タスクバーにショートカットがある時

１．エクスプローラーにおいてショートカット一覧のディレクトリへいく。

path

C:\Users\ユーザ名\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

にショートカットがあるのでここにあるGitBahのプロパティを開く。

２．プロパティからリンク先を変更する。

リンク先

"C:\Program Files\Git\git-bash.exe" --cd-to-home

// --cd-to-homeを消す
"C:\Program Files\Git\git-bash.exe" 

３．作業ファルダのパスを書き換えるまたは付け足す。

作業フォルダー

%HOMEDRIVE%%HOMEPATH%

タスクバーにショートカットがない時

１.まずどこでもいいのでショートカットを作成して、エクスプローラーの作成した場所へいく。
２．タスクバーにショートカットがある時の２以降と同様に従う

Git bashのホームディレクトリを変更する

gitbash

$ cd ~
$ pwd
/c/Users/ユーザ名

更に場所を指定する方法
(例)初期カレントディレクトリをDesktopにする

gitbash

$ setx HOME "C:\Users\ユーザ名\desktop"

$ cd ~
$ pwd
/c/Users/ユーザ名/desktop

なぜ起こる？

　push先のリモートディレクトリの設定が行えていない。gitからしてみれば、『どこにpushすればええねん。』状態です。

簡単に解消法を説明

　こちらは、既存のリモートレポジトリで現在のプロジェクトをgit管理する場合になります。

git管理します宣言

git init

既にありますよ？って言われたら、.gitを一度削除して、initし直すのが一番手っ取り早いです。

push先レポジトリの指定

git remote add origin https://github.com/ユーザー名/プロジェクト名.git

ユーザー名、プロジェクト名は下記画像参考にしてください。

レポジトリの作成

git checkout -b develop

試験的にpushするためのレポジトリなので説明は省略します。とりあえずdevelop

add,commit,push

git add .
git commit -m "コミットメッセージ"
git push origin develop

pushでエラーが出なければ、本記事における作業は終了です。github.comにてリモートに反映ができているかの確認をしてください。

おわりに

　今回コマンドでのgitの扱いを解説しましたが、コンフリクト等起こった時は個人的にコマンドでの解決が一番早いので、慣れておいて損はないかと思います。僕自身初心者としてgitが煩わしく感じましたが、ラプトップ一つで仕事をする上で非常に重要なツールなので、常に触るようにすることを心がけております。

　最後までお読みいただきありがとうございます。

TS;R

ホーム直下に，リモートリポジトリのURLと対応するようにディレクトリを切ります

~/
├── Applications/
├── Desktop/
├── （省略）
├── gist.github.com/
│   └── u-sho/
│       ├── bash-ascii-logo
│       └── tmux-ascii-logo
│
├── github.com
│   ├── redimpulz/
│   │   ├── k8s-study/
│   │   └── other-private-repositories/
│   │
│   ├── u-sho/
│   │   ├── dotfiles/
│   │   ├── ja.vuejs.org/
│   │   ├── nuxt2.9-template/
│   │   └── u-sho.github.io/
│   │
│   └── other-github-users/
│
├── gitlab.com/
│   └── u-sho/
│

フォークしたのか直接cloneしたのかがわかりやすくて迷子にならないので気に入っています

リポジトリで pwd すると URL になるのも好きです（git config remote.origin.url だと SSH のとき悲しくなるので）

はじめに

いつも通りGitHub上のリモートリポジトリにプッシュしようとしたらなぜかできなくなっていました。
リモートリポジトリのURL設定やSSH接続もできており、原因究明に時間がかかったので備忘録として残します。

原因

該当リポジトリのManage accessのRoleがReadになっていたのが原因でした(チームの誰かがやってしまっていたみたい)。
こちらをAdminにすれば解決します。

背景

AWSのサービスということもあり、コードレビューの自動化やCI/CD等AWSの他のサービスと組み合わせたアーキテクトが便利というCodeCommit。
これまでリポジトリ管理にGitBucketやGitHubを使ってきましたが、CodeCommitを始めて使いずらいと感じた点を少ないですがまとめました。

使いづらい点

遅い

どの操作をするにも体感遅いです。これは時と場合によるかも。

プルリクのコメントが改行されない

全て1行で表示されてしまい見にくいです。

差分を表示できない

エラー『違いを表示できません。個別のファイルが大きすぎて表示できないか、ファイル間の全体的な違いが複雑すぎます。』と表示される場合がある。これは致命的です。ソース管理を奇麗にしろとも取れますが、基準が曖昧ですし不親切に感じます。
追記：ファイルの行数を3250行以下にしないと当該エラーが発生する。開発チームに連携した上で対応有無・時期未定とAWS公式回答。
cf. AWS CodeCommit のクォータ
cf. 公式フォーラムで未解決らしい

プルリクエストに対して、マージ先の最新のソースを取り込む機能がない

GitBucketにあったこんな機能です。これがないとレビューの度に最新のソースを取り込んでからPUSHし直してもらう必要があったりします。

因みにGitBucketの場合に、同じ個所に表示される競合（コンフリ）が発生した際のUIも分かりやすくて好きです。

別のリポジトリ管理を使う

完全プライベートリポジトリに絞ると、GitLab?（CodeGuruには対応していない）とかでしょうか。これいいよというのがあればご教授頂きたいです。

単なるgitコマンド備忘録。
ちょいちょい追加していきます。

リポジトリを新規作成する

$ git init

ファイルをインデックスに追加する（ステージングする）

$ git add

コミットする

$ git commit

ワークツリーのファイルの状態を確認する

$ git status

コミットのログを確認する

#すべて表示
$ git log

#一行で表示する
$ git log --oneline

#ファイルの変更差分を表示する
$ git log -p index.html

#表示するコミット数を制限する
$ git log -n <コミット数>

変更差分を確認する

#git addする前の変更分
$ git diff
$ git diff <ファイル名>

#git addした後の変更分
$ git diff --staged

ワークツリー、gitの記録からファイルごと削除（そもそもファイル自体が不要になった）

$ git rm <ファイル名>
$ git rm -r <ディレクトリ名>

ワークツリーにファイルを残し、gitの記録からのみ消したいとき（パスワードファイルなどgitには上げないけど手元には残したいなど）

$git rm --cached <ファイル名>

ファイルの移動を記録する

$git mv <旧ファイル> <新ファイル>

それは下記と同じ効果である

$mv <旧ファイル> <新ファイル>
$git rm<旧ファイル>
$git add<新ファイル>

ブランチを作成する

$ git branch <ブランチ名>

ブランチの作成だけで、ブランチ切り替えは行いません。

ブランチの一覧を表示する

$ git branch

現在のブランチがどのコミットを指しているか確認

$ git log --oneline --decorate

ブランチを切り替える

$ git checkout <既存ブランチ名＞

ブランチの作成と切り替えを同時に行う

$git checkout -b <新ブランチ名>

切り替えると、HRADも切り替えたほうのブランチに移動する

ブランチ名を変更する

$ git branch -m <新ブランチ名>

ブランチを削除する

$ git branch -d <ブランチ名>

変更作業がマージされずに残っている場合は削除されない。

変更履歴をマージする

$ git merge <ブランチ名>
$ git merge <リモート名/ブランチ名>
$ git merge origin/master

origin：GitHub(リモート)を意味する

Git pushをしようとすると、error: src refspec ブランチ名 does not match anyといったエラーが出る、、

git remore -vで確認すると、対象のリモートレポジトリはちゃんと登録されてる。。

原因と対処法

自分のいるブランチを見てみる。おそらく送信したいブランチが存在してないはず、、

$ git branch
* master

もしくは、fetchしたブランチに移動した場合は、detached headになっている。

$ git branch
master
*(HEAD detached at origin/44382)

送信しようとしてるブランチがそもそも存在していない、、そりゃsrcがないと言われます、、

対処法

ブランチの作成と移動

$ git checkout -b ブランチ名

detached headの場合は

ブランチの移動

$ git checkout ブランチ名

このあとで、git pushしたらうまくいく。

目的

• 何気なく業務でgit rebaseを使っているが毎回危ない橋を渡っている気がするので自分のテスト環境でちゃんと理解してみる

環境

• Gitバージョン: 2.28.0

お願い

• もしもっと良い方法があったらどしどしコメントをお願いいたします。。。！

情報

• 筆者は下記の方法でMacにHomeBrewでGitを導入した。
  • Mac ネイティブのGitからHomebrewでインストールしたGitに切り替えた話
• 下記の方法を参考にローカルリポジトリを用意しGitHubのリモートリポジトリと紐付けた。
  • Git ローカルリポジトリを作ったらやること

• masterブランチのREADME.mdには下記の内容が記載されている。

  README.md

  # リポジトリの説明
  
  - gitのあれこれをテストするためのリポジトリです。
  

• README.mdが登録されただけのmasterブランチからrebase_masterブランチを作成した。

• masterブランチからただ分岐しただけのrebase_masterブランチからrebase_No01ブランチを作成した。

• rebase_masterブランチ、rebase_No01ブランチ作成後に各ブランチでプッシュを行いリモートブランチへの反映を行った。

• 説明で実行するコマンドは特筆しない限り前のコマンドと同じディレクトリで実行するものとする。

準備

1. リポジトリ内の「.git」があるディレクトリで下記コマンドを実行してrebase_masterブランチに移動する。

   $ git switch rebase_master
   

2. 下記コマンドを実行してREADME.mdを開く。

   $ vi README.md
   

3. 下記のようにREADME.mdを修正する。

   README.md

   # リポジトリの説明
   
   - gitのあれこれをテストするためのリポジトリです。
   - これはrebase_masterブランチでの変更です。
   

4. 上記の変更を「rebase_masterブランチでの説明を追加」というコミットメッセージを追加してコミットとプッシュを行った。

5. 下記コマンドを実行してrebase_No01ブランチに移動する。

   $ git switch rebase_No01
   

6. 下記コマンドを実行してREADME.mdを開く。

   $ vi README.md
   

7. 下記のようにREADME.mdを修正する。

   README.md

   # リポジトリの説明
   
   - gitのあれこれをテストするためのリポジトリです。
   - これはrebase_No01ブランチでの変更です。
   

8. 上記の変更を「rebase_No01ブランチでの説明を追加」というコミットメッセージを追加してコミットとプッシュを行った。

git rebaseを行う

1. 現在の情報をまとめる

   1. rebase_masterブランチのREADME.mdの内容

      README.md

      # リポジトリの説明
      
      - gitのあれこれをテストするためのリポジトリです。
      - これはrebase_masterブランチでの変更です。
      

   2. rebase_No01ブランチのREADME.mdの内容

      README.md

      # リポジトリの説明
      
      - gitのあれこれをテストするためのリポジトリです。
      - これはrebase_No01ブランチでの変更です。
      

2. rebase_No01ブランチはrebase_masterから分岐しているが、README.mdに変更が加わる前に分岐しているのでrebase_No01ブランチには当然rebase_masterの変更は加わっていない。（rebase_No01ブランチのREADME.mdには「- これはrebase_masterブランチでの変更です。」の記載がされていない。）

3. $ git rebaseコマンドを使って、rebase_No01のブランチの分岐もとを最新のrebase_masterに変更してみる。

4. 下記コマンドを実行してrebase_No01ブランチに移動する。

   $ git switch rebase_No01
   

5. 下記コマンドを実行してrebaseを実行しrebase_No01ブランチの分岐点を最新状態のrebase_masterに変更する。

   $ git rebase rebase_master
   

6. 下記のような内容がターミナル上に出力された。当たり前だが同じファイルの同じ行に変更が加わっていたのでコンフリクトした。

   Auto-merging README.md
   CONFLICT (content): Merge conflict in README.md
   error: could not apply 6cf625f... rebase_No01ブランチでの説明を追加
   Resolve all conflicts manually, mark them as resolved with
   "git add/rm <conflicted_files>", then run "git rebase --continue".
   You can instead skip this commit: run "git rebase --skip".
   To abort and get back to the state before "git rebase", run "git rebase --abort".
   Could not apply 6cf625f... rebase_No01ブランチでの説明を追加
   

7. 上記の出力内容を簡単に訳す。

   git rebaseを実行したらコンフリクトが発生しました。
   コンフリクトを手動で解決して$ git addかrmを実行して$ git rebase --continueを実行してください。
   スキップするには$ git rebase --skipを実行してください。
   中止してrebase前の状態に戻したいなら$ git rebase --abortを実行してください。
   

8. 「コンフリクトしたからなんとかして解決してね。解決したらこれやってね」的なことを言われているようだ。とりあえずまず手動でコンフリクトを解決するところから始める。

9. README.mdを開いて確認すると下記のようにコンフリクトした印が追記されている。

   README.md

   # リポジトリの説明
   - gitのあれこれをテストするためのリポジトリです。
   <<<<<<< HEAD
   - これはrebase_masterブランチでの変更です。
   =======
   - これはrebase_No01ブランチでの変更です。
   >>>>>>> 6cf625f... rebase_No01ブランチでの説明を追加
   

10. 今回はrebase_masterブランチの内容とrebase_No01ブランチの修正を両方残したいので下記のように修正した。

    README.md

    # リポジトリの説明
    - gitのあれこれをテストするためのリポジトリです。
    - これはrebase_masterブランチでの変更です。
    - これはrebase_No01ブランチでの変更です。
    

11. エディターによっては簡単にコンフリクトを直すことができるボタンが表示される事がある。筆者はVScodeを使用しており下記のように表示された。この場合両方のブランチの変更を取り込みたいので「両方の変更を取り込む」をクリックすると自動でソースをきれいに修正してくれる。

    

12. これでコンフリクトは解決できたので先程の$ git rebaseを実行したときに出力された案内に沿って$ git addや$ git rebase --continueを実行してみる。まずは下記コマンドを実行する。

    $ git add README.md
    

13. コンフリクトを解消したファイルをインデックスに登録できたので下記コマンドを実行する。

    $ git rebase --continue
    

14. コミットメッセージの入力画面が開くがとりあえず特にいじらず保存する。

15. これでrebase_No01ブランチの分岐点を最新のrebase_masterに変更することができた。

16. 下記コマンドを実行して最新のrebase_No01をプルする。

    $ git pull origin rebase_No01
    

17. 先程のようにコンフリクトするのでREADME.mdを開き下記のようになるように修正する。

    README.md

    # リポジトリの説明
    - gitのあれこれをテストするためのリポジトリです。
    - これはrebase_masterブランチでの変更です。
    - これはrebase_No01ブランチでの変更です。
    

18. 下記コマンドを実行して修正点をインデックスに登録する。

    $ git add README.md
    

19. 下記コマンドを実行してコミットする。

    $ git commit 
    

20. このコミットはマージコミットになるので特に必要なければコミットメッセージは記載されたままいじらずに保存する。

21. 下記コマンドを実行してrebase_No01の内容をリモートのrebase_No01ブランチの反映する。

    $ git push origin rebase_No01
    

初投稿です。
Qiitaはよく閲覧しますが、投稿したことはありません。
この度、「開発で自分が困った事は他の方も困っているに違いない」という観点から、自分の備忘録も兼ねて投稿することにしました。
不備はあるかもしれませんが、暖かく見守ってください。

さて、本題です。

git initでリポジトリを作成して、初回のステージングを行う際に、下記のようなエラーがズラズラ出てきました。

The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Content.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Meta.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/MetaInf.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Mimetype.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Settings.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Styles.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/Thumbnails.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/OpenDocument/WriterPart.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/PDF.php.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in common/PHPExcel/Writer/PDF/Core.php.
The file will have its original line endings in your working directory

これは、Gitが自動的にLF改行コードをCRLFに変換した際に出るwarningですので、自動変換をオフにします。
git configで設定します。

$ git config --global core.autoCRLF false

これでwarningは出なくなりました。以上です。

参考：https://kmizukix.hatenadiary.org/entry/20100106/1262711140

S/Wだとそんなことはまずないが、H/Wだと今動いているコードが何か知りたいので、コードの一部にgitのコミット番号を埋め込みたい、みたいなことが起こる (らしい。) その時に引っかかったことがあるので残しておく。結論から言うとTARGETを使うadd_custom_commandを使うのが一番いい気がする。なおCMakeに関してはほとんどわかっていないのでご容赦を...

gitのコミットハッシュを取得する

gitのコミットハッシュ自体は下で取得できる(長いやつ)

$ git log --pretty=format:%H -1
# 又は
$ git rev-parse HEAD

短いやつ

$ git log --pretty=format:%h -1
# 又は
$ git rev-parse --short HEAD

CMakeの処理3段階

1. Configure ファイルの依存関係をさらう
2. Generate さらった依存関係を元にビルド用ファイルを作成
3. Build ビルドを実行
   の主に3段階ある。よく

-- Configuring done
-- Generating done
-- Build files have been written to: /hogehoge

みたいな表示を見る。

CMakeでコマンド実行

CMakeでコマンドを実行する方法は主に2通りある。 execute_process と add_custom_commandの2つ。2つと書いたが、add_custom_commandには使い方が2通りあって、頭にOUTPUTを持ってくるかTARGETを持ってくるかで処理が全く違う。OUTPUTを持ってきた場合はビルド用のファイル生成でTARGETを使うのはビルド時にコマンド実行(ビルドイベント)をする用途になる。
cf. add_custom_command - CMake
このうち、上のビルド時に実行されるのはadd_custom_commandのTARGETのみ。他は configure or generate で実行される。

Gitハッシュ埋め込み

execute_processとadd_custom_commandの使い方についてはCMakeの公式リファレンスにしっかり載ってるのでそちらに譲る。
cf. execute_process - CMake
1つ目の方法としてexecute_processでハッシュ値を取得、configure_fileで埋め込み、という手がある。WORKING_DIRECTORYはgit ~を実行するディレクトリを指定するので、git submodule内部のハッシュ値が欲しい場合はそのディレクトリを指定してあげればいい。

CMakeLists.txt

execute_process(COMMAND git rev-parse --short HEAD 
  OUTPUT_VARIABLE git_rev
  OUTPUT_STRIP_TRAILING_WHITESPACE
  WORKING_DIRECTORY ${WORKING_DIRECTORY})
configure_file ("hogehoge.tmp" "hogehoge.h")

hogehoge.tmpの中に@git_rev@みたいな文字列を用意しておけば、そこが勝手にgitのハッシュに置き換わってhogehoge.hを出力してくれる。
別の方法としてadd_custom_commandでOUTPUTを使う場合。こちらは公式リファレンスにもあるが役目がGenerating Filesなのでビルド前にファイル生成を行うのが主目的。そのファイルがCMakeLists.txtでビルドに使用されるとわかっている時、適当に文字列をハッシュに書きかえる.batなり.shなりを用意してあげればconfigure & generate中にそのコマンドが実行されてくれる。

CMakeLists.txt

add_custom_command(OUTPUT hogehoge.h
  COMMAND hogehoge.bat
  WORKING_DIRECTORY ${WORKING_DIRECTORY})

ただ上の2つの問題点は上でも書いたようにビルド直前では実行されないことだ。一度フォルダを開いてconfigure & generateが済まされた場合、hogehoge.hに何らかの変更が加えられてもその変更を超えてgitのハッシュの反映をなされない。そういう場合でも変わらず埋め込みたい場合はadd_custom_commandのTARGETを使用する。こちらの役割はBuild Eventsである。

CMakeLists.txt

add_custom_command(TARGET ${PROJECT_NAME}
  PRE_BUILD
  COMMAND hogehoge.bat
  WORKING_DIRECTORY ${WORKING_DIRECTORY})

これはビルドが実行される場合、つまりプログラムが走る場合常に直前に実行されるので他の改変の影響を受けない。のでそうして欲しい場合はadd_custom_commandのTARGETを使用しよう。ここではビルド直前に反映されて欲しいのでPRE_BUILDとしているが、PRE_LINK, POST_BUILDなどで実行するタイミングを指定できる。