はじめに

git使っていて「コマンドなんだっけ？」ってなったら、
結局これ。

help

% git --help
usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]

These are common Git commands used in various situations:

start a working area (see also: git help tutorial)
   clone     Clone a repository into a new directory
   init      Create an empty Git repository or reinitialize an existing one

work on the current change (see also: git help everyday)
   add       Add file contents to the index
   mv        Move or rename a file, a directory, or a symlink
   restore   Restore working tree files
   rm        Remove files from the working tree and from the index

examine the history and state (see also: git help revisions)
   bisect    Use binary search to find the commit that introduced a bug
   diff      Show changes between commits, commit and working tree, etc
   grep      Print lines matching a pattern
   log       Show commit logs
   show      Show various types of objects
   status    Show the working tree status

grow, mark and tweak your common history
   branch    List, create, or delete branches
   commit    Record changes to the repository
   merge     Join two or more development histories together
   rebase    Reapply commits on top of another base tip
   reset     Reset current HEAD to the specified state
   switch    Switch branches
   tag       Create, list, delete or verify a tag object signed with GPG

collaborate (see also: git help workflows)
   fetch     Download objects and refs from another repository
   pull      Fetch from and integrate with another repository or a local branch
   push      Update remote refs along with associated objects

'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.

や

% git add --help

など

最後に

ただ、説明が全て英語なので、その解読に時間が掛かってしょうがない…

プロキシを経由している自社ネットワークで使用している開発マシンにて、VSCodeで実行できる以下コマンドでGoの開発環境を構築しようとした。

Go: Install/Update Tools

ところが以下のようなメッセージが出てインストールが失敗してしまうという状況です。

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

いろいろ調べたので、共有します。

前提条件

VSCode、Gitはインストール済み

対応まとめ

GitHubの設定ファイルにプロキシ設定を追加する

先にこれを実行しましたが、事象は解消されませんでした。

git config --global http.proxy http://proxy-address:proxy-port
git config --global https.proxy http://proxy-address:proxy-port
git config --global http.sslVerify false

VSCodeのsettings.jsonにプロキシの設定を追加する

この対応で「Go: Install/Update Tools」が失敗する事象は改善できました。
先ほど記載したgitのプロキシ設定も依存しているのかは不明です。

{
"http.proxy": "http://proxy-address:proxy-port"
}

感想

実はまだgo getができない状態なので、引き続き調査を進めていきます。

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

このエラーで悩んでいる方に届いてほしいです。

• 前の記事：Git初心者のメモ その5：共有リポジトリ

まず git fetch でリモート追跡ブランチを作る。

git fetch ＜リモート名＞ ＜ブランチ名＞

そして git checkout -t でブランチを作ってその作ったブランチに切り替える。

git checkout -t ＜リモート追跡ブランチ＞

例：

y_ito@note MINGW64 /c/work/lo_rep (master)
$ git branch
* master

y_ito@note MINGW64 /c/work/lo_rep (master)
$ git branch -r
  origin/master

y_ito@note MINGW64 /c/work/lo_rep (master)
$ git fetch origin develop
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From file:///c/work/pub_rep/uchinaaguchi
 * branch            develop    -> FETCH_HEAD
 * [new branch]      develop    -> origin/develop

y_ito@note MINGW64 /c/work/lo_rep (master)
$ git checkout -t origin/develop
Switched to a new branch 'develop'
Branch 'develop' set up to track remote branch 'develop' from 'origin'.

y_ito@note MINGW64 /c/work/lo_rep (develop)
$ git branch
* develop
  master

y_ito@note MINGW64 /c/work/lo_rep (develop)
$ git branch -r
  origin/develop
  origin/master

https://qiita.com/k8uwall/items/63c6424a976012122d18

あれから2年、そろそろアップデートしてみる。

docker-compose.yml

version: '3'
services:
  web:
    #image: gitea/gitea:1.7
    image: gitea/gitea:1.13.1
    volumes:
      - ./gitea-data:/data
    ports:
      - "3000:3000"
      - "10022:10022"
    environment:
      - TZ=Japan
      - SSH_PORT=10022
    restart: always

START_SSH_SERVERの行をコメントアウトする

