20200528のGitに関する記事は13件です。

【Bash】ターミナル上で今いるgitのブランチ名を常に表示する

やりたいこと

スクリーンショット 2020-05-28 23.52.52.png

ローカルリポジトリで開発中、ちょくちょく今いるブランチを間違えてコミットしてぐちゃぐちゃになることがありました。ずっとターミナルにカレントブランチ表示してたら間違えないだろうと言うことでやり方を調べました。

環境(念のため)

Mac
Bash
ターミナル

手順

1.https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh にアクセスしてソースをダウンロード(Rawボタン右クリック、ファイルを保存)

ダウンロードフォルダにあるファイルを以下コマンドで移動。

cp /Users/<ユーザ名>/Downloads/git-prompt.sh /usr/local/etc/bash_completion.d/git-prompt.sh

2.bash_profileに以下を追記

vi ~/.bash_profile
#show git branch
source /usr/local/etc/bash_completion.d/git-prompt.sh
GIT_PS1_SHOWDIRTYSTATE=true
export PS1='[\u@\h: $(__git_ps1 "(%s)")\W]\$ '

以上でカレントブランチが表示されるようになります!

ありがとうございました。

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

個人的によく使うgitコマンドをまとめてみた

ずっとIDEで行っていた作業を一部コマンドで実行するようにしてみました。
それ用のメモ。
他にもおすすめの使い方があれば教えていただけると嬉しいです。

(基礎)git Bash上での操作

  • コピー
    • Ctrl + Ins
  • ペースト
    • Shift + Ins

Stash

  • 一覧を見る
$ git stash list
  • 「○○」という名前でスタッシュする
$ git stash save ○○
  • 5番目のスタッシュをアンスタッシュする
$ git stash apply 5
  • 5番目のスタッシュを削除する
$ git stash drop 5
  • 5番目のスタッシュをアンスタッシュしたうえで削除する(めっちゃ便利)
$ git stash pop 5

ブランチ

  • 一覧をみる
$ git branch
  • 「feature_1111」というブランチを削除する
$ git branch -d feature_1111
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitコマンドを恐れずに使えるようになる!

TortoiseGitから操作することが多く、コマンドを忘れそうになったので忘れないようにまとめる! ( ..)φメモメモ

※コマンドのオプション等も随時更新予定:arrows_counterclockwise:

===前提===
- Githubも使っている
- ターミナルはGit Bash

ファイルを編集する前の準備

git clone

リモートリポジトリを丸ごと複製して、自分の手元(ローカル)へ置く。

$ git clone [URL]
Cloning into 'リポジトリ名'...
remote: Enumerating objects: 23, done.
remote: Counting objects: 100% (23/23), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 23 (delta 2), reused 6 (delta 0), pack-reused 0
Receiving objects: 100% (23/23), 5.91 KiB | 1007.00 KiB/s, done.
Resolving deltas: 100% (2/2), done.

[URL]はGIthubのClone or downloadをクリックすると表示される。
git_clone.jpg

git pull

リモートリポジトリからローカルリポジトリへダウンロードすること。
リモートリポジトリの方が変更履歴が新しいはずなので、その内容をローカルリポジトリに取り込む。

$ git pull
※以下は表示例
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), 652 bytes | 59.00 KiB/s, done.
From https://github.com/ユーザー名/リポジトリ名
   de13370..fc71cca  master     -> origin/master
Updating de13370..fc71cca
Fast-forward
 test/index.html         |  23 ++
既に最新の状態である場合
$ git pull
Already up to date.

git status

ファイルの状態を確認する

ファイルの変更が無い場合
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
  • On branch XXX
    • 「現在はXXXというブランチにいる」の意

git branch

ブランチ名を一覧で表示する

$ git branch
* master

:asterisk:マークがついているのが現在いるブランチ

git branch ブランチ名

新しいブランチを作成する

$ git branch test

git checkout ブランチ名

ブランチを切り替える

$ git checkout test
Switched to branch 'test'

切り替わっているか確認する

$ git branch
  master
* test

:asterisk:マークがtestに付いているので、無事に切り替わった

ファイルに変更を加えたら

git status

$ git status
On branch test
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   css/style.css
        modified:   index.html

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

