作業中にマージ依頼が来て困ったのでその時に学んだ対処法（git stashの使い方）を備忘録* git stash save　""　コミットしてないファイルを一時保存 git stash list　stashされてる履歴確認 git stash show ~~ stashされてるファイル確認 git stash pop　元に戻す git stash apply　元に戻しstashにも残す

Gitを使う上での備忘録 ローカルリポジトリの作成からプッシュまで https://qiita.com/sayama0402/items/9afbb519d97327b9f05c https://www.hivelocity.co.jp/blog/34777/ .gitファイルが不可視ファイルだった（ctrl+shift+.） https://pc-karuma.net/mac-shotcut-key-show-hidden-files/ ファイル容量が大きく、アップロードできない場合の対処 https://qiita.com/kanaya/items/ad52f25da32cb5aa19e6 いつまで経ってもファイルでかいって怒られるなーと思ってたら、一度コミットしたものが残り続けているみたい https://teratail.com/questions/55549 Git resetコマンド集 https://qiita.com/ChaaaBooo/items/459d5417ff4cf815abce git push時のerror: src refspec master does not match anyについて https://deepblue-ts.co.jp/git/git-push-error/ わけわからんので、一度 .gitファイルを削除 次からは、ファイルを1つずつ指定しよう。 .gitignore .gitattributes は、リモートのファイルがローカルのコミット時に対象になる模様。 したがって、上記のファイルはリモート側であらかじめ作成するか、先にプッシュしておく必要がある。

