20190203のGitに関する記事は9件です。

git commitとgit pushの前に自動lintをかけて失敗したら中断する

CircleCIで自動テスト・lintチェックなどをかけてる現場で、ローカルでいちいちlintかけるの面倒臭い。
みたいなのがあると思います。

ファイル変更のたびに走らせる必要はないし、ローカルでgitの操作をフックに勝手にやってくれたら便利なのにな。
みたいなモチベーションがあって、探したところhuskyが便利そうだった。

huskyを使う

git commit, git pushをフックに任意のコマンドを実行できる。
v1.0.0以降では.huskyrcを作成してそこに設定を書くだけ。

https://github.com/typicode/husky#readme

yarn add -D husky

例えば自動lintをかけたい場合は
package.jsonにlintのコマンドを定義しといて、husky経由で呼べば
git commitをフックに自動lintをかけられる。

".huskyrc"
{
  "hooks": {
    "pre-commit": "yarn test",
    "pre-push": "yarn es-lint"
  }
}

コマンドが失敗したらcommit/pushされないので、lintかけ忘れもなくなって便利です。
lint以外でも、push前に何かちょっとした処理を入れる必要がある場合に使えそうですね。

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

WindowsでGitを利用する

WindowsでGitを利用する

Windows10でGitを利用するために、公式なビルドであるGit for Windowsを導入する。
Git for WindowsはCUIなので、確認やわかりやすさの観点からGUIのGitもインストールする。
GUIとしては、TortoiseSVNで慣れ親しんでいる人も多いであろうTortoiseGitを使う。

検証環境

  • Windwos 10 Home 1803
  • Git-2.20.1-64-bit
  • TortoiseGit-2.7.0.0-64bit

ダウンロード

Git for Windows

インストール時の注意点

今回はインストーラによるチェックボックスなどはデフォルトのままイントールしたが、
以下の点にこだわりがある場合は注意が必要。

  • エクスプローラーの右クリック設定をいじられたくない。
  • Bash以外のシェルを利用している。
  • Vim以外のエディターを利用したい。
  • PATH設定をいじられたくない。
  • チェックアウト時に改行コードをいじられたくない。(CRLF⇒LF)

Gitインストーラの画面

image.png
image.png
image.png
image.png
image.png
image.png
image.png

TortoiseGit

デフォルト設定のままイントール。インストール完了画面では、
「Run first start wizard」にチェックがついており、続けて
first start wizardでの設定を行う。

first start wizard

first start wizardで設定できる項目は以下の通り。
それぞれ別途設定可能なので、あせらなくてOK。

  • 言語設定
  • git.exeのPATH指定
  • gitconfigのName、Email設定。(git configで実施可能)
git config --global user.email "メールアドレス"
git config --global user.name "名前"
  • 公開鍵認証のキーペアの生成(bin\puttygen.exeから実施可能)
  • 認証情報の保存設定(Credential helperの設定(git configで実施可能))
git config --global credential.helper manager

TortoiseGitインストーラの画面

image.png
image.png
image.png
image.png
image.png

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

VSCodeでgitのconflictを解消させる話

目的

今回は以下を行っていきます。

  • gitでconflictが発生する状況をちょっとだけ理解してみる
  • 実際にconflictを発生させてみる
  • 発生したconflictをVSCode上で解決してみる

※間違いや分かりにくい点は、どんどん指摘してもらえると助かります。(お手柔らかによろしくお願いします。。)

conflictって何??

 Untitled Diagram (1).png

簡単にconflictの発生する可能性のある作業フローのイメージを用意しました。
以下の手順で作業していくと仮定します。
1. まず、Masterを元にしてBranch_AとBranch_Bを作成します。
2. Branch_Aで、あるファイル(ここでは、conflict.txtとしておきます。)を修正します。
修正した分をcommitしてMasterにPullRequestを行います。
Masterに対して変更分をマージします。
3. 次にBranch_Bでの作業に移ります。ここでもconflict.txtを修正します。(Branch_Aでの修正とは異なるようにすること)
修正が完了したらcommitして、MasterにPullRequestを行います。

