GitLabとSourceTreeを連携させるのに苦労した

　会社でGitLabとSourceTree(GitGUI操作ツール)を用いて開発を行っている。趣味でコーディングするにあたり、自宅にもその環境を構築しようとしたが、必要手順が分からず結構手間取った。そのため、GitLabからSoureTreeを連携させるまでに必要な手順を解説する。趣味でもGitとSourceTreeで快適な開発ライフを！

GitLabとSourceTreeを連携させるまでの手順と参考リンク

　手順とその参考になるリンクをまとめていく。

1. GitLabアカウント作成

　当然、GitLabのアカウントが無ければならない。特に詰まることはないので解説は省略。

2. クライアントPCでSSHキーを生成。GitLabにSSHキーを登録

　次に、GitLabからソースをクローンするためのSSHキーを登録する。SSHとは、クライアントPCとWebサーバー側でセキュアに通信を行うための仕組み。Webサーバー上にあるレポジトリとクライアントPCのデータを安全にやり取りするには欠かせない。

参考にさせていただいた記事

• Windows ：GitLabにSSHで接続するまでの手順
• Mac：SSH認証キーをGitLabに登録・設定手順 覚書

SSHKEYの発行後、configファイルの作成も忘れずに。

3. SoureTreeをインストール

　SoureTreeをインストールする。ここでは、特段詰まることは無いかと。インストール時に、製作元のアトラシアンのGit WebサービスであるBitBuketのアカウントを作らされる。デフォルトの連携アカウントがBit Buketとなるので、後でGitLabに変える。

参考にさせていただいた記事

SourceTree(3.0.15)をインストールしてみた
　

4. SourceTreeにSSHKEYを登録する

　先ほど、GitLabに登録するために作成したSSHを、SourceTree側にも設定する。手順は参考リンクに。SSHキーをすでに作成している場合は、Generateの必要は無く、既に作成したものをLoadする。

参考にさせていただいた記事

SourceTreeでGithubの認証に秘密鍵を使う (Windows)
記事題目に「GitHub」とあるが、GitLabも同一手順で可能。

5. SourceTreeがGitLabにアクセスするためのトークンを発行

　次に、SourceTreeがGitLabにアクセスするためのトークンを発行する。これをしないと、GitLabのアカウントをSourceTree上で連携させることができない。手順は参考リンクに。ここで発行したパスワードをSoureTree側に入力する。

参考にさせていただいた記事

GitLabアカウントをSourceTreeに登録する方法

6.SoureTree上でトークンを用いてGitLabアカウントを登録

　上記リンクにも参考がある。
SoureTree上で、GitLabアカウントを登録する。アカウント設定のパスワード入力欄には、4. で発行したGitLabのPersonal Access Tokensを入力する。発行画面を開いたまま行う。ログインに成功すれば、自分のGitLabのプロジェクト、ソースが即座に連携される。

---

以上、GitLabとSource Tree連携させる手順を紹介した。各手順の詳細は優秀なリンク先を参考されたい。

GitLabとSourceTreeを連携させるのに苦労した

　会社でGitLabとSourceTree(GitGUI操作ツール)を用いて開発を行っている。趣味でコーディングするにあたり、自宅にもその環境を構築しようとしたが、必要手順が分からず結構手間取った。そのため、GitLabからSoureTreeを連携させるまでに必要な手順を解説する。趣味でもGitとSourceTreeで快適な開発ライフを！
※ここでは、SSH認証で連携する手法を記述する。HTTP認証については触れない

GitLabとSourceTreeを連携させるまでの手順と参考リンク

　手順とその参考になるリンクをまとめていく。

1. GitLabアカウント作成

　当然、GitLabのアカウントが無ければならない。特に詰まることはないので解説は省略。

2. クライアントPCでSSHキーを生成。GitLabにSSHキーを登録

　次に、GitLabからソースをクローンするためのSSHキーを登録する。SSHとは、クライアントPCとWebサーバー側でセキュアに通信を行うための仕組み。Webサーバー上にあるレポジトリとクライアントPCのデータを安全にやり取りするには欠かせない。

参考にさせていただいた記事

• Windows ：GitLabにSSHで接続するまでの手順
• Mac：SSH認証キーをGitLabに登録・設定手順 覚書

SSHKEYの発行後、configファイルの作成も忘れずに。

3. SoureTreeをインストール

　SoureTreeをインストールする。ここでは、特段詰まることは無いかと。インストール時に、製作元のアトラシアンのGit WebサービスであるBitBuketのアカウントを作らされる。デフォルトの連携アカウントがBit Buketとなるので、後でGitLabに変える。

参考にさせていただいた記事

SourceTree(3.0.15)をインストールしてみた
　

4. SourceTreeにSSHKEYを登録する

　先ほど、GitLabに登録するために作成したSSHを、SourceTree側にも設定する。手順は参考リンクに。SSHキーをすでに作成している場合は、Generateの必要は無く、既に作成したものをLoadする。

参考にさせていただいた記事

SourceTreeでGithubの認証に秘密鍵を使う (Windows)
記事題目に「GitHub」とあるが、GitLabも同一手順で可能。

5. SourceTreeがGitLabにアクセスするためのトークンを発行

