#topicpath
----


#contents


まだまだ試行錯誤中です。

Gitを使ってちゃんとした(？)開発の手順を整理中です。

イメージとしては master は本番稼働として管理して、そこから派生する開発用のdevブランチがあって、そこからさらにチケットごとにブランチ(下記の例でdev_#50 とか)が作成され、チケットの対応が完了したらdevブランチにマージされていく、、、ってイメージ。
イメージとしては master は本番稼働として管理して、そこから派生する開発用のdevelopブランチがあって、そこからさらにチケットごとにブランチ(下記の例でfeature/dev_50 とか)が作成され、チケットの対応が完了したらdevelopブランチにマージされていく、、、ってイメージ。

** 事前準備 [#p44aa929]
GitHub上では masterとdevというブランチが作成済みという前提で進めます。ちなみに、dev ブランチのGitHubへの作成はたとえば[[GitHub/クローンからプッシュまでの流れ]]をみてみてください。
よくよく調べたら、この開発フローはGit-Flowという開発フローとして形式化されてるようで、なるべくそれに沿ったものにしてみようと思います。


** 事前準備 [#p44aa929]
GitHub上では masterとdevelopというブランチが作成済みという前提で進めます。ちなみにそれらの作成方法は [[GitHub/クローンからプッシュまでの流れ]] へ整理済みです。


** ローカルの環境に初回やること [#f3ad2b35]
まずは リモートのdev ブランチのCloneをローカルに作成します。
 $ git clone https://github.com/xxxxxx/helloworld.git
 $ cd helloworld
 $ git log  --decorate --oneline
 9a6a57c (HEAD -> master, origin/master, origin/dev, origin/HEAD) Initial commit
 $ git branch
 * master
 $ git checkout -t origin/dev     <-リモートのBranch(dev)から作成して移動。devは自動的にorigin/devを追跡するようにする
 Branch dev set up to track remote branch dev from origin.
 Switched to a new branch 'dev'
 $ git log  --decorate --oneline
 9a6a57c (HEAD -> dev, origin/master, origin/dev, origin/HEAD, master) Initial commit
 $ git branch
 * dev
   master
** 開発者がローカルの環境で初回やること [#f3ad2b35]
開発者が開発を始めようと思ったとき((ようするに個別のチケットを対応しようと思ったとき))、開発者はまずリモートのdevelop ブランチのCloneをローカルに作成します。
手順は [[GitHub/リモートのブランチをcloneする]] をご確認ください。

ここまでで、devというローカルのブランチが作成・チェックアウトされました。各開発環境で初回やるのはここまでで、チケットを対応する際はつぎからの手順を実施します。
ここまでで developというローカルのブランチが作成・チェックアウトされました。一応確認するとこんな感じ。。

 $ git branch -vv
   develop  1d61f85 [origin/develop] Merge branch 'release/0.0.1' into develop
   master   aa3dca8 [origin/master] Merge branch 'release/0.0.1'

各開発環境で初回やるのはここまでで、チケットを対応する際はつぎからの手順を実施します。



**チケットごとのブランチの作成 [#de37d929]
 $ git checkout -b dev_#50   dev <- チケット番号のイメージ。devからのブランチの作成と移動
 Switched to a new branch 'dev_#50'
 $ git checkout -b feature/dev_50   develop <- チケット番号のイメージ。developからのブランチの作成と移動
 Switched to a new branch 'feature/dev_50'
 $ git branch
   dev
 * dev_#50
   develop
 * feature/dev_50
   master
devから派生したチケット番号#50用のブランチが作成できました。
developから派生したチケット番号#50用のブランチが作成できました。


ちなみに、下記の下記のコマンドで
ちなみに、下記のコマンドで
 $ git branch -vv
   dev     bbf5c22 [origin/dev] committed on 2017.1.27
 * dev_#50 bbf5c22 committed on 2017.1.27
   develop     bbf5c22 [origin/develop] committed on 2017.1.27
 * feature/dev_50 bbf5c22 committed on 2017.1.27
   master  818f281 [origin/master] Merge

いま作成したブランチdev_#50 がどのリモートブランチも追跡していない(紐付いていないというか) 事を確認します。
いま作成したブランチfeature/dev_50 がどのリモートブランチも追跡していない(紐付いていないというか) 事を確認します。



**細かなコミットとかを進めていく使い捨てブランチを作成 [#qff1d031]
 $ git checkout -b dev_#50_spike dev
 $ git checkout -b feature/dev_50_spike develop
 $ git branch
   dev
   dev_#50
 * dev_#50_spike
   develop
   feature/dev_50
 * feature/dev_50_spike
   master


ここまでを図で示すとこんな感じ。

#ref(01.png)

開発はここで進めていきます。全体に反映されたくないようなコミットはココにやっていきます(とりあえずコミット!とかね)。。
なので、コミットを進めていくと下記の図のような感じになります。


#ref(02.png)



** チケット毎のブランチへのマージコミット [#a8c8ef70]

最終的に対応が完了したら、dev_#50にコミットをマージします。コミットを他のブランチにまとめる手順は
[[GitHubでコミットをまとめる>GitHub/コミットをまとめる]] に整理してあります。
最終的に対応が完了したら、feature/dev_50にコミットをマージします。コミットを他のブランチにまとめる手順は
[[GitHubでコミットをまとめる>GitHub/コミットをまとめる]] に整理してありますが、要するに下記のコマンドを実行します。

 $ git checkout dev_#50   ←移動して
 $ git merge --squash dev_#50_spike 
 $ git checkout feature/dev_50   ←dev_50へ移動して
 $ git merge --squash feature/dev_50_spike  spikeの内容をスカッシュマージ。

dev_#50_spikeで作業していた内容が、まるっと dev_#50にマージされました(下図の左の状態)。
feature/dev_50_spikeで作業していた内容が、まるっと feature/dev_50にマージされました(下図の左の状態)。

あとはこれらをコミットするときにちゃんとコメントを書いてコミットすれば、プッシュしても恥ずかしくない履歴が残せます。

 $ git commit -a

#ref(03.png)


そしてリモートのdev_#50へpushして、そこからdevに対してプルリクエストを行い、devへマージしてもらいます。
 $ git push origin dev_#50
** developの更新分をリベースしてコミット [#jb31c024]
さて、チケットの対応が完了したのですが、feature/dev_50をプッシュする前に、developの直近の更新分((他人がチケットを対応してマージされたりしているかもしれない))を git rebase で反映させて対応完了としたいです。仕組みの詳細は、[[GitHub/マージとリベース]]
に整理しましたが、ようするに下記の通りです。

 git checkout develop      developへ移動
 git pull origin develop   ローカルのdevelopを更新
 git checkout feature/dev_50   dev_50へ移動
 git rebase develop            更新元のdevelopの内容でリベース
 ... コンフリクトした場合はココでゴニョゴニョするのですが、詳細は上記リンク。
こうやって、feature/dev_50 のしらないところで更新されたdevelopの内容を、feature/dev_50へ反映させます。

** サーバへ feature/dev_50 の内容をプッシュ [#z7ea2e6f]
そしてリモートのfeature/dev_50へpushして、そこからdevelopに対してプルリクエストを行い、developへマージしてもらいます。
 $ git push origin feature/dev_50
 Total 0 (delta 0), reused 0 (delta 0)
 To https://github.com/xxxxxx/helloworld.git
  * [new branch]      dev_#50 -> dev_#50
  * [new branch]      feature/dev_50 -> feature/dev_50

#ref(04.png)


** devの更新分をリベースしてコミット [#jb31c024]
できることならば dev_#50をプッシュする前に、devの直近更新分をgit rebase で反映させて対応完了としたいです。仕組みの詳細は、
[[GitHub/マージとリベース]]
に整理しました。プルリクエストを送るには、ここまでやるべきのようですね。

 git checkout dev_#50
 git rebase dev
 ... コンフリクトした場合はココでゴニョゴニョするのですが、詳細は上記リンク。
こうやって、dev_#50のしらないdevでの更新分を、dev_#50へ反映させます。




**参考 [#i150b780]
-[[7. merge --squash【チュートリアル3 コミットを書き換えよう！】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ>http://www.backlog.jp/git-guide/stepup/stepup7_7.html]]
-[[GitHubへpull requestする際のベストプラクティス - hnwの日記>http://d.hatena.ne.jp/hnw/20110528]]


----
この記事は
#vote(おもしろかった,そうでもない)

#comment

#topicpath

SIZE(10){現在のアクセス:&counter;}
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS