#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してプルリクエストが望ましい。。 -[[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;}