20210125のGitに関する記事は14件です。

きっと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みたいにオプションが多い印象です。何かの頭文字として覚えられればいいのだが…

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Githubでプッシュしたリモートブランチ名を変更する

リモートにプッシュしたブランチ名が後々イケてない事に気づいた、、、
恥ずかしい、、どうすれば、、、
そんな時の対策!!

手順の流れ

  1. ローカルのブランチ名を変更する
  2. リモートの変更前ブランチを削除
  3. 1で変更したローカルブランチをリモートにプッシュ

※この記事では変更前ブランチ名 > 変更後ブランチ名 に変更する

1. ローカルのブランチ名を変更する

$ git branch -m 変更前ブランチ名 変更後ブランチ名

※この時点ではローカルのみ変更されている

2. リモートの変更前ブランチを削除

  $ git push origin :変更前ブランチ名

3. 1で変更したローカルブランチをリモートにプッシュ

git push origin 変更後ブランチ名

これでローカルもリモートも恥ずかしい履歴がスッキリ!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【未経験対象】GitHubが使えるってどういうこと?

GitHubって募集要項にありますが・・・

未経験採用で応募したい方から質問があったので解説します。

ターミナルで出来なきゃだめ?

GUIツール使ってもOKです。
(インフラエンジニア志望の方はだめです!)

じゃあ何ができればいいの?

コミットの変更行数

 150行とかだと結構読むのが大変なので、こまめにコミットしましょう

コミットのコメント

 画面1とかではなく、メイン画面の遷移ボタンを実装くらい詳しく書いてください

ブランチの切り方

Git-flowかGitHub-Flowで書いてあると嬉しいです。

以下参考までに
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう:こっそり始めるGit/GitHub超入門(終) - @IT

まとめ

スクールや教科書だとあまり言及されてないことなので共有します。
一緒に実務をして気持ちよく開発できるように練習頑張ってください!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git addとcommit、pushの関係をわかりやすく説明する【Gitコマンド解説①】

以下のGitコマンド、よく出てきますよね。

$ git add 
$ git commit 
$ git push

このコマンドを打つことで、ソースコードを書き換えてGithubを更新してくれる。プロフィールに草が生えるからうれしい。今日のプログラミングはおしまい。

しかしここで、「git addとcommitの関係は? git pushってどういう意味?」と聞かれると、すらすらと答えられない人も多いのではないでしょうか。草が生えて喜んでるのにそんなこと聞くなよ、と。プログラミングを始めたころは、私もなんとなくこのコマンドを使っていました。

今日は、git addとcommit、pushの関係をわかりやすく解説していこうと思います。

リモートリポジトリとローカルリポジトリって?

Gitコマンドを理解するためには、まず「リモートリポジトリローカルリポジトリの関係」を理解する必要があります。

リポジトリとは、ファイルやディレクトリの履歴を管理する場所のことです。

自分のパソコン内でバージョン管理するために作成したリポジトリをローカルリポジトリといいます。リモートリポジトリはネット(主にGithub)にファイルをアップロードした状態でファイル管理するものです。

Image from Gyazo
画像引用:https://backlog.com/ja/git-tutorial/intro/02/

チーム開発の場合、個人がローカルリポジトリで開発を進めて、リモートリポジトリで開発したコードを共有する、という流れです。リモートリポジトリはネット上でファイルが共有されているので、プルリクエストという、自分のソースコードに対するレビューをもらったりして、開発を進めていきます。

図にあるように、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)すること「push」と呼びます。

$ git push

これでgit pushの意味が分かりましたね。

git add とgit commitのちがいとは?

git addとcommitはローカルリポジトリ内で使用するコマンドです。

ソースコードを書き換える流れを、図に表すと以下のようになります。

Image from Gyazo
画像引用: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サービス、好きな音楽、カメラ、登山、ランニング、読んだ本などなんでもつぶやいてます。

