結論

Git initしたディレクトが起点となる。

例えばrails new sampleをする。この時.gitignoreが作成されてgit initも行われる。

~/Ruby_on_Rails/sample
➜ rails new sample
      create
      create  README.md
      create  Rakefile
      create  .ruby-version
      create  config.ru
      create  .gitignore  # .gitignoreが作成された
      create  Gemfile
         run  git init from "."　 # git init が実行された
Initialized empty Git repository in /Users/lamp/Ruby_on_Rails/sample/sample/.git/

〜省略〜

.gitignore_globalがホームディクレリにあったとしても、rails newを実行したディレクトリを起点にした相対パスでGitの管理から外したいファイルを書く。

.gitignoreが存在するディレクトリに.gitignore_globalもあるというイメージ。

~/Ruby_on_Rails/sample on  master 
➜ ls -a
.                 .git              Gemfile           Rakefile          bin               db                node_modules      public            tmp
..                .gitignore        Gemfile.lock      app               config            lib               package.json      storage           vendor
.browserslistrc   .ruby-version     README.md         babel.config.js   config.ru         log               postcss.config.js test              yarn.lock

検証

上の結論が正しいこと確かめてみる。
ホームディレクトリの.gitignore_globalに/ignored.txtを追記。/ファイル名のように記述すると.gitignoreが存在するディクトリを起点とする相対パスで、Gitの管理から外すファイルを指定できる。つまり.gitignore_globalはホームディレクトリにあるので、もしホームディレクトリを起点としているならば無視するファイルは~/ignore.txtのみである。

~/Ruby_on_Rails/sample on  master
➜ touch ignored.txt hoge.rb

~/Ruby_on_Rails/sample on  master [?] 
➜ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    hoge.rb

nothing added to commit but untracked files present (use "git add" to track)

hoge.rbとingnored.txtを新規作成したが、Gitが管理しているファイルはhoge.rbのみである。
よって.gitignore_globalにはgit initを実行したディレクトリを起点とした相対パスで無視したいファイル名を記述する。

.gitignoreの書き方

/hoge.rbと書く→ .gitignoreのあるディレクトリと同じディレクトリのhoge.rbを無視する

.
├── .gitignore
├── bar
│   └── hoge.rb
└── hoge.rb #このファイルを無視する

hoge.rbとスラッシュなしで書く→ .gitignore以下の全ての階層のhoge.rbを無視する

.
├── .gitignore
├── bar
│   └── hoge.rb #このファイルを無視する
└── hoge.rb #このファイルを無視する

リモート→ローカルの順でリポジトリを作成する方法です。README.mdファイルはGitHubで作成します。

1. リモートリポジトリを作成する

README.mdファイルを作成する場合は、Initialize this repository with a READMEにチェックを入れます。

リポジトリが作成が完了すると、画面が切り替わります。右上のCodeという緑色のボタンを押すと、リポジトリのURLが表示されます。URLの右側のボタンをクリックすると、URLをコピーできます。

2. ローカルにクローンする

ローカルリポジトリは一から新しく作成せず、リモートリポジトリをクローンして作成します。URLはブラウザからコピーしましょう。

$ git clone https://github.com/your-github-account/my-repository.git

your-github-accountは自分のGitHubアカウントに置き換えてください。

参考リンク

• 【Git】リポジトリの作成方法（ローカル→リモート）〜GitHubにpushするまで

ローカル→リモートの順でリポジトリを作成する方法です。README.md等のファイルはローカルで作成し、GitHubにpushします。

1. ローカルリポジトリを作成する

$ mkdir my-repository
$ cd my-repository
$ git init

2. 最初のコミットを行う

README.mdファイルを作成し、コミットします。README.mdファイルはechoコマンドで作成していますが、エディタで編集してもOKです。

$ echo "# my-repository" >> README.md
$ git add README.md
$ git commit -m "first commit"

3. リモートリポジトリを作成する

GitHubでリモートリポジトリを作成します。README.mdやライセンスファイル等のファイルは、リモート側では作成しないようにします。作成すると、リモートリポジトリを追加するときにエラーになります。

