What's New Qiita

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

  • 投稿日：2020-07-03T22:09:44+09:00

ssh（公開鍵認証）の基礎知識

公開鍵とか秘密鍵とか色々ややこしいじゃないですか、
sshログイン使ってるけどちゃんと理解できていなかったので備忘録。

sshログインって

公開鍵認証方式を使って
「鍵を持っている人(パソコン)からのみ、一般ユーザーによるログインを許可する。」
という方式。

公開鍵認証方式でログインするには鍵が2つ必要になる。
パソコン側に置く秘密鍵ファイルと、サーバー側に置く公開鍵ファイル。
秘密鍵ファイルは人に知られてはいけない！！
公開鍵ファイルは、人に知られても良い(公開できる)ファイル。

この2つのファイルが揃って初めて公開鍵認証によるログインが可能になる。
公開鍵認証では、sshのログイン時に使ったパスワードの代わりに「パスフレーズ」を使用する。
サーバーへログインするパスワードと似たようなもので、自分が決めた文字列を設定できる。
これはサーバーへログインするためのものではなく、秘密鍵にアクセスするための秘密の文字列である。

要は鍵を持っていないPCからは簡単にログインできないということ！

sshの認証方式

SSHの主要な認証方式としてはパスワード認証方式と公開鍵認証方式がある。

パスワード認証方式
パスワード認証方式はデフォルトの認証方式で、ユーザー名とパスワードでログインする方式。
ユーザー名とパスワードは接続先OSのユーザーアカウントの情報が使用される。
公開鍵認証方式
公開鍵認証方式は公開鍵と秘密鍵の２つの鍵(キーペア)を使用した接続方式。
サーバーに公開鍵、クライアントに秘密鍵を置いて使用する。
公開鍵認証を使うとパスワード入力なしでログインする事が可能になる。
パスワード認証方式はサーバー側で明示的に無効にしていない限り使用できるが、セキュリティ的には脆弱なので無効にしている事も多い。

つまりは・・・

公開鍵認証を使うことによって
秘密鍵を持っているパソコンからの接続のみ許可し、鍵を持っていないパソコンからはログイン出来ないのでセキュリティが向上する。
一方で、
・鍵を作成したり管理する手間がかかる。
・パソコンの故障や紛失などで秘密鍵を紛失したら、再び鍵を作りなおさないといけない。
・どこからでも接続できない。
といったデメリットも。。。

公開鍵認証はセキュリティを向上させるための仕組みだということ！

参考文献
よく分かる公開鍵認証」～初心者でもよくわかる！VPSによるWebサーバー運用講座(2)

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

自動デプロイで目指す効率的な開発

問題点

  • 開発を始めるまでが大変（新規メンバー、3ヶ月後の自分）
  • アップロードが衝突する（開発用サーバ）
  • 先祖返り（デグレード）
  • Issueベースでタスクを振りたい
  • バグが起きた時点を知りたい

デプロイで解決

  • 開発を始めるまで
    • Gitさえ分かればデプロイされる
  • アップロード衝突
    • Gitのブランチで独立

デプロイで解決

  • 先祖返り（デグレード）
    • 手動アップロードからの解放
  • タスクベースでタスクを振りたい
    • GitのIssueとPR、デプロイの紐付け
  • バグ発生時
    • リリースをそれぞれデプロイ

開発を始めるまで

  • 新規メンバーに環境を揃えてもらいたい

    • 修正箇所は検討がつくのに整備が大変
    • 3ヶ月前のコードがわからない
    • 3年前のコードは全然分からない?

  • 自動デプロイ?

    • Gitさえコミットできればデプロイされる
    • 一部のロジックに注力できる

アップロード衝突

  • 同時に開発環境を使うことができない

    • 「作業を止めてもらっていいですか？」
    • 3人ぐらいならまだしも、5人、10人となると…
    • どこにテストしているかわからない

  • 自動デプロイ?

先祖返り（デグレード）?

  • 先祖返りを起こしてしまう

    • アップロードした人が古いファイルを持っていた
    • ファイル管理が大変
    • Gitの導入だけでもかなり解決するが、手動部分でオペミス

  • 自動デプロイ?

    • アップロードは「必ず」Gitのものをアップする
    • Gitに必ず注力することになる

