Skip to content
Tanaka Daiki edited this page Oct 30, 2018 · 6 revisions

Welcome to the whole_issue wiki!

Tips

bundle installしてもサーバが立ち上がらない時

$ sudo apt-get install libpq-dev  
$ gem install pg -v '0.18.4' --source 'https://rubygems.org/'
$ bundle install
$ rails s

で解決しました。


全ユーザーへの通知作成方法

  1. lib/tasks/message.txt を作成し、本文を書く
  2. rails runner lib/tasks/notice_sender.rb を実行する

本番環境でレイアウト崩れが起きた場合

開発環境で発生しなかったレイアウト崩れが、本番環境において発生した。

解決策 RAILS_ENV=production bundle exec rake assets:precompile を忘れていた。

cssが反映しないっぽい。


リリースノートの作り方

バージョンの命名則

${VERSION} = ver-${MAJOR}.${MINOR}.${PATCH} ${MAJOR} = 0 ${MINOR} = 1 ${PATCH} = (日付4桁)

例) ver-0.9.1023

リリースノート作成方法

  1. ターミナル上で git tag -a ${VERSION} -m "第 n スプリント" <commit id> (n はスプリントの番号) git push origin ${VERSION}

  2. github 上で releases にアクセス release

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

右上の Edit Tag をクリック edit_tag

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


Branch の命名則

さすがに dev/*develop/* が混在するのはいただけないので・・・

ぼく個人としての分け方はこんな感じでした。


  • master: メインブランチ。常にリリース可能な状態であることが望ましい。 なので基本的に他のブランチからの pull request を受けるだけ。

  • develop/*: master から生やす統合ブランチ 。普段の開発は主にdevelop から生やした feature/* ブランチを使う。 基本消さない。 (つまり masterdevelop は常に生きてる状態)

  • feature/*: develop から生やすトピックブランチ 。 今までの使い方でいくと、develop を更に細切れにしたイメージ。 develop/* に統合される。

  • fix/* or hotfix/*: バグ修正用ブランチ。緊急時にmaster から切られるのが hotfix。 俺はこれと別に develop/* から切る fix/* みたいな使い分けをしてる。 特に意味があるわけじゃないけど。

  • release/*: リリース準備用のブランチ。* にはバージョン名を書くのがいいかもしれない


* の部分にはそのブランチの作業内容がわかるような名前をつける ハイフン区切りが気に入ってるんだけどどうでしょうか。

例)develop/add-image-preview

参考文献: ブランチの運用 トピックブランチと統合ブランチでの運用例

その他

ブランチは原則、生えてきたところに統合する pull request で間違いやすいから注意してね