Quick setupにリポジトリのURLが表示されます。URLの右側のボタンをクリックすると、URLをコピーできます。後で使用するので、この画面は開いたままにします。

4. リモートリポジトリを追加する

ローカルリポジトリにリモートリポジトリを関連付けます。URLはQuick setupからコピーしましょう。

$ git remote add origin https://github.com/your-github-account/my-repository.git

your-github-accountは自分のアカウントに置き換えてください。

5. リモートリポジトリにpushする

ローカルでコミットした変更内容をリモートリポジトリに反映します。

$ git push -u origin master

GitHubにpushするのが初めての場合は、ユーザー名とパスワードを求められるので、入力します。

参考リンク

• 【Git】リポジトリの作成方法（リモート→ローカル）

はじめに

対象読者

• html 等のファイルを静的に出力するタイプの CMS を使っている人
  • 静的 CMS とは？　たとえば……
    • PowerCMS / PowerCMS X
    • Movable Type
    • など
  • Netlify などは、リポジトリをベースにサイトデプロイしてくれる CMS といえるわけですが、その逆方向のケアをしてあげるということになります
• GitHub 等のリポジトリへ差分バックアップを取って管理するようにしたい人
  • 別に BitBucket でも GitLab でも構わないので、適宜読み替えてください
• 特に CMS とか関係ないけれど、とにかく cron で定期的に GitHub へバックアップする方法を知りたい人

本記事におけるサーバ環境

• Ubuntu 20.04

前提

• git コマンドが使える環境
• root 以外のユーザーで SSH ログイン
• あらかじめ GitHub 側でリポジトリを作成しておく
  • ここでは仮に cms-static とする

設定

静的ファイルを置いているディレクトリの Git リポジトリ化

• cd で静的ファイルを置いているディレクトリへ移動
• Git リポジトリ化する

git init

git config --global

• もしまだ git config --global を設定していなかったら、する
  • name, email ともに自身のものを設定

git config --global user.name "GitHubUserName"
git config --global user.email GitHubRegisteredAddress@domainhogehoge.com

キーペア作成／登録

• もしまだキーペアを作成／登録していなかったら、する

キーペア作成

• 4096 bit で作成する

ssh-keygen -b 4096

• 以下が表示されたら enter を押すとデフォルトの id_rsa で作成される
  • 特にこだわりがなければそのままで作成した方がよい
  • というのも GitHub はデフォルトだと他のキー名を読んでくれない
  • 他のキー名へ変更する際には必ず config ファイルを作成しましょう

Enter file in which to save the key (/user/username/.ssh/id_rsa): 

• もし他のキー名へ変更する際の config ファイルの中身
  • 例えば github_rsa へ変更する場合

/home/ptnaweb/.ssh/config

Host github github.com
  HostName github.com
  IdentityFile ~/.ssh/github_rsa
  User git

公開キーの登録

• GitHub の管理画面から登録してください

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

• cms-static という既に GitHub に作ってあるリポジトリを push origin の向かい先として登録する

git remote origin git@github.com:GitHubUserName/cms-static.git

• 正しく登録されたかどうかは、以下コマンドで確認

git remote -v

リポジトリへの push テスト

• 一度手動で実行してみるとよいでしょう
  • 初回実行時に fingerprint の登録云々と訊かれるので yes で進める

git add -A
git commit -m "backup_`date '+%Y/%m/%d'`"
git push origin master

cron

• 以下コマンドで cron の編集ファイルを開く

crontab -e

• 以下を記述
  • 毎日 03:00 に Git リポジトリ化されている /var/www/cms/static/ の変更を add, commit して push するよ、という内容です
  • 注意点としては date の取得時に % をエスケープしてあげる必要があるということ

0 3 * * * cd /var/www/cms/static/; git add -A; git commit -m "backup_`date '+\%Y/\%m/\%d'`"; git push origin master;

検証

GitHub リポジトリ

