使い方その3

GitHubにはPull requestsの他にもたくさんの機能があります。ここではその機能を紹介したいと思います。

Issues

Issuesはプロジェクトやソースコードの課題を管理するための機能です。リポジトリごとに管理されています。

作り方
まずはリポジトリのIssuesページへ行き、「New Issue」を押すと作成ページが出てくるのでタイトルに課題の内容を簡単に書き、コメントに詳細を書きます。最後に「Submit new Issue」でIssueの登録が完了します。

このIssueに対してコメントをすることもできます。
GitHubの便利なところはこのIssueに他のIssueやPull Requestとリンクしてくれる機能があり、見やすいように表示されます。

課題が解決したら「Close Issue」を押してクローズします。クローズしたIssueを一覧から確認することができます。

Issueには他にも便利な機能があります。以下がその一覧です。

• Assignee機能
• Milestone機能
• Label機能

Assignee

これはIssueに担当者を定める機能です。Issueのサイドバーの「Assignee」からユーザーを選択することができます。

これを定めることにより誰がどのくらいタスクを抱えているかがわかり、担当者がしっかり通知を受け取ることができます。

Milestone

これを使うことによって、機能単位の予定日やリリース日の予定日などのスケジュールを設定することができます。
これはIssueごとに期限を設けるのではなく、先にMilestoneを作成してそこにIssueを紐付けします。

Issuesのページから「Milestones」を選択し、「New milestone」から作成します。タイトル、期限、詳細を入力し「Create milestone」を押せば作成されます。
その後、各Issueのサイドバーからそれに対応させたいMilestoneを選択することで完了になります。

一覧からIssueの内容、何％クローズされたかという進捗を見ることができます。

Label

これは増えたIssueにラベル付けをし分類、整理できる機能になります。

これもIssueのサイドバーから選択することができます。
ラベルはデフォルトでいくつか種類がある(bug, puestion, etc...)ので足りない場合は追加していくといいでしょう。

ラベルは複数選択が可能で、一覧からフィルタリングをすることもできます。

Projects

Projectsは簡単に言うとかんばん方式のタスク管理機能です。
これを使用することによって「今どんなタスクが進行しているか」「タスクがどんな状態にあるか」などを確認することができます。

Projectsは「project」「column」「card」から構成されていて、projectの中にcolumn、columnの中にcardを追加することができます。いずれも複数作成することができます。

作り方
まずはprojectを作成します。リポジトリのProjectsから「Create a project」、すでにある場合には「New project」を押して、プロジェクトの名前、説明を書いて「Save project」を押して作成完了です。

次にcolumnは「Add column」から名前をつけて作成します。
columnの「＋」ボタンからcardを作成します。

cardはドラッグ＆ドロップで各columnへ移動させることができます。

例えば、「To do」「Done」という２つのcolumnを作成します。
その後「ユーザー登録機能をつける」や「ログイン機能をつける」などのcardを作り、「To do」のところに置きます。cardの作業が終わったら「Done」にドラッグ＆ドロップします。
これにより今何をすればいいかや、どのタスクが終了しているかなどをひと目で見ることができます。

また、IssueやPull Requestをcardとして追加することができます。
projectのページから「Add cards」を押すとIssue, Pull Requestが表示されるので、それを対応するcolumnにドラッグ＆ドロップして追加することができます。

Wiki

これはその名の通りリポジトリ内のwiki機能です。
GitHub公式ではプロジェクトの利用方法、設計方法、中核的な原理などプロジェクトに関する長いコンテンツを共有するために利用すると説明されています。READMEでは手短にプロジェクト内容を述べていますが、これを使えば追加のドキュメンテーションを提供できます。

使い方
リポジトリのWikiページへ行き「Create the first page」すでにある場合は「New Page」から作成することができます。

記述形式を9種類(Markdown, Mediawiki, etc...)から選択できます。
その他ページの追加や、特殊ページを追加することができます。

特殊ページ
・Home : wikiを開いた時のTopページ。(タイトルを変更すると通常のページになるので注意)
・Sidebar : 常にwikiの横に表示されるページ。目次などで便利。
・Footer : 常に下に表示されるページ。

使い方その2

ここではチーム開発をする上で必要なコマンドや、GitHubの機能を紹介します。

ブランチ

$ git branch
を打つことによって、現在のブランチを確認することができます。
$ git branch -a
を打つと全てのブランチを確認することができます。

Gitにはブランチルールがあります。これに沿って開発を行うことにより、スムーズにチーム開発を行うことができます。
ブランチを以下のように想定します。
masterブランチ:リリースした時点のソースコードを管理するブランチ(安定しているコードを置く)
developブランチ:開発作業中のブランチ

$ git checkout -b [ブランチ名]
で、ブランチの作成と切り替えができます。

ここでGitバージョン2.23.0で、git checkoutにあまりにもできることが多いため、役割を明確に分けるためにgit switchコマンドとgit restoreコマンドが追加されたので、このページの最後で紹介します。

頻出コマンド

$ git log
これを行うとコミット履歴の閲覧ができます。

$ git status -s
これは各ファイルの状態を確認するコマンドです。
以下は実行したときに出力されるものの意味です。
M:変更
A:追加
D:削除
R:ファイル名の変更
??:Git管理していないファイル

$ git fetch
Gitの最新状態を取得するコマンドです。
あるメンバーがpushすることによってそのメンバーのみが最新の状態にある時、他のメンバーがこのコマンドを使用することによってリモートリポジトリの変更点を反映することができます。

Pull Request, Merge

