20201216のGitに関する記事は6件です。

投稿日：2020-12-16T23:05:10+09:00

gitのバージョンアップ

はじめに

gitちゃんと勉強して使えるようになろう！　
と思ってバージョン確認してみたら古かった。で，バージョンアップしようとしたけど手こずったのでメモします。でもちゃんと自分で解決できた！嬉しい！
ちなみにMacです。

そもそもよく理解してないままQiitaとかの記事見てそのままコピペするからいけないんだよね。。

で，本題

まずはバージョン確認
$ git --version
git version 2.20.1 (Apple Git-117)
今2.29.2とかなんで古いですね。
$ brew update 
これはこのまま戻ってこなくなった。よくわかってないです。
あんまり待っても返ってこないから ctrl+C しました。
$ brew install git
Updating Homebrew...
...
ここから下つらつらつらーっと続きます。
どうやら上の２行だけでできるらしいんですが。
$ git --version
git version 2.20.1 (Apple Git-117)
変わってないじゃん！！！
で，よくわかってないからインストールできてないのかなってまた同じことしたりしてました。。
$ which git
/usr/local/bin/git
よくわからないままパスがなんちゃらって読んで，確認して，わからん！！ってなり。
Summaryにどこにインストールされたかが書いてあることを知り，遡って探して…
（無駄にいじったんで探すの大変でした笑）

インストール文の途中，
==> Summary
?  /usr/local/Cellar/git/2.29.2: 1,480 files, 39.2MB
見つけた！
そこだけコピペして，ちょっと付け足して，
$ /usr/local/Cellar/git/2.29.2/bin/git --version
git version 2.29.2
できてたーー!

で，多分このデフォルトになってるApple Gitじゃなくこれにパス指定した方がいいんだよね？ってことで
$ echo 'export PATH="/usr/local/Cellar/git/2.29.2/bin:$PATH"' >> ~/.zshrc
$ source ~/.zshrc
$ git --version
git version 2.29.2
終わりに

一応，インストールは初めにできてたんだけど，確認ができなくて手こずった，って話でした。
簡単に言うと場所が違ったってことですね。
ひとつ成長！

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-16T22:32:52+09:00

git tagdate コマンドの紹介

あるパッチがどのバージョンのkernelに入ったものかを簡単に知るために、
git tagdate というコマンドがあります。

例えば
commit 2a842acab109f40f0d7d10b38e9ca88390628996
Author: Christoph Hellwig hch@lst.de
Date: Sat Jun 3 09:38:04 2017 +0200

というパッチがメインラインに入ったのは、2017年6月3日だとわかりますが、
$ git tagdate
(snip)
Sun Sep 3 13:56:28 2017 -0700 refs/tags/v4.13
Sun Aug 27 17:20:50 2017 -0700 refs/tags/v4.13-rc7
Sun Aug 20 14:14:03 2017 -0700 refs/tags/v4.13-rc6
Sun Aug 13 16:01:40 2017 -0700 refs/tags/v4.13-rc5
Sun Aug 6 18:44:56 2017 -0700 refs/tags/v4.13-rc4
Sun Jul 30 12:40:48 2017 -0700 refs/tags/v4.13-rc3
Sun Jul 23 16:15:27 2017 -0700 refs/tags/v4.13-rc2
Sat Jul 15 15:22:25 2017 -0700 refs/tags/v4.13-rc1
Sun Jul 2 16:07:11 2017 -0700 refs/tags/v4.12
Sun Jun 25 18:30:14 2017 -0700 refs/tags/v4.12-rc7
Mon Jun 19 22:19:48 2017 +0800 refs/tags/v4.12-rc6
Sun Jun 11 16:48:27 2017 -0700 refs/tags/v4.12-rc5
Sun Jun 4 16:47:49 2017 -0700 refs/tags/v4.12-rc4　　<=
Sun May 28 17:20:59 2017 -0700 refs/tags/v4.12-rc3
Sun May 21 19:30:30 2017 -0700 refs/tags/v4.12-rc2
Sat May 13 13:20:00 2017 -0700 refs/tags/v4.12-rc1
Sun Apr 30 19:48:00 2017 -0700 refs/tags/v4.11
(snip)

2017年6月3日は v4.12-rc4のタイミングに入ったというようにわかります。

でも、みなさんの git にはそんなコマンドは用意されていないですよね。
自分で用意しましょう。

~/.gitconfig
[alias]
tagdate = tag -l --format='%(taggerdate) %(refname)' --sort=-taggerdate

