-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the whole_issue wiki!
$ sudo apt-get install libpq-dev
$ gem install pg -v '0.18.4' --source 'https://rubygems.org/'
$ bundle install
$ rails sで解決しました。
- lib/tasks/message.txt を作成し、本文を書く
-
rails runner lib/tasks/notice_sender.rbを実行する
開発環境で発生しなかったレイアウト崩れが、本番環境において発生した。
解決策
RAILS_ENV=production bundle exec rake assets:precompile
を忘れていた。
cssが反映しないっぽい。
${VERSION} = ver-${MAJOR}.${MINOR}.${PATCH}
例) ver-0.9.1023
-
ターミナル上で
git tag -a ${VERSION} -m "第 n スプリント" <commit id>(n はスプリントの番号)git push origin ${VERSION} -
github 上で releases にアクセス

先頭に今 push した tag があるのでクリック(ここでは tmp としている)

右上の Edit Tag をクリック

Release title は何も書かずに
Describe this tag にリリースの内容を書く
prerelease にチェックを入れて Submit

さすがに dev/* と develop/* が混在するのはいただけないので・・・
ぼく個人としての分け方はこんな感じでした。
-
master: メインブランチ。常にリリース可能な状態であることが望ましい。 なので基本的に他のブランチからの pull request を受けるだけ。 -
develop/*:masterから生やす統合ブランチ 。普段の開発は主にdevelopから生やしたfeature/*ブランチを使う。 基本消さない。 (つまりmasterとdevelopは常に生きてる状態) -
feature/*:developから生やすトピックブランチ 。 今までの使い方でいくと、developを更に細切れにしたイメージ。develop/*に統合される。 -
fix/*orhotfix/*: バグ修正用ブランチ。緊急時にmasterから切られるのがhotfix。 俺はこれと別にdevelop/*から切るfix/*みたいな使い分けをしてる。 特に意味があるわけじゃないけど。 -
release/*: リリース準備用のブランチ。* にはバージョン名を書くのがいいかもしれない
* の部分にはそのブランチの作業内容がわかるような名前をつける ハイフン区切りが気に入ってるんだけどどうでしょうか。
例)develop/add-image-preview
参考文献: ブランチの運用 トピックブランチと統合ブランチでの運用例
ブランチは原則、生えてきたところに統合する pull request で間違いやすいから注意してね