20201017のGitに関する記事は4件です。

npm run startを実行するまで~初めてのNode.js動作確認~

背景

実務経験ないまま、共同開発を経験させていただく機会があり
npm run startでブラウザが立ち上がるまで動作確認する必要があった。
内容自体は単純ではありますが、覚えも含めて投稿させていただきます!
また、この動作確認の一連の流れのまとめがなかったため、投稿してみようと思った次第です。

前提

  • 2020/10時点での状況
  • Windows使用者
  • 当時の知識:「npm」「Node.js」というワードを始めて聞いた...
  • Git/GitHubを全く触ったことがなかった...

作業手順優先で詳細は本投稿では省いています。
詳細はリンク先で記載がありますので、申し訳ないですがそちらをご参照くださいm(__)m

手順

1. GitHubにアカウント登録・GitHub内でリポジトリを作成

作業箇所:ブラウザ
https://qiita.com/kutarou197/items/8acea22ae36dbcf45c9f

2. Node.jsのインストール

作業箇所:ブラウザ
https://qiita.com/sefoo0104/items/0653c935ea4a4db9dc2b

npmとはNode Package Managerの略です。
ということでNode.jsのインストールが必須です。
Node.jsのインストールと同時にnpmもインストールされます。
※ちなみに自分は「Node.jsのインストールが必要」ということに気づかず、Node.jsをインストールせずにcmd(=コマンドプロンプト)にコード打込んでエラー出して悶絶、というのを3時間程続けていました(笑)

※尚、cmdはwindowsがデフォルトで持っているツールで、スタートメニュー横の虫眼鏡ボタンで「コマンドプロンプト」で調べると写真のように出てきます。
image.png

3. nodistでバージョン管理する

- nodist のインストール

作業箇所:ブラウザ
https://qiita.com/satoyan419/items/56e0b5f35912b9374305

- バージョン管理

作業箇所:cmd(=コマンドプロンプト)
https://qiita.com/satoyan419/items/56e0b5f35912b9374305
↑「nodistのインストール」と同じリンクです。

共同開発する際、指定されたNode.jsのバージョンに変更
Node.jsのバージョンによってnpmも対応するバージョンが異なるので、npmのバージョン管理もお忘れなく!

尚、リンク先のnpxのインストールは今回は必要ありませんが、困ることはないので一緒にインストールしておいてもいいかもしれません。

4. GitHubで作成したリポジトリをクローンする

作業箇所:cmd

git clone リポジトリのURL(https~)

5. ディレクトリを変更し、Gitのremote urlを変更

作業箇所:cmd

cd リポジトリ名
でディレクトリ移動し
Remote url set-url origin リポジトリのURL(https~)
でリモートURLを変更
https://qiita.com/minoringo/items/917e325892733e0d606e

6. リモートリポジトリにプッシュする

作業箇所:cmd
https://qiita.com/yukibe/items/9ef9d54f2e7d53cfb51c
git push origin master -f
上記コマンドを入力して、リンクにある「リモートリポジトリに反映」の「push」のような画面が出たらOKです

7. 動作確認

作業箇所:全てcmd(=コマンドプロンプト)

- npm packageインストール

既製のパッケージをリモートリポジトリにインストール
npm install

- ファイルやプロジェクトの実行

npm run start
でブラウザが立ち上がったら完了!!
(この時点では真っ白のブラウザかと思います。)

※npmとは?:既に作られたNode.jsのパッケージ
https://qiita.com/righteous/items/e5448cb2e7e11ab7d477


ほんとに作業内容しか記述していないので、各種作業により端末内で何が起こっているのかは各リンクや関連記事をご参照ください!

最後まで読んでいただき、ありがとうございました!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Githubのブランチ名がmainであることに気付かず、masterでpushしようとしたら"There isn’t anything to compare. main and master are entirely different commit histories."と表示された時の対処法

経緯