　次に、SourceTreeがGitLabにアクセスするためのトークンを発行する。これをしないと、GitLabのアカウントをSourceTree上で連携させることができない。手順は参考リンクに。ここで発行したパスワードをSoureTree側に入力する。

参考にさせていただいた記事

GitLabアカウントをSourceTreeに登録する方法

6.SoureTree上でトークンを用いてGitLabアカウントを登録

　上記リンクにも参考がある。
SoureTree上で、GitLabアカウントを登録する。アカウント設定のパスワード入力欄には、4. で発行したGitLabのPersonal Access Tokensを入力する。発行画面を開いたまま行う。ログインに成功すれば、自分のGitLabのプロジェクト、ソースが即座に連携される。

---

以上、GitLabとSource Tree連携させる手順を紹介した。各手順の詳細は優秀なリンク先を参考されたい。

はじめに

この記事では，PX4公式でも推奨されているUbuntu環境でのbuildを実現するためにWSLを用いたWindows 10での環境構築環境構築までの流れを書いていきます．基本的にはwsl環境の構築に加えて，公式の内容をまとめただけになります．
少しでもプログラミング関係のことをかじったことがある人からすれば当たり前のことしか書いてません．備忘録です．
正直まだまだよくわかっていないことだらけなので，詳しい人いたらいろいろ教えてください．
特にGit周りは間違った理解が大いにあり得るので，ぜひ指摘して教えてください．

WSLおよびvscodeの導入

こちらの記事通りに進めていけばできます．
以前まではVMwareにUbuntuを載せたり，GitBashを使ったりしてました．
先の話ですが，PX4でSITLをする場合，この方法ではできませんGUIのUbuntuを用意する必要があります．（GazeboがWindowsに対応していないので）
参考：Visual Studio Codeで競プロ環境構築(導入編) - Qiita

Firmwareを自分のPCに入れる

PX4のFirmwarはGithubで開発されている．とりあえずコードが見てみたい，というだけならまずこれを自分のPCにcloneします．

本家のサイトの右の緑のClone or Downloadからhttpsのアドレスを取得して，git clone <取得したもの>とします．

git clone https://github.com/PX4/Firmware.git

folk+branchでしっかり環境を整える

この参考先通りにやればできます．
参考：GIT Examples · PX4 Developer Guide

アカウントを作りfolkする

まずGitHubの自分のアカウントを作ります．その後本家に行き，右上のfolkを押します．
これは，既存のリポジトリ（今回でいうところのPX4/Firmware）の複製を作る行為です．これがされてない他人様のリポジトリには書き込むことができませんが，folkしたものは自分の所有物なので自由に更新ができます．pullリクエストなどは今は置いておきます．とりあえずコピーをもらってきたという感じです．

folkしたリポジトリをローカルにcloneする

先程と違い，folkしたリポジトリをcloneします．これによって，リモートでもローカルでも自分の好きなように開発ができます．（さっきのだとローカルのみ）

cd ~/wherever/
git clone https://github.com/<your git name>/Firmware.git

cloneしたらcdでFirmwareのdirectoryに移動して，submoduleを更新します．このサブモジュールは（自分の理解があっているかわかりませんが），とあるリポジトリ（今回でいうFirmware）を動かしている一部moduleが，独立してリポジトリとして開発されているという状態．つまり元のリポジトリでは，Winでいうところのショートカットのようなものが設定されている状態．このアップデートは，その参照先のアップデートをFirmwareにも適用させるよーという感じでしょうか…たぶん…ざっくりと…
産業目もあんまりちゃんと理解してないですが，本家の進行状況も見れるように追跡できるようにしておいて，本家がなんか変更されたら自分のリポジトリに本家の変更を反映させる，適菜やつだと思います，ざっくり．

cd Firmware
git submodule update --init --recursive
git remote add upstream https://github.com/PX4/Firmware.git

git remote -v

二個のリポジトリが出ると思います．一つはupstreamでPX4のFirmwareを指しています．もう一つはさっき自分がfolkしたリポジトリを指しています．

branchを作る

基本的プロジェクトの本筋の最新版はmasterというbranchです．ここから枝を伸ばして自分のbranchを作ります．
そしてそのbranchに移動します．

git checkout -b <your feature branch name>

git statusで自分の今いるbranchが確認できます．自分が作ったbranchになっているはずです．

さて，このbranchの名前ですが，基本的には自分が変更したものがわかるものにするのが一般的です．例えば新しいセンサのドライバを新しく追加したなら，add_xxxsensor_ドライバーみたいな感じですかね．まあでも本家に貢献せず（本来は貢献が前提ですが），自分でいろいろ開発するだけなら好きな名前でいいと思います．

commit＆pushする

まず用語から．
- add
- ローカルで変更して，これは確定やな変更したろ，と思う項目をcommitするためのリスト？に追加する
- commit
- 自分のローカル環境の変更（addで指定されたもの）をローカルのリポジトリに書き込む
- ここ変ったよーっていう内容を手元にメモする感じ
- push
- ローカルのリポジトリにcommitされたものを，リモートに反映させる
- そするとGithubに反映される

という流れです．それでは．．．

git add <file name>

これで変更を反映したいファイルなどを指定します．

git commit -m "<your commit message>"