$ vi gitea-data/gitea/conf/app.ini
;START_SSH_SERVER = true

$ docker-compose pull
$ docker-compose up

クライアント側から参照するサーバー側のkeyが変わるらしいので
クライアント側のknowns_hosts行を削除する。

$ vi ~/.ssh/known_hosts
[192.168.1.100]:10022 ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx　←削除

他

ログに以下の行がssh接続するたびにエラーが記録されてしまうが、動きは問題ないらしい。
ssh logs about missing host certificates · Issue #13724 · go-gitea/gitea

web_1  | Could not load host certificate "/data/ssh/ssh_host_ed25519_cert": No such file or directory
web_1  | Could not load host certificate "/data/ssh/ssh_host_rsa_cert": No such file or directory
web_1  | Could not load host certificate "/data/ssh/ssh_host_ecdsa_cert": No such file or directory
web_1  | Could not load host certificate "/data/ssh/ssh_host_dsa_cert": No such file or directory

変更したファイルの一覧を見る

git status

差分を見る

git diff

ステージに追加

git add -A

コミット

git commit -m

カレントディレクトリをリモートにプッシュ(originを指定でブランチ名を指定しなくてよい)

git push origin HEAD

コミットを一つにまとめる

git rebase -i

git stash
git reset
コミットが発生したときの対応

マージと同時にissueをcloseできる？

はじめに

みなさんこんにちは。突然ですが、コミットメッセージを適当な気持ちで書いていませんか？
2,3週間後に過去のコミットのログを見直したときに、何についての変更なのかがわかりづらくて昔の自分を殴りたくなった経験はありませんか？

そんなあなたにとっておきのプラグインを紹介いたします。

概要

結論から申し上げますと、commitizenを使うだけです。

Commitizenとは?
CLIを使って対話的にコミットメッセージを作ることができるコマンドラインツールです。

導入手順

以下の記事を参考に導入して参ります。

Commitizenを使ってもうコミットメッセージに迷わない
個人開発者のためのコマンドラインGit使いこなし術

①グローバルにインストール
(ローカルにインストールすることもできますが、今回はグローバルにインストールします。)
以下のコマンド

$ npm install commitizen -g
$ npm install -g cz-conventional-changelog

②グローバルのルート直下に.czrcファイルを作成

$ touch .czrc
$ vim .czrc

.czrc

{ "path": "cz-conventional-changelog" }

以上です。gitでaddした後に
$ git cz
を入力するとcommitizenがスタートし、以下のような対話形式でメッセージを入力する流れとなります。

コミット後に
$ git log --graph
を入力すると以下のようにメッセージを含んだlogが表示されます。

参考記事

非常にわかりやすかったです。ありがとうございました。

【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話
僕が考える最強のコミットメッセージの書き方

[Question] SyntaxError: Parsing JSON at <path> for commitizen config failed:に対するエラーは以下のissueで議論されていました。
[Question] SyntaxError: Parsing JSON at for commitizen config failed:

【Git】作業ブランチに最新のmasterを反映させる方法！

コンフリクトしたのでrebaseしたい

Git とは

「Git」（ギット）という単語を使うだけで、エンジニアっぽくなる。（気がする）

じゃあ、Gitって何？

結論から、

Gitとは、「作ったプログラムの履歴を残したり、そこに戻ったりするやつ」

CLI（＝CUI）、GUI とは

そのGitの前に知っておくべき、いや、知っておかなければ進めないものがある。

それが、CLI（CUIとも言われる）とGUI。
英語３文字攻撃だけど、たいしたことじゃない。

・CLI（コマンドラインインターフェイス）：裏
・GUI（グラフィカルユーザインターフェイス）：表

以上。いや、例くらい出しておく。

・CLI（コマンドラインインターフェイス）：黒い画面（ターミナル）に呪文を打ち込む
・GUI（グラフィカルユーザインターフェイス）：（たぶん今やってる）マウスやタッチパッドで画面を動かしたり、タッチしたりする

へー。で？

で、非常に大変残念ながら、
「Git」は「CLI」の方ですよ。という話。

Gitはどう使う？

それじゃあ、Gitは実際にどうやって使うのか。

上のCLIのとこで出てきた「ターミナル」というやつを使う。（Mac）

