What's New Qiita

20201013のGitに関する記事は8件です。

  • 投稿日：2020-10-13T23:58:36+09:00

windowsのssh-agentが動かないときの対処法

環境

なお、gitコマンドがPowerShellから使えるようにgit for windowsで設定してある。

問題となった事象

sshコマンドのみの使用では問題なかったが、ssh-agentコマンドを使用した場合にいずれも発生した。

  1. ssh-addを使って確かに秘密鍵をパスワードを登録したはずなのに、gitコマンドを使うとでパスワードを相変わらず聞かれる。
  2. "warning agent returned different signature type ssh-rsa"という警告が出る。

1つ目の問題への対処

原因は、gitコマンドはgit for windowsに付属しているsshバイナリを使用するため。

gitに使用するssh.exeのパスを教えてやればいい。

以下手順

  1. 環境変数GIT_SSHを定義して、値をgitに使用するssh.exeのパスにする。

こちらを参考にした。

2つ目の問題への対処

sshキーを生成する際にEd25519のキータイプを指定する。

次を実行すれば良い。

ssh-keygen -t ed25519 -C "your_email@example.com"

２つ目の問題への対処

(追記: 2020/10/14)

@ttdodaさんからのコメントで、Ed25519鍵を使うと以下の手順を行わずとも正常に動作する事がわかりました。Ed25519鍵のほうがRSA鍵よりも優れているみたいなので、積極的に使っていきましょう。

原因は、windowsに付属しているSSHクライアントのバージョンが古いため。（ゴミかよ！！！）そのうち、WindowsUpdateでバージョンアップされるらしい!?

Issueがすでに建てられていて、白熱していた。

以下、最新のwindows用OpenSSHをインストールするための手順

  1. まずはwindowsに標準で付属しているOpenSSHクライアントをアンインストールする。設定→アプリ→オプション機能からアンインストールできる。
  2. 指示通りに再起動する。
  3. GitHubのreleaseから最新のリリースのOpenSSH-Win64.zipをダウンロードする。
  4. Program FilesにOpenSSHというフォルダ名で展開する。
  5. このディレクトリのパスをシステム環境変数のPathに追加して、パスを通す。
  6. 環境変数の変更を反映するために再起動する。

ひとまず一件落着だが、ssh-agentを起動時に立ち上げるための設定も必要だ。なお、OpenSSH Authentication Agentは標準のOpenSSHクライアントをアンインストールしたときに削除されている。

以下手順

  1. PowerShellを管理者権限で起動する。

  2. 次のコードを実行して、サービスに追加。

   New-Service -Name ssh-agent -BinaryPathName "C:\Program Files\OpenSSH\ssh-agent.exe"

再起動して、ssh-agentを実行して起動していることを確認。

これで快適にgitを使えるようになった!!
Congratulations!!!

以下のサイトを参考にした。

Windows10 で ssh-agent のサービスを登録する

OpenSSH for Windows のインストール（Windows 上）

おまけ：環境変数の編集

windowsボタンを押して「env」と入力すると、「システム環境変数の編集」という選択肢が出てきて素早く編集画面に移動できる。

そもそも、秘密鍵を置くマシンに自分しかアクセスできないということが保証できるなら、無理にパスフレーズを設定しなくてもいいのかもしれない。

https://serverfault.com/questions/142959/is-it-okay-to-use-a-ssh-key-with-an-empty-passphrase#:~:text=As%20long%20as%20no%2Done,keys%20used%20by%20automated%20software.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T23:54:48+09:00

Git　超基本コマンド

git init
Gitリポジトリの作成

ディレクトリの作成

$ mkdir git-tutorial
$ cd git-tutorial

リポジトリの作成

$ git init
Initialized empty Git repository in /home/user/work/git-tutorial/.git/

これで　git-tutorialディレクトリがGitリポジトリとして管理されるようになる。

git status
Git リポジトリの状態の確認

ファイルの作成

$ echo 'Hello,git!!' > README.md
$ cat README.md
Hello,git!!

Gitステータスの確認コマンド

$git status

ステータスの確認

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

・Untracked files(未追跡)状態とは
ステージングエリアにもリポジトリにも登録されていない状態。

Gitの管理下から外すとき

リポジトリの削除を行う

$ rm -rf .git