-mはメッセージをつけるというオプションです．これを書くと，リモートのそのファイルの横にメッセージが載ります．（これが新しいドライバでっせーみたいな）

これでひとまず完了．chrome等で自分のGitHubのfolkしたリポジトリを見ると，ちゃんとbranchが追加され，変更が反映されているはずです．

本家の変更をfolkしたリポジトリにも反映させたい

PX4はかなり活発に開発が進められているOSSですから，知らぬ間に新しい機能やらバグ修正やらいろんなアップデートがされています．しかし（僕の理解だと）folkリポジトリは，ほっといてもそれを参照してくれないので，それを更新する作業が必要です．（たとえば3年前にfolkしたら，今見ても三年前の状態で変わっていないはず）

これをrebaseというコマンドを使ってやります．
まずは一旦masterブランチに移動します．

git checkout master

ここで，先程追っかけ用と言っていたupstreamに最新版の変更を反映させます．pullというコマンドを使います．

git pull upstream master

これで，ローカルのmasterが更新されました．自分のブランチに戻ります．

git checkout <your feature branch name>

ここで，rebaseです．rebaseってなんぞや？てかたはこちらがわかりやすかったのでぜひ参照してみてください．

参照：3.6 Git のブランチ機能 - リベース

git rebase master

これで無事自分のブランチのローカルが更新されました．
これをリモートにも反映させます．

git push origin <your feature branch name>

おわりに

やっと最近ちょこちょこ理解できるようになってきましたがまだまだ…gitの慣れが微妙ですね．
中のソースはpublish/subscribeシステムやCMakeによる自動化等，まだまだ理解しなくてはならないことが山のように…

はじめに

この記事では，PX4公式でも推奨されているUbuntu環境でのbuildを実現するためにWSLを用いたWindows 10での環境構築環境構築までの流れを書いていきます．基本的にはwsl環境の構築に加えて，公式の内容をまとめただけになります．
wsl＋githubといった感じです．

少しでもプログラミング関係のことをかじったことがある人からすれば当たり前のことしか書いてません．備忘録です．
正直まだまだよくわかっていないことだらけなので，詳しい人いたらいろいろ教えてください．
特にGit周りは間違った理解が大いにあり得るので，ぜひ指摘して教えてください．

WSLおよびvscodeの導入

こちらの記事通りに進めていけばできます．
以前まではVMwareにUbuntuを載せたり，GitBashを使ったりしてました．
先の話ですが，PX4でSITLをする場合，この方法ではできませんGUIのUbuntuを用意する必要があります．（GazeboがWindowsに対応していないので）
参考：Visual Studio Codeで競プロ環境構築(導入編) - Qiita

Firmwareを自分のPCに入れる

PX4のFirmwarはGithubで開発されている．とりあえずコードが見てみたい，というだけならまずこれを自分のPCにcloneします．

本家のサイトの右の緑のClone or Downloadからhttpsのアドレスを取得して，git clone <取得したもの>とします．

git clone https://github.com/PX4/Firmware.git

folk+branchでしっかり環境を整える

この参考先通りにやればできます．
参考：GIT Examples · PX4 Developer Guide

アカウントを作りfolkする

まずGitHubの自分のアカウントを作ります．その後本家に行き，右上のfolkを押します．
これは，既存のリポジトリ（今回でいうところのPX4/Firmware）の複製を作る行為です．これがされてない他人様のリポジトリには書き込むことができませんが，folkしたものは自分の所有物なので自由に更新ができます．pullリクエストなどは今は置いておきます．とりあえずコピーをもらってきたという感じです．

folkしたリポジトリをローカルにcloneする

先程と違い，folkしたリポジトリをcloneします．これによって，リモートでもローカルでも自分の好きなように開発ができます．（さっきのだとローカルのみ）

cd ~/wherever/
git clone https://github.com/<your git name>/Firmware.git

cloneしたらcdでFirmwareのdirectoryに移動して，submoduleを更新します．
このサブモジュールは（自分の理解があっているかわかりませんが），とあるリポジトリ（今回でいうFirmware）を動かしている一部moduleが，独立してリポジトリとして開発されているという状態．つまり元のリポジトリでは，Winでいうところのショートカットのようなものが設定されている状態．
このアップデートは，その参照先のアップデートをFirmwareにも適用させるよーという感じでしょうか…たぶん…ざっくりと…

三行目もあんまりちゃんと理解してないですが，本家の進行状況も見れるように追跡できるようにしておいて，本家がなんか変更されたら自分のリポジトリに本家の変更を反映させる，的なやつだと思います，ざっくり．

cd Firmware
git submodule update --init --recursive
git remote add upstream https://github.com/PX4/Firmware.git

git remote -v

二個のリポジトリが出ると思います．一つはupstreamでPX4のFirmwareを指しています．もう一つはさっき自分がfolkしたリポジトリを指しています．

branchを作る

基本的プロジェクトの本筋の最新版はmasterというbranchです．ここから枝を伸ばして自分のbranchを作ります．
そしてそのbranchに移動します．

git checkout -b <your feature branch name>

git statusで自分の今いるbranchが確認できます．自分が作ったbranchになっているはずです．

