What's New Qiita

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

  • 投稿日：2021-01-08T22:51:37+09:00

gitお勉強 GitHubアカウント作成とcommit、push

けんきうしつのフレンズに送り付けた怪文書のQiita版です。

gitとは？

変更履歴を記録・追跡するための分散型バージョン管理システム。 Git - Wikipedia

Linuxカーネルの膨大なソースコードを効率的に高速な管理をするためにリーナス・トーバルズによって開発されたもの。
言ってしまえばLinuxのために生み出されたLinuxの副産物。リーナスさん最強すぎる。

GitHub / GitLabとは？

GitHubは最もポピュラーなgitリポジトリホスティングサービス。
最近の有名なオープンソースソフトウェアのほとんどはGitHubを通じてソースコードが公開されている。
（rails/rails: Ruby on Rails とか、laravel/laravel: A PHP framework for web artisans とか）

GitLabも同じく有名なgitリポジトリホスティングサービス。DevOps Platform Delivered as a Single Application | GitLab
しかし、ホスティングサービスとしてというよりは、自分で用意したサーバへGitLabの環境を構築し、自分の用意したサーバを通じて身内の中でプロジェクトを共有するためによく利用されている印象。

このようなサービスはgitにより管理されているプロジェクトをクラウド上で管理し、大勢と共有し、ともに開発を進めたり、問題を報告したり、議論したりすることができるものです。そのためgitと密接ではあるものの、また違うものという感じ。

gitはコマンドラインツール、GitHub/GitLabはWebサービス。 ざっくりとこんな印象を持っておいてください。

GitHubのアカウントを作る

https://github.com/ を開きましょう。

image.png

右上の Sign upからアカウントの作成を行いましょう！

image.png

ちゃっちゃか必要項目を入力します。

Usernameは割とバシバシに公開されるし割と入力するのでそれなりに覚えやすいもののほうが良いと思います。
Email addressはとにかく通じればよし。
PasswordはGitHubにブラウザからログインするときにくらいしか使わないのでなんでも良いと思います。

んで、アカウントつくると「メールにリンク送ったから確認してちょ」みたいになると思うのでメールボックスを開いて確認を済ませましょう。

公開鍵の登録を行う

sshの設定をするとき、scpコマンドで鍵を送ったように、GitHubにも公開鍵を登録してパスワードいらずでGitHubとやり取りできるようにしておこう。
鍵がない場合はssh-keygenして鍵を作ろう。詳しくは調べてくれると助かる...

GitHubがGit操作時のパスワード認証を廃止、今後はトークンによる認証が必須に - GIGAZINE にもある通り8月でクライアントによるパスワード認証の利用が廃止される。あとGitLabも公開鍵認証方式でやりとりすることになるのでまずは試しにGitHubで鍵登録を行ってみよう。

まず、自分の公開鍵を確認する。以下のコマンドをタイプすることで確認できるはず。

# windows
notepad $HOME/.ssh/id_rsa.pub

# macOS / Linux
less ~/.ssh/id_rsa.pub

ちょっと解説しておくと$HOMEはC:\Users\<ユーザ名>の文字列が格納されている環境変数で、これはすなわちホームディレクトリへの絶対パスになっている。
そして.sshディレクトリはホームディレクトリにあるのが基本でssh-keygenに鍵が作成されるデフォルトのディレクトリも.sshでデフォルトの公開鍵名はid_rsa.pubなので$HOME/.ssh/id_rsa.pubに鍵があることが多いのです。
おそらくこれ以外のディレクトリに鍵がある場合は有識者なので特別な解説はいらないかなって。

あ、あとあと。似た名前のファイルでid_rsaがあると思うがこいつは秘密鍵につき門外不出にして最高機密の情報なので何があってもほかの人に見せたりどこかにコピペしたりしないこと。もし門の外に持ち出しちゃったかも...と思ったらssh-keygenして鍵を書き換えて、今までいろいろなところに登録した公開鍵を新しく生成したものに変えること。
もし、知らない人に秘密鍵を奪取されてしまったら、SSHでサーバをあなたの名義で勝手に使ったり、GitHubのアカウントへのかなり強めなアクセス権が奪われたことと同義になります...

このコマンドをタイプするとWindowsならばメモ帳が起動して公開鍵を表示してくれているはずなのでファイル内容すべてをクリップボードへコピーする。
macOSなりLinuxなりならば画面に公開鍵が表示されているはずなのでファイル内容すべてをクリップボードにコピーしておく。記憶できるのならば脳みそで覚えてもいいけど...

次に、GitHubのSettingsページを開く。

image.png

Settingsを開いたらSSH and GPG keysをクリック。

image.png

そしたら、new SSH key的なミドリのボタンがあるはずなのでそいつをクリック。

image.png

Titleには鍵の名前を入力しよう。複数台パソコンを使う人なら複数の鍵を登録することになるのでどのパソコンの鍵かわかりやすくしておくとよいと思う。
Keyには先ほどコピーしたものをペーストする。

最後にAdd SSH keyをクリックすれば公開鍵の登録完了！やったね！
ちゃんと登録できているかは少し後で確認しましょう。

リモートリポジトリを作成する

GitHubにログインした状態でページ左上のこのミドリのやつをクリックしよう。

image.png

そしたらこんな感じのリポジトリ作成画面に移るので必要項目を入力しよう。

image.png

Repository Name

リポジトリの名前。
これから作成するソフトウェアの名前ともいえるもの。内容が分かりやすいものがよいだろう。
またこのリポジトリをcloneするとRepository Nameがディレクトリ名となるのでほどほどの長さがよいかと思います。

Description (optional)

リポジトリの説明です。
どんなリポジトリなのか、どんなソフトウェアなのかを書くことができます。
optionalなので書かなくていいです。書いても特に何にも影響しないので書いてもいいです。

Public / Private

PublicにするとGitHubで公開されます。誰でもこのリポジトリに含まれるファイルを閲覧することができ、forkして派生プロジェクトを作成することもできます。ただし、設定を変更したり、だれかを招待しない限りは勝手にほかの人に内容を書き換えられることはありません。

Privateにすると自分と招待されたユーザだけしか内容が確認できないリポジトリになります。

どちらを選んでもちょっと使う分にはあんまり違いはないのでどっちでも大丈夫です。
Pricing · Plans for every developer に細かい違いが書いてあります。

Initialize this repository with:

リポジトリ作成と同時に最初のコミットを作成するかどうかの欄です。
リポジトリ作成と同時にコミットをしたくないときはいずれにもチェックを入れる必要はありません。

いずれかひとつでもチェックを入れるとデフォルトのブランチとしてmainが作成され、Initial commitされた状態のリポジトリが作成されます。

Add a README file

README.mdファイルを追加しておくオプションです。

README.mdファイルは通常、ソフトウェアの利用方法や、開発の仕方、開発者の連絡先などを記しておくファイルです。
Markdown記法で書かれることが多く、GitHubではREADME.mdファイルを良い感じにプロジェクトページに表示してくれたりします。

image.png

Add .gitignore

.gitignoreをあらかじめ作成しておくオプションです。

.gitignoreファイルはgitでバージョン管理させたくないファイルを指定するためのファイルです。
例えばコンパイルして生成されるファイルやパッケージマネージャによりダウンロードされるファイルなどを指定しておくことで、不必要に変更を記録してごちゃごちゃしたりだとか、リポジトリのやり取りを不必要に重くすることを防ぎます。

Choose a license

オープンソースライセンスを指定し、LICENSEファイルを作成するオプションです。

オープンソースライセンスとはGitHubなどで公開されているソースコードを2次利用する際のルールとして掲示するものです。
Apache License 2.0やMIT License、クリエイティブ・コモンズ・ライセンスなど、見聞きしたこともあるのではなかろうか。
これらには何をしてよくて、何をしてはダメなのかが明記されており、ライセンスとして自由に使っていい文書として公開されているものです。
これらのオープンソースライセンスはLICENSEの定型文のようなもので、適用したいルールと一致しているライセンスがあればこれをそのまま記せば自分はライセンスを書く手間が省けるし、利用する側も知ってるライセンスなのでルールを把握できていていちいち全文を確認する必要ななくお互いにハッピーな取り組みです。

