ファイルを作って
mkdir

リポジトリを作って
git init

リポジトリをURLと紐づけて
git remote add origin

コミットして
git commit -m "message"

プッシュすると
git push origin master

チーム開発実践入門

技術評論社の「チーム開発実践入門」を読んで学んだことを随時、（自分のためだけに）纏めていきます。
書籍だけから得た知識で頭でっかちなので、今後、CI/CDの実践を交えて情報を追記していければ。

P17メモ

• メールでプロジェクト管理をすることは困難
  • 可視性が悪く、優先度や重要度の判断をつけにくい
  • ステータスの管理ができない
  • 一覧性、検索性が低い

バージョン管理

P33

• 修正箇所にコンフリクトが発生するのは、同じ箇所を違う目的でコード追加しているからであり、リファクタリングが必要な証拠
• リファクタリング（外部からみた振る舞いを変えないでコードを書き換える）を安心して行うには、テストコードを書くこと

P69

• バージョン管理（Git）

  • リリースブランチ
  • 本番環境へのリリースの際に実際に使うために用意するブランチ
  • masterを常にリリース可能なブランチとして用意するケースもあれば、別途、ブランチを切るケースもある
  • ブランチ作成の流れ

  # まずはローカルへコピー
  git clone git@github.com<リポジトリ名>
  
  # 新規開発のためのブランチを切る
  git branch new-cool-function
  
  # ブランチを作成したらチェックインし、ブランチを切り替える
  git checkout new-cool-function
  

  • コミットとコミットログ

  git commit -m "メッセージ"
  
  # コミットログの確認
  git log --pretty=oneline
  <ログの表示>
  

  • ブランチの確認

  git branch
  <ブランチ名>
  

  • ブランチ作成と切替を同時に実施

  git checkout -b issue345
  

  • git checkout -b でブランチ作成とチェックアウトを同時に行うことができる
  • issue345をmasterにマージする場合
  • masterに切り替えてmergeコマンドを実行するのみ

    git checkout master
    git merge issue345
  

• タグ

  • リリースのタイミングをスナップショットとして記録

  git tag -a v0.1 -m "最初のリリースバージョン"
  

• 過去のコミットの探し方

  git log --pretty=oneline

• 該当のコミットに対してあとからタグ付け

  git tag -a v0.1 <コミットID>
  

• タグの中身を確認する方法

  git show v0.1
  

• 中央リポジトリにpush

  git push origin v0.1:v0.1
  

• 中央リポジトリからclone

  git clone git@github.com:Coolinc/someniceapp.git
  

• クローン実行後にブランチを作ってそこにタグをチェックアウトする

  git checkout -b 0.1 v0.1
  

  • 0.1がブランチ名、v0.1がタグ名

  ※Gitにおいてタグとブランチは別の名前空間に属しているが、通常利用においてはそれを意識しなくてよいようになっている。なので、同一名になる場合は、「refs/tags/v0.1」など明示する必要がある。

• git-flowでは中央リポジトリにメインブランチを２つ、各開発メンバーのリポジトリにサポートブランチを３つ、決まったモデルを作ることを提案している。P84

  • メインブランチ

    • 中央リポジトリとそれをクローンした各開発者リポジトリにずっと存在するメインのブランチ
    • master

    リリースするためのブランチ。リリースのたびにタグ付けする。
    - develop

    開発用ブランチ。リリース前の最新バージョン。

  • サポートブランチ

    • 原則、各開発メンバーのリポジトリにだけ存在し、役目が終わったら消える短命なブランチ。
    • feature

    developから派生し、特定の機能開発のために作成されるブランチ。機能開発が終わったらdevelopにマージされて消える。
    - release

    developから派生し、リリースのために準備をするブランチ。リリースのための準備作業中、余計なfeatureが混ざり込まないようにするために作られる。リリースが終わればmasterとdevelopにマージされて消える。
    - hotfix

    主にリリース済みの製品に障害があったときなどに緊急的に作られるブランチ。masterから直接派生し、バグを直したらmasterにマージされ、タグを打つ。またこのバグフィクスが将来漏れないように、同時にdevelopにもマージする。もしそのときリリース作業中でreleaseが存在している場合は、そこにもマージする。