(注)全てのレポジトリでtagと日付がセットで出てくるとは限りません。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-16T18:32:45+09:00

一目置かれるコミット運用

綺麗なコミットを心がける

TL;DR

コードレビューを依頼する立場からgitのコミットログを見やすくするための2つのテクニック

(1つ目) コミットをまとめる

1. データが消えないように小まめにコミットする

様々な開発環境によってリアルタイムに保存されているから予期せぬ事態が発生してもデータが飛ぶことがないということもあるかも知れませんが、安全第一に考えて出来る限りコミットする。

作業が終わっていなくても以下のタイミングでコミットする

休憩前

ランチなどの食事前

1日の作業を終えて帰宅する前

コミットのタイトルに[WIP]をつける

作業が終わっていないけどコミットする際にはコミットログのタイトルに[WIP]をつける

2. コミットをまとめる

作業が完了したらgit logコマンドを実行し、コミットを確認する。
[WIP]がついているコミットがある場合コミットをまとめます。

2-1. コミットログを確認する

↓上の方が新しいコミットです。下に行くほど昔のコミットです。
コミットログ
$ git log --oneline

611dc15 (HEAD -> master) [WIP] Add test code
8cfe213 [WIP] Add parameter
3c53778 Add main.swift
870eb78 Register project files.
上記のコミットログのうち[WIP]がついている上から2つコミットをまとめる

[WIP] Add test code

[WIP] Add parameter

2-2. git rebaseを使う

2つのコミットをまとめるために以下のコマンドを実行する
git rebase -i HEAD~2
実行すると下記のように表示されます。
＊git logの場合は降順(上の方が新しい)で表示されますが、git rebaseの場合は昇順(下の方が新しい)で表示されるので注意が必要です。pick 611dc15 [WIP] Add test codeの方が新しいコミット
rebaseコマンド実行後に表示される
pick 8cfe213 [WIP] Add parameter
pick 611dc15 [WIP] Add test code

# Rebase 3c53778..611dc15 onto 3c53778 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
2-3. コミットを編集する
編集前
pick 8cfe213 [WIP] Add parameter
pick 611dc15 [WIP] Add test code
↑を↓に書き換えます(2行目のpickをsに変更)
編集後
pick 8cfe213 [WIP] Add parameter
s 611dc15 [WIP] Add test code
編集後(全文)
pick 8cfe213 [WIP] Add parameter
s 611dc15 [WIP] Add test code

# Rebase 3c53778..611dc15 onto 3c53778 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
編集完了後に:wqで決定する。

2-4. コミットメッセージを編集する
コミット編集時の表示
# This is a combination of 2 commits.
# This is the 1st commit message:

[WIP] Add parameter

main.swiftファイルに変数を追加。

# This is the commit message #2:

[WIP] Add test code

main.swiftファイルにテストコードを追加しました。

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Tue Dec 15 15:32:14 2020 +0900
#
# interactive rebase in progress; onto 3c53778
# Last commands done (2 commands done):
#    pick 8cfe213 [WIP] Add parameter
#    squash 611dc15 [WIP] Add test code
# No commands remaining.
# You are currently rebasing branch 'feature/#1_Create_main_file' on '3c53778'.
#
# Changes to be committed:
#       modified:   main.swift
#
# Untracked files:
#       hoge.txt
#
編集する部分は以下
編集箇所
# This is a combination of 2 commits.
# This is the 1st commit message:

[WIP] Add parameter

main.swiftファイルに変数を追加。

# This is the commit message #2:

[WIP] Add test code

main.swiftファイルにテストコードを追加しました。
編集後
Add needed functions for main.swift

main.swiftファイルに必要なファイルを全て実装しました。
編集後全文
Add needed functions for main.swift

main.swiftファイルに必要なファイルを全て実装しました。

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Tue Dec 15 15:32:14 2020 +0900
#
# interactive rebase in progress; onto 3c53778
# Last commands done (2 commands done):
#    pick 8cfe213 [WIP] Add parameter
#    squash 611dc15 [WIP] Add test code
# No commands remaining.
# You are currently rebasing branch 'feature/#1_Create_main_file' on '3c53778'.
#
# Changes to be committed:
#       modified:   main.swift
#
# Untracked files:
#       hoge.txt
#
編集完了後に:wqで決定する。
編集後のコミットログ
$ git log --oneline

