ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
実務でどんな git コマンドを使っているか振り返ってみる - Qiita
gitコマンドって実務でどう使うんだろう？ 独学の git コマンドを実務で使いまくり、最近やっとうまく運用できているように感じます。 そのうえで、git コマンドを勉強し始めた頃、「コマンドの説明はいっぱいあるけど、実務でどうコマンドを使うんだろう？」 と感じていたのを思い出しました。 そんな想いから、よく使う git コマンドを実務テイストで振り返ってみました。 本記事に書いていないもの 実務では使うのですが、諸事情により以下は省いています。 submodule 本当はこの記事に含めようかと思ったのですが、長くなりすぎてしまったので、需要がありそうだったら次回作に書こうかと思います。 プルリク コマンドの説明をしたいため、省きます。 Git Flow やら GitHub Flow やらの Flow 系の考え 説明がややこしくなってしまうので省きます。 developブランチ、maste
【初心者向け】UnityプロジェクトにGitを導入しGitHubと連携する手順 - naichi's lab
はじめに GitHubの価格が改定され、無料で非公開リポジトリが作れるようになりました。 Gitを使うとこんなことができます。 アセット入れたらおかしくなった！ -> 戻せます。（簡単） 昨日まで動いてたのに... -> 戻せます。（簡単） 突然PCが壊れた！！ -> 戻せます。（GitHubから別のPCに）（そこそこ簡単） WinとMacで作業したい -> できます。（ちょっと難しい） 複数人で共同開発したい -> できます。（ちょっと難しい） もしフォルダをコピーしてバックアップしているのなら、Gitを覚えると全く違った体験が待っています。 一人でバックアップ代わり使う分にはそんなに難しくないので多くの人にぜひ使ってほしいと思います。 この記事ではUnityプロジェクトを作ってからGitの初期設定を行い、GitHubにアップロード（プッシュ）するところまでを画像付きで紹介します。 今日
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
特定のブランチをもとに本番同様の動作確認ができる「レビュー環境」の話 - 弥生開発者ブログ
こんにちは。tkykです。 みなさん、コードレビューしていますか？今日はMisocaのレビュープロセスで用いられている、とっても便利な「レビュー環境」について紹介します。 Misocaのレビュー体制とその課題 MisocaではPull Request（以下、PR）ベースの開発体制をとっており、必ず他のエンジニアによるPRのレビューを経てから、masterへマージすることになっています。 レビュー時に動作確認をするには、エンジニア各自がローカル環境にブランチをチェックアウトして行うのですが、時にはそれだけでは不都合なケースもあります。 非エンジニアにも動作確認をしてほしい 動作確認をするための条件を整えたい 最終的にはマージされないコードを一時的に追加したい 依存するライブラリのバージョンを変更したい RAILS_ENV=production でビルド・実行したい などなど このようなケース
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
Gitでpushする前にテストが通る事を確認する - Tech Blog
ようやく暖かくなってきて春が近づいてきた感がありますが花粉症が辛い時期のiOSチームのかっくん(@fromkk)です。 そういえば先日のtry! SwiftはTimersのiOSチーム全員で参加してきました。 面白いトークばかりでしたが頑張って英語で聞こうとしたばかりにあまり理解が十分に出来なかった箇所もあるので動画が公開されたら振り返りたいなと思っています^^; 昨晩サーバーチームの人達と話をしていて、稀に Syntax error が発生したコミットをプッシュしてしまい開発サーバーでエラーが出てしまう事があるという話を聞きました。 iOSでもビルドエラーだったりPushした後にCIでテストが通らなくてSlackでテストが失敗した旨を通知されると悲しくなりますよね。。 リモートリポジトリにPushする前にエラーチェック出来ないかなと思って少しトライしてみました！ Git hookを利用
JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ
JetBrainsユーザーグループにて「IntelliJとYouTrack」というタイトルにて発表してきましたが、グダグダな発表をしたのでちゃんとまとめた記事を書きます。 jbugj.connpass.com 要点 JetBrains系IDEでは、標準に付属しているツールを用いることで、スマートに作業ができます。(なお、一部のIDEについてはリポジトリーからインストールしないといけなさそうです(GoglandにはTaskManagementプラグインが付属していないようだった)) Task Management プラグイン ITS(イシュー管理システム)とIDEを連携させてTask と Context を管理できるプラグイン Task - イシュー管理システムのチケットに該当する、作業の単位をあらわす Context - 開いているファイルのカーソルの位置や、プロジェクトツリーの開いている
iOS開発におけるgit flow - Qiita
iOS開発の際にgithub flowからgit flowへ移行したのでまとめておきます。 git flowとは git flowとは、Gitの機能であるブランチを活用したGitの開発手法でもあり、ツールの名前でもあります。 git flowは、役割ごとにブランチを使い分けます。 各ブランチの役割 master AppStoreで配布中の最新バージョンと同じです。 配布バージョンごとにタグを切ります。 develop 開発ブランチです。 developブランチからIssue毎にfeatureブランチを作成し、開発を進めます。 次期バージョンの要件を満たしたらreleaseブランチを作成します。 feature developブランチからIssue毎に作成します。 対象Issueの開発が終わるとdevelopブランチにマージします。 developブランチにマージしたタイミングで対象のfea
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
Emojiで楽しく綺麗なコミットを手に入れる | Goodpatch Blog
綺麗にコミットしてますか？？ はじめまして！Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何？ Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
俺的Androidアプリ開発の基本方針 ver 2016.Q3 - Qiita
前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Cloud9 - Your development environment, in the cloud
A cloud IDE for writing, running, and debugging code AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser. It includes a code editor, debugger, and terminal. Cloud9 comes prepackaged with essential tools for popular programming languages, including JavaScript, Python, PHP, and more, so you don’t need to install files
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Unity】Git でコミットする時に .meta が選択されていなければコミットを止めることができる「Unity Git Hooks」紹介 - コガネブログ
