Git Git/SourceTree使用方法

個人での利用

ステージング
作業コピーの変更をインデックスに登録

全てインデックスに追加
git add .

指定ファイルをインデックスに追加
git add test.txt

コミット
ステージングされた作業コピーの変更をローカルブランチに登録

コミット
git commit -m “コメント”

ブランチ
現在のコミットからブランチを作成
ローカルブランチを複製

現在のコミットからTESTブランチを作成
git branch test

beforeブランチからafterブランチを作成
git branch after before

チェックアウト

過去/未来のコミットに移動
別ブランチのコミットに移動
→ 作業コピーのファイル状態は移動先のコミット状態に変更される

別ブランチのコミットに移動
git checkout paypal_sandbox

マージ
チェックアウトしているブランチへ別ブランチの変更を取り込む

更新されたリモート追跡ブランチを、現在のローカルブランチにマージする
git merge FETCH_HEAD

リセット
コミット状態を戻す
git reset (オプション) (戻す位置)

戻す対象

オプション HEAD インデックス 作業ツリー
–hard
–mixed
–soft

戻す位置

位置 機能
HEAD^ 直前のコミット
HEAD 現在のコミット

HEAD、インデックス、作業ツリーを戻す
git reset –hard ~

HEAD、インデックスを戻す
git reset –mixed ~

HEADを戻す
git reset –soft ~

HEAD^(直前のコミット)を戻す
git reset –hard HEAD^

コミット後の変更を戻す
git reset –hard HEAD

スタッシュ
作業コピーの変更を退避

チームでの利用

クローン
リモートブランチをローカルブランチとしてコピー

【手順】
「ファイル」メニュー > 「新規/クローンを作成する」

git clone https://github.com/ユーザ名/レポジトリ.git

フェッチ
リモートブランチの変更をリモート追跡ブランチに更新(1)
その後、リモート追跡ブランチの変更を作業コピーにマージ(2)する必要がある
PULLは(1)~(2)を同時実行する
リポジトリ:originのmasterブランチのコミットをリモート追跡ブランチに更新
git fetch origin master

プル
リモートブランチのコミットをローカルブランチに更新
リポジトリ名:originのmasterブランチのコミットをローカルブランチに更新
git pull origin master

レポジトリ名設定
git remote add 別名 https://github.com/ユーザ名/レポジトリ.git

【強制pull】
コンフリクトを無視してリモートに合わせる

フェッチ
git fetch origin master

②リモート追跡ブランチのorigin/masterまで戻す
git reset –hard origin/master

プッシュ
ローカルブランチのコミットをリモートブランチに更新
リポジトリ名:originへローカルのmasterブランチのコミットを更新
git push origin master

リポジトリ名:originのmasterブランチへ、ローカルのtestブランチのコミットを更新
git push origin test:master

Git GitHub Pages利用方法

リモートリポジトリ作成

https://github.com/office-yone/office-yone.github.io.git
末尾がgithub.io

リモートリポジトリと同期

git clone https://github.com/office-yone/office-yone.github.io.git targetdir

html作成

cd targetdir
echo "hello world" > index.html

ステージにアップロード、コミット

git add index.html
git commit -m "index.html"

リモートリポジトリにアップロード

リモートリポジトリをブックマーク登録
git remote add origin https://office-yone@github.com/office-yone/office-yone.github.io.git

プッシュ
git push origin master

htmlをブラウザで表示

http://office-yone.github.io/index.html

Git チームでの利用方法

git-hubとローカルリポジトリの関係


ブランチ

ブランチとは?

「枝」の意味
git_branch
master
デフォルトで作成されるブランチ
↑ 図で言うと灰色
複数のバージョンを管理したい場合、テスト的なバージョンを用意したい場合に応じて追加する。
ブランチは互いに影響を及ぼさず完全に別ファイル。
Gitを操作する際はどのブランチがカレントになっているか?を意識する必要がある。

ブランチ操作

ブランチ新規作成&ブランチ切り替え
$ git checkout -b (ブランチ名)
↑ 図で言うと黄色

Git Git/SourceTree使用方法」参照

リモートリポジトリ

複数人でバージョン管理を行う場合にローカル外に作成するリポジトリ
GitHubというインターネット上のリモートリポジトリを利用可能
使用量に応じて料金が掛かる

リモートリポジトリ操作

Git Git/SourceTree使用方法」参照

