はじめに

こんにちは！ベンチャー企業でソフトウェア開発をしている加納です！

意欲が高く一人で勉強されている初心者プログラマの方はGitの存在を知ってるかもしれません。Progateにも詳しい手順が解説されていたりしますよね！

実務経験がない状態だと（僕もそうだったのですが）『なぜGitでブランチを使うのか』と思うことがあると思います。今回はその理由を図を用いてわかりやすく解説いたします！

この記事を読んで得られること

Gitのブランチを用いた開発の良さを知って頂ければと思います。

本題：『なぜGitでブランチを使うのか』

結論から言いますと、『ブランチを使わない開発は危険すぎるから』です。

具体的にブランチを使わず開発をしている危険性を見ていきましょう。

上の図のように本番環境だけで開発をしているとします。何が起こってしまうでしょうか。

このように直で本番環境のコードを書き直したり、付け足したりしていると突然システムが機能しなくなってしまうこともあるのです。正直めちゃめちゃ焦ります。何を変更したんだっけと全て忘れてしまうかもしれないです（僕はそうです）

もちろんバックアップをとっておいたら良いのですが毎回コードを少し変えるたびにバックアップを取っていると無限に不要なフォルダができてしまうかもしれません。

そこでブランチを使うのです！！

ブランチの素晴らしさ

以下がブランチを用いて作業をした時の図です。

先ほどまでは[開発段階2]から[開発段階3]を直で変更していましたが、ブランチを使うとどうでしょう。

最低でも「開発用」、「テスト用」、「本番用」ブランチを用意して開発をすることで、[開発段階2]のコードはそのままにして、そのクローンをこまめに開発することができるのです！

開発中にバグが発生しても問題ありません。元のブランチを参照することですぐにバグが発生する前のコードに戻れるのです。

本番用ブランチで動作を確認し終えたのなら、[開発段階2]と[本番用ブランチ]をマージして終了となります。

最後に

最後まで読んでいただきありがとうございました。
一人で開発をしている方や、友達と開発をしている方！ぜひブランチを使って安全で快適なエンジニアライフをどうぞ！！

Gitのブランチの必要性を教えていただいた大先輩エンジニアの青木さんに感謝致します。

関連記事

・具体的なブランチの構成について知りたい
→いまさらだけどGitを基本から分かりやすくまとめてみた

・効率的に優秀なプログラマになる方法を知りたい
→ハッキングを学ぼう-日本語訳

なんか毎度バージョン更新の手順が思い出せなくなるので、備忘録。

注意点： 開発時には、ローカルdevelopブランチのpackage.jsonのバージョンは変更しないこと！（これをいつも忘れるから面倒になる）

ローカル作業中のdevelopブランチをmasterへマージ:

$ git add .
$ git commit -m "Modified by some enhancements and fixed bugs"
$ git checkout master
$ git pull origin master
$ git merge develop

で、プロジェクトのバージョンを更新して、npmパッケージを更新:

$ npm version minor
$ git tag
$ git push origin tags/{TagName}
$ npm publish ./

これで完了。

もし、package.jsonのバージョン番号を手動で書き換えたりしてて、バージョンtagが飛び石になってしまったら、コミットを取り消し、タグを消してから、package.jsonのバージョンを元に戻す。そしたら、npmコマンドをやり直す。

$ git log -2
$ git reset --hard {CommitHash}
$ git tag -d {TagName}

最後に、developブランチを最新masterに追従させておく。

$ git checkout develop
$ git merge origin master
$ git push origin develop

以上。

「Githubはなんとなくわかるけど、Xcodeで作ったアプリを
　Githubにpushするにはどうしたらいいの？」
という方向けに、XcodeならではのGithubの使い方をまとめました！

動作環境

Xcode Version 11.3.1

目次

・Xcodeでローカルリポジトリを作成
・(既存のプロジェクトでローカルリポジトリを作成する方法)
・commitする
・Xcodeでリモートリポジトリを作成
・pushする
・テスト用に作ったリモートリポジトリを消したい！

Xcodeでローカルリポジトリを作成

①プロジェクトを作成

②「Create Git repository on my Mac」にチェックして、ローカルリポジトリを作成。
そしてCreate

③ローカルリポジトリができているかチェック

masterをクリックすると、コミットの履歴が確認できます。

(既存のプロジェクトでローカルリポジトリを作成する方法)

①上部の"Source Control"→"Create Git Repositories..."をクリックして作成