• リポジトリを確認して、正しく反映されていればよしです

おわりに

感想

• CMS 内に差分管理できる機能を備えたものもありますが、 GitHub で一元的に管理できるようになっていると、一覧性が担保できてわかりよいですね
• cron の中で日付を記述する時にはエスケープ使わないといけない、というのがちょっとしたクセモノ

関連して

• そもそも出力された静的ファイルは、管理サーバ内ではなく外に置いておきたいですよね！　というニーズを満たすために、以下の記事を書いています
  • CMSの管理サーバと静的ファイルの公開サーバを別に分ける

概要

この記事ではDjango-girlsのチュートリアルを進める初心者向けに、PythonAnywhere上でのConsoleがうまく挙動しなくなった際の留意点を初心者が幾つかまとめておく。

半日くらい分かんなくてもう無理詰んだ、って思っても
まぁ、大体エラー文を読み続けてればなんとかなります。たぶん。

実行環境

• Windows10 64bit
• Python 3.6
• git version 2.27.0.windows.1
• Chromeブラウザ

エラーが出た際の確認手順

web上でうまく表示されないとか

コンソールが途中で止まるとか

原因は色々考えられるが、

１．まずはリモートリポジトリにあげる前のローカル環境で実行してみよう。

python manage.py runserverを実行して、サイトが動いているか（変更が反映されているか）確認。

ここでhtmlやcssが反映されていない場合は、
- サーバーを再度走らせる
- ブラウザの更新ボタンを右クリックしてキャッシュクリア＆リロード
を試す。
反映されない場合、コードのほうに誤りがないか確認する。

問題がなければ次のステップ。

---

２．GitHubにちゃんと変更がpushされているか確認。

ブラウザからリポジトリの中にある、更新したファイルをみてみる。
反映されていない場合、Console上で再度以下のコマンドをたたく。

% git status
% git add --all .
% git status

赤文字が緑になったら選択されているので、そのままコミット。(XXXXはブランチ名)

% git commit
% git push origin XXXX

詳しい用語の説明については、他記事で分かりやすくまとめてくれている方がいるのでここでは省略する?（【Git】オレならこう説明する！Git初心者への用語説明）

※git statusで変更が検出されない場合は以下の手順を試す

% git fetch --all
% git add -A
% git commit -m"recommit" -v
% git push

※マージせなあかんで！と怒られちゃった場合

% git merge --allow-unrelated-histories origin/master

調べたところ、どうも現verでは関係のないヒストリー同士をマージするにはオプションの追記が必要らしい。詳しくはこちらの記事?（：初めてGitHubリポジトリにpushしたらrejectedエラーになったときの対応メモ）

※(余談)プルしようとしたら「マージする前にコミットするか隠して！」と怒られた場合?

ErrorMessage

error: Your local changes to the following files would be overwritten by merge: 
         XXXX.py
Please commit your changes or stash them before you merge.
Aborting

対処法➊：隠す

#一旦退避してプル
$ git stash
$ git pull origin master
#スタッシュを戻す
$ git stash pop

対処法➋：強制的にマージ（とにかくリモートに合わせれりゃいい！って時にオススメ）

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

リモートリポジトリに無事プッシュ出来たら、PythonAnywhere.comへ。

---

３．PythonAnyWhere上でConsoleエラーが出る時

GitHubまではうまくいってるのに、ブラウザにうまく表示されない。
そん時は、だいたいConsoleを立ち上げればヒントが隠されている。

Consoleを立ち上げて
通常、--nukeオプションを付与して以下のコマンドを実行することで自動でvenvを作り直したりあれこれ自動でやってくれる。

pa_autoconfigure_django.py https://github.com/your-github-username/my-first-blog.git --nuke

これでうまく表示されればそれでOK。

自分の場合、復習がてらもう一度 同一コンソール上からPythonAnywhere.comを作る所からやろうとして、見事に躓いた。

⇩KeyError: 'collectstatic'と表示されとまってしまう。

