現在作業しているブランチのPRが既に作られている場合、そのPRをブラウザで開く関数です。

依存

• hubコマンド
• openコマンド

function pr-open {
    local url=$(hub pr list -h $(git symbolic-ref --short HEAD) -f "%U")
    if [ -z "$url" ]; then
        echo "The PR based this branch not found."
        return 1
    fi
    open $url
}

概要

この回ではVersion Controlを学ぶ。
Version Controlとは・・・
・その時々のversionを保存できる。
・前回保存した内容を復元できる
・違うバージョンの変化点を比較できる
・ほかの人と、コラボしやすい

具体的には下記２つを使ってVersion Controlを行っていく。
・Git・・・a Version control system
・GitHub・・・a code sharing and collaboration platform
これらを使う上ではUnixのコマンドラインのようなものを使用する。

コマンドラインインストラクションCommand Line Instructions@Udacity
コマンド集University of SURREY DEPARTMENT OF ELECTRICAL AND ELECTRONIC ENGINEERING UNIX Introduction：サリー大学

このコースでは下記の流れで進んでいく。
Lesson1: Version Controlを学び、Gitをインストールして、コードを見てみる。
Lesson2: Gitでコードを読んで書いてみる
Lesson3: コードをシェア＆ほかの人とコラボの仕方
今回はLesson1

ファイルの比較：コマンドプロンプトで

今まで動いていたのに、コーディングしていたら突然動かなくなった！ということがあった場合に、新・旧のコードを比較すると問題を容易に解決できる。ただ、人が行うのは骨が折れるので、コンピューターで行いたい。各OSのコマンドプロンプトに簡単なコマンドを入力して実現できる。比較したいファイルが置かれているディレクトリに移動して下記コマンドを実施。
Windows・・・FC old_file_name.py new_file_name.py
Mac/Linux・・・diff -u old_file_name.py new_file_name.py

比較したいファイルは.pyにした。FCはfile compareらしい。
違いが分かったら、コーディングで使っていたテキストエディタでコードをなおす。

このやり方だと、いろいろめんどくさいのでお勧めはGitを使うこと。

講義を受ける準備

Gitとテキストエディタのインストール・設定

＜準備0＞
Windowsユーザーなら通常のコマンドプロンプトは少し物足りないのでGitを入れよう。
どちらにしろ、このコースで後々インストールする。
Git Installation on Windows

＜準備1＞テキストエディタインストール・設定
Microsoft Word等ではなく、軽いテキストエディタPCにインストールし、コマンドプロンプトから起動できるようにしよう。
Setting up Sublime

この通りやってもうまくいかない。。。
まずはsublime_text.exeの保存先(パス)はもちろん違う。
いろいろやって解決したので、下記にやり方を。

cd ~
でホームディレクトリに移動。ここにある、.bash_profileというファイルをSublimeで開いて、一番下に、下記

alias subl='c:/"program Files"/"Sublime Text 3"/sublime_text.exe'

をコピペ。スペースがあるファイル名はクオーテーションで囲まないといけないみたい。

＜準備2＞コース専用「version-control」フォルダ・テキスト作成
GitBashから下記のコマンドを使って行う。#はコメントアウト。#より右はコンピューターに認識されない。

cd ~ # change directories to your home directory
mkdir version-control # make version-control directory
cd version-control # go to version-control directory
mkdir reflections # create reflections directory
cd reflections # go to reflections directory
subl lesson_1_reflections.txt # launch sublime with file called lesson_1_reflections.txt (you can replace subl with another editor here if you prefer a different one)

できたかどうかの確認のためには下記コマンドを実行

pwd # print working directory - shows what directory you are in
ls # list the files in this directory

これで準備は整った！

Git(GitBash)の使い方

日本語だとここがわかりやすかった。
WindowsでGitを始めたらまず確認！Git Bashの設定&ショートカット

コミットしたかったら、フォルダの一番上でgit initをまずはすること。
参照:Gitを使いこなすための20のコマンド