さて，このbranchの名前ですが，基本的には自分が変更したものがわかるものにするのが一般的です．例えば新しいセンサのドライバを新しく追加したなら，add_xxxsensor_driverみたいな感じですかね．まあでも本家に貢献せず（本来は貢献が前提ですが），自分でいろいろ開発するだけなら好きな名前でいいと思います．

commit＆pushする

まず用語から．
- add
- ローカルで変更して，これは確定やな変更したろ，と思う項目をcommitするためのリスト？に追加する
- commit
- 自分のローカル環境の変更（addで指定されたもの）をローカルのリポジトリに書き込む
- ここ変ったよーっていう内容を手元にメモする感じ
- push
- ローカルのリポジトリにcommitされたものを，リモートに反映させる
- そするとGithubに反映される

という流れです．それでは．．．

git add <file name>

これで変更を反映したいファイルなどを指定します．

git commit -m "<your commit message>"

-mはメッセージをつけるというオプションです．これを書くと，リモートのそのファイルの横にメッセージが載ります．（これが新しいドライバでっせーみたいな）

これでひとまず完了．chrome等で自分のGitHubのfolkしたリポジトリを見ると，ちゃんとbranchが追加され，変更が反映されているはずです．

本家の変更をfolkしたリポジトリにも反映させたい

PX4はかなり活発に開発が進められているOSSですから，知らぬ間に新しい機能やらバグ修正やらいろんなアップデートがされています．しかし（僕の理解だと）folkリポジトリは，ほっといてもそれを参照してくれないので，それを更新する作業が必要です．（たとえば3年前にfolkしたら，今見ても三年前の状態で変わっていないはず）

これをrebaseというコマンドを使ってやります．
まずは一旦masterブランチに移動します．

git checkout master

ここで，先程追っかけ用と言っていたupstreamに最新版の変更を反映させます．pullというコマンドを使います．

git pull upstream master

これで，ローカルのmasterが更新されました．自分のブランチに戻ります．

git checkout <your feature branch name>

ここで，rebaseです．rebaseってなんぞや？てかたはこちらがわかりやすかったのでぜひ参照してみてください．

参照：3.6 Git のブランチ機能 - リベース

git rebase master

これで無事自分のブランチのローカルが更新されました．
これをリモートにも反映させます．

git push origin <your feature branch name>

おわりに

やっと最近ちょこちょこ理解できるようになってきましたがまだまだ…gitの慣れが微妙ですね．
中のソースはpublish/subscribeシステムやCMakeによる自動化等，まだまだ理解しなくてはならないことが山のように…

結論

force push 禁止しよう。
一人でもプルリク運用した方が安全。

前提

• 中央リポジトリは github
• master へのコミットは原則禁止し、PullRequest で運用
• 個人無料アカウント
• 一人プロジェクトなので、他のマシンなどに master 最新のコミットが残っていたりはしない

サマリ

1. github のサイト上で、master にマージされた最新のPRを探す
2. 上記 PR のマージコミットの番号を調べる
3. 該当のコミットをローカルに fetch する
4. そのコミットにチェックアウトしてブランチを切る
5. そのブランチを master として force push する

状況

• master 最新になっていないローカル master を git push -f origin master した
• 結果、 github 上のコミット履歴が1ヶ月くらい前にタイムスリップ
• github のサイトではプルリクやマージの状況は残っている
• ローカルにも他のマシンにも最新のコミットがない
• 目の前が真っ暗になった

対応

1. github のサイト上で、master にマージされた最新のPRを探す

2. 上記 PR のマージコミットの番号を調べる

PRのページの下の方にスクロールするとマージされたコミット番号が表示されているはず。
それをクリックするとマージコミットのページに移動する。

URLないし画面内のコミット番号をコピーする。

3. 該当のコミットをローカルに fetch する

ローカルで fetch する

git fetch origin コミット番号

fetch したコミットは FETCH_HEAD にある。

4. そのコミットにチェックアウトしてブランチを切る

git checkout FETCH_HEAD
git checkout -b 任意のブランチ名

そのブランチを master として force push する

git push -f origin 任意のブランチ名:master

はぁ、また force push するの。

git-credential-osxkeychainを使います。
キーチェインにパスワードを保存するので安全です。

git config --global credential.helper osxkeychain

pullやpushの初回だけユーザー名とパスワードを入力すれば、以降はパスワード入力を省略できます

GitHubでよくやるリポジトリ作成から開発までのフロー

1. GitHubでリポジトリを新規作成する
2. cloneする
3. cloneしたディレクトリ内にXcodeのプロジェクトを作成
4. git push
5. 実装を進めていく

Xcodeでよくファイル名の隣にでる差分のアイコンがでない

最初に上記のフローで開発を始めたら、よく見るファイル名の隣の差分アイコンが表示されませんでした。

ローカルブランチとの差分をみようとしても見れない。

解決策

メニュー>Source Control>Create Git Repositories...を選択してcreateすればOK!

Rails で個人でアプリケーションを開発中です。
表題のエラーが出た際に、改めてgitの理解が深まりましたので備忘録として残します。

状況

開発中のタイミングで普段通り、「git pusu origin　ブランチ名」で、
ローカルの変更をリモートにpushしようとすると。。。

terminal