自分のプロジェクトにLICENSEという名前テキストファイルを配置してあげることで「これに従って2次利用しなさい」とお願いしていることになります。不特定多数に広めたいプロジェクトならば必ず作成すべきですがそうでもないならなくても問題にならないです。

ちなみに、オープンソースライセンスの中には「成果物を必ずオープンソースにし、このライセンスを適用しろよな」みたいな強い制約のあるものもあるので、見たことないライセンスを目にしたら全文読んでみるうえに和訳なり解説記事を読むなりしてライセンスで制限されていることを十分に理解してから使うようにしましょう。

リモートリポジトリへのURLをクリップボードにコピーする

リポジトリのページの真ん中へんにあるCodeのミドリのやつをクリックすると何やらリンクが表示される。

image.png

これのSSHのところに下線が引かれているか確認しよう。
HTTPSとかになっていたらSSHをクリックしてリンクをクリップボードへコピーしておこう。

HTTPSのリンクを使ってもいいけど... さっき公開鍵登録したしさ... パスワードを手入力しなくてよくなるんだ...

おっと、ここでちょっとルート分岐だ。
先ほど、Initialize this repository with: のどれかにチェックを入れたかな？

入れていたらリポジトリをcloneするに、入れていなければローカルリポジトリを作成するに進んでくれ！

リポジトリをcloneする

コマンドラインでリポジトリを配置したいディレクトリを開いて次のコマンドをタイプしよう。

git clone git@github.com:XXXXXX/XXXXX.git # <- コピーしたURL

公開鍵の登録が正しくできていればリポジトリがGitHubよりダウンロードされ、自分のパソコンに配置される。
これがcloneと呼ばれる操作でリモートに存在するリポジトリをローカルにダウンロードしている。

アクセスできなさそうな感じになったら公開鍵の登録がうまくできていない。
先ほど追加した鍵を削除してもう一度鍵の登録を試してみよう。

ローカルリポジトリを作成する

コマンドラインからリポジトリを配置したいディレクトリを開こう。

プロジェクトのルートディレクトリとなるディレクトリを作成しよう。
この時作成するディレクトリの名前は先ほど作成したリモートリポジトリのものとそろえておくのがベターだ。

mkdir your-repository-name # リポジトリの作成
cd your-repository-name # カレントディレクトリの移動

そしていよいよ、ローカルリポジトリの作成だ。
いでよ、git init ───

git init

そうするとまだインターネッツに接続されていないローカルリポジトリが作成される。
このままだと井の中の蛙大海を知らず、だれもこのプロジェクトを知らないし、きみのパソコンだけに幽閉されてしまっている。
リモートを追加してGitHubにアップロードできるようにしてあげようじゃないか。

git remote add origin git@github.com:XXXXXX/XXXXX.git # <- 先ほどコピーしたURL

git remote addはリモートの追加を行うコマンド、originはデフォルトのリモートの名前としてよく使われている。
特別な理由がなければoriginとして登録しておくのが無難だと思うけど、別にどんな名前でも差し支えない。
そして最後に先ほどコピーしたURL。こちらを参照してリポジトリを共有したり、GitHubでのリポジトリの状態を取得したりするわけだ。

ちゃんと登録できたか、確認してみよう。

git remote -v

これでなんか2行くらい出てきたらおっけー。

では、けなげなローカルリポジトリをインターネッツに染め上げてやろうか...

git push -u origin main

git pushはリモートにローカルリポジトリに加えた変更を反映させるコマンド。これをタイプすることでリモートへ自分の生み出した進捗が共有され、他のチームメンバーがこの進捗を取り込んだりすることもできるってこと。
-uオプションは今後mainブランチが参照するリモート（up stream）を設定してあげている。これからはgit pushだけタイプすれば変更がリモートに反映されるようになります。
最後のmasterはリモートに作成されるブランチの名前。なんでもかまいません。伝統的にはmasterです。

black lives matterに配慮してGitHubではデフォルトのブランチ名がmainに変更されていますが、gitがデフォルトで作成するブランチ名はmasterのままです。そのうち変わったりするのだろうか...
この記事では以下mainを使っていきますので適宜読み替えてね。 デフォルトのブランチ名変えたいときはググってみよう。

このコマンドをタイプするとリモートにローカルリポジトリの内容が反映される。
公開鍵の登録が正しくできていればリポジトリがGitHubアップロードされる。
これがpushと呼ばれる操作なのである。

アクセスできなさそうな感じになったら公開鍵の登録がうまくできていない。
先ほど追加した鍵を削除してもう一度鍵の登録を試してみよう。

メールアドレス / 名前の設定

さて次はcommitを試しにしてみたいのだが、このままだとgitに「おまえだれやねん」って怒られる。
なので、メールアドレスと名前を設定しよう。

git config --global user.name 好きなお名前
git config --global user.email c0118999xx@edu.teu.ac.jp

お名前は特になんでもいいけど、GitHubのアカウント名が適切かと思います。
メールアドレスはGitHubでの表示に絡んでくるのでGitHubでの登録に使ったメールアドレスにしておくのが良いかと思います。

コミットしてみる

エディタか何かでリポジトリのディレクトリにファイルを追加してみよう。
そして、git statusコマンドを実行してみよう。

$ git status
On branch master

No commits yet

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

nothing added to commit but untracked files present (use "git add" to track)

こんな感じの出力があればよろし。

そしたらgit addしよう。

git add 作成したファイル名

# とにかくすべてのファイルをコミットするファイルとする
git add *

git add出来たらgit commitだー！
コミットに対するコメントは何でもよいですが、どんな作業をしたかわかりやすいものを書くと有識者がメロメロになります。

-mオプションはコミットにコメントをつけるというものです。
これを省いてgit commitだけタイプするとviエディタを使って「コミットメッセージ打てやコラ」みたいな感じになります。
もし間違えちゃったときはescキーを押して :wqとタイプしてenterを押すととりあえず抜けられます。
viエディタの使いかたを習得すると長文コミットメッセージを打ちたいときなんかに便利です。

git commit -m "コミットに対するコメント"

コミットという操作はRPGゲームなんかで新しいスロットにセーブを書くようなもの。
コミットを打った時点にいつでもリポジトリすべてでも一部のファイルだけでも復元することができたりします。

とにかく、進捗を生んだらコミット。コミットメッセージをひとことで言い表せるくらいの細かさで作ると有識者にモテます。

pushする

いくらコミットしても git pushをしない限りはリモートリポジトリに反映されません。
コミットしたら忘れずにgit pushをしましょう。

git push

さすればきみがコミットした進捗はインターネット上に共有されるってワケ。
ざっくりこれらのコマンドを活用してみんなでひとつのソフトウェアを作り上げたりあげなかったりします。

ちゃんとgit pushできたか、GitHub上で確認しましょう！
git pushに失敗したらメールアドレス/名前の設定ができていないことが主に考えられます。git config --global user.email、git config --global user.nameのコマンドをタイプして設定が完了しているか確認しましょう。

多分連載。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T22:45:24+09:00

【Gitを使い始めて１年】SourcetreeとGitの併用という個人的ベストプラクティス

Gitに触れて1年が経ちました

昨年のこの時期、Gitの入門書を買ってSourcetreeの使い方を勉強したり、簡単なGitコマンドを学習していました。
その後、業務のソース管理をGitで行うようになり、約１年の月日が流れたということで、自分なりのGitの使い方について、これからGitを勉強する方や始めたばかりの方にお役に立てればと思ってこの記事を書いています。

この記事の目的

【対象の方】
（主に）Git初学者の方