git add
ステージングエリアへファイルを追加しコミット対象にする

ステージングエリアへのファイルの追加コマンド

$ git add README.md

ステータスの確認

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md



複数ファイルの指定

$ git add <file> <file> ...



全てのファイルを登録

$ git add .

・ステージングエリアとは
ファイルをコミットする前に変更内容を一時的に登録しておくバッファのようなもの。

ワーキングディレクトリとステージングエリアの差分の確認

# すでにステージングされたREADME.md　の編集を行う
$ echo '# Hi!! Git!!' > README.md
$ cat README.md
# Hi!! Git!!
# Gitの状態の確認
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

git diff
Gitでファイルの変更差分を確認する

ステージングエリアとの比較

$ git diff
diff --git a/README.md b/README.md
index e69de29..5264c8b 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
+# Hi!! Git!!

単語単位の比較

$ git diff --word-diff
diff --git a/README.md b/README.md
index e69de29..5264c8b 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
{+# Hi!! Git!!+}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T23:54:48+09:00

Git　超基本コマンドの学習。。。

git init
Gitリポジトリの作成

ディレクトリの作成

$ mkdir git-tutorial
$ cd git-tutorial

リポジトリの作成

$ git init
Initialized empty Git repository in /home/user/work/git-tutorial/.git/

これで　git-tutorialディレクトリがGitリポジトリとして管理されるようになる。

git status
Git リポジトリの状態の確認

ファイルの作成

$ echo 'Hello,git!!' > README.md
$ cat README.md
Hello,git!!

Gitステータスの確認コマンド

$git status

ステータスの確認

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

・Untracked files(未追跡)状態とは
ステージングエリアにもリポジトリにも登録されていない状態。

Gitの管理下から外すとき

リポジトリの削除を行う

$ rm -rf .git

git add
ステージングエリアへファイルを追加しコミット対象にする

ステージングエリアへのファイルの追加コマンド

$ git add README.md

ステータスの確認

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md



複数ファイルの指定

$ git add <file> <file> ...



全てのファイルを登録

$ git add .

・ステージングエリアとは
ファイルをコミットする前に変更内容を一時的に登録しておくバッファのようなもの。

ワーキングディレクトリとステージングエリアの差分の確認

# すでにステージングされたREADME.md　の編集を行う
$ echo '# Hi!! Git!!' > README.md
$ cat README.md
# Hi!! Git!!
# Gitの状態の確認
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md

git diff
Gitでファイルの変更差分を確認する

ステージングエリアとの比較

$ git diff
diff --git a/README.md b/README.md
index e69de29..5264c8b 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
+# Hi!! Git!!

単語単位の比較

$ git diff --word-diff
diff --git a/README.md b/README.md
index e69de29..5264c8b 100644
--- a/README.md
+++ b/README.md
@@ -0,0 +1 @@
{+# Hi!! Git!!+}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T21:38:08+09:00

Gitのブランチを頑張って解説する

構成管理のツールにはかかせないブランチという機能。Gitのブランチってどんな仕組みなの？というところを書いていきます。

ブランチ is 何？

まずは構成管理ツールにおける、ブランチってなんなの？というところから。
ブランチを一言で表すと、
ほかの人の開発の邪魔をせず、自由に開発するための機能
って感じです。一言でって難しいよね。。。

というわけで例え話

自動車を生産する工場をイメージしてください。
ブランチなしで自動車工場
一か所の作業場で、板金、組み立て、塗装などすべての作業をしようとしているようなイメージです。
エンジンもタイヤもシートもすべてその場で作っている状態です。わちゃわちゃしてそうでしょ。
シートの革を一枚一枚丁寧に縫製している横から、塗装のスプレーの流れ弾が飛んできて、革の質感が台無しに、、なんて悲劇が起こるかもしれません。

ブランチありで自動車工場
パーツ、工程ごとに専用の工場があるイメージです。
エンジンはエンジン工場、タイヤはタイヤ工場、シートはシート工場で作成され、完成されたものがメインの生産工場に納入されて、自動車に組み込まれます。
この方法なら、シートの縫製中に汚される心配もありませんね。

ちょっと誇張しましたが、ブランチというのは生産ラインを分けるというイメージと捉えられるかなと思います。
システム開発の構成管理においても、ほかの人の開発を邪魔せず(ほかの人の開発に邪魔されず)開発を進めていくための作業場の役割を果たすのがブランチです。

Gitにおけるブランチとは？

ブランチを理解するうえで、ちゃんと解いておきたいありがちな勘違いを紹介します。
(自分が勘違いしていただけで、本当にありがちな勘違いなのかどうかは知らないです。。)

その勘違いとは、ブランチを「線」だと解釈することです。

Gitブランチ001.png

hogeとfugaの二つのブランチを使って説明します。(ここでのブランチ名に特に意味はありません。)
ソースの修正を確定させて、Gitに登録する操作をコミットといいます。この図では黒い四角の箱でそれを表現しており、中にはコミットを行った際に記録される情報の一部を記載しました。(中身はテキトーです。)

勘違いパターンとは、このコミット同士をつなぐ線のことをブランチと思ってしまうことです。
しっくりきやすいのでこう覚えてしまいがちですが、Gitにおけるブランチというのは、線ではないのです。

これが正解。

Gitブランチ002.png

いうならば「線」ではなく、「点」と表現できます。
Gitのブランチとは、特定のコミットへのポインタなのです。
コミットというのは、その時のソースの状態のスナップショットを保持してくれるものなのですが、開発を進めていくとそれは無数に増えていくものです。
(ちなみに自分が仕事をしているプロジェクトでは、5万弱のコミットが行われています。)
それをうまく管理して、扱いやすくするためにブランチというものが存在するのです。要するに目印になるんですね。

じゃあ、勘違いパターンだった「線」って、ブランチじゃなかったらなんなの？という疑問が出てきますね。
これはコミットの親子関係を表します。
上の図のコミットの情報で、「Parent aaaaaaa」と記載されているのは、そのコミットの親コミットを記録しているのです。
コミットをしたときに、その直前に行われていたコミット(HEADというポインタが指しています)を親コミットとして記録することで、コミット同士の線のつながり＝親子関係ができあがるのです。
また、二つのコミットを親とするコミットを作ることができます。これをマージコミットといいます。

つらつらと書きましたが、一番覚えておきたいのは「ブランチはコミットの目印」ということです。
Git操作によってこの目印の位置を自由に操作できるようになると、Git便利だなぁ～って感じられるようになると思います。

Gitコマンドでブランチを操作する

ブランチは目印であるということを意識して、いくつか代表的なブランチの操作を紹介します。

ブランチを作成する

git branch <ブランチ名>

新しい目印を作ります。
自分が作業をしているブランチの目印の位置で作成してくれますが、ブランチ名の後ろに既存の別のブランチ名を指定すると、指定したブランチのコミット位置で新しいブランチを作成できます。

作業するブランチを変更する

git checkout <ブランチ名>

一つのローカルリポジトリの中で、同時に作業に使えるブランチは一つだけです。
このcheckoutコマンドを使って、ブランチを切り替えながら作業していくことになります。

ちなみに、ブランチを作成する⇒作業するブランチを変更する　をコマンド一発で行うことができます。

git checkout -b <ブランチ名>

このコマンドでも、作成元のブランチの指定が可能です。

扱っているブランチの一覧

git branch -a

今作業しているブランチ、ローカルブランチの一覧、リモート追跡ブランチの一覧が確認できます。
ブランチの確認はこのコマンドだけ覚えていれば、困ることは何もないかと。

※完全に備忘用：リモートリポジトリに上がっているブランチをすべて表示するコマンド

git remote show <リモート名>

ブランチを削除する

git branch -d <ブランチ名>

強制的に削除する場合

git branch -D <ブランチ名>

リモート追跡ブランチを削除する場合

git branch -dr <リモート追跡ブランチ名>

リモートブランチを削除する場合

git push <リモート名> :<ブランチ名>

リモート追跡ブランチの削除の場合は、-rオプションを追加します。
リモートブランチの場合、通信が必要なので、pushコマンドに用意されたオプションを使います。
目印を一つ消すだけなので、怖がる必要はそんなにないコマンドだと思っています。

ブランチ名を変更する

git branch -m <旧ブランチ名> <新ブランチ名>

別のブランチのコミットを作業中のブランチに取り込む

git merge <取り込むブランチ名>

本題ではないので紹介だけ。
二つの親コミットを持つマージコミットの作り方です。

目印の位置を任意の場所に変更する

git reset <コミット>

軽率に紹介してみましたが、「resetって何？」って思った方は使用を控えることを全力でオススメします！
やらかすと開発現場を数時間ストップさせるくらいの魔力を持っています。ご利用は計画的に。

※ちなみに、GitHubを使っている場合は、ブラウザから簡単にリモート上でのブランチ作成、削除等が可能です。他のGUIでもあるんだろうけど。。

Gitのブランチの使い方のベストプラクティス

最後に、Gitの便利なブランチという機能をより効率的に使いこなしていくためのベストプラクティスとして、「git-flow」と「GitHub Flow」という二つのワークフローを簡単に紹介します。
このワークフローってどういうものかというと、ブランチを役割ごとに分類して、運用ルールを定めて、効率よくシステム開発を進めよう！というものです。

git-flow

git-flowは比較的大規模な開発向けの、複雑で厳密なワークフローです。

git-flow.png

ブランチの役割とルールを簡単に。

ブランチ 役割
master リリースされた、出来上がったソースが保管される。リリースのたびにバージョン番号をつけてタグを打つ。
develop 開発の中心となるブランチ。出来上がったソースをこのブランチに集めていくことになる。このブランチのソースが最新。
feature branches 開発のタスクに応じて切られる。このブランチを使用して開発し、作業が完了したらdevelopにソースをマージする。
release branches リリースをする際にdevelopから分岐する。バグ修正など、どうしても必要な更新以外は行わない。
リリースが完了したら、masterとdevelopにそれぞれマージを行う。
hotfixes 緊急でパッチを当てる必要がある場合などに、masterから直接分岐させる。作業完了後には、masterとdevelop(またはrelease)にそれぞれマージを行う。

正直、小さいチームであればやりすぎ感のあるワークフローです。理にかなっているのは確かだと思うのですが。。
個人的にオススメは、次のGitHub Flowです。

GitHub Flow

GitHubの機能を活用したワークフローです。
主にプルリクエストの機能を活用しながら、ブランチ構成はシンプルに、いくつかのルールをみんなで守っていく、というスタイルです。

GitHub_Flow_steps.png

ブランチ 役割
master 開発の中心となるブランチ。常にデプロイが可能な状態をキープする必要がある。
topic 開発を行うブランチ。そのブランチで行う作業内容をそのままブランチ名にする。

ブランチの分類は二つだけでとても理解しやすいです。
ほかにもいくつかルールがあります。
・小さな作業単位でこまめにコミットする。
・ブランチでの開発が済んだら、masterへのプルリクエストを作成し、ソースレビューを受ける。
・レビューでOKが出たら、速やかにマージを行い、デプロイする。

重要なのはmasterはいかなる時もデプロイが可能であるということです。
この前提を崩さないために、しっかりとレビューをして、デプロイを阻害するソースをmasterにマージすることを防ぐ必要があります。
これが守られることにより、高頻度でのデプロイが可能な状態をキープできるわけです。

やっぱりレビューは大切ですね。
プルリクエストという機能も、レビューをするためのものとしてとても進化しており、手軽で使いやすいサービスになっています。

ブランチについて長々と説明してきました。簡潔にまとめるスキルが欲しい。。。
最後にもう一度言いますが、ブランチを使いこなせると、本当にGit便利だな～ってなると思うので、それが感じられるようにいろいろ使って試してみてください！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T15:34:47+09:00

Gitのローカルブランチを一括削除

master, develop 以外のローカルブランチを一括削除するワンライナー。

git branch | grep -v master | grep -v develop | xargs git branch -D
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T14:26:29+09:00

ローカルブランチを新規ブランチとしてプッシュしたいとき

やりたいこと

ローカルにあるブランチを、新規ブランチとしてリモートにプッシュしたい。

手順

大元にしたいブランチをチェックアウト
image.png

チェックアウトするときに名前を変えておく
image.png

SourceTree上のUI操作では新規ブランチとしてプッシュできないので
ターミナルを起動
image.png

コマンドでプッシュ
$ git push origin master_test
image.png


フェッチすると
image.png

新規ブランチとして作成されている
image.png



  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T14:15:27+09:00

vagrant環境でGitHubの草が生えない(Contributionできない）時の対処方法

せっかく日々のGitHubへのPushを頑張っているのに、草が生えないとがっかりします。
私もVagrant環境で何回か草が生えないが状況に陥ったので、参考になればと思います。

草の生える条件

以下の3点が全て満たされていないと草が生えません。

①コミットに使用されるメールアドレスがGitHubアカウントと連携されていること
②フォークされたリポジトリではなく、独立したリポジトリでコミットされること
③デフォルトブランチもしくはProject Pages sitesでのコミットであること

私は初期の段階でメールアドレスの設定ができていなかったので、ターミナルで設定しました。
ローカルでのメールアドレスは以下で確認する事ができます。

$ git config user.email

GitHubに登録してあるメールアドレスは、Profileのsetting内のEmailsで確認する事ができます。

メールアドレスが合致していない場合は、ターミナルから以下の通りで設定を行います。

git config –global user.email “email@example.com“

時刻を合わせる（vagrant環境）

上記のメールアドレスの未設定エラーは、よくある事なのですが
vagrantを使用している場合、時刻の不具合によって生えないケースがあります。
vagrantを実行した後に下記のコマンドで時刻を確認。

$ date

初期のUTCの設定だと生えません。
またvagrant側とホスト側の時刻が合致していない場合でもダメです。
下記のサイトがとても参考になりました。
https://polidog.jp/2014/01/08/vagrant/

それでも生えない場合

上記を実行してもダメなケースもあります。

私は一度、vagrant実行時にエラーが起きてそれ以降、時刻がなぜかずっと止まったまま？になっていました。
その場合はこちらの記事を参考にすると良いです。
https://qiita.com/y0shihiro/items/13628b39e620354be6a3

記事内の注意点として通常のvagrant実行時にntpパッケージをアップロードしようとすると以下のエラーが出ます。

このコマンドを実行するには root である必要があります。

この場合、アップロードするには、管理者(root）の状態でないと実行できません。
ログイン後の最初の状態である[vagrant@localhost ~]の状態まで戻り
以下のコードを入力するとパスワードが求められます。

[vagrant@localhost ~]$ su –

パスワード:

パスワードの為、打ち込んでも表示はされませんが、中身はちゃんと打ちこまれています。
尚、パスワードとはvagrantのrootのパスワードの事で初期値は”vagrant”です。

[root@localhost vagrant]

この状態になったら、記事内の通りにアップロードを進めていく。

以上となります。
vagrantユーザーはGitHubの草はこまめにチェックしておいた方がいいかもしれません。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-10-13T13:03:12+09:00

git add できないときの対応方法

自分用のメモ書きです:fist:
間違っている等ありましたらコメントください！！

ことの発端として、、、
デザイナーさん「git add style.ccsできない...:frowning2:」
ということがありました。

☆対応方法

まず、プロジェクトのトップにある.gitignoreを確認
→同じファイル名や拡張子がないか確認しましょう。
→ない場合は下の解決策を試してみて下さい！

.DS_Storeが悪さしている

Mac用に.DS_Storeを.gitignoreに記述してあることがあります。
スクリーンショット 2020-10-13 12.58.15.png

解決策

.gitignoreから.DS_Store
を削除
↓
追加できなかったファイルがGitに認識されているか確認し

git add 対象ファイル

↓
.gitignoreに.DS_Storeを追記

設定かキャッシュが残っている

一度Git管理下にしたファイルは、.gitignoreや.git/info/excludeに管理を無視する設定があっても適用されません。
そういう場合にGitに追加の設定として、"assume-unchanged"としてあえて無視させている場合があります。
これが、ステージングできない理由の1つです。

解決策

ターミナルで、プロジェクトのTOPから下記コマンドを入力

$ git update-index --no-assume-unchanged ファイルパス

上記コマンドで認識されない場合
→キャッシュを削除し、最後のコミットからGitインデックスを再ロードさせます。
※"Stack Overflow"の直訳なので間違っていたらすみません。

$ git rm --cached ファイルパス
$ git reset ファイルパス

☆参考文献

https://qiita.com/arabian9ts/items/61cfe6a5e2655e857e23
https://qiita.com/usamik26/items/56d0d3ba7a1300625f92
https://stackoverflow.com/questions/16993082/why-doesnt-git-recognize-that-my-file-has-been-changed-therefore-git-add-not-w/24316479

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

日付別

タグ一覧