これでconflictが発生します。
つまり、複数人で開発している際に各々が別々のファイルで作業している分にはMasterに対して変更分がそのまま吸収されていきますが
同じファイルを修正していた際に、どちらの修正をMasterに反映させるか(あるいは、どちらの修正も反映させる)を判断してねと言われるのがconflictです。
conflictを日本語にすると『衝突』と言う意味になります。

実際にconflictを発生させてみよう!

理解できているかを判定するのに、自分の環境でも発生させてみます。

①Branch_Aで修正

スクリーンショット_2019-02-03_16_49_02.png

今回はconflict.txtに文章を追加しています。
これをcommitしてGitHub上でPullRequestをします。
今の段階ではconflictが発生しないので、そのままmergeします。

スクリーンショット_2019-02-03_17_03_34.png

②Branch_Bで修正

スクリーンショット_2019-02-03_17_31_27.png

①と同様にconflict.txtに文章を追加しています。
これをcommitしてGitHub上でPullRequestをします。

スクリーンショット_2019-02-03_17_35_35.png

conflictが発生しました。
ここからは、VSCode上でconflictの原因を調査していきます。

VSCode上でconflict解消を行う

具体的には以下の手順で行います。
1. ローカルに保存してあるmasterを最新にする
2. Branch_Bに対して、masterをMergeする
3. Mergeした際にBranch_B上でconflictが発生して、VSCode上で確認できるので解消する
4. 解消した分をcommitしてPushして、MergePullRequestができるようになっていることを確認

1.ローカルに保存してあるMasterを最新にする

masterに移動 git checkout master
masterの最新を取得 git pull

2. Branch_Bに対して、masterをMergeする

Branch_Bに移動 git checkout Branch_B
Branch_BにmasterをMergeする git merge master

3. Mergeした際にBranch_B上でconflictが発生して、VSCode上で確認できるので解消する

 スクリーンショット_2019-02-03_17_59_45.png

Accept Both Changeを選択します。

4. commitしてPush、MergePullRequestができるようになっていることを確認

あとは、MergePullRequestをして完了!

スクリーンショット_2019-02-03_18_18_28.png

まとめ

今回は単純なconflictを発生させて、それを解消する手順をまとめてみました。
しかし、ファイルの編集でのconflict以外にもファイルの存在に関わるconflictもあります。
色々なパターンを再現してみて、実務に役立てればいいかなと思っています。

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

first commit が古い順でファイルの一覧を取得する

$ git ls-files *.php | xargs -n1 -I{} git log --reverse -1 --format='%cd {}' --date=short {} | sort

1 ファイルごとに git log するので、ファイル数が多いと重い。以下のように出力される。

  :
2015-10-07 src/.../a.php
2016-10-07 src/.../b.php
2017-10-07 src/.../c.php
  :

日付が不要なときは --format%cd (committer date) を消せば OK。

そもそもの動機としては会社で、first commit が古い --> 技術的負債がたまっている可能性あり? --> リファクタのしがいがあるかも、という考えに至ったため。
負債の程度は first commit date だけでなく、コミットの総数や修正行数なども判断材料として使えそうだけど、ただでさえ重い処理に拍車がかかりそうなので一旦見送り…。

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

EclipseのGit連携機能を無効化する

コンソールから自分でコントロールしたいのですが、Eclipseは例えばファイルをリネームすると自動でgit mv相当のことをやってくれたりお節介です。

これを無効化します。

インポートしたプロジェクトが自動でGit機能を有効化されるるのを防ぐ

初期状態だと.gitディレクトリがあるプロジェクトを取り込むと自動でGit連携してしまいますが、取り込み時自動連携しないように設定します。

  1. Preferences を開き、 Team > Git > Projects と辿ります。
  2. 右側の Projects から、 Automatically share projects located in a Git repository のチェックを外します。

git01.png

既にインポートしたプロジェクトのGit連携機能を無効化する

上記の設定は、これからインポートするプロジェクトに対する設定です。
既にインポートしたプロジェクトに対しては効果がありません。

既にインポートしたプロジェクトに対しては、次の通りプロジェクトごとの設定で無効化します。

  1. Package Explorer でプロジェクトを右クリックし、 Team > Disconnect を選択します。

複数のプロジェクトを同時に選択しても設定可能です。

git02.png

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

gitの使い方 - githubの新規リポジトリと紐付ける方法

gitとは

