- 投稿日：2020-08-14T15:25:32+09:00
GiteaをUbuntuにインストール
備忘録です。
GiteaをUbuntuにインストールしました。Gitは基本コマンドラインで操作しますが、GitHubのように、GUIから一覧管理できると便利です。Giteaがうってつけです。
Gitea – Git with a coup of tea
https://gitea.io/en-us/インストール
以下の手順に従います。
Installation from binary
https://docs.gitea.io/en-us/install-from-binary/とりあえず、Gitをインストール
# apt-get install git以降が、Giteaのインストール
$ wget -O gitea https://dl.gitea.io/gitea/1.12.2/gitea-1.12.2-linux-amd64 $ chmod +x gitea # cp gitea /usr/local/bin/gitea # adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password --home /home/git git # mkdir -p /var/lib/gitea/{custom,data,log} # chown -R git:git /var/lib/gitea/ # chmod -R 750 /var/lib/gitea/ # mkdir /etc/gitea # chown root:git /etc/gitea # chmod 770 /etc/gitea自動起動のため、systemdファイルを作成します。
vi /etc/systemd/system/gitea.service/etc/systemd/system/gitea.service[Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target ### # Don't forget to add the database service requirements ### # #Requires=mysql.service #Requires=mariadb.service #Requires=postgresql.service #Requires=memcached.service #Requires=redis.service # ### # If using socket activation for main http/s ### # #After=gitea.main.socket #Requires=gitea.main.socket # ### # (You can also provide gitea an http fallback and/or ssh socket too) # # An example of /etc/systemd/system/gitea.main.socket ### ## ## [Unit] ## Description=Gitea Web Socket ## PartOf=gitea.service ## ## [Socket] ## Service=gitea.service ## ListenStream=<some_port> ## NoDelay=true ## ## [Install] ## WantedBy=sockets.target ## ### [Service] # Modify these two values and uncomment them if you have # repos with lots of files and get an HTTP error 500 because # of that ### #LimitMEMLOCK=infinity #LimitNOFILE=65535 RestartSec=2s Type=simple User=git Group=git WorkingDirectory=/var/lib/gitea/ # If using Unix socket: tells systemd to create the /run/gitea folder, which will contain the gitea.sock file # (manually creating /run/gitea doesn't work, because it would not persist across reboots) #RuntimeDirectory=gitea ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini Restart=always Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea # If you want to bind Gitea to a port below 1024, uncomment # the two values below, or use socket activation to pass Gitea its ports as above ### #CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE ### [Install] WantedBy=multi-user.targetとりあえず、Giteaを起動させます。
# systemctl start gitea/etc/giteaにapp.iniが生成されます。
私の場合、デフォルトのポート番号3000が他とかぶっていたため、変更しました。
vi /etc/gitea/app.ini・・・ [server] HTTP_PORT = 3001 ・・・再起動
# systemctl restart giteaMySQLにデータベース作成
Gitea経由で設定した情報の管理のために、MySQLを使います。
DB名：giteadb
照合順序：utf8mb4_unicode_ciブラウザからログイン
以下のURLをブラウザから開きます。
http://【インストールしたPCのホスト名】:3000
右上の登録からユーザを追加
※一番最初に登録したユーザは管理者として登録される。以降は一般ユーザとして登録される。
最初に接続するDBの設定画面が表示されるので、作成したデータベースの情報とデータベースのホスト名：ポート番号、ログインユーザ名・パスワードを指定する。（メール設定欄がありますが、使わないのであれば、そこに何も入力しないこと。）
うまくいきましたでしょうか？
あとは、GitHubと同じ要領で操作できます。
後処理
(参考)
https://docs.gitea.io/en-us/config-cheat-sheet/〇セルフユーザ登録の無効化
誰でも右上の登録から、ユーザ登録してログインできてしまっています。以下で無効化します。
vi /etc/gitea/app.ini/etc/gitea/app.iniDISABLE_REGISTRATION = false ENABLE_OPENID_SIGNUP = true → DISABLE_REGISTRATION = true ENABLE_OPENID_SIGNUP = false〇パスワード制限の緩和
結構パスワードの制限がきついので、緩和したい方向け。
vi /etc/gitea/app.ini/etc/gitea/app.ini[security] PASSWORD_COMPLEXITY = off〇app.iniの保護
DBのセットアップが完了して、app.iniが更新されたので、もうWebからの変更は不要です。以下で、アクセス権を制限します。
# chmod 750 /etc/gitea # chmod 640 /etc/gitea/app.ini○その他
PC再起動後も自動起動させます。
# systemctl enable giteaGiteaを再起動します。
# systemctl restart giteaリポジトリをNFSに設定
リポジトリをRAID化された別のNASにマウントします。プロトコルはNFSにしました。（この作業は必須ではありません）
# apt-get install nfs-commonidmapd.confにこのPCのホスト名を記載します。
vi /etc/idmapd.confDomain = 【このPCのホスト名】次回PC起動後も有効にします。以下を追記します。
vi /etc/fstab/etc/fstab【NFSサーバのホスト名】:/git_data /home/git/gitea-repositories nfs defalts 0 0以下のようにマウントして、データを丸ごとコピー
# cd /home/git # mv gitea-repositories gitea-repositories.org # mkdir gitea-repositories # mount /home/git/gitea-repositories # cp -Ra /home/git/gitea-repositories.org/* /home/git/git-repositories/ # chown git:git /home/git/gitea-repositories以上
- 投稿日：2020-08-14T11:38:18+09:00
自分のgit alias晒す(20/08/14)
記事を書いた目的
- 毎回行うaliasの設定手順の備忘録
- .fileで管理できるみたいだけど設定できなかったので毎回コピペしている（反省）
早速.gitconfigをいじってみる
下記コマンドを実施する
git config -e解決策1 - set pasteでペースト前入力し、ペーストするときのズレを防ぐ。
:set paste # こんな表示になる -- INSERT (paste) --モードを元に戻したい時はこれ。
:set nopaste:set paste!を使えば、履歴で再度
:set paste!を打てば 元のモードに戻れる。簡単！alias
[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true [color] status = auto diff = auto branch = auto interactive = auto grep = auto [alias] f = fetch -p c = commit -m a = add m = merge b = branch l = log st = status sh = show mg = merge # branch関連 sw = switch br = branch ba = branch -a # originも含めた全てのbranchを表示 bm = branch --merged # merge済みのbranchを表示 bn = branch --no-merged # mergeしてないbranchを表示 co = checkout cob = checkout -b # log関連 wc = whatchanged # logに変更されたファイルも一緒に出す ls = log --stat # logに変更されたファイルも一緒に出す lp = log -p # diffも一緒に出す la = log --pretty=\"format:%ad %h (%an): %s\" --date=short # ざっくりログ出す lr = log origin # originのlog lm = log --merges lc = log --no-merges oneline = log --pretty=oneline ranking = shortlog -s -n --no-merges # logをtree表示 lg = log --graph --date=short --pretty=format:'%Cgreen%h %cd %Cblue%cn %Creset%s' log-all = log --graph --all --color --pretty='%x09%h %cn%x09%s %Cred%d%Creset' # diff関連 dn = diff --name-only # name-only dm = diff master # masterとのdiff dd = diff develop # developとのdiff dw = diff --color-words # 単語単位でいろつけてdiff dc = diff --cached # addされているものとのdiff ds = diff --staged # 同上(1.6.1移行) d1 = diff HEAD~ # HEADから1つ前とdiff d2 = diff HEAD~~ # HEADから2つ前とdiff d3 = diff HEAD~~~ # HEADから3つ前とdiff d4 = diff HEAD~~~~ # HEADから4つ前とdiff d5 = diff HEAD~~~~~ # HEADから5つ前とdiff d10 = diff HEAD~~~~~~~~~~ # HEADから10前とdiff dfm = diff --diff-filter=M dfm1 = diff HEAD~ --diff-filter=M dfa = diff --diff-filter=A dfa1 = diff HEAD~ --diff-filter=A dfc = diff --diff-filter=C dfc1 = diff HEAD~ --diff-filter=C dfd = diff --diff-filter=D dfd1 = diff HEAD~ --diff-filter=D dfr = diff --diff-filter=R dfr1 = diff HEAD~ --diff-filter=R # mergeの際にconflictが起きたファイルを編集 edit-unmerged = "!f() { git ls-files --unmerged | cut -f2 | sort -u ; }; vim `f`" # mergeの際にconflictが起きたファイルをadd add-unmerged = "!f() { git ls-files --unmerged | cut -f2 | sort -u ; }; git add `f`" # grep関連 gr = grep gn = grep -n # gc gcn = gc --prune=now設定したaliasを確認したいときの設定
.gitconfiggit config --global alias.al "config --get-regexp alias.*" #エイリアスの一覧を確認する。又は vi ~/.gitconfig で確認する。$ source ~/.bashrc で先ほどの変更を有効にする
読んでいただきありがとうございます！（コメントお待ちしております。）
- 投稿日：2020-08-14T11:30:15+09:00
【Git】自分まとめ
エディタだけでGitを使えるよう勉強中です
アウトプットをメモします1. よく使うコード
General
目的 コード ステージングに移動 git add ファイル コミットする git commit -m "コミット内容 " 履歴をみる git log 履歴をみる（1行で） git log --oneline 履歴をみる（具体的に） git log -p 履歴をみる（変更数） git log --stat 現在の状態をみる git status 差分比較（ステージング前） git diff 差分比較（ステージング後） git diff caches Branch
目的 コード 確認する git branch 作成する git branch ファイル 移動する git checkout ファイル マージする git marge ファイル 削除する git branch -d ファイル 作成したらすぐに移動 git checkout -b ファイル Tag
目的 コード タグを作成 git tag タグ名 コミットID タグを確認 git tag コミットの内容を確認 git show タグ名 タグを削除 git tag -d タグ名 Setting / Help / Back
目的 コード 色分け git color.ui true ヘルプ git confit --help 戻る q
勉強のきっかけ
お世話になっているドットインストールさんです
分かりやすくて、とても楽しく勉強させて頂いています
本当にありがとうございます
https://dotinstall.com/
- 投稿日：2020-08-14T02:20:53+09:00
Git入門 - 番外編
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の番外編です。
今回は GitHubとは何なのか ということと GitとGitHubの連携 について説明します。
- 1回: 概要
- 2回: 導入手順とGitコマンド
- 3回: データの保存
- 4回: データの活用と便利な操作
- 5回: ブランチ
- 番外編: GitHub
2. GitHubとは？
GitHub（ギットハブ） は2008年4月10日に正式スタートしたWebサービスです。Gitのリリースが2005年12月21日なので、およそ2年半後のことですね。開発元はGitHub社で（開発自体は法人化する前から始まっていたっぽい）、同社は2018年10月26日をもって75億ドルでMicrosoftに買収されています。
サービスの特徴としては――
- ローカルや社内で管理していたソースコードをクラウド上に保存できる
- ソースコードの公開と非公開を選択できる
- SNS的な側面があり、ソースコードやプロジェクトについて議論を交わせる
――などが挙げられます。
現在のところ、およそ1億個のリポジトリがGitHubで管理されているとされ、約4,000万の開発者と、約210万の組織で利用されるサービスにまで成長しました。
ちなみに、GitHubの開発には、Rubyのフレームワークの1つであるRuby on Railsや、スウェーデンのIT企業Ericsson社が開発したプログラミング言語Erlangが用いられているようです。
2-1. 普及と好評の理由
GitHubがこれほどまでに普及した理由の1つに、OSSと相性が良かったという指摘をいくつか確認しました。
ざっと調べてみたかぎりですと、2000年くらいから企業のシステムにOSSが利用されるようになり、2010年にもなるとOSSの利用が一般化、そして、2020年現在では無くてはならない存在にまでなったOSSは、そのプラットフォームとしてGitHubを利用することが多く、それに伴いGitHubの規模も大きくなっていったと考えられます。
そして、そもそもOSS勢がGitHubを利用するようになったのは、OSSの開発を助けるいくつかの機能が用意されていたことにあるでしょう。誰かがアップロードしたリポジトリを、自身の環境にコピーして好きに弄ることができる フォーク機能 。OSS開発責任者に機能の追加・改修・バグ修正等を提案することができる プルリクエスト機能 。GitHub上で意見交換や議論ができる イシュー機能 などです。
3. GitHubにリポジトリを用意する
GitHubにリポジトリを用意するにはGitHubのアカウントが必要です。アカウントは無料・有料、どちらもありますので、とりあえず無料のプランでアカウントを取ってしまいましょう。
アカウントが取得できましたら、GitHubの指示に従ってリポジトリを作成してください。リポジトリは Public と Private の2種類あります。前者は公開用、後者は自分および特定のメンバーにのみ公開されるリポジトリです。どちらを選んでもよいと思いますが、とりあえず最初はPrivateにして色々弄ってみるのが無難だと思います。
4. データを上げる
GitHub上に作成したリポジトリにバージョン情報をアップロードするには pushコマンド を使用します。
まず、第1引数にデータのアップロード先となるGitHubリポジトリのURLを指定します。URLといっても色々だと思いますが、基本的には「https://github.com/GitHubアカウント名/リポジトリ名」という構成になっているURLを指定すればOKです。具体的には、例えば、私が公開しているリポジトリですと「https://github.com/AGadget/rps-like」です。
そして、第2引数にアップロードしたいブランチを指定します。GitHubに上げるバージョン情報はブランチ単位となります。
文法PS C:\Users\AGadget> git push [GitHub上に作成したリポジトリのURL] [アップロードしたいブランチ]例文PS C:\Users\AGadget> git push https://github.com/AGadget/rps-like master初めて実行するときはウィンドウが表示され、GitHubのID・パスワードの入力が求められますので入力してください。1度通った場合は入力を求められなくなります。
5. エイリアス
アップロード先となるURLに対して、エイリアスを設定することができます。エイリアスを付けることで長いURLを打ち込む必要がなくなる他、後ほどエイリアス一覧を確認することで、そのリポジトリがどのGitHubリポジトリと連携しているか把握する助けになります。
エイリアスの操作には remoteコマンド を使用します。
5-1. 追加
エイリアスを追加するにはremoteコマンドの第1引数に add を指定し、さらにエイリアス名・URLと続けます。
ちなみに、Git界隈では主要なエイリアスには origin という名前を付ける傾向があります。
文法PS C:\Users\AGadget> git remote add [エイリアス] [GitHubのURL]例文PS C:\Users\AGadget> git remote add origin https://github.com/AGadget/rps-like master5-2. 確認
作成したエイリアスを一覧表示したいときはオプション・引数無しにremoteコマンドを実行してください。
PS C:\Users\AGadget> git remoteURLも併せて知りたいときは --verboseオプション も付けてください。
PS C:\Users\AGadget> git remote --verbose5-3. リネーム
エイリアス名を変更するならばremoteコマンドの第1引数に rename と指定し、第2引数に変更したいエイリアス、第3引数に変更後の名前をそれぞれ入力してください。
PS C:\Users\AGadget> git remote rename [古い名前] [新しい名前]5-4. 削除
削除するにはremoteコマンドの第1引数に rm を指定し、削除したいエイリアス名を続けます。
PS C:\Users\AGadget> git remote rm [エイリアス]6. GitHubに上げたデータを確認
pushコマンドでアップロードしたら、割とすぐにGitHubのページに反映されるはずなので確認してみてください。
7. データを取ってくる
GitHubに上げておいてデータを自身のPCのリポジトリに持ってくるには fetchコマンド を使用します。第1引数に対象となるGitHub上のリポジトリを指定するのですが、原則としてURLではなく、エイリアスを使って指定することをオススメします。
理由は後述します。
PS C:\Users\AGadget> git fetch [GitHubのリポジトリ（エイリアスの指定を推奨）] [取ってくるブランチ名]7-1. fetchコマンドの実行結果
fetchコマンドを実行すると、リポジトリにGitHubに上げたブランチがそのまま追加されます。ブランチ名は「エイリアス名/ブランチ名」となります。
例えば「https://github.com/AGadget/rps-like」というGitHub上のリポジトリに、「origin」というエイリアスを付けて、そこに「master」ブランチのデータを上げるとします。後ほど、以下のようにコマンドを実行します。
PS C:\Users\AGadget> git fetch origin masterすると自身のPCのリポジトリ内に「origin/master」という リモートトラッキングブランチ（トラッキングブランチ、リモートブランチとも） が作られます。
7-2. フェッチ後、どうするのか？
fetchコマンド実行後は基本的に、取ってきたブランチと同名のブランチに対して、マージ処理を行います。
PS C:\Users\AGadget> git switch master PS C:\Users\AGadget> git merge origin/masterこうしてGitHubにアップロードされたデータとの差分を、ローカル環境のリポジトリに反映させます。
もちろん、コンフリクトが発生する可能性がありますので注意してください。
7-3. エイリアスではなくURLを指定した場合
fetchコマンド実行時にエイリアスではなくURLを指定した場合、リモートトラッキングブランチは作成されません。
では、どのようにしてGitHubのブランチを参照するのかというと FETCH_HEAD というポインタを参照します。名前から何となく分かるようにHEADのお仲間で、fetchコマンド実行時に生成されるポインタです。
PS C:\Users\AGadget> git merge FETCH_HEAD7-4. pullコマンド
fetchコマンドと似た役割を持つコマンドとして pullコマンド があります。
PS C:\Users\AGadget> git pull [GitHubのリポジトリ（エイリアスの指定を推奨）] [取ってくるブランチ名]pullコマンドを実行すると、まず、fetchコマンドを実行したときのようにGitHub上に保存されたリポジトリを取得し、さらに、mergeコマンドを実行して、ブランチの統合まで行ってくれます。fetchコマンド・mergeコマンドを省略してくれるので便利です。
8. cloneコマンド
cloneコマンド は引数に指定したリポジトリを基に、リポジトリを新規作成するコマンドです。既にGitHubでバージョン管理を行っているプロジェクトに途中参加するときや、GitHubに登録されている有名なプロジェクトの内容を確認するのに便利なコマンドです。
PS C:\Users\AGadget> git clone [リポジトリ]9. 知っておきたい概念と操作
ここまで来た人は以下の概念・操作を知っていてください。
9-1. ローカルとリモート
バージョン情報を保存するリポジトリですが、リポジトリがどこに存在するかで ローカルリポジトリ と リモートリポジトリ とに呼び分けられます。ローカルリポジトリはクライアント側にあるリポジトリ。対して、リモートリポジトリはサーバー側にあるリポジトリです。
9-2. リポジトリは2種類
リポジトリにはワークツリーが有るものと無いものがあります。ワークツリーが有ると ノンベアリポジトリ 、無いと ベアリポジトリ と言ばれます。「ベア（bare）」は「裸の」あるいは「剥き出しの」という意味です。
これまで紹介してきたinitコマンド・cloneコマンドで作成したリポジトリは全てノンベアリポジトリです。対して、GitHubのリポジトリはベアリポジトリとなります。
ベアリポジトリは、ノンベアリポジトリで編集・保存したデータを集積するだけの役割しかありません。機能こそノンベアリポジトリよりも劣りますが、そのぶんリポジトリのサイズが小さくなるというメリットがあります（らしいです）。また、ワークツリーを持たないがために直接編集することができないというのも、見方を変えれば、バージョン情報をセキュアに管理するための制約と考えることができます。
9-3. ベアリポジトリを作成
ところで、ベアリポジトリはGitHub固有のものではありません。自作することが可能であり、GitHubを利用する代わりに社内サーバー上などに配置し、リモートリポジトリとして利用することができます。
ベアリポジトリを作るには、initコマンドを実行するときに --bareオプション を付けて実行してください。カレントディレクトリ直下にベアリポジトリが自動作成されます。
面白い挙動として、ノンベアリポジトリを作成するときは「.git」というディレクトリが作られたのに対して、ベアリポジトリを作るときは「.git」の中身がカレントディレクトリ直下に作られます。これはまさにリポジトリの内容が剥き出し――ベアであるということなのでしょう。
PS C:\Users\AGadget> git init --bare作成したベアリポジトリはGitHub上に作成したリポジトリと同じように使用することができます。pushコマンドでデータを送ったり、fetchコマンドでデータを受信したりです。
ところで、ベアリポジトリを作るときというと、それはGitHub等のクラウド上にソースコードを置きたくないが、プロジェクトのバージョン情報をどこかで集中管理したいときでしょう。そんなときは --sharedオプション を付け、その引数に true を指定してください。これは1つのリポジトリを複数のユーザーで共有する許可を与えるオプションです。
PS C:\Users\AGadget> git init --bare --shared=true引数を省略した場合、自動的にtrueが指定されますので省略してもかまいません。
PS C:\Users\AGadget> git init --bare --shared
- 投稿日：2020-08-14T02:20:27+09:00
Git入門 - 5
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第5回です。
今回は ブランチ について説明します。
2. ブランチとは？
ブランチ はコミットを分岐させることができる機能であり、分岐したコミットの流れの最新のコミットを指し示すポインタでもあります。
3. コミットの流れ
これまでの解説では触れてきませんでしたが、Gitには コミットの流れ とでも表現すべき概念が存在します。
例えば、あるリポジトリに対して、3回コミットを行ってみます。その後、コミット履歴を確認するためのlogコマンドを --graphオプション と組み合わせて実行します。
PS C:\Users\AGadget> git log --graph * commit 814b2e6bf4a13dd1c46a7c6314a616fe2798e872 (HEAD -> master) | Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:03:00 2020 +0900 | | 3回目のコミットです。 | * commit 8dd64f12e3b69ec76430bbdfb99e2b9f8675842a | Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:02:00 2020 +0900 | | 2回目のコミットです。 | * commit bbf4ff0b9ba40cbbf15c6fb8fa4aa6ca0a3f6661 Author: AGadget <AGadget@gmail.com> Date: Sat Aug 1 12:01:00 2020 +0900 1回目のコミットです。--graphオプションについては説明していないので上記実行結果を見るのは初めてだと思います。--graphオプションを付けなかったときに出力される内容に加えて、アスタリスク記号と縦棒記号が出力されています。この第1回コミットから、第3回コミットに向かって伸びるような表現がコミットの流れを表しています。
さらに少しコミットを足してみます。
PS C:\Users\AGadget> git log --graph * commit dd9d3f8ae6d44f6bd8979ef4a95bae144e5fb1c0 (HEAD -> master) | Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:05:00 2020 +0900 | | 5回目のコミットです。 | | * commit a0e701a07cc170b5d04ba5a45d3a04621db01e40 (bugfix) |/ Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:04:00 2020 +0900 | | 4回目のコミットです。 | * commit 61fab30c63cc55dd64dd8677f7c7591e68a6a06b | Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:03:00 2020 +0900 | | 3回目のコミットです。 | * commit e5afb32a598403fc14e4c43537b11bff44521b14 | Author: AGadget <AGadget@gmail.com> | Date: Sat Aug 1 12:02:00 2020 +0900 | | 2回目のコミットです。 | * commit 6beb18ed081c010ca5bad0d305b6c831571f01a9 Author: AGadget <AGadget@gmail.com> Date: Sat Aug 1 12:01:00 2020 +0900 1回目のコミットです。何やら奇妙な内容になりました。まるで、コミットが分岐したような、複数のコミットの流れができたような出力結果です。
また、コミットの流れの、それぞれの先頭にあたる第4回コミットと第5回コミットに、それぞれ master と bugfix という記号が付いているのも確認できます。masterは以前からありましたがbugfixとは何なのでしょうか。そして、これら記号は何を意味しているのでしょうか。
4. ブランチの正体
ブランチの正体は、このmasterとbugfixのような 任意の名前を付けることができるポインタ です。先ほどの例で見せたbugfixというポインタは裏で作成していおいた自作のブランチです。ちなみにbugfixという名前に意味はありません。何となくbugfixという名前にしました。
masterブランチは初めてコミットすると自動的に作成されるブランチです。正直、初めてコミットする前にブランチの作成を要求する仕様にしたが良いと思うのですが、Gitでは初コミット時にmasterブランチが自動作成される仕様になっているので仕方ありません。
4-1. タグとの違い
このように説明すると前回紹介した タグ と似ているようと思われるかもしれません。
実際、ブランチもタグも、その実態はただのポインタであり、特定のコミットを指し示すだけのものです。
ただ、ブランチはHEADのように（基本的に）コミットするたびに最新のコミットに移動するという性質があります。これは、あるコミットを指し示し続けるタグとは異なる性質です。
また、上記例でも確認できたようにブランチは分岐します。ブランチはかなりの独立性があり、あるブランチで作業した内容は基本的に他のブランチに影響を与えません。そのため多くの開発現場では完成品用ブランチ・開発用ブランチ・バグ修正用ブランチなど、複数のブランチを用意する傾向にあります。
5. ブランチの操作
ブランチの作成や削除には branchコマンド を、ブランチの切り替えには switchコマンド を使用するのをオススメします。
また、色々なことができるコマンドとして checkoutコマンド がありますが、ちょっと多機能すぎるので使いにくいと思います。
5-1. 確認
作成されたブランチの一覧を確認するには branchコマンド を単体で使用します。現在有効になっているブランチ名の先頭にはアスタリスク記号が付きます。
PS C:\Users\AGadget> git branchあるいは --show-currentオプション を付けることで現在有効となっているブランチだけを表示させることができます。
PS C:\Users\AGadget> git branch --show-current5-2. 作成
ブランチを作成することを ブランチを切る と言います。何故そのような言い回しをするのかは知りませんが、ともかく「切る」と表現するのです。
ブランチを切るにはbranchコマンドの引数にブランチ名を指定します。既に存在しているブランチを新たに切ることはできませんので注意してください。このコマンドを実行するとHEADの位置に新たなブランチが作成されます。
PS C:\Users\AGadget> git branch [ブランチ]HEADではない――過去のコミットにブランチを新規作成したいときは第2引数に付与したコミットを指定します。
PS C:\Users\AGadget> git branch [ブランチ] [コミット]5-3. 切り替え
有効なブランチを切り替えるには switchコマンド を使用してください。
PS C:\Users\AGadget> git switch [ブランチ]5-4. リネーム
既に作成されたブランチをリネームするときはbranchコマンドと --moveオプション を組み合わせてください。
PS C:\Users\AGadget> git branch --move [旧ブランチ] [新ブランチ]5-5. 削除
ブランチを削除するときはbranchコマンドと --deleteオプション を使います。
PS C:\Users\AGadget> git branch --delete [ブランチ]6. コミットの全体像を確認
logコマンドに --branchesオプション と --graphオプション を付けることで、全てのブランチのコミットがグラフィカルに表示されます。個人的に、よく使うコマンドなのでオススメします。
PS C:\Users\AGadget> git log --branches --graph7. マージ
ブランチは作ったら作りっぱなし、分岐したら分岐させっぱなし、ということはありません。不要になり破棄するケースはあるでしょうが、有効な（有用な）ブランチは、いずれかのタイミングで マージ するのが基本です。
7-1. マージとは？
マージ は異なる2つのブランチの状態・内容を1つに統合させる操作・機能のことです。
例えば、masterブランチに最初の完成版となるv1.0.0のコミットを保存したとします。
PS C:\Users\AGadget> git commit --message="最初の完成版となるv1.0.0です"一旦完成したということで、Aさんはv1.0.0のバグ修正を、Bさんは新機能の実装を、それぞれ分担して行うことにしました。そこで、お互い専用のブランチを切って作業することにしました。
PS C:\Users\AGadget> git branch A/fix PS C:\Users\AGadget> git branch B/feature数日後、AさんもBさんも作業を完遂しました。この時点ではmasterブランチにはv1.0.0の状態が保存されており、A/fixブランチにはv1.0.0のバグ修正を行ったプログラムが、B/featureにはv1.0.0をベースに新機能を追加したプログラムが保存されています。
さて、この状況でAさん・Bさんが加えた修正をv1.0.0のソースと統合するにはどうすればよいでしょうか。1つには、何らかの方法で差分を確認し、masterブランチに保存されたソースを差分のとおりに書き直してコミットするというのも手でしょう。ただ、マージを使えばもっとスマートかつセクシーに統合を行うことができます。
7-2. mergeコマンド
マージを行うときは マージ元となるブランチ と マージ先となるブランチ という視点が必要です。それぞれプログラミングでいう親クラス・子クラスのような関係と言えます。先の例ですとmasterブランチが前者、A/fixブランチとB/featureブランチが後者となります。
マージするときは、まず、マージ先となるブランチに移動します。
PS C:\Users\AGadget> git switch masterそして mergeコマンド の引数にマージさせたいブランチを指定します。
PS C:\Users\AGadget> git merge A/fix PS C:\Users\AGadget> git merge B/featureマージ処理が成功すると統合されたコミットが作成され、リポジトリに保存されます。
8. コンフリクト
基本的にマージは成功する
頼むから成功してほしいのですが、時折 コンフリクト が生じることがあります。コンフリクトとはマージを実行したときに何らかの理由から統合に失敗すること、また、その状態を指します。例を挙げましょう。まず、以下のようなファイルを用意します。
sample.txtHello world.これをmasterブランチにコミットし、新たにsubブランチを切って、masterブランチとsubブランチの双方で変更を加えます。
masterブランチHello world. mastersubブランチHello world. subこのように、元のファイルの同じ個所に変更を加えたファイル同士をマージした場合、コンフリクトが発生し、マージ処理が失敗します。statusコマンドを実行してみると Unmerged paths: や both modified: という記述があり、やはりコンフリクト状態になっていることが分かります。
PS C:\Users\AGadget> git status On branch master You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: sample.txt no changes added to commit (use "git add" and/or "git commit -a")8-1. マージを取り消す
コンフリクト状態になった場合、何らかのリアクションを行い、コンフリクトを解消せねばなりません。
最も安全なのはマージ処理を取り消すことです。
コンフリクト発生後、コンフリクト解消のためにファイルの編集などを行っていない場合はmergeコマンドと --abortオプション を組み合わせることでマージ処理を取り消すことができます。
PS C:\Users\AGadget> git merge --abortコンフリクト解消のために何らかの編集を行った場合は resetコマンド を使用し、最初の状態に復元しましょう。
PS C:\Users\AGadget> git reset --hard HEAD8-2. 手動マージ
取り消さないならば手動でマージを行う必要があります。
まず、statusコマンドなどで問題が発生したファイルを開きましょう。すると問題発生個所が次のように書き換えられていることが分かります。
Hello world. <<<<<<< HEAD master ======= sub >>>>>>> sub元の内容に加え、謎の記号が書き込まれています。見方は何となく分かると思いますが <<<<<<< HEAD と >>>>>>> sub の間が問題のあった部分です。そして、それぞれのブランチの内容が ======= で区切られています。
この範囲を手動で修正し、ステージング・コミットします。今回は次のように修正してみました。
修正後Hello world. sub master修正できましたらステージング・コミットして、2つのコミットの内容をマージしたコミットを作成します。
PS C:\Users\AGadget> git add .\sample.txt PS C:\Users\AGadget> git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: sample.txt PS C:\Users\AGadget> git commit .\sample.txt hint: Waiting for your editor to close the file... [master 0675cab] Merge branch 'sub' into master
- 投稿日：2020-08-14T02:19:50+09:00
Git入門 - 4
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第4回です。
今回は 保存したデータの活用方法 と 必須ではないが覚えておくと便利な操作 について説明します。
- 1回: 概要
- 2回: 導入手順とGitコマンド
- 3回: データの保存
- 4回: データの活用と便利な操作
- 5回: ブランチ
- 番外編: GitHub
2. 差分を確認
ソースファイルを編集していると、最後に保存したときから、どれだけ変更を加えたのか分からなくなるときがあります。
statusコマンド を使うことで、どのファイルに、どのような変更が加えられたのか――新規作成されたのか、変更されたのか、削除されたのか、リネームされたのかなどは分かります。
PS C:\Users\AGadget> git statusただ、内容の変化までは分かりません。内容を知りたいときは diffコマンド を使用します。オプションも引数も無しに実行すると、インデックスと比較して変更のあった全てファイルの変更が表示されます。
PS C:\Users\AGadget> git diffこれはこれで便利ですが、実際に需要があるのは、ある特定のファイルに限った差分表示でしょう。diffコマンドの引数にファイルを指定することで、そのファイルのみチェック対象にとることができます。
PS C:\Users\AGadget> git diff [ファイル]2-1. インデックスを対象に
--cachedオプション を付けると、インデックスに保存されたファイルと最新コミットとの差分を確認することができます。
PS C:\Users\AGadget> git diff --cached [ファイル]「ステージングしたファイルのなかに、どれだけ変更を加えたか覚えていないファイルがある」といったときに便利です。
3. あるコミットの状態に復元
restoreコマンド を使うと、任意のファイルを過去保存したコミットの状態に戻すことができます。
基本的には最後に保存したコミットの状態に戻ります。
PS C:\Users\AGadget> git restore [復元したいファイル]任意のコミットの復元したいときは --sourceオプション を使用してください。
PS C:\Users\AGadget> git restore --source=[コミット] [復元したいファイル]4. ステージングを取り消す
作業していると誤ってステージングすることがあると思います。そんなときは restoreコマンド と --stagedオプション を組み合わせることで、ステージングの取り消し処理が実現できます。
そもそも「ステージングを取り消す」とは、どういった結果になればステージングを取り消したことになるのでしょう。人によっては異なる意見があるでしょうが、概ね 最後にコミットしたときの状態に戻す ことがステージングを取り消すということになるのではないでしょうか。
状態の復元を行うrestoreコマンドと、復元範囲をワークツリーからインデックスに切り替える--stagedオプションを使うことで、そのような結果を得ることができます。
PS C:\Users\AGadget> git restore --staged [ファイルパス]4-1. コミットがないとき
1度もコミットしたことがない場合はrestoreコマンドは使えません。何故ならばrestoreコマンドは、あるコミットの状態に戻すコマンドであるため、そもそもコミットがされていない場合は戻し先がないのです。
そのときは緊急的（？）に rmコマンド と --stagedオプション の組み合わせで対応します。
PS C:\Users\AGadget> git restore --staged [ファイルパス]後述しますがrmコマンドはワークツリーにあるファイル――厳密には1度でもコミットされたことがあるファイルを削除するためのコマンドです。そして--stagedオプションは削除範囲をワークツリーからインデックスに変更する効果があります。
個人的には、ステージングを取り消すのには原則としてrestoreコマンドを使うべきだと思います。
5. ファイルを削除する
先述したようにファイルを削除するには rmコマンド を使用します。
基本的に、ファイルを削除するときはシェルやファイルマネージャーではなく、rmコマンドを使って削除するようにしてください。特に 捕捉 されたファイルに対してはrmコマンドの使用を推奨します。
PS C:\Users\AGadget> git rm [ファイルパス]5-1. 捕捉
Gitには 捕捉 という状態・概念があります。リポジトリに保存されたファイルは捕捉状態になります。捕捉状態になると、不要なファイルを削除したいとき（あるいは削除したとき）Gitに削除した旨を通知する必要が生じます。
これまで、ファイルを新規作成したり、変更したりした場合は、その都度ステージング・コミットを実行してきました。それらと同様に、削除した場合もステージング・コミットを実行して、Gitに削除したという記録を残す必要があるのです。
こんな感じにGitに削除記録を残すPS C:\Users\AGadget> Remove-Item .\samaple.ps1 PS C:\Users\AGadget> git add .\samaple.ps1 PS C:\Users\AGadget> git commit --message="○○の理由から、sample.ps1は不要になったので削除しました。" .\samaple.ps1ただ、それは捕捉状態に限った話です。捕捉状態にないファイルは消したところで そもそも、そのようなファイルは最初から存在しなかった と認識されるのでステージング・コミットの必要はありません。
5-2. rmコマンドを推奨する理由
ファイルを削除した場合、ステージングとコミットを行う必要があるという話ですが、rmコマンドは削除とステージングをまとめて行ってくれます。
ちょっと操作が減るPS C:\Users\AGadget> git rm .\samaple.ps1 PS C:\Users\AGadget> git commit --message="○○の理由から、sample.ps1は不要になったので削除しました。" .\samaple.ps1シェルやファイルマネージャーから削除した場合、ステージングを忘れる可能性があるのでミス防止のためにrmコマンドの使用を推奨します。
また、そもGitにファイル削除用のコマンドがあるのですから、できることならコマンドを使って操作したほうが 綺麗・丁寧 だと思うのです。
6. ファイルの移動とリネーム
ファイルを移動させたり、リネームするときは mvコマンド を使用してください。
PS C:\Users\AGadget> git mv [旧ファイル] [新ファイル]7. コミットをやり直す
コミットを間違えたときは commitコマンド と --amendオプション の組み合わせで直前のコミット処理をやり直すことができます。このコマンドを実行すると最新コミットが上書きされます。
PS C:\Users\AGadget> git commit --amend [コミットしたファイル]8. resetコマンドとHEADポインタ
便利なコマンドの1つに resetコマンド があります。resetコマンドの本質は HEADを変更すること です。副次的な効果として、インデックス・ワークツリーの状態を、変更先のコミットの状態にすることができます。
文法PS C:\Users\AGadget> git reset [影響規模を指定するオプション] [HEAD変更先のコミット]例文PS C:\Users\AGadget> git reset --mixed HEAD^8-1. HEADとは？
HEADとは 現在選択中のブランチにおいて参照中・作業中のコミットを表すポインタ です。ただ、この説明を理解するには ブランチ という概念・機能を知らねばなりません。そのため現在のところは 最新のコミットを表すポインタ と理解しておいてください。
これまで、何らかの理由で特定のコミットを指定したいときは、コミットのハッシュ値を使う必要がありました。ただ、ハッシュ値をいちいち入力するのは手間ですし、そもそもlogコマンドなどを使ってハッシュ値を調べる必要があります。古いコミットを参照するならともかく、最新のコミットや最新の1つ前くらいのコミットぐらいは、もっと簡単に参照したいものです。そんなときに役立つのがHEADです。
基本的に、HEADはcommitコマンドが実行されるたびに移動し、常に最新のコミットを参照します。そのため以下のような感じで最新のコミットを参照することができます。長ったらしいハッシュ値を打ち込むよりも、はるかに短くて済みます。
PS C:\Users\AGadget> git [何らかのコマンド] HEADまた、HEADには特殊な記法が用意されており、柔軟な利用が可能になっています。
最新のコミットの、1つ前のコミットを参照PS C:\Users\AGadget> git [何らかのコマンド] HEAD^ PS C:\Users\AGadget> git [何らかのコマンド] HEAD~1最新のコミットの、2つ前のコミットを参照PS C:\Users\AGadget> git [何らかのコマンド] HEAD^^ PS C:\Users\AGadget> git [何らかのコマンド] HEAD~2ところで基本的に最新のコミットを参照するHEADですが、状況によっては最新以外のコミットを指す場合があります。そのような状態を detached HEAD と言います。普通に操作していれば発生しませんし、発生したからといって必ずしも悪いわけではないので、特別気にする必要はありませんが一応覚えておいてください。
8-2. 改めてresetコマンドについて解説
HEADについて理解できたところで、改めてresetコマンドの挙動について説明します。
resetコマンドは引数に指定されたコミットにHEADを移動させるためのコマンドです。その副次的な効果として、インデックスとワークツリーに、移動先のコミットの状態を反映させたりさせなかったりすることができます。
まず、HEADの移動だけ行いたい場合は --softオプション を指定してください。インデックスとワークツリーの状態は最後にコミットしたときの状態のままですので、直前のコミットをやり直すときなどに便利です。
PS C:\Users\AGadget> git reset --soft [コミット]--mixedオプション を付けると移動先のコミットの状態をインデックスに反映させます。--softオプションと似ていますが、インデックスまで変化するので、コミットをやり直すのに際してステージングするファイルを大きく変化させたいときなどに便利です。
PS C:\Users\AGadget> git reset --mixed [コミット]インデックスとワークツリーのどちらにも影響を与えたいときは --hardオプション を使ってください。個人的には--hardオプションが一番使う機会が多い気がします。
PS C:\Users\AGadget> git reset --hard [コミット]ちなみに、この3オプションのいずれかを指定しなかった場合、--mixedオプションが自動的に適用されます。
9. タグ
タグ とはコミットに付けることができるポインタ・記号・目印のことです。
Gitには、コミットの内容・意図を説明するコミットメッセージ機能が付いています。ただ、そのコミットが何であるか――つまり、バージョン情報とかをコミットに紐づけたいときは、その旨をコミットメッセージ内に含める必要がありました。
そこでタグの出番です。タグはコミットメッセージから独立しており、コミットの状態を表現するのに適しています。また、コミットを指定するときにハッシュ値やHEADとともに使用することができます。
9-1. 作成されたタグを一覧表示
タグを操作するには tagコマンド を使用します。
コマンド単体で実行するとタグの一覧を確認することができます。
PS C:\Users\AGadget> git tag9-2. タグを作成・付与
タグを作成したいときは引数にタグ名を指定してください。作成されたタグは、作成されると同時に最新コミットに付与されます。
PS C:\Users\AGadget> git tag [タグ名]任意のコミットにタグを付けたいときは、第2引数に付与したいコミットを指定してください。
PS C:\Users\AGadget> git tag [タグ名] [コミット]タグは重複して使用することはできません。つまり、あるタグを複数のコミットに付けることはできないわけです。逆に、1つのコミットに複数のタグを付けることは可能です。
既に作成されているタグを、現在付いているコミットから別のコミットに変更したいときは --forceオプション を指定します。
PS C:\Users\AGadget> git tag --force [タグ名] [コミット]9-3. タグを削除
タグを削除したい場合は --deleteオプション を使用します。
PS C:\Users\AGadget> git tag --delete [タグ名]9-4. 注釈付きのタグ
--annotateオプション と --messageオプション 使うことで、タグに注釈を付けることができます。
文法PS C:\Users\AGadget> git tag --annotate --message=[注釈] [タグ名]例文PS C:\Users\AGadget> git tag --annotate --message="バグ修正完了版です。" v1.0.1
- 投稿日：2020-08-14T02:18:32+09:00
Git入門 - 3
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第3回です。
今回は Gitにデータを保存する操作 について説明します。
- 1回: 概要
- 2回: 導入手順とGitコマンド
- 3回: データの保存
- 4回: データの活用と便利な操作
- 5回: ブランチ
- 番外編: GitHub
2. バージョン情報保持構造
Gitではバージョン情報を保持するのに リポジトリ ・ インデックス ・ ワークツリー の3つのエリアを利用します。具体的な操作方法を知る前に、まずは、この3つの用語について、しっかりと理解してください。
2-1. リポジトリ
リポジトリ はバージョン情報を保存する場所のことです。「バージョンデータベース」とか「データディレクトリ」といった分かりやすい名前だったらよかったのですが、何故かGitを始めとする多くのVCSではリポジトリと呼びます。
リポジトリの正体は .git という名前の隠し属性付きディレクトリです。詳しくは後述しますが、以下のようなコマンドを実行することで、カレントディレクトリにリポジトリが作成されます。
PS C:\Users\AGadget> git init2-2. インデックス
インデックス（ステージングエリアとも） はリポジトリに保存したいファイルを一旦配置しておく場所のことです。言い換えるならば 仮登録エリア あるいは 仮保存エリア といった感じでしょうか。
リポジトリに保存する前に、ここに保存したいファイルをまとめておくことで「保存するファイルに漏れがないか」「保存予定にないファイルまで保存しようとしていないか」といった最終確認を行うのに使います。
インデックスの存在を初めて知った人は「インデックスって要る？」「正直無くてもいいんじゃ？」と思われるでしょう。正直、私も必須の機能ではないと考えています。インデックスがあるためにGitの敷居が上がっているのは間違いありません。ただ、操作に慣れてくると色々と便利な側面が見えてくるので頑張って付き合っていきましょう。
ちなみに、このインデックスの実態も、先ほど紹介した「.git」というディレクトリのなかにあります。
2-3. ワークツリー
ワークツリー（ワーキングツリー、作業ディレクトリとも） はリポジトリに保存したいファイルを配置する場所のことです。難しく考える必要はありません。単に、ソースファイル等を置いておく場所に、ワークツリーというお洒落な名前を付けただけのことです。
ワークツリーがどこを指すかはリポジトリが配置されたパスに応じて変化します。ワークツリーは リポジトリが配置されたディレクトリのなか かつ リポジトリ以外の場所 を指します。
以下例をご覧ください。以下例には「file-1.ps1」から「file-7.ps1」までの7つのファイルと、リポジトリが1つだけあります。このうち、ワークツリーに配置されているファイルはどれでしょうか。正解は「file-3.ps1」「file-5.ps1」「file-6.ps1」の3つです。
■ .\ ├ file-1.ps1 │ ├■ app │├ file-2.ps1 ││ │└ ■ src │ ├ file-3.ps1 │ │ │ ├■ .git │ │└ file-4.ps1 │ │ │ └■ lib │ ├ file-5.ps1 │ │ │ └■ lib-main │ └ file-6.ps1 │ └■ test └ file-7.ps13. データ保存の流れ
リポジトリにファイルを保存するまでは、ざっくりと以下のような流れになります。
- リポジトリを新規作成
- 保存処理に先んじて、Gitの設定が正しいかチェック
- 保存したいファイルをワークツリーに配置
- ワークツリーにあるファイルをインデックスに保存
- インデックスに保存されたファイルに誤りがないか確認
- リポジトリに保存
あくまでも、ざっくりとした目安ですので、この通りに行う必要はありません。
4. リポジトリを新規作成
最初に行うのはリポジトリを新規作成することです。
「データを保存する場所を自分で作成する」ということに違和感を覚える人は少なくないと思います。多くのアプリ・システムではデータを保存する場所は予め用意されており、そこにデータを保存するのが一般的だからです。とはいえ、結局のところは予め用意されているか、自分で作るかだけの違いなので慣れていきましょう。
リポジトリを配置したいディレクトリに移動して initコマンド を実行してください。カレントディレクトリにリポジトリ、つまり「.git」というディレクトリが配置されます。
例として、デスクトップ上にリポジトリを作ってみます。
PS C:\Users\AGadget> Set-Location ".\Desktop" PS C:\Users\AGadget\Desktop> git init Initialized empty Git repository in C:/Users/AGadget/Desktop/.git/ちなみに、既にリポジトリが存在する場所でinitコマンドを実行しても何も起こりません。表示されるメッセージが多少変わるくらいです。
リポジトリが存在しない場合PS C:\Users\AGadget\Desktop> git init Initialized empty Git repository in C:/Users/AGadget/Desktop/.git/リポジトリが存在する場合PS C:\Users\AGadget\Desktop> git init Reinitialized existing Git repository in C:/Users/AGadget/Desktop/.git/4-1. リポジトリ作成の目安
リポジトリは自分で作ることができますし、好きな数だけ作ることができます。では、どのように、どれくらい作るべきなのでしょうか。
これは私個人の考えになりますが、基本的に 1つのアプリ・システムにつき、リポジトリは1つ というのが基本になるかと思います。そのため、例えば、電卓アプリと家計簿アプリを作るとしたら、それぞれに1つずつリポジトリを用意するべきと考えます。5. Gitの設定
これからの操作のために、事前に、いくつかの設定を済ませておくとよいでしょう。
Gitでは設定情報を3箇所で管理しています。システム全体で有効となる system 、ユーザーごとに有効となる global 、そしてリポジトリごとの固有設定となる local です。
同じ設定項目でも3箇所にそれぞれ異なる値を指定することができます。例えば、systemに「a」、globalに「bb」、localに「ccc」といった具合にです。このように重複が生じた場合はlocal・global・systemの順に優先されます。ですので、先の例ではlocalに設定された「ccc」が有効となります。
基本的にsystemを触ることはなく、設定を弄るとしたらglobalかlocalのどちらかとなります。とりあえずglobalに設定を入れておくと、リポジトリを新規作成するたびに再設定する手間が省略できるので便利です。
5-1. 設定を確認
設定を確認したり変更したりするには configコマンド を使用します。
--listオプション を指定することで、全ての設定項目を確認することができます。system・global・localに重複して値が指定されていた場合は、そのうちで有効となる値が表示されます。
PS C:\Users\AGadget> git config --list特定の設定項目だけ確認するならば引数に設定項目を指定します。こちらもsystem・global・localに重複して値が指定されていた場合は、そのうちで有効となる値が表示されます。
文法PS C:\Users\AGadget> git config [設定項目]例文PS C:\Users\AGadget> git config user.email有効な値ではなく、system・global・localのいずれかの設定項目を確認したいときは、それぞれ --systemオプション ・ --globalオプション ・ --localオプション のいずれかを指定します。
文法PS C:\Users\AGadget> git config [設定場所] [設定項目]例文PS C:\Users\AGadget> git config --system user.email--listオプションを用いることもできます。
PS C:\Users\AGadget> git config --system --list5-2. 設定を変更
設定を変更するには、system・global・localのいずれの場所の値を変更するかをオプションで指定し、加えて、第1引数に変更する設定項目、第2引数に新たに設定する値を指定します。
文法PS C:\Users\AGadget> git config [設定場所] [設定項目] [値]例文PS C:\Users\AGadget> git config --global user.email AGadget@gmail.comちなみに、変更する場所を指定する--systemオプション・--globalオプション・--localオプションを省略した場合、--localオプションが指定されたものとして処理されます。
--localオプション付きと見做されるPS C:\Users\AGadget> git config user.email AGadget@gmail.com5-3. 代表的な設定項目
いくつか代表的な設定項目を紹介します。
まずは user.email です。連絡先を表しています。この設定項目に有効な値が入っていないと、リポジトリにデータを保存することができませんので注意してください。「連絡先を入力するのはちょっと……」という方は適当な値を入れておいても大丈夫です。
例文PS C:\Users\AGadget> git config user.email AGadget@gmail.comテキトーな値でもOKPS C:\Users\AGadget> git config user.email xxxuser.name は名前を表します。user.nameに有効な値がない場合は unknown という値がuser.nameに入っているものとして処理されます。
PS C:\Users\AGadget> git config user.name AGadgetインストール時に指定した標準のテキストエディタを表すのが core.editor です。Gitではリポジトリにデータを保存するときにコメントを添えることが求められます。「何故保存したのか？」「何を保存したのか？」といったことを書くのですが、このcore.editorに設定されたテキストエディタが起動します。
PS C:\Users\AGadget> git config core.editor code6. ワークツリーの使い方
リポジトリに保存したいファイルを配置する場所 と説明したワークツリーですが、このように説明されると「アプリ・システムを構成するソースファイルだけど、保存する予定のファイルはどこに置いておくの？」「保存処理が実行できたら、ワークツリーに配置していたソースファイルはどうしたら良いの？」と疑問に思われるかもしれません。
多くの場合、リポジトリは1つのアプリ・システムと紐づくように作られます。そのアプリ・システムを構成するソースファイル等は常にワークツリーに置いておき、ワークツリーに置いたままテキストエディタ等で編集するのが一般的です。
もちろん、リポジトリに保存したいときだけワークツリーに配置し、保存後はワークツリーから削除するという運用でも問題はありませんが、かなり特殊な運用だと思います。
7. インデックスとステージング
リポジトリにファイルを保存したくなったら、まずはインデックスにファイルを保存・登録しましょう。この操作を ステージング と言います。
ステージングするには addコマンド を使用します。
PS C:\Users\AGadget> git add [ステージングしたいファイルパス]複数のファイルをステージングするときは、ファイルパスを半角空白で区切るか、正規表現を使用してみてください。
PS C:\Users\AGadget> git add .\file-1.ps1 .\file-2.ps1 .\file-3.ps1PS C:\Users\AGadget> git add .\*.ps1変更のあったファイルの全てをステージングしたいときは --allオプション が便利です。
PS C:\Users\AGadget> git add --all8. ワークツリーとインデックスの状態を確認
リポジトリに保存したいファイルはステージングする必要があるわけですが、リポジトリへの保存処理を実行する前に、本当にステージングできたか確認しておくのがベターです。
確認には statusコマンド を使います。
PS C:\Users\AGadget> git statusstatusコマンドを使うことで――
- ステージングされていない新規ファイル
- ステージングされた新規ファイル
- ステージングされた変更のあったファイル
- ステージングされていない変更のあったファイル
- ステージングされていない削除されたファイル
- ステージングされた削除されたファイル
――など、ほとんどのファイルの状態が確認できます。ただし、リポジトリに最後に保存されたときから変更が加えられていないファイルなどはstatusコマンドに表示されないので注意してください。何度か使ってみれば挙動がよく分かると思います。
挙動や表示内容が理解できるようになったら --shortオプション を試してみましょう。--shortオプションを付けると、通常の表示メッセージよりも短い内容で出力されます。
PS C:\Users\AGadget> git status --short9. コミット
initコマンドでリポジトリを用意し、configコマンドで設定を済ませ、addコマンドでファイルをステージングし、statusコマンドでステージングされたかどうかを確認できましたら、リポジトリへのファイル保存処理を実行することができるようになります。
commitコマンド を使うことでリポジトリにファイルを保存することができます。この保存処理のことを コミットする と言い、commitコマンドを実行するたびに作られるデータ単位（ゲームでいうセーブデータのことです）を コミット と言います。
commidコマンドの引数に指定されたファイルがコミットの対象になります。正規表現も使用できます。
文法PS C:\Users\AGadget> git commit [ファイルパス]例文1PS C:\Users\AGadget> git commit .\main.ps1例文2PS C:\Users\AGadget> git commit .\file-1.ps1 .\file-2.ps1 .\file-3.ps1例文3PS C:\Users\AGadget> git commit .\*.ps1全てのファイルをコミットしたいときは --allオプション を使用すると便利です。
PS C:\Users\AGadget> git commit --all9-1. コミットメッセージ
commitコマンドを実行すると コミットメッセージ を入力するために、設定項目 core.editor に登録されたテキストエディタが起動します。
コミットメッセージとは各コミットに付ける説明文のことです。 コミットした理由 ・ コミットの概要および詳細 ・ このコミットがどういう結果を及ぼすか などをコミットメッセージに入力します。コミットメッセージがあるおかげで、後からコミット履歴を読み返したときに「ここで○○を実装したのか」「こういう流れで開発されたのか」「バグ修正に随分と時間がかかっているな」みたいなことが分かるのです。
テキストエディタが起動しましたら、1行目からコミットメッセージを入力してください。途中に改行を入れても問題ありません。
入力が完了しましたら上書き保存してテキストエディタを閉じてください。テキストエディタが閉じられたタイミングで、コミットメッセージの登録が完了します。
コミットメッセージの入力をコマンドライン上から行いたいという場合は --messageオプション を使用してください。
PS C:\Users\AGadget> git commit --message="main.ps1をコミットします。" .\main.ps19-2. コミットメッセージは必須
コミットメッセージを入力しない――コミットメッセージを空のまま登録することは、原則として許可されませんので注意してください。入力せずにテキストエディタを閉じるとエラーになり、コミット処理が無効になります。
どうしても入力したくない（そんなケースあるか？）という場合は --allow-empty-messageオプション を付けてください。テキストエディタは起動しますが、空のまま閉じてもエラーにならず、コミット処理が正常終了します。
PS C:\Users\AGadget> git commit --allow-empty-message .\main.ps110. 履歴を確認
コミットの記録を確認するには logコマンド を使用します。
PS C:\Users\AGadget> git log実行すると新しいコミットから順に表示されます。コンソールに表示されるメッセージの量はコミットの数に比例しますので、コミットの数があまりに多いと以前の記事で触れました Vi/Vimモード になります。
新しいコミットから任意の数だけ表示したいという場合は --max-countオプション が使えます。
文法PS C:\Users\AGadget> git log --max-count=[表示件数]例文PS C:\Users\AGadget> git log --max-count=5
- 投稿日：2020-08-14T02:16:46+09:00
Git入門 - 2
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第2回です。
今回は Windows 10にGitを導入する手順 と Gitコマンドの操作方法 について説明します。
- 1回: 概要
- 2回: 導入手順とGitコマンド
- 3回: データの保存
- 4回: データの活用と便利な操作
- 5回: ブランチ
- 番外編: GitHub
2. 導入手順
Windows 10にGitをインストールするには、公式サイトからWindows用のGitのインストーラーを落としてくるのが一番簡単だと思います。まずはGitの公式サイトに行きましょう。
トップページからダウンロードページに移動します。
このページからWindows用のインストーラーをダウンロードしてください。インストーラーのサイズは大きめなので時間も相応にかかります。
ダウンロードできましたらインストーラーを立ち上げ、セットアップを行ってください。導入作業はインストーラーの指示に従って進めれば、特に困るようなことはありません。ただ、いくつか注意しておいたほうがよい設定箇所があるので、そこだけ紹介します。
2-1. インストールパス
初期設定だと C:\Program Files\Git になっているはずです。Cドライブの直下などに配置したい人は、この設定を見逃さないようにしてください。
2-2. インストールオプション
途中、インストール時に行う処理を選択できる画面が表示されます。ここは好きに設定してもらったらよいのですが、特に気にしないならば標準設定のまま先に進んでもらって大丈夫です。
2-3. 標準のテキストエディタ
標準のテキストエディタの設定は少し注意をしてください。
Gitではテキストエディタを利用する機会があります。詳しくは次回記事にて解説しますが、Gitにデータを保存するときにメッセージを残すことができるのです。その入力にはコマンドライン上から入力する方法と、テキストエディタから入力する方法とがあります。
このとき呼び出させれる設定をインストール時に行う必要があります。初期設定では「Vim」というエディタが設定されているのですが、操作方法が大変特殊なので個人的にはオススメできません。可能であれば他のエディタ――最悪「メモ帳（notepad.exe）」でもよいので別のものを検討してください。
万が一、ここでVimにしても後ほど変更できますので、そこは安心してください。
3. Gitコマンド入門
インストールできましたら、さっそく操作してみましょう。バージョン管理には直接関係のないコマンドを、いくつか紹介しますので試しに実行してみてください。
Gitを操作するには git.exe をシェルから呼び出す必要があります。git.exeの場所はインストールされたディレクトリ直下にある bin というディレクトリのなかです。標準のインストールパスが C:\Program Files\Git なので、Gitインストール時にパスを変更していないならば C:\Program Files\Git\bin\git.exe にあるはずです。
インストール時に同ディレクトリにPathが通っているはずなので、ファイルの場所は意識せずに呼び出せるはずです。
3-1. 文法
git.exeの使い方――Gitコマンドの文法は以下の通りです。
PS C:\Users\AGadget> git [オプション] [コマンド] [コマンドのオプション] [コマンドの引数]オプションは色々あるのですが、オプション名の前にハイフン記号が1つか2つ付くという共通点があります。また、ハイフン記号が1つのオプションはオプション名が簡易的で、ハイフン記号が2つのオプションはオプション名が丁寧であるという共通点もあります。
4. バージョン情報を確認
インストールされているGitのバージョンを確認するには --versionオプション を使用します。
PS C:\Users\AGadget> git --version git version 2.27.0.windows.15. アップデート
インストールされているGitをアップデートするには update-git-for-windowsコマンド を使用します。
実行すると新バージョンが存在するか確認し、新バージョンがあるならばアップデートするかどうか訪ねてきます。
以下は、インストールされているバージョンが2.27.0で、新たに2.28.0が来ていたときに表示された内容です。
PS C:\Users\AGadget> git update-git-for-windows Git for Windows 2.27.0.windows.1 (64bit) Update 2.28.0.windows.1 is available Download and install Git for Windows 2.28.0 [N/y]?メッセージが [N/y]? で途切れていますが、これは入力待ちの状態であることを表しています。アップデートするならば y と入力して、Enterキーを押してください。すぐに新バージョンのダウンロードが開始されます。
以下は、アップデートを許可した後に表示された内容です。
PS C:\Users\AGadget> git update-git-for-windows Git for Windows 2.27.0.windows.1 (64bit) Update 2.28.0.windows.1 is available Download and install Git for Windows 2.28.0 [N/y]? y ##################################################################################################################################################################################################################################### 100.0%- ##################################################################################################################################################################################################################################### 100.0%新バージョンのデータのダウンロードが完了すると、インストーラーが立ち上がりますので、以降はインストーラーの指示に従ってください。
ちなみにアップデートがないときは以下のようなメッセージになります。
PS C:\Users\AGadget> git update-git-for-windows Git for Windows 2.28.0.windows.1 (64bit) Up to date6. ヘルプ
ヘルプを確認したいときは helpコマンド を指定します。
コマンド単体で実行すると、Gitの文法と主要なコマンドが表示されます。
PS C:\Users\AGadget> git help6-1. 特定のコマンドのヘルプを表示
特定のコマンドの使い方を知りたいときは、helpコマンドの引数に知りたいコマンドを指定してください。
文法PS C:\Users\AGadget> git help [知りたいコマンド]例文PS C:\Users\AGadget> git help init実行するとコマンドの使い方が書かれたHTMLファイルが開かれます。当コマンドを実行する前に、HTMLファイルの既定のプログラムにブラウザアプリを設定しておいてください。
6-2. 全てのコマンドを表示
全てのコマンドを表示するには --allオプション を指定します。
PS C:\Users\AGadget> git help --allGitのコマンドは非常に多いので、コマンド数の多さに比例して、表示されるメッセージもかなり長いものになります。
当コマンドにかぎらず、Gitでは非常に長いメッセージが表示されるとき、特殊な操作状態に移行します。これを便宜上 Vi/Vimモード と呼称します。詳しくは次項にて説明します。
7. Vi/Vimモード
コマンドを実行した結果、非常に長いメッセージが表示されるとき、Gitは特殊な操作モードに移行します。これを便宜上 Vi/Vimモード と呼称することにします。ViおよびVimというテキストエディタに似た操作方法で操作するモードだからです。
Vi/Vimモードの主要な操作を紹介します。
- q: Vi/Vimモードを抜ける
- ↓: 1行下にスクロール
- z: 大きく下にスクロール
- ↑: 1行上にスクロール
- w: 大きく上にスクロール
- 投稿日：2020-08-14T02:16:01+09:00
Git入門 - 1
1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第1回です。
今回は そもそもGitとは何なのか ということについて説明します。
2. Gitとは？
Git は2005年12月21日に発表された VCS です。「ギット」と読みます。
「ジット」だと思ってた。開発元は、Linuxの生みの親であるLinus Benedict Torvalds氏と、Linuxコミュニティです。元々Linuxコミュニティでは、Linuxのソースコードの管理にBitKeeperというVCSを使用していました。ただ、様々な事情からBitKeeperの使用をやめることになり、その際BitKeeperの代替となるVCSを探したのですが、満足できるものが無かったため、新たにGitが開発されました。
3. VCSとは？
VCS (Version Control System) は バージョン管理 を支援するアプリの総称です。もちろん、バージョン管理ができるならば、アプリでなくとも（Webサービスなどであったとしても）VCSたりうると思うのですが、主要なVCSは全てアプリという形を採っています。
Git以外のVCSには――
- 世界初のVCSである SCCS (Source Code Control System)
- 世界で2番目のVCSであり、今なお一部では現役と聞く RCS (Revision Control System)
- クライアントサーバー型VCSの祖として広く普及した CVS (Concurrent Versions System)
- CVSの改良型のように語られることが多い SVN (Apache Subversion)
- Gitのライヴァル Mercurial
- 悪評高き VSS (Microsoft Visual SourceSafe)
- VSSの汚名返上に成功した（？） TFS (Team Foundation Server)
――などがあります。
4. バージョン管理とは？
私が調べたかぎりでは厳密な定義はないようです。バージョン管理（version control）という呼び方すら絶対ではなく――
- software configuration management
- SCCM (Software Change and Configuration Management)
- source configuration management
- revision control
- source control
――といった色々な呼称が使われているようです。
ただ、それでは話が進まないので、私個人の解釈を申し上げますと、バージョン管理とは ある成果物の状態の変遷を、特定の法則に基づいて記録・管理する手法および概念 ということになるでしょう。
プログラムの改修作業（変更作業）は常に成功するわけではありません。時には、変更を加えたことで新たなバグが生じたり、余計なところにまで手を付けてしまったり、そもそも変更内容自体が適切でなかったりします。そんなとき、変更前の状態が残っているのと残っていないのとでは、その後の対応状況・対応方法・対応難易度が変わってきます。言わずもがな、変更前の状態が残っているほうが対応が容易になります。
また、各状態を残すにしても規則性が必要です。例えば、新しい状態になるごとに「ソースファイルの末尾の数字を増やしていく（v1、v2、v3）」とか「変更を加えた日付を付ける（20200101、20200103、20200201）」といったようにです。これを徹底しないと以下のように収拾が付かなくなります。
- main.ps1
- main_v2.ps1
- main_20200203.ps1
- main-200204.ps1
- 【最新版】main.ps1
- 【最新版】main.ps1_バグ修正済み
- main.ps1_本番環境
上記例だと7つのファイルがありますが、結局どれが最新版なのか分かりません。どのように変更が加えられてきたのかも読み取れません。これではバージョン管理ができているとは言えません。
5. バージョン管理するのにVCSって要るの？
バージョン管理を行うのにVCSは必須ではありません。
実際、電子式コンピューターの生産、およびプログラミング言語の利用は1940年代から始まりましたが、世界初のVCSであるSSCSが登場したのが1972年のことです。つまり、およそ30年近くにわたって、VCSを用いないバージョン管理が行われてきたわけです（バージョン管理が1940年代から存在していたという前提に立つ）。
ただ、VCSを用いないバージョン管理は往々にして、VCSを用いたバージョン管理よりも問題を生じさせます。各バージョンを区別する方法（概ねファイル名で区別しますが）で悩んだり、旧バージョン・現行バージョン・開発中バージョンの分け方・管理体制で悩んだり、メンバーのなかからバージョン管理を無視する人が出てきたり、プロジェクトが進むにつれて管理が煩雑になってきたり、と色々と苦労する羽目になるでしょう。
このようなエンジニア職の本質ではない仕事はVCSというツールに任せてしまえばよいのです。
6. Gitの評価
他のVCSと比較したGitの長所として、よく聞くのは――
- 動作が軽快
- 多機能
- 大規模開発に耐えうる
- 現状、VCSはGitかVSNのツートップ
- ブランチを積極的に切っていく開発フローに適する
- マージ処理が賢い
――などがあります。反対に、短所としては――
- 覚えなければならない概念・仕様が多い
- Gitコマンドの抽象化が足りておらず使いにくい
- VCSのなかで最も学習難易度が高い
――などです。
私個人の考えも含めた総評としては 多機能、かつ高性能。それでいて様々プロジェクトで使われてきた実績もある、最も優れたVCSの1つ。ただし、学習コストも相応に大きい といった感じでしょうか。
ちなみに、無料のアプリなので安心して使ってください。