ブランチを間違えたとき

• 対処法：正しいブランチに修正を反映させる。

# 1. 作業していた内容を退避する。
$ git stash

# 2. 正しいブランチに切り替える。
$ git checkout [正しいブランチ名]

# 3. 退避した情報をもとに戻す。
$ git stash pop 

コミットメッセージを間違えたとき

• 正しいコミットメッセージで上書きする。

$ git commit --amend -m [修正後のコミットメッセージ]

git add し間違えたとき

• 間違えたファイルを git add する前の状態に戻す。

$ git rm --cached [間違えたファイル]

コミットを間違えた場合

• コミットを取り消す。

# 直前のコミットを間違えた場合
$ git reset --hard HEAD^
# または
$ git reset --hard @^

# n個前のコミットを間違えた場合
$ git reset --hard HEAD~n
# 3個前のコミットを間違えた場合
$ git reset --hard HEAD~3

# Working Area の修正はそのままでコミットだけ取り消す場合
$ git reset --soft

# Working Area の修正も含めて完全にコミットを取り消す場合
$ git reset --hard

• コミットした内容を打ち消すコミットを行う。

$ git revert [打ち消すコミットのハッシュ値]

Good Git Life !!

git関連メモ

Githubのアカウントは作っているものとします。
環境はUbuntuです。

ssh設定

sshとは自分のパソコン内で秘密鍵と公開鍵を生成し、github上に公開鍵を登録することでユーザー名やパスワードの入力なしに安全に自分のリポジトリを操作できるようにする通信暗号化技術です。

鍵生成

生成する場所は ~/.ssh/ です。
最も一般的なrsa暗号を使用するといいと思います。
デフォルトの暗号強度である2048bitでも十分ですが、さらなるセキュリティの強化のために4096bitにしておきます。
コメントの部分にはgithubに登録しているメールアドレスを使用するといいでしょう。

$ ssh-keygen -t rsa -b 4096 -C "mailaddress@hoge.com"
# -t 暗号化方式を指定
# -b 暗号化強度を指定
# -C コメントを設定 

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ts/.ssh/id_rsa): github_rsa # 秘密鍵の名前を指定(なんでもいい)
Enter passphrase (empty for no passphrase):  #パスフレーズを設定したい場合は入力、いらない場合はそのままEnter
Enter same passphrase again:  # 確認入力、いらない場合はそのままEnter
Your identification has been saved in github_rsa.
Your public key has been saved in github_rsa.pub.

ここで作成された github_rsa が秘密鍵で、github_rsa.pub が公開鍵です。
秘密鍵は誰にも知られてはいけません。

ssh config設定

~/.ssh 内にconfigファイルを作り、下記を追加します。

Host github
  HostName github.com
  IdentityFile ~/.ssh/github_rsa
  User git

Githubに公開鍵を設定

GithubのSettingのSSH and GPG keysでNew SSH Keyを選択します。
Titleを適当に設定して、Keyの部分に先程作った公開鍵 github_rsa.pub の中身をコピペします。
ちなみにファイルの中身をクリップボードにコピーするのはxclipを使ってできます。aptでインストールしましょう。

$cat github_rsa.pub | xclip -selection c
# -selection はコピー先を指定。cはclipboard

テスト接続

接続確認して、以下のように出ていれば成功です。

$ssh -T github
Hi user_name! You've successfully authenticated, but GitHub does not provide shell access.

localのgitにユーザー情報登録

Gitを初めて使うときは、user.nameとuser.emailを設定しないとコミットやプッシュができません。

$ git config --global user.name "Hoge Taro"
$ git config --global user.email hogetaro@example.com

これでgitを使う準備ができました。

git init

実際にソースコードをgitで管理し始めるとき、まずはgithubでリモートリポジトリを作成します。
この状態で、リモートでは一度もコミットをしていない状態です。
次に、ソースコードがあるディレクトリで次のコマンドを実行します。

$git init
$echo "# TEST" >> README.md //READMEファイルを作ります
$git add README.md //READMEファイルをadd
$git commit -m "first commit"  //READMEファイルだけをコミット
$git remote add origin git@github.com:username/repositoryname.git  //リモートを追加
$git push -u origin master //プッシュ

