20210914のGitに関する記事は4件です。

gitの過去のコミットを分割する

はじめに gitのコミットを整理することは大事です。特にチーム開発をしている時は、コミット履歴の綺麗さがレビュアーの生産性に直結します。 なので、自分はPRを出す前にコミット履歴をまとめて整理することがよくあります。 ですが、大きなPRを作る時など、整理したつもりが間違えてコミットを作ってしまうことがあります。 例えば次のような感じです。 - init project - create package1 - package1/file1.txt 追加 - create package2 - package2/file1.txt 追加 - add files to package1 - package1/file2.txt 追加 - package1/file3.txt 追加 - package1/file4.txt 追加 - package2/file2.txt 間違えて追加 - add files to package2 - package2/file3.txt 追加 - package2/file4.txt 追加 - modify ... - modify ... - modify ...- modify ... .... 三つ目のコミット「add files to package1」に間違えてpackage2/file2.txtの作成を混ぜてしまっています。本来はこのファイルの作成は次のコミットに含めるべきものです。 直近のコミットならgit reset HEAD~なりで修正すれば良いですが、その後にいくつものコミットがある場合は、それらのコミットも全てリセットすることになってしまいます。色々整理し終わっていざpushする直前にこのような間違いに気づくととても大変ですね。 このような状態の時に、簡単に過去のコミットのファイルを移動させる方法です。 やり方 まず、間違えてファイルを追加してしまったコミットのコミットIDを取得します。 $ git log --oneline 872653a (HEAD -> master) modify package1/file1.txt 71135ef add files to package2 ffb5ca4 add files to package1 # 今回はこれのコミットID b876371 create package2 903598c create package1 続いて、移動させたいファイルをどのような名前でも良いのでリネームします。すると、gitにはこのような差分として表示されます。 $ mv package2/file2.txt package2/file2.txt_ $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: package2/file2.txt Untracked files: (use "git add <file>..." to include in what will be committed) package2/file2.txt_ このdeletedとして表示された差分だけをfixupでコミットします。 $ git add package2/file2.txt $ git commit --fixup ffb5ca4 # 先ほどのコミットIDを指定 [master 4d0136f] fixup! add files to package1 1 file changed, 1 deletion(-) delete mode 100644 package2/file2.txt 今度は、ファイルを本来追加すべきコミットのコミットIDを取得します。 $ git log --oneline 872653a (HEAD -> master) modify package1/file1.txt 71135ef add files to package2 # 今度はこれのコミットID ffb5ca4 add files to package1 b876371 create package2 903598c create package1 そして、リネームしたファイル名を元に戻して、fixupでコミットします。 $ mv package2/file2.txt_ package2/file2.txt $ git add . $ git commit --fixup 71135ef # コミットIDを指定 [master bbe31b9] fixup! add files to package2 1 file changed, 1 insertion(+) create mode 100644 package2/file2.txt 最後にrebaseをかけてfixupを適用させます。 git rebase -i --autosquash ffb5ca4~ # 間違えてファイルを追加してしまったコミットのコミットIDを指定 これでコミット履歴が素敵になります。 どういうことか 詳しくは解説しませんがgit fixupは複数のコミットをまとめるコマンドです。 今回は「間違えてファイルを追加したコミット」と「ファイルを削除」というコミットを1つにまとめ、さらに「ファイルを追加し忘れたコミット」と「ファイルを追加する」というコミットをまとめました。 こうすることにより、擬似的にコミット間でファイルを移動させたというわけです。 参考文献
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【git】【初心者向け】git pull はどうやら推奨されないらしい。

こんにちは! 未経験からフロントエンドエンジニアを目指し学習5ヶ月目の者です。 これまで学んだことの整理&備忘録の目的で投稿します。(今回が初投稿!) 今日の内容は、現在ボランティアとして参画しているスタートアップで初めての共同開発に挑戦していて、gitについての理解不足からやらかしてしまった話です。。 初学者の方の参考になると幸いです。 概要 ・git pull  をするとリモートリポジトリの内容がローカルリポジトにソースが引っ張られ、ワークツリーに内容が反映される ・その際、ローカルリポジトリにあった未コミットの内容はbranchが上書きされるため消える → git pull すると未コミットの内容が吹っ飛びます!! 対処法 1.git pull をする前にはbranchを切ってコミットしておく(未コミットのものがある状態でgit pullしない) 2.git stash で未コミットの内容を退避させておき、git pull後に戻す 3.やってしまった場合→git checkout . でワークツリー変更内容の取り消し 4.そもそも、git pull ではなく git fetch + git merge を使うべし (git pull は作業ツリー自体を操作してしまうため。他にも複雑な部分があり、公式にもpullについてはそこまで詳しく触れられていないと聞いたことがあります。) 参考 【git】Git pullには罠がある git fetchとgit pullが別々に存在する理由 https://qiita.com/anchor-cable/items/3f3195fb8a928c7cae02 git push の反対は git pull ではない https://qiita.com/usamik26/items/28be7d2c221a7a53c2c3 Gitの取り消しいろいろまとめ https://qiita.com/Yu_engineer/items/1aaa37b43702db75ef4c 学びや所感 1.実務と勉強の違い 個人開発で学習しているのみだと、テストブランチpushしてチームにプルリクを出し、mergeしてもらって、それをfetchするというような作業は発生しない。 こういうのが実務と勉強の違いだなと実感しました。 2.エンジニアとしてもとめられるコミュニケーション能力 プルリクの内容が相手にとってわかりやすいか?ミスった時の報連相は適切か?等、「エンジニアにはコミュニケーション力が求められる」と言われる所以がよくわかりました。 質問の意図を一発で伝えられたり、そもそもクリティカルな質問を一発でできるように現状把握~問いの分析を行えるなど、コミュニケーションコストを最小限に抑えられる人間が重宝される気がします。 (私自身、今回は上記のミスをうまく処理できず開発を遅らせてしまったため) 補足 エンジニア転職を目指す実務未経験者のため、情報に不足や誤りがございましたら遠慮なくご指摘いただけると大変ありがたいです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ローカルリポジトリをGitHubへアップロードする

