- 投稿日：2019-02-26T19:05:32+09:00
masterブランチ一本槍で攻めていたプロジェクトを、過去に遡って整理した 「初期状態（git init 時）に開発用ブランチを切っておけばよかった....」という時の事業仕分け
TL;DR ( = "Too Long; Didn't Read")
プロジェクトのgit 管理が雑だったためやり直しました。
- master の一本槍だった （一人で管理していたため、まあいいや、の精神でした）
- 受託案件にて、複数の細かな複数の仕様変更が来た
- 問題点１・・・それぞれの更新タイミングが未定
- クライアント：「今週は仕様Aを適用してね。」「来週は仕様Bを適用してね。」
- 問題点２・・・ころころ仕様が変わる
- クライアント：「やっぱり仕様Aはなしね。」「今週は仕様Cを適用して、仕様Bはとりあえず保留ね。」
- 初期状態（git init 時）に開発用ブランチを切っておけばよかった....
慌てて以下の手順で整理
git initを行った際の初期状態のcommit 遡り、新たにmaster_newブランチを作る- 現在のブランチ （
master）を、開発用ブランチとする (feature-A)- １で作った
master_newブランチをリネームしmasterブランチとするgit 生理前
master -------------------- いろんな修正-A --------------------> currentgit 生理後
master-------------------------------------------------> current | ^ +--- feature-A -------------- いろんな修正-A ---------------|
- 以下の流れで git 管理を修正しました。
1.
git initを行った際の初期状態のcommit 遡り、新たにmasterブランチを作る初期状態（git init 時）に開発用ブランチを切っておけばよかった....
ということなので、まず initial commitに戻り、ブランチを切ります。
gitで過去のcommitに対してbranchをきるこの時点ではまだ
masterブランチが存在するため、新たに作るブランチは仮にmaster_newとします。
git checkout <hash> // 過去のcommitへcheckout. 一時的に detached head になるが怖がらずに
git checkout -b master_new // 新規ブランチを作成とともにcheckout.
この作業により、以下のような形になりました。master-------------------------------------------------> current | +--- master_new (こいつをいずれmaster とします）2. 現在のブランチ （
master）を、開発用ブランチとする (feature-A)いままで
masterとして進めてきたブランチですが、実質作業は仕様変更Aを行っていたため、
feature-Aへと名前を変更します。（masterは直接編集しない）2.1. ローカルの
masterブランチの名前をfeature-Aへ変更git branch -m master feature-A2.2. リモートの
masterブランチの名前をfeature-Aへ変更リモートブランチの名前変更は不可（？）ググっても情報見つからず
→ 一度削除して、新規名前でもう一度作る、という手順を経る2.2.1. リモート master ブランチを削除
git push origin :masterエラー。削除に失敗。下記を参考にさせていただく。
[git] リモートのmasterブランチを削除するリモートのmasterブランチはデフォルトだから、消したら次にgit cloneしたときに困るということみたいです。
すぐにmasterを作り直す予定なので、エラーメッセージに従い一時的にカレントブランチの削除を許可させました。リモートリポジトリのconfigファイルに、以下を追加すれば削除ができるようになります。2.2.2. vim を使用して .git/config ファイルに以下を追加
※ bare リポジトリに共有としていたため、そちらを変更（ローカルの .git/config ではない）
vim xxxxx/.git/config // 下記を追加 _________________________________________ [receive] denyDeleteCurrent = false _________________________________________2.2.3. リモート master ブランチを削除 (再)
git push origin :master→ 削除に成功。
2.2.4.
feature-Aとしてリモートリポジトリを作成git push -u origin feature-Aこの作業により以下のような形になりました。
feature-A-------------------------------------------------> current | +--- master_new (こいつをいずれmaster とします）3. １で作った
master_newブランチをリネームしmasterブランチとするgit branch -m origin master_new master以上の作業で、以下のような構造になりました。
master (もとはmaseter_new) | +--- feature-A -------------------------------------------------> current上記の手順でmaster ブランチよりマージを行えば、下記のような状態へ持っていけます。
master-------------------------------------------------> current | ^ +--- feature-A -------------- いろんな修正-A ---------------|
- 投稿日：2019-02-26T17:06:30+09:00
GitHub で noreply email へ移行する際にすべきこと
GitHub Privacy 101: How to remove personal emails from your public repos
上記リンク先の記事を参考にしています。
途中から noreply email を使い始めても、いままでのコミットに記載されたメールアドレスは noreply に変わることはないので、GitHub 上でアイコンが適切に表示されないコミットが発生したり、以前に使用していたメールアドレスがコミットログに記載された状態で公開され続けたりします。
今までに使用していたメールアドレスをコミットログから抹消したければ、すべてのコミットを消去してしまうしかありません。以下のコマンドを実行してすべてのコミットを無かったことにします。
git checkout --orphan new-master git add . git commit -m "Clean commits" git branch -m master old-master git branch -m new-master master git push --force --set-upstream origin master git branch -D old-master
- 投稿日：2019-02-26T13:05:41+09:00
巨大なファイルを含んだリポジトリの履歴を改変して GitHub にインポートする方法
概要
GitHub.com には巨大なファイルを含んだコミットに対して push 制限があります。
具体的には push をする際、 次のようなメッセージが表示されます
- コミットに 50MB を超えるファイルが含まれている場合は warning が表示されます
- warning は表示されるものの、リモートへの転送自体は成功します。（ただし非推奨）
remote: warning: Large files detected. remote: warning: File big_file is 55.00 MB; this is larger than GitHub's recommended maximum file size of 50 MB
- コミットに 100MB を超えるファイルが含まれている場合は error が表示されます
- リモートへの転送に失敗します
remote: warning: Large files detected. remote: error: File giant_file is 123.00 MB; this exceeds GitHub's file size limit of 100 MB上記の問題は、以下のいずれかの対応をすることで解決できます。
1. 対象ファイルが必要な場合は、Git-LFS を利用する Versioning large files
2. 対象ファイルが不要な場合は、リポジトリから取り除く Removing files from a repository's historyこの記事では、後者の巨大なファイルをリポジトリから取り除く 2 通りの手順について紹介します。
具体例
プロジェクトで利用するために、外部で構成管理されているリポジトリを GitHub.com にインポートするケースについて考えてみます。
例えば Android オープンソースプロジェクト（以下 AOSP）は android.googlesource.com で公開されていて 1,000 を超える Git リポジトリから構成されています。これらのリポジトリの中には、「巨大なファイルが含まれている、または過去に含まれていた」リポジトリがあり、GitHub.com でそのままインポートすることができません。
- 実際、見つかった巨大なファイルの多くは、通常のソースコードではなくビルド済みバイナリであったりテストデータであったりします。
次のステップでは、実在する外部管理のリポジトリを GitHub.com にインポートする処理を行います。
Step0 インポート時に git-push が失敗することの確認
巨大なファイルが含まれていることがあらかじめ判明している AOSP の platform/system/core.git を題材として、GitHub.com へのインポートに失敗することを確認します。
まずは以下の手順でインポートを試みます。
$ git clone --mirror https://android.googlesource.com/platform/system/core $ git remote add github $YOUR_GITHUB_URL $ git push --mirror github remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. remote: error: Trace: be6e0a48b32da493f6a767241ba85e9b remote: error: See http://git.io/iEPt8g for more information. remote: error: File libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so is 219.06 MB; this exceeds GitHub's file size limit of 100.00 MB ! [remote rejected] android-9.0.0_r16 -> android-9.0.0_r16 (pre-receive hook declined)ここで上記のエラーが出ました。エラー内容から 200MB を超える共有ライブラリ
libartd.soがコミットされていたため push に失敗したことがわかります。次のステップでは、巨大なファイルの正体を特定します。
Step1 対象ファイルの特定する
200MB を超える共有ライブラリがコミットが含まれていたため、 GitHub.com への push に失敗しました。ところが実際は、この共有ライブラリは指定のパスには既に
libartd.soは存在しません。$ test -e libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so次に、既に削除済みファイルであることを確認します
$ git log --diff-filter=D --summary -- libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so delete mode 100644 libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.soつまり、例え削除済みであっても、巨大ファイルを含んだコミットがあったことには変わりないため、push に失敗したことがわかりました。このように push に失敗する前に、リポジトリの中に含まれた巨大なファイルをあらかじめ確認するためには、Atlassian の Reduce repository size で紹介されている
git_find_big.shを活用すると良いことが知られています。このスクリプトでは Git 内部の パックファイル を走査して、巨大なファイルのサイズ順に表示してくれます。今回扱う platform/system/core.git リポジトリを対象にgit_find_big.shを実行すると次の結果が得られます。All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file. size pack SHA location 224312 60015 70352dbb7a51e338096bb1305ea63641a39200cd libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so 28051 7497 e72e673ad74ff69060291ddab1a3989a7c6a8c07 libunwindstack/tests/files/offline/jit_debug_x86_32/libarttestd.so 10380 3225 92ed9915d4f9ea96a4accfcad82c657ff72f17fd libunwindstack/tests/files/offline/jit_debug_x86/libartd.so 8127 3048 ef1a6a1857bc2613a9ae162dd56f2cb67858eb3a libbacktrace/testdata/arm64/libskia.so 5968 2422 05278936be5fda0f62b5bd37b6951bcdbb5e8cd2 libunwindstack/tests/files/offline/jit_debug_arm/libart.so 5952 2401 09ba49532205981ff638c6935436cbb09d678aba libunwindstack/tests/files/offline/art_quick_osr_stub_arm/libart.so 5400 2175 bed8e3595aa8cab7f381cfcb7aa05d10f010e687 libbacktrace/testdata/arm/libart.so 5294 2610 855905655e4c822794b6d66657c657b5307f17c9 libunwindstack/tests/files/offline/jit_debug_arm/libartd.so 5076 1392 092fc3aec90445662e23c2fdca8207e031602793 libunwindstack/tests/files/offline/straddle_arm64/libunwindstack_test 4134 1369 871f6dc89e9fb88b8758f5ef2deb2224295f8411 libbacktrace/testdata/arm/libGLESv2_adreno.so上記の結果から、 50MB を超える巨大なファイルは
libartd.soだけであることが明らかになりました。したがって、
1. 過去に管理されていた巨大なファイルが参照できなくても問題ないこと
2. 対象コミット以降のすべてのコミットハッシュ（SHA-1）が変わっても問題ないこと上記のポイントを理解したうえで、それでも問題がなければ、次のステップで、対象コミットを削除するためにコミット履歴を書き換えます。
Step2 コミット履歴の書き換え
Step2a コミット履歴の書き換え:
git-filter-branchを用いた場合git-filter-branch コマンドを用いることで、コミット履歴を書き換えることができます。
すべてのブランチ・タグから対象の巨大なファイルを rm する場合は、次のコマンドで実現できます$ time git filter-branch --index-filter 'git rm --ignore-unmatch libunwindstack/tests/files/offline/jit_debug_x86_32/libartd.so' --tag-name-filter 'cat' -- --allオプションの説明:
--index-filter <command>
- 各コミットハッシュに対して
<command>を実行します--tag-name-filter <command>
- コミット履歴の書き換えに際し、新しいコミットハッシュに対してタグを上書きするオプションです
<command>の規則にしたがってタグ名を上書きします- 元のタグ名のままタグを上書きする場合
--tag-name-filter 'cat'- すべて大文字でタグを上書きする場合
--tag-name-filter 'cat | tr [:lower:] [:upper:]'- タグを上書きしても元のメッセージやタイムスタンプ、Tagger は変化しませんが、 タグにつけられた GPG 署名はストリップされます
-- --all
git-filter-branchの対象とするコミットハッシュを取得する際のgit-rev-listに渡すオプションです- 今回の目的はすべてのブランチ・タグから巨大なファイルを削除したいので
--allとしますファイル削除の確認手順
上記
git-filter-branchを実行後、libartd.soの削除が正しく行われたことを確認します。$ git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
git-filter-branchによって退避されたrefs/originalのすべての参照を git-update-ref で削除します$ git reflog expire --expire=now --all
- アクセスできないすべての無効な reflog エントリを削除します
$ git gc --prune=now
- git-gc で GC を実行し、古いオブジェクトを削除して、パックファイルを更新します
その後
git_find_big.shを再実行しますAll sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file. size pack SHA location 28051 7497 e72e673ad74ff69060291ddab1a3989a7c6a8c07 libunwindstack/tests/files/offline/jit_debug_x86_32/libarttestd.so 10380 3200 92ed9915d4f9ea96a4accfcad82c657ff72f17fd libunwindstack/tests/files/offline/jit_debug_x86/libartd.so 8127 3048 ef1a6a1857bc2613a9ae162dd56f2cb67858eb3a libbacktrace/testdata/arm64/libskia.so 5968 2417 05278936be5fda0f62b5bd37b6951bcdbb5e8cd2 libunwindstack/tests/files/offline/jit_debug_arm/libart.so 5952 2401 09ba49532205981ff638c6935436cbb09d678aba libunwindstack/tests/files/offline/art_quick_osr_stub_arm/libart.so 5400 2170 bed8e3595aa8cab7f381cfcb7aa05d10f010e687 libbacktrace/testdata/arm/libart.so 5294 2607 855905655e4c822794b6d66657c657b5307f17c9 libunwindstack/tests/files/offline/jit_debug_arm/libartd.so 5076 1391 092fc3aec90445662e23c2fdca8207e031602793 libunwindstack/tests/files/offline/straddle_arm64/libunwindstack_test 4134 1362 871f6dc89e9fb88b8758f5ef2deb2224295f8411 libbacktrace/testdata/arm/libGLESv2_adreno.so 3695 1604 7a30bfa440efc24d651b544163e5574d6b027a63 libunwindstack/tests/files/offline/offset_arm/libunwindstack_test上記のとおりようやく 50MB を超える
libartd.soが存在しなくなっていることが確認できました。ところがここで一つ課題があります。
今回の作業は Azure D2V2 (Core=8, RAM=28GB, SSD=400GB) インスタンスで行いましたが、実行時間は
real 15m48.335sと 15 分以上要しました。実行時間をより短くするために、次のステップでは、 BFG という機能を絞ったシンプルかつ高速なツールを紹介します。Step2b コミット履歴の書き換え:
BFGを用いた場合BFG は Scala 製でシンプルかつ高速なツールです。
git-filter-branchほど複雑な処理はできませんが、今回の目的に最も適した--strip-blobs-bigger-than <MB>という便利なオプションがあります。再度取得し直した platform/system/core.git にこのツールを適用してみます。$ java -jar bfg.jar --strip-blobs-bigger-than 50M platform/system/core.gitオプションの説明:
strip-blobs-bigger-than 50M
- 50MB より大きなすべての blob を削除します
実行結果
Scanning packfile for large blobs: 140503 Scanning packfile for large blobs completed in 1,009 ms. Found 1 blob ids for large blobs - biggest=229696508 smallest=229696508 Total size (unpacked)=229696508 Found 1897 objects to protect Found 687 tag-pointing refs : refs/tags/afw-test-harness-1.5, refs/tags/afw-test-harness-2.1, refs/tags/android-1.6_r1, ... Found 190 commit-pointing refs : HEAD, refs/heads/master, refs/remotes/origin/HEAD, ... Protected commits ----------------- These are your protected commits, and so their contents will NOT be altered: * commit f80c326d (protected by 'HEAD') Cleaning -------- Found 45661 commits Cleaning commits: 100% (45661/45661) Cleaning commits completed in 4,047 ms. Updating 89 Refs ---------------- Ref Before After --------------------------------------------------------------------------- refs/heads/master | f80c326d | 9a90afc4 refs/remotes/origin/master | f80c326d | 9a90afc4 refs/remotes/origin/master-cuttlefish-testing-release | fd088948 | 9c55624d refs/remotes/origin/nougat-iot-release | 044e0276 | 52cd619d refs/remotes/origin/o-mr1-iot-preview-7 | 2b49abe4 | 8ff6ed0b refs/remotes/origin/o-mr1-iot-preview-8 | 22dc27b9 | 219cb8c9 refs/remotes/origin/oreo-mr1-1.2-iot-release | c53a0e91 | 8e1c9575 refs/remotes/origin/oreo-mr1-iot-release | f307efcf | 9ee5bb5f refs/remotes/origin/pie-cts-dev | 2ef5c2ef | 1be06911 refs/remotes/origin/pie-cts-release | bfe37429 | 0710a778 refs/remotes/origin/pie-cuttlefish-testing | 17b9e8e0 | 7135e773 refs/remotes/origin/pie-dev | 820ef150 | c9998b31 refs/remotes/origin/pie-dr1-dev | 93d837f3 | bfe27d17 refs/remotes/origin/pie-dr1-release | 47e38865 | 92fcac25 refs/remotes/origin/pie-gsi | afc32531 | 788ecf39 ... Updating references: 100% (89/89) ...Ref update completed in 55 ms. Commit Tree-Dirt History ------------------------ Earliest Latest | | .....................................................DDmmmmm D = dirty commits (file tree fixed) m = modified commits (commit message or parents changed) . = clean commits (no changes to file tree) Before After ------------------------------------------- First modified commit | 150db124 | ecbcdafc Last dirty commit | e242a97d | cd89e6b1 Deleted files ------------- Filename Git id -------------------------------- libartd.so | 70352dbb (219.1 MB) BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive上記のような実行レポートのサマリーが得られます。
Deleted filesから何が削除されたかも明らかになりました。より詳細な実行レポートはリポジトリ脇のディレクトリ配下に次の形式で残されています。
cache-stats.txtdeleted-files.txtobject-id-map.old-new.txtそして実行結果はわずか
real 0m9.403sで、git-filter-branchよりも 100 倍前後高速に結果が得られました。またgit_find_big.shの内容も Step2a と同一でした。Step3 インポート成功確認
最後に GitHub.com にインポートできることを確認します。
$ git push --mirror github今度は無事成功しました。
上記 Step2a, Step2b のどちらの手法を用いても巨大なファイルは削除され、
git-pushできるようになったことが確認されました。削除できない巨大なファイルが含まれている場合は
今回の例では、見つかった巨大なファイルが不要なため削除できるケースでしたが、削除できない場合はどうでしょうか。まずは Git LFS を利用するのが最も素直な解になります。それでもプロジェクトの都合で Git LFS が利用できない場合は巨大なファイルを分割したり、圧縮したりする回避策もあるかもしれません。
管理方法
$ md5sum $LARGEFILE > $LARGEFILE.md5 $ split $LARGEFILE -b 10M $LARGEFILE-
- 元ファイルのチェックサムと数 MB ごとに分割したファイルとして管理します
復元方法
$ cat $LARGEFILE-* > $LARGEFILE $ md5sum -c $LARGEFILE.md5
- githooks の
post-mergeやビルドシステムなどで fetch 後に復元処理と元ファイルとの完全性を確認しますただし what-is-my-disk-quota にもあるように GitHub ではリポジトリのサイズは 1GB 以下を推奨されているため、分割管理をしたとしてもサイズの総和の制約は回避できません。
まとめ
この記事では、不要かつ巨大なファイルが含まれたリポジトリを GitHub.com にインポートする手順についてまとめました。
git-filter-branchでもBFGでも不要なファイルを扱ったコミットを除去できることが確認できました。単純に巨大なファイルを削除するだけが目的ならBFGを用いて、タグを一意の命名規則に沿って上書きしたり、ブランチ別に処理を分ける等、より複雑な操作をするときはgit-filter-branchを用いると良いと思います。
- 投稿日：2019-02-26T08:08:35+09:00
【最新サービス試用④】Gitの差分を視覚的に楽しめて、イメージの手助けとなる、「Git History」を試用
- 日々輩出される素晴らしき最新サービスを素早く試して、不鮮明な先見性を堂々と誇示する記事第四弾。
- あるドラマでの、「真似事でも、必死で見習えば、それは本物だから」という刺激的名言を、「山盛り解釈・少々捏造」の行為で、大量模倣の許可を得たと被害妄想。
- 今回は、GitHubの差分が、視覚的に楽しく把握できる「GitHistory」を試用することにしよう。
試用サービス名
「Git History」
概要
- 把握しづらい差分を、視覚的に動きをつけて表示してくれる。
- コミッターやメッセージも非常に見やすい。
- インストール不要で、GitHub上でURLを変えるだけでよい。
- 初学者がイメージをつかむのに適している
結果
- 下記の例は、GitHub上の「Vue.js」のpackage.jsonファイル
- バージョンの変化が把握できる。
基本手順
1. GitHubへ行く。
2. 差分を表示したいファイルを開く。
※GitHubアカウントを持っていない場合は、気になるオープンソースプロジェクトのファイルでも良い。
※GitHubのスター数（評価数）ランキングはこちら。3. ファイルのURLを下記のように変更
※例では、「Vue.js」のpackage.jsonを使用。
＜変更前＞ : https://github.com/vuejs/vue/blob/dev/package.json ＜変更後＞ : https://github.githistory.xyz/vuejs/vue/blob/dev/package.json
- 例のように、URLの「github.com」の部分を、「github.githistory.xyz」へ変更
4. 表示確認。
5. 左右矢印キーで、差分確認
※だいぶ奥深くでの変更等はわかりづらい。
6. 差分を詳細に見たい場合は、コミッター欄のリンクで、確認。
※各コミットファイルへアクセスできる。
7. 完了
試用感
- 差分を視覚的なアニメーションで楽しめる。
- 奥深くの差分や多くの量等の、一発では把握しにくいものもある。
- しかし、各個別の差分ファイルへのリンクがあるので良い。
- Git環境がなくても、簡単にできる。
- 初学者がGitの概念やイメージを把握しやすい。
まとめ
- 今回は、差分表示の視覚的把握ということで、「将来、散髪や化粧・体重変化等が、鮮やかに把握できる視覚機器が出ないかな。」という、高等級男性の特徴的行動までも自己解決しない、底辺等級人の私。
- 「今回もJavaScript製とはね」という、この言語の多様性・可能性を身に染みて再認識。
- 試用後の恒例行事の「開発者への礼拝作業」に、今回は「全開発者への魅力サービス開発祈願」という、本来の意味を大きく逸れた礼拝を追加することにしよう。
参考
- https://www.moongift.jp/2019/02/git-history-%E3%83%93%E3%82%B8%E3%83%A5%E3%82%A2%E3%83%AB%E7%9A%84%E3%81%AA%E5%B7%AE%E5%88%86%E8%A1%A8%E7%A4%BA/
→こちらの紹介記事で知りました。毎度毎度大変お世話になっております。今回もありがとうございました。
- 投稿日：2019-02-26T07:00:31+09:00
Gitの大きいリポジトリを小さくする方法
git gcだけだと二週間がデフォルトなのですぐに消えない。
nowをつけて即時削除する。$ git reset HEAD $ git reflog expire --expire=now --all $ git gc --aggressive --prune=now参考： https://blog.clock-up.jp/entry/2017/12/03/git-gc
これで
.git/容量が 1.2GB -> 5.7MB になった。
- 投稿日：2019-02-26T02:29:20+09:00
remote repositoryの作成＆初めてのpush
はじめに
リモートリポジトリを作成し、初めてpushを行うためには、以下の（１）～（５）を行う必要がある。
（１）リモートリポジトリ作成
ホーム画面左上のリモートリポジトリ作成ボタンを押す。
（２）リモートリポジトリの名前決定
スペース無しで、アンダーバー、スペース、大小文字を駆使して名前を付ける。
（３）リモートリポジトリをgitを紐づけ
$ git remote add origin git@github.com:Sega-Hiro/リモートリポジトリ名 origin git@github.com:Sega-Hiro/リモートリポジトリ名 (fetch) origin git@github.com:Sega-Hiro/リモートリポジトリ名 (push) //成功（４）ローカルリポジトリのmasterブランチをpush
ローカルリポジトリのmasterブランチをリモートリポジトリのmasterに上書きする。
$git push origin master Counting objects: 100% (6/6), done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 701 bytes | 701.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:Sega-Hiro/kidukebapronamiPHP_revised-edition.git * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'. //成功（５）add、commit、pushする
任意のファイルをadd、commit、pushすれば良し。
- 投稿日：2019-02-26T02:29:20+09:00
remote repositoryの作成し、初めてpushする for Win7
はじめに
リモートリポジトリを作成し、初めてpushを行うためには、以下の（１）～（５）を行う必要がある。
（１）リモートリポジトリ作成
ホーム画面左上のリモートリポジトリ作成ボタンを押す。
Descriptionは空欄で良い。
README.mdは、ここで追加せずにファイルとして後から追加する方が良い。
（２）リモートリポジトリの名前決定
スペース無しで、アンダーバー、スペース、大小文字を駆使して名前を付ける。
（３）リモートリポジトリをgitを紐づけ
$ git remote add origin git@github.com:Sega-Hiro/リモートリポジトリ名 origin git@github.com:Sega-Hiro/リモートリポジトリ名 (fetch) origin git@github.com:Sega-Hiro/リモートリポジトリ名 (push) //成功（４）ローカルリポジトリのmasterブランチをpush
ローカルリポジトリのmasterブランチをリモートリポジトリのmasterに上書きする。
$git push origin master Counting objects: 100% (6/6), done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 701 bytes | 701.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:Sega-Hiro/kidukebapronamiPHP_revised-edition.git * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'. //成功（５）add、commit、pushする
任意のファイルをadd、commit、pushすれば良し。
- 投稿日：2019-02-26T01:56:27+09:00
git pushでsimpleでもcurrent
「
push.default = currentは楽だけど、ちゃんと tracking 設定したいなぁ。でもpush.default = simpleでいちいち-uつけるのは面倒だなぁ。」という人向けの zsh の設定。
.gitconfigの alias で設定したいけど、 git のコマンドは存在するコマンドを上書きさせてくれないので zsh で変更する。まず、
setopt correctやcorrect_allで修正を提示する感じをシミュレーションする。SPROMPTにフォーマットが入っているので、readで聞いて 0 から 3 の数値を返す。function ask_ynae { local prompt=${SPROMPT/\%r/$1} while true; do read -rsk \?"$prompt" ynae case $ynae in [Yy] ) return 0 ;; "" | [Nn] ) return 1 ;; [Aa] ) return 2 ;; [Ee] ) return 3 ;; esac echo -ne "\r" done }実際に git をラップする部分。
\gitのようバックスラッシュを使うと、置き換え前のコマンドを使える。組み込みの-zで次の編集中のコマンドにできる。function in_git() { [[ "$(git rev-parse --is-inside-work-tree 2> /dev/null)" = "true" ]] } function wrapped_git() { if [[ "$*" = "push" ]] && in_git && ! (\git rev-parse --abbrev-ref @{upstream} >/dev/null 2>&1); then suggest="push -u origin $(\git rev-parse --abbrev-ref HEAD)" ask_ynae "git $suggest" exit_code=$? echo case $exit_code in "0" ) \git ${=suggest} ;; "1" ) \git $@ ;; "2" ) return 130 ;; "3" ) print -z "git $@" ;; esac else \git $@ fi } alias git=wrapped_git