no changes added to commit (use "git add" and/or "git commit -a")
  • Changes not staged for commit
    • ステージング環境に追加されていないファイルを表示
  • Untracked files
    • 新しく追加したファイルで、Gitでまだ管理されていないファイルを表示

git add

編集・追加したファイルをステージング環境へ追加する

$ git add .

git add .で、カレントディレクトリにある全てのファイルを追加

git status

$ git status
On branch test
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   css/reset.css
        modified:   css/style.css
        modified:   index.html

  • Changes to be committed
    • これからコミットするファイルを表示

git commit

このコマンドを実行するとvimに切り替わる

ここはvim
コミットタイトル
[空行]
コミットコメント
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch test
# Changes to be committed:
#       new file:   css/reset.css
#       modified:   css/style.css
#       modified:   index.html
#

編集が終わったら以下のように表示される

$ git commit
[test 0b6049e] コミットタイトル
 3 files changed, 172 insertions(+), 47 deletions(-)
 create mode 100644 css/reset.css
 rewrite css/style.css (92%)

git status

$ git status
On branch test
nothing to commit, working tree clean

無事にコミットできた(コミットするファイルが無くなった)

いざリモートリポジトリへプッシュ!

git push

git pushだけだとエラーになってしまうので、

$ git push
fatal: The current branch test has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin test

git push origin ブランチ名とする。

$ git push origin test
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.61 KiB | 826.00 KiB/s, done.
Total 6 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'test' on GitHub by visiting:
remote:      https://github.com/ユーザー名/リポジトリ名/pull/new/test
remote:
To https://github.com/ユーザー名/リポジトリ名.git
 * [new branch]      test -> test

成功するとGithubに表示される(黄色の所)
git_push.jpg

あとはGithubのCompare & pull requestから操作して作業を完了させる。

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

git使いへのステップアップ

gitはそもそもバージョン管理に使われる.
バージョンをファイル名に追記したものを量産するのではなく,ファイルは1つ,ただしバージョン管理システムにそのいろんなバージョンを管理させる.git の管理物は .git フォルダに格納される.

すなわちバックアップをとるようなものだ.

どうせバックアップするなら別のストレージに置きたくなる.それをリモートリポジトリという.
バージョン管理するだけなら,リモートリポジトリは不要だ.
リモートリポジトリには,子分(クローンリポジトリ)と親分(所謂リモートリポジトリ)

TL;DR

  • ファイルの管理(バージョン管理): init, add, rm, mv, commit, (restore, reset, revert)
    • 派生ファイルを作る場合 : branch, switch, merge, stash
  • リモートリポジトリ: remote, fetch

0.リポジトリ(Repository)とは

編集歴を保存しているディレクトリのことである.
編集歴は.git/というディレクトリに保存されている.
.git/を削除したら普通のディレクトリである.

1.Gitの始め方(リモートリポジトリ不要)

おもむろに,今,編集歴を記録していきたいディレクトリがあるとする.
そのディレクトリに行き,

% git init

git statusを打つと,現在の状況が表示される.

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

1.1. staging(tracking): 管理対象を決める.

  • 管理したい変更(ファイル追加,ファイル内容変更)を記録する
% git add <FileName>
% git status
Changes to be committed: (use "git rm --cached <file>..." to unstage)
newfile: file.txt

Untracked files: (use "git add <file>..." to include in what will be committed)
file2.txt
  • 管理したい変更(ファイル削除)を記録(untracking)
git rm <FileName>
  • 管理したい変更(ファイル名変更)を記録
git mv <FileName> <NewFileName>

track しているファイルを記録前に戻す

git reset <FileName>

1.2. commit:編集歴をコメント入りで追記する

  • 編集歴追加の準備

編集歴(commit log)には,

  • 編集者の名前とメアド
  • コメント
  • 編集内容

が記録される.したがって,まず名前とメアドをgitに教えておく

git config user.name="名前"
git config user.email="メアド"
  • バージョンアップロード(コミットする)
git commit

commitした変更をなくす(というcommitを作る)

trackしているファイルはそのcommitの前のcommit後状態に戻される

git revert <commit>

2. バックアップ

2.1. バックアップを作る

こんがらがるので,現在Aというリポジトリがあるときに,Bというリポジトリを新しく作るとする.

  • クローンリポジトリ(バックアップ)になりたい側Bで:
