GitHubでの開発の流れ
github_development.md GitHubでの開発の流れ 1. issue をたてる 不具合修正などは issue に詳しい内容を書く 2. ローカルで master からブランチを作る git checkout -b ブランチ名 3. コミットをする git commit -am 'コミットメッセージ' 4. push する git push origin ブランチ名 5. pull request を作る pull request のタイトル、説明欄に含める内容 issue の番号を先頭に#を付けて記述 (例: #123) fix #123 のように fix を付けるとマージされたときに対象の issue が自動的に close されます。 見てほしい人のアカウントIDを先頭に@を付けて記述 (例: @github) この pull request によって何が変わるのか
Ruby on RailsによるWebアプリ開発記(03) - メモ置き場
Ruby on RailsによるWebアプリ開発記(03) 前回 Ruby on RailsによるWebアプリ開発記(01) - メモ置き場 Ruby on RailsによるWebアプリ開発記(02) - メモ置き場 ルールは決まったけど、やっぱりちょっとやりにくい これまで、「作業が完了したらPull Requestを作成してコードレビュー」という方針で実施してきたが、下記の問題が多々発生した。 Pull Requestが作成されるまでは、各自の作業状況が把握しにくい commitログを見ればどんな変更を行っているかは一応把握できるが、全作業の何%が終わっているのかがわからない。 意識相違やミスがキャッチできない Pull Requestでのソースレビュー時に「ここはこういう書き方にすべき」などの指摘が入った場合、大きな手戻りが発生してしまう。 (その機能実装についての)悩みや疑問がうま
git commit --allow-empty を使った WIP PR ワークフロー - Qiita
先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の（親コミットと差分がない）コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何？ Work In Progress Pull Request の略です。 Github に Pull Request （以下、PR と表記）という機能があるのは皆さんご存知だと思います（知らない方はググってください）し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