Issueベースでタスクを振りたい

  • Issueベース

    • 「料金計算の修正」「フッターデザインの修正」
    • Gitのブランチ化、マージで衝突を防ぐ
    • それぞれ同時並行で進むと確認が大変（アップロード衝突と同じく）

  • 自動デプロイ?

    • Gitブランチごとに独立したデプロイ

バグが起きた時点を知りたい

  • 「今回の修正をお願いしたところ、全部の計算がおかしくなりました」

    • 今回の修正が計算をおかしくしたのか、もともとそうだったのか
    • 「お客様への説明責任」と「原因の追跡」を行いたい
    • 旧バージョンをアップすれば再現

  • 自動デプロイ?

自動デプロイ

  • 開発の問題を解決し、持続的な開発を行いたい
  • ソフトウェアの寿命
    • 開発者「2年」　発注者「10年」
    • ただし長年のメンテは大変…
  • 開発者のスケールアウト

開発者のスケールアウト

  • 開発メンバーを増やしたい -> 開発者のスケールアウト

    • テストの自動化、チームの組織化

  • タスクの分割を行えばスケールできる

    • イメージとしてはWordPressのプラグインのようなエコシステム（相互独立性）

まとめ

  • 開発を取り巻く環境を良くしたい

  • より良いシステムを より安価に提供したい

    • 利用者の利益につなげたい

  • 更に先

    • システムテスト自動化
    • テストエンジニアのスケール
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-07-03T13:44:14+09:00

Git

Git revert
https://qiita.com/chihiro/items/2fa827d0eac98109e7ee

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

Masterブランチへのmergeを取り消して再度mergeする手順

Git revert

commitを打ち消す

$ git revert <commit ID>

参考サイト
【gitコマンド】いまさらのrevert

開発環境で

$ git pull origin revert-branch

問題のあるコードを修正し、

$ git push origin rever-branch

Git lab or Git hub上で

revert-branchのMergeRequestからmasterにmergeする。

以上

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

Git 超基礎 基本コマンド学習記録

これは個人の学習メモです

どんな記事か

git コマンドの超基礎。