【書く理由】
僕の周りには、Gitを使う上で、Sourcetree派とGitコマンド派に分かれていて、個人的には併用するのが一番使いやすいなぁと思ったから。

SourcetreeとGitコマンドについて

Sourcetree

Gitを簡単に使えるようにした、GUIツール。初心者が躓きがちな、コマンドプロンプトを使わずに、視覚的に操作できるのが特徴。

Gitコマンド

コマンドプロンプトやターミナルで、Gitが用意しているコマンドを入力して、操作する方法。

Sourcetreeのほうが便利な操作

Sourcetreeの強みは、ソースの差分や履歴が視覚的に見えやすいところです。なので、主に目で見て確認したほうが、間違いが少ないよね。といった操作をSourcetreeで行うのがオススメです。実例をあげるとこんな感じです。

1. ローカル環境でのコミット作業

Sourcetreeでコミット作業を行うメリットとしては、特定のファイルはコミットに含めたくない、特定ファイルの特定箇所だけコミットしたい。などと言ったときに、GUIで対象を指定できるので、Gitに慣れてなくてもなんとなくで操作できます。あと、コミットメッセージを書くのが楽です。

2. コンフリクト発生時の発生箇所の確認、解決時のコミット

コンフリクトが発生したとき、めっちゃ焦りますが、Sourcetreeを使うことで、視覚的にコンフリクト箇所を見ることができるので、少し落ち着きます。（笑）

3. コミット履歴の閲覧

個人的に絶対にSourcetreeのほうが見やすいです。特に、ブランチの数が増えたり、マージコミットが多くなると尚更。

4. ブランチのチェックアウト

Sourcetreeだと、チェックアウトしたいブランチをダブルクリックするだけで、ブランチの変更ができます。Gitコマンドだとチェックアウトするのに、ブランチ名を入力するので、少しめんどくさい印象。

Gitコマンドの方が便利な操作

Gitコマンドのほうが便利な作業としては、主にリモートとの疎通作業です。
また、マージ、リベースなどは、個人的にGitコマンドのほうがやりやすくて好きです。

1. リモートリポジトリとのやり取り

具体的なコマンドとしては、以下に挙げました。

git fetch 
-> リモートリポジトリの変更を確認する

git pull
-> リモートリポジトリの変更をローカルに取り込む

git push
-> ローカルの変更をリモートに適用する

2. リベース、マージ作業

リベースやマージ作業は、個人的にコマンドのほうが早い気がします。コマンドは、ターミナル(コマンドプロンプト)に履歴が残るため、同じブランチを再度マージしたりするときに、同じコマンドを履歴から探して実行するだけなので、そのあたりが楽でミスも少ないかなと思っています。

現在のブランチがmasterブランチで、developブランチの変更を取り込みたい場合
git merge develop

現在のブランチがdevelopブランチで、ソースベースをmasterの最新に変更したい場合
git rebase master

3. ローカルの変更取り消し

ローカルで開発したソースで不要になったものを取り消ししたいときに以下のコマンド一発で全取消できます。入力量が少ないのでおすすめです。
※新規追加のファイルは削除できないです。

git checkout .

4.その他

たまにしか使わない操作・コマンド。
Gitを使っていると、本当にたまにしか使わない操作を実行するときがあります。
そういうときは、やり方がわからないのでググって調べるのですが、大抵Gitコマンドでのやり方がHitします。
ですので、ググって調べたときは、Gitコマンドを使えたほうが早いというのは、事実だと思います。

結論

なんやかんやどっちもちゃんと使えたほうが便利
以上、、、です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T18:46:02+09:00

Gitについて

はじめに

Gitのコマンドについて学習したので、備忘録もかねてこちらにまとめさせていただきます。

ファイルを選択する

git add ファイル名

選択したファイルを記録する

git commit -m "コミットメッセージ"

「コミットメッセージ」には変更内容を相手にわかりやすいように書く。

リモートの登録

git remote add リモート名　URL

ファイルをアップロードするURLを登録する
リモート名は一般的にoriginとすることが多い

アップロードする

git push リモート名　master

先ほど登録したリモートにアップロードできる。（プッシュという）

ダウンロードする

git pull リモート名　master

ダウンロードできる。（プルという）

変更したファイルが何かを確認する

git status

また、ファイルがaddされているのかどうか確認できる
（addされたファイルが緑色されていないファイルが赤色で表示される）

変更内容を確認する

git diff

変更前は赤色　変更後は緑色で表示される。

変更履歴を確認する

git log

自分や他人のコミット履歴を確認できる

変更内容まで確認する

git log -p

Qキーを押すと終了する。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T18:15:19+09:00

Git 基礎の理解　まとめ

Udemyの講座を受講したので備忘録としてまとめてみた

もう怖くないGit！チーム開発で必要なGitを完全マスター

Gitの設定

初期設定

terminal.
% git config --global <内容> //pc全体の設定
% git config --global user.name <名前> //名前の設定
% git config --global user.email <アドレス>//メールアドレスの設定

エイリアスを設定し入力コマンドを短縮

terminal.
% git config --global alias.<新コマンド> commit //commitコマンド設定
% git config --global alias.<新コマンド> status //statusコマンド設定
% git config --global alias.<新コマンド> branch //branchのコマンド設定
% git config --global alias.<新コマンド> checkout //checkoutのコマンド設定

ブランチ操作コマンド

terminal.
% git branch  //ブランチの一覧表示
% git branch <ブランチ名>  //ブランチの追加
% git checkout <ブランチ名>  //ブランチの切り替え
% git checkout -d <ブランチ名>  //ブランチを追加して切り替え
% git branch -m <ブランチ名>　　//<ブランチの名前変更>
% git branch -d <ブランチ名>  //ブランチの削除
% git branch -D <ブランチ名> //ブランチの強制削除

リモートリポジトリ(GitHub)の操作コマンド

terminal.
% git remote add <github url>  //新規追加
% git remote add origin <github url>  //URLを別名(origin)で新規追加

% git remote  //リモートリポジトリ名の表示
% git remote -v  //リモートリポジトリのURLの表示
% git remote show <リモート名>  //リモートリポジトリの詳細情報を表示
% git remote rename <旧リモート名><新リモート名>　　//リモートリポジトリ名の変更
% git remote rm <リモート名>　　//リモートリポジトリの削除

GitHubにpushするまでの流れ

terminal.
% git status  //変更内容の確認
% git add <ファイル名>  //変更内容をステージ(index)に追加
% git commit  //変更内容をコミット
% git push <リモート名><ブランチ名>  //変更内容をリモートリポジトリ(GitHub)へ送信

GitHubから取り込む流れ

リモート→ローカル→ワークツリー

terminal.
% git fetch <リモート名>  //ファイルの取得
% git merge <リモート名><ブランチ名>  //取得したファイルをワークツリーへ統合

リモート→ワークツリー

terminal.
// ※HEADのブランチ確認
% git pull <リモート名><ブランチ名> //リモートから取得してmergeまでを一度に実行

変更差分・履歴の確認

terminal.
% git diff <ファイル名>  //ステージ(index)に追加前の変更分
% git diff --staged  //ステージ(index)に追加後(commit前)の変更分

% git log  //commit済の変更履歴を確認
% git log -p <ファイル名> //commit済の変更履歴の詳細な差分を確認
% git log -n <コミット数>  //表示するcommit数の指定

変更・取り消し

terminal.
//  ワークツリー内の変更取り消し
% git checkout --<ファイル名>
% git checkout --<ディレクトリ名>
% git checkout -- .  //ワークツリー内全ての変更の取り消し

//  ステージ(index)に追加した変更の取り消し ※ワークツリーの変更は取り消されない
% git reset HEAD <ファイル名>
% git reset HEAD .  //ステージ(index)に追加した全ての変更の取り消し

//  直前のcommitの変更 ※pushする前のcommit
% git commit --amend

mergeとコンフリクトの解消

merge

変更内容をリモートリポジトリから自分のブランチに取り込む作業のこと