[https://twitter.com/atsushi101011]

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git addとcommit、pushの関係をわかりやすく解説する

以下のGitコマンド、よく出てきますよね。

$ git add 
$ git commit 
$ git push

このコマンドを打つことで、ソースコードを書き換えてGithubを更新してくれる。プロフィールに草が生えるからうれしい。今日のプログラミングはおしまい。

しかしここで、「git addとcommitの関係は? git pushってどういう意味?」と聞かれると、すらすらと答えられない人も多いのではないでしょうか。草が生えて喜んでるのにそんなこと聞くなよ、と。プログラミングを始めたころは、私もなんとなくこのコマンドを使っていました。

今日は、git addとcommit、pushの関係をわかりやすく解説していこうと思います。

リモートリポジトリとローカルリポジトリって?

Gitコマンドを理解するためには、まず「リモートリポジトリローカルリポジトリの関係」を理解する必要があります。

リポジトリとは、ファイルやディレクトリの履歴を管理する場所のことです。

自分のパソコン内でバージョン管理するために作成したリポジトリをローカルリポジトリといいます。リモートリポジトリはネット(主にGithub)にファイルをアップロードした状態でファイル管理するものです。

Image from Gyazo
画像引用:https://backlog.com/ja/git-tutorial/intro/02/

チーム開発の場合、個人がローカルリポジトリで開発を進めて、リモートリポジトリで開発したコードを共有する、という流れです。リモートリポジトリはネット上でファイルが共有されているので、プルリクエストという、自分のソースコードに対するレビューをもらったりして、開発を進めていきます。

図にあるように、ローカルリポジトリの内容をリモートリポジトリに送信(アップロード)すること「push」と呼びます。

$ git push

これでgit pushの意味が分かりましたね。

git add とgit commitのちがいとは?

git addとcommitはローカルリポジトリ内で使用するコマンドです。

ソースコードを書き換える流れを、図に表すと以下のようになります。

Image from Gyazo
画像引用: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サービス、好きな音楽、カメラ、登山、ランニング、読んだ本などなんでもつぶやいてます。

[https://twitter.com/atsushi101011]

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitで間違ってPRをマージした時にRevertして再度PRを出す方法

対象者

  • Gitでrevertした後、再度Mergeしようと思ってプルリクを出したら差分がないと言われて困っている人。
  • 他の記事で「RevertのRevertをする」という言葉を見て、頭がこんがらがった人。

何が起きたのか

  1. developブランチ -> masterブランチ にプルリクを出してMerge
  2. やっぱりMergeを取り消したいのでRevert
    • revertボタンを押してrevertブランチ -> master にrevertプルリクを出してMerge
  3. 再度 develop -> master にプルリクを出す
    • すると、There isn't anything compare.

差分がないとなってしまう。。

どうすればよいのか

Revertと聞くと、「戻す」というイメージを持つかもしれないが、実際は新たな修正をMergeしているに過ぎない。つまり上記の例のようにrevertした直後は、「origin/masterの状態が最新、localのdevelopブランチは古い状態」となっている。なので、再度プルリクを出すには以下の手順を踏む必要がある。

  1. localのdevelopブランチにmasterの変更を取り込んで、origin/master(リモートのmasterブランチ)とlocalのdevelopの状態を同じにする。
  2. developブランチに修正を加える
  3. develop -> masterへのプルリクを出す。

実際の作業

masterの変更をdevelopに取り込む

まずはlocalのdevelopブランチにmasterの変更を取り込んで、origin/masterとlocalのdevelopの状態を同じにする。

$ git checkout develop
# 一応logを確認しておく
$ git log
$ git pull origin/master

developブランチに修正を加える

軽微な内容であれば手動で修正してもよいが、変更内容が大きい場合、先程の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

以上

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git cloneはローカル→ローカルも可能な話

はじめに

常駐ソフトの管理方法を検討していたところで、
不要なファイルをignoreした後の状態での常駐ソフトの動作確認をするために、ローカル→ローカルのクローンをしたくなりました。

↓ 乱雑なのでignoredな状態にしたい
2.jpg

方法

今回はGUI操作の方が早かったので、作業の流れも示しておきました。

まず、クローン先のフォルダを開いてCtrl + LcmdEnterします。
1.jpg

3.jpg

あとは普通にクローンします。

4.jpg

以上です。当然ですが、普通にクローンできました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Windows版Gitで複数のGitHubアカウントを使い分ける方法(https認証)

はじめに

WindowsにおけるGitHubアカウントの複数運用に関して、簡潔な情報が見当たりませんでしたので解決策を記しておきます。

  1. リポジトリの作成
  2. git configにて資格情報の設定をする
  3. 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 + Rcontrol.exe /name Microsoft.CredentialManagerもしくはWin + Sしかくなどから開けます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitでignoreされたファイル一覧を表示する

はじめに

思い通りに.gitignoreされたのか確認したかったため、その方法を調査しました。

ignoreされていないファイル

Git管理対象のファイル一覧は、以下のコマンドで取得します。

git ls-files

ignoreされたファイル

上記のコマンドに、然るべきオプションを付けます。

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

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git rebase -i {hash} したらMacVimに空が表示されるときに確認すること。

導入 (こんなことがあった)

  • git rebase -i {hash} したらMacVimに空が表示されて「?」となった。
  • git commit では大丈夫。(今考えるとこれは大丈夫ではなかったのかもしれない)

結論 (こうやったら解決した)

  • git グローバル設定の core.editor のみが効くようにした。(git ローカル設定に、core.editor がたくさんあったので削除した)

解決までの経緯

調査1. 「-f オプションを付けよ」との情報を入手。

> 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 が効くようにすることで解決しました。

チャンチャン。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitの運用ルール

2021-01-25_06h10_19.png

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}

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker×Git×VSCodeの環境構築は多分これが一番やさしい説明だと思います。

環境

  • Windows 10 Pro

詳細なシステム要件は以下のページで確認。(Hyper-Vを有効にするための要件)

https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements

準備するもの

  1. Docker Desktop for Windows
  2. Git for Windows
  3. Visual Studio Code

この記事では1,2,3の順番で説明。

Docker Desktop for Windowsをインストール

  1. ダウンロードページへ移動(https://www.docker.com/products/docker-desktop)
  2. 「Download for Windows」をクリックしてダウンロード

image.png
 
3. ダウンロードしたインストーラをクリックしてインストール開始

image.png
 
4. インストーラを起動したらOKを押下(「Enable Hyper-V Windows Features」をチェックすることでHyper-Vを有効にしてくれる)

image.png
 
5. 「Close and restart」を押下して再起動

image.png
 
6. 再起動後、自動的にDockerが起動したら完了

image.png

再起動後に「WSL 2 installtion is incomplete」のエラーが発生する場合

現象

再起動後、自動的にDockerが起動する。その際に以下のエラーが発生。

image.png

解消方法

  1. 以下のリンクに移動して、「x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ」をクリック

https://docs.microsoft.com/ja-jp/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package

image.png
 
2. ダウンロードしたファイルをクリックして更新プログラムパッケージを実行

image.png
 
3. Nextを押下して実行

image.png
 
4. Finishを押下してダイアログを閉じる

image.png
 
5. エラーのダイアログでRestartを押下

image.png

Git for Windowsのインストール

  1. ダウンロードページへ移動(https://gitforwindows.org/)
  2. 「Download」をクリックしてインストーラをダウンロード

image.png
 
3. ダウンロードしたインストーラをクリックしてインストール開始

image.png
 
4. Nextを押下

image.png
 
5. インストール場所を指定。特に理由が無ければデフォルトにしてNextを押下

image.png
 
6. コンポーネントの選択。これも特に理由が無ければデフォルトにしてNextを押下

image.png
 
7. Nextを押下

image.png
 
8. Gitのデフォルトのエディタを選択。ここは特に気にする必要はないのでNextを押下(後で変更可能)

image.png
 
9. Gitで新しくリポジトリを作成するときのデフォルトの初期ブランチ名を決定。特にこだわりが無ければ「Let Git decide」を選択してNextを押下

image.png
 
10. Nextを押下

image.png
 
11. HTTPS接続するときのSSL/TLSライブラリを選択。「Use the OpenSSL library」を選択してNextを押下

image.png
 
12. ここは要注意。チェックアウト・コミット時の改行コードの選択。以下の表を参照して選択し、Nextを押下

選択肢 チェックアウト時 コミット時
Checkout Winsows-style,
commit Unix-style line endings
LF -> CRLF CRLF -> LF
Checkout as-is,
commit Unix-style line endings
変換しない CRLF -> LF
Checkout as-is,
commit as-is
変換しない 変換しない

image.png
 
13. GitBashのターミナルを選択。特に理由が無ければデフォルトを選択してNextを押下

image.png

  1. git pullの振る舞いを選択。特に理由が無ければデフォルトを選択してNextを押下

image.png
 
15. 「Enable Git Credential Manager」を選択してNextを押下(https接続時に入力したパスワードを保持してくれる)

image.png

  1. 「Enable file system caching」を選択してNextを押下(ファイルシステムのキャッシュを利用する)

image.png

  1. 「Enable experimental support for pseudo consoles」のチェックをしない(バグがある模様)。Installを押下

image.png
 
18. Finishを押下して完了(リリースノートが表示されるが、どうでもよい)

image.png

Visual Studio Codeのインストール

  1. ダウンロードページへ移動(https://code.visualstudio.com/download)
  2. WindowsのInstallerをクリックしてインストーラをダウンロード

キャプチャ.PNG
 
3. インストーラをクリックしてインストール開始

image.png
 
4. 使用許諾契約書の同意。「同意する」を選択して次へを押下

image.png
 
5. インストール先の選択。デフォルトのままで次へを押下

image.png
 
6. スタートメニューフォルダーの指定。デフォルトのままで次へを押下

image.png
 
7. 追加タスクの選択。特に理由が無ければデフォルトで次へを押下

image.png
 
8. インストール先などを確認して、インストールを押下

image.png
 
9. 完了を押下してインストール完了(Visual Studio Codeが自動的に実行される)

image.png

Visual Studio Codeの拡張機能

  1. Visual Studio Codeを起動して「Ctrl」+「Shift」+「X」を押下して拡張機能を選択
  2. 検索ボックスで検索して、以下の拡張機能をインストールする
  • Japanese Language Pack for Visual Studio Code:日本語化の拡張機能
  • Remote-Containers:Dockerコンテナ内開発ができる拡張機能

image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker×Git×VSCodeの環境構築は多分これが一番やさしい説明だと思います

環境

  • Windows 10 Pro

詳細なシステム要件は以下のページで確認。(Hyper-Vを有効にするための要件)

https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/reference/hyper-v-requirements

準備するもの

  1. Docker Desktop for Windows
  2. Git for Windows
  3. Visual Studio Code

この記事では1,2,3の順番で説明。

Docker Desktop for Windowsをインストール

  1. ダウンロードページへ移動(https://www.docker.com/products/docker-desktop)
  2. 「Download for Windows」をクリックしてダウンロード

image.png
 
3. ダウンロードしたインストーラをクリックしてインストール開始

image.png
 
4. インストーラを起動したらOKを押下(「Enable Hyper-V Windows Features」をチェックすることでHyper-Vを有効にしてくれる)

image.png
 
5. 「Close and restart」を押下して再起動

image.png
 
6. 再起動後、自動的にDockerが起動したら完了

image.png

再起動後に「WSL 2 installtion is incomplete」のエラーが発生する場合

現象

再起動後、自動的にDockerが起動する。その際に以下のエラーが発生。

image.png

解消方法

  1. 以下のリンクに移動して、「x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ」をクリック

https://docs.microsoft.com/ja-jp/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package

image.png
 
2. ダウンロードしたファイルをクリックして更新プログラムパッケージを実行

image.png
 
3. Nextを押下して実行

image.png
 
4. Finishを押下してダイアログを閉じる

image.png
 
5. エラーのダイアログでRestartを押下

image.png

Git for Windowsのインストール

  1. ダウンロードページへ移動(https://gitforwindows.org/)
  2. 「Download」をクリックしてインストーラをダウンロード

image.png
 
3. ダウンロードしたインストーラをクリックしてインストール開始

image.png
 
4. Nextを押下

image.png
 
5. インストール場所を指定。特に理由が無ければデフォルトにしてNextを押下

image.png
 
6. コンポーネントの選択。これも特に理由が無ければデフォルトにしてNextを押下

image.png
 
7. Nextを押下

image.png
 
8. Gitのデフォルトのエディタを選択。ここは特に気にする必要はないのでNextを押下(後で変更可能)

image.png
 
9. Gitで新しくリポジトリを作成するときのデフォルトの初期ブランチ名を決定。特にこだわりが無ければ「Let Git decide」を選択してNextを押下

image.png
 
10. Nextを押下

image.png
 
11. HTTPS接続するときのSSL/TLSライブラリを選択。「Use the OpenSSL library」を選択してNextを押下

image.png
 
12. ここは要注意。チェックアウト・コミット時の改行コードの選択。以下の表を参照して選択し、Nextを押下

選択肢 チェックアウト時 コミット時
Checkout Winsows-style,
commit Unix-style line endings
LF -> CRLF CRLF -> LF
Checkout as-is,
commit Unix-style line endings
変換しない CRLF -> LF
Checkout as-is,
commit as-is
変換しない 変換しない

image.png
 
13. GitBashのターミナルを選択。特に理由が無ければデフォルトを選択してNextを押下

image.png

  1. git pullの振る舞いを選択。特に理由が無ければデフォルトを選択してNextを押下

image.png
 
15. 「Enable Git Credential Manager」を選択してNextを押下(https接続時に入力したパスワードを保持してくれる)

image.png

  1. 「Enable file system caching」を選択してNextを押下(ファイルシステムのキャッシュを利用する)

image.png

  1. 「Enable experimental support for pseudo consoles」のチェックをしない(バグがある模様)。Installを押下

image.png
 
18. Finishを押下して完了(リリースノートが表示されるが、どうでもよい)

image.png

Visual Studio Codeのインストール

  1. ダウンロードページへ移動(https://code.visualstudio.com/download)
  2. WindowsのInstallerをクリックしてインストーラをダウンロード

キャプチャ.PNG
 
3. インストーラをクリックしてインストール開始

image.png
 
4. 使用許諾契約書の同意。「同意する」を選択して次へを押下

image.png
 
5. インストール先の選択。デフォルトのままで次へを押下

image.png
 
6. スタートメニューフォルダーの指定。デフォルトのままで次へを押下

image.png
 
7. 追加タスクの選択。特に理由が無ければデフォルトで次へを押下

image.png
 
8. インストール先などを確認して、インストールを押下

image.png
 
9. 完了を押下してインストール完了(Visual Studio Codeが自動的に実行される)

image.png

Visual Studio Codeの拡張機能

  1. Visual Studio Codeを起動して「Ctrl」+「Shift」+「X」を押下して拡張機能を選択
  2. 検索ボックスで検索して、以下の拡張機能をインストールする
  • Japanese Language Pack for Visual Studio Code:日本語化の拡張機能
  • Remote-Containers:Dockerコンテナ内開発ができる拡張機能

image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む