独学でgitをよく使っていてgit完全に理解したなと思っていたのですが、実務に入ってから突然cherry-pickしといてと言われん？チェリー？？え、えとパニックに陥った経験があります。 今回はそんな実務に入りたての自分が事前に知っていたら助かったなというコマンドを、ケース別にまとめてみたいと思います。 未経験エンジニアが実務で一番最初に取り組むプロジェクトは、すでにある程度形になっているアプリケーションのバグ改修業務が多いのでは無いでしょうか？今回はそんなプロジェクトを任された過去の筆者を例にとって解説していきたいと思います。 こちらで紹介するのは筆者が経験したプロジェクトでの使い方です。組織内でルールが規定されている場合はそちらに従うようにしてください。 対象読者 実務未経験の方 gitの基本的なコマンドをある程度使いこなせるようになってきた方 "〇〇の機能を実装して"と言われたら ポイントとなるコマンド git checkout -b <任意のブランチ名> <基点としたいブランチ名> 最初に開発環境を整えるためにプロジェクトのリポジトリをクローンしてきます。 $ git clone <gitURL> 以下のコマンドでプロジェクトにどんなブランチがあるか確認してみましょう。 $ git branch -a 基本的には以下3種類のブランチがあると思います。 main(master)ブランチ：本番環境にデプロイするブランチ developブランチ：featureブランチで作成した機能の検証をするブランチ featureブランチ：アプリケーションの機能を開発するブランチ 今回は新しい機能を実装するよう言われているので、developブランチを基点としてfeatureブランチを新しく作成します。 $ git checkout -b feature/implement_〇〇_feature origin/feature これで作業用のブランチを作成することができました。 $ git branch feature/implement_〇〇_feature developブランチを基点としたのには理由があります。 developブランチはfeatureブランチで実装した機能を検証するためのブランチです。したがって今回作成したfeature/implement_〇〇_featureブランチも、開発が完了すればdevelopブランチにマージされ機能が検証されます。featureブランチが最終的にマージされる先がdevelopブランチのためdevelopブランチを基点としてfeatureブランチを作るのです。 またdevelopブランチは様々な開発者のfeatureブランチがマージされています。つまり、プロジェクトの最新状態が反映されたブランチなのです。ここを基点とすることで最新のコード上で開発をすることができるというのがもう１つの理由になります。 開発が完了したらおなじみのコマンドでcommit&pushし、developブランチにプルリクエストを送ればOKです。 実務ではどこを基点としてブランチを作成するかを意識できるとgoodjobです。 "差分だけプルリクエストしといて"と言われたら 無事新しい機能の追加をすることができました。 developブランチで検証も完了し一安心です。しかしこんなことを言われてしまいます。 上司「developブランチで動作確認できたからmainブランチにfeatureブランチの差分だけプルリクしといて」 筆者「？？？？？」 今回のポイントなるコマンドはcherry-pickです。 git cheryy-pick <コミットID> cherry-pickは特定のコミットを抽出して適用することができるコマンドです。 どういうことか詳しく説明していきます。 まず、先ほどのfeature/implement_〇〇_featureブランチで追加した機能の検証が終わったため、この機能をmainブランチに反映させたいです。 しかしdevelopブランチをmainブランチにマージしようとすると、他の開発者が作成した検証途中の機能もマージされてしまいます。 またfeatureブランチを直接mainブランチにマージさせようとしても、featureブランチはdevelopブランチが基点となっているため同じように検証途中の機能がマージされてしまいます。 そこで、feature/implement_〇〇_featureブランチで作った機能だけをmainブランチに反映させたいときにgit cherry-pickコマンドが役に立ちます。 まずfeature/implement_〇〇_featureブランチでgit logコマンドを打ちます。 $ git branch feature/implement_〇〇_feature $ git log commit asd8dfgeff817ec66f445da521402690a937 Author: test name <test@test.com> Date: Mon May 7 20:02:11 2021 -0000 implement 〇〇 feature 実装した機能のコミット情報が表示されるので、commitID:asd8dfgeff817ec66f445da521402690a937をコピーしておきます。 次にmainブランチを基点として新たにreleaseブランチを作成します。 $ git checkout -b release/implement_〇〇_feature origin/main $ git branch release/implement_〇〇_feature そしてcherry-pickコマンドを用いてfeatureブランチのコミットをreleaseブランチに反映させます。 $ git cherry-pick asd8dfgeff817ec66f445da521402690a937 これでfeature/implement_〇〇_featureブランチで追加した機能のみを反映したブランチを作成することができました。 これをpushしてmainブランチにプルリクエストを送れば、追加した機能の差分のみを反映させることができます。 "緊急で別の機能対応して"と言われたら ポイントとなるコマンド git stash feature/implement_〇〇_featureブランチで新しい機能を開発している途中「緊急で別の機能対応して」と言われてしまいました。対応するために別のブランチに移行しようとすると以下のエラーが出てしまいました。 error: Your local changes to the following files would be overwritten by checkout: test.app Please, commit your changes or stash them before you can switch branches. この時に取れる対策は以下の３つです。 変更を破棄する 変更をコミットする 変更を退避させる せっかく途中まで作った機能なのでコードの破棄はしたくありません。しかしコミットするには中途半端なところまでしか作れていない…。そんなときはgit stashコマンドで変更を退避させましょう。 $ git stash これにより今までの変更が一時的に退避され、他のブランチに移行することができるようになります。 $ git checkout feature/implement_other_feature feature/implement_other_featureブランチでの作業が完了したら元のブランチにcheckoutし下記コマンドで退避させた内容を元に戻すことができます。 $ git stash list stash@{0}: WIP on feature/implement_〇〇_feature: xxxx stash@{1}: WIP on release/implement_other_feature: xxxx $ git stash apply stash@{0} <- 元に戻したい変更 おわりに gitコマンドをまとめておくだけでもよかったのですが、実際に実務の中でどうやって使われるのかイメージしてもらいたかったので、ケース別に解説をしてみました。 この記事が少しでもどなたかの役に立ったのであれば幸いです。

