20201012のGitに関する記事は5件です。

【Shell】Gitでリモートのデフォルトブランチを取得する方法

  • 普段Gitを用いた開発の際に、shellやCIでデフォルトブランチ名を取得した処理を記述する場合がある。
  • ただ、最近諸事情でデフォルト名がmasterからmainへ変更されたため、汎用的に取得する必要がある。
  • そのため、Gitソースのリモートデフォルトブランチ名を取得する2つの方法を記録する。

結果

  • git remoteコマンドを利用した主に2つのやり方は下記。
    • 環境に合わせて選択
# awkの場合
# 出力 : master(or main)
git remote show origin | awk '/HEAD/ {print $NF}'

# grep / cutの場合
# 出力 : master(or main)
git remote show origin | grep 'HEAD branch' | cut -d' ' -f5

参考

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

[VScode] git/ GitHub を管理する方法

概要

Visual Studio Code を利用して、git で作業ディレクトリ(ローカルディレクトリ/リモートディレクトリ)を管理する方法についてまとめる。

前提知識

ターミナルで git/github を管理する方法

環境

  • Visual studio Code 1.47.2
  • git 2.17.2 (ユーザー名、メールアドレスなどの初期設定済み)

事前準備

作業フォルダとして事前に「gitVScode」を作成し、「hogehoge.md」 を格納
スクリーンショット_2020-09-29_14_30_24.png

ローカルディレクトリの管理

git init //フォルダをバージョン管理の対象にする

[Initialize Repository] をクリック
スクリーンショット_2020-09-29_14_24_38.png

フォルダに「.git」が作成された
スクリーンショット 2020-09-29 14.39.55.png
※「.git」は隠しファイルであるため、隠しファイルを表示するように設定
 mac の場合、command + shift + .で表示/非表示の切り替えが可能

git add //記録対象の指定

変更がある場合に左側のアイコンに❶といったように表示される
対象ファイルのプラスマーク([Stage Changes])をクリック
スクリーンショット_2020-10-12_11_04_47.png

複数ファイルを一括でステージさせたい場合は [Changes] の横をホバーすると [+] が出てくる
スクリーンショット_2020-10-12_11_05_00.png

git commit // 変更点の記録

[Message] にコミットメッセージを入力する
スクリーンショット_2020-10-12_11_09_27.png

入力したら、[✔︎] をクリックすると commit 完了
スクリーンショット_2020-10-12_11_11_01.png

リモートディレクトリ(GitHub) の管理

GitHub でリポジトリを作成

[Your profile] → [Repositories] → [New] をクリック
スクリーンショット 2020-09-10 17.05.16.png

[Create a new repository] ページが表示されるので、[Repository name] を入力する。ここでは、ローカルフォルダとあわせて「gitvscode」とする。
スクリーンショット 2020-09-29 15.39.34.png

設定が完了したら、[Create Repository] をクリックする
スクリーンショット_2020-09-29_15_40_53.png

画面に表示された [HTTPS] か [SSH] をコピーする
ここでは、GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~を参照し、SSH の設定を行っている

git remote add //ローカルディレクトリを github のリモートディレクトリに紐づける

[・・・] → [Remote] → [Add Remote] をクリック
スクリーンショット_2020-09-29_15_48_12.png

GitHub でコピーした https/SSH を貼り付けてエンターキー
スクリーンショット_2020-09-29_15_48_32.png

[Remote name] に「origin」と入力し、エンター
スクリーンショット 2020-09-29 21.22.03.png

ターミナルでgit remote -vを入力し、正しく登録できたか確認スクリーンショット_2020-09-29_21_24_35.png

git push //commit 済みのディレクトリを github に更新

[・・・] → [Push] をクリック
スクリーンショット 2020-09-29 21.35.00.png

初回は以下のようなメッセージがでる。このメッセージは、新規ブランチなので、リモートに紐づけるブランチ(追跡ブランチ/アップストリームブランチ)がない、というメッセージ。
スクリーンショット 2020-09-29 21.35.09.png
参照:Git で新規ブランチを切って Push する時に何やら怒られるヤツの回避方法

[OK] をクリックした後に追跡ブランチを確認するgit branch -vvを実行