6f6c506 (HEAD -> master) Add needed functions for main.swift
3c53778 Add main.swift
870eb78 Register project files.
コミットをまとめる前とまとめた後のコミットログの比較は以下です。
前
611dc15 (HEAD -> master) [WIP] Add test code
8cfe213 [WIP] Add parameter
3c53778 Add main.swift
870eb78 Register project files.
後
6f6c506 (HEAD -> master) Add needed functions for main.swift
3c53778 Add main.swift
870eb78 Register project files.
＊最新のコミットAdd needed functions for main.swiftのコミットID(ハッシュ)が新たに作成されています => 6f6c506

3. リモートリポジトリへ登録する

コミットを編集する前と編集した後ではコミットのIDが変わってしまっているためそのままgit pushするとエラーが発生します。そこでpushに-fオプションをつけます。強制プッシュとなりますのでmasterやmain、developブランチでコミットを編集して強制プッシュはしないようにしましょう。チーム開発をしている場合は特に。

$ git push -u -f origin 作業ブランチ名

(2つ目)マージコミットを作らない

チームで開発では各メンバーはfeatureブランチで作業を行なっているかと思います。誰かがPull requestを完了させてdevelopブランチにマージされると他のメンバーはdevelopにマージされた情報を自分の作業ブランチであるfeatureブランチにマージする必要があります。
そこでfeatureブランチにdevelopをマージすると以下のようなマージコミットが作成されます。
Merge branch 'develop' into feature/自分の作業ブランチ
自分の作業したコミット以外にマージコミットができるのでコミットログが増えてしまいます。

そこでコミットログが増えないようにするために利用できるのがrebaseです。
rebaseはコミットをまとめるでも出てきたように多機能なコマンドです。
ここではマージコミットを作らないようにするための機能を紹介いたします。

まず通常のマージとリベースとの違いを比較いたします。

マージ

あるキャラクターを作成する作業フローを図式しました。
AさんとBさんの2人でキャラクターを作成しています。
よくあるgit-flowでの開発フローです。
Aさんの作業が先に終わってdevelopにマージされました。
そこでBさんはdevelopが更新されたのでBさんが作業しているブランチにdevelopの情報をマージしました。
すると赤枠になっているマージコミットが作成されます。

Bさんの作業は「耳の作成」「口の作成」「目と鼻の作成」の3つですがマージコミットが入ってきたので4コミットになっています。自分で作業していないコミットが一つ入ってきてしまっています。

マージコミットが1つだけなので然程気にならないかも知れませんがもっと大人数で開発している場合はマージコミットがどんどん増えていきます。後から見返すにもコミットログが多くなってしまって他のブランチを含めてコミットログが見にくくなってしまいます。

そこでマージコミットを残さないやり方をしてみます。リベースの登場です。

リベース

まずは以下のgitのコミットログ画像を参照ください。

マージコミットがなく自分で作業したコミットのみになっています。
自分の作業ブランチのコミット数はdevelopをマージした場合は4つ、リベースした場合はコミットが3つとなっています。

どうやってマージコミットを残さないようにするかについて図説致します。

developが更新される

git pull --rebase origin developコマンド実行

git pull --rebase origin developコマンド完了後

Aさんが更新した顔の色を塗った変更がマージされたdevelopブランチが新たな起点となってBさんの変更が開始されています。

最後に比較です。
左がdevelopの変更をmergeしたもの、右がdevelopの変更をpull --rebaseしたものです。

まとめ

コミットをまとめる

マージコミットを残さない

この2つを実践して自分の作業ブランチのコミットログを綺麗に保ってみましょう。
レビュワーの方が気づいて「できるな！」と思われるかも知れません。
「余計なことするな」と言われる可能性もあるので事前に確認することで「できるな！」と思ってくれるかも知れませんので一度試してみてはいかがでしょうか。

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-16T14:04:37+09:00

git pull --rebaseを取り消す方法

git reflogして
9102cb2 (HEAD -> hogehoge_branch) HEAD@{0}: rebase finished: returning to refs/heads/hogehoge_branch
省略
50859b6 (origin/develop) HEAD@{10}: pull --rebase origin develop: checkout 50859b63d2ec7911ba6ef791e80324a56077d841
こんな感じのが出力されるので、git reset --hard HEAD@{11}したらよい（head番号はもちろん変わります）

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-16T09:58:37+09:00

GitHub CLIの導入手順

そもそもGitHub CLIとは

前提としてCLIとは、コマンドラインインターフェイス(Command line interface)の略です。

つまりGitHub CLIとは、これまでブラウザ上で行っていたGitHubの操作(プルリクエストの作成やリポジトリの作成など)をMacならターミナル上で可能にするツールのことを指します。