• git-flowを容易にするgit-flowスクリプトが提供されている

  • git-hub flow

1. masterのものはすべてリリース可能である
2. 新しく何かをするときはmasterから直接ブランチを作る
3. 作成したブランチはローカルマシンにコミットして、リモートリポジトリにも同じ名前のブランチとして定期的にPushする
4. 開発が完了したらPull Requestする
5. Pull Requestがレビューされたらmasterへマージし、その場で本番環境にリリースする

• P87のgit-flowとgit-hub flowがチーム開発をするうえではベスト？

• データベーススキーマのバージョン管理

• データベーススキーマをCI（継続的にメンテナンス）することをCDBI（Continuous DB Integration）というが、最近ではデータベースマイグレーションということが多い

• 設定ファイルは環境毎に分けてバージョン管理すべき

  • 絶対に手作業で環境毎に書き換えるようなことをしてはいけない

チケット管理システム

• チケット駆動開発の手順

  • 新機能やバグ修正を行う際、その都度に内容や目的を記述したチケットを起票する。
  • チケットの内容に応じて適切にコードを修正してコミットする。このとき、コミットログに関連するチケット番号を入れる。チケットにもコミットログの番号を記入する。

• チケット駆動開発を徹底する

  • バージョン管理システムがもっているクライアントサイドフックやサーバサイドフックを用いるとよい。
  • コミットメッセージのなかにチケット番号が入っているかどうかチェックし、入っていない場合はコミットを受け付けないようにする。

• Redmineをよく使う自分には以下の状況が該当

GitHubが登場し、Gitの手軽さとGitHubのPull Requestの便利さが知られ普及した今となっては、あえて自分たちでGitリポジトリをセットアップしてTracまたはRedmineをリポジトリブラウザとして使う意味が薄れました。素直にGitHubを使うのがコスト的にも合理的な時代になっています。リポジトリブラウザとしてGitHubを使い、TracやRedmineはチケット管理システムとしてのみ使うのが良いでしょう。GitHubのService HooksにもTracとRedmineは用意されていますので活用してください。

• Git自身のHookを使う方法

  • GitのHookはクライアント・サーバサイドそれぞれで動作するHookがリポジトリの.git/hooks/の下に多数用意されている。.samplesという名前のサンプルスクリプトを参考に記載すべし。

• どこまでをチケット管理システムでカバーできるのか

  • Scrum開発の言葉を借りて説明

  No.	課題名称	説明	該当するツール	チケットシステムの管理対象
  1	エピック（大きな要望、部署横断の課題など）	システム要求に落ちる前の要件定義のフェーズ - 非エンジニアが関わることが多い - 優先順位付けをするのがメインの目的であるため一覧性が重要 - 曖昧な状態で始まるものが多く定形フォーマットは向かず、柔軟な編集が可能なものが良い - 複数の人たちの編集、共有がかんたんなものが良い	Google Docs、Excelなど	-
  2	ストーリー（具体的な要望、機能要求や仕様に近いレベル）	顧客に届ける価値を表す - その製品に責任を持つ人が書くことが多い - 組織やプロジェクトによってかわるが、非エンジニアもあり得るし、プログラマ自身が書くこともある - ステータス管理が必要である - コードとの関連性をつけ始めた方が良い - 担当者が複数であることも単独であることもある ※タスクに落とすときはチケット管理システムでチケットの親子関係を作り、親：ストーリー、子：タスクとすると良い。 ※組織の境目で表計算ソフトと使い分ける方法もある。組織横断の時点では表計算ソフトで扱い、具体的な組織内のタスクに落ちてきたらチケットを起票、という感じ。	-	○
  3	タスク	- 具体的な作業内容 - ストーリーの下に複数ぶら下がるイメージ - 担当者は単独 - コードとの連携が必要かどうかは内容による	-	○
  4	バグ、障害対応、問い合わせ	- レベル感はタスクと近い - 担当者は通常単独 - コードとの連携が必要	-	○

CI（継続的インテグレーション）

インテグレーションとは以下のプロセスのことをいう