TERMINAL
gitVScode $ git branch -vv
* master 8bd914e [origin/master] add message

[Cancel] をクリックして、git push -u origin masterを実行後、追跡ブランチを確認

TERMINAL
gitVScode $ git push -u origin master 
Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes | 214.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/xxxxx/gitvscode.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

gitVScode $ git branch -vv
* master 58b5df5 [origin/master] add message

git push -u origin masterを実行した時と、追跡ブランチが同様に設定されていることが確認できたので、初回に表示されるメッセージは [OK] を選択して問題ないことがわかった。

git pull // ローカルリポジトリに最新版を適用

github 上で変更した場合は pull コマンドを利用して、ローカルリポジトリも更新する

[・・・] → [Pull] をクリック
スクリーンショット 2020-09-29 21.34.40.png

VScode では利用しないコマンド

git status //ステータスの表示

[Changes] 以下にファイル名が並んでおり、ファイルの追加、編集、削除を行うと自動的に U, M, Dがファイル名の横に記載される
スクリーンショット 2020-09-29 14.54.59.png
ステータスの表示にあたる画面

git log // ログの表示

デフォルトでは git log に替わる UI がないため、ログを見やすく表示することができるアドインツール(Git History)をインストールする必要がある
スクリーンショット_2020-09-29_21_47_42.png

[Git : View History (git log)] アイコンが表示される。クリックするとログが表示される。
スクリーンショット_2020-09-29_15_28_01.png

参照

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

不要なリモートブランチ削除

覚書です:thumbsup:
※"GitFlow"の場合であればプルリク→マージし、Github/GitLab側でブランチ削除するので不要です。

プルリクでの開発現場でない際に使いました。参考になれば幸いです。
間違っている点がありましたらご指摘ください!!

[手順]
リモートブランチ削除

ローカルブランチ削除

どちらが先でも良いですが、自分のわかりやすい手順で行ってください。
もし誤って他人のリモートブランチを削除した場合は、削除してしまったブランチの人に伝えてください!
ローカルのブランチ情報が残っているので問題ありませんがびっくりすることでしょう...

リモートブランチの削除

git push --delete origin ブランチ名 

もしくは

git push origin :ブランチ名

例) git push --delete origin feature/#0001

最初は--deleteをつけて削除するのがおすすめです。
理由として、コードやオプションが間違っていたら削除できないため、ブランチの誤削除防止になります。

ローカルブランチの削除

git branch --delete ローカルブランチ名

もしくは

git branch -d ローカルブランチ名

あるいは

git branch -D ローカルブランチ名

<<注意>>-Dは、マージしていないブランチも削除できますのでご注意ください!

他人がリモートブランチを削除した時の対応

git fetch --prune

もしくは

git fetch -p

Gitはローカルの".git/"にデータを格納しています。
git fetchで追加されたリモートブランチの情報取得はできますが、デフォルトで削除は対応していません。
ですので、--pruneで削除していきましょう。
いちいち打ちたくない人は、configを修正してください。参考文献の一つ目URLにあります。

参考文献

https://qiita.com/yuu_ta/items/519ea47ac2c1ded032d9
https://qiita.com/hogeta_/items/33d2334c9b1919bd5120

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

Git コミットを一部削除する方法

GitHubでコミットを一部のみ削除する方法

結論

ターミナル
git reset <コミットID>

コミットID?????

commit IDの出し方

ターミナル
git log

git logでブワーッと下記のようになる

git07_01.png

上記のcommit 5daf90338461・・・5から5までのランダムな英数字混合がコミットIDです!

削除したい該当のコミットのIDをresetすれば・・・

ターミナル
git reset 5daf90338461ead0665b16bf02f9fbfafbba7da5

特定のコミットだけが削除された状態になります

注意点としてはこの方法はコミットしてpushする前の状態の説明なのでpushしてしまった後の削除法につきましては以下の記事などを参考にしてみて下さい!

参考Qiita記事

@Maeda-Shoota
~Git困ったぞこれ集~
https://qiita.com/Maeda-Shoota/items/56d5fddccf5e89bbeba0

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

あんまりターミナル好きじゃない人がGitHub CLIでどう快適になるのか検証してみた