Pull Requestは簡単に言うと、開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。これには以下のような機能があります。

• 機能追加や改修などの作業内容を他開発者に通知
• ソースコードの変更箇所を分かりやすく表示
• ソースコードに関するコミュニケーションの場の提供

これを行うことによって、バグが起こりにくくなります。
これはある作業が終わって、pushした後に行います。

Mergeとは簡単に言うと、ブランチを合流させることです。
以前、ブランチをパラレルワールドを作成して、のちに元の世界に収束させることもできると表現しましたが、Mergeは収束させるというところに当たります。

例えば、developを変更してその内容をmasterに反映させたい！と言う時にMergeを使います。

ちなみに、pull = fetch + mergeといった感じになります。
つまりpullする必要はないということになります。
fetchとmergeを行うことによって、よりミスなどがなくなるようにpullと同じ作業が行えます。

ここで、チーム開発をしていて同じファイルを違うブランチで編集している時にMergeさせようとすると不具合が起きてしまいます。
これを「コンフリクト」といいます。日本語で「衝突」「不一致」という意味になります。
このコンフリクトを解決するのにGitHubを用いるととても効率よく行うことができます。

やり方

これはGitHubの機能なのでまずはリモートの方で行います。

• リモートリポジトリのページへ行き、「Compare & pull request」を押します。
• Open a pull requestの下の部分を「変更内容を反映させたいブランチ」←「内容を変更したブランチ」となるようにする。
• pull requestのタイトルと説明を入力します。
• 「Create pull request」を押します。これでpull requestの作成が完了しました。
• Pull requestsのページへ行きます。
• コンフリクトが起こった場合は「Resolve conflicts」を押します。すると、

<<<<<<< [内容を変更したブランチ]
[[内容を変更したブランチ]の変更内容]
=======
[[変更内容を反映させたいブランチ]の変更内容]
>>>>>>> [変更内容を反映させたいブランチ]

といったようにお互いの変更内容が表示されます。

• 上記の部分を直接書き直します。書き直したら、右上の「Mark as resolved」を押します。この作業をコンフリクトが起こったファイルの分だけ行います。
• 全て書き直したら「commit merge」を押します。
• 「Merge pull request」を押します。
• 「Confirm merge」を押します。(コンフリクトが起こらなかった場合はこの工程までそのまま行きます。)
• 完了したらいらなくなったブランチを「Delete branch」で消します。 これで、リモートでの作業が完了しました。

次に、ローカルに反映させます。
$ git fetch
$ git merge origin/[変更内容を反映させたいブランチ]
その後、いらなくなったブランチを消します。
$ git checkout -d [ブランチ名]

これで全て完了です。

switch, restore

さっきも言った通り、Gitバージョン2.23.0でgit checkoutにあまりにもできることが多いため、役割を明確に分けるためにgit switchコマンドとgit restoreコマンドが追加されました。

以下のように使います。
ブランチの変更はgit switch
ファイルの変更はgit restore
で行えます。今までどうりgit checkoutも使うことができますが、バージョンが2.23.0以降の人はswitch, restoreを積極的に使っていきましょう。
以下は使用例です。

switch

ブランチの切り替え
$ git checkout [ブランチ名]
$ git switch [ブランチ名]

ブランチを新規作成して切り替え
$ git checkout -b [ブランチ名]
$ git switch -c [ブランチ名]

restore

ファイルの変更を取り消す
$ git checkout -- [ファイル名]
$ git restore [ファイル名]

特定ファイルを特定のコミットの状態にする
$ git checkout [コミットid等] -- [ファイル名]
$ git restore --source [コミットid等] [ファイル名]

などなどです。他にもいろんなコマンドがあるので調べてみてください。

番外編

ここではリポジトリの作り方のときにスルーした、「README.md」と「.gitignore」について説明していきます。

README.md

READMEとはプロジェクトについての説明書みたいなものです。
その名の通り、俺を読めということです。これが重要な役割を担っていて、プロジェクトを公開した際にリポジトリを見て使ってくれるかどうかの第一歩はREADMEにかかっているといっても過言ではありません。

READMEには大きく分けて2つの役割があります。

• プロジェクトの使い方、インストール方法
• プロジェクトの宣伝

です。

READMEはローカルでもリモートでも編集できます。

README作成を始めに飛ばした人はGitHubのリポジトリのページへ行き「Add a README」から中身を書いて「Commit new file」で作成、もしくはローカルでRAEDME.mdというファイルを作り、add, commit, pushすれば完了です。

.gitignore

.gitignoreとはGitリポジトリにおいて、意図的に追跡対象から外したい(無視したい)ファイルを設定するためのファイルです。
例えばどのようなファイルが追跡対象かというと、ビルドファイルやドキュメント、アプリケーションのリソース(画像など)、テストコードなどです。

書き方(ファイルの中身)
特定の拡張子を無視する場合は
*.[任意の拡張子]
特定のファイルを無視する場合は
/[任意のファイル名]
特定のディレクトリを無視する場合は
/[任意のディレクトリ]/
などなどです。

#でコメントアウトできるので説明などを書くと良いでしょう。

続き

使い方その3(Git,GitHub資料5)

使い方その1

ここでは、知らないと何もできないレベルの最も基本的なことを書いています。

リポジトリの作り方

まずはGitHub側で新しいリポジトリ(リモート)を作成します。

