Create React App + TypeScriptを作成

npx create-react-app my-ts-app --typescript
cd my-ts-app

ESLintとPrettierの設定

必要なパッケージをインストール。

yarn add -D prettier eslint-config-prettier eslint-plugin-prettier

.eslintrc.ymlを作成。

extends:
  - react-app
  - plugin:prettier/recommended
rules:
  prettier/prettier: # - error以下はお好みで
  - error
  - semi: false
    singleQuote: true

package.jsonの以下の部分を削除（上記.eslintrc.ymlとの重複を避けるため）

- "eslintConfig": {
-   "extends": "react-app"
- },

同じくpackage.jsonにESLintとfixのタスクを追加。

"scripts": {
+   "lint": "eslint './src/**/*.{ts,tsx}'",
+   "lint:fix": "eslint --fix './src/**/*.{ts,tsx}'"
}

Create React App + TypeScriptでESLintとPrettierを使うことができるようになりました。

Gitコミット時にチェックする

必要なパッケージをインストール。

console.log

yarn add -D pre-commit lint-staged && yarn add -D husky

package.jsonにコミット時のチェックを追加。

+ "husky": {
+   "hooks": {
+     "pre-commit": "lint-staged"
+   }
+ },
+ "lint-staged": {
+   "*.{ts,tsx}": [
+     "eslint './src/**/*.{ts,tsx}'"
+   ]
+ }

Gitコミット時にeslint './src/**/*.{ts,tsx}'が実行され、チェックしてくれます。

以上。

$ git push をするまで。

この記事を読んでいる方は 「うまく git push までできないよ！」という方だと思います。

僕は初学者で、最初は苦戦しました。笑

でも、以下のコマンドをなぞっていけば何とかなるかもしれませんので、諦めずにやっていきましょう。

GitHub に push する。

【やったこと】 SwiftSampleApps というフォルダの中にある news というファイルを GitHub に push した

それでは、⑴〜⑺まで順を追って見ていきましょう。

⑴$ cd SwiftSampleApps\ /news

まず、該当のファイルがある場所にいきます。

⑵$ git init

そして、そのファイルを git 管理下におきます。

⑶$ git add .

そのファイル以下を全て push する対象として追加します。（これをステージングといいます）

add と .(コンマ) の間に半角スペースがあるので注意しましょう。

⑷$ git status

追加されたか確認します。追加が成功していたら、緑色で new file　などの文字が出てきます。

⑸$ git commit -m " ここにはメッセージ内容を書く "

そして、コミットします。また、同時に " "　の中にメッセージを書きます。

⑹$ git remote add origin git@github.com: ここにユーザー名を書く / ここにレポジトリ名を書く.git

GitHub に add します。これだけでは push されていないので注意しましょう。

⑺$ git push origin master

とうとうプッシュです！　

うまくいくと、パスワードの入力が求められるので、パスワードを入力したら終わりです。

*[ new branch ] master -> master などの文字が見えたら成功です。

お疲れさまでした！

Gitの設定

• 設定ファイルを作る
  • git config
  • git config --list　※Gitの設定内容を確認する

リポジトリの作成

• カレントディレクトリにローカルリポジトリの作成する
  • git init

コミットの作成

• ステージングエリアに変更を登録する　=コミット予約

  • git add
  • git add .　※カレントディレクトリ配下の全てのファイルを追加
  • git add subDirectory　※「subDirectory」ディレクトリ配下のファイルを全て追加
  • git add subDirectory/file1.md　※「subDirectory」ディレクトリ配下の file1.md を追加

• 変更したファイルをまとめてステージングエリアに追加する

  • git add -A　※「-A」は、「--all」とも書ける

• コミットを作成する

  • git commit
  • git commit -m "コミットメッセージ"　※1行コミットのみ

• 更新されたファイルをステージングエリアに追加して、そのままコミットする

  • git commit -am "コミットメッセージ"　※新規ファイルの場合はgit addコマンドを使う必要がある

• Git管理下のファイルやディレクトリを削除する

  • git rm
  • gir rm -r　※ディレクトリの場合は「-r」オプションを付ける

状態の確認

• ローカルリポジトリの状態を確認する　※ファイルの状態を確認

  • git status
    (git statusコマンドは使用中のブランチを確認することもできる)

• コミットの履歴を確認する

  • git log
  • git log -p　※ファイルの差分も確認できる

差分を確認

• ファイルの差分を確認

  • git diff　※ローカルリポジトリ(ワークツリー)とステージングエリア
  • git diff --cached　※ステージングエリアとGitディレクトリ(前回のコミット)の差分

• 今使っているブランチをmasterブランチと比較

  • git diff master

状態の復元

