雛形リポジトリを作ってESLintなどの設定を使いまわす

# ESLintやPrettierなどの設定を使いまわしたい

毎回設定するのが面倒なので、いつも使う設定はあらかじめ雛形のリポジトリを**GitHub**に置いておき、使いたいときに`git clone`して使うようにしたかった。

`create-next-app`して、**ESLint**設定して、**GitHub**と連携してだと、気軽に始めたいときに腰が重くなるので、個人開発でぱっと始められるようにするため調べた方法の備忘録です。

### まず、雛形のリポジトリをGitHub上に作っておく

**ESLint**や最近よく使う**ChakraUI**や**recoil**などのライブラリや、**tsconfig**などを設定済みのリポジトリを、依然プロジェクトから引っ張ってきて作りました。

### 使い始めるとき

– プロジェクトを始めるディレクトリ上で`git clone`します。

“`
git clone [雛形となるリポジトリのURL] .　←最後に”.”をつけるとリポジトリの中身だけcloneされる
“`

– 一度`git remote -v`コマンドで

githubで履歴から該当データを完全に削除

プロジェクトの最初の頃はログデータもgithubにアップしてた方が楽だったが、徐々に規模が大きくなってくるとログデータが重くなってくる。

そんな時にログ出ただけ削除する方法。

githubのルートディレクトリで以下を実行。

“`
git filter-branch –tree-filter “rm -f -r [消したいディレクトリパス] ” HEAD
“`

例えば`./tutorial/data/*`を消したい場合には以下を実行する。

“`
git filter-branch –tree-filter “rm -f -r ./tutorial/data/*” HEAD
“`

次にリポジトリの最適化

“`
git gc –aggressive –prune=now
“`

`-f`オプションで強制プッシュ

“`
git push -f origin master
“`

あとはそのローカルのレポジトリを消してpull仕直せばいいらしい。

これからエンジニアを目指す人に読んでほしいWeb開発まとめ

# はじめに
この記事は，以下に当てはまる方が読むことを想定しています．
– エンジニアとして働いたことがない方
– IT企業に就職を考えている方
– Web開発の流れを理解したい方
– HTMLやCSS以外のことを知りたい駆け出しエンジニアの方

# 全体の流れ
どの企業もそうだと思いますが，いきなり開発から始まることはめったにありません．
基本的には，以下のような流れでシステム開発が進んでいきます．知らない単語が出てくると思いますが，後で詳しく説明するので，気にせず読み進めて大丈夫です．

1. チケットが切られる
1. MTGに参加する
1. スケジュールを立てる
1. 調査を行う
1. 設計をする
1. 設計書をもとにDEV環境で開発を行う
1. ユニットテストを行う
1. ソースコードをGitHubに上げて，チームの人にレビューしてもらう
1. STG環境にデプロイする
1. テストケースを作成する
1. ブラウザテストを行う
1. リリースに向けたドキュメントを作

行が削除されたコミットを特定するのにgit log -Sを使ってはいけない話（git log -Gを使うべき）

## 背景
仕事でコードレビューをしているときに「あれ、あの処理があったはずだけど消えてるな？どこで消えてるんだろ？」と疑問に思い、その処理の行が削除されたコミットを特定する方法を調べたら`git log -S “文字列”`で探すという情報を見つけましたが**それでは探せない例があるとわかった**ので備忘録です。

## git log -Sでは探せない例
例えば、`git log -S “function doSomething”`というふうに`doSomething`という名前の関数をコミット履歴から探そうとしたときに、1つのコミット内で`function doSomething`という文字列が同じ回数削除されていて同じ回数追加されていた場合に検知ができません。

`git diff`で説明をすると、`git diff`を実行して以下のような結果になるときには実際に`function doSomething`が削除されているにもかかわらず`git log -S “function doSomething”`では検知ができません。

“`
$ git diff
…

【Git】GitHub CLIの補完を有効にする方法

## Homebrewでインストールしている場合
GitHub CLIをHomebrewでインストールしている場合には以下のページの手順に沿って設定を行います。

https://docs.brew.sh/Shell-Completion

zshの場合には以下を`~/.zshrc`に記述します。

“`~/.zshrc
if type brew &>/dev/null
then
FPATH=”$(brew –prefix)/share/zsh/site-functions:${FPATH}”

autoload -Uz compinit
compinit
fi
“`

これでコマンドの補完ができるようになります。

`gh `を入力してタブを入力すると以下のように表示されます。

“`zsh:zsh
$ gh
alias — Create command shortcuts
api — Make an authenticated GitHub API request
auth — Authenticate gh an

【Git】.gitignore で指定してもファイルが作業ツリーに上がってきてしまうときの対処法

途中で .gitignore に追加した（すでにそのファイルをコミットしてしまっている）場合は，あとから.gitignore しても無視できない（ことがある？）．

ignoreしたいファイルを一度別の場所に移してからコミットし，再度戻してからコミットしなおすとignoreできました．

自分用 git チートシート

## コミットをまとめる
“`
git rebase -i HEAD~5
“`
– p: 残すコミット
– s: 使うが前のコミットに溶かす