※GitHubが公式で公開してます
　https://github.com/cli/cli

インストール方法

Macなら以下で一発です
brew install gh
※Windowsの方はこちらを参照
　https://github.com/cli/cli

次に自分のGithubと紐付けしましょう
gh auth login
これで自分のGitHubにログインします。すると、
? What account do you want to log into?  [Use arrows to move, type to filter]
> GitHub.com
  GitHub Enterprise Server
と聞かれますので、GitHub.comを選択し、思いっきりEnterを押すと、
? How would you like to authenticate?  [Use arrows to move, type to filter]
> Login with a web browser
  Paste an authentication token
と聞かれます。
要はどの様にして認証しますか？と聞かれているだけなので、今回はLogin with a web browserを選択し、再度思いっきりEnterを押します。すると、
First copy your one-time code: ●●●●-●●●●
- Press Enter to open github.com in your browser... 
と表示されると思います。

※●にはそれぞれ英数字が入る。

Enterを押して頂くと、

こんな画面がデスクトップ上に出ると思いますので、先程の●●●●-●●●●をコピーして貼っ付けて下さい。

後はContinue→Authorize githubの順に進んだらほとんど完了です。

ターミナルに戻りますと、
✓ Authentication complete. Press Enter to continue...
とあり、要は認証は完了したよ。Enterさっさと押して次へいってねとあるのでEnterを押します。すると、
? Choose default git protocol  [Use arrows to move, type to filter]
> HTTPS
  SSH
と出てきます。
デフォルトのプロトコルを選択してねとありますので、今回はHTTPSを選択します。
✓ Configured git protocol
✓ Logged in as [ここにGitHubのユーザーネーム]
と表示されれば完了です！！！

これでghコマンドが使える様になっていると思います！！！

ghコマンドについては丁寧にまとめられていた記事を見つけたのでそちらをどうぞ(^^)
GitHub CLIで始める快適GitHub生活
https://qiita.com/ryo2132/items/2a29dd7b1627af064d7b

お疲れ様でした！！！

　 Tweet
Qiitaで続きを読む

投稿日：2020-12-16T02:02:11+09:00

【入門】GitHub備忘録１【ぶっちゃけ良くわかってない】

はじめに

先日初めてGitHubを導入したので備忘録。
偉い人が口を揃えてアウトプットの大事さを語るので乗せられてみました。
タイトルの通り私自身良くわかってない事もありますので、間違った記載がありましたらご指摘いただけると嬉しいです。
拙い記事ではありますが、よろしくお付き合いください。

目次

1.GitHubとは
 2.前提条件
 3.Gitの初期設定
 4.リポジトリの作成
 5.インデックスに追加
 6.ローカルリポジトリに反映
 7.リモートリポジトリに反映
 8.まとめ

1. GitHubとは

ご存知の通りGitをオンライン上で管理するアレです。
おおまかな概要は下記のサイトがわかりやすいかと思います。
>>GitHubとは？概要やメリットを初心者向けに簡単解説！

本記事では「コマンド打ったら色々出来るのは分かったが、いまいち何してるか分からん」状態の人間向けにイメージしやすいような説明をしていきたいと思います。
実際に手を動かしながらやっていきましょう。

2. 前提条件

まず、本記事に沿ってGitを触る前提条件
- Gitのインストールを済ませてある
- GitHubのアカウント作成済み
- Windows10が基準

Gitのインストールは下記のサイトを参考に。
>>【初心者向け】Gitのインストール方法をわかり易く解説（画面付き）

3. Gitの初期設定

インストールが終了すると「Git Bash」「Git CMD」「Git GUI」が現れますが、私の記事では「Git Bash」を使用します。
理由はLinuxで覚えたコマンドが使えるからです。
コマンド操作覚えてて損はないので今のうちに慣れておきましょう。

初期設定

まずはユーザー名を設定します。
下記コマンドのを入力、実行してください。
$ git config --global user.name ここにユーザー名を記入
次にメールアドレスを設定します。
下記コマンドのを入力、実行。
$ git config --global user.name ここにメールアドレスを記入
ちゃんと設定できたか確認します。
$ git config --list
上記を入力するとこんな感じに設定が表示されます。

赤で囲った所にユーザー名とメールアドレスが表示されてるのがわかりますね。
複数人で作業した際、誰が変更したのか判別するためにきちんと設定しておきましょう。

4. リポジトリの作成