• すべてのソースコードを1箇所に集める
• 依存するライブラリなどにパスを通す
• 必要な場合はコンパイルする
• データベースの構築とデータのロードを行う
• 必要に応じてミドルウェアの設定や起動を行う
• 単体テストと結合テスト、ユーザ受け入れテストなどを実施する

これらのプロセスを常時実行するのがCI。

振る舞い駆動開発（BDD）

• 最初にテストコードを書くのはTDDと同じ
  • ただし、テストというよりは要求仕様に近い記述をする
  • 仕様を書いてからアプリケーションコードを書くスタイル
  • Cucumber-jvmを使って、自然言語で振る舞いを記述する例が挙げられていた
  • この例では、振る舞いを記述してテストを生成→テストクラスにコピペして実行の手順
  • Pythonで同様のものはないのか？？
    • behaveというBDDフレームワークが有名な模様（あとで使ってみよう）

カバレッジ

コードカバレッジとは、対象となるアプリケーションコードのうち、テスト時に何％のコードが実行されたかを表す指標。これを計測することによって、対象のコードがどの程度テストされているかを視覚化できる。ただし、コードカバレッジは対象となるアプリケーションコードが実行されたかどうかだけを計測するものであって、テストコードの内容がテストとして妥当化どうかは判断できない。この点はコードレビューで担保すればよい。

ビルドが壊れたらどうするか

• Subversionなど中央集権型バージョン管理システムの場合

壊れたらその時点で同じリポジトリの同じブランチ上で作業しているすべてのメンバのコミットを禁止する必要がある。（壊れたコミットのうえにさらにコミットが重なってしまう）

• Gitなど分散バージョン管理システムの場合

基本はSubversionと同じで同一ブランチ上で作業しているメンバのコミットを禁止する。ただし、git-flowのように、メンバー各位がリポジトリを持ってプルリクを送る運用の場合はその限りではない。（GithubとTravisCIの組み合わせだけでなく、Github－Jenkinsでもプラグインを使えば実現可能）

デプロイの自動化

ここではプロビジョニングツールを以下の３つにわけ、具体的なツールでの例を挙げて説明している。

1. Bootstrapping

サーバOSの設定や仮想マシンによるサーバ立ち上げの自動化に関するツール

1. Configuration

サーバやミドルウェアの設定を自動化するツール

1. Orchestration

ソースコードのデプロイやリリースに関わるサーバの操作などを自動化するツール

以下、それぞれのレイヤーに属するツールの説明。

1. Bootstrapping

   1. Kickstart

   ベアメタルサーバのOSインストール時に初期設定を記載したConfigファイルを読み込ませて、一律同じ設定のサーバを作成する。
   2. Vagrant

   ベアメタルではなく、VirtualBoxの仮想環境の設定を自動化するツール。Kickstartのように各用途、各人にベアメタルサーバを用意できないときはこちらを用いる。プラグインを入れればAWSにも使えるらしい。同じくRubyで書かれたConfigurationツールのChefとは相性が良い。

2. Configuration

   1. Chef

   サーバ設定を自動化するツール。小規模なサーバ構築であればChef Soloのみで、大規模なサーバ構築であればChef Severを構築するとよいらしい。検証－本番等の環境差異については、レシピ中の変数にattributeとして記載できるため、差異を吸収できる。よって、全環境で同一のCookbooksを利用すべき。注意事項としては、本ツールを使う以上、手作業でのサーバ構築を禁止しなければいけない。
   2. serverspec

   サーバ構成をユニットテストするためのツール。Chef等でサーバ構築を行ったあとに利用するとよい。Rubyで書かれていてRubyに精通してないとキツいと思われがちだが、対象にたいしてどうなっているべき（shoud be xx）みたいな簡潔な書き方であり、すぐに慣れると思われる。

以下、Bootstrappinng→Configurationへのベストプラクティスとして、以下のような例が挙げられています。

ベストプラクティス１

　①Vagrantでクリーンなインスタンスを起動

　②ChefのCookbookとserverspecのテストケースをGitからチェックアウト

　③Chefが実行され、サーバが設定される

　④serverspecでサーバの状態テストが実施される

　⑤実行結果がJenkinsにフィードバックされる

これら一連の処理がVagrantfileに記載され、実行されます。

ベストプラクティス２