• 編集内容を取り消す

  • git checkout ファイル名
    　　例）git checkout -- Git_memo.md
    　　※ファイルの状態が直前のコミット(または直前のステージングエリア)に戻る。
    　　※ファイルを新規作成したり、ファイル名を変更した時は、操作を取り消せないので自分で削除する

• ステージングを取り消す（編集内容は残る） = コミット予約の取り消し

  • git reset ファイル名
    　 　例）git reset HEAD Git_memo.md
    　 　※HEADは最後にコミットした状態。つまり最後のコミットと同じ状態にリセットする
    　 　※ファイルの状態はそのままでステージングエリアへの登録だけを取り消す

戻る

• 特定のコミットに戻す

  • git reset --hard コミットid
    ※コミットidは、git logコマンドで調べて、戻りたいコミットのidを指定
    ※戻った以降のコミットをなかったことにする(コミットログが消える) ※masterではなくブランチの場合は切り替えを忘れずに。
  • git revert コミットid
    ※コミットログを残したまま戻る。 ※非推奨

• 特定のファイルのみ、コミットのバージョンを戻す

  • git checkout コミットid ファイルパス

ブランチ

• ブランチの作成

  • git branch ブランチ名

• 使用中のブランチを確認

  • git branch　※先頭にアスタリスクが付いているのが今使っているブランチ

• ブランチ切り替える(=チェックアウト)

  • git checkout master(使いたいブランチ名)

• チェックアウトと同時にブランチを作成する

  • git checkout -b ブランチ名

• ブランチの削除(ローカルレポジトリ) ※マージ済みのブランチを削除する

  • git branch --delete ブランチ名
    　　　or
  • git branch -d ブランチ名

• ブランチの削除(ローカルレポジトリ) ※マージ状況に関わらずブランチを削除する

  • git branch -D ブランチ名

• ブランチの削除(リモートレポジトリ)

  • git push --delete origin ブランチ名
    　　　or
  • git push origin :ブランチ名

アップロード

• 現在のローカルリポジトリの内容をリモート側（GitHub側）にアップロードする
  • git push
    　 　例）git push origin master
    　 　例）git push origin ブランチ名　※originはプッシュ先のリモートリポジトリの名前を表す

merge と rebase

• rebase

  • git rebase つなぐ元にするブランチ名
  • git rebase -i ひとまとめにする地点の一つ前のコミットID

• merge

  • git merge マージ元(取り込みたいブランチ名など)

リモートリポジトリの内容をローカルリポジトリに取り込む

• pull (取得内容がワークツリーにまで反映される)

  • git pull origin master(プルするブランチ名)
    ※originはプル先のリモートリポジトリの名前を表す

• fetch (ローカルリポジトリへの取得しか行わず、ワークツリーには反映させない)

  • git fetch origin
    ※originはフェッチ先のリモートリポジトリの名前を表す

注意
ブランチを切り替えずにgit pullコマンドを実行すると、今使っているローカルリポジトリのブランチに、リモートリポジトリのmasterブランチがマージされてしまうので注意しましょう。

• ローカルリポジトリに存在しないブランチを取得するコマンド
  • git fetch origin
    　　　　↓続けて
    
  • git checkout ブランチ名

リモートレポジトリの設定

• リモートレポジトリの設定を確認する
  • git remote -v

---

コミット&プッシュのサイクル

$ git add ファイル名
　　　↓
$ git commit -m "コミットメッセージ"
　　　↓
$ git push origin master

曲がりなりにもWEBサービスを公開した中で、いわゆるプログラミング言語技術以外で身についたんじゃないかなーということを書きたいと思います。

対象読者

駆け出しエンジニア
インプットが大好きな人

総論

とにかく手を動かさないと身につかない！し、動かしてたら身につくよ。

身についたこと

Gitでのバージョン管理

今まで切った貼ったで適当に上書き保存をしたり、別名で保存したり、気になった箇所を条件反射で修正したりしていましたが、今回意識してGitを使ってみるととても便利、というか気が楽になりました。

GitHub Flowはモチベーションを保つのに良い

導入が簡単そうだったのでGitHub Flowを参考にしました。
GitHubを中心にして管理するわけですが、シンプルで分かりやすいというのと、草が生えるのはモチベーション的にとても助かりました。

タスクごとにブランチを切る

タスクごとにブランチを切ることで今すべきことに集中できました。ブランチ名をタスクに沿った名前にするとターミナル上に表示されて意識しやすく良かったです。

コンフリクトは怖くない

コンフリクトは今までどう対処したらいいのかが分からなくて、コンフリクトが起きる前までとにかく戻ってなかった事にする、みたいなことしかできていなかったんですが、VSCodeを使うととてもわかり易く対処できました。

VSCodeをちゃんと使う