git push origin develop
To https:///githubのURL !
[rejected]develop -> develop (non-fast-forward)error: failed to push some refs to 'https://githubのURL'

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.

上記のエラーが出ました。

原因

このcommitを行う前に、私がリモートでgithubのREADMEの変更を行っていたことが
今回のエラーの原因でした。

「リモートのファイルがローカルのファイルも最新版だから、そのファイルにpushできないですよ」ということみたいです。

対処法

いくつか対処法があるみたいです。

①git pull origin develop

git pull origin developでリモートの環境をローカルファイルにpullした後、
再度pushを行う。

②git fetchした後、git mergeする

①とやっていることはほとんど変わらず、pull＝fetch + mergeという意味合いなのかと思います。

③git push ––forceで矯正的にpushする

こちらは、個人開発なら自分一人しかリポジトリを操作しないので大きな影響はなさそうですが、
チーム開発の場合だと自分以外にcommitやpushする人がいる無闇に使用すべきでは無い、という記事をいくつか確認しました。

①か②で対処するのが無難かもしれません・・・（私は①で対処しました）

備考

「origin」や「master」の理解については、こちらの記事が大変参考になりました！

Git - originとmasterとは何か(初心者向け)

背景

WSL2を利用することでWindwosでもLinux環境での開発を実現することができるようになった。しかし、WSL2でHTTPSプロトコルを使用してgitのリポジトリにプッシュしようとすると毎回、ユーザー名とパスワードの入力を求められる。この問題を回避するためにWSL2とGit for Windowsに付属しているgit-credential-managerを連携させる。WSL2とgit-credential-managerを連携することでgitリポジトリにpushをしても毎回ユーザー名とパスワードの入力を求められなくなる。

Git for Windowsのインストール

もし、まだGit for Windowsをインストールしていなければ以下のサイトからダウンロードしてインストールを行う
https://git-scm.com/download/win

WSL2上のgit-credientialとGit for Windowsのgit-credential-managerを連携

エディタでgit-credential-managerを開く

sudo vi /usr/bin/git-credential-manager

git-credential-managerに以下に内容を追記して保存する

#!/bin/sh
exec /mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe $@

git-credential-managerの実行権限を付与する

sudo chmod +x /usr/bin/git-credential-manager

~/.gitconfigを開き、認証に関する設定（認証時に利用する認証マネージャーの設定）を追記する

[credential]
helper = manager

以上の設定で連携が完了する。これで初回のプッシュ時に認証情報を入力すると、以降同じリポジトリにプッシュしても認証情報は求められない。

参考ページ

https://blog.anaisbetts.org/using-github-credentials-in-wsl2/

背景

WSL2を利用することでWindwosでもLinux環境での開発を実現することができるようになった。しかし、WSL2でHTTPSプロトコルを使用してgitのリポジトリにプッシュしようとすると毎回、ユーザー名とパスワードの入力を求められる。この問題を回避するためにWSL2とGit for Windowsに付属しているgit-credential-managerを連携させる。WSL2とgit-credential-managerを連携することでgitリポジトリにpushをしても毎回ユーザー名とパスワードの入力を求められなくなる。

Git for Windowsのインストール

もし、まだGit for Windowsをインストールしていなければ以下のサイトからダウンロードしてインストールを行う
https://git-scm.com/download/win

WSL2上のgit-credientialとGit for Windowsのgit-credential-managerを連携

エディタでgit-credential-managerを開く

sudo vi /usr/bin/git-credential-manager

git-credential-managerに以下に内容を追記して保存する

#!/bin/sh
exec /mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe $@

git-credential-managerの実行権限を付与する

sudo chmod +x /usr/bin/git-credential-manager

~/.gitconfigにどのcredentialを利用するのかを追記する

[credential]
helper = manager

以上の設定で連携が完了する。これで初回のプッシュ時に認証情報を入力すると、以降同じリポジトリにプッシュしても認証情報は求められない。

参考ページ

https://blog.anaisbetts.org/using-github-credentials-in-wsl2/

本記事について

railsアプリをherokuでデプロイする方法を調べていたのですが、開発環境(developmentやtest環境)でRailsアプリに最初からついているDB(SQLite3)を使用している事を前提に書かれた記事が多く、混乱してしまったので、DBにMysqlを採用している方に向けて記事を書いていこうと思います。

※変更内容の意味を理解していればどのDBを使っていようが同じ手順だと気づくのですが、初心者の僕は混乱して躓いてしまったので、同じ様な方が少しでも楽に理解できる様に執筆しています。

環境

• Ruby 2.5.1
• Rails 5.0.7.2
• git 2.25.2
• heroku/7.41.1 darwin-x64 node-v12.16.2

事前に準備して欲しいもの

• Railsで作成したアプリ(下記二つの条件を満たしているもの)
  • Gitで管理している
  • ローカル環境でエラーが出ていない(デプロイ中にエラーが出た場合、デプロイ時に起こったエラーかローカル環境でのエラーが関係しているのか分からなくなってしまうので、それを防ぐ為)
• herokuのユーザー登録
  • https://signup.heroku.com/login
• heroku-cil(herokuの機能を自分のPCに紐付けるもの→herokuのコマンドをPCで使える様にする)のインストール
  • https://devcenter.heroku.com/articles/heroku-cli