　ベアメタルサーバを使わざるを得ない人向け（自分はレガシーな職場にいるのでこちらのほうが使えそう…）。

　こちらは上記のVagrantがKickstartに変わったようなものだと思っていただければよい。

　※Kickstartは仮想環境のインストールにも適用できるため、ベアメタルに行く前に検証は必須。

1. Orchestration

   1. Capistrano

   Capistranoサーバを用意するだけど、アプリやDBサーバに手を入れることなく、Pushでリリース作業を行ってくれる。
   2. Fabric

   Python製のツール。Capistranoとの違いは、処理の直列／並列を簡単に切り替えられること。ゼロダウンタイムデプロイメントの例を挙げてこのメリットが説明されている。

ベストプラクティス

​ 全体のジョブ管理用のJenkinsとFabricの組み合わせの例が挙げられています。Jenkinsでマスター／スレーブノードを構成し、スレーブエージェント経由でFabricを実行しています。この構成を取ることで、Fabricの実行結果をJenkinsのコンソールログとして残すことができます。

※セキュリティ

​ Fabric等でリモートサーバに接続する際、どこからでもrootログインを許容するとセキュリティを損なうことになる。Fabric等を実行するサーバに限定してrootログインが可能なように設定すること。また、それらのサーバは限られたユーザのみ限定してログイン可能とし、公開鍵認証方式でセキュリティを担保するとよい。

​ sshdでは、/etc/ssh/sshd_configにおいて、Matchディレクティブという条件分岐を設定でき、条件にあったIPアドレスやユーザアカウントからのSSH接続要求があった場合に指定した設定通りの振る舞いを制御することが可能。例では、Fabric実行サーバからの接続のみrootアカウントへのRSA認証でのSSH接続を許可している。

参考）P255では手作業のデプロイで便利なツールが紹介されている。

ツール名	説明
RLogin	Windows上で動作するターミナルソフトで、開いているすべての接続にキー操作を同時におくることができ、ログイン先のサーバですべて同じ作業を同時に実施することが可能。
Tera Term	RLogin同様、複数の接続先へ同時にコマンドを送信できるブロードキャストコマンド機能がある。
ClusterSSH/ Parallelssh/ClusterIt	LinuxやまｃなどのUnix環境で使える同時実行ツール。

運用について考慮する

ブルーグリーンデプロイメント

ロードバランサによりテストアカウントはブルー環境に割り振られ、一般ユーザはグリーン環境に割り振られる。

この章はなんとなく言ってることは分かるんだけど、経験が乏しすぎてなんとも…

リグレッションテスト

P289で、Seleniumで取得した画面キャプチャをImageMagickで比較する手法が挙げられている。この手法は試したことがないので、ぜひ試してみたい。レガシーな職場（多くのSIerの現場）でも有効なのではと思う。

はじめに