git clone <PathToクローン元リポジトリA>

リモートAをクローンした場合,ローカルBのブランチの状況は,

  • origin/master
  • master

の2つのブランチができる.origin/がリモートレポジトリAのコピーである.
何もないほうが,ローカルレポジトリBである.クローン直後はAとBのmasterは同じである.

  • 構成ファイルが見えなくてもいいならベア(裸)で

B側で,

git clone --bare <PathToクローン元リポジトリA>

2.2. バックアップからコピーする.

cloneすればいい.

  • リモートリポジトリと全く同じだと親子関係が不明なので,リモートAをmaster(本店),自分Bはブランチ(支店)になり,自分のほうのmasterを消す.

バックアップと言っているが,実際はバックアップ元とバックアップ先の区別がなくなってしまう.remoteブランチを持たないほうが原本かもしれない.

気持ち悪い場合は,リモート(クラウド)にmaster,PC(ローカル)にはmasterを置かないという手がある.

git branch <NewBranchName> 
git switch <NewBranchName>
git branch -D master

2.3. リポジトリ間の同期

リポジトリがAとBの2つあり,

A - a
  - b

B - a
  - c

というディレクトリ構造だとする.

バックアップの基本は,「すべてをバックアップに取り込む」である.つまり元は無かった要素を追加する.自分の何も消さない.

集合でいえば,Aがバックアップ先だとすると,$A\cap B$を作る.
今の場合,Aにcが加わる.bはバックアップ元Bにないが,消されない.

A - a*
  - b
  - c

B - a
  - c

aは,AにもBにも存在するので,3つ選択肢がある.

  1. Bのaを全面的に採用する.(Aのaは消える)
  2. Aのaを全面的に維持する.(Bのaはバックアップされない)
  3. 同期するときに手作業でいいようにする.

バックアップ先をAとするバックアップ元がBだけであれば,BのaはAのaから一方的に編集されたものなので,「1.Bのaを全面的に採用する」で全く問題ない.gitレポジトリは編集歴を保持しているため,2つのレポジトリの編集歴からこの判断ができるとき,自動でBのaを全面的に採用する.

問題が起きるのはバックアップ元がB以外にCがあり,Bがバックアップした後にCがバックアップしたことで,「BのaはAのaから一方的に編集されたもの」とは言えないときである.このときconflict(衝突)となり,3つの選択肢を手動で選ぶ必要がある.

自動であれ手動であれ,同期は内容が変わった側のレポジトリでは1つのコミットとなる.

  • AにBを,反映させる:Aを$A\cap B$にしたい

Bから

git push

A側にconflictが起きる場合がありそうだが,実は絶対に起きない.なぜなら,編集歴が一方的でない場合は,そもそもpushしようとしてもできないからである.pushする前にpullせよと言われる.

  • AをBに,反映させる:Bを$A\cap B$にしたい.

Bから

git fetch A
git merge A/master

conflictしない場合は,自動で同期コミットされる.

conflictするかもしれないが,上記の3つの選択肢をしっかり選んで解消し,解消するために行った編集を新しくcommitする.(手動で同期コミット)

3. ブランチ

3.1. レポジトリとブランチ

レポジトリが銀行だとすると,ブランチは支店である(そもそも支店の英訳はbranch).ふつうは本店があってmasterというブランチである.

ラーメン屋ののれん分けのアナロジーでいえば,各のれん店がブランチである.
元祖の店がmasterである.

銀行にしても,のれんにしても,必ず店がある.私たちが実際に触れるのはどこかの店である.すなわちレポジトリには必ずブランチがあり,私たちはブランチに触れる.前節まで言っていたレポジトリは実際は,ブランチのことであった.

ただ,店名を指定しない場合は,代表店masterを指す決まりである.

3.2. ブランチの使い方

つまり,ディレクトリの交流(pull,push,merge)は,

  1. 同一レポジトリのブランチ間:A/a -- A/b
  2. 異なるレポジトリのブランチ間:A/a -- B/c

1は必ず同一のサーバの中であるが,2では各レポジトリは異なるサーバにあると考えるのでレポジトリはURL表記の別名を

git remote add 名前 URL

で登録する.