今回Git周りではVSCodeにかなり助けられてます。
VSCodeの組み込みのGit画面も便利で、常に表示しておくとこまめに労なくコミットができました。今までが疲れたらまとめてコミットみたいなひどい状態だったので、幾分かましになったんじゃないかと思います。

使わない(かもしれない)コードを気兼ねなく消せる

新しい実装を思いついた時に今までは古い実装部分をコメントアウトをして残していました。
特に気にしていなかったんですが、コメントアウト部分を思い切って消してしまうとコード上がとてもすっきりし、こんなに散らかったところでコード書いてたんだなぁと、机を掃除したような気分になりました。
Gitをちゃんと使ってると、もし必要になってもまたすぐ戻せるってのは安心できるもんですね。

プログラミングの組み立て方

小さく、簡単なものをまずは動かす。

これはプログラミングの学習においてどこでも言われることかと思いますが、やっとできてきたように思います。

実際のコード上で新しいことを試すのではなく、ダンドboxとして別のファイルを作ってそこで試してみると、原因の究明や仕組みの理解がしやすかったです。

今まではライブラリの設定など、本番と同じ環境にするのが面倒くさかったり理解できてなかったため、本番のソースコード上で新しいこと試してました。そうすると影響の範囲が広くて全然理解できないんですよね。その上進捗も無いので自信も無くなるという悪循環。

テスト駆動的に作る

厳密なテスト駆動とは違うんですが、console.logで希望する返り値を横に書いとくと便利でした。
console.log(tagging()) //"TAKI183"
console.log(tagging(pubkey)) //"CSDM398"
のように実装する前に先に書いとくって感じです。

本当はJest等の自動テストツールを使ってちゃんと作りたかったんですが、これでも割と助かりました。

上から作るか下から作るかみたいな話だと思うんですが、今までは最初からロジックを組み立ててました。

そうじゃなくて、上から、というか関数を作ってとりあえず欲しい返り値をreturnしちゃう。文字列なのか数値なのか、オブジェクトならどんなパラメータがあるのか。consoleで先に出してはっきりさせとくと、返り値の定義もしやすくロジックも作りやすかったです。

技術のこだわりを一旦捨てる

Qiitaはめちゃくちゃ読んでます。だからなのか最新の技術はこれ！どうせやるならこの技術！といった最先端病とても言うような思考に陥っていました。

一番効率的な技術、最先端の環境にばかり興味が言って、技術調査でどんどん時間が溶ける…

最先端病から脱せたのは締切を作ったことと、完成を第一にしたのが良かったんだと思います。

最初はVue CLIを使って単一コンポーネントで作り、ScopedCSSで効率的に！とか思ってたんですが、最終的にはCDN版のVueになりました。
それでも愚直に動くものを作ることを第一にすることで、やっとひとつ完成させる事ができました。

自分で実装してみないと結局わからん

上記とも関連しますが、Qiitaやはてブロ、書籍など、情報はたくさんあふれています。スマホでどこでも情報を読めます。

でもそれでできる気になってしまっていたのがはっきりわかりました。やっぱり自分で動かして、実装してみないとちゃんとは理解できないもんですね。

今回ですと、WebSocketやPromise周りが全然理解できてなかったです。正直今でも怪しいんですが、ちゃんと理解が怪しいと自覚できたのも収穫です。

やってよかったこと

サービスの周辺知識を広く調べる

今回作ったサービスはストリートグラフィティをモチーフにしました。

とにかくコードを書き実装をしたかったので、ストリートグラフィティについては画像を検索し、なんとなくの知識で作り始めました。が、いまいちかっこよくならない。

そんな行き詰まった時に改めてストリートグラフィティの歴史から意味、書き方を調べてみると、今まで実装方法だけでしか考えていなかったものが、血が通ったアイデアが湧いてきました。今考えるとUXデザイン的なことなのかも知れません。

ここ最近プログラミングの事ばかりQiitaやら本やらで調べていたので、全然違う勉強が単純に楽しかったのもあります:)

プログラミングの勉強だけじゃなく、そのサービス自体の知識を直接関係ないかもしれない周りのことまで知ると、実際のサービスにもとても良い影響があると思います。

まとめ

独学で勉強している方、プログラミングの学習方法について不安も多いかと思います。僕も独学でやっているので、本を読み漁り、Qiitaに張り付き、「一番のやり方」をずっと求めてしまっています。

でも「一番のやり方」を探すよりも、手を動かすとホントに意外と身につくってのがここ最近の一番の収穫です。

それこそ、この記事を読んでもプログラミングが速くなるわけでも、ソースコードが綺麗になるわけでもありませんが（笑）この記事を読んで下さった方の、少しでも励みになれば嬉しいです。

Gitが使いたいのに、なにからしたらいいかわからない