どうも‪✋(´･ᴗ･` )‬
題名の通り, 署名付きcommitをKeybaseとともにやりましょうというお話です。

Keybase の鍵で GitHub のコミットに Verified バッジをつける - Qiita
基本的には上記の記事の実践記録になります。
書かれている手順を実施しながら, 私みたいな初学者向けに設定の根拠等を自分なりに調べたのでそれをまとめてみました。

手順

Keybaseのインストール

Keybaseを使って鍵の管理をしたいので, インストールしていなければインストールしておきます。
公式サイトからインストーラーをダウンロードしてインストールしてください。
The App - Install Macos | Keybase Docs

GPG_TTYの設定

この後で使用するGnuPGというソフトウェアに使っているシェルの場所を教えるために, 下記の手順で環境変数 GPG_TTY を設定します。
これを設定しないとGnuPGがどのシェルから入力を読み取ったら良いかわからず, Inappropriate ioctl for device というエラーが出てしまいます。

① .zshrc 等, 利用しているシェルの設定ファイルを開きます。
② 下記を追加します。

GPG_TTY=$(tty)
export GPG_TTY

③ 設定ファイルを再読み込みします

$ source .zshrc

必要なソフトウェアのインストール

① 下記のコマンドを実行し, GnuPGとpinentry-macをインストールします。
GnuPGは暗号化ソフト, pinentry-macは秘密鍵のパスフレーズを入力する際に使用するソフトです。

$ brew install gnupg pinentry-mac

② GnuPGの設定ファイルを格納するフォルダを作成します。

$ mkdir ~/.gnupg

③ 下記のコマンドを実行して ~/.gnupg 配下の設定ファイルに設定値を書き込み, GnuPGにpinentry-macの場所を教えてあげます

$ echo "pinentry-program `which pinentry-mac`" > ~/.gnupg/gpg-agent.conf

④ GPG Agentを再起動します。

$ gpgconf --kill gpg-agent

Keybaseから鍵をインポート

① Keybaseから公開鍵をエクスポートし, それをGnuPGにインポートします。

$ keybase pgp export | gpg --import

② Keybaseから秘密鍵をエクスポートし, それをGnuPGにインポートします。
秘密鍵のパスフレーズを訊かれたら適宜設定します。

$ keybase pgp export --secret | gpg --allow-secret-key --import

こんな感じの表示が出ればOKです。

gpg: 鍵****************:"Ray Nanamiya <****@***.***>"変更なし

gpg: 鍵4F7AF2B0AF315E05: 秘密鍵をインポートしました
gpg:           処理数の合計: 1
gpg:               変更なし: 1
gpg:       秘密鍵の読み込み: 1
gpg:     秘密鍵のインポート: 1

github.comに公開鍵情報を登録する

まだgithub.comに公開鍵情報を登録していなければ登録します。

① 公開鍵をコピーするために, Keybaseの自身のプロフィールページに行き, ここをクリックします。

② ここに表示されている文字列をコピーします。

③ Githubの自身のプロフィールページにアクセスし, 画面右上のSettingsをクリックします。

④ 「New GPG Key」をクリックしてコピーしたGPGキーを登録します。

gitの設定

最後に, 必要な設定をgitに入れ込みます。

鍵情報の登録

① 下記のコマンドを実行して鍵情報を確認します。
この時, メールアドレスがgitにcommitする時のメールアドレスと一致していないといけませんのでご注意ください。

$ gpg --list-secret-keys

gpg: *警告*: homedir '/Users/***/.gnupg'の安全でない許可
/Users/***/.gnupg/pubring.kbx
-----------------------------
sec   rsa4096 2019-09-29 [SC] [有効期限: 2035-09-25]
      E474************************************
uid           [  不明  ] Ray Nanamiya <***@***.***>
ssb   rsa4096 2019-09-29 [E] [有効期限: 2035-09-25]

② E474から始まる文字列をgitに登録します。

$ git config --global user.signingkey E474************************************

GnuPGのパス設定

① 下記のコマンドを実行してgitにGnuPGの場所を教えてあげます。

$ git config --global gpg.program `which gpg`

最後に

以上の手順を踏めばGPGキーで署名したコミットをすることができるようになります。
署名つきコミットをする場合は

$ git commit -S -m "***"

のように -S オプションを利用します。

参考資料

• gpg-agent forwarding: inappropriate ioctl for device - Stack Overflow
• Keybase の鍵で GitHub のコミットに Verified バッジをつける - Qiita
• gpg: signing failed: Inappropriate ioctl for device · Issue #2798 · keybase/keybase-issues

はじめに

この記事はまだGitを使ったことのない人、使い始めたけどいまいちつかめないひとにすこし噛み砕いて説明しています。
厳密には違ったりする部分もあります。ご了承ください。

Gitとは

よく、バージョン管理ツールって言われます。
いわゆるコードの歴史年表です。

〇〇〇〇年〇〇月〇〇日〇〇:〇〇、このファイルのこの文をこういうふうに追加しました。

みたいな歴史をたくさん刻んでプロジェクトの歴史年表を作っていく感覚です。
このひとつの出来事をコミットと呼びます。

コミットは

• 日時
• コメント(出来事を簡潔に表したもの)
• 実際に起きたコードの変化の履歴

が主な構成要素となっています。

歴史年表なのでいつでも昔の状態を見るられるし、一覧も見られます。

なんかよくわからないエラーが出て昔に戻りたい！そんなときにすぐ好きな時代に戻れるのがGit管理の最大の魅力です。
共同で開発する際もお互いが違う場所で作業してもお互いの作業(パラレルワールド(あとで出てくる))をいい感じにまとめてくれるのもGitの利点です。

GitHubとの違い

GitとGitHubはよく混同されがちな事柄の一つです。

• Gitは歴史年表を刻むサービスそのものです。
• GitHubはその歴史年表をインターネット上に公開して共有できるサービスです。
  • インターネット上にあるので複数人で歴史を刻める。
  • パソコンが壊れてしまったときのバックアップにもなったりします。

GitHubはGitをインターネット上で管理するツールの一つです。
ほかにもBitBucketやGitLabなんかもありますが一番メジャーなのはGitHubでしょう。

歴史を刻む

さあGitについて少しわかってきたところで早速プロジェクトの歴史年表を作って、歴史を刻んでいきましょう。

MacにはGitがはじめからインストールされているので何もせずに歴史年表を作るとから初めて問題ないのですがWindwosにはGitがインストールされていません。こちらのインストール方法に則ってインストールをしてから次に進みましょう。

まずターミナルを開きましょう。

⌘ + spaceのSpotlight検索にターミナルと入れれば起動できます。(もちろん他の方法で起動してもOK)



こんなかんじで立ち上がればOKです。

次にプロジェクトのフォルダに移動しましょう。

まず、ターミナルにcd と入力し半角スペースを押します。

次にFinderを開き、プロジェクトのフォルダをターミナルにドラッグアンドドロップします。

そしてreturnキーを押します。
するとプロジェクトフォルダに移動できました。ターミナルの$や% の前にプロジェクトフォルダの名前が来ていれば成功です。

現在のgitの状態を確認する

ターミナルでgit statusと入力しreturnキーを押してみてください。
次の２つのどちらかになると思います。

masakazozaki@MasakaznoMacBook-Pro SampleProject % git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    SampleProject.xcodeproj/
    SampleProject/
nothing added to commit but untracked files present (use "git add" to track)
masakazozaki@MasakaznoMacBook-Pro SampleProject % 

若干一致しないところもあるかもしれませんがこのようになにかしらのごちゃごちゃしたものが出てきた場合、すでに歴史年表はつくられています。Xcodeなどは自動で作ってくれる設定がデフォルトになっているので自分で歴史年表を作る必要はありません。

masakazozaki@MasakaznoMacBook-Pro ~ % git status
fatal: not a git repository (or any of the parent directories): .git
masakazozaki@MasakaznoMacBook-Pro ~ % 

のように not a git repository と出てきた場合はまだ歴史年表が作られていません。
歴史年表を作成するgit initという歴史年表を作成するコマンドをターミナルで打ち込み、returnキーを押して歴史年表を作成します。

歴史を刻む

実際に歴史を刻んでいきましょう。前のコミットからの差分(初めての場合はすべてになる)を歴史として登録します。

git add .
まずこれですべてのファイルを年表の変更に追加します。(一旦おまじないと思っていても大丈夫)

次に歴史を刻みます
git commit -m "hogehoge"
このhogehogeの部分にコミットメッセージを入力します。

〇〇〇〇年〇〇月〇〇日〇〇:〇〇、このファイルのこの文をこ言うふうに追加しました。

最初に出てきたこのコメントの部分です。
そのときプロジェクトに何をやったかを簡潔にまとめてあげましょう。(日本語で大丈夫)

これで歴史を刻むことができました。

次からは
cd プロジェクトファイルのパス
git add .
git commit -m "hogehoge"
の3つをやってあげると歴史を刻めます。

歴史をどれぐらいの頻度で刻むのか、とても難しいのです。機能を一つ作った、この機能をこう変えた。新しい画面を作った、程度の粒感で最初は大丈夫です。あと作業を終わりにするときも必ずcommitしましょう。(パソコン壊れて消える可能性あり)

歴史をインターネット上に公開する

GitHubの使い方はたくさんネットにあるのでぜひググってみてください。(希望があればまとめます)
一通り設定をしたら
cd プロジェクトファイルのパス
git add .
git commit -m "hogehoge"
git push origin master
でローカルとリモート、つまりパソコン内とインターネット上の両方に歴史を刻めます。(設定する前にpushしてもうまくいきません)

歴史を見る

ターミナルでgit logとコマンドを叩くことで歴史を見ることができます。キーボードの矢印キーでスクロールできます(マウスやトラックパッドではできない)

昔の歴史の状態に戻ることも可能だが、リスクが高い。(慣れてきてからやってみましょう)

最後に歴史を刻んでから今までの変更をなかったコトにするのは
git checkout .
この一行で戻すことができます。(変更はもう戻せない)

また変更を戻すことを前提に一旦逃しておくには
git stash
戻すには
git stash pop

パラレルワールドを作る

いわゆるbranchというやつです。
「ブランチを切る」という表現をします。
git checkout -b hogehoge　(hogehogeは好きなブランチ名)
で新しくブランチを切るることができます。

もとのメインの年表(master branch)を見るには
git checkout master
で戻れます。

二回目以降、またパラレルワールド(feature branch)に移動したいときは
git checkout hogehoge　(hogehogeはブランチ名、-bはブランチを作るときだけ)
で戻れます。

ブランチを切ると新しくパラレルワールドが作られてそこでの変更はメインの年表(master branch)には反映されません。パラレルワールド上のみで歴史を刻みます。

パラレルワールドはいくつでも作ることができます。パラレルワールドをつくったあと(branch切ったあと)にメインの年表(master branch)に新しい歴史を刻んでもパラレルワールドでは変更されません。

この機能を使って新しい機能を追加するときや、共同開発をするときなどはパラレルワールドを作ってそこで新機能を実装して行きます。本体をいじらないので安全に新機能を追加したりいじったりできます。

もちろん、パラレルワールドをメイン年表に取り込めます。

パラレルワールドは複数作れるし、パラレルワールドがあるときでもメインの年表は更新できる。
　だけど、個人開発(特に初心者)の場合だと、同じ箇所を複数の年表で違う変更したりしたとき、そしてそのパラレルをメイン年表に取り込むときにどっちの歴史が正しいのかコンピューターが判断できなくなってしまいます。そしてコンフリクト(衝突って意味)をおこしてそれを解消するという難しいことをしなくてはなりません。それは避けたい。

なので最初のうちは新しいことをやるときはブランチ切って(パラレルワールドを作って)もよいが、作ったら他のブランチ(年表)はいじらないのをおすすめします。

パラレルワールドで起きた出来事をメイン年表に取り込む

そのパラレルワールド(feature branch)をメイン(master branch) に取り込むことで新機能などをメイン年表に取り込めます。

取り込むにはまず、メイン年表(master)に移動する必要があるので
git checkout master
これでメイン年表に移動できました。(移動する前にキチンとfeature branch(パラレルワールド)でaddとcommit(歴史刻む)しておく。)

そしていよいよ取り込みます
git merge hogehoge　(hogehogeはパラレルワールドのブランチ名)
これで取り込むことができます。

パラレルワールドをなかったコトにする

新機能をbranch切って作っていてやっぱりやめた。うまく行かないからやめた。となったとき。
かんたんにbranchをなかったコトにできます
git checkout master
master branch(メイン年表)に移動するこのコマンドを叩くことでなかったコトにできます。あとは新しくパラレルワールド作ってそっちで作業すればOK。

ブランチ(パラレルワールド)を削除することもできるのですが、間違ってメインを削除すると大変なことになるのであまりおすすめしません。技術がついてきたらそのときにまとめて削除するといいでしょう。
一応、master branchに移動(git checkout master)した状態で
git branch -d hogehoge　でブランチを消すことができますがおすすめしません。やめたほうがいい。

歴史は刻み続けなくてはならない

歴史って刻まれ続けますよね。gitも同じで常に更新し続けアップデートしていくことがとても大切です。
古いままだと新しい実行環境などでうまく動かない場合もあります。新バージョン対応だけでもアップデートはとても大切です。

基本的に2年以上更新のないプロジェクトは死んでるとおもってもいいかもしれません。それぐらいITの世界の時間の流れは早いです。

Git触りかけのみなさんもたのしくITに触れ、モノづくりを楽しんでいきましょう！

その他便利コマンド集

Git でよく使われるコマンドにイラストによる説明を加えて1枚のチートシートにまとめてみた - Qiita
Gitでやらかした時に使える19個の奥義 - Qiita