はじめに
事の発端は、GitUpというツールを使用した際にmasterブランチがいろんなブランチと被っているのと、同じ名前のブランチがいくつかできてしまっていることに気がついたことで、今回の対処をすることになりました。
リモートリポジトリ や コマンドでも確認出来なかったので、GitUp様さまです。
Gitup
ちなみに実際の状況がこんな感じでした。
そこで、一旦、masterブランチを最新にして、他のブランチを削除したディレクトリを新たに作成し直しました。
この状態でGitHubとの紐付けや、ローカル側の環境を再構成していったというのが、この記事の内容です。
注意事項
自分の環境と参考になる記事などを照らし合わせながら作業しましたので、ご自分の環境を確認しながら作業を進めて頂ければと思います。
それでは始めます
ディレクトリ、ファイルの移植
一旦元のディレクトリはバックアップとして取っておき、作成し直したディレクトリで抜けてしまった修正などないか確認を行いました。
- featureブランチにスイッチ
$ git switch feature
- もし足りないコード、今修正していたコードがあれば移植。よければ以前、差分比較について書いた記事がありますので、そちらを参考に「diff -rq」コマンドで差分を比較して見ると差分の一覧を表示することが出来ます。
【差分比較】ファイルやディレクトリの差分を比較する方法
ちなみに、「 | grep -v」 で表示させたくない文字列を指定して、不要なファイルは表示しないようにすると確認が楽かと思いますので、この方法で行う際は試してみて下さい。
% diff -rq ＜ディレクトリのパス1＞ ＜ディレクトリのパス2＞ | grep -v ".git"
- master.keyや.envファイルなどがあればそちらはgitには含まれていませんので、そちらも元のフォルダからコピーしてください。（gitignoreで除外しているファイル）
- 基本的にはbundle installなどのコマンドで入るパッケージ等はbundle installで入れ直すので移植しなくて大丈夫です！なのでnode_modulesなどはその時インストールして入ったもので問題ありません。
- GemfileとGemfile.lockは移植した方が良いですね、yarn.lockもです。
ちなみにどうやって選別したかと言うと、私は下記の記事などを参考にディレクトリやファイルの移植を判断しました。
参考：Railsドキュメント
config: master.key
package-lock.json
Gemfile differ
Gemfile.lock differ
yarn.lock differ
.git/ 配下の全てのファイル (Git用のディレクトリ)
tmp: 配下の全てのファイル (キャッシュなど、一時的なファイル用のディレクトリ)
.DS_Store (Macのシステムが各ディレクトリに勝手に生成するファインダーファイル)
app/views: .DS_Store ( 〃 )
log: development.log (ログファイル用のディレクトリ)
log: test.log ( 〃 )
node_modules (bundle installなどのコマンドで入るパッケージなので不要)
db: development.sqlite3 (アプリケーションを動かしてから生成されるファイル群なので不要)
db: test.sqlite3 ( 〃 )
public: packs ( 〃 )
storage: 配下の全てのファイル ( 〃 )
.bundle
yarn-error.log
ちなみに、上記のように「development.sqlite3」を移植しないので、データベースに以前保存していたものは失われてしまいますので、どうしても前のものを使いたいという場合は「development.sqlite3」をコピーするのではなく、データベースのデータをダンプして（情報を正しい形でコピー）反映させる方法もあります。
便利なgemもあります。
参考：SQLite3のデータを別のRails環境にコピーする
bundle install
- 移植してからbundle installを実行
- Gemfile.lockで固定されたバージョンでgemなどがインストールされます。
GitHub トークンによる接続設定（SSHとは別です）
- Personal Tokenの生成方法は、GitHubの画面右上のユーザーメニュー「Settings」から
- 設定画面のサイドメニュー一番下「Developer settings」を選択すると、次の画面に「Personal access tokens」というメニューが表示されます。
- そちらをクリックして、Generateボタンから新しくトークン（パスワード）を生成します。 こちらは生成されたものは画面に一度しか表示されませんので、メモを忘れないように注意してください。
ちなみに、こちらの2つの記事を参考にトークンを利用した接続を行いました。
参考：GitHubのAccess token認証方法とは？Password認証の廃止
参考：GitHub – アクセストークンの作成・取得方法とgit操作での使い方
SSH接続については下記の記事が参考になりそうなので、こちらも試してもいいかもしれません。
参考：GitHub・SSH接続の環境設定方法（Mac OS）
git push
そしてその状態（featureブランチが最新のコード）で「git push -f」をしてGitHubを上書
% git push -uf origin feature
〜〜成功〜〜
GitHub側の操作
-
GitHubのレポジトリの設定（Settings）からサイドバーのbranchesを選択
-
デフォルトブランチを一旦featureブランチに切り替えます。
-
そしてmasterブランチをGitHub上で削除
-
そうするとレポジトリにローカルの環境も同じになるようにこのコマンドを打ってくださいというような警告が出ると思いますので、そちら実行してください。
ローカル側の操作
もしローカル（開発環境）でgit branchを実行して、masterブランチが残っているようでしたら、ローカルのmasterブランチも以下のコマンドで削除します。
% git branch
develop
* feature
master
release
% git branch -dr origin/master
Deleted remote-tracking branch origin/master (was XXXXXXX).
% git branch -d master
Deleted branch master (was XXXXXXX).
% git branch
develop
* feature
release
リモートブランチを最新化
- GitHub上で、プルリクエストを作成し、develop ← featureとなるようにして、developブランチにfeatureブランチをマージします。
私はこのタイミングで、コンフリクトが発生というようなエラーが出ました。 この場合、「Resolve Conflicts」ボタンからウェブ上で解決することが出来るはずなのですが、私の場合はこのボタンはグレーアウトになっていたので、コマンを実行して解決しました。 コマンドについては「Use the command line」というところをクリックすると、親切にアナウンスしてもらえるので、ここでは割愛しますが、その通り実行すれば大丈夫です。
* さらにプルリクエストを作成し、release ← developとなるようにして、releaseブランチにdevelopブランチをマージします。
mainブランチ作成
ローカルで以下のコマンドで推奨のmainブランチを作成しました。
% git pull # 現在のブランチの追跡情報はありませんでした
% git branch # releaseブランチになっていることを確認
develop
feature
* release
% git branch main
% git branch # mainブランチが作成されていることを確認
develop
feature
main
* release
% git switch main
% git push --set-upstream origin main # GitHubにアップ
最後に無事にpush出来たので、GitHubで、デフォルトブランチをmainブランチに変更して作業完了です。作業後はこんな構成に変わっています。
お疲れ様でした。
最後に
今回の作業で、GitHubについての知識や、Rub on Railsのディレクトリ構成、どのタイミングでファイルが生成されるのかなど、理解を深めることが出来ました。
そのきっかけとして、今回のようにツールを導入して今の状態を把握するといった手法のおかげだったので、そういった可視化されるようなツールは積極的に導入して理解を深めていきたいと思います。
最後までお読み頂きありがとうございました。