GitHub

SSH用認証暗号鍵の登録


2018/9/8現在の画面

サーバー証明書/SSH用認証暗号鍵」で生成した暗号を「Key欄」に貼り付け

Git 基本的な使い方

Gitとは?

(ギット)
CUIバージョン管理ツール
通常、ファイルを上書きすると過去のファイルは削除されファイルは最新の状態になるが、
バージョン管理ツールを使うと各保存時の状態まで戻せる。
有志で開発されているGUIの拡張バージョンもある
他のバージョン管理ツールとの比較
差分だけをサーバーにアップできる
Git Bash
windows用Git

コマンド一覧

コマンド 機能
--version バージョン表示
init ローカルリポジトリ作成
add (ファイル名) ステージにアップロード
commit -m (コメント) コミット
status ステータス表示
log ログ表示
branch ローカルブランチ一覧表示
branch --remotes リモートブランチ一覧表示
branch --all リモートブランチを含むブランチ一覧表示
branch (ブランチ名) ブランチ作成
branch --delete (ブランチ名) ブランチ削除
branch --delete --remotes (ブランチ名) リモートブランチ削除
remote add (ブックマーク名) (URL) ブックマーク登録
remote rm (ブックマーク名) ブックマーク削除
remote --v ブックマーク一覧表示
push (ブックマーク名) (ブランチ名) リモートリポジトリへアップロード
pull (ブックマーク名) (ブランチ名) リモートリポジトリからダウンロード
clone (URL) (ディレクトリ) リモートリポジトリを複製
config --list 設定情報表示

インストール

バージョン確認

$ git -v

インストール

CUI版のインストール
$ apt-get install git
GUI版のインストール
$ sudo apt-get install gitk
GUI版gitの起動
$ gitk

初期設定

ホームディレクトリのconfigファイルに設定値を入力
$ git config –global user.name (ユーザ名)
$ git config –global user.email (メールアドレス)

リポジトリ作成

リポジトリをローカルに作成
$ git init
リポジトリとは?

保存領域

リポジトリ

保管庫の意。
バージョン管理対象ファイル保管場所
(.gitディレクトリ)
$ git init
ではローカルに作成される。
=ローカルリポジトリ
複数人でファイルを共有する場合は別コンピュータにリポジトリを作成する。
=リモートリポジトリ
GitHubというインターネット上のリモートリポジトリを利用可能
使用量に応じて料金が掛かる
Git チームでの利用方法/リモートリポジトリ」参照

ステージ

コミット待ち記憶領域
ステージにあるファイルのみリポジトリへアップロードできる。
ローカル→ステージ→リポジトリ
=インデックスに登録する
とも呼ばれる
インデックス=ステージングされたファイルの状態

作業ツリー

=作業領域
=ワークスペース
=ワークツリー

ローカルにあるファイルのみステージへアップロードできる。
ローカル→ステージリポジトリ

HEAD

リポジトリの最新のコミット状態

アップロード・ダウンロード

インデックスに追加

ローカルファイルをステージにアップロードし、コミット対象に加える
$ git add ファイル名
カレントディレクトリの全ファイルをインデックスに追加(コミット対象に加える)
$ git add .

コミット

ステージファイルをリポジトリにアップロードする。
$ git commit -m (コメント)
コミット毎にコミット番号が付加され、この番号へのロールバックが可能になる。

ロールバック

コミット番号の状態へロールバック
コミット番号はログで取得できる。
$ git reset --hard (コミット番号)
特定のファイルのみ、コミット番号の状態へロールバック
$ git checkout (コミット番号) (ファイルパス)

ステージクリア

ステージ内ファイルを削除
git reset

状態確認

ステータス表示

$ git status -s
A 新規
M 編集
D 削除
U 競合
? バージョン管理外

コミット番号表示

ログ表示(コミット番号表示)
git log --oneline
git log --oneline (ファイル名)
コミット時のハッシュ値の前7桁の数値を取得できる。

履歴表示

$ git log
$ git log (ファイル名)

ローカル状態確認

git show-branch -a

現場主導によるITS導入

概要

DebLove関西主催の勉強会

実際に(株)島津製作所グループで実際に導入・実践され、
管理コスト、テスト工数、保守工数を削減した事例を紹介。
効率・品質・統制」の共通課題に着目した 現場主導によるITS導入の効果検証