コンフリクト

mergeした際に同じ箇所の変更が競合すること

terminal.
% git merge <リモート名>/<ブランチ名>  //リモートリポジトリから変更を取り込む

コンフリクトの解消

① コンフリクトが起きた箇所の内容を書き換える
② 「<<<」 「===」 「>>>」　の記述を削除する

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T18:15:19+09:00

Git 基礎の理解　

Udemyの講座を受講したので備忘録としてまとめてみた

もう怖くないGit！チーム開発で必要なGitを完全マスター

Gitの設定

初期設定

terminal.
% git config --global <内容> //pc全体の設定
% git config --global user.name <名前> //名前の設定
% git config --global user.email <アドレス>//メールアドレスの設定

エイリアスを設定し入力コマンドを短縮

terminal.
% git config --global alias.<新コマンド> commit //commitコマンド設定
% git config --global alias.<新コマンド> status //statusコマンド設定
% git config --global alias.<新コマンド> branch //branchのコマンド設定
% git config --global alias.<新コマンド> checkout //checkoutのコマンド設定

リポジトリ作成

terminal.
% git init

ブランチ操作コマンド

terminal.
% git branch  //ブランチの一覧表示
% git branch <ブランチ名>  //ブランチの追加
% git checkout <ブランチ名>  //ブランチの切り替え
% git checkout -d <ブランチ名>  //ブランチを追加して切り替え
% git branch -m <ブランチ名>　　//<ブランチの名前変更>
% git branch -d <ブランチ名>  //ブランチの削除
% git branch -D <ブランチ名> //ブランチの強制削除

リモートリポジトリ(GitHub)の操作コマンド

terminal.
% git remote add <github url>  //新規追加
% git remote add origin <github url>  //URLを別名(origin)で新規追加

% git remote  //リモートリポジトリ名の表示
% git remote -v  //リモートリポジトリのURLの表示
% git remote show <リモート名>  //リモートリポジトリの詳細情報を表示
% git remote rename <旧リモート名><新リモート名>　　//リモートリポジトリ名の変更
% git remote rm <リモート名>　　//リモートリポジトリの削除

GitHubにpushするまでの流れ

terminal.
% git status  //変更内容の確認
% git add <ファイル名>  //変更内容をステージ(index)に追加
% git commit  //変更内容をコミット
% git push <リモート名><ブランチ名>  //変更内容をリモートリポジトリ(GitHub)へ送信

GitHubから取り込む流れ

リモート→ローカル→ワークツリー

terminal.
% git fetch <リモート名>  //ファイルの取得
% git merge <リモート名><ブランチ名>  //取得したファイルをワークツリーへ統合

リモート→ワークツリー

terminal.
// ※HEADのブランチ確認
% git pull <リモート名><ブランチ名> //リモートから取得してmergeまでを一度に実行

変更差分・履歴の確認

terminal.
% git diff <ファイル名>  //ステージ(index)に追加前の変更分
% git diff --staged  //ステージ(index)に追加後(commit前)の変更分

% git log  //commit済の変更履歴を確認
% git log -p <ファイル名> //commit済の変更履歴の詳細な差分を確認
% git log -n <コミット数>  //表示するcommit数の指定

変更・取り消し

terminal.
//  ワークツリー内の変更取り消し
% git checkout --<ファイル名>
% git checkout --<ディレクトリ名>
% git checkout -- .  //ワークツリー内全ての変更の取り消し

//  ステージ(index)に追加した変更の取り消し ※ワークツリーの変更は取り消されない
% git reset HEAD <ファイル名>
% git reset HEAD .  //ステージ(index)に追加した全ての変更の取り消し

//  直前のcommitの変更 ※pushする前のcommit
% git commit --amend

mergeとコンフリクトの解消

merge

変更内容をリモートリポジトリから自分のブランチに取り込む作業のこと

コンフリクト

mergeした際に同じ箇所の変更が競合すること

terminal.
% git merge <リモート名>/<ブランチ名>  //リモートリポジトリから変更を取り込む

コンフリクトの解消

① コンフリクトが起きた箇所の内容を書き換える
② 「<<<」 「===」 「>>>」　の記述を削除する

リベース

変更履歴を一直線に整えて取り込む

terminal.
% git branch
  master2
* master

% git checkout master2
% git rebase master
% git checkout master
% git merge master2

commit履歴の書き換え

terminal.
% git rebase -i HEAD~<コミット数(3)>

pick a0ca45c github　追記
edit 91f7a7e master2新規作成  //先頭のpickをeditに変更
pick 53118f1 masterを新規作成

% git commit --amend  //変更したい内容を修正後
% git rebase --continue  //次のコミットへ移動　※今回editは１つのみのため終了

複数のcommit履歴をまとめる
※squashに指定したcommitと直前のcommitがまとめられる

terminal.
% git rebase -i HEAD~<コミット数(3)>

pick a0ca45c github　追記
squash 91f7a7e master2新規作成  //先頭のpickをsquashに変更
squash 53118f1 masterを新規作成  //先頭のpickをsquashに変更

タグ

terminal.
% git tag <タグ名>  //タグの作成
% git tag -a <タグ名> -m <メッセージ>　　//注釈付きタグの作成
% git tag <タグ名><コミット名>　　//過去のcommitにタグを作成

% git show <タグ名>  //タグのデータを表示
% git push <リモート名><タグ名>　　//タグをリモートリポジトリに送信
% git push < リモート名>　--tags  //タグを一斉にリモートリポジトリに送信

stash

作業の一時避難

terminal.
% git stash  //作業を一時避難

% git stash list  //避難した作業の確認

% git stash apply  //避難した作業の復元
% git stash apply --index  //ステージ(index)の状況も復元

% git stash drop  //避難した最新の作業を削除
% git stash drop <スタッシュ名>　　//避難した特定の作業を削除
% git stash clear  //避難した全ての作業を削除

まとめ

下記の講座ではより分かりやすく図解で表現されています。
基礎の基礎を理解できるためおすすめです。

もう怖くないGit！チーム開発で必要なGitを完全マスター

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T17:41:09+09:00

git pullでコンフリクトした際の対応方法

Gitでpull requestしてコンフリクトした際の対応方法

Gitでpull requestしてコンフリクトした際になんとなく対応しておりましたので、改めて対応方法をまとめてみました。

※主に自身の毎日の復習・学習の機会創出、アウトプットによる知識の定着を目的としております。
暖かい目で見ていただけますと幸いです。

git pullとは

リモートリポジトリの変更をローカルリポジトリに取り込みコマンドが「git pull」。

※既存のリモートリポジトリのソースコードを取得したい場合は「git clone」で複製。git pullはその変更(バージョンアップ)を取得できる。

そもそもコンフリクトとは

同じファイルの重複する部分が変更されると、変更内容同士が衝突して「コンフリクト」と呼ばれる状態を引き起こします。

git側がどちらの変更を優先して良いかわからず「コンフリクトしていますので
人間の方でどっちが良いか対応してください」と言うニュアンスになります!

対応方法

※STEP0:　リモートリポジトリからmasterブランチをpull

git pull origin master

STEP1: ローカルで競合を解決

コンフリクトが発生しているファイルの目印

対象のフォルダ名は赤字で表示されている

フォルダ内のコンフリクトが発生しているコードの目印

<<<<<<< HEAD
  //処理1
=======
  //処理2
>>>>>>> 1111111111111 //仮の番号

このHEADの記載がある部分がコンフリクトの箇所になります。

======= の上:ローカルリポジトリ
======= の下:リモートリポジトリ

STEP2: 修正したコードを再度コミットしてプッシュ

git add .　など。。。

完了!!

まとめ

gitについてもまだまだわからないことばかりなので、勉強するためにまとめ・アウトプットしていきます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T14:01:07+09:00

必要最低限のgitコマンド一覧

投稿の趣旨

