- 投稿日:2021-01-25T21:20:11+09:00
きっとgit使えないとbad②
はじめに
昨日に引き続き、gitの基本的なコマンドを覚え書きのつもりで紹介します。
↓昨日の投稿
きっとgit使えないとbad
ローカルでブランチを切ってマージするまで
ローカルブランチを作成
% git branch ブランチ名ローカルでブランチを切り替える
% git checkout ブランチ名ローカルでブランチを作成し、切り替える(上2つを同時に行う感じ)
% git checkout -b ブランチ名
間違えてマスターにコミットしないためには、こっちの方が使い勝手がいいかな…
マスターに切り替える
% git checkout master全て(ローカル・リモート)のブランチを一覧表示
% git branch -a
ローカルのブランチをリモートにプッシュ
% git push -u origin ローカルのブランチ名
ブランチをマージする
% git merge ブランチ名その他使いそうなコマンド
ブランチの削除
% git branch -d ブランチ名
ブランチ名の変更
% git branch -m 古いブランチ名 新しいブランチ名
変更点の表示
% git diff終わりに
-d
みたいにオプションが多い印象です。何かの頭文字として覚えられればいいのだが…
- 投稿日:2021-01-25T20:57:44+09:00
Githubでプッシュしたリモートブランチ名を変更する
リモートにプッシュしたブランチ名が後々イケてない事に気づいた、、、
恥ずかしい、、どうすれば、、、
そんな時の対策!!手順の流れ
- ローカルのブランチ名を変更する
- リモートの変更前ブランチを削除
- 1で変更したローカルブランチをリモートにプッシュ
※この記事では変更前ブランチ名 > 変更後ブランチ名 に変更する
1. ローカルのブランチ名を変更する
$ git branch -m 変更前ブランチ名 変更後ブランチ名※この時点ではローカルのみ変更されている
2. リモートの変更前ブランチを削除
$ git push origin :変更前ブランチ名3. 1で変更したローカルブランチをリモートにプッシュ
git push origin 変更後ブランチ名これでローカルもリモートも恥ずかしい履歴がスッキリ!!
- 投稿日:2021-01-25T20:37:07+09:00
【未経験対象】GitHubが使えるってどういうこと?
GitHubって募集要項にありますが・・・
未経験採用で応募したい方から質問があったので解説します。
ターミナルで出来なきゃだめ?
GUIツール使ってもOKです。
(インフラエンジニア志望の方はだめです!)じゃあ何ができればいいの?
コミットの変更行数
150行とかだと結構読むのが大変なので、こまめにコミットしましょう
コミットのコメント
画面1とかではなく、メイン画面の遷移ボタンを実装くらい詳しく書いてください
ブランチの切り方
Git-flowかGitHub-Flowで書いてあると嬉しいです。
以下参考までに
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう:こっそり始めるGit/GitHub超入門(終) - @ITまとめ
スクールや教科書だとあまり言及されてないことなので共有します。
一緒に実務をして気持ちよく開発できるように練習頑張ってください!
- 投稿日:2021-01-25T18:59:31+09:00
git addとcommit、pushの関係をわかりやすく説明する【Gitコマンド解説①】
以下のGitコマンド、よく出てきますよね。
$ git add $ git commit $ git pushこのコマンドを打つことで、ソースコードを書き換えてGithubを更新してくれる。プロフィールに草が生えるからうれしい。今日のプログラミングはおしまい。
しかしここで、「git addとcommitの関係は? git pushってどういう意味?」と聞かれると、すらすらと答えられない人も多いのではないでしょうか。草が生えて喜んでるのにそんなこと聞くなよ、と。プログラミングを始めたころは、私もなんとなくこのコマンドを使っていました。
今日は、git addとcommit、pushの関係をわかりやすく解説していこうと思います。
リモートリポジトリとローカルリポジトリって?
Gitコマンドを理解するためには、まず「リモートリポジトリローカルリポジトリの関係」を理解する必要があります。
リポジトリとは、ファイルやディレクトリの履歴を管理する場所のことです。
自分のパソコン内でバージョン管理するために作成したリポジトリをローカルリポジトリといいます。リモートリポジトリはネット(主にGithub)にファイルをアップロードした状態でファイル管理するものです。
画像引用:https://backlog.com/ja/git-tutorial/intro/02/チーム開発の場合、個人がローカルリポジトリで開発を進めて、リモートリポジトリで開発したコードを共有する、という流れです。リモートリポジトリはネット上でファイルが共有されているので、プルリクエストという、自分のソースコードに対するレビューをもらったりして、開発を進めていきます。
図にあるように、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)することを「push」と呼びます。
$ git pushこれでgit pushの意味が分かりましたね。
git add とgit commitのちがいとは?
git addとcommitはローカルリポジトリ内で使用するコマンドです。
ソースコードを書き換える流れを、図に表すと以下のようになります。
画像引用:https://backlog.com/ja/git-tutorial/intro/04/ワークツリーとは、実際に作業している場所(ディレクトリ)のことを指します。ここでああでもあい、こうでもないと試行錯誤して開発を進めるわけですね。
そのあとソースコードが完成したら、リポジトリに更新する必要があります。このソースコードの更新作業を「commit」と呼びます。
ここでワークツリーとリポジトリの間には、インデックスというスペースがあります。これはコミットするファイルを準備するところです。ワークツリーからインデックスに登録することを「add」と呼びます。
※ちなみに、なんでインデックスが必要なの?いきなりワークツリーからリポジトリにコミットで良くない?と思った方もおられるかもしれません。
インデックスの役割としては、変更点をいきなりコミットすると更新されてほしくない箇所も更新する恐れがあるからです。色々変更を加えたけど、ファイルAとBを変更したとき、Aだけコミットしたいことがあります。インデックスにAだけを登録することで、変更して欲しいファイルだけコミットすることができるんですね。
コミットに含めたい変更を選別する作業を行うのがインデックスの役割です。
これで、git add とgit commitの違いがわかったかと思います。このあとpushコマンドを使って、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)する流れになります。
まとめ
git addとcommit、pushの関係をまとめると
1.git addコマンドで、インデックスにコミットしたいファイルを登録する。 2.git commitコマンドで、インデックスにあるファイルを更新する。 3.git pushコマンドで、ローカルリポジトリの内容をリモートリポジトリに送信するこの3つを押さえておきましょう。
そのほかにもpull、fetch、mergeコマンドなど、良く出てくるGitコマンドがあるのですが、それは次回の記事で解説したいと思います。
追記:【Gitコマンド解説②】はこちら↓↓↓
git fetchとmerge、pullの関係をわかりやすく説明する【Gitコマンド解説②】この記事の説明がわかりやすかった!ここ間違ってるよ!次こんな記事を書いて欲しい!などあればコメント、DMよろしくお願いします。LGTMもぜひ。
Twitterもやってますので、フォローしていただけたらうれしいです。
卓球、心理学、哲学、Webサービス、好きな音楽、カメラ、登山、ランニング、読んだ本などなんでもつぶやいてます。
- 投稿日:2021-01-25T18:59:31+09:00
git addとcommit、pushの関係をわかりやすく解説する
以下のGitコマンド、よく出てきますよね。
$ git add $ git commit $ git pushこのコマンドを打つことで、ソースコードを書き換えてGithubを更新してくれる。プロフィールに草が生えるからうれしい。今日のプログラミングはおしまい。
しかしここで、「git addとcommitの関係は? git pushってどういう意味?」と聞かれると、すらすらと答えられない人も多いのではないでしょうか。草が生えて喜んでるのにそんなこと聞くなよ、と。プログラミングを始めたころは、私もなんとなくこのコマンドを使っていました。
今日は、git addとcommit、pushの関係をわかりやすく解説していこうと思います。
リモートリポジトリとローカルリポジトリって?
Gitコマンドを理解するためには、まず「リモートリポジトリローカルリポジトリの関係」を理解する必要があります。
リポジトリとは、ファイルやディレクトリの履歴を管理する場所のことです。
自分のパソコン内でバージョン管理するために作成したリポジトリをローカルリポジトリといいます。リモートリポジトリはネット(主にGithub)にファイルをアップロードした状態でファイル管理するものです。
画像引用:https://backlog.com/ja/git-tutorial/intro/02/チーム開発の場合、個人がローカルリポジトリで開発を進めて、リモートリポジトリで開発したコードを共有する、という流れです。リモートリポジトリはネット上でファイルが共有されているので、プルリクエストという、自分のソースコードに対するレビューをもらったりして、開発を進めていきます。
図にあるように、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)することを「push」と呼びます。
$ git pushこれでgit pushの意味が分かりましたね。
git add とgit commitのちがいとは?
git addとcommitはローカルリポジトリ内で使用するコマンドです。
ソースコードを書き換える流れを、図に表すと以下のようになります。
画像引用:https://backlog.com/ja/git-tutorial/intro/04/ワークツリーとは、実際に作業している場所(ディレクトリ)のことを指します。ここでああでもあい、こうでもないと試行錯誤して開発を進めるわけですね。
そのあとソースコードが完成したら、リポジトリに更新する必要があります。このソースコードの更新作業を「commit」と呼びます。
ここでワークツリーとリポジトリの間には、インデックスというスペースがあります。これはコミットするファイルを準備するところです。ワークツリーからインデックスに登録することを「add」と呼びます。
※ちなみに、なんでインデックスが必要なの?いきなりワークツリーからリポジトリにコミットで良くない?と思った方もおられるかもしれません。
インデックスの役割としては、変更点をいきなりコミットすると更新されてほしくない箇所も更新する恐れがあるからです。色々変更を加えたけど、ファイルAとBを変更したとき、Aだけコミットしたいことがあります。インデックスにAだけを登録することで、変更して欲しいファイルだけコミットすることができるんですね。
コミットに含めたい変更を選別する作業を行うのがインデックスの役割です。
これで、git add とgit commitの違いがわかったかと思います。このあとpushコマンドを使って、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)する流れになります。
まとめ
git addとcommit、pushの関係をまとめると
1.git addコマンドで、インデックスにコミットしたいファイルを登録する。 2.git commitコマンドで、インデックスにあるファイルを更新する。 3.git pushコマンドで、ローカルリポジトリの内容をリモートリポジトリに送信するこの3つを押さえておきましょう。
そのほかにもpull、clone、mergeコマンドなど、良く出てくるGitコマンドがあるのですが、それは次回の記事で解説したいと思います。
この記事の説明がわかりやすかった!ここ間違ってるよ!次こんな記事を書いて欲しい!などあればコメント、DMよろしくお願いします。LGTMもぜひ。
Twitterもやってますので、フォローしていただけたらうれしいです。
卓球、心理学、哲学、Webサービス、好きな音楽、カメラ、登山、ランニング、読んだ本などなんでもつぶやいてます。
- 投稿日:2021-01-25T16:21:25+09:00
Gitで間違ってPRをマージした時にRevertして再度PRを出す方法
対象者
- Gitでrevertした後、再度Mergeしようと思ってプルリクを出したら差分がないと言われて困っている人。
- 他の記事で「RevertのRevertをする」という言葉を見て、頭がこんがらがった人。
何が起きたのか
- developブランチ -> masterブランチ にプルリクを出してMerge
- やっぱりMergeを取り消したいのでRevert
- revertボタンを押してrevertブランチ -> master にrevertプルリクを出してMerge
- 再度 develop -> master にプルリクを出す
- すると、There isn't anything compare.
差分がないとなってしまう。。
どうすればよいのか
Revertと聞くと、「戻す」というイメージを持つかもしれないが、実際は新たな修正をMergeしているに過ぎない。つまり上記の例のようにrevertした直後は、「origin/masterの状態が最新、localのdevelopブランチは古い状態」となっている。なので、再度プルリクを出すには以下の手順を踏む必要がある。
- localのdevelopブランチにmasterの変更を取り込んで、origin/master(リモートのmasterブランチ)とlocalのdevelopの状態を同じにする。
- developブランチに修正を加える
- develop -> masterへのプルリクを出す。
実際の作業
masterの変更をdevelopに取り込む
まずはlocalのdevelopブランチにmasterの変更を取り込んで、origin/masterとlocalのdevelopの状態を同じにする。
$ git checkout develop # 一応logを確認しておく $ git log $ git pull origin/masterdevelopブランチに修正を加える
軽微な内容であれば手動で修正してもよいが、変更内容が大きい場合、先程のrevert前のソースを取り込みたい。
まずは現在のgit logを見てみる。
$ git log # Revert内容のMerge commit ew183be83aec39vngkd58884a5c5ee08e6irot Merge: 362266b 029fe1b Author: Esfahan Date: Mon Jan 25 13:59:02 2021 +0900 Merge pull request #553 from EsfahanRepo/revert-552-develop Revert "ソースコードの修正" # Revert用のcommit commit 009fe2b20b059a2da3b48air943f4a35a643296 Author: Esfahan Date: Mon Jan 25 13:20:10 2021 +0900 Revert "ソースコードの修正" # develop -> masterへのマージ。 commit 362226b7f594if45328b237bf5e738fc1887217b Merge: 6cdf2e1 2de7734 Author: Esfahan Date: Mon Jan 25 13:18:11 2021 +0900 Merge pull request #552 from EsfahanRepo/develop ソースコードの修正logの一番上の変更をRevertする。
[Revert内容のMerge] commit番号: ew183be83aec39vngkd58884a5c5ee08e6irot
このcommit番号の変更内容が先程Revertしたものなので、「RevertのRevertをする」という表現がなされるのだ。実際にやっていることは、「先ほどRevertする前の変更内容を、現在のlocalのdevelopブランチに取り込む」ということだ。ただし、実際にはrevertコマンドを使うので、「取り込む」という表現は適切でないのかもしれない。頭がこんがらがったのなら考えなくて良い。
develop -> masterのマージをする前の状態に戻す
Revertを実施する。
-m 1
というオプションを付けているが、これを付けないとエラーとなる。$ git revert ew183be83aec39vngkd58884a5c5ee08e6irot -m 1このcommitの詳細を確認すると、
Merge: 362233b 009ve1b
という行がある。$ git show ew183be83aec39vngkd58884a5c5ee08e6irot commit ew183be83aec39vngkd58884a5c5ee08e6irot Merge: 362233b 009ve1b Author: Esfahan Date: Mon Jan 25 13:59:02 2021 +0900 Merge pull request #553 from EsfahanRepo/revert-552-develop Revert "ソースコードの修正"このcommitはMergeなので、どちらのブランチの状態に戻すのかまで指定しなければならないのだ。
-m
(mainlineという意味)で1か2を指定するのだが、それぞれ以下の意味となる。
- 1: マージ元のブランチ(この場合はdevelop)
- 2: マージを適用するブランチ(この場合はmaster)
今回は、先程のMerge、つまりRevertプルリクのdevelopの状態に戻したいので、
1
を指定する。実行。
$ git revert ew183be83aec39vngkd58884a5c5ee08e6irot -m 1以下コマンドで、localのdevelopとリモートのmasterの差分を確認して想定どおりになっていれば、再度develop -> masterへのプルリクを出すことができる。
$ git diff develop origin/master
以上
参考
- 投稿日:2021-01-25T11:52:48+09:00
Git②【ローカルリポジトリとリモートリポジトリ 】
はじめに
これは学習用のメモになります。
①ローカルリポジトリ
ローカルリポジトリ流れ
ローカルは3つのエリアに分かれている。
①ワークツリー→②ステージ→③リポジトリ①ワークツリー・・・・ファイルを変更する作業場
②ステージ・・・・コミットする変更を準備する場所
③リポジトリ・・・・スナップショットを記録する場所1.ワークツリーの変更をステージに追加する
git add <ファイル名> git add <ディレクトリ名> git add .2.変更を記録する(コミット)
git commit
コマンドでリポジトリにスナップショットを記録します。git commit git commit -m '<メッセージ>' git commit -v現在の変更状況を確認する
変更されたファイルを確認する
git status変更差分を確認する
#git addする前の変更分 git diff git diff <ファイル名> #git addする後の変更分 git diff --staged変更履歴を確認する
git log #1行で表示するオプション git log --oneline #ファイルの変更差分を表示するオプション git log -p index.html #表示するコミット数を制限するオプション git log -n <コミット数>ファイル削除を記録する
#ファイルごと削除 git rm <ファイル名> git rm -r <ディレクトリ名> #ファイルを残したいとき git rm --cached <ファイル名> #ファイルの削除を取り消す ①git reset HEAD <ファイル名> ②git checkout <ファイル名>ファイルの移動を記録する
git mv <旧ファイル><新ファイル> #以下のコマンドと同じ意味 mv <旧ファイル><新ファイル> git rm <旧ファイル> git add <新ファイル>3.リモートリポジトリ(GitHub)へ送信する
リモートリポジトリを新規追加する
git remote add <リモート名> <リモートURL>ローカルリポジトリの内容をリモートリポジトリに送ることを「プッシュ」と言う。
git push <リモート名><ブランチ名> git push origin master②GitHub上にあるプロジェクトプロジェクトから始める場合
Gitリポジトリのコピーを作成する
git clone <リポジトリ名>クローン(コピーを)作成する
③リモートリポジトリ
リモートリポジトリとはオンライン上にあるリポジトリ(GitHub)。
リモートの情報を表示する
git remote git remote -vリモートリポジトリを新規追加する
git remote add <リモート名> <リモートURL>リモートから情報を取得する
リモートから情報を取得するには2種類のやり方があります。
1)フェッチ
フェッチとは取ってくるという意味です。
①フェッチ
リモートブランチからローカルブランチに情報を取得するgit fetch <リモート名> #例 git fetch origin②マージ
ローカルブランチからワークツリーに情報を取得する
git merge
2)プル
プルはリモートから情報を取得(プル)してマージまでを一度にやりたいとき(プル)。
フェッチとマージを同時にしてくれる。git pull <リモート名> <ブランチ名> git pull origin master #上記コマンドは省略可能 git pull #これは下記のコマンドと同じこと git fetch origin master git merge origin/masterフェッチとプルの使い分け
フェッチを基本的に使うのがオススメ。
プルした際に今いるブランチが開発環境にいれば問題ないが本番環境(masterブランチ)にいるとプルしようとしたものが反映されてしまうのでファイルがグチャグチャになってしまうので注意です。(する際は今どのブランチいるのか確認が必要)リモートを変更・削除
変更
git remote rename <旧リモート名> <新リモート名> #例 git remote rename tutorial new_tutorial削除
git remote rm <リモート名> #例 git remote rm new_tutorial
- 投稿日:2021-01-25T07:53:02+09:00
git cloneはローカル→ローカルも可能な話
はじめに
常駐ソフトの管理方法を検討していたところで、
不要なファイルをignoreした後の状態での常駐ソフトの動作確認をするために、ローカル→ローカルのクローンをしたくなりました。方法
今回はGUI操作の方が早かったので、作業の流れも示しておきました。
まず、クローン先のフォルダを開いて
Ctrl + L
→cmd
→Enter
します。
あとは普通にクローンします。
以上です。当然ですが、普通にクローンできました。
- 投稿日:2021-01-25T07:45:31+09:00
Windows版Gitで複数のGitHubアカウントを使い分ける方法(https認証)
はじめに
WindowsにおけるGitHubアカウントの複数運用に関して、簡潔な情報が見当たりませんでしたので解決策を記しておきます。
- リポジトリの作成
- git configにて資格情報の設定をする
- https認証する
手順
ローカルリポジトリにおいて、以下のコマンドで資格情報を個別に指定します。
git config credential.namespace git-sub
git-sub
は任意の文字列ですが、git...
としておいた方が管理の都合がいいと思われます。後は普通にPushします。
git-sub
の利用が初めてなのであれば、その段階でログインが求められます。
※この際、予めGitHubのメインアカウントからはログアウトしておくなどしなければ、自動的にメインアカウントで認証されてしまう場合があります。git add . git commit -m "init" git remote add origin https://github.com/user/repo.git git push origin masterこのリポジトリは
git-sub
としたGitHubアカウントに関連付けられたため、次回以降は特別な設定作業は不要です。
ところで、
git-sub
の情報は資格情報マネージャ
から確認できます。
資格情報マネージャはWin + R
→control.exe /name Microsoft.CredentialManager
もしくはWin + S
→しかく
などから開けます。
- 投稿日:2021-01-25T07:33:21+09:00
Gitでignoreされたファイル一覧を表示する
はじめに
思い通りに
.gitignore
されたのか確認したかったため、その方法を調査しました。ignoreされていないファイル
Git管理対象のファイル一覧は、以下のコマンドで取得します。
git ls-filesignoreされたファイル
上記のコマンドに、然るべきオプションを付けます。
git ls-files --others --ignored --exclude-standard
オプション 説明 --others / -o untrackedなファイルを表示 --ignored / -i --exclude*オプションにおける指定にマッチしたファイルを表示 --exclude-standard Gitによりignoreされたファイルを指定(.gitignoreや.git/info/excludeなど) 参考
Gitチートシート
https://training.github.com/downloads/ja/github-git-cheat-sheet/Git - git-ls-files Documentation
https://git-scm.com/docs/git-ls-filesあとからまとめて.gitignoreする方法
https://qiita.com/yuuAn/items/b1d1df2e810fd6b92574
- 投稿日:2021-01-25T06:53:49+09:00
git rebase -i {hash} したらMacVimに空が表示されるときに確認すること。
導入 (こんなことがあった)
- git rebase -i {hash} したらMacVimに空が表示されて「?」となった。
- git commit では大丈夫。(今考えるとこれは大丈夫ではなかったのかもしれない)
結論 (こうやったら解決した)
- git グローバル設定の core.editor のみが効くようにした。(git ローカル設定に、core.editor がたくさんあったので削除した)
解決までの経緯
調査1. 「-f オプションを付けよ」との情報を入手。
- これら。
- ほう。では、git 設定を確認しましょう。
> git config --list --global core.editor=/Applications/MacVim.app/Contents/bin/gvim -f
- ふむ。-f オプションはついているぞ?
調査2. global, local の設定を再確認
- local も見てみるか。
> git config --list --local core.editor=mvim core.editor=gvim -f core.editor=/Applications/MacVim.app/Contents/bin/gvim
- core.editor がたくさんある。。
- と、いうわけで、local の core.editor を削除し、global の core.editor が効くようにすることで解決しました。
チャンチャン。
- 投稿日:2021-01-25T06:19:11+09:00
gitの運用ルール
Gitの流れ
gitの運用ルールに関して備忘。
■最新のdevelopブランチに移動する
git checkout develop
git pull origin develop■自分のブランチを作る
git checkout -b {自分のブランチ名:future}
■コミット
git add {対応してるファイル}
git commit -m "{コミット名}"■コミットをまとめる
git rebase -i HEAD~{コミットを実行した回数}
■rebaseして最新のdevelopブランチのコミットを取得する
git pull --rebase origin develop
■pushを実行
git push origin {自分のブランチ名:future}
すでにリモートにプッシュしている場合は-fでコミット履歴を上書きできる。
(1merge1commitなどの運用ルールがある場合利用)
git push -f origin {自分のブランチ名:future}
- 投稿日:2021-01-25T00:09:15+09:00
Docker×Git×VSCodeの環境構築は多分これが一番やさしい説明だと思います。
環境
- Windows 10 Pro
詳細なシステム要件は以下のページで確認。(Hyper-Vを有効にするための要件)
https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements
準備するもの
- Docker Desktop for Windows
- Git for Windows
- Visual Studio Code
この記事では1,2,3の順番で説明。
Docker Desktop for Windowsをインストール
- ダウンロードページへ移動(https://www.docker.com/products/docker-desktop)
- 「Download for Windows」をクリックしてダウンロード
3. ダウンロードしたインストーラをクリックしてインストール開始
4. インストーラを起動したらOKを押下(「Enable Hyper-V Windows Features」をチェックすることでHyper-Vを有効にしてくれる)
5. 「Close and restart」を押下して再起動再起動後に「WSL 2 installtion is incomplete」のエラーが発生する場合
現象
再起動後、自動的にDockerが起動する。その際に以下のエラーが発生。
解消方法
- 以下のリンクに移動して、「x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ」をクリック
2. ダウンロードしたファイルをクリックして更新プログラムパッケージを実行Git for Windowsのインストール
- ダウンロードページへ移動(https://gitforwindows.org/)
- 「Download」をクリックしてインストーラをダウンロード
3. ダウンロードしたインストーラをクリックしてインストール開始
5. インストール場所を指定。特に理由が無ければデフォルトにしてNextを押下
6. コンポーネントの選択。これも特に理由が無ければデフォルトにしてNextを押下
8. Gitのデフォルトのエディタを選択。ここは特に気にする必要はないのでNextを押下(後で変更可能)
9. Gitで新しくリポジトリを作成するときのデフォルトの初期ブランチ名を決定。特にこだわりが無ければ「Let Git decide」を選択してNextを押下
11. HTTPS接続するときのSSL/TLSライブラリを選択。「Use the OpenSSL library」を選択してNextを押下
12. ここは要注意。チェックアウト・コミット時の改行コードの選択。以下の表を参照して選択し、Nextを押下
選択肢 チェックアウト時 コミット時 Checkout Winsows-style,
commit Unix-style line endingsLF -> CRLF CRLF -> LF Checkout as-is,
commit Unix-style line endings変換しない CRLF -> LF Checkout as-is,
commit as-is変換しない 変換しない
13. GitBashのターミナルを選択。特に理由が無ければデフォルトを選択してNextを押下
- git pullの振る舞いを選択。特に理由が無ければデフォルトを選択してNextを押下
15. 「Enable Git Credential Manager」を選択してNextを押下(https接続時に入力したパスワードを保持してくれる)
- 「Enable file system caching」を選択してNextを押下(ファイルシステムのキャッシュを利用する)
- 「Enable experimental support for pseudo consoles」のチェックをしない(バグがある模様)。Installを押下
18. Finishを押下して完了(リリースノートが表示されるが、どうでもよい)Visual Studio Codeのインストール
- ダウンロードページへ移動(https://code.visualstudio.com/download)
- WindowsのInstallerをクリックしてインストーラをダウンロード
4. 使用許諾契約書の同意。「同意する」を選択して次へを押下
6. スタートメニューフォルダーの指定。デフォルトのままで次へを押下
7. 追加タスクの選択。特に理由が無ければデフォルトで次へを押下
9. 完了を押下してインストール完了(Visual Studio Codeが自動的に実行される)Visual Studio Codeの拡張機能
- Visual Studio Codeを起動して「Ctrl」+「Shift」+「X」を押下して拡張機能を選択
- 検索ボックスで検索して、以下の拡張機能をインストールする
- Japanese Language Pack for Visual Studio Code:日本語化の拡張機能
- Remote-Containers:Dockerコンテナ内開発ができる拡張機能
- 投稿日:2021-01-25T00:09:15+09:00
Docker×Git×VSCodeの環境構築は多分これが一番やさしい説明だと思います
環境
- Windows 10 Pro
詳細なシステム要件は以下のページで確認。(Hyper-Vを有効にするための要件)
https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements
準備するもの
- Docker Desktop for Windows
- Git for Windows
- Visual Studio Code
この記事では1,2,3の順番で説明。
Docker Desktop for Windowsをインストール
- ダウンロードページへ移動(https://www.docker.com/products/docker-desktop)
- 「Download for Windows」をクリックしてダウンロード
3. ダウンロードしたインストーラをクリックしてインストール開始
4. インストーラを起動したらOKを押下(「Enable Hyper-V Windows Features」をチェックすることでHyper-Vを有効にしてくれる)
5. 「Close and restart」を押下して再起動再起動後に「WSL 2 installtion is incomplete」のエラーが発生する場合
現象
再起動後、自動的にDockerが起動する。その際に以下のエラーが発生。
解消方法
- 以下のリンクに移動して、「x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ」をクリック
2. ダウンロードしたファイルをクリックして更新プログラムパッケージを実行Git for Windowsのインストール
- ダウンロードページへ移動(https://gitforwindows.org/)
- 「Download」をクリックしてインストーラをダウンロード
3. ダウンロードしたインストーラをクリックしてインストール開始
5. インストール場所を指定。特に理由が無ければデフォルトにしてNextを押下
6. コンポーネントの選択。これも特に理由が無ければデフォルトにしてNextを押下
8. Gitのデフォルトのエディタを選択。ここは特に気にする必要はないのでNextを押下(後で変更可能)
9. Gitで新しくリポジトリを作成するときのデフォルトの初期ブランチ名を決定。特にこだわりが無ければ「Let Git decide」を選択してNextを押下
11. HTTPS接続するときのSSL/TLSライブラリを選択。「Use the OpenSSL library」を選択してNextを押下
12. ここは要注意。チェックアウト・コミット時の改行コードの選択。以下の表を参照して選択し、Nextを押下
選択肢 チェックアウト時 コミット時 Checkout Winsows-style,
commit Unix-style line endingsLF -> CRLF CRLF -> LF Checkout as-is,
commit Unix-style line endings変換しない CRLF -> LF Checkout as-is,
commit as-is変換しない 変換しない
13. GitBashのターミナルを選択。特に理由が無ければデフォルトを選択してNextを押下
- git pullの振る舞いを選択。特に理由が無ければデフォルトを選択してNextを押下
15. 「Enable Git Credential Manager」を選択してNextを押下(https接続時に入力したパスワードを保持してくれる)
- 「Enable file system caching」を選択してNextを押下(ファイルシステムのキャッシュを利用する)
- 「Enable experimental support for pseudo consoles」のチェックをしない(バグがある模様)。Installを押下
18. Finishを押下して完了(リリースノートが表示されるが、どうでもよい)Visual Studio Codeのインストール
- ダウンロードページへ移動(https://code.visualstudio.com/download)
- WindowsのInstallerをクリックしてインストーラをダウンロード
4. 使用許諾契約書の同意。「同意する」を選択して次へを押下
6. スタートメニューフォルダーの指定。デフォルトのままで次へを押下
7. 追加タスクの選択。特に理由が無ければデフォルトで次へを押下
9. 完了を押下してインストール完了(Visual Studio Codeが自動的に実行される)Visual Studio Codeの拡張機能
- Visual Studio Codeを起動して「Ctrl」+「Shift」+「X」を押下して拡張機能を選択
- 検索ボックスで検索して、以下の拡張機能をインストールする
- Japanese Language Pack for Visual Studio Code:日本語化の拡張機能
- Remote-Containers:Dockerコンテナ内開発ができる拡張機能