色々と試行錯誤した結果、
原因はSECRET_KEYが上手く読み込まれてないことと分かった。
どうりで、ページは表示されなくなるし作り直そうとしても途中で止まってしまうわけだ・・。.ignoreに指定しているからよく考えなくても当たり前だったorz

この記事を参考に別スクリプトでランダム生成してから読み込む形にしていたので、

from django.core.management.utils import get_random_secret_key

secret_key = get_random_secret_key()
text = 'SECRET_KEY = \'{0}\''.format(secret_key)

with open('local_settings.py', 'w') as f:
  print(text, file=f)

に少し変えてPythonAnywhereのブラウザ上から一回Run。

無事SECRET_KEYが生成され、再びBashコンソールから上述の--nuke付コマンドで再構築。
そのまま再度pullして、

$ cd ~/<your-pythonanywhere-domain>.pythonanywhere.com
$ git pull

無事反映。
サイトが表示された。

思ったこと

Django-girlsのチュートリアル、SECRET_KEYを分離させないのはなんでなんだろう。。
でもまあ、躓いたおかげででGitHuへコミットする流れやらバージョン管理の仕組みやら体感出来て理解ふかマンハッタン島。

---

(Reference&&Thanks)

• Djangoの使い方～デプロイ編②～
• DjangoのSECRET_KEYをバージョン管理対象外にする
• KeyError: 'collectstatic' When deploying the Django application to pythonanywhere
  
• gitでリモートのブランチにローカルを強制一致させたい時
• 本番環境でpullしたらコンフリクト？解決法３パターン！

はじめまして、Yuiです。

私は現在Vue.jsを使って受託開発を行っているのですが、そこで詰まったことを紹介します。

何が起こったか

Vueで書いたコードをBitbucketにpushした際、node_modulesが.gitignoreに書かれてあるにも関わらず、まとめてpushされていた。

.gitignoreを見直してもきちんとnode_modulesの記載があり、しばらく原因がわからなかった。

原因

どうやらキャッシュが原因だった。

7/22追記　kmdkukさんよりコメントを頂き、原因がキャッシュではないことがわかりました。すでにgitの追跡対象になっているファイルはどんだけignoreしようとしても追跡対象から外さないとコミット履歴が残ってしまうようです。私はその部分をまとめてキャッシュと呼んでいました・・・・。すみません！

試したこと

とりあえず、いかなる条件でもignoreするように .gitignoreに

*node_modules/

と記載した。

そしてその後

$ git add .gitignore
$ git commit -m "comment"
$ git push origin hoge_branch

これで解決！
と思いきやまだ残ったままだった・・・。

解決法

*node_modules/

こう書いても消えないということは、キャッシュの可能性が高いと思い、キャッシュを全削除してみた。

7/22追記　kmdkukさんのコメントより引用

すでにgitの追跡対象になっているファイルはどんだけignoreしようとしても追跡対象から外さないと変更履歴を永遠と追跡してコミット履歴に残ってしまいます．
その追跡対象から外すコマンドがgit rmコマンドです．
これにrオプションを付けることで再帰的にフォルダ以下のファイルを対象から外してくれます．
cachedオプションは，追跡対象から外したときに，ファイルをそのまま残してくれるようにしてくれるオプションです．

つまり、下記のように消すと今まで追跡するべくして追跡してたファイル郡までaddし直す羽目になるそうなので、きちんとファイル名を明示する必要があるらしいです。
（この辺もざっくりとは認識していたのですが、もう一回addすればよいかと思い、あまり重要視していませんでした。）

ですので、

$ git rm -r --cached .

ではなく、

$ git rm -r --node_modules

とファイル名を明示的に指定する方が良いです。

感想

なにか挙動がおかしいときはキャッシュをチェックするということを忘れないようにしたい。
kmdkukさん、本当にありがとうございました。

概要

最近Gitの勉強をしています．過去のコミットした状態に戻したいときの選択肢として，git reset --hard <commit_id>とgit checkout <commit_id>があります．これらの違いがいまいちよく分からなかったので調査中です．

git reset --hard <commit_id>