これで完了となります。
あとはこまめにcommitしたり、ブランチを切ったりして開発していきます。

Gitを使っていて困ったこと

commit pushしてしまったがgitignoreしたいとき

.gitignoreに書いただけではignoreされないので、

$ git rm -r --cached filename

とするとignoreすることができます。
できない理由はキャッシュにインデックスが残っているからです。

SourceTreeでグローバルで無視したファイルをやっぱりGithubにあげたい場合（macの場合）

下記のコマンドを打つと、現在グローバルで無視しているファイルの一覧が表示されます。
その一覧から、グローバルの無視を解除したいファイル名を削除します。

open ファイル名で、ファイルを開くコマンドになっています。

  $ open ~/.gitignore_global

開いたファイルを修正後、保存して閉じて少しすると、SourceTreeの差分に反映されるようになります。

設定ファイルなので、修正するときは慎重に行ってください。
こちらの作業を行ったことによる責任は一切負いかねます。

この記事を書いた経緯

またこのような事態は起こるだろうと思い、備忘録として。

はじめに

目的

最近、@daikikatsuragawa はGitやGitHubに興味があり、試行錯誤や失敗を繰り返しつつ学習しています。本記事では、試行錯誤や失敗を踏まえて学んだメモやコマンドなどを書き留めていきます。

※断り

本記事は筆者の学びに応じて更新されます?
本記事に誤りが存在した場合、積極的に編集リクエストをしてください?‍♂️

Git&GitHub備忘録

フォーク元リポジトリのブランチの更新をフォーク先リポジトリのブランチに同期させる方法

以下のコマンドを実行！

フォーク元リポジトリのブランチの更新をフォーク先リポジトリのブランチに同期させる方法

# 以下、TARGET_BRANCHの値は同期させたいブランチ名に変更してください
TARGET_BRANCH=“master”
git fetch upstream
git checkout ${TARGET_BRANCH}
git merge upstream/${TARGET_BRANCH}
git push

参考

• フォークを同期する - GitHub ヘルプ

コミットメッセージの思案

難しいですよね。以下を参考にしています。

参考

• gitにおけるコミットログ/メッセージ例文集100

オンラインIDE

Gitpodがオススメです。開発環境を用意する必要がない！対象リポジトリのGitHub（もしくはGitLab）のURLの頭にgitpod.io#を加えることで、利用可能です。

参考

• Gitpodが最強過ぎる件について - Qiita
• クラウドIDE「Gitpod」を試してみたら予想以上に使えそうだった - Qiita

remote: error: GH007: Your push would publish a private email address.

git pushを試みる時、上記のエラーが生じることがある。コミットに設定しているメールアドレスは管理画面でプライベートに設定したものだけど大丈夫？公開されてしまうよ？といった内容である。GitHubは代替のメールアドレスを用意してくれているのでそれに変更する。Email settingsにアクセスすることで、以下の記述から、代替のアドレスを取得可能である。

Primary email address
Because you have email privacy enabled, hogefuga@gmail.com will be used for account-related notifications as well as password resets. 12345678+hogefuga@users.noreply.github.com will be used for web-based Git operations, e.g., edits and merges.

この12345678+hogefuga@users.noreply.github.comを設定する必要がある。

エラー解消法

# まずは先ほどのコミットを取り消し
git reset --soft HEAD^^
# メールアドレスの設定
git config --global user.email "12345678+hogefuga@users.noreply.github.com"
# これより、コミット、プッシュなどしてもOK！

以後は設定しておくか、git config --global user.email "12345678+hogefuga@users.noreply.github.com”を実行してからコミットすると良い。

※git config --global user.emailにより、現在設定されているメールアドレスを確認可能。

変更の取り消し

諸々変更したものの、やっぱり現在コミットされている状態に戻したい、変更を取り消したいと思うことがあります。以下コマンドにはよくお世話になっています。念のため開発を始める前に一通り試すこともあります。

変更の取り消し

git checkout .

変更の取り消し（新規追加の削除）

git clean -df .

add状況の取り消し（コミットされている状態にリセット）

git reset HEAD .

