今さら聞けないGit　2020年10月07日

mac OSのアップデート後、gitとhomebrewが使えなくなった

##経緯
macOSをアップデートしたら、何故かgitコマンドが使えなくなった！
エラー内容はこんな感じ。

“`
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
“`

エラーメッセージのみでは解決法がわからなかったのでgoogleで検索。
すると、同じようなエラーにハマっている人が何人もいた。

## 解決フロー

調べてみると、command line tools for xcodeのインストールが必要らしい。
以下のコマンドでインストール。

“`
xcode-select –install
“`

しかし、以下のエラーが発生。

![スクリーンショット 2020-10-07 11.33.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/

Gitのコンフリクトを正しく恐れる

# 前置き
誰かが言ってました。
「正しく恐れよ、恐れ自体それが恐れなのである」

# コンフリクトが発生するということ
（間違い）ソースの同じところを触ったからですね
（正しい）仕様の競合が起きているからですね

# コンフリクトを解消するためのマージ作業
（間違い）ソースをマージしましょう
（正しい）仕様をマージしましょう

# 競合の恐怖
(間違い)　コンフリクトが起きないように事前にお互いにソースを把握して気を付けよう
(正しく)　コンフリクトが起きないように事前にお互いに仕様を把握して気を付けよう

# ソースの競合と仕様の競合の関係
（間違い）仕様が競合していれば、ソースが競合している
（正しい）ソースが競合していると、仕様が競合している

# プルリクで競合が起きていない
（間違い）よかった特に問題ないですね。
（正しい）もしかしたら漏れがある可能性があるので仕様をきちんと確認する。

# あとがき
コンフリクトを恐れるあまり、
誰かの手を止めることのないようにしてほしいという思いです。

GitHubでフォーク元の変化を取り込む

GitHubで共同開発をしていると、フォークしてから作業をするという形で作業することが多くなるかと思います。

その際、フォーク元のリポジトリに差分が生じてしまうと“`git pull“`では差分を取り込むことができません。

そこで今回はフォーク元の差分を自身のリポジトリに反映させる方法を書きます。

# 手順
まずは正しくupstream先が登録されているか確認します。

“`
$ git remote -v
origin git@github:private/hoge.git (fetch)
origin git@github:private/hoge.git (push)
upstream git@github:work/hoge.git (fetch)
upstream git@github:work/hoge.git (push)
“`

もしupstream先を登録できていない場合は下記コマンドで登録します。

“`
$ git remote add upstream git@github:work/hoge.git
“`

後はupstream先の最新をfe

Gitのローカルリポジトリをmasterからmainに変更する方法

# はじめに
GitHubのデフォルトブランチがmasterからmainに変更されました。
理由等は以下の記事を参考にしてもらえるとmainに変更された理由がわかります。

[GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更 － Publickey](https://www.publickey1.jp/blog/20/githubmainmastermain.html)

これに準じて、ローカルリポジトリもmasterからmainに変更したほうがいいなと感じることがあります。
例えば、masterのままでいると、first commitでリモートのmainブランチに直プッシュをしたくてもリモートにmainブランチを作成してからプルリクエストを出してマージする手順が必要になります。

これを続けているとかなり面倒くさいです。ですが、ローカルリポジトリのデフォルトブランチをmasterからmainに変更することで面倒くささがなくなり、mainのリポジトリに直プッシュできます。

以下で、デフォルトブランチをmasterか

自動デプロイで目指す効率的な開発

# 問題点
– 開発を始めるまでが大変（新規メンバー、3ヶ月後の自分）
– アップロードが衝突する（開発用サーバ）
– 先祖返り（デグレード）
– Issueベースでタスクを振りたい
– バグが起きた時点を知りたい

—

# デプロイで解決
– 開発を始めるまで
– Gitさえ分かればデプロイされる
– アップロード衝突
– Gitのブランチで独立

—

# デプロイで解決
– 先祖返り（デグレード）
– 手動アップロードからの解放
– タスクベースでタスクを振りたい
– GitのIssueとPR、デプロイの紐付け
– バグ発生時
– リリースをそれぞれデプロイ

—

# 開発を始めるまで
– 新規メンバーに環境を揃えてもらいたい
– 修正箇所は検討がつくのに整備が大変
– 3ヶ月前のコードがわからない
– 3年前のコードは全然分からない?

– 自動デプロイ?
– Gitさえコミットできればデプロイされる
– 一部のロジックに注力できる

—

# アップロード衝突
– 同時に開発環境を使うことができない
– 「作業を止めてもらっ

覚えておきたいコマンドたち

##はじめに

開発するうえで覚えておきたいコマンドたちをまとめていきます。随時更新します。
初心者の覚え書きです。
あまり書きすぎても身につかないので、使ったことのあるものを書いていきます。

##Git

* git clone <コピーしたいリポジトリのURL>
* git リポジトリを自分のPCにコピーする

* git branch <ブランチ名>
* 新たなブランチを作成

* git branch -d <削除したいブランチ名>
* 指定したブランチを削除

* git switch <切り替えたいブランチ名>
* 指定したブランチに切り替える

* git push origin <ローカルブランチ名>
* ローカルリポ

Github で採用するFlowについてのメモ

[Git利用時のフローはどれを使うか – Qiita](https://qiita.com/tkhm/items/cc7855d32d640687b43c)

[Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた – Qiita](https://qiita.com/TsuyoshiUshio@github/items/51c6662cd45bded95389)

[GitLab flowから学ぶワークフローの実践 | POSTD](https://postd.cc/gitlab-flow/)

[2019年のDevOps/MLOpsエンジニアの標準的スキルセット – Qiita](https://qiita.com/poly_soft/items/8dd105341869f93b129c#git%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%83%A2%E3%83%87%E3%83%AB%E3%81%AE%E9%81%A9%E5%88%87%E3%81%AA%E8%A8%AD%E8%A8%88%E3%

Git config設定(global)

global:プロジェクトをまたいだ全体の設定
# 現在の状態を確認
“`
$ git config -l
“`

# ユーザ名の設定
“`
$ git config –global user.name “ユーザ名”
“`

# メールアドレスの設定
“`
$ git config –global user.email メールアドレス
“`

【参考】Git 作業 commitの名前の付け方

# Git作業について
色々現場の決め方などをどのように採用しているのかいくつか紹介していきましょう

### シンプル

ブランチ作業されている方に現場での作業の際にみんなに何の作業をしたのか変更をしたのかというのをcommit履歴を残すといいですね。

シンプルな方法は以下の通りになります

commitの際に

コミットする際は、最初は、「【画面名or機能名】画面名or機能名新規作成」
次回以降は

「【画面名もしくは機能名】変更内容の概要・・・（ここは何をしたのかを書いてもらえたら）」
という感じにしてもらってもいいですか？

例
「【新規登録画面】新規作成」
「【お客様画面】機能拡張」
「【お客様画面】バグ：表示が出ない問題の対応」

### 職場のチケット制を採用している場合

現場によっては、チケットというタスク管理ではよく使われているのですが、新しいチケットを発行した際にこちらを採用している場合があります。

チケット管理で対応している現場の主な方法は以下の通りになります

commitの際に

コミットする際は、最初は、「【画面名or機能名】チケットタイトル#チケット

git lfs を使用していてファイルが不完全状態で復元される場合

git lfs を使用していて checkout のコマンドでFloder内にある削除したファイルが復元しない場合
下記のコマンドを試す

“`
git lfs checkout Floder
“`

ファイルがlfsで管理されているかを確認する場合は下記のコマンドで確認

“`
git lfs ls-files
“`

git メモ書き

git reset –hard origin/dev-cai　　強制pull local上書き
git push –set-upstream origin dev-test
git log –name-status
git stash apply stash@{0}
git checkout -b fix/#RPO-10 origin/dev
git log –merge –decorate –source -p　src/…/
git branch -d 　　localブランチ削除
git push –delete origin branch_name　– remote ブランチ削除
git checkout -b issue/#RPO-36 origin/dev

GIT MP4 壊れる

## 現象

git でファイルを保存して、
違う場所でpull　した時にデータ壊れてしまう

## 対応

.gitattributes
に
*.mp4 binary
追加

OS Catalinaにアップデートした際に、Gitがつかえなくなった

## mojaveからCatalinaへ
いつも無視していたが誕生日も来たことだしOSアップデートするかと思い2020/10/04にOSのアップデートを行いました。

Gitが動かない…
下記のようなエラーが表示されました。

“`
$ git fetch
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
“`

## xcode-select –install
他の方のQiitaやブログを読むと下記コマンドで直る方もいるそうです。

“`
$ xcode-select –install
“`

参考
> [macOS CatalinaにしたらGitコマンドが動かなくなった](https://qiita.com/n0bisuke/items/3aebc4ab635030119f6c)

## 上記コマンドでエラーが出た

EC2 Webサーバー構築

# EC2サーバー構築共通
## 概要
AWSのEC2を利用して、Webサーバーを構築したときの手順をご紹介します。

## 環境
– nginx 1.16.1
– PHP 7.4.3
– git 2.23.1

## 手順
### 1. システム
“`bash
# yumのパッケージ更新
$ sudo yum update

# タイムゾーン確認
$ timedatectl status

# タイムゾーンを日本時間に設定
$ sudo timedatectl set-timezone Asia/Tokyo

# ロケール確認
$ localectl status

# ロケール変更
$ sudo localectl set-locale LANG=ja_JP.UTF-8
“`

### 2. ニックネーム設定

ホスト名に影響を与えずにシェルプロンプトを変更する
[参考](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/set-hostname.html#set-hostname-shell)

1. 環境変数

Gitの使い方

#前提条件

– GitHubに既にレポジトリを作成済み
– “first commit”は実施済み
– PCにgitがインストールされている

#手順

1. ステージングする
2. コミットする
3. プッシュする

##ステージングする

例えば、ファイルを更新した場合、以下のようにステージングします。

“`bash
git add style.css
“`

更新したものを忘れてしまったときは、以下で確認できます。

“`bash
git status
“`
表示例：

“`bash
On branch master
Your branch is up to date with ‘origin/master’.

Changes to be committed:
(use “git restore –staged …” to unstage)
modified: style.css
“`

##コミットする

ファイルを変更した後は、コミットします。必ずコメントをつけて変更内容がわかるようにします。

“`bas

Git 2.27 での git pull 時の warning について

## 概要

今更ですが、いつぞや Git のバージョンを上げた後、 `git pull` したときに、以下の warning が出るようになりました。

“`
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

git config pull.rebase false # merge (the default strategy)
git config pull.rebase true # rebase
git config pull.ff only # fast-forward only

You can replace “git config” with “git config –global” to set a defau

新しくインストールしたOSから、GitHubにアクセスできるようにするまでにすること

# はじめに

新しく導入した OS で GitHub を使うには、GitHub に SSH の登録が必要になります。

今回は SSH を使って GitHub 上のリポジトリにアクセスできるようにします。

# 手順

## 1. git が入っているか確認

Ubuntu に git が入っているか確認します。（たぶんデフォルトで入っている）

“`
$ git –version
“`

なければインストールします。

## 2. 公開鍵を生成

Ubuntu 側に下記コマンドを入力して公開鍵を生成します。

“`
$ ssh-keygen -t rsa
“`

以下のように出力されます。
鍵の保存先を設定できますが、特に事情がなければそのまま Enter を押下してよいです。

“`
Generating public/private rsa key pair.
Enter file in which to save the key (/home/%USERNAME%/.ssh/id_rsa):
“`

以下のように出力されます。
パスフレーズを設定できます。
その

EC2 などの Linux に git をインストールする方法

備忘のために Linux に git をインストールする方法をメモ

まずは各種パッケージをアップデート

“`
$ sudo yum update -y
“`

それから git をインストール（簡単）

“`
$ sudo yum install git -y
“`

インストールできていることを確認します。

“`
$ git version
git version 2.23.3
“`

【GitHub Tips】プルリクエストをcheckoutする

# はじめに
みなさん、GitHubでプルリクエストのコミット内容をcheckoutするとき、どのような方法でされていますか？
特にforkを多用する文化でブランチをcheckoutしようと思うと、ブランチはfork先のリポジトリにしか上がっていないため、remoteとしてfork先を登録してからcheckoutする必要があり面倒くさいですよね。
そこで、お使いの方も多いと思いますが、fork先を気にせずプルリクエストの内容をcheckoutする方法をまとめておきたいと思います。

# プルリクエストをcheckoutする方法
## 方法1
この場合、チェックアウトをした後に`detached HEAD`状態になります。
つまり、HEADがブランチ以外のコミットオブジェクト(ポインタ)を指している状態になります。
この方法ではブランチが新規に作成されないので、`git log`で差分を確認したりするだけの場合、非常に有用です。

“`bash
git fetch origin pull//head
git checkout FETCH_HEAD
“`
## 方法1

gitコマンド_備忘録(自分用)

LINEbot作成時にゴリゴリ躓いたので(‘ω’)
自分なりにgitコマンドを理解する。。
(備忘録程度に残すだけ)

~~モジュール作成後にgit init → git add . → git commit -m ~ → git push heroku master~~
~~みたいな呪文を唱えなければアプリケーションがデプロイできないらしく~~
~~自分自身、gitを殆ど理解しないまま何となくで作業を進めてしまっていた….~~

**◇前提**
Git→リポジトリのこと(ソースコードのデータベース)

**◇構造**
編集者
↓
ワークツリー
↓↑
インデックス
↓↑
ローカルリポジトリ(各PC上にあるDB)
↓↑
リモートリポジトリ(サーバ上のバックアップDB)(Github)

**◇コマンド一覧**
`git commit -m “コメント”` #インデックスの内容をコミットログとして保存
`git remote a