コミットする

まずは、何か編集をしてみてください。
そうすると、下記のように編集ファイルの右にMマークが付いていると思います。
これが、編集されてからまだコミットされていないしるしになります。

次に、そのMマークのついたファイルを右クリック
→"Source Controll"→"Commit "ViewController swift"..."
をクリック。

すると、コミット画面が表示されます。
コメントを加えて右下の"Commit 1 File"をクリック

確認してみましょう！

このコミットをダブルクリックすると、

このように、どこが編集されたのか丸わかりです！！

Xcodeでリモートリポジトリを作成

"Xcode"→"Preferences..."をクリック

すると、このような画面が出るので、GithubのアカウントからSSHを取得して接続してください。

上記の接続ができたら、
"Remotes"→"Create "プロジェクト名" Remote..."をクリック

アカウントを設定してCreate

このように、originがあれば無事作成されています！

実際にGithubを見て、確認してみましょう

こちらに作成されていますね！

pushする

それでは、またファイルを編集してみましょう。

すると、履歴が一つ増えていますね。

では、こちらをpushします！
"Source Control"→"Push..."をクリック

"Push"をクリック

無事pushができました！

テスト用に作ったリモートリポジトリを消したい！

テスト用に作ったけど、邪魔だから消したい場合は、
作成したリモートリポジトリをクリック

"Setting"をクリック

一番下にある、"Delete this repository"をクリック
※押す前に本当に間違いないか確認してくださいね！！

上記の太字を入力
→今回は"y-aimi/GithubTest"を入力

Githubのパスワードを入力

無事削除されました！

TL;DR

• フロント・バックエンドサービスをそれぞれコンテナ化、docker-composeで全てのコンテナを管理する
• monorepoで管理した際に1リポジトリとなるので気軽にGit Hookの処理ができない
• Lefthookを導入してpre-commit時にすべてのコンテナに対してLintツールを動作させるようにした

サンプルコード

https://github.com/MegaBlackLabel/lefthook-docker-node-go-dev-sample

1リポジトリで開発環境を管理したい

渋川さんの記事

マイクロサービスほどじゃないけどウェブサービスを分割開発したい人向けDocker設定を集めるスレ
https://qiita.com/shibukawa/items/fd49f98736045789ffc3

を読んでフロントエンドとAPIがごっちゃになっている開発環境ヨクナイ！ってことでサービス単位でコンテナ化してvs codeのリモートコンテナ機能を使って開発環境を再構築をしていたらGitとGItHooksの扱いで躓く。

Git Hooksの扱い

1リポジトリでサービスをコンテナ化してmonorepoを構築した際に.gitはルートディレクトリのみに存在する。
何が起こるかというと、フロントエンド開発時に「Husky+lint-stagedでコミット前にeslintやprettierを実行してコミット前にソースをチェックする」ができなくなります。これは治安が悪くなるってことで調査を進めた結果、試してみたのがLefthookです。

Lefthookを使ってみる

Lefthookとは？ということで公式の説明を引用

The fastest polyglot Git hooks manager out there

Fast and powerful Git hooks manager for Node.js, Ruby or any other type of projects.

• Fast. It is written in Go. Can run commands in parallel.
• Powerful. With a few lines in the config you can check only the changed files on pre-push hook.
• Simple. It is single dependency-free binary which can work in any environment.

• GO製。コマンドを並列実行できる
• かんたんな設定ファイルでpre-pushのhookが使えるようになる
• (GOによる)シングルバイナリなので、どのOSでも実行可能

今回は以下のことを実装しました。

• 起動時にdocker-composeでインスタンス起動
• 起動したインスタンスに対してコマンドを実施
• 更新対象のファイルの拡張子をgrepして対象の拡張子がstageにあるときのみ実行する

※、余談ですが日本語での紹介記事は2つのみ。1つは公式の翻訳ともう一つはRubyでのHusky置き換え記事です。

Lefthook: 多機能GItフックマネージャ
https://techracho.bpsinc.jp/hachi8833/2019_10_16/79052

Git HooksマネージャーのLefthookを試してHusky(+lint-staged)と比較した結果、乗りかえました
https://blog.solunita.net/posts/change-lefthook-instead-of-lintstaged-with-husky/

Lefthookインストール

Lefthookインストールですが、公式サイトのInstallationか、リリースページから直接ダウンロードします。自分はWindows環境なのでプロジェクト内にlefthook.exeをそのまま置いて使っています。
インストール後に対象のリポジトリで以下のコマンドを実行