ターミナルっていうのは、いわゆる黒い画面?
これが実物。

せめて日本語１文字くらい入れてくれ！と思うよね。。

この画面だけで拒否反応が出そうだけど、大丈夫。
まず、こんな英語をいろいろと入力できない！と勘違いしがち。

実は、自分が入力した部分は、「％」の右部分だけ。
これで見ると、「pwd」と「ls」の合計５文字だけ！
あとは全部、Enter押したら勝手に出てくる。

だいぶハードル下がったんじゃない？

その「％」の右側に自分で入れるのを「コマンド」っていう。
コマンドっていうのは、こうしてくれという命令。
「パンを買ってこい」と命令して、Enter押したら、「はい/いいえ」と返事が返ってくる感じ。

ディレクトリ と パス

ディレクトリ。なんでわざわざ難しいような名前にするのか。。
結局は、ディレクトリってこれ↓

ディレクトリ ＝ フォルダ

ここでは、フォルダを「カバン?」」と考えてみて欲しい。

コンピュータのデータはいろんなカバンの中に入っている。

こんなこともよくある。
カバンを開けたら、またカバンが入っていて、さらにそのカバンの中にもカバンが入っていて。。。

用語の説明をしておく。

・ルートディレクトリ：一番上のフォルダ（一番大きいカバン）
・カレントディレクトリ：今いる/作業しているフォルダ（今開いているカバン）

・絶対パス：ルートディレクトリからの経路（一番大きいカバンからのスタート）
・相対パス：今のフォルダからの経路（今開いているカバンからのスタート）

パスっていうのは経路、つまり、道。

カバンで言うと、
・どのカバンからスタートするのか
・そこから何個か開くか、何個かしまい直す
みたいな感じ。

、、、分かりづらいので、例↓

フォルダ１（1番大きいカバン）

フォルダ２（その中の２番目のカバン）←これを開いている

フォルダ３（さらにその中の３番目のカバン）

この３つのフォルダ（カバン）があったとする。

・ルートディレクトリは、フォルダ１の１番大きいカバン
・カレントディレクトリは、今開いているフォルダ2のカバン

フォルダ３までのパスを考えると、

・絶対パスなら、「/フォルダ２/フォルダ３」（カバン1がスタートで、その中のカバン2の中のカバン３）
・相対パスなら、「/フォルダ３」（カバン2がスタートで、その中のカバン３）

「/」は「その中の」みたいな意味。

なんとなくわかったかな？

大事なこと

この黒い画面の操作で、最も大切だと感じたのは、

今、自分がどこにいるのか（どのカバンを開いているのか）を意識すること

これはまず間違いないので、最後にもう一回言う。

今、どのカバンを開いているのかを常に意識すること

【次回】黒い画面（ターミナル）でよく使うコマンド

私は現在、オンラインプログラミングスクール「やんばるエキスパート」で、４人チームで共同開発を行っています。

開発現状

ブランチは開発用のdevelopブランチをメインとしており、自分で作業する時は、developブランチから新しい作業ブランチを切って作業しています（ここでは仮に feature/hoge_fuga とします）。そして、コンフリクトの発生時にスクールの教材では、

git branch で作業ブランチにいることを確認後
git fetch --prune
git merge origin/develop

を行うように記載されており、「fetchってなに？」「--pruneってなに？」「merge origin/developって何で行うの？」と疑問になったので、自分で調べてまとめてみました。

git fetch --pruneとは？

git fetch

が、リモートリポジトリから最新情報を取ってくるコマンドで、--pruneオプションをつけることで、自動的にリモートリポジトリで消されたリポジトリを削除してから、ローカルリポジトリにも反映させてくれます。

ローカルリポジトリの作業ブランチにorigin/develop（開発用）ブランチをmergeする