これは基本通りの型です．

git checkout <commit_id>

これは少し特殊な方法だと思います．そもそもcheckoutというのはブランチを切り替えるためのコマンドです．参考(1)でもcheckoutの応用編としてこちらの使い方を紹介しています．

参考

(1) 【 git checkout 】コマンド（応用編）――ワークツリーを特定のブランチやコミットに切り替える
この記事自体は無料会員にならないとみれないかもです．
(2)Git の 'detached HEAD' 状態とその注意点
(3)git reset & git checkout 使い分けまとめ
(4)「git checkout 」はブランチを「ブランチなし」に変更しています
(5)7.7 Git のさまざまなツール - リセットコマンド詳説
(6)[git] 戻したい時よく使っているコマンドまとめ

はじめに

Netlifyでホスティングしているリポジトリにsubmoduleで他のプライベートリポジトリを使おうと思ったら一手間必要だったので、その時のメモ

問題発生

Netlifyでホスティングしているリポジトリにsubmoduleで他のプライベートリポジトリを使おうと思い、ふつうにpush & buildしようとしたらbuildでこけた

Deploy logでは下記のようなError messageが

Preparing Git Reference refs/heads/master
Error fetching branch: https://github.com/owner/project refs/heads/master
Failing build: Failed to prepare repo
Failed during stage 'preparing repo': exit status 1
Finished processing build request in 6.873688521s

念のため、Clear cache and deploy siteを試みたが、

Preparing Git Reference refs/heads/master
Error checking out submodules: Submodule 'path/to/submodule' (https://github.com/owner/project) registered for path 'path/to/submodule'

などと言われて、通らず

どうして？

冷静に考えたら、自分以外の人（今回はNetlify）が特に認証なども行わずにプライベートリポジトリをクローンできたら問題だなぁと思った

対処法

Netilfy公式のdocsにあるRepository permissions and linkingをみるとしっかりと対処法が明記されていました。

If a submodule repository is public, you can use https format (for example, https://github.com/owner/project) to link it in your submodule configuration. If the repository is private, or if you prefer to use ssh format (for example, git@github.com:owner/project.git), you will need to follow the instructions below to generate a deploy key in Netlify and add it to the submodule repository settings.

ざっくり翻訳すると、
「submoduleがpublicであれば、submoduleのconfigにhttpsのurlを書けばOK
submoduleがprivate（またはsshを使いたい）であれば、Netlify内でdeploy keyを生成してsubmodule repositoryに設定しましょう」
ってな感じなので

つまり、deploy keyで設定してsshでアクセスを試みればよさそう

Deploy Keyの生成とGitHubへの追加

これも上記の公式のdocsをみれば書いてあるが、
Netlifyのサイト内でSettings -> Build & deploy -> Continuous deployment -> Deploy keyまでいきGenerate public keyを押す
すると

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDOG2pzIItUQ1IWKqQSN8pAB4VeHwHDFSw0M3ASVMj6sv+09zpBgA+bM0yf6x733q0hOPZASWf8IhmB8NINxz8d+DPndY6ORipQr3ROEhFS5gOfQZEEF6W9VO2ics3XwPczNT9E........

ってな感じの公開鍵が生成されるので、これをGitHubのsubmoduleリポジトリのSettings -> Deploy keysまでいき、Add depoloy keyを押して、適当な名前を入力し、その下に生成された公開鍵をコピペし、Add keyを押します

.gutmodulesの修正

ホスティングしてるリポジトリの.gitmodulesをエディタでひらき、submoduleで使おうとしてるprivateリポジトリのurlを

https://github.com/owner/project

というhttps形式のものから

git@github.com:owner/project.git

というsshの形式のものに修正し、保存

submoduleをsyncして再push

その後、

$ git submodule sync

を実行し、.git/configのsubmoduleセクションを更新

最後に、.gitmodulesの差分をpushしたらbuildが通るようになった

参考

• Repository permissions and linking
• サブモジュールを自分のフォークしたリポジトリで置き換える方法