• GitHubの自分のアカウントのrepositoryへ行き、右上の「New」を選択します。
• Repository nameを入力します。何をするか分かりやすい名前にしましょう。
• Descriptionにはリポジトリの説明を入力します。ここは任意です。
• Public/Private公開したくない場合はPrivateを選択しますが、有償契約をしてない場合はpublicになります。
• Initialize this repository with a READMEはREADMEを作成するかどうかを選択します。後から作れるため未チェックでも構いません。
• Add.gitignoreでgitで無視するファイルを指定するファイルを加えるかどうかを選択します。これも後から作れるため、Noneでも構いません。
• Add a licenseはライセンス設定を加えるかを選択します。これもこれも後から作れるためNoneで構いません。
• 「Create repository」を押したら完成です。

次にローカル側でリポジトリ(ローカル)を作成します。すでにgitで管理したいローカルリポジトリがある場合は飛ばして大丈夫です。
以下のコマンドでリポジトリを作成します。
$ mkdir [リポジトリ名]

最後にローカルリポジトリをリモートリポジトリへ反映させます。以下はその流れです。

まずは作成したローカルリポジトリに移動します。
$ cd [ローカルリポジトリ名]
そして以下のコマンドを入力して、ローカルリポジトリをGitリポジトリに変換します。
$ git init

次にローカルリポジトリのファイルをインデックスに追加、コミットします。
$ git add .
$ git commit -m “first commit”

そして、GitHubのリモートリポジトリ情報を追加します。
まずはGitHubの作成したリポジトリに行き、「Clone or download」を押し、そこからリポジトリ情報をコピーします。
この時、SSH接続した場合は、「Clone with SSH」になっているかチェックしましょう。なっていない場合は「Use SSH」を押します。
していない場合はSSHがHTTPSになります。
その後以下のコマンドを打ちます。
$ git remote add origin [コピーしたリンク]

最後に以下のコマンドを入力します。
$ git push -u origin master
リモートリポジトリのほうで確認してきちんと反映されていれば完了です。

既存のリポジトリを導入

導入したいGitHubのリポジトリに行き、「Clone or download」を押し、そこからリポジトリ情報をコピーします。
その後以下のコマンドを入力すれば完了です。
$ git clone [コピーしたリンク]

頻繁に使うコマンド

最も頻繁に使うコマンドです。これだけは知っておきましょう。

add, commit

基本的にGitリポジトリの内容を変更したら以下のコマンドを入力します。
$ git add [変更したファイル]
$ git commit -m "[コミットメッセージ]"
コミットメッセージは変更した内容の説明を書きます。
なるべく変更内容が分かりやすいように書きます。

これらの操作はゲームのセーブに似ています。これによって、いくつもセーブデータを作って好きな場所に戻したり、いらないデータを消したりなどに似た作業をすることができます。ですのでこまめにこの作業を行いましょう。

これらのコマンドには様々な使用例があるのでこのページの最後に書きます。

push, pull

コミットではローカルリポジトリにのみ反映されるので、pushによりリモートリポジトリのほうに反映させます。
$ git push origin [ブランチ名]
これは今いるブランチの変更をリモートリポジトリのブランチ([ブランチ名]のブランチ)にpushするコマンドになります。

pullはリモートリポジトリの内容をローカルリポジトリに反映させるコマンドです。
$ git pull origin [ブランチ名]
これはリモートリポジトリの[ブランチ名]ブランチの内容をローカルリポジトリの今いるブランチにpullするコマンドになります。

また、masterブランチにpush, pullするときには
$ git push
$ git pull
のみで行うことができます。

pushはadd, commitのように毎回する必要はありません。むしろpushすると後からcommitの修正をするのが大変になります。しかしいつまでもpushしないでいるとリモートリポジトリに反映されないままなので、良きタイミングで行いましょう。

pullは作業を始める前に一度しておくと良いでしょう。

もっと詳しい説明をページの最後に書いています。

その他の基本的なコマンド

一個前のコミットの状態に戻したいなというとき

$ git reset --hard HEAD
で最後にコミットしたときの状態に戻ります。

任意の変更を取り消したい時

$ git revert [HEAD or commitのid (などでcommitを指定)]
これを行うと指定したcommitが取り消されます。

ブランチについて

ここではブランチの作り方、切り替え方だけ書き、詳しいことは別のページに書きます。

$ git branch [任意のブランチ名]
これでブランチが出来上がりました。
$ git checkout [ブランチ名]
これによりブランチ移動ができます。

ブランチはまとまった作業を始める時に作成するようにしましょう。積極的にブランチを分ける癖をつけると、取り返しのつかないことになりにくいです

もっと詳しく

add, commit

ここでリポジトリを作るときにも出てきたadd, commitとは一体何なのかを説明します。
まずはaddですが、Gitにはインデックスという「どのファイルを管理対象にするか」を記録するエリアがあります。そこにファイルやフォルダを追加(add)するためのコマンドです。

そしてcommitとは、ディレクトリやファイルの追加・変更・削除等を記録したひとかたまりのことをいいます。
言い方を変えると、addでインデックスに追加された変更をログとして記録しているものです。

このcommitがとても重要です。commitするとcommitした時点の最新インデックスと、一つ前のcommitを比較し、変更点を記録します。commitを元に、過去のある時点の状態に戻すこともできます。commitにはメッセージをつけることができ、過去のcommitを見た時にどのような変更がされたのかをわかりやすくするために「定型的で簡潔」に書きます。

addの使用例
addの後に打つコマンドによってaddするものが変わります。
$ git add .
　今いるディレクトリ以下のすべてのファイル、ディレクトリをadd
$ git add -A
　リポジトリ全体のすべてのファイル、ディレクトリをadd
$ git add -u
　変更されたファイルをadd(新しく作ったファイルはaddされない)
$ git add *.[任意の拡張子]
　任意の拡張子のファイルすべてをadd
$ git add -n
　追加されるファイルを調べる
$ git rm --cached
　addしたファイルを除外