今回はherokuについての記事なので、Gitについての説明は割愛させて頂きます。

デプロイ作業を始める前に

デプロイ作業を始める前に、デプロイしたいRailsアプリのコードを一部編集する必要があります。
編集するのは以下の三箇所です。

• Gemfile(各環境で使うDBの設定を変更する)
• config/datebase.yml(実際に本番環境で使うDBを接続する記述を追加する)
• config/environments/production.rb(本番環境でのプリコンパイルをオンにする)

編集する内容について一つずつ理由とともに解説していきますので、変更する場所だけ確認できたら読み進めて貰って大丈夫です。

Gemfileの設定

削除するコードが一箇所、追記するコードが二つあります。

• 削除する箇所

Gemfile

gem 'mysql2'

• 追記する箇所

Gemfile

group :development, :test do
  gem 'mysql2'
end

※group :development, :test do ~ end内に他にもgemが書いてあったと思いますが、消さないでください。

Gemfile

group :production do
  gem 'pg'
end

　何をしてんだ?

herokuではPostgreSQL(pg)というDBをデフォルトで使う様に設定されています。
普通に作っている方は、全ての環境下でmysqlを使う様に表記していると思うので、その表記を削除し、開発環境、テスト環境下のみでmysqlを使える様にgroup :development, :test do ~ end内にgem 'mysql2'の表記を追加しています。
また、本番環境でPostgreSQL(pg)が使える様にgroup :production do ~ end内にgem 'pg'を表記しています。

config/datebase.ymlの設定

追記するコードが一つあります。

config/datebase.yml

production:
  <<: *default
  adapter: postgresql
  encoding: unicode
  pool: 5 

※production:内にあった元々の記述は全て削除して、上記の様に書き換えて下さい。

　何をしてんだ?

先ほどgemを追加し、機能をインストールするための準備は整えたのですが、実際にDBと接続する記述はまだ完了していません。どのDBに接続するのか？という設定をする箇所がconfig/database.ymlです。
※開発環境、テスト環境で使用するDBの設定もここに書かれています。

追加したコードの意味は以下の様になります。

adapter: postgresql - postgreSQLのデータベースに接続。
encoding: unicode - unicodeという文字コードを使用。
pool: 5 - DBに接続できる上限の数を指定。

DBに接続する為の設定をしたんだ！ってことが分かればOKです。

config/environments/production.rbの設定

追記するコードが一つあります。

config/environments/production.rb

#デフォルトでfalseとなっている以下の箇所をtrueに変更
  config.assets.compile = true

　何をしてんだ?

Railsは本番環境でのプリコンパイルがデフォルトでオフになっています。
assetsを圧縮して少しでも軽くする為だそうです。
assets以下のフォルダから動的にコンパイルしながらページを読み込む為にtrueに変更しています。
難しく書きましたが、本番環境でも画像を読み込んでくれよ~って表記にしただけです。

いよいよデプロイ作業開始

これでデプロイをする前の事前準備が終わったので、いよいよデプロイ作業に移ります。
デプロイまでの流れは以下の通りです。

1. herokuにログイン
2. 公開されるRailsアプリのurlを決める
3. pushしてデプロイ
4. 本番環境でマイグレーションをする

AWSとかと比べて超絶簡単なので気負いせずにさくっと終わらせましょう！

１.herokuにログイン

ターミナル

$heroku login

上記コマンドでherokuにログインします。
コマンド入力に成功すると(なんか格ゲーみたい)herokuに登録したEmailとpasswordの入力を求められるので、ゆっくり正確に入力しましょう。
入力に成功すると下記の様にターミナルに表示されます。
(as ~ は自分のメールアドレスです。)

ターミナル

Logged in as ~~~~~@icloud.com

公開されるRailsアプリのurlを決める

https://nameless-atoll-34353.herokuapp.com/

上記のURLは僕が初めて作った個人アプリなんですが、これでいうところのnameless-atoll-34353の部分を自身で決めることができます。
heroku createだけでも問題はないのですが、僕みたいになんのアプリか分からない変なURLになるのでしっかり設定しておきましょう！

ターミナル

$heroku create 好きな文字列

pushしてデプロイ

以下のコマンドを打つだけです。楽勝です。
この時、gitのmasterで管理されているコードがpushされるので、brunch生やして作業している方は一旦masterにpushしましょう。

ターミナル

$git push heroku master

こんな感じで進んでいたら順調です。

ターミナル

Enumerating objects: 148, done.
Counting objects: 100% (148/148), done.
Delta compression using up to 4 threads
Compressing objects: 100% (125/125), done.
Writing objects: 100% (148/148), 39.65 KiB | 2.09 MiB/s, done.
Total 148 (delta 24), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote: 
remote: -----> Ruby app detected
remote: -----> Installing bundler 2.0.2
remote: -----> Removing BUNDLED WITH version in the Gemfile.lock
remote: -----> Compiling Ruby/Rails
remote: -----> Using Ruby version: ruby-2.6.6
remote: -----> Installing dependencies using bundler 2.0.2
remote:        Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
remote:        The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
remote:        Fetching gem metadata from https://rubygems.org/............

下記のコードの5行目に書かれているのが、今回デプロイしたアプリのURLです。
8行目のは全然関係ないです。僕はそれで悩んでました。