lefthook install　#Windowsで直下に置いている場合は lefthook.exe install

インストールが完了するとリポジトリのルートに「lefthook.yml」が作成されますので、こちらに設定を書きます。

Lefthook設定ファイル解説

lefthook.yml

# EXAMPLE USAGE
# Refer for explanation to following link:
# https://github.com/Arkweid/lefthook/blob/master/docs/full_guide.md
#
# pre-push:
#   commands:
#     packages-audit:
#       tags: frontend security
#       run: yarn audit
#     gems-audit:
#       tags: backend security
#       run: bundle audit
#
# pre-commit:
#   parallel: true
#   commands:
#     eslint:
#       glob: "*.{js,ts}"
#       run: yarn eslint {staged_files}
#     rubocop:
#       tags: backend style
#       glob: "*.rb"
#       exclude: "application.rb|routes.rb"
#       run: bundle exec rubocop --force-exclusion {all_files}
#     govet:
#       tags: backend style
#       files: git ls-files -m
#       glob: "*.go"
#       run: go vet {files}
#   scripts:
#     "hello.js":
#       runner: node
#     "any.go":
#       runner: go run

pre-commit:
    piped: true
    commands:
        1_docker-compose:
            root: .
            run: docker-compose up -d
        2_eslint:
            root: "containers/frontend/"
            glob: "*.{js,jsx,ts}"
            run: docker exec -it frontend-container yarn eslint-check
        3_frontend-test:
            root: "containers/frontend/"
            glob: "*.{js,jsx,ts}"
            run: docker exec -it frontend-container yarn test
        4_api-test:
            root: "containers/api/"
            run: docker exec -it api-container go test

サンプルとインデントの数が違うのはご愛嬌。今回使っている処理は以下の通り。

• pre-commit： コミット実施前に実行してほしい処理
• piped：commandsを名前順に実施する。そのため頭文字に数字をつける
• commands：実行するコマンド
• root：どの階層でコマンドを実施するかを記載
• glob：stagedのファイルのうち、コマンド実行対象とするファイルを選別する
• run：実行するコマンド

コマンドの内容ですが以下の処理を実施しています。

• docker-composeでコンテナを起動
• docker execを使用してフロントエンドコンテナでeslint+Prettierを実施
• docker execを使用してフロントエンドコンテナでテストを実施
• docker execを使用してAPIコンテナでテストを実施

フォルダ・ファイル構成

以下の想定でファイル構成を行っています。
- フロントエンドとAPIサーバをそれぞれコンテナ化して管理
- docker-composeでコンテナを一元管理
- フロントエンドではeslint+Prettierでのソース整形とテストを実施
- APIサーバではテストを実施
- それぞれ正常に実行時のみコミットを実施する

ファイル構成

lefthook-docker-node-go-dev-sample
│  .gitignore
│  docker-compose.yml
│  lefthook.exe
│  lefthook.yml
│  LICENSE
│  README.md
│
└─containers
    ├─api
    │      docker-entrypoint.sh
    │      Dockerfile
    │      go.mod
    │      go.sum
    │      main.go
    │      main_test.go
    │
    └─frontend
        │  .eslintrc.json
        │  docker-entrypoint.sh
        │  Dockerfile
        │  package.json
        │  README.md
        │  yarn.lock
        │
        ├─node_modules
        ├─public
        │      favicon.ico
        │      index.html
        │      logo192.png
        │      logo512.png
        │      manifest.json
        │      robots.txt
        │
        └─src
                App.css
                App.js
                App.test.js
                index.css
                index.js
                logo.svg
                serviceWorker.js
                setupTests.js

Lefthookでpre-commit時にコンテナに対してコマンド実行

pre-commitをrunしてみる。

実行結果

.\lefthook.exe run pre-commit
RUNNING HOOKS GROUP: pre-commit

  EXECUTE > 1_docker-compose
api-container is up-to-date
frontend-container is up-to-date

  EXECUTE > 2_eslint
yarn run v1.22.4
$ eslint --print-config .eslintrc.json | eslint-config-prettier-check
No rules that are unnecessary or conflict with Prettier were found.
Done in 0.69s.

  EXECUTE > 3_frontend-test