会社で学習したことと、自分のブログ (https://kei-s-lifehack.hatenablog.com/) の記事を統合した

image.png

基本コマンド (add, reset, commit, push)

add, index に追加

全て add する

git add .

git の管理下(index)に全部足す, add all

1ファイルだけ add する

git add hoge.txt

hoge.txt一個だけ管理下に置くとき, Add just the file　
create-react-app などでプロジェクトを作成したとき、最初に .gitignore をあげるときによく使う

.gitignore とは

node_modules など、** git 管理下におかないもの ** は.gitignore に記載する

参考
".gitignore file - ignoring files in Git | Atlassian Git Tutorial"

また、.gitignore に node_modules を新しく記載しても node_modules を
git add . で一緒に index に add すると反映されないで node_modules も push されてしまう。

なので前述のように先に .gitignore のみ先に commit する必要がある

git reset

git reset

以前の状態に戻す

commit, 差分記録

git commit

前回の commit からの差分を現在のブランチの内部に記録する

push, リモートブランチへの押し出し

git push <HEAD> <branch>

commit を 主にリモート (origin) の feature ブランチに送る。

なおチーム開発では master への直 push は NG なので注意
rebase や reset でなかったことにできるが、まとめて編集すると非常に面倒くさいことになるので
そもそも 作業ごとに commit を分割しておくこと が非常に重要である

pull, リモートから引っ張ってくる

git pull <HEAD> <branch>

リモートの方が新しい場合，その内容をパソコンの内部(ローカル)に
引っ張ってくる。ブランチなどを作成する時に先にしておかないとコミットが絡まって首が絞まる

stash, 一時待避

git stash

参考
【git stash】コミットはせずに変更を退避したいとき

「とあるブランチで作業中だけど、いますぐやりたいことができた。
作業すごく中途半端だからコミットはしたくない。」
というときに、stashが使えます。
stashを使用すると、コミットしていない変更を退避することができます。
stashで変更を退避させて、今すぐやりたい作業をして、退避させていた変更を戻して作業を再開することができます。

コミットしていない変更がある状態で上記のコマンドを実行すると、変更した部分が退避されます。
コミットしていない変更とは、addしたものもaddしていないものもどちらも含まれます。
ブランチは変更が取り消されたきれいな状態となります。

commit するまでもない変更を退避させる。
他のブランチに行く前にワーキングディレクトリに変更があって commit したくない時はこれをしないと動けない。
stash に保存して、ワーキングディレクトリを、最後に commit されている地点まで巻き戻す。

git stash
Saved working directory and index state WIP on 20200708-daily-report: 9ecbd48 applied report template

commit してないファイルの変更を退避して、最後の commit の変更までワーキングディレクトリを巻き戻した。

以下のコマンドで退避した作業の一覧を見ることができます。

git stash list
// こんな感じで出力されます
stash@{0}: WIP on test: xxxx
stash@{1}: WIP on commit-sample: xxxx

stash@{X}がstashの名前で、WIP onのあとはブランチ名です。xxxxはstashをしたときのHEADのコミットハッシュとコミットメッセージになります。

git stash apply

これで git stash をする前に戻せる。

git fetch

git fetch <HEAD> <branch>

参考
https://www.git-tower.com/learn/git/faq/difference-between-git-fetch-git-pull

git fetch really only downloads new data from a remote repository
but it doesn't integrate any of this new data into your working files

  • git fetch は リモートリポジトリから 新しいデータ(変更)をダウンロードするだけ
  • ダウンロードした新しいデータを、ワーキングファイル（ワーキングディレクトリ）に統合することはない

git pull, in contrast, is used with a different goal in mind:

  • 対して git pull は 全く違うゴールで作られている

to update your current HEAD branch with the latest changes from the remote server.

  • 現在の HEAD ブランチをリモートサーバーの最新の変更に更新する(というゴールだ)

だからよく pull は fetch と merge だと言われるのだな。

URL 操作, remote 設定

git remote -v

一番使う．
今の push 先の URL を確かめる: 

git init

.git/ の初期化．新しく git 連携のレポジトリを作る時に行う

git remote add origin yourURL

https://github.com/new

などで作成した push 先のリモートブランチがある場合，
そこの URL をローカルブランチの push 先に追加できる

例えば ユーザー の hoge-blog というリポジトリを SSH でリモート設定する場合は

git remote add origin git@github.com:kaede0902/hoge-blog.git

となる。

git remote set-url origin NEWURL

リモートの URL が予め設定されていて、それを変更するときはこっち

CONFIG設定

config 確認

参考
https://docs.github.com/en/github/using-git/setting-your-username-in-git

git config --global user.name

で現在の username が返ってくる
e-mailも同様。

また，コマンドではなくconfig fileを直接開ける．

vi .git/ すると

.git/config にこういうのがある．

.git/config
    [remote "origin"]
        url = https://yourusername@github.com/yourusername/repositoryname.git  
        fetch = +refs/heads/*:refs/remotes/origin/*  
    [branch "master"]  
        remote = origin  
        merge = refs/heads/master  
    [user]  
        name = yourusername  
        email = your@adress

url が https のままだと毎回作業時にユーザーネームとパスワードを聞かれて面倒なので，

ssh の設定をして書き換えておくと楽。

git commit -m でnanoが開いてしまう場合

私はあまり nano を使いたくないので default を vim にしたかった

参考
https://qiita.com/wnoguchi/items/f7358a227dfe2640cce3

これで 

git config --global core.editor 'vim -c "set fenc=utf-8"'

をしておけばコミットメッセージなしでコミットしても，自動的に vim が開いてくれる

（私はメッセージ付きコミットより，vim開いてメッセージ書いた方がやりやすいので、コミットメッセージなしで git commit で vim でコミットメッセージを 開く場合が多い。）

以上です。

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

私的、Macのターミナル（Bash）外観設定

※フォントのインストール手順が古かったので修正しました！

こんにちは。
MacbookPro2016のキーボードがチャタって辛いyagrushです...
これはだめかもわからんね...

Silicon搭載MBPを待った方がいいんでしょうか...?
買い時がすごく難しいタイミングですね...

さて、もはや完全に私的メモですが:sunglasses:
Macのターミナルを↓な風にしたい方、ご参考になれば幸いです。
カレントディレクトリがGitリポジトリの場合、ブランチ名も表示されます。
スクリーンショット 2020-07-03 14.45.21.png

（MBP君がやたらzshをお勧めしてくるけど、Windows作業もあったりするので私はbashを使っています。）

必要なもの

  • Mac（筆者側では、MBP2016のmacOSをCatalinaにアップグレードしたもので検証しました。）
  • Homebrewを導入済みである。
  • Git ... Homebrewなどでインストール済みである。

手順（おおまかに３つ）

1. クールなMacターミナルテーマIcebergのインストール

https://cocopon.github.io/iceberg.vim/
こちらの公式サイトのした〜〜〜〜の方に、Mac用ダウンロードボタンがあります。

ダウンロードしたZIPを解凍するとiceberg.terminalがあるので、ターミナルの設定画面でインポートするか、ダブルクリックしてください。（「ネットからダウンロードした信用できないファイルです！」ってMacOSが怒るかもですが、無視して【開く】でOK。）

ターミナルのデフォルトテーマをIcebergに変更する

ターミナルの設定画面を開きIcebergを選択した状態で【デフォルト】ボタンを押す。

スクリーンショット 2020-07-03 12.32.41.png

2. coolなフォントSF Mono Squareのインストール

https://github.com/delphinus/homebrew-sfmono-square
これほんとすき...フォントだけに（激ウマギャグ）

DLとかしなくてもHomebrewでコマンドでインストールできちゃいます。
ターミナルで以下のコマンドを順番に実行していってください。

xcode-select --install

brew upgrade

brew tap delphinus/sfmono-square

# これ結構時間かかります
brew install sfmono-square

open "$(brew --prefix sfmono-square)/share/fonts"
# Finderでフォントファイルが４つ入っているディレクトリが表示されるので、
# １つずつダブルクリックして【インストール】ボタンを押していく。

ターミナルのフォントを変更する

ターミナルの設定画面でIcebergを選択した状態でフォントの【変更】ボタンを押してSF Mono Squareに変更する。（フォントインストールに成功していれば、フォントリストのSF Monoの下にSF Mono Squareが居るはずです。）
太さ/スタイル/サイズなどは好みに合わせてください。

スクリーンショット 2020-07-03 12.41.54.png

3. 色設定などを反映させるコードを仕込む

ターミナル(Bash)起動時に必ず読み込まれるファイルに、色設定などを反映するコードを仕込んでいきます。

~/.bashrcを編集する

vimなどのテキストエディタを使って、

vim ~/.bashrc

~/.bashrcに以下の設定を追記します。
もし~/.bashrcが無かったら、そのまま新規作成でOK。

~/.bashrc
source /usr/local/etc/bash_completion.d/git-prompt.sh
source /usr/local/etc/bash_completion.d/git-completion.bash
GIT_PS1_SHOWDIRTYSTATE=true

HOST='\u@\h'
PS1="\[\033]0;$HOST\007\]"     # set window title
PS1="$PS1"'\n'                 # new line
PS1="$PS1"'\[\033[32m\]'       # change color
PS1="$PS1"'\u@\h '             # user@host<space>
PS1="$PS1"'\[\033[33m\]'       # change color
PS1="$PS1"'\w'                 # current working directory
if test -z "$WINELOADERNOEXEC"
then
    PS1="$PS1"'\[\033[36m\]'
    PS1="$PS1"'$(__git_ps1)'   # bash function
fi
PS1="$PS1"'\[\033[0m\]'        # change color
PS1="$PS1"'\n'                 # new line
PS1="$PS1"'$ '                 # prompt: always $

# "-F":ディレクトリに"/"を表示 / "-G"でディレクトリを色表示
alias ls='ls -FG'
alias ll='ls -alFG'

~/.bash_profileを編集する

vimなどのテキストエディタを使って、

vim ~/.bash_profile

~/.bash_profileに以下の設定を追記します。
もし~/.bash_profileが無かったら、そのまま新規作成でOK。

~/.bash_profile
if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

設定を反映する

以下のコマンドを打ってください。

source ~/.bashrc

どうでしょう、即座に変わりましたか？
もちろん、今後は起動しただけでもこうなってくれます。

参考記事

ありがとうございます！

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

私的、Macのターミナル（Bash）外観おすすめ設定

※フォントのインストール手順が古かったので修正しました！

こんにちは。
MacbookPro2016のキーボードがチャタって辛いyagrushです...
これはだめかもわからんね...

Silicon搭載MBPを待った方がいいんでしょうか...?
買い時がすごく難しいタイミングですね...

さて、もはや完全に私的メモですが:sunglasses:
Macのターミナルを↓な風にしたい方、ご参考になれば幸いです。
カレントディレクトリがGitリポジトリの場合、ブランチ名も表示されます。
スクリーンショット 2020-07-03 14.45.21.png

（MBP君がやたらzshをお勧めしてくるけど、Windows作業もあったりするので私はbashを使っています。）

必要なもの

  • Mac（筆者側では、MBP2016のmacOSをCatalinaにアップグレードしたもので検証しました。）
  • Homebrewを導入済みである。
  • Git ... Homebrewなどでインストール済みである。

手順（おおまかに３つ）

1. クールなMacターミナルテーマIcebergのインストール

https://cocopon.github.io/iceberg.vim/
こちらの公式サイトのした〜〜〜〜の方に、Mac用ダウンロードボタンがあります。

ダウンロードしたZIPを解凍するとiceberg.terminalがあるので、ターミナルの設定画面でインポートするか、ダブルクリックしてください。（「ネットからダウンロードした信用できないファイルです！」ってMacOSが怒るかもですが、無視して【開く】でOK。）

ターミナルのデフォルトテーマをIcebergに変更する

ターミナルの設定画面を開きIcebergを選択した状態で【デフォルト】ボタンを押す。

スクリーンショット 2020-07-03 12.32.41.png

2. coolなフォントSF Mono Squareのインストール

https://github.com/delphinus/homebrew-sfmono-square
これほんとすき...フォントだけに（激ウマギャグ）

DLとかしなくてもHomebrewでコマンドでインストールできちゃいます。
ターミナルで以下のコマンドを順番に実行していってください。

xcode-select --install

brew upgrade

brew tap delphinus/sfmono-square

# これ結構時間かかります
brew install sfmono-square

open "$(brew --prefix sfmono-square)/share/fonts"
# Finderでフォントファイルが４つ入っているディレクトリが表示されるので、
# １つずつダブルクリックして【インストール】ボタンを押していく。

ターミナルのフォントを変更する

ターミナルの設定画面でIcebergを選択した状態でフォントの【変更】ボタンを押してSF Mono Squareに変更する。（フォントインストールに成功していれば、フォントリストのSF Monoの下にSF Mono Squareが居るはずです。）
太さ/スタイル/サイズなどは好みに合わせてください。

スクリーンショット 2020-07-03 12.41.54.png

3. 色設定などを反映させるコードを仕込む

ターミナル(Bash)起動時に必ず読み込まれるファイルに、色設定などを反映するコードを仕込んでいきます。

~/.bashrcを編集する

vimなどのテキストエディタを使って、

vim ~/.bashrc

~/.bashrcに以下の設定を追記します。
もし~/.bashrcが無かったら、そのまま新規作成でOK。

~/.bashrc
source /usr/local/etc/bash_completion.d/git-prompt.sh
source /usr/local/etc/bash_completion.d/git-completion.bash
GIT_PS1_SHOWDIRTYSTATE=true

HOST='\u@\h'
PS1="\[\033]0;$HOST\007\]"     # set window title
PS1="$PS1"'\n'                 # new line
PS1="$PS1"'\[\033[32m\]'       # change color
PS1="$PS1"'\u@\h '             # user@host<space>
PS1="$PS1"'\[\033[33m\]'       # change color
PS1="$PS1"'\w'                 # current working directory
if test -z "$WINELOADERNOEXEC"
then
    PS1="$PS1"'\[\033[36m\]'
    PS1="$PS1"'$(__git_ps1)'   # bash function
fi
PS1="$PS1"'\[\033[0m\]'        # change color
PS1="$PS1"'\n'                 # new line
PS1="$PS1"'$ '                 # prompt: always $

# "-F":ディレクトリに"/"を表示 / "-G"でディレクトリを色表示
alias ls='ls -FG'
alias ll='ls -alFG'

~/.bash_profileを編集する

vimなどのテキストエディタを使って、

vim ~/.bash_profile

~/.bash_profileに以下の設定を追記します。
もし~/.bash_profileが無かったら、そのまま新規作成でOK。

~/.bash_profile
if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

設定を反映する

以下のコマンドを打ってください。

source ~/.bashrc

どうでしょう、即座に変わりましたか？
もちろん、今後は起動しただけでもこうなってくれます。

参考記事

ありがとうございます！

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

Gitの「--color-moved」オプションがかなり便利だったの紹介してみる

Gitの --color-moved オプションで、 移動だけの差分をいい感じに表示する ことができ 、かなり便利だったので紹介してみようと思います。
https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---color-movedltmodegt

ちなみに2年くらい前からあるようですが、最近知りました :innocent:
https://www.infoq.com/jp/news/2018/04/git-2.17-released

※ 本記事のサンプルでは、Gitのバージョンは2.24.3、シェルはfishを使っています。

サンプル

例えば以下のようなクラスがあった場合。

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }

    override fun onCreateOptionsMenu(menu: Menu): Boolean {
        menuInflater.inflate(R.menu.menu_main, menu)
        return true
    }

    override fun onOptionsItemSelected(item: MenuItem): Boolean {
        return when (item.itemId) {
            R.id.action_settings -> true
            else -> super.onOptionsItemSelected(item)
        }
    }
}

onOptionsItemSelected を一番上に移動したい、となった場合、オプション無しの diff だと…
スクリーンショット 2020-07-02 14.28.20.png
元の位置にあった onOptionsItemSelected の削除と、新しい位置への onOptionsItemSelected の追加が表示されることになります。

しかしながら、 diff --color-moved=dimmed_zebra とした場合は…
スクリーンショット 2020-07-02 14.28.37.png
移動だけの差分なため、グレーアウトされた表示になります…！（かなりわかりやすい:grinning:）

さらに便利なところがありまして、ただの移動のつもりが

R.id.action_settings -> true

を

R.id.action_settings -> false

に間違って変えてしまっていた場合は…
スクリーンショット 2020-07-02 14.28.54.png
移動したところだけはグレーアウト、変更があったところは通常の差分表示、とかなりいい感じに表示してくれます:clap:

オプション無しと --color-moved=dimmed_zebra を付けた時を比べてみると一目瞭然。かなり便利では…！

なし あり
スクリーンショット 2020-07-02 14.44.53.png スクリーンショット 2020-07-02 14.28.54.png

モードは6つ

サンプルでは dimmed_zebra を使っていますが、 --color-moved のモードとしては

no , default , blocks , zebra , dimmed-zebra , plain

の6つを指定可能です。（ no はハイライトなし、 default は zebra と同じなため、実質4つ。）

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---color-movedltmodegt

個人的には dimmed-zebra が一番いいのかなと思いますが、 派生元の blocks には

Blocks of moved text of at least 20 alphanumeric characters are detected greedily.

という条件があり、うまく移動の差分として表示されないケースもあるため、適宜モードを使い分ける必要がありそうです。

終わりに

Gitの --color-moved オプションで、移動の差分をいい感じに表示できることをご紹介しました。
このオプション自体は2年くらい前からあるようなので、まだまだ知らない便利なオプションがGitにはあるんだなと思いました。

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

日付別

タグ一覧