#topicpath
----


#contents


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

キレイにGitをつかって開発しようとするとこんな感じ？？

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


**GitのCloneと、チケットごとのブランチの作成 [#de37d929]

 $ git clone https://github.com/xxxxxx/helloworld.git
 $ cd helloworld
 $ git checkout -t  origin/dev     <-リモートからのBranchの作成と移動
 Branch dev set up to track remote branch dev from origin.
 Switched to a new branch 'dev'
 $ git branch
 * dev
   master
 $ git checkout -b dev_#50    <- チケット番号のイメージ。devからのブランチの作成と移動
 Switched to a new branch 'dev_#50'
 $ git branch
   dev
 * dev_#50
   master
devから派生したチケット番号#50用のブランチが作成できました。

**細かなコミットとかを進めていく使い捨てブランチを作成(これは必須じゃあないかなぁ) [#qff1d031]
 $ git checkout -b dev_#50_spike
 $ git branch
   dev
   dev_#50
 * dev_#50_spike
   master

開発はここで進めていきます。全体に反映されたくないようなコミットはココにやっていきます(とりあえずコミット!とかね)。。最終的に対応が完了したら、dev_#50にコミットをマージします。
 $ git checkout dev_#50   ←移動して
 $ git merge --squash dev_#50_spike 

dev_#50_spikeで作業していた内容が、まるっと dev_#50にマージされました。。
あとはこれらをコミットするときにちゃんとコメントを書いてコミットすればプッシュできるような履歴が残せますね！

そしてリモートのdev_#50へpushして、そこからdevに対してプルリクエストを行い、devへマージしてもらいます。

# 欲を言えば、dev_#50をdevの直近でrebaseしてプッシュが望ましい。。
# 欲を言えば、dev_#50をdevの直近でrebaseしてプルリクエストが望ましい。。


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

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

#comment

#topicpath

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