プッシュ以降は諸々ややこしくなるのでオススメしない。慎重にしています。

参考

• gitでいろいろ取り消したい - Qiita

はじめに

Gitを理解するためには、その前提として「VCS」という思想を学ぶ必要があります。

この記事の対象者

• Gitを理解する準備がしたい人
• 駆け出しエンジニア

なぜこの記事を書いたのか

駆け出しエンジニアの頃にVCS入門で勉強した時のメモを発見したので供養です。

VCSの意義

VCSの能力は、主に次の2つです。

• 履歴を残す
• 作業の競合を防ぐ

履歴を残す

履歴が残ると何ができるのか。大まかには次の3つができるようになります。

• 履歴を残す
  • 参照
  • 再現
  • 分岐

参照

履歴をたどることで、誰がいつ何をやったかを確認することができます.
一般的なVCSでは履歴の検索機能もありますので、簡単に対象となる履歴を参照することができます。

再現

VCSを使うと、履歴を参照するだけでなく、その時点の状態を再現することも可能です。つまり、動かなくなったとしても正常に動作していた状態に巻き戻せる、ということです。

分岐

過去の状態を再現した上で、そこから別の変更を加えることで、履歴を分岐することもできます。つまり、複数のアプローチにより、作業を行うことができるということです。

作業の競合を防ぐ

VCSのもう一つの大きな機能が、「作業の競合を防ぐ」です。VCSを使うことで、誰かが先に変更していればそのことを検知し、VCSが競合箇所を知らせてくれます
また、使うVCSによっては、ファイル内の変更箇所を解析し、自動的に自分が行った変更内容と統合（マージ）する機能を持っています。この機能を活用することで、他のメンバーと効率よく並行して作業を進めることができるようになります。

VCSの限界

1. 「とりあえず」反映している
2. 「どうやったのか」をメッセージに書いている
3. 動かないものも反映している
4. 複数の変更を盛り込んでいる

⇨VCSは便利ですが、あくまでツールです。ツールは人の作業を補助はしてくれますが、それだけではうまくいきません。ましてやシステム開発はチームで行うものです。2人以上がコミュニケーションを取るには、最低限のルールが必要です。

このことを言い換えると、VCSはルールと対になって初めてその真価を発揮する
守るべきルールが見えてきます。それが次のルールです。

• 「時間」ではなく「作業」の単位で行う
• 「どのように」ではなく、その作業を「何故」「何を」「何のために」行うかをメッセージに残す
• 動かない成果物はリポジトリに反映しない
• 一度に一つの変更だけ反映する

「一言で何をやるのか表せる単位で作業を区切って、リポジトリに反映する」ことが重要です。一言で表せないのならば、それは行おうとしている作業が大きすぎるのです。こんなときは、より小さな単位に分けて作業を行えないか考えてみましょう。

SCMという智慧

VCSがない状態では、次の問題がありました。

• 作業履歴が残らない
• 他の人と作業がぶつかる

また、VCSを導入した後、ルールが無ければこんな問題がありました。

• 履歴から目的の変更を探せない
• 履歴の一つが、どういったきっかけで変更されたかわからない

以上の問題から、VCSを使って行いたかった事とは、

• 各バージョンを識別したい
• 特定のバージョンを再現したい
• 何故変更が行われたのか知りたい
• 他の人と連携して作業を行いたい

ともいえると思います。

これらを実現するための考え方が「SCM（Software Configuration Management、ソフトウェア構成管理）」です。
- Software : ソフトウェア
- Configuration : 構成
- Management : 管理
「ソフトウェア構成」とは「ソフトウェアというまとまりがどのような要素の組み合わせでできているか」

ある時点でのソフトウェアを構成する要素すべてを、識別、再現、追跡出来るようメンバー間で成果物を共有し、連携を促すための仕組み、ルール、プロセスを構築し、運用する
SCMでやりたいことを今一度まとめると、仕様変更、バグなどをトリガーとした「変更依頼」で発生した、ソフトウェア構成の変更履歴について、

• 識別
• 参照
• 再現 が出来なくてはなりません。

このことから、VCSを使う際には次のことを意識する必要があります。