どのファイル、ディレクトリをaddしたいかを確認して使っていきましょう。

commitの使用例
$ git commit -m "[コミットメッセージ]"
　コメントをつけてcommit
$ git commit [ファイル名]
　特定のファイルのみをcommit
$ git commit .
　今いるディレクトリ以下のすべてのファイル、ディレクトリをcommit
$ git commit -a
　リポジトリ全体のすべてのファイル、ディレクトリをcommit
$ git commit --amend
　直前のcommitを取り消す

-mをつけないとエディタが起動してそこでコミットメッセージを入力しないといけないので、vimに慣れてない場合は-mをつけましょう。

他のコマンドと同時に使うこともできます。
例)

• $ git commit -m "[コミットメッセージ]" [ファイル名]
• $ git commit . -m "[コミットメッセージ]"

push, pull

ここではpush, pullのもう少し詳しい説明をします。
先ほどとりあえずでコマンドを覚えたと思いますが、originってなに？など思っていると思います。
実は
$ git push origin [ブランチ名]
をもっと詳しく書くと
$ git push [リモートサーバのURL] [ローカルのブランチ名]:[リモートのブランチ名]
となります。つまり、originとはリモートサーバの別名なのです。
リポジトリをつくったときに
$ git remote add origin [コピーしたリンク]
をしたと思います。
これはリモートサーバのURLに“origin”というニックネームをつける、というコマンドになります。これにより先程のコマンドがorigin(リモートサーバ)にpushするという意味になるということがわかったと思います。

次に[ローカルのブランチ名]:[リモートのブランチ名] の説明をします。これは名前の通り、ローカルの[ローカルのブランチ名]ブランチをリモートの[リモートのブランチ名]ブランチにpushするという意味になります。この時ローカルとリモートのブランチ名が同じならばそのブランチ名だけで指定することができるので、
$ git push origin [ブランチ名]
これだけで大丈夫ということになります。

ローカルの作業中に間違えて別のブランチでコミットしていた、という時に正しいリモートブランチにpushすることが可能になります。
この応用として以下はリモートブランチの削除コマンドとなります。
$ git push origin :[リモートのブランチ名]
なぜ削除になるのかというと、「何もないものをリモートのブランチにpushする」というコマンドになるので、「リモートブランチの削除」と同義になります。

また、リポジトリを作った時に
$ git push -u origin master
をしたと思います。この“-u”をすることによって、originとmasterがデフォルトになります。なので、masterにpushやpullするときには
$ git push
$ git pull
で大丈夫になります。

続き

使い方その2(Git, GitHub資料4)

前置き

gitのブランチ移動はエディタと連携したりSourcetreeのようなリッチなツールを試してみたりしている
gitのtab補完機能は勿論導入している

だがしかし、時にはコマンドラインでの作業中他のツールを開くのもめんどくさくてCLIでgit checkoutしたくなる時がある
というかしている

そして仕事で使うgitリポジトリはfeatureとかissue番号とかがprefixに含まれてるので、
tab補完が活かせるほどブランチ名覚えてないんですよね...
検索機能だからsearchとかブランチ名に入れた気がする...みたいなノリで移動したいの

忙しい人向け

~/.bashrcに下記のbash関数を書く
gc {ブランチ名}で過去にcheckoutしたブランチに部分一致で移動できます
例えばgc devでdevelopブランチに移動
一致したブランチが複数ある場合はヒットしたブランチ名を全て表示します
リモートにしか存在しないブランチは部分一致で移動できません(頑張ってカスタマイズすればできると思いますが)
よくわからない人はbash alias 設定でググってね

.bashrc