webサイト・アプリなどを複数人で協力して開発するときに便利なバージョン管理システム
簡単に説明すると、複数人で協力しながらWebサイトなどを開発する時に、Gitを使うと共同開発がスムーズに進められるから便利という話
(もちろん、1人で開発するときも履歴が残るので便利)

用語

  • リポジトリ
    • ファイルやディレクトリの履歴を管理している場所
  • ローカルリポジトリ
    • 自分のPC内で作業するために作成したリポジトリ(基本的に作業はここでしかしない)
  • リモートリポジトリ
    • githubなどのネット上に作成したリポジトリ(基本的に、ここが最新のリポジトリになっているイメージ)
  • ブランチ
    • 全体に影響を与えないために、gitで分岐させて安心して開発できるようにする機能
  • Masterブランチ
    • 大元のブランチのこと(チーム開発の時は、ここでの作業はNG)
  • マージ
    • ブランチを統合(別々のブランチをくっつけること)
  • コンフリクト
    • 同じ箇所を別々のブランチで変更させた後にマージすると、gitがどっちが正しいかわからなくてエラーになること

Gitを使うには

1. Git はターミナルで操作するのが基本

mac既存のターミナルもいいけどオススメは 『iterm 2
設定でいじれば、好きなショートカットコマンドを入力すると現在のデスクトップ上にフルスクリーンでターミナルを表示させたり消したりすることができるので、結構重宝してます
(見た目がカッコイイのも良いw)
※iterm 2の設定の方法はここの記事がオススメです
※コマンドは苦手だという人はコマンドを使わないSourcetreeの使い方を参考にしてください

2. GitHubでレポジトリを1つ作成する

GitHubでアカウントを作成してリポジトリを1つ作成しておく
※最近GitHubは、無料個人アカウントでも他の人に見られないPrivateリポジトリが作成できるようになったので、ありがたすぎます
※GitHub以外にGitLabなど他のバージョン管理のサービスもあります

gitで開発する時の流れ

あくまでも僕個人の方法なので、人やチームによって方法が違う場合も多々あるかと思います

個人だけで開発する場合

リモートリポジトリとローカルリポジトリの準備(最初の1回だけでOK)
  1. GitHubで新規のリポジトリを作成する
  2. 自分のPCでディレクトリを作成して、軽く作業する(index.thmlなど簡単に作成してみる)
  3. 作成したディレクトリをGitリポジトリに変換する(リモートリポジトリにアップロード:コマンドの①)
リモートリポジトリと紐付けたあとの流れ
  1. ローカルリポジトリで作業する
  2. 作業した内容をリモートリポジトリに共有する準備(コマンドの⑤)
  3. リモートリポジトリに反映させる(コマンドの⑥)

複数人で共同開発する場合

リモートリポジトリとローカルリポジトリの準備(最初の1回だけでOK)
  1. GitHubで新規のリポジトリを作成する
  2. 自分のPCでディレクトリを作成して、軽く作業する(index.thmlなど簡単に作成してみる)
  3. 作成したディレクトリをGitリポジトリに変換する(リモートリポジトリにアップロード:コマンドの①)
  4. チーム開発の時は1人がリモートリポジトリを作るので、他の人はローカルリポジトリにクローンを作れば共同開発の準備OK(コマンドの②)