なんかみんなGitを使っている。私も使いたい。芝とか言ってみたい。
でも職場はSubversionばっか！なんてこったい！
GitHubとGit？GitLab？よくわかりません、お手上げです。
―となってしまった私へ。以下の手順でやればとりあえず導入できます。
細かいことは現在(2019/05/02)のわたしもわかってないですが、とりあえず使えています。

概要

GitHubをとりあえず運用する。
ローカル環境とリモートの環境構築と、簡単な使用方法

わたしへの備忘録なので、指向がわたし向き！です。

環境構築

Git for windows をダウンロード

macはもともと付属しているようです。
が、私はWindowsを使っていることでしょう。"git for windows"とググれば出てきます。

GitBushの設定

1. Gitコマンドが使えるか確認

$git --version

GITのバージョンが返ってくればOK

2. ユーザー名とメールアドレス登録

$git config --grobal user.name "TanakaTaro"
$git config --grobal user.email "TanakaTaro@tmp.com"

名前とメールアドレスは各々置き換えること
設定が反映されているかは$git config --listで確認できます。

3. SSHのカギを作りましょう

$ssh-keygen -t rsa -b 4096 -C TanakaTaro@tmp.com

メールアドレスは各々置き換えること
フォルダをどこに配置するかとか、パスワードの設定とか聞かれますが、適当に（投げやりといういみではなく）対応してください。

4. SSHのconfig設定

$vim ~/.ssh/config
Host github
 HostName github.com
 User git
 IdentityFile ~/.ssh/id_rsa(デフォルト名の場合/秘密鍵のパスを入力）

わたしはVimが特別に苦手でしょうから、あえて言及しますが、入力から保存などのコマンドへ移行するにはescを押すと切り替わりますからね。esc+:wqです。

WebでGitHubアカウント作成

アカウント作成はgithub.comからどうぞ
アカウントを作成したら公開鍵を登録します。
拡張子が.pubのほうのファイルid_rsa.pubです。パブリックの意味です。
GitHub右上のアイコン>アカウントメニューから「Settings」>左側メニュー「SSH and GPG keys」>「New SSH key」>公開鍵を登録
から登録できます。

リポジトリ作成

このWebブラウザから作れちゃうのでそのまま作っちゃいましょう。
名前は何でもいいです。Sampleとかtestとか、なんでも。

SSH接続確認

$ssh github

これで通信が成功すればとりあえず次に進めます。（今回は躓かないことを目標としているのでこれで良しとする）

使ってみる(運用)

使わなきゃどうしようもないので使いましょう。

作業ディレクトリをつくる

$mkdir git_work
$cd git_work

この時エラーを吐いたら、とりあえずDesktopとかに移動してリトライしてみること。
（詳細はメモ書きへ…）

GitHubからクローンする

$git clone git@github.com:***********/test.git

git@github.com…はブラウザからGitHubにアクセスして緑色のClone or Downloadのところから持ってくる。

もしもこの時エラーを吐いたら、とりあえず上で作ったフォルダ(ディレクトリ)に移動してリトライしてみること（詳細はメモ書きへ…）

作業用ブランチを切る

$git branch test_branch
$git checkout test_branch

ブランチを切るときはクローンしたフォルダ(ディレクトリ)に移動してからやりましょう。
ブランチを切るときはクローンしたフォルダ(ディレクトリ)に移動してからやりましょうね。
git branchで今あるブランチを確認することができます。

作業したらコミットする

$git add 追加ファイル名
$git status
$git commit -a

コミットはローカルレポジトリに変更を反映させる作業です。
addで追加してstatusで確認、commitでコミットさせる(この時コメントが書けるのでどんな変更をしたかをコメントしとく)

PUSH！

$git push origin test_branch

PUSHはローカルリポジトリの変更をリモートリポジトリへ反映させる
PUSH！

マージしよう

ブラウザからマージしちゃいましょう

ローカルを最新状態にする

$git pull

PULLはリモートリポジトリの変更をローカルリポジトリへ反映させる
これで一通り終わり！

メモ書き

ここでは不要になったブランチの削除は言及していませんが、いらなくなったブランチは適宜削除してしまいましょう。加えてSSH keyのchmodの設定にも言及してないです。ちゃんと設定したほうがいいです。
そして、恥ずかしいほど初歩的な質問をしてしまったにもかかわらず、快くご回答いただいたteratailの回答者様には深く感謝申し上げます。
基礎的な部分ほど自分で見落としがちだということに気付かされた瞬間でした。
備忘として：Permission deniedで作業ができません
又、一人で作業するには（現状は）これで十分ですが、複数人で作業する場合（本来の使い方はこっち）、もっと使いこみたくなった場合にはこれでは不十分だと思います。
今回はGITに躓かないように、ということを重視して書きました。
また迷子になったら適宜編集します。

（レポジトリ・リポジトリ表記ゆれご容赦ください…）