gitの操作はSourcetreeで行うぐらい、そんなにターミナル好きじゃない自分がGitHub CLIを使ってみたら、何が快適になったか、快適にならなったのか紹介します。

v1.1.0の情報です。

実際に使ってみて

もともとめんどくさかったこと

  • マイクロサービスで開発していて、チーム全員がほぼ全てのリポジトリをいじるスタイルなので、めっちゃいっぱいリポジトリをいじらないといけない
  • 開発した内容によっては、複数のリポジトリにわたる変更があるので、プルリクをいっぱい作らないといけない
  • GitFeatureFlowを採用してるので、プルリクを作る時にmaster向けのプルリクと環境ごとのプルリクを作る必要がある
  • 大きな変更をした場合、作るプルリクが10を超えることもよくある
  • どのリポジトリのどのプルリクがどんな状態なのか把握しづらい

何が快適になったの?

  1. リポジトリのページを開くのが楽になった
    • もともとブラウザで新しいタブ作ってurl入力してた
    • gh repo view --web ってやるだけでブラウザで開いてくれる(aliasはったらもっと短くなる)
  2. プルリクの作成が楽になった
    • もともとブラウザでリポジトリのページを開き、プルリクのタブを開き、「New Pull Request」をクリックして、ブランチを選んでた
    • gh pr create -w ってやるだけで上の4ステップを完了した状態でブラウザを開いてくれるので圧倒的に楽になった (aliasはったらもっと短くなる)
  3. GitFeatureFlowにおけるプルリクの作成が楽になった
    • GitFeatureFlowは要すると、プルリク作成する時に、環境の数だけプルリクを作成する必要がある<-めちゃめんどくさい
    • 詳しくは https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama
    • master向きに作ったブランチと同じタイトルとつけて、そのリンクを詳細にはり、環境名を表すラベルをはるプルリクを作らないといけない
    • シェルを書くことになってしまったが(なのでGitHub CLI使わなくてもAPIたたけよって話ですが)、コマンド一発で実行できるようになった。https://github.com/nekoshita/shell-scripts/tree/master/github

何が快適にならなかった?

  1. やっぱりブラウザでみた方がなんかいろいろ慣れてる
    • コマンドラインだけで完結はするのはいいけど、コマンドをいちいち覚えるのもめんどう
    • issueもpullRequestもブラウザで検索できるし
  2. ghコマンドは基本各リポジトリに対する操作なので、複数のリポジトリをいい感じに扱えない
    • 全てリポジトリのOPENなプルリクを一括で取得するとかできなかった
    • マイクロサービスの場合はやっぱりここをみるしかない https://github.com/pulls

GHEでも使えるの?

業務で使いたい人は、GHE(GitHub Enterprice)の場合もあるかと思います。
GitHub CLIは、GHEのv2.20以降に対応しています。

GHEのバージョンの調べ方はこちら

結論

マイクロサービス、かつ、GitFeatureFlowという数多くのプルリクを作成しないといけない現場において、プルリクを作成するコストが圧倒的に下がったので、まあま嬉しい。
かなり限定的な使い方かもしれませんが、これからもGitHub CLIを使います。

GitHub CLIについて

GitHub CLIとは?

コマンドラインでGitHubの操作ができるCLIツールです。
https://github.com/cli/cli
たぶんGitHub上でおこなるほぼ全ての操作をコマンドラインで実行できます。
コマンド詳細はこちらの記事にまとまっています。

インストール

brew使える場合(それ以外はhttps://github.com/cli/cli#installationをみてください)

brew install gh

認証

# GitHubの場合
gh auth login
# GHEの場合
gh auth login --hostname <hostname>

コマンド補完の設定(やらなくてもいい)

# zshの場合、.zshrcに以下を追記する
eval "$(gh completion -s zsh)"
# bashの場合、.bashrcに以下を追記する
eval "$(gh completion -s bash)"

aliasはぜひ使いたい

ghコマンドでaliasの設定ができます
例えば、プルリクをブラウザで作成するためのコマンドを設定する場合

# プルリクをブラウザで開くコマンド
gh pr create -w
# 下のコマンドで `prc` っていうaliasを設定し
gh alias set prc 'pr create -w'
# 以下のコマンドでプルリクをブラウザで開けるようになる
gh prc
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む