checkout_to_found_branch() {
  if [ $# == 1 ] ; then
    COUNT=`git branch | grep -c $1`
    if [ "$COUNT" = "1" ] ; then
      BRANCH=`git branch | grep $1`
      git checkout ${BRANCH##* }
    else
      git branch | grep $1
    fi
  fi
}
gc() {
  git checkout ${@:1} 2>/dev/null || checkout_to_found_branch ${@:1}
}

tab補完のアレに追記すればtab補完機能も有効にできます

/Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash

# __git_complete git __git_mainとか書いてあるあたりに
__git_complete gc _git_checkout

解説

うろ覚えのシェルスクリプトです、普段シェル書かないので...改善案は大歓迎です

1. bash関数を作成する

gc() {
  git checkout ${@:1} 2>/dev/null || checkout_to_found_branch ${@:1}
}

自作関数gc (git checkoutのaliasのつもり) に渡した引数をgit checkoutに渡します
${@:1}はシェルスクリプトにおける可変長引数なので、-bとかのオプションとかをどんな順番で渡しても問題なく動きます
2>/dev/nullは完全一致でブランチにヒットしなかった場合にエラーがターミナルに出力されないように殺しています

制御演算子||を用いて通常のgit checkoutに失敗した場合自作の関数checkout_to_found_branch ${@:1}を走らせます
つまり完全一致するブランチを指定したり -b オプションで新規にブランチを作成したりする分には、
純粋なgit checkoutのaliasとして機能します

自作の関数はその名の通り見つかったブランチにcheckout

checkout_to_found_branch() {
  if [ $# == 1 ] ; then # オプション引数込みで何かして死んだときに動かないように、引数がブランチ名単一の時だけ動かす
　　　　　　　　　　　　  # こんな保険は必要無いという豪の者は削除してif文のネストを減らそう 
    COUNT=`git branch | grep -c $1` # 部分一致するブランチ名をカウント

　　if [ "$COUNT" = "1" ] ; then　　 # カウント結果が一つの場合
      BRANCH=`git branch | grep $1`
      git checkout ${BRANCH##* }   # ヒットしたブランチにcheckout、
　　　　　　　　　　　　　　　　　　   # 現在のブランチと同じブランチに無駄にcheckoutしても死なないように
                                    # 検索結果の先頭に*があった場合は除外
    else
      git branch | grep $1 # カウント結果が複数ある場合一致したブランチ名を表示
    fi
  fi
}

意外とgit checkout 部分一致でググってもこれといった手法が出てこないので需要無いのだろうか...
取り敢えず自分が使う分にはこれで充分です、ブランチ切り替えでそんなに特殊な事しないので

GitHubのアカウント登録

まず、GitHubにアクセスします。

その後、GitHubに登録するを選択し、Username、Email、Passwordを入力してサインアップします。進めていくと入力フォームが表示されますが何も入力しなくても大丈夫です。

その後、登録したメールアドレスにメールが届くので、「Verify email address」をクリックしてアカウントが登録されます。

Gitをインストール

GitHubに登録したら次はパソコンにGitをインストールします。ここでは、Linuxのインストール方法を紹介します。

まずはターミナルを開いて以下のコマンドを入力します。
$ sudo apt-get install git
インストールされたか確認をします。
以下のコマンドを入力してバージョンが表示されていれば大丈夫です。
$ dpkg -l git

次にGitの初期設定を行います。
以下のコマンドを入力して初期設定を行います。
$ git config --global user.name "[設定したユーザーネーム]"
$ git config --global user.email "[設定したメールアドレス]"

次にエディタをVimに設定します。
コミットログを書くときにUbuntuのデフォルトだとnanoに設定されてしまうのでこれをVimに修正します。
$ git config --global core.editor 'vim -c "set fenc=utf-8"'

これで完了です。

GitHubでSSH接続をする

これを行うと、pushやpullの時にパスワード入力する手間が省けます。
必ずやることではないですが、やっておくと便利です。

まずは秘密鍵、公開鍵を作成します。
鍵を入れるフォルダに移動します。
$ cd ~/.ssh
次のコマンドで鍵を生成します。
$ ssh-keygen -t rsa
何か聞かれたらエンターを三回押せばid_rsaとid_rsa.pubの２つの鍵が生成されます。

次に公開鍵をGitHubにアップします。
https://github.com/settings/ssh
から公開鍵の設定ができます。
開いたら画面右上の「New SSH key」を押します。
「title」に公開鍵名(自分の名前とかなんでも)、「key」に公開鍵の中身を入れます。
公開鍵の中身については、以下の操作をします。
$ cat id_rsa.pub
これを実行すると公開鍵の中身が出力されるので、マウスで全て選択して、Shift + Ctrl + c でコピー(ターミナルではコピー等のショートカットキーが少し違うので注意)します。コピーが完了したら「key」の欄にCtrl + v で貼り付けし、「Add key」を押すとパスワードを求められるので入力します。

接続が完了したか確かめます。以下のコマンドを入力します。
$ ssh -T git@github.com
そして「Hi (account名)! You've successfully authenticated, but GitHub does not provide shell access.」と返ってきたら接続完了です。

続き

使い方その1(Git,GitHub資料3)

はじめに

プロ研216はGitHubを使っています。しかし、Git, GitHubとはそもそも何なのかを知らない人もいると思うので、資料にまとめます。

Git, GitHubとは？

Git

Gitとはプログラムのソースコードなどの変更内容を記録・追跡するための分散型バージョン管理システムです。

Gitでは各ユーザーのワーキングディレクトリに、全履歴を含んだリポジトリ(作業場)の完全な複製が作られるので、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができます。

例えば、プログラミングをしていると日々ファイルの中身は変わっていきます。この変遷の履歴を管理し、必要に応じて前のものに戻したり、途中で枝分かれして別の変更を加えたりするためのシステムです。

かんたんに言うと、オフラインでもプログラムの編集などができ、その変更履歴も管理できるシステムです。

GitHub

GitHubとは、このGitの仕組みを利用して、世界中の人たちがプログラムコードやデザインデータなどを保存できるウェブサービスです。

GitHubは様々なプロジェクトのためにGitのリポジトリをホスティングできるサービスです。Gitは基本的にコマンドラインツールですが、
GitHubはWeb上で扱うことができます。

なぜGitHubを使うのか？

GitHubにはたくさんの便利な機能があります。プロジェクトのバグ管理に使えるIssuesや、コードレビューを効率化できるPull Requestなどのチーム開発に役立つ機能がWeb上から使えるようになります。
その他にも、チーム開発で一番大変なコード統合をGitの機能を使うことによって自動的にしてくれるので、開発効率が上がります。

コードレビューでは、指摘と対象のコードがひと目で分かるようになり、バグ修正や機能追加がどの時点のバージョンで実装されたのかも一目瞭然になります。

要するにチーム開発やコード管理などにおいて便利なので入れたほうがいいよ、ということです。

P.S.

Git, GitHubは使えば使うほどわかっていくと思うので、今はよくわからなくても全然大丈夫です。
たくさんコードを書いて使っていきましょう。

予備知識

これから記事を読み進める時に必要な情報を書いておきます。
分からないときはここを見ましょう。

SSH

SSH(secure shell)とはネットワークを経由してマシンを遠隔操作する仕組みのことで、通信が暗号化されているのが特徴的です。
主にクライアント(ローカル)からサーバー(リモート)に接続する時に使われます。

仕組みを見ていく上で重要になるのが秘密鍵と公開鍵です。
まずはクライアントのマシンで秘密鍵と公開鍵を作り公開鍵をサーバーに渡します。サーバー側はその公開鍵を使ってユーザーを特定し紐付けを行っていきます。
ちなみに、秘密鍵は自分で管理して必ず見せてはいけません。

SSH接続を行うことによって安全にサーバーへ接続し、操作することができます。

ブランチ

ブランチとは、1つのプロジェクトから分岐させることにより、プロジェクト本体に影響を与えずに開発を行える機能のことを言います。
イメージとしてはパラレルワールドを作成して、のちに元の世界に収束させることもできる、という感じです。
リポジトリを作るとmasterというブランチが作成されます。
個人開発でも使うことはありますが、チーム開発ではほぼ確実に使うと思うので知っておきましょう。

リポジトリ

リポジトリ(repository)は保管場所のようなもので、中身はドキュメントファイルだったり、設定ファイルだったり、プログラムそのものだったり、いろいろです。
リポジトリは以下の2種類があります。

リモートリポジトリ

リモートリポジトリはパブリックな場所でみんなで共有するものです。
これ自体は樹木に例えられることが多く(実際にツリー構造をしている)、masterと呼ばれる幹に安定したコードを置いておき、そこからブランチを生やしていきます。

ローカルリポジトリ

ローカルリポジトリはプライベートな場所で、ユーザ一人ひとりが利用するために自分の手元のマシン上に管理するリポジトリのことです。
ローカルリポジトリで編集した内容をリモートリポジトリにアップロードすることができます。

続き

インストール、初期設定(Git, GitHub資料2)

初心者はターミナル以外のエディタの使い方がわからないのである。というか、「ターミナルがなんか違う感じになった！」くらいしかわからないのでエディタが変わったこともよくわからない。
そんな過去の自分が幾度となく泣かされたので、この通りにすればとりあえず何とかなる、というのを書いておきます。

閉じ込められてしまった！

体感として、一番多かったのは$ git commit --amendではないかなと思います。
このコミットをさっきコミットした分に含めたい、というときに使うコマンドです。
--no-editというオプションを付ければ、勝手にエディタが開くことはありません。が、コミットメッセージを変更したいときもあります。オプションを付け忘れることもあります。

特に変更しない場合

^X（control + X）を押せば、無事エディタを閉じてコミットできます。
エディタで特に操作をしなくても、ちゃんとコミットは統合されています。

コミットメッセージなどを変更する場合

このように変更した状態で^Xを押すとSave modified buffer (ANSWERING "No" WILL DESTROY CHANGES) ?と確認されます。

変更を保存したいので、Yを押す。

この画面に戻るので、そのままエンターキーを押せば、変更を保存してエディタから脱出できます。

または、^O(control + O)で保存する。

このような画面が出るのでエンターキー。その後^Xでも脱出可能です。

Qiitaでトレンド入りしていた下記の記事を読んで
循環的複雑度を可視化し、強制的に改善させるにLaravelにphpmdを導入しました

プログラムの可読性を上げるための条件分岐を減らす方法7個
循環的複雑度について

phpmdのinstall

composer.jsonにphpmd/phpmdを追加する

composer.json

    "require-dev": {
        "phpmd/phpmd": "*"
    },

$ composer update

インストールが完了しました。

次にphpmdのルールファイル作成します

phpmd.xml

<?xml version="1.0"?>
<ruleset name="Custom_PHPMD">
    <description>Custom ruleset PHPMD</description>
    <rule ref="rulesets/codesize.xml" />
    <rule ref="rulesets/controversial.xml">
        <!-- 判定から除外: 変数名がキャメルケースかどうか -->
        <exclude name="CamelCasePropertyName" />
        <exclude name="CamelCaseParameterName" />
        <exclude name="CamelCaseVariableName" />
    </rule>
    <rule ref="rulesets/design.xml" />
    <rule ref="rulesets/unusedcode.xml" />
    <rule ref="rulesets/naming.xml">
        <!-- 判定から除外: 変数名の長さ -->
        <exclude name="LongVariable" />
    </rule>
</ruleset>

$ php vendor/phpmd/phpmd/src/bin/phpmd ファイル名 text phpmd.xml

とやれば実行できます

毎回このコマンドを書くのは面倒なので
まとめてartisanコマンドに追加しました。

artisanコマンド作成

$ php artisan make:command PhpmdCommand

app/Console/Commands/PhpmdCommand.php

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

class PhpmdCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'phpmd {file_path}';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'phpmd';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {
        $phpmd = base_path('vendor/phpmd/phpmd/src/bin/phpmd');
        echo shell_exec('php '.$phpmd.' '.$this->argument('file_path').' text 
 phpmd.xml');
    }
}

$ php artisan phpmd ファイル名
で毎回チェックできるようになりました。

でも修正ファイルを毎回手動で確認するのも面倒なので、
commitする際にチェックさせて、エラーがあったらcommitさせないようにしようと思います。
けっこうチェック厳しいですが、これなら絶対複雑度は下がりますよね。

git hookの設定

.git/hooks/pre-commit

.git/hooks/pre-commit

IS_ERROR=0
for file in `git diff --cached --name-only && git diff --name-only`
do
    echo $file
    ERROR_MSG=`php artisan phpmd $file`
    if  [ "$ERROR_MSG" != "" ]; then
        echo $ERROR_MSG
        IS_ERROR=1
    fi
done

if [ $IS_ERROR -eq 1 ]; then
    echo ""
    echo "Please resolve the error"
fi
exit $IS_ERROR

git commit するたびにエラーを指摘されて大変ですが、
命名規則の徹底や複雑度改善がされていい感じですね。
今後ほかのサイトにも導入してみようと思います

以下を参照して修正予定
phpmdのルール一覧
githooksのpre-pushを共有してレポジトリを健全に保つ

【Git】git branch -a - ローカル＆リモートブランチ一覧を表示する

git branch -a

ローカル＆リモートブランチ一覧を表示する

git

$ git branch -a

作業ブランチの履歴ずらっと出てきます
（まだブランチを切ったことがない人は少しだけ）

例：
*BRANCH_A,BRANCH_B,・・・,BRANCH_Z

BRANCH_Aにいる時

コマンド

git[command]

git branch -a

*ブランチの一覧がみれるコマンド

ログ

git[log]

  develop
* feature/BRANCH_A
  feature/BRANCH_B
  .
  .
  .
  feature/BRANCH_X

• 今いるブランチを表します。場合によっては色分けされている場合があります。 　↓　を押していくと進みます。

git[command]

git branch -a

これを押すと git[log] が表示されるので復帰の方法は、

git[log]

  develop
* feature/BRANCH_A
  feature/BRANCH_B
  .
  .
  .
  feature/BRANCH_X
:｜←カーソルがここにきてる状態

上記のカーソルがここにきてる状態で、キーボード「q」を押すとコマンドラインに戻ります。
戻れないって焦る前にここまで読んでね

関連記事

【Git】一覧 - Gitコマンドまとめ
【Git】git branch - ブランチの一覧表示
【Git】git branch [ブランチ名] - ブランチを作る
【Git】git branch -a - ローカル＆リモートブランチ一覧を表示する
【Git】git branch -d [ブランチ名] - ブランチを削除
【Git】git branch -r - リモートブランチ一覧を表示する

---

制作チーム：サンストライプ

http://sunstripe-main.jp/
(月１WEBコンテンツをリリースして便利な世の中を作っていくぞ！！ボランティアプログラマー/デザイナー/イラストレーター/その他クリエイター声優募集中！!)

地域情報 THEメディア

THE メディア 地域活性化をテーマに様々なリリース情報も含め、記事をお届けしてます！！
https://the.themedia.jp/

ゼロからはじめる演劇ワークショップ

多様化の時代に向けて他者理解を鍛える

https://workshop.themedia.jp/

プログラミングワークショップ・ウェブ塾の開講！！！

様々なテーマでプログラミングに囚われずに取り組んでいきます。
詳しくはこちら　↓　↓　↓　↓　↓　↓　↓　↓
プログラミングサロン 月１だけのプログラミング学習塾

協力応援 / 支援者の集い

トラストヒューマン

http://trusthuman.co.jp/
私たちは何よりも信頼､人と考えてます｡

｢コンサルティング｣と｢クリエイティブ｣の両角度から｢人材戦略パートナー｣としてトータル的にサポートします！！

※使用環境:Windows10, Cloud9, GitHub

railsチュートリアルをCloud9上で進めるうえで必須なコマンドをまとめました。

新規アプリの場合

①ターミナル上でcdコマンドを用いて保存したいフォルダ階層に移動する(例はsample_appを保存したい場合)

$ cd Cloud9User:~/environment/sample_app

②git initでセットアップ

リポジトリ作成に必要な作業

$ git init

③git add -A

ステージングで変更したファイルを選択する。
-Aで現在のディレクトリのファイル全て選択できる。

$ git add -A

例えばREADME.mdのみ変更した場合はgit add README.mdとすればよい

④git commit -m "変更コメント"

-mコマンドでメッセージを挿入

$ git commit -m "変更コメント"

⑤GitHub上でリポジトリ作成

GitHubアカウント登録が必要です。（無料）
ログインして右上のアイコンをクリックして"Your repository"をクリックします。
"New"を選択し、"Repository name"にアプリ名（例の場合はsample_app）にして"Create repository"をクリックします。

⑥GitHubをリポジトリのoriginとする

git remote add origin https://github.com/(gitHubユーザー名)/(リポジトリ名).git

⑦ステージングで選択したフォルダ（ファイル）をプッシュする

以下のコマンドを入力します。
ユーザー名とパスワードが要求される場合があるのでGitHubのユーザー名とパスワードを入力します。（パスワード入力の文字は表示されないので注意）

$ git push -u origin --all

途中から始める場合

ブランチ(branch、分岐)を利用すると途中で戻りたくなった場合に復元できます。

branch作成

$ git checkout -b (baranch名)

branch確認

$git branch
  master
* modify-README

*は現在使用しているブランチになります。

Merge（マージ）

ファイル変更が終わってmasterに変更内容を反映させたい場合、Mergeを行います。
変更内容がわかるようにまずcommitでコメントを残してからmergeするとよいでしょう。

$ git commit -a -m "変更内容コメント"
$ git checkout master
Switched to branch 'master'
$ git merge (branch名)

変更内容を確認

git statusで現状の変更内容を確認できます。
git logでコミットメッセージの履歴を確認できます。

前のbranchに戻りたい場合

$ git branch
* master
  modify-README

の状態で

$ git checkout modify-README
Switched to branch 'modify-README'

となるが

$ git checkout -
Switched to branch 'master'

とするとブランチを切り替える前の状態に切り替えられる。

クラウドIDE上でHerokuをインストールするコマンド

$ source <(curl -sL https://cdn.learnenough.com/heroku_install)

SVNが使いにくい・・・

現在、お仕事でSVNを使用しているのですがgitに比べるとやはり使いにくい。
特にローカルコミットができずに変更点をそのまま抱えておくのがすごく面倒くさいです。
というより1回間違ったファイルをコミットして嫌気が差したのでgit化できないかと調べてみたらたくさん出てきました。

というわけでやってみます。

Gitリポジトリを作る

Gitリポジトリ用のディレクトリを作成した後、SVNリポジトリからGitリポジトリを作ります。

git svn init -s --prefix=svn/ http://hogehoge.com/svn
git svn fetch

リビジョンが多いと数時間はかかるので時間がある時や放置できそうなタイミングでやるのが良いと思います。
僕の環境では何も起きずに終わりましたがエラーが発生したらリビジョンを指定してfetchするのが必要になるみたいです。
正直ここまで出来たらほぼ終わったようなものです。

ブランチを切る

この辺から通常のgit操作とほとんど変わらないです（コマンドが若干違うくらい）。
GitリポジトリのmasterブランチがSVNのtrunkになります。

masterからbranch作成

git checkout master
git branch hogehoge
git checkout hogehoge

SVNリポジトリの変更を取り込む

masterブランチにSVNの変更点を取り込む場合、svn rebaseをします（gitにおけるpullみたいな感じ）。

git checkout master
git svn rebase

この時、ローカルに変更点があると次のエラーログが出ます。

update-index –refresh: command returned error: 1

この状態になったらstashかresetしてからsvn rebaseしましょう。

切ったブランチにmasterブランチの変更を適応したい場合はmargeします。

git checkout master
git svn rebase
git checkout hogehoge
git marge master

SVNリポジトリにコミットする

masterブランチにcommit後、svn dcommitでSVNリポジトリにコミットすることができます（gitにおけるpushみたいな感じ）。
SVNリポジトリには「gitからコミットされた」みたいな余計な情報は付加されないので素直にコミットして大丈夫です。

git commit -m "こみっとこめんと"
git svn dcommit

おしまい

これでSVNリポジトリをgit環境で開発することができます。やはりローカルブランチを切れるのは良い！
普段はVSCodeで開発をしており、GitLensをずっと使いたいと思っていたのでこれから捗りそうです。
構築にちょっと時間はかかりますが「SVNがヤダ！」って言う人はやってみる価値はあると思います。

何かあったらコメントください。

参考

interprism's blog 現場がSubversionでつらい貴方へ…自分だけこっそりGitで開発する方法
のぶろぐ git-svnを使った開発の手順
Qiita:git-svnでSVN→Gitへの移行をやってみたログ

はじめに

コミットにチケット名入れるの自動化したので共有します。
たとえばこんな感じにします。

作業ブランチ
feature/issue/#9

コミットメッセージ
xxxの実装

↓コミット

コミット名
[#9] xxxの実装

準備

コミットにブランチ名を入れるために、git-hook機能を使います。
以下のコマンド実行してcommit-msgというファイルを作成します。

$ touch <repo>/.git/hooks/commit-msg
$ chmod +x <repo>/.git/hooks/commit-msg

commit-msgファイル編集
スラッシュ区切りの最後の文字列を入れてるだけです。
アンダーバーとかに変更したい場合は任意に変更してください。

#!/usr/bin/env ruby
message_file = ARGV[0]
message = File.read(message_file, :encoding => Encoding::UTF_8)
# remove prefix issue number like [#1234] from COMMIT_EDITMSG
message = message.sub(/^\[#[0-9A-Za-z_].*\]/, "")
# remove comment
message = message.gsub(/^#(?! ------------------------ >8 ------------------------).*\n|^\n/, "")
if message =~ /(?=\A)# ------------------------ >8 ------------------------\n/
  puts "An empty message aborts the commit."
  exit 1
end
# get last path of current branch
current_branch = `git branch | grep '*'`.chomp.sub('* ', '')
current_branch = current_branch[current_branch.rindex("/")+1 .. current_branch.length] # スラッシュ区切りにしてるが任意の文字に変えることも可能
# add [last path of current branch] to commit message
newmessage = "[#{current_branch}] #{message}" # コミットメッセージ作成
File.write(message_file, newmessage)

以上です

お初目にかかります。いえもとです。

初投稿は何がいいかと考えたら、gitのコマンドしかないと思い、コマンド一覧を書くことにしました。

私はチームの影響により基本gitを扱うときはターミナルで操作しています。

理由は2つ

1. githubのデスクトップ操作はわかりやすいが、時間がかかる。つまりはターミナル操作の方が早い。

自分の時間も、相手の時間も短縮できる！
時は金なり、短縮されたその時間、チリも積もれば馬鹿にはできない。

2. ターミナル操作は通のように感じられる。

キーボード操作の方が、打刻感が感じられやすい。

操作手順の一例

ローカルディレクトリ下のインデックス作成

git init

変更修正したファイルをインデックスへ追加

///ファイルを一つ一つ追加する場合
git add <file> 

///変更したファイルをすべて追加する場合
git add .

コミットしよう。
インデックスに格納されているファイル群を1セットとしてバージョン記録します。

///一行コメントでのコミット
git commit -m 'コミット名（日本語もいけます）'

///なんだったらもっと詳細に書きたい！以下で、
got commit

これでバージョンは記録できます。

リモートデポジトリは後日更新します。