リポジトリとは「貯蔵庫」「収納庫」という意味です。
Git及びGitHubでは「リポジトリ」という大きな箱に仕様・デザイン・ソースコードなど、システムを構成する様々なデータを入れて管理します。
カタカナだらけで混乱しますよね。わかります。

4-1リポジトリ作成の前に

リポジトリを作成する前に、作業用のディレクトリを作ります。
今回は仮に「test01」という名前のディレクトリにします。
$ mkdir test01　　　//「test01」ディレクトリを作成
$ cd test01     　　//「test01」ディレクトリに移動
上記はUnixコマンドといって、Linux等で使用されてるコマンドです。
今はよくわからなくても、なんとなくでやってみましょう。

イメージ的にはこんな感じです(多分)

4-2ローカルリポジトリの作成

では、ローカルリポジトリを作成します。
下記コマンドを入力してください。
$ git init
はいおしまい。ローカルリポジトリできました。
簡単すぎてちゃんとできてるか不安ですが、こんなもんです。

4-3リモートリポジトリの作成

次にリモートリポジトリを作ります。
前提条件でGitHubのアカウント作成してるかと思うので、お好きなブラウザでGitHubのマイページに行きます。
ヘッダー右側に「▼＋」みたいなマークがあるのでクリック。
プルダウンから「New repository」を選択すると、下の画像のようなページに飛びます。

①任意のリポジトリ名を入力
②Public(公開)かPrivate(非公開)を選択
➂「Create repository」をクリック

これでリモートリポジトリが作成されました。

4-4リモートリポジトリを紐づけ

ローカルとリモートでやり取りをするにはリポジトリ同士の紐づけが必要です。
下記コマンドで”ユーザ名”を自分のGitHubユーザ名に書き換え、”リポジトリ名”に先ほどGitHubで作成したリポジトリ名を入力し、実行します。
$ git remote add origin https://github.com/ユーザ名/リポジトリ名.git
これでローカルとリモートのやり取りができるようになります。

5. インデックスに追加

ここからようやくファイルの操作に入ります。
ですがtest01ディレクトリは空なので、適当なファイルを作りましょう。

ファイルの作成

エクスプローラーからtest01ディレクトリに移動し、「右クリック」＞「新規作成」＞「テキスト文書」でテキストファイルを作成します。
今回は「sample01.html」「sample02.html」の二つを用意しました。
テキストファイル作成時デフォルトで「.txt」拡張子が付いていますが、書き換えちゃって大丈夫です。
テキストの中も今回は空でいきます。

インデックスに追加

ローカルリポジトリに反映するには、まずインデックスに反映したいファイルを追加します。
$ git add sample01.html
インデックスに追加することで、ディレクトリ内にあるファイルから変更を反映したい物だけ選ぶことができます。

6. ローカルリポジトリに反映

インデックスへ追加したファイルをリポジトリに反映。
つまり、「コミット」します。
まだ未熟者なので「コミット」って常用するのなんか恥ずかしいです……。
$ git commit 
ここにきても私自身「あ、コミットされたわ」と実感が持てないんですよね。
そんなもんです。

7. リモートリポジトリに反映

下記コマンドを入力し、ローカルリポジトリの変更をリモートリポジトリに反映(Push)します。
GitHubのユーザ名とPWを要求されるので、正しく入力しましょう。
省略するやり方もあるらしいのですが、またの機会に。
$ git push origin master
反映後はGitHubの「Your repositories」から確認できます。
私はここまできてやっとGitHub使えてる実感が3㎜ぐらい湧きました。

8.　まとめ

こんなかんじでGitHubつかうんだなーってイメージ出来ればOkです。
最後までお付き合いいただきありがとうございました。
次回はブランチ機能についての備忘録(予定)(続けば)。

以下、参考までに。

今回使ったコマンド一覧
$ mkdir 任意のディレクトリ名　　 //ディレクトリを作成
$ cd 任意のディレクトリ名     　 //ディレクトリに移動
$ git init
　　//現在のディレクトリをローカルリポジトリとして初期化
$ git add ファイル名　　　　　　 //インデックスへ追加
$ git commit 　　　　　　　　  //インデックスへ追加したファイルをコミット
$ git remote add origin https://github.com/ユーザ/リポジトリ名.git
　　//ローカルリポジトリとリモートリポジトリを紐づけ
$ git push origin master
　　//ローカルリポジトリの変更内容をリモートリポジトリに反映
実際起こったエラー
fatal: pathspec '{ファイル名}' did not match any files
//原因：ファイル名が間違ってた
//対処：ファイル名を正しいものに書き換えた