アプリケーション作成のためGithubにリモートリポジトリを作成し、ローカルのブランチ名をmasterにしてpushを行いました。Githubを確認するとプルリクの表示が出ていたので疑問に思い確認すると、Githubで作成されたデフォルトブランチがmainになっていたことに気が付きました。調べてみると2020年の10月からGithubにて作成されるデフォルトブランチがmainになっていることが分かりました。

今回、私と同じようにローカルブランチをmasterにしてpushし、プルリクの表示が出て以降進めず、どう対処すればよいか分からない方がいると思い記事を書こうと思いました。

※記事にしようと思ったときにはマージまで終了してしまったので画像は少ないです!

※10月からリポジトリのデフォルトブランチ名がmainになるという情報は以下を参考にしています。
https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-created-repositories-is-now-main/

原因

リモートリポジトリ作成時、デフォルトブランチがmainになっていることを確認せずにローカルブランチをmasterのままpushしてしまったこと。

実際に発生したこと

いつものようにpushまでしました。

$ git init
$ git add .
$ git commit -m "XXXXXXX"
$ git remote add origin https://github.com/YYYYYYY/test.git
$ git push origin master

ここでGithubを更新すると、Compare & pull requestが表示されます。

通常であれば、Compare & pull requestを押すと以下が表示されますが・・・

スクリーンショット 2020-10-14 10.46.18.png

今回は表示されませんでした。

今回の場合、Conpare & pull request押すと以下が表示されました。

There isn’t anything to compare. main and master are entirely different commit histories.

「mainとmasterは全く異なるコミットを持つので比較できません」という意味ですね。

関連性を構築できればうまくいくかもしれません

解決策

mainとmasterを関連づける

$ git branch --set-upstream-to origin/master main                     

master = (ローカルリポジトリのブランチ)
main = (リモートリポジトリのブランチ)

これでmainとmasterの関連性を構築できました。

あとは以下を行います。

$ git checkout master
$ git pull
$ git checkout main
$ git pull
$ git merge master
$ git push origin main

補足

上記を行った際に以下が発生するかもしれません。

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/maruuchi/health_care6.git'
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.

その際は以下の方法で対処しました。

$ git push -f origin main

これはpushを強制的に行うことです。あまり良い方法ではないかもしれませんが...

追記

新たなアプリケーションを作成するため新しくリモートリポジトリを作成し、ブランチ名をmainにしてローカルリポジトリのブランチ名をmasterにしてpushしたところエラーは発生せず、通常通りpushできました。原因は不明です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitのリモートリポジトリにpushしてしまった機密データを削除する

はじめに

リモートリポジトリから機密データを削除する際に調べたことを備忘のためにまとめます。

前提

  • Git version: 2.26.1
  • トランクベース開発のため、masterブランチのみが作業対象でした(他のブランチも対象にする場合は未検証です)
  • タグは使っていなかったので、タグ周りのコマンドは省略しています(→上のGitHubヘルプページが参考になると思います)

手順

  1. 手順確認用のブランチでリハーサルする
  2. 他のブランチで実行する

A.手元のローカルリポジトリでの作業

# 機密データが含まれているコミットを確認
$ git log -- ファイル名

# 機密データをリポジトリから削除(全ブランチの場合は--allを指定すると思われる)
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch 機密データを含むファイルへのパス" \
  --prune-empty

# 先のgit logコマンドで機密データを含むコミットがないことが確認できる

# 以下は2.他のブランチでの作業の中で実行
# リモートリポジトリのブランチを上書き(--all指定により全ブランチを上書き)
git push origin --force --all

B.他の開発者の手元のリポジトリでの作業

リモートリポジトリのブランチを上書きした後の作業。
ローカルにリモートリポジトリを強制的にpullする。

# 前提: カレントブランチはmaster

# リモートのmasterブランチをフェッチ
git fetch origin master
# ローカルリポジトリのインデックスと作業ディレクトリにある変更がなくなるので注意
git reset --hard origin/master

参考

コマンド調査事項メモ