現状、ローカルリポジトリには作業ブランチであるfeature/hoge_fugaと origin/developが存在しています。そして、origin/developはリモートリポジトリと結びついています。`

git fetch --prune

でorigin/developが最新情報になってますのでここで、

git merge origin/develop

コマンドを使う事によって、ローカル環境のfeature/hoge_fugaが最新の状態に更新されるということになります。

まとめ

スクールの教材などを行っていると、良い方向に誘導してくれますが、それだけではいけないと思ってます。自分の頭で考え、「これってどういうこと？」というのは今後も深堀りしていきたいと思います。もし今回のまとめが「ここ違うよ！」って点がありましたら教えていただけると嬉しいです。最後までお読みいただきありがとうございました。

参考文献

• リモートで消されたブランチが手元で残ってしまう件を解消する
• git fetchの理解からgit mergeとpullの役割

私は現在、オンラインプログラミングスクール「やんばるエキスパート」で、４人チームで共同開発を行っています。

開発現状

ブランチは開発用のdevelopブランチをメインとしており、自分で作業する時は、developブランチから新しい作業ブランチを切って作業しています（ここでは仮に feature/hoge_fuga とします）。そして、コンフリクトの解消時の注意点として、現在の開発ブランチにマージする手順をスクールの教材では、

git branch で作業ブランチにいることを確認後
git fetch --prune
git merge origin/develop

を行うように記載されており、「fetchってなに？」「--pruneってなに？」「merge origin/developって何で行うの？」と疑問になったので、自分で調べてまとめてみました。

git fetch --pruneとは？

git fetch

が、リモートリポジトリから最新情報を取ってくるコマンドで、--pruneオプションをつけることで、自動的にリモートリポジトリで消されたリポジトリを削除してから、ローカルリポジトリにも反映させてくれます。

ローカルリポジトリの作業ブランチにorigin/develop（開発用）ブランチをmergeする

現状、ローカルリポジトリには作業ブランチであるfeature/hoge_fugaと origin/developが存在しています。そして、origin/developはリモートリポジトリと結びついています。`

git fetch --prune

でorigin/developが最新情報になってますのでここで、

git merge origin/develop

コマンドを使う事によって、ローカル環境のfeature/hoge_fugaが最新の状態に更新されるということになります。

まとめ

スクールの教材などを行っていると、良い方向に誘導してくれますが、それだけではいけないと思ってます。自分の頭で考え、「これってどういうこと？」というのは今後も深堀りしていきたいと思います。もし今回のまとめが「ここ違うよ！」って点がありましたら教えていただけると嬉しいです。最後までお読みいただきありがとうございました。

参考文献

• リモートで消されたブランチが手元で残ってしまう件を解消する
• git fetchの理解からgit mergeとpullの役割

私は現在、オンラインプログラミングスクール「やんばるエキスパート」で、４人チームで共同開発を行っています。

開発現状

ブランチは開発用のdevelopブランチをメインとしており、自分で作業する時は、developブランチから新しい作業ブランチを切って作業しています（ここでは仮に feature/hoge_fuga とします）。そして、コンフリクトの発生時にスクールの教材では、

git branch で作業ブランチにいることを確認後
git fetch --prune
git merge origin/develop

を行うように記載されており、「fetchってなに？」「--pruneってなに？」「merge origin/developって何で行うの？」と疑問になったので、自分で調べてまとめてみました。

git fetch --pruneとは？

git fetch

が、リモートリポジトリから最新情報を取ってくるコマンドで、--pruneオプションをつけることで、自動的にリモートリポジトリで消されたリポジトリを削除してから、ローカルリポジトリにも反映させてくれます。

ローカルリポジトリの作業ブランチにorigin/develop（開発用）ブランチをmergeする

現状、ローカルリポジトリには作業ブランチであるfeature/hoge_fugaと origin/developが存在しています。そして、origin/developはリモートリポジトリと結びついています。`

git fetch --prune

でorigin/developが最新情報になってますのでここで、

git merge origin/develop

コマンドを使う事によって、ローカル環境のfeature/hoge_fugaが最新の状態に更新されるということになります。

まとめ

スクールの教材などを行っていると、良い方向に誘導してくれますが、それだけではいけないと思ってます。自分の頭で考え、「これってどういうこと？」というのは今後も深堀りしていきたいと思います。もし今回のまとめが「ここ違うよ！」って点がありましたら教えていただけると嬉しいです。最後までお読みいただきありがとうございました。

参考文献

• リモートで消されたブランチが手元で残ってしまう件を解消する
• git fetchの理解からgit mergeとpullの役割