リモートにプッシュした時、次のようなエラーが返ってきた。

To github.com:○○○○○○/○○○○○○○
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:○○○○○○/○○○○○○'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

状況確認

non-fast-forward は、下のような状況で言うとmasterブランチのリモートとローカルの最新情報が異なっていることを示す。そのため、通常のプッシュが行えず、rejectが表示される。

master    a --- b --- c --- d --- e
(リモート)
　　　　　　　　　 
master    a --- b --- c --- d --- f
(ローカル)　   　

対処法１

$ git pull origin master　　リモートの情報をローカルに持ってくる(自動的にマージも行われる)
$ git push origin master　　最新情報が一致するため通常のプッシュが行える

対処法2

$ git push -f origin master  　強制(force)的にプッシュする

エラー詳細

任意のブランチをpushする際に、下記のようなエラーが発生しました。

$ git push origin ブランチ名
error: src refspec ブランチ名 does not match any

git branchを実行すると、下記のような表示がでます。

$ git status
develop
master
*(HEAD detached at origin/49792)

解決策

git push origin HEAD:pushしたいブランチ名

参考

making a git push from a detached head

よくある話かと思いますが、masterからブランチを切って作業していて、PRを出してマージしたんだけどmasterに戻ろうとすると一部の変更ファイルがあってcheckoutできない場合があります。

$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
    ファイル...
Please commit your changes or stash them before you switch branches.
Aborting

これはまあPleaseに書いてあるとおり、一度

• git stashして、
• git checkout master
• git pullして
• git stash apply

すると対応ができるのですが、これが正直面倒です。
変更ファイルを残すなって話もあるかと思いますが、これをスピーディーにやる方法があります。

git fetch origin master:master

というコマンドを打つと、他のブランチにいてもローカルのmasterブランチの内容が最新に更新できるので、

• git fetch origin master:master
• git checkout master

の２コマンドで解決することができます。(これでもAbortしてしまったらそのときはstash利用しようね)

ちょいちょいgit fetch origin master masterだとかgit fetch origin masterだとかコマンドを忘れがちなのでメモ程度にここに書いておきます。

備忘録＆定着のため、自分が使いそうな点も含め残します。
基礎の基礎です。
必要になれば追記していきます。

VScodeのgit拡張機ってとても便利ですよね。

設定

$ git config --global user.name 'username' // 作業者名の表示に使用（コミット者名等）
$ git config --global user.email 'username@example.com' 作業者メールアドレスの表示に使用（コミット等）

上手くいかないからと何度も行うとエラーが発生する。（当たり前）
その場合はエディタで編集すると解決しやすいかも。

エディタで設定

$ git config -e  # ローカルの設定を変更
$ git config --global -e
$ git config --system -e

一連の流れ

ファイルのステージング（全ファイルをステージングするとき）

git add --all

ファイルを指定する

git add index.html

コミットする

git commit -m "first commit"

リモートリポジトリへpush

リモートリポジトリの追加

git remote add origin [url]

リモートリポジトリへpush

git push -u origin master

リモートリポジトリから引っ張ってくるとき

git clone [クローンしたいリポジトリ] [クローン先のディレクトリ(省略可)]

参考