yarn run v1.22.4
$ CI=true react-scripts test
PASS src/App.test.js
  ✓ renders learn react link (39ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.081s
Ran all test suites.
Done in 3.23s.

  EXECUTE > 4_api-test
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:   export GIN_MODE=release
 - using code:  gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /ping                     --> github.com/MegaBlackLabel/lefthook-docker-node-go-dev-sample.setupRouter.func1 (3 handlers)
[GIN] 2020/03/15 - 03:43:28 | 200 |      44.742µs |                 | GET      /ping
PASS
ok      github.com/MegaBlackLabel/lefthook-docker-node-go-dev-sample    0.014s

SUMMARY: (done in 7.78 seconds)
✔️  1_docker-compose
✔️  2_eslint
✔️  3_frontend-test
✔️  4_api-test

コマンドが順番に実行されそれぞれの実行結果が表示。最後にサマリーとしてOK・NGが出力されます。

まとめ

• サービス単位でコンテナ化して開発するのは便利だね。でもGit Hooksの処理ができない
• Lefthook使えばできるよ。シングルバイナリだから導入もかんたんだよ
• コンテナ化してもGit Hooksが使えるので複数の開発者がいても治安が維持できそう

以上

はじめに

この記事は、過去 GitBucket から GitHub への移行時に、
ファイルサイズ超過エラーが発生した際の対応方法を記述した記事になります。
他の方も書いている内容にはなりますが、どなたかの一助になれば幸いです。

注意点

この記事の手法を使うとGitリポジトリの履歴を書き換えることになり、
他メンバーが対象リポジトリをクローンしていると、整合性が合わなくなってしまいます。
自身のケースでは GitBucket から GitHub への移行という、完全クリーンな状態で
実施した内容にはなりますので、その点ご留意ください。

どんなエラーか

下記のエラーです。

remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.

エラーの原因

文言通りですが、ファイルサイズ超過のエラーです。
GitHubでは100MB超えのファイルを保存することができないため(Git LFSを使用すれば可能)、
GitHubへのPUSH時にエラーになる現象となります。
Git LFS については下記の方が解説くださっていますので、ここでは省きます。
https://qiita.com/ikmski/items/5cc8b8832336b8d85429

対策方法

対象ファイルを検索

まずは、リポジトリ内で下記のコマンドを実行し、100MB超えのファイルを検索します。

% find . -size +100M -ls
XXXXXXXX XXXXXXX -rw-r--r--    1 user group 316274484  3  16 12:00 ./hoge.zip

対象ファイルを履歴から削除

自身のケースでは、対象ファイルがGit管理不要なもの(そもそもそんなものを追加するなって思いますが)だったので、
Git履歴から全て削除を行いました。
git filter-branch という非常に破壊的なコマンドがあるので、そちらを利用しました。
簡潔にいうと git filter-branch は大量のコミット履歴を一括で書き換えることのできるコマンドになります。
パスワードやキー情報を誤ってコミットしてしまった履歴や、今回のようなエラーの発生時が主なユースケースになると思います。
(とはいってもかなり破壊的なコマンドなので、可能なら使いたくない・・・。)

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch ./hoge.zip' HEAD

現在の内容をPUSH

履歴の削除後、現在の状況を強制的にPUSHします。
(developブランチの場合)

git push -f origin develop

これで履歴から100MB超えのファイルが削除され、 GitHub への移行が可能なはずです。
また、この手順は公式が出している下記の記事が参考になるかもしれません。
機密データをリポジトリから削除する

最後に

git filter-branch は使いどころをちゃんと考えたいコマンドですが、
使い方さえ誤らなければ非常に便利なコマンドだと思います。
そもそも使う必要がある状況に陥らないことが最優先だと思いますが・・・。

git、痒いところに手が届く感じがすごく便利です。

共に働くWebエンジニアを募集しています!

不動産SHOPナカジツでは自社サービスを作っていく仲間を募集しています。
詳しくはWantedlyからお問い合わせください。

ポートフォリオ作りのために初めてgit管理してみたのでメモ。
投稿主の環境
1.aws cloud9（デフォルトでgit導入済み）
2.windows
3.bitbucket

手順としては
1.git init
2.git add
3.git status
4.git commit
5.git log

1.git init

操作しているアプリケーションのルートディレクトリに移動してからgit initでそのディレクトリをgitの管理対象（初期化）にする。

git_init

cd ルートディレクトリ名/
git init
Initialized empty Git repository in ~~

自分がgit initするときに出てきた（エラー？）メッセージは

git_init

Reinitialized existing Git repository in ~~

これはすでにあるものをもう一回初期化しましたという意味だそう。(特になにかをする必要ないと思われる。）

2.git add

git add ファイル名で対象のファイルをリポジトリに移動。

git_add

git add ファイル名

ちなみにgit add -A実行するとそのディレクトリにあるファイル全てがリポジトリに追加されます。

git_add

git add -A

3.git status

git addでgitにファイルを追加をしようとしてもこの段階ではまだ追加はされていません。というのも、間違って直gitに追加してしまわないようにするためです。
そのため、git addを実行すると、ファイルは一時保存のような状態になります（ステージングという待機用リポジトリへ移動）。
わかりやすく言うと、git add => ステージング（一時保存）=> 反映といった3段階になっています。
git statusでは、ステージングの状態を確認することができます。

git_status

git status

4.git commit

ステージングにあるファイルを反映（コミット）するためにgit commit -m "メッセージ"を実行します。

git_commit

git commit -m "メッセージ"

このメッセージはgitを使った共同開発で何をしたかをわかりやすくするためのものみたいです。

5.git log

git logでgit commit -m "メッセージ"のメッセージの履歴を確認することができます。履歴が長いときは"q"を押して解除できます。

bitbucketに反映

1~5実行後にgit pushを実行するとbitbucketに反映されます。

最後に

初学者ながら自身の経験を投稿してみました。gitのやり方がよくわかっていなかったのでメモとしてアウトプット。少しでも参考になればと思います。

はじめに

ローカル環境からgithubにpushをし、EC2からpullをしたときにエラーが出たのでメモを残します。

以下の記事を参考にして対処しました。
本番環境でpullしたらコンフリクト？解決法３パターン！【Please commit your changes or stash them before you merge】

エラーの内容

$ git pull origin master
From https://github.com/user-name/app-name
     * branch　     master       ->   FETCH_HEAD 
Updating e05c05f..050505
error: Your local changes to the following files would be overwritten by merge: 
         Gemfile.lock
         config/initializers/devise.rb
Please commit your changes or stash them before you merge.
Aborting

私が実践した対処法

terminal

$ git fetch origin master

$ git reset --hard origin/master

これで無事にgithubの内容がEC2上に反映されました。

終わりに

今回は少し強引なやり方をしてpullをしましたが、実際の開発現場ではもう少し慎重にgitを扱う必要があるのだと思います。
今後も、gitについて深く勉強していきます。

Gerritとは

Gerritとは無料のブラウザベースで使えるコードレビューツールです。主にソフトウェアのアジャイル開発を行う目的で利用されます。チームでソフトウェア開発を進める際に、ソースコードの変更をお互いにレビューし合い、レビューを通過したものだけを開発中のコードにマージすることができます。Gitを使って、開発しているソースコードのクローンや変更の提出などを行います。また、Jenkinsと連携させることで提出したコードの自動検証も可能です。Gerritの構築方法と簡単な使い方を紹介します。

Gerritの構築

Gerritはサーバー上で構築し、ブラウザからアクセスして使用します。構築の方法は公式ページにもいくつか書いてあります。その中でもDockerを使った構築方法が最も簡単でした。

sudo docker run -d -p 8080:8080 -p 29418:29418 gerritforge/gerrit-ubuntu15.04
sudo docker ps
CONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS              PORTS                                              NAMES
bdaf2ac5560f        gerritforge/gerrit-ubuntu15.04   "/bin/sh -c '/var/ge…"   5 minutes ago       Up 5 minutes        0.0.0.0:8080->8080/tcp, 0.0.0.0:29418->29418/tcp   pedantic_ardinghelli

ブラウザで0.0.0.0:8080を開けるようになります。

次に、sshでGerritに接続できるようにします。

ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub

catで出力された公開鍵をGerritのブラウザから登録します。
Account>Settings>SSH Public Keysの場所から登録します。
その後以下のコマンドで、ssh接続ができることを確認します。

ssh admin@localhost -p 29418
  ****    Welcome to Gerrit Code Review    ****

  Hi Administrator, you have successfully connected over SSH.

  Unfortunately, interactive shells are disabled.
  To clone a hosted Git repository, use:

  git clone ssh://admin@25680d00e8b3:29418/REPOSITORY_NAME.git

Connection to localhost closed.

次に、練習として、testプロジェクトを作成して修正をコミットする手順を示します。

ssh -p 29418 admin@localhost gerrit create-project --empty-commit test

testというプロジェクトが作成されました。

testというプロジェクトに変更点を提出していきます。

git clone ssh://admin@localhost:29418/test
cd test

scp -p -P 29418 admin@localhost:hooks/commit-msg .git/hooks/

echo 'test' > test.txt
git add test.txt
git commit -m "test commit"
git push ssh://admin@localhost:29418/test  HEAD:refs/for/master

3行目のscp ・・・というコマンドは、コミットに自動でIDを付与するために必要です。IDが付与されていないと変更点の提出ができないことがあります。
下の画像の通り、変更点が提出されました。

Gerritで変更点の提出までの流れ

現在開発中のリポジトリのクローンと、Gerritへの変更点の提出までの手順を書きます。

git clone ssh://admin@localhost:29418/test
cd test
git checkout -b myBranch

ソースコードに変更を加えます。JIRAとGerritの連携機能を使っているのであればJIRAの課題管理IDをコミットメッセージに記載します。

git add .
git commit -m "[JIRA issue ID] commit message"

最後に、Gerrit上のリモートリポジトリと同期し、git reviewによりソースコードの修正を提出します。

git checkout master
git pull --ff-only origin master
git checkout myBranch
git rebase -i master
git review

提出内容の修正方法

提出した変更内容を修正したい場合の手順を示します。

git review -d [変更番号]
git checkout review/[提出者名]/[ブランチ名]

ソースコードを修正します。

git add .
git commit --amend
git review

目的

• Git本体のバージョン管理をHomebrewで行いたくていろいろやった話をまとめる
• 書いている内容は単純にHomebrewでGitをインストールして使用するものと変わらない

実施環境

項目	情報
OS	macOS Catalina(10.15.3)
ハードウェア	MacBook Pro (16-inch ,2019)
プロセッサ	2.6 GHz 6コアIntel Core i7
メモリ	16 GB 2667 MHz DDR4
グラフィックス	AMD Radeon Pro 5300M 4 GB Intel UHD Graphics 630 1536 MB

実施方法概要

1. HomebrewでGitのインストール
2. パスを通し
3. バージョン確認

実施方法詳細

1. HomebrewでGitのインストール

   1. 下記コマンドを実行してHomebrewをインストールする(すでに実施済みの場合は飛ばす。)

      $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
      

   2. 下記コマンドを実行してHomebrewでGitをインストールする。

      $ brew install git
      

2. パス通し

   1. 下記コマンドを実行してHomebrewのgitのパスを通す。(X.XX.XはみなさんのHomebrewでインストールしたgitのバージョン)

      $ echo "export PATH=/usr/local/Cellar/git/X.XX.X/bin:$PATH" >> ~/.bash_profile
      

   2. 下記コマンドを実行して.bash_profileを再読み込みする。

      $ source ~/.bash_profile
      

3. バージョン確認

   1. 下記コマンドを実行してGitのバージョンがHomebrewでインストールされたものになっているのか確認する。

      $ git --version
      >git version X.XX.X
      

Git 操作でクッソ困ったことをメモしていきます。

どうやって解決したらえーねん！という事ばかりが頻繁に起こるのでメモ。

フロー間違ってるかもだけど。

まずやったこと。

$ git status

で状態確認する。

On branch feature/useredit
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    .env.example
#   modified:   app/Http/Controllers/CustomerController.php
#   modified:   config/database.php

はいはい、で

$ git commit -m "hogehoge"

で今回修正対象のファイルはControllerなので

git add app/Http/Controllers/CustomerController.php

で、Push

$ git push origin feature/useredit

でたぜエラー！！！

 ! [rejected]        feature/useredit -> feature/useredit (fetch first)
error: failed to push some refs to 'https://github.com/oboTeamDeve/deve_obo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge 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 pull') before pushing again.

とあるので、おそらくPushする前にPullしてちょ。だと思う。

で、

git pushがrejectされたときの対応方法
を参考に

$ git pull origin feature/useredit

実行。

すると、

Merge branch 'feature/useredit' of https://github.com/oboTeamDeve/deve_obo into feature/useredit

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

なんかcommmitメッセージ入れろや、と出てきましたが、空でも良さそうなのでそのまま:q

で、なんか色々mergeされていざアクセスしたらEroor!表示だけど、Mergeしたことで余計なコードが入っただけだから修正して無事解決。

で、git push origin feature/usereditで解決。