<コマンド>
git log
直近のcommit一覧が出る。それぞれにIDがついている。

git diff commitID1 commitID2
２つのcommitを比較する。

いつコミットすべきか

commitしまくるとlogが見づらくなる。かといって、変化点が大きすぎるcommitは何が変わったのかわかりづらい。
commitタイミングは、one commit per logical changeがベスト。
→typo修正は複数ではなく、1つ修正したらcommitしよう。

複数ファイルに関係するcommit

リポジトリに入っているファイルをすべてcommitすれば、複数ファイルで保存できる。
それぞれのcommitでどのファイルが変更されたかは、
git log --stat
で見れる。

リポジトリのクローン

サンプルリポジトリ"Asteroid game"のwebからのクローン

クローンをすると今までの変更履歴、つまり、すべてのコミットを含めてファイルをダウンロードできる。
git clone URL
今回はアステロイドゲームのリポジトリをクローンした。
Asteroids URL
Use the following url to clone the Asteroids repository: https://github.com/udacity/asteroids.git

git checkout：各コミット時の動作確認

ここまででコミット同士の比較をgit diffコマンドで行ってきた。
git checkoutコマンドでは、一時的に各コミット時点での、動作確認をすることができる。
例えばどのコミットでバグが発生したのかの後追いで使う。

上記のアステロイドゲームのリポジトリで、git checkoutを使ったバグ特定をやってみる。
アステロイドフォルダのidex.htmlをクロームで開くとアステロイドゲームが出てくる。
プレイし始めると、弾丸が間髪おかずに出てきていることが分かった。このバグがどこのコミットの時点で出てきたか探っていく。
1, git log #コミットログを見る。
2, git checkout commitID #コミットIDの時点のプログラムで実行

上記1,2を繰り返して、変な挙動をし始めたコミットを特定。
コミットIDが特定できたら、git diff commitID(変な挙動) commitID(その前)
でどの部分が変わったかを特定する。

GitBashの設定

自分好みにいろいろカスタマイズできる。
・背景色の変更
→GitBash開いて、右クリックのOptionsを選んでBackgroundで変えられる。
・tabキーを押したら、残りのコマンドを入れてくれる
→PCごとに設定しないといけないのは不便なのでやめた。
・GitBash上での現状の状態表示(現状のコミットID表示、*で変化点あり→コミット推奨)
→1, git-prompt.shをブラウザで開いて右クリックして保存。
2, 保存した場所から、ホームディレクトリにファイルを移動。
3, 下記コマンドをGitBashから実行

git config --global core.editor "'C:/Program Files/Sublime Text 2/sublime_text.exe' -n -w"
git config --global push.default upstream
git config --global merge.conflictstyle diff3

1行目のリンク先は、Sublimeのexe保存フォルダに書き換えること。
これで完成。

感想

結構時間がかかってしまった。特にsublimeのエイリアス設定で躓いた。。。

調べた英単語

restore・・・v, 復興する、再建する、修復する、復元する
terminology・・・adj, (特殊な)用語法、術語、(専門)用語
pros and cons・・・n, 賛成・反対(pro-：賛成, con-：反対contra-)
doable・・・adj, することのできる。
interrelated・・・adj, 相互に関係のある
proportional・・・adj, 釣り合った、均整のとれた、比例の、比例した、(…に)比例して
cohesive・・・adj, 密着する、結合力のある、凝集性の
configure・・・v, 形成する、設定する、設計する

はじめに

未来電子テクノロジー
でインターンをしています、Sotaです。
プログラミング初心者であるため、内容に誤りがあるかもしれません。
もし、誤りがあれば修正するのでどんどん指摘してください。

今回はgitの学びの導入について備忘録を残して行きます。
なお、勉強の途中ですので、最序盤のみになります。

gitとgithubの違い

gitを学ぶに当たって、はじめに思ったことはgitとgithubって何が違うの？ということでした。
めっちゃ要約するとgitがツールでgithubがgitを利用したサービスです。

gitを学ぼう