gitの勉強をしている際に、覚えるべきgitコマンドがかなり多く頭がパンパンになってしまったため備忘録として記載する。

カレントディレクトリの移動する。

カレントディレクトリ　「.」
ホームディレクトリ　　「~」
ルートディレクトリ　　「/」

$ cd ~      //ホームディレクトリの場合

カレントディレクトリのパスを確認する。

$ pwd

新しいディレクトリを作成する。

$ mkdir ディレクトリ名

ローカルリポジトリを作成する。

$ git init

ステージングエリアに変更を登録する。

$ git add ファイル名

コミットする。

-m：コミット時にコメントを追記するオプション
-am：ワークツリーから一気にコミットしてコメントを追記するオプション

$ git commit -m"コメント"　

$ git commit -am"コメント"　

ワークツリーの変更を取り消す。

不要なファイル修正をしてしまった際に、コミットした時のファイルに戻す。
但し、このコマンドで取り消せないケースがあり、それは以下の2点。
その場合はコマンドではなく自身でファイルを削除する必要がある。
・ファイルを新規作成したとき。（コミット自体していないため）
・ファイル名を変更したとき。（ファイル名を変更すると追跡できないため）

$ git checkout -- ファイル名

ワークツリーに特定のバージョンを反映する。

ブランチを作成して、作業するバージョンの切替えに使用する。

$ git checkout ファイル名

ステージングエリアへの登録を取り消す。

間違ってステージングエリアに登録してしまったときに使用する。
ステージングエリアというステータスのみ取り消すため、ワークツリーでの
変更は取り消されない。

$ git reset HEAD ファイル名

ファイル、ディレクトリを削除する。

Git管理下にある不要になったファイルもしくはディレクトリを削除する。
削除した場合もコミットが必要になるので忘れないこと。

$ git rm ファイル名

$ git rm -r ディレクトリ名

コミットの履歴を確認する。

$ git log

リポジトリをフォークする。

複数人で作業するとき等、複製元のリモートリポジトリをフォーク（複製）して、自分のリモートリポジトリに取得する。さらに、下のクローン作業でローカルリポジトリに取得し作業を開始する。
フォークする方法は、複製元のリモートリポジトリをGitHubで検索し、Forkボタンをクリックするのみ。

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

GitHubのClone or downloadのSSHを選択し、記載されているURLをコピーし、以下のコマンドを入力する。

$ git clone URLをコピペ

ファイルの差分を確認する。

ワークツリーとステージングエリアの差分を確認。

$ git diff

ステージングエリアとGitディレクトリの差分を確認。

$ git diff --cached

Gitで管理しないファイルの取り扱い

ローカルリポジトリに「.gitignore」ファイルを作成し、管理しないファイル名を中に記載する。当ファイルを保管する場所は「.git」ディレクトリと同じレベルの階層が望ましい。.gitignoreの効果がある範囲は、.gitignoreを配置したディレクトリ配下のパスであるため。
管理したくないファイルを一度ステージングエリアへ登録し、git stutasで確認すれば反映されているかどうかを判断できる。

管理すべきではないファイル

・自動生成される一次ファイル（ログファイル、パッケージファイル、バックアップファイル）
・OSのファイル管理に伴うもの（WindowsのThumbs.db、macOSの.DS_Store）
・パスワードが書かれたファイル ...etc

ブランチする。

元データであるmasterブランチに対し、編集用のファイルを作成（分岐点の形成）する。
ブランチを作成して編集するときは、どのブランチを操作しているのか認識して実施すること。
git checkoutコマンドで操作するブランチを切り替えることができる。

$ git branch 作成するブランチ名

また、ブランチの一覧を表示したい場合は以下のコマンドで表示できる。
選択しているブランチは、*の印が付いている。
（git statusコマンドでも、on branchの項目に記載されている）

$ git branch

ブランチをプッシュする

ローカルリポジトリで作成したブランチを、リモートリポジトリへ反映させること。
流れとしては、そのデータをチェックして頂いた（レビュー）後、マージ（ブランチの結合）する。

$ git push origin プッシュするブランチ名

リモートリポジトリに元データが存在しない場合（新規作成）、以下のコマンドでGitHubへプッシュし、ローカルリポジトリへ反映する。

$ git remote add origin https://から始まるリモートリポジトリのURL
$ git push origin master

リモートリポジトリからローカルリポジトリへ反映する。

マージされた最新データを、ローカルリポジトリへ反映する。（プル）
※masterブランチにcheckoutしてから実施すること。

$ git pull origin master

ワークツリーへの反映はせず、内容を確認したいだけの時（ローカルリポジトリに入れたいだけの時）は以下のコマンドを使用する。（フェッチ）
その後、ワークツリーに反映したい場合はプルする。

$ git fetch origin
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T13:02:13+09:00

明日から使えるGitHub便利機能 7選 (2021年版)

github-logo_icon-icons.com_73546.png

はじめに

現在、多くの開発のバージョン管理ツールとしてGitが利用されるようになりました。
その中でも特に多くの開発で利用されているサービスと言えばGitHub 。
この記事ではチーム開発を加速させるオススメ機能を7つ厳選してご紹介致します。

対象読者

  • GitHubを用いてチームで開発・運営を行っている方
  • GitHubをうまく活用してコミュニケーションを円滑にしたいと考えている方

お品書き

  1. Issues/PullRequestテンプレート機能
  2. コードオーナーの設定と自動マージ
  3. Draft pull Request機能
  4. コードハイライト機能
  5. Diff機能(ブランチ、タグ、コミット)
  6. GitHub Grep機能(高度検索機能)
  7. ブランチタイムライン表示機能

1. Issues/PullRequestテンプレート機能

IssuesやPullRequest作成時に文面をテンプレート文章を自動的に挿入します。

【メリット】

  • 記載内容の統一し、コミュニケーションロス低減
  • 過去のIssueのコピペ・編集の手間の削減

【デメリット】

記載粒度が細かいと形骸化する。

Issuesテンプレートの作成方法