Git(Hub)で作業をする一連の流れ 忘備録 - Qiita
[https://qiita.com/oreo/items/d07877c640bfd94fb489]

備忘録＆定着のため、自分が使いそうな点も含め残します。
個人用トラブルシューティング的なやつです。
必要になれば追記していきます。

VScodeのgit拡張機ってとても便利ですよね。
静的Webサイト構築時に使用しています。

設定

$ git config --global user.name 'username' // 作業者名の表示に使用（コミット者名等）
$ git config --global user.email 'username@example.com' 作業者メールアドレスの表示に使用（コミット等）

上手くいかないからと何度も行うとエラーが発生する。（当たり前）
その場合はエディタで編集すると解決しやすいかも。

エディタで設定

$ git config -e  # ローカルの設定を変更
$ git config --global -e
$ git config --system -e

一連の流れ

ファイルのステージング（全ファイルをステージングするとき）

git add --all

ファイルを指定する

git add index.html

コミットする

git commit -m "first commit"

リモートリポジトリへpush

リモートリポジトリの登録

git remote add origin [url]

リモートリポジトリの変更

git remote set-url <リポジトリの名前> <新しいリポジトリのURL>

リモートリポジトリの削除

git remote rm origin

登録済みのリモートリポジトリ確認

git remote -v

リモートリポジトリへpush

git push -u origin master

リモートリポジトリから引っ張ってくるとき

git clone [クローンしたいリポジトリ] [クローン先のディレクトリ(省略可)]

参考

Git(Hub)で作業をする一連の流れ 忘備録 - Qiita
[https://qiita.com/oreo/items/d07877c640bfd94fb489]

UnityプロジェクトをGitで管理していてLFSを使っているときに起きた現象です。

事象

Unityで開発してたときにgitをみるとmetaファイルに謎のdiffが出ている。
ImportLogsがうんちゃら。
類似現象 → https://forum.unity.com/threads/editor-keeps-reimporting-fbx-assets.514085/

原因

差分の出るmetaファイルの元ファイルがlfs fetchされる前のテキスト状態になってた。
なぜか git lfs fetch --all してもファイルがfetchされない。

対処

一度fetchされないファイルを削除してgitで変更を破棄する。

やりたいことは差分ファイルの抽出

今回の夢は、指定コミットから指定コミットまでの差分を、ディレクトリ構造そのままで、差分のみzipに圧縮したい願望を叶えることです。

既存記事での差分抽出方法おさらい

色々調べた上で見つかった便利抽出コマンドのおさらいです。
色々なコマンドが見つかりまして、使わせて頂いてました。

git archive revision `git diff --name-only origin/master revision --diff-filter=ACMR` -o diff.zip

diffでファイルリストを出力して、アーカイブでzip可するコマンドですが、
大量のファイルに対応できません

比較的大きなプロジェクトで差分を出していると、すぐにハマります。
なので、これは使わなくなりまして……。

git diff --name-only --diff-filter=ACMR {OLDID} {NEWID} | xargs git archive --format=zip {NEWID}  -o diff.zip

xargsの力で、たくさんファイルがあっても大丈夫！　というコマンドですが、
超大量のファイルもしくは、大容量ファイルに対応できません

ここ、きちんと出力できていない事実だけで問題でしたので、原因をそんなに詳しく調べてないのですが、

• Git Lfsを使っている
• 1000ファイル以上の大量のファイル
• mp4等の大容量ファイルを含んでいる

この条件で実行した場合、HEADから数コミット分の差分ファイルしか出力されず、期待したzipを作成できませんでした。

これ以上の差分作成コマンドはネットの海に見当たりません……。
僕は自作を余儀なくされたのでした。

大量、大容量ファイルでも大丈夫バージョンができたー！

git archiveの挙動がエラーも出ず度々変わってくるので、かなり悩まされました。

git diff はどんなにファイルが多くてもすべての差分ファイルリストを出力してくれているようです。

そこで僕は気づきました。

別に git archive使う必要ないんじゃね？？？？

挙動が変なら使わなければいいんですよ。

rm -f diff.zip && git diff --name-only --diff-filter=ACMR {OLD} {NEW} | zip diff.zip -@

これでいいじゃん！！！!

gitに archiveなんて機能があると使いたくなっちゃいますが、 git diffで差分リストさえ出せればどうとでもできるんですよねー。
windowsの人は gitBashとかにでもzipコマンドをインストールしておきましょう。

ただし、チェックアウトしているファイルがzip圧縮されます。HEAD以外の差分抽出は、該当コミットにチェックアウトしてから実行しましょう。

より簡潔にかつスマートなコマンドが出来上がって僕は満足なのでした。

おわり。

What is "good commit" that is aware of the change unit in #git? In a nutshell, it's detachable. In other words, it is a well-made time machine.

• 自分や他の人が、思うような変更差分に戻りやすく、一つの状態で動作を再現しやすい
• rebase などをしてコミット同士の順序を入れ替えても、コンフリクトあるいは手に負えないコンフリクトが起きにくい
• どのコミットの状態をとっても、動作不可能なものや、テストに落ちるものがなく、実装とテストが一体になっている
• rebase などでコミットを削除しやすく、削除してもコンフリクトが起きにくい
• cherry-pick で他のブランチに持って行きやすい
• Github などの Pull Request でコミット単位でのレビューがしやすい
• 二個以上のブランチで同じコミットを共有しやすい、共有しても問題が起こりにくい

色々と書いたが、一言「着脱自由」にまとめられる。

つまりよく出来たタイムマシーンだ！

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/2370

エラー内容

git pullをしたら、以下のエラーが表示された。

$ error: The following untracked working tree files would be overwritten by merge:

ローカルの修正を捨ててしまっていいときの対処法

$ git fetch --all
$ git reset --hard origin/master

エイリアスとは

別名、通称と言う意味になります。

何が出来る？

gitコマンドに別名をつけて、省略することが出来ます。

以下例

git checkout master
git log --oneline
git status
git commit -m 'update: ~~~~~'

↓

git co master
git lgone
git st
git cm -m 'update: ~~~~~'

こんな感じになります。

設定方法

git config --global alias.[略称] '[gitコマンド]'
git config --global alias.co 'commit'
git config --global alias.logone 'log --oneline'

例(個人的なものです)

• cm : commit -m
• co : checkout
• logone : log --oneline
• st : status
• fe : fetch
• me : merge
• br : branch

終わりに

何か間違っていることがあればご指摘お願い致します。

コマンド

$ git log

• q : git logの終了
• h : ヘルプの表示

概要

• gitignoreに入れたのに、差分が出た時にコミット対象に表示され続ける
• 一度コミットしてしまっている

ビルドしたり、新しいパッケージを入れたり、マイグレートしたりすると、
自動生成されるあのファイルとかこのファイルとかをコミットするのは結構不毛です

解決法：追跡を停止する

コマンド

git rm --cached path/to/filename

• --cachedオプションで、インデックスのみ削除し、作業ツリーにファイルを残す。
• その後コミットする

SourceTreeの場合

• 対象ファイルを右クリック → 「追跡を停止する」を選択
• 削除状態になるのでコミットする（ローカルのファイル自体は消えてない）

まとめ

• 無視したいファイルをコミットしてしまった場合は、追跡を停止しよう

参考

• gitで、追跡対象ファイルの外す（追跡をやめる）方法。

背景・対象

• 弊現場ではEclipse上でGitの操作を行う運用となっており、そもそもcommitとpushくらいしか分からないという人も少なくない。
• その他の細かな操作のマニュアルが欲しいということで少し調べてみたが、Eclipseでの利用を前提としたGit関連の詳細な記事が意外と少ない。
• ほぼ弊現場向けではあるが、同じく悩んでいるレガシィ環境下のエンジニアは少なくないだろうと思い、せっかくなので記事として残すことにした。
• commitとpushくらいしか使ってない、ブランチの概念はなんとなく知ってる程度の人向け。
• 環境構築、リポジトリの初期設定などは済んでいる前提。
• Pleiadesのバージョン4.5.2で説明する。
• シリーズ記事になるかもしれないしならないかもしれない。

スタッシュ(stash)とは？

スタッシュそのものの説明に関してはこちらの記事が大変わかりやすい。
『変更を一時的に退避！キメろgit stash』
要するに変更をコミットせずに退避する。
コミットしていないファイルが存在しているとブランチの切り替えができない。作業中のブランチとは別のブランチの作業が入ってしまった際などに使える。割り込みタスクはよくあること。

スタッシュってどこにある？

プロジェクトを右クリック -> チーム -> Stashes で出てくる。

つかいかた

1. プロジェクトに変更がある状態で、｢変更をスタッシュ｣を選択する。
2. スタッシュの名前を入力する。｢未追跡ファイルを含む｣にチェックを入れない場合、新規追加されたファイルはスタッシュに含まれないので注意。
3. プロジェクトの変更状態マークが消えるので、別のブランチに切り替えて割り込みタスクを片付ける。
4. スタッシュを行ったブランチに戻り、先ほど作成したスタッシュを選択する。
5. 退避された変更ファイルの一覧が出るので、確認して右上の適用ボタンを押す。
6. 適用しただけではスタッシュの削除は行われない。作業を続行しコミットが済んだらスタッシュを削除しよう。

注意事項

• プロジェクト全体でスタッシュを作成するため、ファイル単位でのスタッシュはできない。ただしEclipseでは｢未追跡ファイルを含む｣のチェック有無で変更ファイルと追加ファイルでスタッシュを分けることは可能。
• スタッシュは作成ブランチに紐づいているため、異なるブランチで作成したスタッシュを適用することはできない。そういうことをしたいのならチェリー・ピック(cherry-pick)でも使ったほうがよい。
• スタッシュ作成時とブランチの状態が変わっていると適用に失敗する可能性がある。例えばスタッシュしてからブランチのリベースを行った場合など。Eclipseの場合、スタッシュの適用に失敗すると中途半端に適用された状態になってしまい、マージツール無しの手作業での修復が必要となる。まだしもマージツールが使える苦肉の手段として、作業途中でもコミットしてしまってからリベースしてコンフリクトを解消し、リベースが済んだらリセットでコミットを取り消すという手も。
• 以上の内容は弊現場での環境下で確認されている事象であり、Eclipseならば必ずこうなるという話ではないのであしからず。また表現に関して厳密でない点へのマサカリはお手柔らかに。
• スタッシュは、退避してそのまま戻す使い方さえしていれば普通は特に問題が起こることがない。それ以外の使い方はしないほうが良い。

その他参考になりそうな記事

『EGit逆引きリファレンス（ブランチ操作関連）』
Pleiadesではないがスクショ付きでさらっと解説してあり見やすい。

sourcehut という git のホスティングサービスがあります。
公式サイトは https://sourcehut.org/ です。

日本ではあまり見慣れないサービスですが、利用されている例を上げると Go の GUI ライブラリの Gio はこのサービスでホストされています。
https://git.sr.ht/~eliasnaur/gio

このサービスには Pull Request という概念はなく、自分でパッチをメーリングリストに投稿し、取り込んでもらう必要があります。
git には send-email というコマンドがあり、これを使ってパッチをメーリングリストに送ります。

今回自分がパッチを投げるまでに苦労したので同じことを行いたい人に向けて手順を残します。

前提条件

• git config の user.email に gmail のアカウントを設定している
• google のアカウントで2段階認証を設定している
• gmail の「メール転送と POP/IMAP」の項目で IMAP を有効にしている

事前準備

アプリパスワードを設定する

https://support.google.com/accounts/answer/185833 を見ながら設定します。

https://myaccount.google.com/security からアプリパスワードを作成します。
端末の種類を選ぶ箇所がありますが、その他で設定します。
生成が完了すると、パスワードが表示されます。
このパスワードは一度ページを離れると見れなくなるので、1password などに保存しておく必要があります。

git の config の設定をする

gitconfig ファイルに以下の設定を追加します。
大抵はリポジトリの .git/config に設定すると影響範囲が対象のリポジトリだけになるので便利です。

[sendemail]
    smtpEncryption = tls
    smtpServer = smtp.gmail.com
    smtpUser = username@gmail.com
    smtpServerPort = 587

実際にパッチを送る

実際にコマンドを実行してパッチを送ります。

git send-email HEAD^

HEAD^ の部分は適宜変更する必要がありますが、これを実行するとメールを送信するための編集画面が開きます。

特に変更する必要がなければ、このままエディタを閉じます。

すると「本当に送信するか？」というダイアログが出ます。
yesで送信しようとすると

Password for 'smtp://username@gmail.com@smtp.gmail.com:587':

というダイアログが出るので事前準備で取得したパスワードを入力します。
上手くいくとメールが送信されて、https://lists.sr.ht/USER/REPO から確認することができます。

最近AtCoderのbeginer contestにリアルタイムで参加するようになり、競プロが楽しくなってきた。

5月から参加し始めたので、約3ヶ月が経ちソースコードもそこそこ増えてきた。
せっかくなのでgithubで管理してコードが溜まっていく様子を眺めてみたいと思った。

とはいえgithubにpushしたところでACしたコードは後から手を加えないと思うので、
今回はgit hookの勉強のため、コミットメッセージを自動生成してみることを目的にしようと思う。

git hookとは

gitのコマンドのあれやこれやを使う前や後に自動で任意の処理を加えることができるスクリプト。

使い方などについては、記事の最後に参考記事のリンクを貼っておくのでこの記事では省略し、実例として紹介する。
公式のマニュアルはここで見ることができる。

コミットメッセージを自動生成

今回はgit commitを叩いたときに
prepare-commit-msgで、デフォルトのコミットメッセージが記述されているようにする。
AtCoderの解答をgit管理するので、デフォルトのコミットメッセージは自分の提出一覧へのリンクにすることにする。

自分の提出一覧へのリンクはhttps://atcoder.jp/contests/{コンテスト名}/submissions/meとなっている。

私の場合、コンテストのコードは以下のようにコンテスト名でディレクトリを分けており、偶然にも提出一覧へのリンクの{コンテスト名}と同じものをディレクトリ名にしていたので、ステージングしたファイルのディレクトリ名からURLが生成できる。

AtCoder
│  .gitignore
│  Source.cpp (雛形)
│
├─ABC126
│     Source.cpp
├─ABC127
│     Source.cpp
├─ABC129
│     Source.cpp
├─以下略

ステージングしたファイル名を取得

普段git statusをするときは特にオプションを付けていないので調べてみたところ、とても簡素にファイル名だけ表示してくれる-sコマンドがあった。

$ git status -s
 M ABC126/Source.cpp

prepare-commit-msg

上述したファイル名からディレクトリ名だけ切り出して、URLをつなげてコミットメッセージへ流す。出来上がったものは以下の通り。

prepare-commit-msg

#!/bin/sh

if [ "$2" == "" ] ; then
    # addしたファイル名からURLを作る
    echo "https://atcoder.jp/contests/`git status -s | awk -F '[ /]' '{print $3}'`/submissions/me `cat $1`" > $1
fi

git commit後

https://atcoder.jp/contests/ABC126/submissions/me 
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Changes to be committed:
#   modified:   ABC126/Source.cpp
#

ShellScriptはあまり得意ではない。

参考記事

Git フックの基本的な使い方
git hook はじめの一歩