gitを勉強する上で使った教材でよかった物をメモしておきます。
Linuxの基礎知識がある上なら、
オライリーの実用git

gitit
https://github.com/jlord/git-it-electron#user-content-git-it-desktop-version
です。
gititで出てくる内容を実用git見ながら進めていくのがおすすめです。
gititが一通り終わったら、色々試しながら実践的に学ぶと良いと思います。

最後に

今回はこれだけです。
めっちゃ少ないですけど、gitは今やエンジニアとして必須の技能なのです。ブログで学ぶのも良いですけど、きちんとした教材で深い知識を身につけた方が良いと思います。

状況

Githubと連携したローカルリポジトリにおいて、誤ったコミットメッセージでコミットをしてしまい、しかもそれをリモート（Github）にpushしてしまった。
ローカルのコミットを修正する方法はわかっていたが、pushしてしまった以上、コミットやり直したところでリモートと差分が出てしまう…
なんてこったい。

準備

• ソースツリーではなく、ターミナルでやるべし。脱GUI。
• 独特な操作のvimを一瞬触る。心の準備を。
• 強制pushの際、リモートの接続パスワード（＝Githubのサインイン情報）求められる場合がある。事前に確認しておくこと。

手順

「まちがえたーーー」のコミットを消して、「うわーー」状態に戻したいとする。

1. リベース

$ git rebase -i HEAD~2

コマンドを叩くと以下のような画面になる。
これがvimに入った状態。
ターミナル初心者はその独特の操作法に焦りがち。（自分

コミットを消したいので、表示されている「Commands」の dropに該当する。
「d」を押して、「↓」を一度押すと、
以下のように「まちがえたーーー」コミットが消えた画面になる。

これでミッションは完了。
あとは保存してvimを閉じるだけ。

vimコマンド
:wq　保存して終了
:q!　保存せずに強制終了

いきなり「:wq」と打つだけで、下の方に入力される。
enterを押せば、いつものターミナル画面に戻る。

万が一変な操作をしてしまった気がする場合は「:q!」を打ってやり直そう。

ターミナル画面に戻って以下のメッセージが出ていればOK。（なぜかvimを保存せずに閉じたときも出る…？

Successfully rebased and updated refs/heads/master

リベース後にSourceTreeを見てみると、ローカルのgitが一つ巻き戻っている。

2. 強制push

あとはローカルの状態をリモートを合わせれば勝ち。

通常のpushを行おうとすると、エラーで弾かれる。

the tip of your current branch is behind

なので、秘技「強制的push」を発動。「f」はforceの「f」だね。

$ git push -f

以下のような画面になれば成功。

SourceTreeやGithubで確認してみると消えてる。強制pushすごい。

参考

さっきの取り消したい！って時のGitコマンドまとめ - Qiita
githubにgit pushした変更の取り消し - Hack Your Design!

GitLabにリポジトリを新規作成した際のGitコマンドの備忘録です。

Git のグローバル設定

git config --global user.name "Atelier-Mirai"
git config --global user.email "atelier-mirai@example.com"

新しいリポジトリを作成

git clone git@gitlab.com:Atelier-Mirai/new-repository.git
cd myapp
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

既存フォルダをプッシュ

cd existing_folder
git init
git remote add origin git@gitlab.com:Atelier-Mirai/new-repository.git
git add .
git commit -m "Initial commit"
git push -u origin master

既存のリポジトリをプッシュ

cd existing_repo
git remote rename origin old-origin
git remote add origin git@gitlab.com:Atelier-Mirai/new-repository.git
git push -u origin --all
git push -u origin --tags

前回までのあらすじ

• GitHubにユーザを登録した。
  • (No.1) おじさんが、Git・GitHubを利用できるようにしてみる - GitHubにユーザを登録する