Githubとやり取りする際のターミナル上でのコマンドに関してまとめます。 出力はあくまでも例となります。 ◎リモートリポジトリを表示 % git remote >origin #URLを表示 % git remote -v >origin git@github.com:アプリ名.git (fetch) origin git@github.com:アプリ名.git (push) ◎リモートリポジトリの新規追加 git remote add [リモート名] [リモートURL] 上記コマンドは、Github上で、「Repositories」→「new」同じ意味。 ◎フェッチとプル リモートリポジトリから情報を取得する方法は2パターンあり、それがフェッチとプルです。 #フェッチの場合 git fetch [リモート名] >remote: 〜〜〜 remote: 〜〜〜 　略 From github.com:アプリ名 #プルの場合 git pull >同上 #省略せずに書くと、 git pull [リモート名][ブランチ名] このフェッチとプルの違いは、リモートリポジトリから取得した情報を一気にワークツリーまで持ってくるかどうかです。 フェッチの場合、フェッチコマンドを入力した時点ではローカルリポジトリに情報を持ってきているだけです。そのためワークツリーまで情報を持ってこようとすると、統合するための「git merge」コマンドを入力しなければいけません。 反対にプルの場合は、一気にワークツリーまで情報取得してくるので、いちいちmaergeを用いる必要がありません。 ※プルコマンドの注意点 一見便利なプルコマンドですが、別ブランチの情報を取得する時は注意が必要です。 例えば現在masterブランチにいるとしてmainブランチの情報を取得してしまうと、ブランチが異なっているためファイルの中身が混在してしまう可能性があります。 ◎リモートリポジトリの詳細情報を確認 git remote show [リモート名] >* remote origin Fetch URL: ~~~ Push URL: ~~~ HEAD branch: main Remote branch: main tracked Local branch configured for 'git pull': main merges with remote main Local ref configured for 'git push': main pushes to main (local out of date) 最初に出てきた「git remote」より詳細情報を表示します。 上から、フェッチとプルのURL/リモートブランチ名/HEADブランチ/git pullの動き/git pushの動きが表示されています。 ◎リモートリポジトリの削除、修正 #削除する場合 git remote rm [リモート名] #修正する場合 git remote rename [旧リモート名][新リモート名] rmはリムーブの省略です。 以上です。

ポートフォリオ作成中にrailsとrubyのバージョンを変更したい為、環境構築しました。環境構築した際に、gemもbundle installでファイルの内容を変えました。その変更点をGitでコミットプッシュして、アプリ自体に反映させなければと思いました。 発生した経緯：環境構築する為にrubyのバージョンを変更し、railsを新しくインストロールしました。 　　　　　　内容反映させる為にギットでコミットプッシュしました。 エラーの内容： （ターミナルでのエラー）/usr/local/bin/git-secrets: line 116: /Library/Developer/CommandLineTools/usr/libexec/git-core/git: Argument list too long　　（bundle install で取り込んだ大量のファイルなどを含めてコミットしようとした際に表示されるエラー文） 解決策：Gitでの場合 .gitignoreに、git対象から外したいファイルを記載します。(今回であればvendor) gitignore. vendor/ 次にGitのキャッシュから、対象ファイルを削除します。 git rm -r --cached vendor/ 解説：bundle instalでインストールするファイル自体は、gemファイルにインストールすべきファイルが記載してある為、コミットに含める必要はないので外す必要があります。

☆railsチュートリアル初学者向け rails newでアプリ作成〜コミットまで、チュートリアルの反復学習用に纏めています。 注意点を含めて、個人的に忘れそうな部分を所々追記していきます。 コミット対象の新規アプリケーションを作成 $ rails _4.0.5_ new アプリケーション名 新規作成したいアプリケーション名が「sample_app」の場合は、 $ rails _4.0.5_ new sample_app と入力。_4.0.5_ はバージョン指定 (省略可)。 リポジトリの初期化 $ git init 現在のディレクトリに対して、新しいリポジトリを新規作成する。 コマンド実行後、配下に.gitという名前でサブディレクトリが作成される。ls -aコマンドで確認。 コミット対象のファイルを指定 $ git add -A ファイルをコミットする為に、ステージングエリアと呼ばれる待機リポジトリに置く。 エリアに置かれたファイルはコミット待ち状態になる。 -Aは「全てのファイル」を指定するオプション。$ git add README.md のように直接ファイル指定も可能。 ファイルのコミット $ git commit -m "メッセージ" ステージングエリアに存在するファイルをコミットする。 ファイルの変更のたびgit addをするのが面倒な場合は、-aオプションによって、git addコマンドを省略可能。 （-aは変更された全ファイルを一括でコミットする） $ git commit -a -m "メッセージ"