バックアップ用途で新しいブランチでなく,新しいレポジトリを用意するのは,異なるサーバにバックアップを置きたいからだとか,どこからでも見に行けるクラウドに置きたいからである.

3.3. ブランチの使いどころ

レポジトリを分けるのではなく,同一レポジトリ内でブランチを分ける動機は,masterを書き換えるのは畏れ多いので,ブランチを作って実際はそこを普段使いするってところだと思う.ブランチなくても,いつでもある時点のmasterに戻ることはできるが,度重なる編集歴にその「ある時点」が埋もれてしまうのが嫌なので,開発終了したら不要となるような編集歴をまとめて別に管理したいがために,ブランチを分けるのかもしれない.ブランチはトカゲの尻尾切りのように本体からまとめて削ることが簡単なのである.基本的に普段使いのブランチは短命である.

バックアップ先と元の話でいえば,バックアップ先がmasterで元がdevelopブランチかと.masterに取り込んでもらうには相当のそれなりの承認が必要だ的な.

なので,チーム開発するときは下っ端はmasterを触らない.いじるのは自分だけのfeatureブランチを作ってイジリ,それを直属の上司にdevブランチに集めてもらう.devブランチは,もっと上の上司にmasterに集めてもらう.

いずれにせよ,masterという絶対的な名前のブランチではない,別のブランチを普段使いする癖をつけていたほうがいいかもしれない.masterは神であり唯一なのである.

4. commitの名指し(ポインタ)

コミットを行うとハッシュ値が割り振られる.

このハッシュ値は,そのコミットを行った直後の状態を表す.

復元する場合にこのハッシュ値が必要であるが,長いので最初の数桁だけを指定してもよい.また,ハッシュ値の別名となるようなポインタがある.

  • ブランチ名:ブランチは上記の3で説明したが,こんがらがるかもしれないが,「ブランチ」は「そのブランチの最新のコミット直後の状態」へのポインタである.
  • HEAD:現在の「ブランチ(ポインタ)」を指すポインタ

ポインタ演算
- p~ :ポインタがあるコミットを指すが,そのコミットの1つ前のコミットを指す.
- p~~ :さらに1つ前
- p~n :n個前のコミットを指す.

5. github

5.1. Fork

github内でのcloneである.pullやmergeではないのでconflictがない.

pullしたい場合は,pull requestからcompare across forkで,
方向(「自分 <- fork元」)を間違えないようにして,pull requestを自分から自分に送って自分でmergeする.
conflictがあるかもしれない

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

Git 使いそうなコマンド

直前のコミットを修正したい

git commit --amend

※pushする前のコミットを修正したいときのみ使用できる

このコマンドの利点

もしこのコマンドが無かったら、コミットしなおした分、コミットの数が増える。
しかしこのコマンドは直前のコミットを上書きするような形なので(コミットIDは変わる)、コミットの数が増えない

コマンドを使う流れ

  • 間違えてコミットしてしまった
  • 作業し忘れたファイルの編集を行う
  • 作業し忘れたファイルをaddする(追加し忘れたファイルもここでadd)
  • このタイミングで使う

このコマンドができないこと

すでにコミットしたファイルを省くことはできない。

直前のコミットのメッセージだけ変更したい

git commit --amend -m "コミットメッセージを変更しました"

■ 修正前のコミットメッセージの一部を変えたい場合
-mオプションを省いて実行することで、修正前のコミットメッセージが入力された状態でエディタが開く。
一文字だけ変えたい、等の場合はこちらの方が楽。

直前のコミットメッセージのままコミット修正をしたい

git commit --amend --no--edit

マージしたらコンフリクトが起きてたため取り消したい

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

Git 使いそうなコマンド()

直前のコミットを修正したい

git commit --amend

※pushする前のコミットを修正したいときのみ使用できる

このコマンドの利点

もしこのコマンドが無かったら、コミットしなおした分、コミットの数が増える。
しかしこのコマンドは直前のコミットを上書きするような形なので(コミットIDは変わる)、コミットの数が増えない

コマンドを使う流れ

  • 間違えてコミットしてしまった
  • 作業し忘れたファイルの編集を行う
  • 作業し忘れたファイルをaddする(追加し忘れたファイルもここでadd)
  • このタイミングで使う