• GitHubを利用してみた。
  • (No.2) おじさんが、Git・GitHubを利用できるようにしてみる - GitHubを利用してみる
    • Gitは、成果物（ファイル）の変更内容や履歴を管理する保管場所（リポジトリ）が必要だってわかったよ。
    • リポジトリは、特定の場所にだけ存在するものではなく、そのリポジトリを必要とする人のコンピュータ上に丸ごと複製する仕組みのようだよ。
    • 複製したリポジトリは、各々のコンピュータ上で好き勝手に育てることが出来るようだよ。
    • 成果物（ファイル）の編集後、編集内容や履歴をリポジトリに追加するには、次の手順が必要だったよ。
      • 成果物（ファイル）を編集する。
      • 編集した成果物（ファイル）のスナップショットを、Staging Areaに追加。（git add）
      • コミットする。(git commit)
    • おじさんの編集内容や履歴を保存したリポジトリを、他人に共有することが出来れば、結果的に、おじさんの成果物を共有したことになるよ。
      • リポジトリを共有する手段のひとつとして、GitHubがあるよ。
      • 前回、おじさんのコンピュータ上で作成したリポジトリの内容を、GitHubに反映することが出来たよ。(git push)

前回までの反省点

• おじさん、反省ばかりの人生だよ。
• おじさん、せっかちだから、説明書を読まずに作業しがちだよ。
  • ここ(Git Book)に、Gitに関する大切なことの多くが書かれていたよ。
  • 急がば回れって言葉、本当だったんだね・・・。
• 早速、心が折れそうになったよ。
• 難しい横文字がたくさん出てきて、混乱したよ。同じようなことを意味するのに、異なる単語が出てきたり・・・。
• 言葉にムラがあると、おじさんでもしんどいのに、読む人はもっとしんどいよね・・・。
  • おじさんのコンピュータ上のリポジトリを、ローカルリポジトリと呼ぶことにしたよ。
  • GitHubのような公開するリポジトリを、リモートリポジトリ、または、単にリポジトリと呼ぶことにしたよ。
  • おじさん、自分が嫌なことは人にもやってはいけないって言われて育ってきたんだ。すっかり忘れてたよ。
• おじさんは、いつか理解出来る日が来ると信じて、逃げないで頑張ってみるよ。

今回の目的

• 前回、おじさんはGitHubにリポジトリを作成して、おじさんのローカルリポジトリをGitHubのリポジトリに反映することが出来たよ。
• 今回は、おじさん以外の人でも、おじさんが作成したGitHubのリポジトリを複製（クローン）することが出来るか確認するよ。
  • おじさんの成果物を共有出来るようにすることが目的だよ。まだ何もないけどね（照）。

GitHubのリポジトリを、ローカルリポジトリに複製（クローン）する

• おじさんが作成したリポジトリは次のリンク先にあるよ。
  https://github.com/resojisan?tab=repositories
• Qiitaを書いている時点では、「test」という名前のリポジトリしかないけどね・・・
• さらにtestのリポジトリの中をみてみるよ。　　
• README.mdというファイルが一つだけ保管されたリポジトリだってことがわかるよ。
• 今回はこのリポジトリを、おじさんのコンピュータの適当な場所に複製（クローン）しようと思うんだ。
  • こんなダメなおじさんでも複製（クローン）することが出来るなら、他の人もおじさんと同じように複製（クローン）出来るってことだと思うんだ。

前提

• おじさんと同じことを試す場合は、前回までの手順のように、Gitをインストールしておく必要があるよ。
  (No.2) おじさんが、Git・GitHubを利用できるようにしてみる - GitHubを利用してみる
• 前回と同様にターミナルを使ってコマンドを入力するよ。

コマンドで、作業するフォルダ（ディレクトリ）の場所を変更するよ