リモートリポジトリと紐付けたあとの流れ
  1. 自分のローカルリポジトリを最新のリモートリポジトリに変更する(コマンドの③)
  2. 新しい作業をするためのブランチを作る(コマンドの④)
  3. 切ったブランチで作業する
  4. 作業した内容を共有する準備(コマンドの⑤)
  5. 最新のリポジトリをダウンロードしてコンフリクトがないか確認する(コンフリクトがあった時は修正してから再度共有する準備をする)(コマンドの③と⑤)
  6. リモートリポジトリに反映させる(コマンドの⑥)
  7. リモートリポジトリでプルリクエストを送る(GitHub内での話:参考サイト
  8. Masterブランチに戻る(コマンド④の2.)
  9. 自分以外のチームの人に確認してもらって、問題なければMasterブランチにマージしてもらい、リモートリポジトリを更新してもらう(参考サイト内の『GitHub のWebサイト上で、「Marge pull request」する』がわかりやすいかと)

gitのコマンド

上で書いた開発する時の流れで必要なgitコマンド +αで便利なgitコマンド一覧です
($ではじまるのがコマンド)

// ①作成したディレクトリをGitリポジトリに変換する方法
// 下のコマンドを順番に打つだけ(必ずルートディレクトリで作業をする)
$ git init
$ git ass .
$ git commit -m "first commit"
$ git remote add origin URL
$ git push origin master
※URLはGitHub内にある緑色のボタンをクリックすると表示される
※"first commit"はなんでもOK(自分がわかりやすい言葉で)



// ②リモートリポジトリをローカルリポジトリにクローンする方法
$ git clone URL
※URLはGitHub内にある緑色のボタンをクリックすると表示される



// ③自分のリポジトリを最新のリモートリポジトリに変更する
$ git pull origin master



// ④ブランチをきる(新しいブランチを作成して移動する方法)
// 1.新しいブランチを作る
$ git branch 新しいブランチ名

// 2.ブランチを移動する
$ git checkout 移動したいブランチ名

// 3.上の1,2をまとめて1回でやる方法
$ git checkout -b 新しいブランチ名
※このコマンドで新しいブランチを作ったうえで、そのブランチに移動できる



// ⑤作業した内容を共有する準備
// 1.共有したいファイルを追加する
$ git add ディレクトリ名
※追加したいディレクトリ名の数だけコマンドをたたく
※オススメはしないけど、下のコマンド1回だけでまとめて追加できる
$ git add .

// 2.追加した内容を保存(コミットという)する
$ git commit -m "コメント"
※コメントには自由に書いてOK(何を追加するかや、変更したことなどを書くとわかりやすい)



// ⑥リモートリポジトリに反映させる
// 1.個人開発の場合
$ git push origin master
※Masterブランチに直接変更内容を反映させる

// 2.共同開発の場合
// 絶対にMasterブランチでの作業・更新はNG
// ブランチで作業している前提
$ git push origin ブランチ名



// その他、便利なコマンド

// 自分が変更したファイルのファイル名を表示する
$ git status

// 自分が変更した変更内容(コード)を表示する
$ git diff

// コミットの履歴を表示する
$ git log
※下のコマンドにするとコミットの履歴+変更内容も表示できる

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

gitの使い方 - GitHubの新規リポジトリと紐付ける方法

gitとは

webサイト・アプリなどを複数人で協力して開発するときに便利なバージョン管理システム
簡単に説明すると、複数人で協力しながらWebサイトなどを開発する時に、Gitを使うと共同開発がスムーズに進められるから便利という話
(もちろん、1人で開発するときも履歴が残るので便利)

用語

  • リポジトリ
    • ファイルやディレクトリの履歴を管理している場所
  • ローカルリポジトリ
    • 自分のPC内で作業するために作成したリポジトリ(基本的に作業はここでしかしない)
  • リモートリポジトリ
    • githubなどのネット上に作成したリポジトリ(基本的に、ここが最新のリポジトリになっているイメージ)
  • ブランチ
    • 全体に影響を与えないために、gitで分岐させて安心して開発できるようにする機能
  • Masterブランチ
    • 大元のブランチのこと(チーム開発の時は、ここでの作業はNG)
  • マージ
    • ブランチを統合(別々のブランチをくっつけること)
  • コンフリクト
    • 同じ箇所を別々のブランチで変更させた後にマージすると、gitがどっちが正しいかわからなくてエラーになること

Gitを使うには

1. Git はターミナルで操作するのが基本

mac既存のターミナルもいいけどオススメは 『iterm 2
設定でいじれば、好きなショートカットコマンドを入力すると現在のデスクトップ上にフルスクリーンでターミナルを表示させたり消したりすることができるので、結構重宝してます
(見た目がカッコイイのも良いw)
※iterm 2の設定の方法はここの記事がオススメです
※コマンドは苦手だという人はコマンドを使わないSourcetreeの使い方を参考にしてください

2. GitHubでレポジトリを1つ作成する

GitHubでアカウントを作成してリポジトリを1つ作成しておく
※最近GitHubは、無料個人アカウントでも他の人に見られないPrivateリポジトリが作成できるようになったので、ありがたすぎます
※GitHub以外にGitLabなど他のバージョン管理のサービスもあります

gitで開発する時の流れ

あくまでも僕個人の方法なので、人やチームによって方法が違う場合も多々あるかと思います

個人だけで開発する場合

リモートリポジトリとローカルリポジトリの準備(最初の1回だけでOK)
  1. GitHubで新規のリポジトリを作成する
  2. 自分のPCでディレクトリを作成して、軽く作業する(index.thmlなど簡単に作成してみる)
  3. 作成したディレクトリをGitリポジトリに変換する(リモートリポジトリにアップロード:コマンドの①)
リモートリポジトリと紐付けたあとの流れ
  1. ローカルリポジトリで作業する
  2. 作業した内容をリモートリポジトリに共有する準備(コマンドの⑤)
  3. リモートリポジトリに反映させる(コマンドの⑥)

複数人で共同開発する場合

リモートリポジトリとローカルリポジトリの準備(最初の1回だけでOK)
  1. GitHubで新規のリポジトリを作成する
  2. 自分のPCでディレクトリを作成して、軽く作業する(index.thmlなど簡単に作成してみる)
  3. 作成したディレクトリをGitリポジトリに変換する(リモートリポジトリにアップロード:コマンドの①)
  4. チーム開発の時は1人がリモートリポジトリを作るので、他の人はローカルリポジトリにクローンを作れば共同開発の準備OK(コマンドの②)
リモートリポジトリと紐付けたあとの流れ
  1. 自分のローカルリポジトリを最新のリモートリポジトリに変更する(コマンドの③)
  2. 新しい作業をするためのブランチを作る(コマンドの④)
  3. 切ったブランチで作業する
  4. 作業した内容を共有する準備(コマンドの⑤)
  5. 最新のリポジトリをダウンロードしてコンフリクトがないか確認する(コンフリクトがあった時は修正してから再度共有する準備をする)(コマンドの③と⑤)
  6. リモートリポジトリに反映させる(コマンドの⑥)
  7. リモートリポジトリでプルリクエストを送る(GitHub内での話:参考サイト
  8. Masterブランチに戻る(コマンド④の2.)
  9. 自分以外のチームの人に確認してもらって、問題なければMasterブランチにマージしてもらい、リモートリポジトリを更新してもらう(参考サイト内の『GitHub のWebサイト上で、「Marge pull request」する』がわかりやすいかと)

gitのコマンド

上で書いた開発する時の流れで必要なgitコマンド +αで便利なgitコマンド一覧です
($ではじまるのがコマンド)

// ①作成したディレクトリをGitリポジトリに変換する方法
// 下のコマンドを順番に打つだけ(必ずルートディレクトリで作業をする)
$ git init
$ git ass .
$ git commit -m "first commit"
$ git remote add origin URL
$ git push origin master
※URLはGitHub内にある緑色のボタンをクリックすると表示される
※"first commit"はなんでもOK(自分がわかりやすい言葉で)



// ②リモートリポジトリをローカルリポジトリにクローンする方法
$ git clone URL
※URLはGitHub内にある緑色のボタンをクリックすると表示される



// ③自分のリポジトリを最新のリモートリポジトリに変更する
$ git pull origin master



// ④ブランチをきる(新しいブランチを作成して移動する方法)
// 1.新しいブランチを作る
$ git branch 新しいブランチ名

// 2.ブランチを移動する
$ git checkout 移動したいブランチ名

// 3.上の1,2をまとめて1回でやる方法
$ git checkout -b 新しいブランチ名
※このコマンドで新しいブランチを作ったうえで、そのブランチに移動できる



// ⑤作業した内容を共有する準備
// 1.共有したいファイルを追加する
$ git add ディレクトリ名
※追加したいディレクトリ名の数だけコマンドをたたく
※オススメはしないけど、下のコマンド1回だけでまとめて追加できる
$ git add .

// 2.追加した内容を保存(コミットという)する
$ git commit -m "コメント"
※コメントには自由に書いてOK(何を追加するかや、変更したことなどを書くとわかりやすい)



// ⑥リモートリポジトリに反映させる
// 1.個人開発の場合
$ git push origin master
※Masterブランチに直接変更内容を反映させる

// 2.共同開発の場合
// 絶対にMasterブランチでの作業・更新はNG
// ブランチで作業している前提
$ git push origin ブランチ名



// その他、便利なコマンド

// 自分が変更したファイルのファイル名を表示する
$ git status

// 自分が変更した変更内容(コード)を表示する
$ git diff

// コミットの履歴を表示する
$ git log
※下のコマンドにするとコミットの履歴+変更内容も表示できる

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

git 困った場合のメモ

状態を把握するコマンド

status

git status 

commitとuntrackedの状態を確認できる

log

git log

commitの履歴を確認できる

ls-files

# 全ての管理済ファイルを表示
git ls-files -c

# ワークツリーで変更済のファイルを表示
git ls-files -m

# ワークツリーで削除済のファイルを表示
git ls-files -d

# 無視リストに載っているが管理済のファイルを表示
git ls-files -i --exclude-standard

# 全ての未管理ファイルを表示
git ls-files -o

# ワークツリーで新規作成されたファイルを表示
git ls-files -o --exclude-standard

# 無視リストに載っていて未管理のファイルを表示
git ls-files -io --exclude-standard

add の取り消し

git rm [file-name]

ローカルのファイルごと削除する。慎重に。

git rm -r --cached .

addの履歴のみ削除する

100MBを超えるサイズのファイル、ファイル群をpushしてしまいrejectされたとき

commitの履歴を調べる

git log

commitIDを確認

commitされる前の状態までさかのぼる

git reset --soft [commitID]

いつでも戻れるように、一番最初のcommitはreadmeだけにした方が良い。最初からメインのcommitするとそこでrejectされた場合戻れなくなる。

その場合は

git commit --amend 

でcommitを上書きする

gitignoreに100MB超えのファイル、ディレクトリを記載してcommitしなおす

git add .
git commit -m "commit modified"
git push origin master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Fish, ghq, peco導入

SourceTreeが苦手なのでgitコマンドを使いこなせるようになりたいです。
リポジトリが沢山あって大変なのでターミナル環境含めて環境構築をしました。

出来るようになること

  1. リポジトリを一つのディレクトリ配下で集中管理する(ghq)
  2. Ctrl+Gでリポジトリ一覧表示、検索、ディレクトリ移動(fish-ghq + peco)
  3. Ctrl+rでコマンド履歴検索(plugin-peco)
  4. fish_configなどカスタマイズはお好みで

手順

  1. fishインストール
  2. pecoインストール
  3. ghqインストール
  4. ghqで管理するgitディレクトリを設定する
  5. fisher(fisherman)インストール
  6. oh-my-fish/plugin-pecoインストール
  7. コマンド履歴検索のキーバインドを追加(Ctrl+r) (oh-my-fish/plugin-peco)
  8. decors/fish-ghqインストール(キーバインドは標準でCtrl+g)
  9. fish-ghqで利用するSELECTORをpecoに切り替える
  10. ログインシェルを変更する(お好みで)
brew install fish
brew install peco
brew install ghq
git config --global ghq.root ~/git

ghqでリポジトリを管理する、ディレクトリを指定します。~/gitなどお好みで。

curl https://git.io/fisher --create-dirs -sLo ~/.config/fish/functions/fisher.fish
fisher add oh-my-fish/plugin-peco
# ~/.config/fish/config.fishに追加
#fisherパッケージoh-my-fish/plugin-pecoの設定
function fish_user_key_bindings
  bind \cr peco_select_history # Bind for prco history to Ctrl+r
end
fisher add decors/fish-ghq
# ~/.config/fish/config.fishに追加
#fisherパッケージdecors/fish-ghqの設定
set GHQ_SELECTOR peco
# 末尾に /usr/local/bin/fish を追加
sudo vi /etc/shells

# デフォルトシェルを fish に変更
chsh -s /usr/local/bin/fish

使い方

fisherパッケージマネージャで管理しているパッケージをロードする

fisher

fishシェルを起動後、上記コマンドを実行します。(誰か自動で実行する正しい?方法を知っている方が居たら教えてください)

コマンド履歴を表示する

Ctrl-rでコマンド履歴を表示します。

Gitリポジトリをクローンする

ghq get リポジトリのURL

ghq.rootを設定することで、保存先のディレクトリを意識せず手軽にクローンできます。

Gitリポジトリ一覧を表示する

Ctrl-gでリポジトリの一覧を表示します。

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