ローカルリポジトリ作成 git init git add . git commit -, "init commit" 現在のディレクトリの内容の初期コミットが行われる。 GitHubで新規リポジトリを作成する Initialize the repositoryにいろいろとチェックボックスがあるが、それらはチェックしない。 作成後、アップロードするのに必要なURLが表示されるので、それをコピーする。 ローカルリポジトリに戻る。 GitHubへアップロードする git remote add origin {さっきコピーしたURL} git push origin master originは任意の名前だと思うので他の値でもおそらくいけると思われる。 これにて完了です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

githubでフォルダに矢印が!やっと解決した話 

githubでフォルダに矢印が出てやっと解決した話 はじめに、この画像をご覧ください。 section4フォルダに矢印がついています。何これ? で、中身はというと、、、 あれ??? 理想は、こんなイメージにしたかった。 フォルダが綺麗に並んでいるイメージだったのに、何か違う。。。 ※矢印フォルダの中に、さらに同じような矢印フォルダの場合もあります。 実際のエディタでは、フォルダ(ファイル)があるんだけどな、、、 teratailで同じ様に質問している人がいる gitでクローンしても矢印がついたフォルダだけ空になってしまうのですが、原因はなんなんでしょう? 回答者1 「そのフォルダにファイルが入ってないだけなんでは」 ←"いやいや、入ってるし" 回答者2 「SubModuleでしょう。」 ←"へー、SubModuleっていうんだ” 質問者 「回答ありがとうございます。サブモジュール、、初めて聞きました。調べて色々試してみます! 」 ←”質問者の逃げパターンあるあるw、いやー、そのあとが知りたいのに。。。" 別の記事にヒントがあった git add で fatal: Pathspec '/moge/hoge' is in submodule が出た時の対応 この記事が、ほぼ今回の解決の決定打だったので、この記事で勘がいい人は解決します。 試行錯誤 学習用だったので、特にブランチを切っていたわけではありませんでした。 そもそも、pushしてファイルがアップされないのはなぜ?? ①pushされない、つまり、リポジトリがちゃんと設定されていない?? //リポジトリが正しく設定されているか確認 $ git remote -v ちゃんと指定されていたので違いました。 ②ローカルとリモートがうまく紐づいてない?? // ローカルブランチ「main」を、リモートブランチ「main」に push // git push origin {ローカルのブランチ}:{リモート先のブランチ} $ git push origin main:main ブランチ名の指定する引数に「:(コロン)」を用いれば、push 先となるリモートブランチを明示的に指定する事もできますが、違いました。 (自分は、リモートのデフォルトmasterとなるブランチをmainにしています) ③pushするまで (1) add(ステージング) ← ココ ?? (2) commit(リポジトリに記録) ←違うっぽい (3) push  何のために $ git add するのか? Git管理するために、$git addでステージングします。 (自分は単純にステージングするために$git addするとだけ認識していました) $ git ls-files $ git ls-files でリポジトリで管理しているファイルを一覧表示できます。 実際に、ターミナルで見てみると、「section4(矢印付きフォルダ)」だけフォルダ以下のファイルがリポジトリ管理になっていません! つまり、先ほどの、"teratailで同じ様に質問している人がいる"の所で、 gitでクローンしても矢印がついたフォルダだけ空になってしまうのですが、原因はなんなんでしょう? 回答者1 「そのフォルダにファイルが入ってないだけなんでは」 ←"いやいや、入ってるし" 入ってなかった!!(管理されてなかった)なるほど!! 回答者1の方、もう少し細かく説明して(ツッコんで)ほしかった。。。 解決方法 ここで、先ほどの記事で解決できます。 git add で fatal: Pathspec '/moge/hoge' is in submodule が出た時の対応 (※監視から外すをググると「.gitignore」の説明ばかりにあたってしまいますが、今回は以下が解決方法です) $ git rm -rf --cached <対象ファイル or path> $ git add <対象ファイル or path> // <対象ファイル or path>部分は、$git ls-files した時に表示されている部分。 // --cachedオプションを付けることにより、ファイルを残したまま管理対象から外すことができる。 自分の場合は、 $ git rm -rf --cached section4 //rm 'section4'となり、いったん追跡対象から外す。 $ git add section4/nuxt-routing/nuxt.config.js $ git status 試しに、section4フォルダの一番深いファイルを監視対象にして、$ git statusで確認してみると、 あらたに、section4フォルダ以下、更新に違いが確認できました。 $ git add -A これで、section4の中のファイルが全部監視対象になったので、 $ git commit -m"メッセージ" $ git push section4フォルダの矢印が消えました! section4の中 /section4/nuxt-routing/ファイル のパス通りになっています! 以上です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む