• ソースコード以外も管理する
• 履歴を識別するメタデータを付加する
• 「タグ」を活用する

SCMの次のステップ

SCMは「変更依頼」の管理も含めてSCMである、と説明してきました。主な変更依頼のトリガーとしては、「バグ」、「仕様変更」等があります。

そこで、変更依頼を管理するためのツールの出番です。こういったツールは一般的に「ITS（Issue Tracking System、課題管理システム）」と呼ばれます。

ITSでは、Issue（課題）を「Ticket（チケット）」という単位で登録します。このチケットには一意となる番号（チケット番号）が振られ、担当者を割り当てたり、関連する内容をコメントしたりする機能があり、課題を完了したらチケットを「閉じる（クローズする）」決まりになっています。

これにより、今残っている課題、終わった課題、誰が担当しているかなどが明確になり、管理が容易になります。

参考文献

VCS入門
Github上で無償公開されています。本当に素晴らしい資料です。

Gitをはじめからていねいに
こちらもGithub上で無償公開されています。本当に素晴らしい資料です

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ
こちらは書籍ですが、Kindle Unlimitedで0円で利用できます。基礎から丁寧に理解するには先に紹介した2つが最良ですが、実際の開発業務でGithubを利用するようになってから本書をパラパラめくると新たらしい発見がありました。余談ですが、エンジニアならkindle端末は一台手元に持っておくと何かと便利です。

railsで作成したアプリをBitbucketに一番初めに保存するときにわからないことがあったためメモしておきます。

・cloud9(aws)環境で実施
・アカウント作成は省略

公開鍵の作成

console

cat ~/.ssh/id_rsa.pub

上記のコマンド入力で公開鍵を所持しているか確認できます。所持していない場合にはNo such file or directoryと表示されます。
鍵を所持していない場合は

console

cd ~/.ssh　#sshフォルダに移動
ssh-keygen -t rsa -C saber@example.com  # 自分のメールアドレス入力

Entキー押すと色々と出てくるが特にいじる必要ないのでそのままEntキー何回か押して鍵を作成。鍵を作成した後に先ほどの

console

cat ~/.ssh/id_rsa.pub

を実行して鍵を表示させます。

公開鍵の追加

bitbucketにログイン後、
ユーザーアイコン
　　↓
Bitbucket setting
　　↓
セキュリティー
　　↓
SSH鍵
　　↓
鍵追加
　　↓
さきほど表示した鍵をコピペ
　　↓
作成
これで完了です。

bitbucketへリポジトリ作成

＋アイコンを押し、空のリポジトリを作成します。リポジトリ名はなんでも大丈夫せす（わかりやすくするなら自身のアプリケーション名が良いかと）。
bitbucketにリポジトリを作成するとバケツに何かを入れましょうというページに移動しgit remote add origin git@bitbucket.org:ユーザー名/先ほど作成したリポジトリ名.gitとgit push -u origin masterいうコマンドが表示されます。このコードそのまま入力してもいいのですが、まだ自身の環境にリポジトリを作成していない場合は

console

git init （自身の環境の新しいリポジトリの初期化）

ちなみにawsのcloud9の場合はgit導入済みのためこのコマンドが最初から使用できます。

console

git add -A
git commit -m "メッセージ"

上記のコマンド実行し、自身のgitにリポジトリを作成したあとは先ほどのgit remote add origin git@bitbucket.org:ユーザー名/作成したリポジトリ名.gitとgit push -u origin masterいうコマンドを実行します。

console

git remote add origin git@bitbucket.org:ユーザー名/先ほど作成したリポジトリ名.git
git push -u origin master

これでBitbucketに内容が反映されます。

あとがき

自分なりにわかりやすいよう書いてみましたがわかりにくかったらすみません。
参考になれば幸いです。

はじめに

2020年3月30日。
僕はプルリクを出した際に、本来の修正箇所と全く関係ない

「インデント直してー」
「ここのスペースいらないよー
「console.log消しといてー」

などのミスを連発してしまいレビュアーの方に大変負担をかけてしまいました。
そこで原因を探って行った所、本来みんなが踏んでいるプルリクを出すまでのチェック項目を踏んでいなかった為、ミスを連発していることが発覚しました。