このコマンドができないこと

すでにコミットしたファイルを省くことはできない。

直前のコミットのメッセージだけ変更したい

git commit --amend -m "コミットメッセージを変更しました"

■ 修正前のコミットメッセージの一部を変えたい場合
-mオプションを省いて実行することで、修正前のコミットメッセージが入力された状態でエディタが開く。
一文字だけ変えたい、等の場合はこちらの方が楽。

直前のコミットメッセージのままコミット修正をしたい

git commit --amend --no--edit

マージしたらコンフリクトが起きてたため取り消したい

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

Gitでやらかしたコミット&プッシュを無かったことにした話

こんにちは、@0yanです。
運用中のアプリのコード修正時、直前のgit addを取り消したかったのですが、某記事に書いてあった「はじめてのgit addを取り消す」という内容を「最近行ったaddの1回目を取り消す」という意味だと勘違いし、git rm --cached -r .を実行後、マスターブランチにgit pushするという大失態を犯しました。git initした後のgit addを取り消すという意味だったらしく、GitHubのマスターブランチは空っぽに・・・。

本記事はそれを解決したという記事です。こんなしょうもないことをする人はいないと思いますが、万が一、私と同じことをしてしまった方がいた時に役立つよう投稿しておきます。あぁ、恥ずかしい。

解決手順

  1. GitHubのリモートリポジトリで元に戻したいコミットのコミットIDを調べる
  2. ローカルリポジトリで元に戻したいコミット以降のコミット(=やらかしたコミット)を、git reset --hard [1で調べたコミットID]によって削除
  3. git push -f origin masterでリモートリポジトリに強制プッシュ

補足

git resetはあまり推奨されない方法らしく、本当はgit revertを使った方が良いそうです。詳しくは以下の記事等をご参照ください。

【Git】間違ってpushした場合の取り消し方

参考文献

git commit を取り消して元に戻す方法、徹底まとめ

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

リモートブランチを削除してローカルのブランチをpushする方法

リモートのブランチ名を変えたいけれどあ゛~~~~~~ってなったので備忘録です。

リモートのブランチを表示します

$ git branch -r 
  origin/HEAD -> origin/master
  origin/master
  origin/fix_example

ローカルのブランチを表示します

$ git branch
* fix_example
  master

ローカルのブランチを書き換える必要が生じた!

$ git branch -m 5.fix_example

$ git branch
* 5.fix_example
  master

そのままpushしてもローカルのブランチ名は昔のまま

$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:fix_example

To push to the branch of the same name on the remote, use

    git push origin HEAD

.git/config を編集します。

$ vim .git/config

編集前

~略~
[branch "5.fix_example"]
         remote = origin
         merge = refs/heads/fix_example

編集後

~略~
[branch "5.fix_example"]
         remote = origin
         merge = refs/heads/5.fix_example

揃えた。
あとはpushします。

$ git push

力技で解決系なので自己責任でお願いします。

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

【Git】私のためのGitチートシート

自己紹介

こんにちは。tetraです。
最近GitHubを利用し始めました。2ヶ月目の新卒エンジニアです。

Gitを用いた作業の始め方。

リポジトリの初期設定

まずはリポジトリー作成。

スクリーンショット 2020-05-28 11.08.07.png

次にgit cloneをする。

スクリーンショット 2020-05-28 11.09.47.png

USE SSHを選択し、コピーする。

スクリーンショット 2020-05-28 11.15.23.png

ターミナル上で以下の操作を行う。

mkdir (リポジトリ名)
git clone (クローンでコピーしたものを貼り付ける)

ブランチを切ろう

git branch sample
git checkout sample

ファイルをアップロードしてみよう

ファイル作成

アップロードするファイルを作成。
別にアップロードするファイルがある場合は飛ばして良い

touch sample.txt

ファイルをコミットの対象にしよう

今回は全てのファイルを追加します。

git add .

コミットしよう

git commit -m "commit message"

プッシュしよう

git push origin sample

プルリクしよう

New pull requestから

スクリーンショット 2020-05-28 11.38.02.png

Create pull requestを選択
スクリーンショット 2020-05-28 11.49.09.png

マージしよう

Merge pull requestを選択
スクリーンショット 2020-05-28 12.05.34.png