Settingタブから実施要領は以下の通りです。
（※リポジトリ設定権限がない場合は後述の「Settingタブが表示されない場合(リポジトリの設定権限がない場合）」を参照ください）

1.1.1 GitHubのSettingタブを表示

github_001.gif

1.1.2 Futures - Issuesより「Set up templates」を選択

github_002.gif

1.1.3 テンプレートを選択と編集

テンプレートは以下3種類から選択することができます。
1. Bugテンプレート(バグ用テンプレート)
2. Futureテンプレート(機能リクエストテンプレート)
3. カスタムテンプレート(空のテンプレート）

追加したテンプレートは画面上でカスタマイズすることも可能です。
github_003.gif

1.1.4 テンプレートをコミットする

「Propose changes」ボタンより追加したテンプレートをコミットすることができます。
オプションとして、以下2種類を選択することができるので、プロジェクトの方針に合わせて選択しましょう。
1. デフォルトブランチへ直接コミット
2. 別ブランチを作成しプルリクエストを作成する

github_004.gif

コミットされると以下のディレクトリにmdファイルが追加されます

repo/.github/ISSUE_TEMPLATE/

github_005.gif

1.1.5 Issuesからテンプレートを選択します

Issuesから「New issue」をクリックすると追加したテンプレートが表示されます。

github_006.gif

Settingタブが表示されない場合(リポジトリの設定権限がない場合）

直接以下のディレクトリへファイルを作成しPushしても同様の効果を得ることができます。フォーマットは以下の通り。

---
name: タイトル
about: フォーマットについての説明
title: 'タイトルのPrefix'
labels: ラベル
assignees: アサイン
---

# テンプレート本文(Markdownで記載)

Ex.) 質問用のIssueテンプレートを追加したい場合

---
name: Question
about: Ask the developer about the feature
title: '[Question]'
labels: question
assignees: ''
---
# テンプレート本文(Markdownで記載)

repo/.github/ISSUE_TEMPLATE/questions.mdを追加すると、Issuesに追加した内容が追加されていることがわかります。

github_007.gif

Pull Requstテンプレートの作成方法

Pull Requstのテンプレートは直接ファイルレポジトリへファイルを追加する形となります。
ファイルの配置先は以下の通りとなります。

repo/.github/PULL_REQUEST_TEMPLATE.md (デフォルトのテンプレートファイル)
repo/.github/PULL_REQUEST_TEMPLATE/[任意の名前].md

ファイルの追加方法( デフォルトテンプレートの場合 )

テンプレートの追加
github_008.gif

プルリクエストへの反映

github_009.gif

本設定はGitHub上の画面から実施しましたが、ローカルで編集してPushする方法でもOKです。

任意テンプレートの追加方法と利用方法

利用用途
本機能を利用する場合は用途・運用を事前に検討ください。

  • 機能追加、バグでテンプレートを分けたい
  • masterブランチやstagingブランチへのマージでテンプレートを分けたい

設定方法

プロジェクトルールを運用を検討する必要があります。以下はmasterブランチマージする時のPull Requestは別のテンプレートを利用する。

.githubディレクトリにPULL_REQUEST_TEMPLATEを作成し、任意の名前のmdファイルを作成します。

github_011.gif

Pull Request時のパラメータに&template=[テンプレートファイル名]を入れることで適用されます。

github_011.gif

テンプレートコピペ用

先程作ったテンプレートの通りとなります。プロジェクトに合わせてカスタマイズしてご利用ください。

**対処概要**

 ～ 対処内容を簡潔に明記する ～

**区分**
  - [ ] 機能追加
  - [ ] バグ対応
  - [ ] リファクタリング

**対処内容**

 ～ 対処内容を明記する ～

**関連チケット**

 ～ 関連するissue / pull request を明記する ～

**関連資料**

 ～ 設計書のパス(URL）を明記する

**チェックリスト**

  - [ ] タイトルは簡潔か
  - [ ] コーディングガイドラインに遵守しているか
  - [ ] フォーマッタは実行しているか
  - [ ] 静的解析にて潜在バグを指摘されていないか
  - [ ] 単体試験はパスしているか
  - [ ] 疎通確認は実施しているか

**特記事項**


**証跡**

尚、上記で配置する方法の他にPull Requestテンプレート( PULL_REQUEST_TEMPLATE.md )は以下ディレクトリへの配置も許容しております。Pull Requestのテンプレートは一つでOKという場合は以下に配置しましょう。

場所 ファイル名
リポジトリ直下 repo/PULL_REQUEST_TEMPLATE.md
docs/配下 repo/docs/PULL_REQUEST_TEMPLATE.md

2. コードオーナーの設定と自動マージ

本章ではブランチへのマージ事故を回避すると共に、開発に待ち時間を作らないために用意されているGitHubの機能について紹介致します。

【機能内容】

  • デフォルトブランチの変更
  • ブランチへの直接のPush禁止
  • コードオーナー設定
  • 自動的にマージする機能（現在ベータ版）

【メリット】

  • マージ事故の防止
  • レビューの徹底。コード品質の保証
  • 待ち時間の軽減

2.1. デフォルトブランチの変更

repository新規作成時、defaultブランチは masterとなります。(※)
masterブランチへ誤って操作をされるのを防止するため、developブランチをデフォルトブランチにします。

※2020年10月にmasterをmainブランチにするという発表 がありましたが本記事ではmasterという名称で記載します。

Settings -> Branches -> Default branch

github_012.gif

2.2. ブランチへの直接Push禁止

リリース後ソースコードやE2E試験環境のソースコードが入っているブランチへ直接Pushされると、管理者の知らないところでコード改変が行われてしまい、品質を担保することが難しくなります。本例ではmasterブランチに直接Pushすることを禁止とする設定を行います( プロジェクトによって stagingやdevelopブランチへのpushも制限も検討しましょう。)

2.2.1 直接Push禁止設定

ここではmasterブランチを対象に最小限の設定のみかけます。プロジェクトに応じて設定項目を見直ししましょう。

Settings -> Branches -> Branch protection rules -> Add rule

設定項目 設定内容
Branch name pattern 制限をかけたいブランチ名を指定します(正規表現利用可)
Protect matching branches Pull Requestを強制する( これで直接Pushされることはなくなります)
Include administrators 管理者にも適用する

github_013.gif

2.2.1. 直接Push禁止設定

Rejectの確認

image.png

Reviewを必須となっていることの確認

image.png

image.png

2.3. コードオーナーの設定

先程の設定では誰かが承認するとMerge可能となってしまいます。そのため必須レビューアの設定を行います

2.3.1. コードオーナーの設定を有効にする

  1. Settings -> Branches -> Branch protection rule -> 対象ルールを選択
  2. Protect matching branches に 「Require review from Code Owners」にチェックを入れる

github_014.gif

2.3.2. CODEOWNERSファイルを作成する

リポジトリ直下にCODEOWNERSファイルを作成する

image.png

レビューアを細かく分ける場合

monorepo運用を行っている場合やプログラミング言語によってレビューアを変更したいというケースがあるかと思います。

設定例 対象内容
* 全ファイル対象
*.js 拡張子による制限
/dir ROOT配下にあるdirディレクトリにある全てのファイル
dir/ dirディレクトリ名配下にある全てのファイル
dir/* dirディレクトリ名配下の第一階層のファイル

詳細は公式ドキュメントをご連絡ください。
https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners

コードオーナーのレビューが必須であることの確認

鍵穴マークが表示されていること
github_015.gif

「Code owner review required」と表示されていること
image.png

2.3. 自動マージの設定(ベータ版)

必須レビューアがApproveしたら即座にMergeする設定をいれ、マージ漏れや待ち時間を減らします。

2.3.1. 自動マージの有効化

Settings -> Merge button -> Allow auto-merge へチェックをつける

github_016.gif

2.3.2. プロテクトされたブランチへのPull Requestを出す

Enable auto-mergeと表示されていること。auto-merge有効後、必須レビューアによるレビューにてApproveされたら自動マージされます

github_017.gif

3. Draft pull Request機能

作業中のPull Requestの作成します。

メリット

  • 進捗状況の見える化
  • 有識者によるウォークスルーレビューによる手戻り工数の低減
  • Merge事故防止( Draft pull requestではMerge不可 )

3.1. 「Create pull request」ボタンの右にある「▼」より「Create draft pull request」へ変更し、ボタンを押下する

github_018.gif

3.2. 「Ready for review」で正式のPull Requestへ昇格させる

image.png

4. コードハイライト機能

Gitのテキストファイルを行単位でハイライトします。

メリット

コミュニケーションの円滑化( ファイル名、クラス名、関数名、行番号を伝える工数を削減 )

4.1. 構文

[1行] 
https://github.com/[owner]/[repo]/blob/[branch]/**filepath**/#L行番号

[複数] 
https://github.com/[owner]/[repo]/blob/[branch]/**filepath**/#L行番号-#L行番号

例）1行をハイライト
https://github.com/yukiusa/slick3-sample/blob/master/src/main/scala/com/yukiusalab/sample/slick3/Main.scala#L30
image.png

例）複数をハイライト
https://github.com/yukiusa/slick3-sample/blob/master/src/main/scala/com/yukiusalab/sample/slick3/Main.scala#L30-#L34
image.png

5. Diff機能(ブランチ、タグ、コミット)

ブランチ間やTag間、またはコミット間の差分を表示します。

メリット

  • コミュニケーションの円滑化と工数削減

5.1. 構文

[ブランチ間で比較する]
https://github.com/[owner]/[repo]/compare/[branch]...[branch]

[Tag間で比較する] 
https://github.com/[owner]/[repo]/compare/[tag]...[tag]

[Commit間で比較する] 
https://github.com/[owner]/[repo]/compare/[commit hash]...[commit hash]

「ブランチとタグ」「タグとコミット」などの組み合わせも可能です

例)タグ間での可視化
Spring Frameworkのv5.3.1とv5.3.2を比較
https://github.com/spring-projects/spring-framework/compare/v5.3.1...v5.3.2

image.png

6. GitHub Grep機能(高度検索機能)

GitHubの対象リポジトリのソースコードを検索したい時、わざわざcloneしたり、zipでダウンロードする必要はございません。
対象リポジトリ内で完結してソースコードを検索することが出来ます。

メリット

  • 検索の手間軽減
  • コミュニケーションの円滑化(URLだけで連携できるのは嬉しい)

6.1. 検索ページを開く

https://github.com/search/advanced

入力項目

特定のリポジトリ内を検索する場合以下を設定すること

設定項目 対象内容
In these repositories owners/repository

例）spring frameworkからRestTemplateという単語を検索する

image.png

image.png

検索結果

該当のリポジトリの情報が検索されます。動作を見たい方は以下のURLで実際に結果をご確認ください。
https://github.com/search?l=&q=RestTemplate+repo%3Aspring-projects%2Fspring-framework+language%3AJava&type=code
image.png

今回は最小限の設定のみ記載しましたがAdvanced searchには様々条件を指定できますので色々と試してみましょう。

6.2. URLにて直接検索を行う

毎回advanced searchページを開くのは大変なのでURLを直接変更して検索を行います。

構文

&q=[検索ワード]

image.png

上記を直接編集することで、好きなワードで検索が行えます。

7. ブランチタイムライン表示機能

自身が作業しているブランチがどのブランチから派生したのか？またはいつマージされたのか？グラフィカルに表示する。

メリット

  • ブランチ状況把握にかかる工数削減

リポジトリのコミットはマージ状況の可視化する

Insights -> Network
github_019.gif

番外編：ダークモード

ダークモードラブ！という方GitHubにもちゃんとダークモードが用意されました！

ダークモードを有効化する(ベータ版)

github_900.gif

さいごに

いかがでしたでしょうか？
普段から利用されている機能もあれば、知らなかった機能もあるのではないでしょうか？

各プロジェクトによってバージョン管理の運用は様々かと思っております。
運用するための手順書を作成することも大切ですが、システム側で制限を付与することによって未然の事故防止や手順の簡略化ができるのではないかと思っております。使えそうな機能がありましたら、今後の業務にお役立てください。

最後まで読んでいただきましてありがとうございました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2021-01-08T13:02:13+09:00

明日から使えるGithub便利機能 7選 (2021年版)

github-logo_icon-icons.com_73546.png

はじめに

現在、多くの開発のバージョン管理ツールとしてGitが利用されるようになりました。
その中でも特に多くの開発で利用されているサービスと言えばGithub 。
この記事ではチーム開発を加速させるオススメ機能を7つ厳選してご紹介致します。

対象読者

  • Githubを用いてチームで開発・運営を行っている方
  • Githubをうまく活用してコミュニケーションを円滑にしたいと考えている方

お品書き

  1. Issues/PullRequestテンプレート機能
  2. コードオーナーの設定と自動マージ
  3. Draft pull Request機能
  4. コードハイライト機能
  5. Diff機能(ブランチ、タグ、コミット)
  6. Github Grep機能(高度検索機能)
  7. ブランチタイムライン表示機能

1. Issues/PullRequestテンプレート機能

IssuesやPullRequest作成時に文面をテンプレート文章を自動的に挿入します。

【メリット】

  • 記載内容の統一し、コミュニケーションロス低減
  • 過去のIssueのコピペ・編集の手間の削減

【デメリット】

記載粒度が細かいと形骸化する。

Issuesテンプレートの作成方法

Settingタブから実施要領は以下の通りです。
（※リポジトリ設定権限がない場合は後述の「Settingタブが表示されない場合(リポジトリの設定権限がない場合）」を参照ください）

1.1.1 GithubのSettingタブを表示

github_001.gif

1.1.2 Futures - Issuesより「Set up templates」を選択

github_002.gif

1.1.3 テンプレートを選択と編集

テンプレートは以下3種類から選択することができます。
1. Bugテンプレート(バグ用テンプレート)
2. Futureテンプレート(機能リクエストテンプレート)
3. カスタムテンプレート(空のテンプレート）

追加したテンプレートは画面上でカスタマイズすることも可能です。
github_003.gif

1.1.4 テンプレートをコミットする

「Propose changes」ボタンより追加したテンプレートをコミットすることができます。
オプションとして、以下2種類を選択することができるので、プロジェクトの方針に合わせて選択しましょう。
1. デフォルトブランチへ直接コミット
2. 別ブランチを作成しプルリクエストを作成する

github_004.gif

コミットされると以下のディレクトリにmdファイルが追加されます

repo/.github/ISSUE_TEMPLATE/

github_005.gif

1.1.5 Issuesからテンプレートを選択します

Issuesから「New issue」をクリックすると追加したテンプレートが表示されます。

github_006.gif

Settingタブが表示されない場合(リポジトリの設定権限がない場合）

直接以下のディレクトリへファイルを作成しPushしても同様の効果を得ることができます。フォーマットは以下の通り。

---
name: タイトル
about: フォーマットについての説明
title: 'タイトルのPrefix'
labels: ラベル
assignees: アサイン
---

# テンプレート本文(Markdownで記載)

Ex.) 質問用のIssueテンプレートを追加したい場合

---
name: Question
about: Ask the developer about the feature
title: '[Question]'
labels: question
assignees: ''
---
# テンプレート本文(Markdownで記載)

repo/.github/ISSUE_TEMPLATE/questions.mdを追加すると、Issuesに追加した内容が追加されていることがわかります。

github_007.gif

Pull Requstテンプレートの作成方法

Pull Requstのテンプレートは直接ファイルレポジトリへファイルを追加する形となります。
ファイルの配置先は以下の通りとなります。

repo/.github/PULL_REQUEST_TEMPLATE.md (デフォルトのテンプレートファイル)
repo/.github/PULL_REQUEST_TEMPLATE/[任意の名前].md

ファイルの追加方法( デフォルトテンプレートの場合 )

テンプレートの追加
github_008.gif

プルリクエストへの反映

github_009.gif

本設定はGithub上の画面から実施しましたが、ローカルで編集してPushする方法でもOKです。

任意テンプレートの追加方法と利用方法

利用用途
本機能を利用する場合は用途・運用を事前に検討ください。

  • 機能追加、バグでテンプレートを分けたい
  • masterブランチやstagingブランチへのマージでテンプレートを分けたい

設定方法

プロジェクトルールを運用を検討する必要があります。以下はmasterブランチマージする時のPull Requestは別のテンプレートを利用する。

.githubディレクトリにPULL_REQUEST_TEMPLATEを作成し、任意の名前のmdファイルを作成します。

github_011.gif

Pull Request時のパラメータに&template=[テンプレートファイル名]を入れることで適用されます。

github_011.gif

テンプレートコピペ用

先程作ったテンプレートの通りとなります。プロジェクトに合わせてカスタマイズしてご利用ください。

**対処概要**

 ～ 対処内容を簡潔に明記する ～

**区分**
  - [ ] 機能追加
  - [ ] バグ対応
  - [ ] リファクタリング

**対処内容**

 ～ 対処内容を明記する ～

**関連チケット**

 ～ 関連するissue / pull request を明記する ～

**関連資料**

 ～ 設計書のパス(URL）を明記する

**チェックリスト**

  - [ ] タイトルは簡潔か
  - [ ] コーディングガイドラインに遵守しているか
  - [ ] フォーマッタは実行しているか
  - [ ] 静的解析にて潜在バグを指摘されていないか
  - [ ] 単体試験はパスしているか
  - [ ] 疎通確認は実施しているか

**特記事項**


**証跡**

尚、上記で配置する方法の他にPull Requestテンプレート( PULL_REQUEST_TEMPLATE.md )は以下ディレクトリへの配置も許容しております。Pull Requestのテンプレートは一つでOKという場合は以下に配置しましょう。

場所 ファイル名
リポジトリ直下 repo/PULL_REQUEST_TEMPLATE.md
docs/配下 repo/docs/PULL_REQUEST_TEMPLATE.md

2. コードオーナーの設定と自動マージ

本章ではブランチへのマージ事故を回避すると共に、開発に待ち時間を作らないために用意されているGithubの機能について紹介致します。

【機能内容】

  • デフォルトブランチの変更
  • ブランチへの直接のPush禁止
  • コードオーナー設定
  • 自動的にマージする機能（現在ベータ版）

【メリット】

  • マージ事故の防止
  • レビューの徹底。コード品質の保証
  • 待ち時間の軽減

2.1. デフォルトブランチの変更

repository新規作成時、defaultブランチは masterとなります。(※)
masterブランチへ誤って操作をされるのを防止するため、developブランチをデフォルトブランチにします。

※2020年10月にmasterをmainブランチにするという発表 がありましたが本記事ではmasterという名称で記載します。

Settings -> Branches -> Default branch

github_012.gif

2.2. ブランチへの直接Push禁止

リリース後ソースコードやE2E試験環境のソースコードが入っているブランチへ直接Pushされると、管理者の知らないところでコード改変が行われてしまい、品質を担保することが難しくなります。本例ではmasterブランチに直接Pushすることを禁止とする設定を行います( プロジェクトによって stagingやdevelopブランチへのpushも制限も検討しましょう。)

2.2.1 直接Push禁止設定

ここではmasterブランチを対象に最小限の設定のみかけます。プロジェクトに応じて設定項目を見直ししましょう。

Settings -> Branches -> Branch protection rules -> Add rule

設定項目 設定内容
Branch name pattern 制限をかけたいブランチ名を指定します(正規表現利用可)
Protect matching branches Pull Requestを強制する( これで直接Pushされることはなくなります)
Include administrators 管理者にも適用する

github_013.gif

2.2.1. 直接Push禁止設定

Rejectの確認

image.png

Reviewを必須となっていることの確認

image.png

image.png

2.3. コードオーナーの設定

先程の設定では誰かが承認するとMerge可能となってしまいます。そのため必須レビューアの設定を行います

2.3.1. コードオーナーの設定を有効にする

  1. Settings -> Branches -> Branch protection rule -> 対象ルールを選択
  2. Protect matching branches に 「Require review from Code Owners」にチェックを入れる

github_014.gif

2.3.2. CODEOWNERSファイルを作成する

リポジトリ直下にCODEOWNERSファイルを作成する

image.png

レビューアを細かく分ける場合

monorepo運用を行っている場合やプログラミング言語によってレビューアを変更したいというケースがあるかと思います。

設定例 対象内容
* 全ファイル対象
*.js 拡張子による制限
/dir ROOT配下にあるdirディレクトリにある全てのファイル
dir/ dirディレクトリ名配下にある全てのファイル
dir/* dirディレクトリ名配下の第一階層のファイル

詳細は公式ドキュメントをご連絡ください。
https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners

コードオーナーのレビューが必須であることの確認

鍵穴マークが表示されていること
github_015.gif

「Code owner review required」と表示されていること
image.png

2.3. 自動マージの設定(ベータ版)

必須レビューアがApproveしたら即座にMergeする設定をいれ、マージ漏れや待ち時間を減らします。

2.3.1. 自動マージの有効化

Settings -> Merge button -> Allow auto-merge へチェックをつける

github_016.gif

2.3.2. プロテクトされたブランチへのPull Requestを出す

Enable auto-mergeと表示されていること。auto-merge有効後、必須レビューアによるレビューにてApproveされたら自動マージされます

github_017.gif

3. Draft pull Request機能

作業中のPull Requestの作成します。

メリット

  • 進捗状況の見える化
  • 有識者によるウォークスルーレビューによる手戻り工数の低減
  • Merge事故防止( Draft pull requestではMerge不可 )

3.1. 「Create pull request」ボタンの右にある「▼」より「Create draft pull request」へ変更し、ボタンを押下する

github_018.gif

3.2. 「Ready for review」で正式のPull Requestへ昇格させる

image.png

4. コードハイライト機能

Gitのテキストファイルを行単位でハイライトします。

メリット

コミュニケーションの円滑化( ファイル名、クラス名、関数名、行番号を伝える工数を削減 )

4.1. 構文

[1行] 
https://github.com/[owner]/[repo]/blob/[branch]/**filepath**/#L行番号

[複数] 
https://github.com/[owner]/[repo]/blob/[branch]/**filepath**/#L行番号-#L行番号

例）1行をハイライト
https://github.com/yukiusa/slick3-sample/blob/master/src/main/scala/com/yukiusalab/sample/slick3/Main.scala#L30
image.png

例）複数をハイライト
https://github.com/yukiusa/slick3-sample/blob/master/src/main/scala/com/yukiusalab/sample/slick3/Main.scala#L30-#L34
image.png

5. Diff機能(ブランチ、タグ、コミット)

ブランチ間やTag間、またはコミット間の差分を表示します。

メリット

  • コミュニケーションの円滑化と工数削減

5.1. 構文

[ブランチ間で比較する]
https://github.com/[owner]/[repo]/compare/[branch]...[branch]

[Tag間で比較する] 
https://github.com/[owner]/[repo]/compare/[tag]...[tag]

[Commit間で比較する] 
https://github.com/[owner]/[repo]/compare/[commit hash]...[commit hash]

「ブランチとタグ」「タグとコミット」などの組み合わせも可能です

例)タグ間での可視化
Spring Frameworkのv5.3.1とv5.3.2を比較
https://github.com/spring-projects/spring-framework/compare/v5.3.1...v5.3.2

image.png

6. Github Grep機能(高度検索機能)

Githubの対象リポジトリのソースコードを検索したい時、わざわざcloneしたり、zipでダウンロードする必要はございません。
対象リポジトリ内で完結してソースコードを検索することが出来ます。

メリット

  • 検索の手間軽減
  • コミュニケーションの円滑化(URLだけで連携できるのは嬉しい)

6.1. 検索ページを開く

https://github.com/search/advanced

入力項目

特定のリポジトリ内を検索する場合以下を設定すること

設定項目 対象内容
In these repositories owners/repository

例）spring frameworkからRestTemplateという単語を検索する

image.png

image.png

検索結果

該当のリポジトリの情報が検索されます。動作を見たい方は以下のURLで実際に結果をご確認ください。
https://github.com/search?l=&q=RestTemplate+repo%3Aspring-projects%2Fspring-framework+language%3AJava&type=code
image.png

今回は最小限の設定のみ記載しましたがAdvanced searchには様々条件を指定できますので色々と試してみましょう。

6.2. URLにて直接検索を行う

毎回advanced searchページを開くのは大変なのでURLを直接変更して検索を行います。

構文

&q=[検索ワード]

image.png

上記を直接編集することで、好きなワードで検索が行えます。

7. ブランチタイムライン表示機能

自身が作業しているブランチがどのブランチから派生したのか？またはいつマージされたのか？グラフィカルに表示する。

メリット

  • ブランチ状況把握にかかる工数削減

リポジトリのコミットはマージ状況の可視化する

Insights -> Network
github_019.gif

番外編：ダークモード

ダークモードラブ！という方Githubにもちゃんとダークモードが用意されました！

ダークモードを有効化する(ベータ版)

github_900.gif

さいごに

いかがでしたでしょうか？
普段から利用されている機能もあれば、知らなかった機能もあるのではないでしょうか？

各プロジェクトによってバージョン管理の運用は様々かと思っております。
運用するための手順書を作成することも大切ですが、システム側で制限を付与することによって未然の事故防止や手順の簡略化ができるのではないかと思っております。使えそうな機能がありましたら、今後の業務にお役立てください。

最後まで読んでいただきましてありがとうございました。

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

日付別

タグ一覧