MailtrapTestSendControl Email Delivery Platform that delivers just in time. Great for dev teams.
Git作業スタイル: リモートレポジトリに保存しつつキリのいいところで変更をまとめる - Qiita
あらまし 大きな作業をする場合、こまめにローカルレポジトリのブランチにコミットして、何かあったときにすぐに戻せるようにしたくなります。 また、パフォーマンス改善など、実験や研究の色合いの強い作業は、試行錯誤しながらブランチに"とりあえず"保存しつつ、「あっちのほうが良かったかな〜」と思ったときに取り出せるようにしておきたくなるものです。 また、ローカルレポジトリだけでなく、リモートレポジトリに置いたほうがチームみんなで共有できたりしていろいろ便利です。 ですが、最終成果物はなるべく少ないコミットにしないと、マージが大変です。 メインブランチにこんなコミットが入るとゲンナリしますよね？ $ git log --oneline bcdef12 Revert foo abcdef0 Add foo cdef123 Refactor bar again def1234 Refactor bar e
続・Gitリポジトリ運用の最適解 - chulip.org
このエントリは過去に書いたエントリの続編として位置づけています。 過去の記事：Gitリポジトリ運用の最適解 - chulip.org この記事を書いた当時、いや少なくとも少し前までは本気でマージコミットがないGit運用が最高だと考えていました。 だからこそ、何故A successful Git branching modelがNon-Fast-Forwordマージを推奨しているか疑問であり、昨今のgit-mergeには--no--ffオプションを設定。むしろgit-configでデフォルトの挙動を--no-ffにできるから設定しとけお前らという話に対してよく理解ができていませんでした。 マージコミットがないGit運用が最高だというのは限られた場合の話ではないか ある特定の場合においてのみこの話は適応されるのではないかということに気づきはじめたような気がします。 これは例えばリリース前の開発
RedmineのREST APIは素晴らしい～ビッグデータの手法をRedmineにも活用する - プログラマの思索
RedmineのREST APIを実際に試してみたら、とても素晴らしい。 分かったことをメモ書き。 【元ネタ】 Rest api - Redmine Redmine REST API - r-labs Rest Issues - Redmine コマンドラインとブラウザで JSON API を手軽に試す | COLOPL Engineers' Blog | 株式会社コロプラ【スマートフォンゲーム＆位置ゲー】 RedmineのREST APIを使ってみる | 『世界』はあまりにも広い Redmine REST API の翻訳 | プログラマーズ雑記帳 【1】RESTはマッシュアップというWebサービスの一つ。 REST APIを使えば、Redmineからチケットの情報だけでなく、プロジェクトやユーザ、果てはWikiまでHTTP経由で取得できる。 RedmineのREST APIの内容を見ると
git flow feature finishした後にリモート更新で気づくと悲しい問題への対処法 - cynipeと読む
7/21のSCM Boot Camp in Tokyo 3にGitの講師役として参加してきた。その時に id:ToMmY さんとgit-flow(もしくはgit merge --no-ff)した後にリモートが更新されていると悲しいという話をしてたらgit-flowのオプションあるから使うべきという耳寄り情報をゲット*1したのでまとめてみる。 何が問題か？ git-flowで開発をしている場合feature startでフィーチャーブランチを作成して作業を進め、フィーチャーの実装が完了したらfeature finishでdevelopブランチにマージといった流れになる。 この時のコマンドの流れは以下 $(develop) git flow feature start cool-feature $(feature/cool-feature) # イケてる機能の実装＆コミットコミット $(fea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