Confirm mergeを選択
スクリーンショット 2020-05-28 12.05.46.png

いかがでしょうか?

いかがでしょうか。経験が浅いため至らぬところがまだまだあります。
もし間違い等に気がつきましたら、コメント又はtetraまでお知らせください。

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

Macのターミナル表示をいじったらモノクロだった私の人生に色がつきました。(.bashrc改修備忘録)

Macで開発しているとターミナルはよく利用しますよね?
デフォルトで表示されている文字列はなんか長いし見づらい!
そんな方は.bashrcを編集して好きな表示にしてしまいましょう!
(編集後はsource .bashrcを忘れずに!)

スクリーンショット 2020-05-28 1.59.21.png
↑こんな感じ


こちらのページ( https://qiita.com/hmmrjn/items/60d2a64c9e5bf7c0fe60 )を参考にさせていただきました!
詳しくはそちらを見てください。
このページではわたしが利用したものをご紹介します。


書式

sample
export PS1='Hello Prompt! \# \t \w \$ '

表示する内容を選ぶ

記号 意味
\h ホスト名 ka2ya's Macbook 
\u ユーザ名 ka2ya
\w ディレクトリ(フルパス) ~/Documents/GitHub
\W ディレクトリ GitHub
\t 時間 (24形式) 23:29:38
\T 時間 (12形式) 11:29:38
\@ AM / PM PM
\d 日付 Wed Jun 20
\D 日時 18/06/20 23:29:38
# コマンドの番号 (1, 2, 3...) 1
\n 改行
\$ 一般ユーザーの時 $、rootの時 # を表示 $

エスケープシーケンスで囲んで色の指定も可能

export PS1='装飾なし \[\e[32m\] ここは緑色 \[\e[0m\] 装飾なし \$ '
文字色 背景色
30m 40m 背景黒
31m 41m 背景赤
32m 42m 背景緑
33m 43m 背景黄
34m 44m 背景青
35m 45m 背景紫
36m 46m 背景水
37m 47m 背景灰

設定例(私のやつ)

.bashrc
# 出力の後に改行を入れる
function add_line {
  if [[ -z "${PS1_NEWLINE_LOGIN}" ]]; then
    PS1_NEWLINE_LOGIN=true
  else
    printf '\n'
  fi
}
PROMPT_COMMAND='add_line'

source ~/.git-prompt.sh

export PS1='\t \[\e[36m\]\u\[\e[0m\] \[\e[33m\] \W\[\e[0m\]\[\e[1;32m $(__git_ps1 "(%s)") \[\e[0m\] \n\$'

※ Gitフォルダだった場合にいい感じにする為に
~/.git-prompt.shを作成して以下のソースを入れとく

https://github.com/git/git/edit/master/contrib/completion/git-prompt.sh

スクリーンショット 2020-05-28 1.59.21.png

感想

「カラーがあれば、まいにちたのしい。」 by.GameboyColor

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

Macのターミナル表示をいじったらモノクロだった私の人生に色がつきました。

Macで開発しているとターミナルはよく利用しますよね?
デフォルトで表示されている文字列はなんか長いし見づらい!
そんな方は.bashrcを編集して好きな表示にしてしまいましょう!
(編集後はsource .bashrcを忘れずに!)

スクリーンショット 2020-05-28 1.59.21.png

こちらのページ( https://qiita.com/hmmrjn/items/60d2a64c9e5bf7c0fe60 )を参考にさせていただきました!
このページではわたしが利用したものをご紹介します。

書式

sample
export PS1='Hello Prompt! \# \t \w \$ '
記号 意味
\h ホスト名 ka2ya's Macbook 
\u ユーザ名 ka2ya
\w ディレクトリ(フルパス) ~/Documents/GitHub
\W ディレクトリ GitHub
\t 時間 (24形式) 23:29:38
\T 時間 (12形式) 11:29:38
\@ AM / PM PM
\d 日付 Wed Jun 20
\D 日時 18/06/20 23:29:38
# コマンドの番号 (1, 2, 3...) 1
\n 改行
\$ 一般ユーザーの時 $、rootの時 # を表示 $

エスケープシーケンスで囲んで色の指定も可能

export PS1='装飾なし \[\e[32m\] ここは緑色 \[\e[0m\] 装飾なし \$ '
文字色 背景色
30m 40m 背景黒
31m 41m 背景赤
32m 42m 背景緑
33m 43m 背景黄
34m 44m 背景青
35m 45m 背景紫
36m 46m 背景水
37m 47m 背景灰

設定例(私のやつ)

.bashrc
# 出力の後に改行を入れる
function add_line {
  if [[ -z "${PS1_NEWLINE_LOGIN}" ]]; then
    PS1_NEWLINE_LOGIN=true
  else
    printf '\n'
  fi
}
PROMPT_COMMAND='add_line'

source ~/.git-prompt.sh

export PS1='\t \[\e[36m\]\u\[\e[0m\] \[\e[33m\] \W\[\e[0m\]\[\e[1;32m $(__git_ps1 "(%s)") \[\e[0m\] \n\$'

※ Gitフォルダだった場合にいい感じにする為に
~/.git-prompt.shを作成して以下のソースを入れとく

https://github.com/git/git/edit/master/contrib/completion/git-prompt.sh

スクリーンショット 2020-05-28 1.59.21.png

感想

「カラーがあれば、まいにちたのしい。」 by.GAMEBOY COLOR

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

Macのターミナル表示をいじってモノクロな人生に色をつけよう

Macで開発しているとターミナルはよく利用しますよね?
デフォルトで表示されている文字列はなんか長いし見づらい!
そんな方は.bashrcを編集して好きな表示にしてしまいましょう!
(編集後はsource .bashrcを忘れずに!)

スクリーンショット 2020-05-28 1.59.21.png

こちらのページ( https://qiita.com/hmmrjn/items/60d2a64c9e5bf7c0fe60 )を参考にさせていただきました!
このページではわたしが利用したものをご紹介します。

書式

sample
export PS1='Hello Prompt! \# \t \w \$ '
記号 意味
\h ホスト名 ka2ya's Macbook 
\u ユーザ名 ka2ya
\w ディレクトリ(フルパス) ~/Documents/GitHub
\W ディレクトリ GitHub
\t 時間 (24形式) 23:29:38
\T 時間 (12形式) 11:29:38
\@ AM / PM PM
\d 日付 Wed Jun 20
\D 日時 18/06/20 23:29:38
# コマンドの番号 (1, 2, 3...) 1
\n 改行
\$ 一般ユーザーの時 $、rootの時 # を表示 $

エスケープシーケンスで囲んで色の指定も可能

export PS1='装飾なし \[\e[32m\] ここは緑色 \[\e[0m\] 装飾なし \$ '
文字色 背景色
30m 40m 背景黒
31m 41m 背景赤
32m 42m 背景緑
33m 43m 背景黄
34m 44m 背景青
35m 45m 背景紫
36m 46m 背景水
37m 47m 背景灰

設定例(私のやつ)

.bashrc
# 出力の後に改行を入れる
function add_line {
  if [[ -z "${PS1_NEWLINE_LOGIN}" ]]; then
    PS1_NEWLINE_LOGIN=true
  else
    printf '\n'
  fi
}
PROMPT_COMMAND='add_line'

source ~/.git-prompt.sh

export PS1='\t \[\e[36m\]\u\[\e[0m\] \[\e[33m\] \W\[\e[0m\]\[\e[1;32m $(__git_ps1 "(%s)") \[\e[0m\] \n\$'

※ Gitフォルダだった場合にいい感じにする為に
~/.git-prompt.shを作成して以下のソースを入れとく

https://github.com/git/git/edit/master/contrib/completion/git-prompt.sh

スクリーンショット 2020-05-28 1.59.21.png

まとめ

「カラーがあれば、まいにちたのしい。」 by.GAMEBOY COLOR

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

github static page作成

makes branch : gh-pages
user名.github.io/repository名でつながる

私は最初にrepository 設定はprivateにしたので、404エラーが出た
https://myksb1223.github.io/develop_diary/2019/03/09/GitHub-pages-404-not-found.html
のように、ソースをrebuildした後にpushしたら直るらしい。

私はまだできないけど。。。

上の場合はvscのterminalでpushしたことで、
github desktopではまだpushができる状況だった。(うまく行かなかったぽい)
それで再びpushしたら正常に入るようになった

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