Skip to content

開発フロー

Jump to bottom
Yuta Kawai edited this page Jul 23, 2024 · 3 revisions

= 概要

  • SCALEは、主に Fortran90で書かれています。(一部 C を含みます)
  • ソースは、gitで管理されています
  • gitリポジトリのアクセスは、github にて管理されています。
  • ブランチのポリシーは、"A successful Git branching model"（ http://nvie.com/posts/a-successful-git-branching-model/ ）に従います。
  • git-flowを使うことを推奨します
= 開発に必要なもの = 事前準備

git リポジトリにアクセス出来るよう管理者に連絡し、ssh公開鍵の登録手続きを行ってください。 gitに初期設定（コミット時の名前）を設定します。 

 % git config --global user.name "Yang-Mauler Tsuyoshi"
 % git config --global user.email yang-m.t@examle.com

= ソースチェックアウト

  • git-flow の version が 0.4.1 以下の方 (mac ports で git-flow をインストールした方)
 % git clone git@github.com:scale-met/scale-dev -b master
 % cd scale-dev
 % git checkout -t origin/develop
 % git flow init -d
  • 0.4.2 以上の方
 % git clone git@github.com:scale-met/scale-dev
 % cd scale
 % git flow init -d

= 開発スタート 

 % git checkout develop
 % git flow feature start hogehoge(修正/機能に応じた名前)

= 開発終了 

 % git pull
 % git rebase develop (マージが必要な場合がある)
 % git flow feature publish hogehoge

一度 publish したことがあるブランチについては、rebase は行ってはいけない。

管理者に develop ブランチへのマージを申請。

管理者によるマージ後、 

 % git checkout develop
 % git pull
 % git branch -D feature/hogehoge

= 複数人での開発

  • 誰か一人が、上記の「開発スタート」および「開発終了」の git flow feature publish hogehoge までを行う
= それぞれ 



ひととおり作業が終わったら



 % git flow feature pull origin hogehoge
 % git push





作業再開時には、



 % git checkout feature/hogehoge
 % git flow feature pull origin hogehoge





= github.com での Issue 化



他の開発者との情報共有のため、github.com の scale-met/scale-dev プロジェクトで作業を Issue 化する。SCALE では git のブランチによるコード修正をご本尊へ反映させる前に、開発者同士でレビューを行うことにしている。そのレビューをスムーズに行うため、またその他の開発者が後々の参考にするため、開発用の Issue は次の作法に従ってオープンすることが望ましい。








    

  • Issue で「この Issue で解決すべき問題点」、既に修正コードが用意されているなら「修正コードを適用する前後の比較」を明示する。
    • 

  • ハイライトする数式・箇所等を Issue に記録しておく。
    • 

  • コード内で複雑になる場合は適切なコメントを挿入する。
    • 

  • Issue 提案者と開発者が異なる場合等も考慮し、誰が「問題点」や「比較」の情報を載せるかについてはケースバイケースでの対応とし、コードがマージされる前に上記情報が提示されていれば良いことにする。
    • 


レビューを行う人（マージリクエストを受けた人）は上記の点に考慮しながら、問題点があれば Issue のコメント等に記述して残すようにする。


Issue のクローズは原則、 Issue をオープンした人が行う。ただし Issue を提案した人とその提案を受けて実際に開発を実施した人（＝マージリクエストを発行した人）が異なる場合、マージリクエストを受けた人はマージ後に『 Issue を立ち上げた人を担当者に変更する』ようにする。Issue を立ち上げた人とマージリクエストを発行した人が同じであれば、マージリクエストを受けた人は担当者を変更しなくてもよい。マージされれば、マージリクエストを投げた人に通知がいくので、従来通りマージリクエストを発行した人が Issue をクローズする。これは Issue を立ち上げた人が最後に閉じ忘れるのを防止するための措置。



= 開発ドキュメント



作成途中。何かの参考になることがあれば……。



[SCALE_developers_guide.pdf](https://github.com/scale-met/scale/files/10421880/SCALE_developers_guide.pdf)



[SCALE_developer_document.pdf](https://github.com/scale-met/scale/files/10421883/SCALE_developer_document.pdf)

              


          



  
          

            


            
Clone this wiki locally