ターミナル

remote: -----> Compressing...
remote:        Done: 58.8M
remote: -----> Launching...
remote:        Released v4
remote:        https://nameless-atoll-34353.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.
To https://git.heroku.com/nameless-atoll-34353.git
 * [new branch]      master -> master

これで終わりと思いきや、、まだ本番環境にDBが作成されてないので、マイグレーションをしなきゃいけません。

それで終わりだよん。

4. 本番環境でマイグレーションをする

以下のコマンドでマイグレーションしてください。

ターミナル

$heroku run rails db:migrate

heroku runをつけるとrailsのコマンドをherokuを動かしているときにも使える様になります。

はい。終わりです。先ほどのURLを貼っつけて、正常に見れるか確認しましょう。

見れた方、お疲れ様でした。

見れてない方、調べても分からない方は僕のTwitterにでも相談しにきて下さい。
いつでも答えますよ?(@rurukasan0212 )

はじめに

初Qiita記事投稿です！
boost noteに書き殴っていた内容をまとめていきたいと思います。
独学歴は４ヶ月ちょっとなので、
初学者がgitを操作してgithubにコードを上げて自分の学習時間を記録したい！という方には役立つ記事にしたいと思います(僕もそのためにgitを勉強しました）。ご指摘・ご意見等あればご連絡いただけたら幸いです。
＊lssuesから作成していくのが本来の共同開発の手順みたいなので、あくまで一連の手順を練習したい！という方向けです。流れを理解したら追記しようと思います。

参考文献・参考記事

・【初心者必見】Gitの基本
https://www.youtube.com/watch?v
・Gitを使ったクローン、プルリク、マージの流れについて解説
https://www.youtube.com/watch?v=JispFS6zeDw&t=617s

上記２つともプログラング講師として有名なかみざとさんのyoutube動画です。
こちらの動画両方見ればgitについての一連の流れは理解できるかと思います。
無料でこれが見れるのは神すぎる！

・【Git入門】サルでも分かるGit入門の前に！Git使い方高速入門編【入門は5分で十分だと思います】
https://www.youtube.com/watch?v=i1L3A0SLDyg

gitをある程度扱えるようになってからですが、こちらの動画も大変参考になりました。（git add .でstagingに保存されるという理解はできてなかった）
５分で説明されているので、すぐにでもgitを使いたい！という方にはおすすめです。

・Githubにport:22 で push できなかった場合の対処法
https://qiita.com/SOJO/items/74b16221580a17296226
こちらがおそらくメインといっても過言ではないです笑
このエラーに1日~２日程度悩まされました。。。
手順通りしてるのにpushできない!となったときはこちらの記事を確認してみてください。

開発環境

OS:Macbook Pro(gitとgitHubを導入またはアカウント登録済みであることが前提）

擬似開発するまでの手順

1.githubにてフォルダを作成後ターミナルでdesktopに移動

cd desktop

2.gitを起動してフォルダをコピー

git init
git clone https://github.com/作成したフォルダの名前.git

githubに作成したフォルダのcodeにhttpsのリンクが書いてあります。

3.エディターを使用し、index.htmlをファイルをフォルダ内に作成

ファイルに適当にテキストを書き込んでおく。

4.ターミナルに戻り、フォルダに移動

cd フォルダ名

5.git add .でwork treeからstagingに保存し、git commit -m でローカルリポジトリに保存(自分のパソコンだけにデータを保存する）

git add .
git commit -m "追加した内容"

6.ローカルリポジトリからリモートリポジトリにプッシュ(githubに保存）

git push origin master

これでgithubにデータが保存されているかと思います！次はブランチを作成してプルリクエストするまでの手順を説明します。
7.ブランチを作成し、作成できているか確認

git checkout -b "ブランチ名"
git  branch

ターミナルにmasterとブランチ名が書かれていれば作成完了です。
**8.ファイルに書き込み、5の手順で保存し、プッシュします。

git push origin ブランチ名

この後、githubにpull requestが表示されているはずなのでクリックしcreate　pull requestをクリックします。(このあとがコードレビュー)
そして、コードが問題なければブランチのプルリクエストをリモートリポジトリのマスターにmargeします。(Delete branchでブランチを削除する)

9. masterに移動し、githubの中身をロカールリポジトリのマスターに反映

git checkout master
git pull origin master

これでgithubにあるデータがローカルリポジトリに反映されました！このあとは7〜９までを繰り返していくだけで擬似開発がおこなえると思います。

10. ローカルリポジトリのブランチ削除

git branch -D 削除したいbranch名

使い終わったローカルリポジトリのブランチを削除します。

最後に

ここまで読んでいただきありがとうございます！
書いていて感じたのですがローカルリポジトリやリモートリポジトリの説明が少ないため何をしているのか理解しづらいかもしれません。一度動画を見て仕組みを理解しておいた方がいいかと思います。あとは使っていたらだんだんわかってくるのでまずやってみましょう！

はじめに

初Qiita記事投稿です！
boost noteに書き殴っていた内容をまとめていきたいと思います。
独学歴は４ヶ月ちょっとなので、
初学者がgitを操作してgithubにコードを上げて自分の学習時間を記録したい！という方には役立つ記事にしたいと思います(僕もそのためにgitを勉強しました）。ご指摘・ご意見等あればご連絡いただけたら幸いです。
＊lssuesから作成していくのが本来の共同開発の手順みたいなので、あくまで一連の手順を練習したい！という方向けです。流れを理解したら追記しようと思います。

参考文献・参考記事

・【初心者必見】Gitの基本
https://www.youtube.com/watch?v
・Gitを使ったクローン、プルリク、マージの流れについて解説
https://www.youtube.com/watch?v=JispFS6zeDw&t=617s

上記２つともプログラング講師として有名なかみざとさんのyoutube動画です。
こちらの動画両方見ればgitについての一連の流れは理解できるかと思います。
無料でこれが見れるのは神すぎる！

・【Git入門】サルでも分かるGit入門の前に！Git使い方高速入門編【入門は5分で十分だと思います】
https://www.youtube.com/watch?v=i1L3A0SLDyg

gitをある程度扱えるようになってからですが、こちらの動画も大変参考になりました。（git add .でstagingに保存されるという理解はできてなかった）
５分で説明されているので、すぐにでもgitを使いたい！という方にはおすすめです。

・Githubにport:22 で push できなかった場合の対処法
https://qiita.com/SOJO/items/74b16221580a17296226
こちらがおそらくメインといっても過言ではないです笑
このエラーに1日~２日程度悩まされました。。。
手順通りしてるのにpushできない!となったときはこちらの記事を確認してみてください。

開発環境

OS:Macbook Pro(gitとgitHubを導入またはアカウント登録済みであることが前提）

擬似開発するまでの手順

1.githubにてフォルダを作成後ターミナルでdesktopに移動

cd desktop

2.gitを起動してフォルダをコピー

git init
git clone https://github.com/作成したフォルダの名前.git

githubに作成したフォルダのcodeにhttpsのリンクが書いてあります。

3.エディターを使用し、index.htmlをファイルをフォルダ内に作成

ファイルに適当にテキストを書き込んでおく。

4.ターミナルに戻り、フォルダに移動

cd フォルダ名

5.git add .でwork treeからstagingに保存し、git commit -m でローカルリポジトリに保存(自分のパソコンだけにデータを保存する）

git add .
git commit -m "追加した内容"

6.ローカルリポジトリからリモートリポジトリにプッシュ(githubに保存）

git push origin master

これでgithubにデータが保存されているかと思います！次はブランチを作成してプルリクエストするまでの手順を説明します。
7.ブランチを作成し、作成できているか確認

git checkout -b "ブランチ名"
git  branch

ターミナルにmasterとブランチ名が書かれていれば作成完了です。
**8.ファイルに書き込み、5の手順で保存し、プッシュします。

git push origin ブランチ名

この後、githubにpull requestが表示されているはずなのでクリックしcreate　pull requestをクリックします。(このあとがコードレビュー)
そして、コードが問題なければブランチのプルリクエストをリモートリポジトリのマスターにmargeします。(Delete branchでブランチを削除する)

9. masterに移動し、githubの中身をロカールリポジトリのマスターに反映

git checkout master
git pull origin master

これでgithubにあるデータがローカルリポジトリに反映されました！このあとは7〜９までを繰り返していくだけで擬似開発がおこなえると思います。

10. ローカルリポジトリのブランチ削除

git branch -D 削除したいbranch名

使い終わったローカルリポジトリのブランチを削除します。

最後に

ここまで読んでいただきありがとうございます！
書いていて感じたのですがローカルリポジトリやリモートリポジトリの説明が少ないため何をしているのか理解しづらいかもしれません。一度動画を見て仕組みを理解しておいた方がいいかと思います。あとは使っていたらだんだんわかってくるのでまずやってみましょう！

GitHubのレポジトリーのmasterにpushができないようにする

目的

maseterにpushするとCI/CDが走ってしまい勝手にデプロイされてしまう。気をつけていても間違ってmasterにpushしてしまうので、システム的にmasterにはpushできないようにする。(自分がadministratorでもできないようにする)

調べた結果、以下の方法1だけすれば良い気がします。

方法1；Branch protection rule

GitHubレポのsettings -> Branches で

• Branch name pattern に master を設定して、
• Require pull request reviews before merging にチェックを入れて、
• Include administrators にチェックを入れる。(これにチェックを入れないと個人レポジトリーのオーナーではpushができてしまう。Organizationのレポジトリーでは未調査)

これだけでmasterへのpushはエラーとなります。

方法2：.git/hooks/pre-push

方法1はGitHubサーバー上で行う方法でした。こちらはクライアント側で行う方法です。

.git/hooks/pre-pushにpush前に実行されるスクリプトを置いて、pushしたときにmasterに対してのpushであれば中止する、ということが可能です。

ただGitHub上で実行されるわけではなくクライアントマシン上で実行されるものなので、どうやってスクリプトを配り、実行を強制させるのかは別で考えないといけません。

スクリプト自体は下の参考のリンクを参照ください。(僕は動作未確認です)

参考

Stack Overflowの質問
https://stackoverflow.com/questions/46146491/prevent-pushing-to-master-on-github

pre-pushのスクリプト
https://gist.github.com/vlucas/8009a5edadf8d0ff7430