git log

2.3 Git の基本 - コミット履歴の閲覧

最後に紹介する git log のフィルタリング用オプションは、パスです。 ディレクトリ名あるいはファイル名を指定すると、それを変更したコミットのみが対象となります。 このオプションは常に最後に指定し、一般にダブルダッシュ (--) の後に記述します。

git filter-branch

https://git-scm.com/docs/git-filter-branch#_examples

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

  • --index-filtergit rmの組合せはtree-filterrmより速い
  • --forcerefs/original/で始まるrefがあったり、一時ディレクトリで開始したりすることを拒否しないようにする指定
  • --prune-empty:filter-branchによりできる空のコミットを削除(枝刈り)する指定

git rm

https://git-scm.com/docs/git-rm

  • --cached:インデックスからのみアンステージし、削除する指定
  • --ignore-unmatch:1つもファイルが一致しなかったとしてもステータスコード0(正常終了)で終了する指定
  • --dry-runあり

git push

3.5 Git のブランチ機能 - リモートブランチ

git fetch origin master

ローカルリポジトリのリモート追跡ブランチを更新。

リモート追跡ブランチは以下の記事が分かりやすかったです。
【Git】リモートからの取得とリモートへの反映で行っていること(fetch,pull,push)

git reset --hard

現在のブランチの内容を、リモート追跡ブランチ(ここではorigin/master)と同じにしている。

7.7 Git のさまざまなツール - リセットコマンド詳説

--hardは「HEAD が指し示すブランチを移動」し、「インデックスの内容を HEAD と同じに」し、「作業ディレクトリの内容をインデックスと同じにする」
→インデックスと作業ディレクトリの変更はなくなる

所感

filter-branchコマンドで機密データを削除できました。
ただ、変更したmasterブランチのpullを開発者全員にお願いする必要がありました。
小さなチームでもこれは大変でした。
なので、filter-branchコマンドは本当に最終手段で、機密データをpushしないようにする手段を整えていくのがよさそうです。

以上です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git ignoreを使って特定のファイルをgitでプッシュしない

開発すれば開発するだけ、プログラミングが楽しくなっているうったむです☺️

今日はenvファイルなど開発者以外の人には見せたくないファイルをgitでプッシュしない方法を見つけたのでメモとしました。

解決法は「git ignore」です!どのように使うかを以下の部分から説明しますね。

開発環境 macOS Catalina バージョン 10.15.7

git ignoreとは

硬い言葉で説明すると「指定したファイルをgitの追跡対象から除外する」ことを可能にします。パスワードが書かれたファイルなどはgithubにはプッシュしない方が良いですよね。

僕の場合は、mysqlのパスワードなどを書いたenv.phpに適用するために使いました。

git ignoreをどのように使うか

まず

git status

で内容の確認します。

おそらくgitでプッシュしたくないファイルが表示されているでしょう。

そのファイルをプッシュしないようにするため

vim .gitignore

を使います。

そうすると、指定したいファイルなどを打ち込める画面になります。

私の場合はenv.phpをgitでプッシュしたくないので

env.php

と打ち込みます。

ファイルなら「ファイル名を」、コメントなら最初に「#」を。ディレクトリなら末尾に「/」を書きます。

その他にも、特定のファイル名の指定をしたいなら「.ファイル名」とします。例えばphpで書かれたファイル全てを指定したいなら「.php」と書きましょう。

逆にgitの管理対象にしたいなら最初に「!」を書けばokです。

ではgitの管理対象外にしたいものを指定したら

:w

で保存しましょう。

:q

にて終了しましょう!(:wqで保存して終了とどちらもできます)

できたら

ls -al

で中身の確認です(ls 何がディレクトリ内にあるか確認。-al 隠しファイルや詳細などの表示)。

最後にgit statusで確認すると.gitignoreができていることがわかりますね。

まとめ

ぜひセキュリティゆえに共有したくないファイルがあったら「git ignore」を使いましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む