-
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 で間違いやすいから注意してね