ITS

IssueTrackingSystem
RedMine、TRec、JIRA等。
以下の機能を持つ管理ソフト
・プロジェクト管理機能
・タスク管理
・進捗管理
・ファイル管理
・Wiki機能
一つのタスクを登録した際に「チケット」を作成。
皆がそれを閲覧・編集できる。
タスクが解決した場合「クローズ」する。
タスクを検索する事で1つのタスクに関連する問題や解決方法を知ることができ、保守コストを低減できる。

バージョン管理システム

Subversion、GIT、VSS(MicrosoftVisualSauseSafe)等。
ソースコードやドキュメントの履歴ごと保存し、差異を抽出したり、過去バージョンへ戻す事が可能。
開発工数削減に大いに役立つ。

やり方

RedMine、Subversionを導入し、それを使用する管理ルールを設定。
多くの場合、個々が独自のやり方を貫く(ルールを守らない)事でこの手の管理は複雑化、失敗するが、
社内に嫌々強制するのではなく、社員にもメリットがある事を粘り強く説得・教育し、
社内ルールを文化として浸透させる事に成功。
管理コスト < 現場メリット

定着
(1)ファイルサーバー:ドキュメント類(全て電子化)
(2)SubVersion:ソースコード

RedMine:タスクに(1)、(2)を関連付ける。

有益な情報が全てタスクに関連付けられており、検索する事でそれをすぐに得られる為、
RedMineを利用する事で現場の開発・保守労力が大幅に低減されている。
管理ルールを守らないとそれを実現できない事を現場が完全に理解しているので
積極的・自発的にルールが守られる好循環が形成されている。

Subversion③ TortoiseSVN

概要

Windows上で動作するGUIベースのSubversion
フォルダ階層や状態を把握しやすい

アイコンの意味

一覧

svn1
オフィシャルサイトの説明

通常

InSubVersionIcon
リポジトリとローカルのファイルが一致している状態

変更

ModifiedIcon
リポジトリとローカルのファイルに差異がある状態
ローカルのファイルを変更している場合。
ローカルのファイルを開いているだけでもこのマークが表示される。

競合

ConflictIcon
複数ユーザーが同じファイルを同時に変更。
後でコミットした方がコミットできず、同じ行を同時に変更している為にマージもできない状態

競合の解決方法

流れ

svn4
svn5

マージ

・両者の編集箇所をマージする
・以下の様な競合箇所を示す文字列が自動的に挿入される
<<<< .mine
|||| .r5
=======
>>>> .r6
以下のファイルが自動的に生成される
・filename.ext.mine ファイル
・filename.ext.r* ファイル

問題の解消

実際には競合を解消しない。
マージによって自動的に生成されるfilename.ext.mine ファイルや filename.ext.r* ファイルを削除する。
結果、変更をコミットできる様になる。

競合の編集

・自動的にマージされた競合内容
・自動挿入された競合箇所を示す文字列
を編集/削除する。
この後、コミットする事で競合が完全に解決する。

Subversion②

アカウント作成

(~/svnをリポジトリとした場合)
svnディレクトリには自動で作成されるディレクトの内、
「conf」ディレクトリ直下の「svnserve.conf」を編集する。
svnserve
匿名ユーザー
anon-access = read(読取のみ)/write(読取・書込)/none(許可しない)
認証ユーザー
auth-access = read(読取のみ)/write(読取・書込)/none(許可しない)
認証先ファイル
password-db = (パス)

次に、
同じ「conf」ディレクトリ直下の「passwd」を編集します。
[users]
の下に
ユーザー = パスワード
を入力します。

test = testpasswd

Subversion①

インストール

ubuntuの場合
ソフトウェアセンターから検索&インストール
Windowsの場合
公式サイトからダウンロード
コマンドラインツール
Apache Subversion command line tools
インストール不要。
コマンドラインから
svn.exe
を実行。

svn_command1
svn_command2

$ svnadmin create

リポジトリパス設定
$ svnadmin create (リポジトリパス)
~/svn/testディレクトリをリポジトリとする。
$ svnadmin create ~/svn/test

$ svn import

リポジトリにファイルをアップ
$ svn import (ローカル作業パス) (リポジトリパス) -m (メッセージ)

$ svn import ~/work/source file:///home/username/svn/test/ -m “initial import”

$ svn checkout