本記事は今後、僕がケアレスなミスをなくす為にプルリクを出す前に確認するチェックリストです。
「自分はこうやってるよー」などのより良いやり方があったら教えていただけると幸いです。

前提

「チーム単位でフォーマッターなどを導入して仕組みで解決する」事が優先されるべきです。
可能であればチームに対して進言し、より良い仕組みの導入を検討してください。
フォーマッターについて知る上で、個人的にはこちらの記事が参考になりました。
https://wemo.tech/3307

その上で、フォーマッターを導入していないチームの中で、個人の裁量での対処法が本記事になります。

1 作業が終わったらdiff(変更差分)を開く！

これは大前提でやりましょう。
これやってないと、「絶対やろうね?」的な反応になります。

自分はvscodeを使っているので、その方法を。

①左端のバーからソース管理を選択
②差分があるファイルが表示されるので、1つずつクリックしてdiffを開く
③diffが表示されるので確認する

左の赤いラインが変更前の箇所
右の緑の箇所が変更後の箇所　になってます。

2 diffファイルと睨めっこしてケアレスミスをなくす

diffファイルを開けたら左右で睨めっこしてミスがないか、確認していきます。
この段階で意識してチェックする事柄をまとめておきます。

①まずインデントはズレていないか

インデントがズレていると、それだけでプルリクのレビューが終了してしまう恐れがあります。
フォーマッターを入れていると、自動補完で気づかない間にズラしてしまう、なんてこともあり得るので個人的にはフォーマッターは切っておくことをお薦めします。

また、コピペしたときにもインデントがよくズレます！
先輩等にslackで相談して、ソースをそのまま持ってきている時などは、気をつけましょう。

②変なところにスペースが入っていないか

スペースはdiffファイルで半透明で表示されるので、検知は難しくないです。
これまた自動補完なのか、コードをいじった挙句の弊害なのか、よく残ってしまう事があります。

多くの場合、スペースは必要ないので、いらないと思ったら消しましょう。

③そのconsole.log必要？？

console.logやvar_dumpなどは手元で開発しているときによく使うと思います。
テスト用に書いたものの消し忘れに注意しましょう。

④その改行必要？？

改行も個人でやっている時に色々いじってしまっている事があります。
必要な改行なのか、コードをごっそり消した際に残った物なのかを判断して要らなければ消しましょう。

ここまでやって問題なければ、プルリクを出しましょう

3 プルリクを出したら、レビュアーを指定せず最終チェックしよう

プルリクを出した後にすぐにレビュアーを指定してレビューしてもらうのではなく、
自分がレビュアー1人目になった感覚で最終チェックしましょう。

githubで見ると、さっき気が付けなかったミスが見つかるかも知れません！！
これで問題ない！って思ったらレビュアーを指定してレビューを受けましょう。

まとめ

今回の記事は「ケアレスミスに対して全く対処していない→最低限これだけはやろう！」までをまとめた内容になっているので、ほとんどの人にとっては当たり前すぎる内容かと思います。

「もっとここを意識すると良いよー」的な内容があれば教えていただけると幸いです。

問題

githubでPull Requestをする際に、差分ファイルを確認すると、2982と表示されていた。明らかに管理するべきではないものがpushされてしまっている。

　

原因

こちらのFilterFileTypesで確認すると、jpgが多いことがわかった。

ディレクトリから確認していくと、

　public/uploads/

の内容が原因であることがわかった。

解決

$ git rm --force -r public/uploads/*

こちらで、削除することができ、

.gitignoreに

　public/uploads/*

を追加すると、以降addされなくなった。

結果、

と差分を一気に少なくすることができた。

終わりに

転職の為、未経験の状態からRailsを学習しております。正しい知識を着実に身に着け、実力のあるエンジニアになりたいと考えています。継続して投稿していく中で、その為のインプットも必然的に増え、成長に繋がるかと考えています。
今現在、初心者だからといって言い訳はできないですが、投稿の内容に間違っているところや、付け加えるべきところが多々あるかと思いますので、ご指摘頂けると幸いです。この記事を読んで下さりありがとうございます。