• どこに複製（クローン）したのかわかってないと、おじさん混乱しちゃうからね。だから、テスト用のフォルダ（ディレクトリ）を作りたいんだよ。
• ターミナル上で次のコマンドを入力してエンターを押下してみて。（Windowsの場合はコマンドプロンプトって名前の似たものがあるらしいよ）
  • コマンド: cd ~
  • 結果: 作業中のフォルダ（ディレクトリ）を移動する。 ~（チルダ）を指定すると、移動先はホームディレクトリになる。
  • 解説: cdコマンドを使うと、ターミナルが作業するフォルダ（ディレクトリ）の場所を移動することが出来るんだよ。
    移動先の場所をcdコマンドの右側に指定するのだけど、今回は~（チルダ）って書いたよ。
    ~（チルダ）を指定すると、macOSにログインしているユーザの個人フォルダのような場所を意味するみたいだよ。このフォルダ（ディレクトリ）を、ホームディレクトリと呼ぶらしいよ。
    本当に移動したかどうかは、前回のpwdコマンドで確認してみるといいよ。（/Users/oyajiみたいに、表示されるはずだよ）

コマンドで、テスト用のフォルダ（ディレクトリ）を作成するよ

• ターミナル上で次のコマンドを入力してエンターを押下してみて。
  • コマンド: mkdir sutekinaoyaji
  • 結果: ターミナルの現在の作業場所に、「sutekinaoyaji」という名前のフォルダ（ディレクトリ）が作成されるよ。
  • 解説: 省略するよ。

作成したフォルダ（ディレクトリ）の中で実験するよ

• 前手順で作成したフォルダ（ディレクトリ）に作業場所を移動するよ。
• ターミナル上で次のコマンドを入力してエンターを押下してみて。
  • コマンド: cd ./sutekinaoyaji
  • 結果: sutekinaoyajiフォルダ（ディレクトリ）に作業場所が移動するよ。
  • 解説: cdコマンドで作業中のフォルダ（ディレクトリ）を移動するよ。「./」は、現在作業中の場所を表すよ。なので、現在作業中の場所にある「sutekinaoyaji」に移動する、との意味になるよ。今後も使うことがあるみたいだから、今回試しに書いてみたんだよ。

GitHubに戻って、複製（クローン）元リポジトリの場所を調べるよ

• https://github.com/resojisan/testにある「Clone or download」ボタン（緑のボタン）を押下するとわかるよ。
• 「https://github.com/resojisan/test.git」がリポジトリの場所を表す文字だよ。これは複製（クローン）するときに必要な情報だよ。
  

いよいよ、GitHub上のリポジトリを、複製（クローン）するよ！

• ドキドキするね。
• ターミナル上で次のコマンドを入力してエンターを押下してみて。
  • コマンド: git clone https://github.com/resojisan/test.git
  • 結果: 次のように表示され、ローカルリポジトリとして複製されるよ。
    Cloning into 'test'...
    remote: Enumerating objects: 3, done.
    remote: Counting objects: 100% (3/3), done.
    remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.
  • 解説: 「git clone」コマンドで、他所のリポジトリをローカルリポジトリに複製（クローン）することが出来るよ。「git clone」の右側には、複製元のリポジトリを表す場所を指定するよ。これは前手順でGitHub上で確認した情報のことだよ。
  • マニュアル: Getting a Git Repository

本当に複製出来ているのか、Finderでも確認してみる。

• Finderの「移動」メニューにある「フォルダへ移動」を選択。
• 「~/sutekinaoyaji」と入力して移動ボタンを押下。(ここでも~チルダが使えるんだよ)
• おお！ testフォルダと、README.mdがダウンロードされていることがわかるよ！
• でも、前回のおじさんの奮闘ぶりを見守ってくれている人からすると、「.git」フォルダ（ディレクトリ）がないことに気が付いたかもしれないね・・・。
  • .git directory: ローカルリポジトリそのもの。 他のリポジトリを複製（クローン）したならば作成されるはずだよね。
• 実際は「.git」は作成されているのだけど、フォルダ名の先頭に「.（ドット）」があると、Finderがみえないように隠してしまうからなんだ。
• Finder上で、[command] + [shift] + [.(ドット)]のキーを同時に押下すると、前述の隠されたファイルが表示されるようになるよ。（元に戻したい場合は、再度先程の3つのキーを同時に押下すれば良いよ）
• .git（ローカルリポジトリ）も作成されていることが確認出来たよ!!