リポジトリから全ファイルをダウンロード
$ svn checkout (リポジトリパス) (ローカル作業パス)

$ svn checkout file:///home/username/svn/test ~/work/checkout

$ svn update

リポジトリから差分をダウンロード
$ svn update (リポジトリパス) (ローカル作業パス)

$ svn checkout file:///home/username/svn/test ~/work/checkout

$ svn diff

差分表示

$ svn add

管理対象に追加
$ svn add (ローカル作業パス&追加対象ファイル名)
$ svn add ~/work/checkout/new.txt

$ svn commit

コミット
$ svn commit (メッセージ)

Jenkins①

Jenkins利用フロー

(1)開発者:ソースコードの変更
 ↓
(2)開発者:ソースコード管理ツール(Git等)へコミット
 ↓
(3)ソースコード管理ツール:CIツール(Jakins等)へ変更を通知
 ↓
(4)CIツール:ビルドツール(Ant等)へビルド指示
 ↓
(5)ビルドツール:ビルド
 ↓
(6)ビルドツール:CIツールへビルド終了を通知
 ↓
(7)CIツール:テストツール(JUnit等)へテスト実行を通知
 ↓
(8)テストツール:テスト
 ↓
(9)テストツール:CIツールへテスト結果を通知
Jekinsを利用する事で手動で行っていたビルド&テストが自動で行われる。
開発者が行うのは(1)と(2)のみとなる。

java実行環境インストール

http://java.com/ja/download/

jenkins.warのダウンロード

http://jenkins-ci.org/

右側の「Latest and greatest」をクリックして「jenkins.war」ファイルを保存。
Jenkins_download

起動

コマンドラインからjenkins.war保存フォルダに移動&以下コマンドを実行
java -jar jenkins.war
ブラウザで
http://localhost:8080
を開く

Jenkins

ジョブの作成
「新規ジョブ作成」
 ↓
「フリースタイル・プロジェクトのビルド」
 ↓
「ビルド手順の追加」
 ↓
シェルスクリプトを記述
 ↓
「ビルド実行」

継続的インテグレーション

概要

継続的インテグレーション(ContinuousIntegration:継続的統合)
アジャイル開発に必要な以下の工程をほぼ自動で行う事
・バグは即時修正
・メンバーへ即時共有
・頻繁に広範囲に執拗に自動でテスト
・修正ソースの即時反映(ビルド)

アジャイル開発

顧客の要求を細かく切ってその都度開発&テスト&納品を行う手法。
最初の仕様やスケジュールとどんどんズレていく事になるが
そこには拘らない事を顧客に了承を得た上で進める。
永遠に仕様追加・変更を続けるのとは違い、
全体の予算・期限の制限がある中での仕様・スケジュールの変更なので
全体的なゴールを顧客、開発側が常に意識しておかなければならない。
多くの場合、仕様の変更・追加要求があった場合に代わりに何かの機能を削る。
スピードを伴った開発能力だけでなく、予算管理を含めた交渉能力を必要とされる開発手法。

継続的インテグレーションに必要なツール

・CIツール(Jenkins,Xcode等)
・テストツール(XUnit,Selenium等)
・ビルドツール(Ant等)
・ソースコード管理ツール(Git,Subversion等)

(1)開発者:ソースコードの変更
 ↓
(2)開発者:ソースコード管理ツール(Git等)へコミット
 ↓
(3)ソースコード管理ツール:CIツール(Jakins等)へ変更を通知
 ↓
(4)CIツール:ビルドツール(Ant等)へビルド指示
 ↓
(5)ビルドツール:ビルド
 ↓
(6)ビルドツール:CIツールへビルド終了を通知
 ↓
(7)CIツール:テストツール(JUnit等)へテスト実行を通知
 ↓
(8)テストツール:テスト
 ↓
(9)テストツール:CIツールへテスト結果を通知
CIツールを利用する事で手動で行っていたビルド&テストが自動で行われる。
開発者が行うのは(1)と(2)のみとなる。

まとめ

良い開発を行う為に、アジャイル手法を用いる。
その為に各種ツールを用いての開発する事を継続的インテグレーションという。

なお、「テスト駆動開発」を行う事が現時点では最も開発効率が良いと言われている。
※テストツールに用いるテストコードを最初に書き、
最初にテストツールによるエラーを発生させ、
更にエラーが無くなる様にコーディングを行う開発手法。