## 未追跡ファイルを消す
“`
git clean -df
“`

– [git clean](https://git-scm.com/docs/git-clean) は未追跡のファイルを操作するコマンド
– 危険な操作なため、 `-i`, `-n`, `-f` のいずれかを使わないと実行できない
– `-f` : 強制実行
– `-n` : ドライラン、対象の確認
– `-d` : ディレクトリを含む

gitの復習

# はじめに
webアプリ開発について、学んでいる中、gitの学習をすっかり忘れていたので、ざっと復習。

# gitの概要
今までは、githubというサービスにファイルなどを保存している気でいたが、githubは、リモートサーバーの状態を、ブラウザで表示するツールのことだった。理解不足でした。

## 流れ
1. gitのインストール（済でした）
1. 新規リポジトリーの作成（または、既存のリモートリポジトリ―をコピー）
1. ステージング（リポジトリ内のファイル(の変更点）を、管理対象に加える）
1. ステージングの変更分を、「ローカルリポジトリに」反映させる
1. ローカルリポジトリの変更分をリモートリポジトリに反映させる

## コマンド

1. webページからダウンロードしていました
1. git init （リモートリポジトリからコピーする時は、git clone コピーしたurl)
1. git add ファイル名 (リポジトリ内のすべてのファイルを管理対象にするなら、 git add . )
1. git commit -m “残したいメッセージ”
1. git

【Git】マージされたリモートブランチを自動削除する方法【GitHub】

## 設定方法
以下の手順でマージされたリモートブランチの自動削除を設定できます。

リポジトリの「Code」の画面から「Settings」をクリックします。

「Settings」画面の「General」をクリックし、下にスクロールします。

![スクリーンショット 2022-10-02 22.01.53.png](h

【Git】コマンド早見表

## 概要
Gitコマンドの自分向けの備忘録です。

## コマンド一覧

現在の差分状態を知る
“`
git status
“`

ステージング
“`
git add .
“`

コミット
“`
git commit -m”コミットメッセージ”
“`

プッシュ
“`
git push origin ブランチ名
“`

ローカルリポジトリの操作について（初心者向け）

# ローカルリポジトリを操作するための流れ

gitとは分散型バージョン管理システムの一つです

– リポジトリと呼ばれる`貯蔵庫`にソースコードの変更履歴や実コードを記録します
– リポジトリにはローカル（個人端末）とリモート（共有端末）の2種が存在します
– まずはローカルにデータを保存し、最後にリモートへコードを保存します

## ローカルの基本操作

目次
1. ローカルリポジトリを初期化する
1. ローカルリポジトリへ記録する
1. ローカルリポジトリの状態を確認する
1. ローカルリポジトリの履歴を確認する
1. ローカルリポジトリの変更を元に戻す

### ① ローカルリポジトリを初期化する

プロジェクトを作成する場合、そのディレクトリを作成しますが
Gitでそのディレクトリを管理するにはGitの初期化が必要です

“`console

//ターミナルでカレントディレクトリを
//プロジェクトのディレクトリに設定した後

$ git init
“`

Gitの初期化をすることによりディレクトリへ
ローカルリポジトリが新規作成されます

### ② ローカルリポジトリ

`$ git status -s`について

`$ git status`を使用すれば、現在編集中のファイルやインデックスされているファイルの一覧を確認することができる。
このコマンドに`-s`オプションを付与すればより簡単にファイルの差分を確認することができるが、ファイルの前に文字が表示される。
あまりこの意味に関して理解していなかったので調べてみた。
※`-s`=`–short`

# 基本構造
変更があったファイの頭には1つか2つのアルファベットがつく。
└**XYの構造**

– X（右側）→ ステージ前の状態
– Y（左側）→ ステージ後、コミット前の状態

VSCodeの場合はわかりやすいように色分けしてくれる。
└Y：緑、X：赤

# アルファベット一覧
| 文字 | 単語 | 意味 |
| — | — | — |
| A

.gitignoreで機密情報を守る。

はじめに

Djangoを学習した手の時にGitHubにpushした際に以下のようなメールが届いた。

どうやらDjangoののSecretKeyをGitHub上にアップロードしてしまったのがいけなかったらしい。

慌てて消そうとしたが該当箇所を削除するだけで解決する問題なのかわからず、色々調べたところ、.gitignoreで指定したファイルをGit上にあげないようにする事ができるらしい。
今回はその方法について書いていく。

本記事では初心者向けに手順にのみ絞って記述していくので、細かい説明は割愛する。

.gitignoreファイルを作成する。

　

まず.gitignoreファイルをmanage.pyファイルと同じ階層に作成してみましょう。
（※mysiteの中のsettings.

困ったときはGit Reflogに頼る

SourceTreeなどGit関連のツールはいっぱいあると思いますが
その際にマージミス、リセットミスなどまぁやらかしてしまうことは何回かあります。

その時にGit Reflogコマンドをよく使うので、備忘録として残しておきます。

## git reflogとは
自分がGitを使用した操作のログを確認することができるコマンド。
どちらかというと、操作をやる前に戻すと言った場合に利用する。

そのため、マージミスやブランチを間違えて削除してしまった…など、大きな操作ミスなどのリカバリ策としてよく利用する。

このコマンドを実行すると、以下のようにログが出力される。

## 時間をさかのぼりたい
下記のようなコマンドで、時間を表示してログをさかのぼることができます。
`git reflog –date=default`

![image.png

わかりやすいコミットメッセージとは・・？

# はじめに
スクールでのカリキュラムの復習中にコミットメッセージがぐちゃぐちゃになってしまっていることに気づきました・・。今まで深く考えずに記述していましたが、後から振り返った時に何を変更したのかわかりにくいですね。
(余談：授業中急いでとったノートを後から見返して、自分の文字が読めなかったことを思い出しました:sweat_smile:)

現在は転職に向けての学習段階のため、自身でルールを決めてコミットメッセージを記述していこうと思います！
※あくまで現段階のルールです。転職先の企業やチーム、プロジェクト単位でコミットメッセージの記述ルールは異なると思うので、転職後は臨機応変に対応する必要があると思います！

# コミットメッセージの役割
**何をなぜ変更したのかを記述する**

# コミットメッセージの目的
– 過去の状態に戻したい時にいつのデータに戻ればよいかわかりやすくすることで、作業の効率化を図る
– 自分以外の人が履歴を確認した時にわかりやすくすることで、作業の効率化を図る

# 書くべきこと
コミットメッセージには「何を」と「なぜ」を書くのが望ましいです。
その理由は

【Git】タグ上げ手順

# 共通リポジトリでタグ上げ
– 共通リポジトリ名をcommonとする
– 他のリポジトリ名をotherとする

## 0. 前提
– common側で、トピックブランチでの改修内容がdevelopブランチにマージされていること

## 1. 現在のタグを確認

“`terminal
$ git describe –tags –abbrev=0
“`

仮に、実行結果は`develop-0.776.0`とする

## 2. タグ上げ
– 旧タグ + 1

“`terminal
$ git tag “develop-0.777.0”
“`

## 3. プッシュ

“`terminal
$ git push origin “develop-0.777.0”
“`

“`terminal:例
~/common (develop=)$ git push origin “develop-0.777.0”
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/common.git

【Git】空コミット時のコマンド

“`terminal
$ git commit –allow-empty -m “コミットメッセージ”
“`

“`terminal
$ git push origin ブランチ名
“`

:::note
コミットメッセージは省くことも可能
“`terminal
$ git commit –allow-empty
“`
:::

Git ブランチ作成からマージされるまでの流れ

Issueが割り振られてから、マージされるまでの流れをご紹介します。
プロジェクトによって細かい部分は異なるかもしれませんが、概ねは大丈夫かなと思います。

## 流れ

1. [新しくブランチを作成する](#新しくブランチを作成する)
1. [作業してコミットをする](#作業してコミットをする)
1. [作業ブランチを整理する](#作業ブランチを整理する)
1. [作業ブランチに最新のmainブランチを取り込む](#作業ブランチに最新のmainブランチを取り込む)
1. [リモートブランチへプッシュする](#リモートブランチへプッシュする)
1. [プルリクエストを作成する](#プルリクエストを作成する)
1. [レビューを受ける](#レビューを受ける)
1. [レビュー内容を反映したコミットを作る](#レビュー内容を反映したコミットを作る)
1. [変更点の再レビューを受ける](#変更点の再レビューを受ける)
1. [再度作業ブランチを整理する](#再度作業ブランチを整理する)
1. [マージしてブランチを削除する](#マージしてブランチを削除する)

書き出してみましたが、多いの

過去のコミットで間違ったファイルを追加、さらにいらない差分を含めてしまった時、私がやったこと

# 何が起こったか
1. ユニットテストを書いているブランチ（unit_test/hogeA_ViewController)とあるMVCからMVPにリファクタしているブランチ（mvp/hogeB_ViewController）に同じパスの同じ名前のファイル（以下ファイルパスを被ったファイル.swift）と mvp/hogeB_ViewControllerに要らない差分を含んだファイルが過去にコミットされているのをmvp/hogeB_ViewControllerで発見
“`
// Source treeで発見

commit hash値: yarakashitacommit
new file: ファイルパスを被ったファイル.swift
modified: コミットしたくなかった差分を含んだファイル.swift
modified: コミットしたい差分を含んだファイル.swift
new file: コミットに入れたい新しいファイル.xib
“`

# 具体的に何がしたい？

1. mvp/hogeB_ViewController上ではファイルパスを被ったファイル.swiftはいらない

【GitHub】パッケージを削除する方法

## パッケージを削除する方法
パッケージは以下の手順で削除します。

リポジトリの「Code」の画面右下「Packages」欄のパッケージ名をクリックします。

するとインストール方法などが記載されたページが開きます。
このページ右下の「Package settings」をクリックします。

開いたページ赤枠内の「Delete this package」をクリックし削除します。
![スクリーンショット 20