あとがき

• 今回の手順で、おじさんがこれから作成する（はず）の成果物を、おじさん以外の人にも配ることが出来るようになったよ。
• 次回以降は、Gitに限定せずに、プログラミングに一歩近付くような作業をやってみたいと思うよ。
• 他の作業を進めていくなかで、Gitの使い方は記録していくことにするよ。

参照

• Git Book
• Git Reference
• Git Architecture
• ソフトウェア構成管理、SCM(software configuration management)
• バージョン管理システム
• リポジトリ
• Why GitHub? - Features
• https://git-scm.com
• https://ja.wikipedia.org/wiki/GitHub
• https://ja.wikipedia.org/wiki/Git
• コマンドラインインタプリタ

VimにかつてあったBorland C++対応コード

• 最近Vimに取り込まれた大規模パッチに関する備忘録

現在のWindows版Vimは、Visual C++とMinGWでビルドできるようになっていますが、かつてはBorland C++ 5.5でもできるようになっていました。しかし、Borlandを使う人がいなくなってしまい、いつの間にかビルドできなくなってしまっていました。Borland C++の後継としては、Embarcadero C++も公開されていますが、これに対応させようという人もいませんでした。そのため、Borland向けのコードをすべて削除することになりました。

• patch 8.1.1306: Borland support is outdated and doesn't work
  • https://github.com/vim/vim/commit/eae1b91fea74842000fc055afc74fe2e7934c6ee

過去の実装の除去

壊れた実装は不要なものである。正しい。

一方で、過去に誰かがした仕事を足掛かりとして、将来別の誰かが何かをすることもある。

Git上で消えた#ifdefは、その存在自体を最新版では気づかないことが多い。
Embarcadero C++で実装をしようとする人が現れた時は「ゼロ」からのスタートになる。
(今はC++ BuilderでClang（古いバージョン）も使えるようになっているので、そういう人が現れるか不明ではあるが）

Borland C++の実装（壊れているが）が残っていた場合、その情報を読み解き、「この部分を変更すればいいだろう」と作業が短縮されることもあるかもしれない。一方で、残ることでそれを使わない人にとっては「ソース可読性へ悪影響」でしかない。

難しいところ。

Neovim

上記のように、長い歴史を持つVimのコードの可読性や変更困難性を検討した結果生まれたプロジェクトがNeovimだと認識している。

https://neovim.io/

https://neovim.io/charter/

Neovim is a refactor, and sometimes redactor, in the tradition of Vim (which itself derives from Stevie). It is not a rewrite but a continuation and extension of Vim.

neovimはスクラッチからコードを実装する?(あるいは大規模なリファクタをする?)ことで、長い歴史を持つVimの複雑なコードをシンプルなものへと変えようとしている、と認識している。

neovimが今後どれくらい支持されるか不明であるが、そういう動きもある。

最近 git rebase -iがの便利な機能を知ったのでメモとして残します。

今の git logの状態

commit cd8a4309b4e196d3fc169f10b708197c48898346
Date:   Tue May 21 09:01:15 2019 +0900

    file modified

commit f9d702a3c0f6188c780609270da917aa174d858a
Date:   Tue May 21 08:59:14 2019 +0900

    modified file

commit 321f711dc4a590fd27721523d53a69353e9daf76
Date:   Tue May 21 08:58:42 2019 +0900

    created file

1つ目と2つ目のコミットをまとめたい。

git rebase -i HEAD~2

すると以下のようなvimが立ち上がります。

pick f9d702a modified file
pick cd8a430 file modified

ここで以下のようにすると

pick f9d702a modified file
s cd8a430 file modified

こんな感じでコミットメッセージを編集する画面が表示されます。

# This is a combination of 2 commits.
# This is the 1st commit message:

modified file

# This is the commit message #2:

file modified

しかし、こんな感じにすると

pick 0f1e189 modified file
f b470369 third commit

pickされたコミットのメッセージが残ります。
少しだけ時短