タグ

関連タグで絞り込む (7)

タグの絞り込みを解除

DevelopmentとGitに関するflatbirdのブックマーク (13)

  • モノレポが流行っているらしい

    Monorepo(モノレポ)とは、アプリケーションやマイクロサービスの全コードを単一のリポジトリ (普通は Git) に保存するパターン マイクロサービスアーキテクチャの普及につれて、コードを多数のリポジトリに分割する (ポリレポ) チームが増えてきた 各マイクロサービスの開発チームはそれぞれ独立しており、それぞれの課題に合ったツールとプログラミング言語を使用する チームが 1 つだけでありその規模が小さければ、マイクロサービスを迅速に実装し、担当者が別々にデプロイを行なうことで、ソフトウェア開発のスピードを大きく高められる マイクロサービスの開発では、ポリレポが当然の選択肢に思える しかし、本当にそうだろうか？モノレポにはメリットが多い モノレポには次のようなメリットがある 見やすい: 全てのマイクロサービスのコードを閲覧可能。バグ発生時も正確な原因箇所を特定できる。 コードを共有できる

  • 改めて考える、「Gitのコミットメッセージを能動態や命令調で書く意味」

    改めて考える、「Gitのコミットメッセージを能動態や命令調で書く意味」：命令調のGitコミットメッセージの問題点とは TechTargetは「Gitコミットメッセージの能動態または命令調の書き方」に関する記事を公開した。「開発者はGitのコミットメッセージを命令形で書くべきだ」という意見があるが、本当にそうだろうか。言語的背景やオープンソースプロジェクトでの採用傾向などを踏まえて著者が問題提起する。

    改めて考える、「Gitのコミットメッセージを能動態や命令調で書く意味」

  • Conventional Commits

    Conventional Commits A specification for adding human and machine readable meaning to commit messages Conventional Commits 1.0.0 Summary The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer

  • 結局 Git のブランチ戦略ってどうすればいいの？ - Qiita

    1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

    結局 Git のブランチ戦略ってどうすればいいの？ - Qiita

  • https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25

    https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25

  • 分析チームのチーム開発 Mod

    Overview of ExAlg algorithm on Extracting Structured Data from Web Pages. Original worl by Arvind Arasu & Hector Garçia-Molina {arvinda,hector}@cs.stanford.edu . Presentation by Alessandro Manfredi & Marco Bontempi {a.n0on3,bontempi}@gmail.com

    分析チームのチーム開発 Mod

  • [社内新人向け]Gitで使ってほしくないコマンド - Qiita

    社内に新人が増えてきたので、弊社のWeb開発でのGitのゆるーい利用方針をまとめます。 本当はネガティブなことばかり書かずに、「覚えて欲しいコマンド、使ってほしくないコマンド」というタイトルにしたかったのですが、予想以上に長くなりそうなので分けます。 (追記：第二弾できました) →　[社内新人向け]Gitで絶対にオススメなプラグインや設定3つ 社内環境 Web系開発がほぼ100％ ブランチワークはGitflowをベースにしたプルリク駆動開発 少人数チームなので、エンジニアは全員LinuxのCUI操作をできて欲しい（vagrantや開発サーバ上の操作など） GitのGUIクライアントは、SourceTreeとGithub公式を試しましたが、初学者が使うと却って危ない挙動をしてしまうケースがあったので、全員CUI操作をしてもらうことにしました CIツールはまだ導入できず。各サーバーへのデプロイ

    [社内新人向け]Gitで使ってほしくないコマンド - Qiita

  • gitの良さがいまだに分からない - 負け犬プログラマーの歩み

    ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい

    gitの良さがいまだに分からない - 負け犬プログラマーの歩み

  • GitLab flowから学ぶワークフローの実践 | POSTD

    Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys

    GitLab flowから学ぶワークフローの実践 | POSTD

  • GitHub を用いた開発フロー テンプレート - ペパボテックブログ

    Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope

    GitHub を用いた開発フロー テンプレート - ペパボテックブログ

  • もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術

    はじめに gitはコミットごとにレポジトリ内のファイル全てをスナップショットとして保存するというリッチな 設計になっている。 それがgitの便利さの所以なのだが画像データや音声データのようなバイナリデータを持とうとすると 少しの変更でもそのたびにコピーが生じてファイルサイズ分の容量が増えることになり、あっという間にレポジトリが 肥大化してしまう。 特に学習結果をファイルに保持してテスト等に使いまわすようなプログラムを管理しようとすると アルゴリズムのパラメータを少し変えるたびに100kB近い容量が増えていき、実にイケてない。 普通なら.gitignoreに*.xmlと書いてデータ自体は手動管理したり、シンボリックリンクにして別ディレクトリに置いてそれだけrsyncで同期するようにしたりするんだが 過去の実験時の状態に戻れなかったり、毎回rsyncするのは不便だった。 なんか無いかなーと思っ

    もう巨大なデータをgitignoreしなくていい！ ~git-mediaの使い方~ - 3度の飯と最新技術

  • git による分散作業パターン | GREE Engineering

    分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

    git による分散作業パターン | GREE Engineering

  • 気になるGithubのリポジトリを5分間だけforkしてくれる『5 minute fork』 | 100SHIKI

    あぁ、これは便利。ひさびさにじんわり感動した！ Githubのリポジトリを見ていて「お、これは気になるけどデモページがない・・・でもforkするの面倒・・・」というシーンはよくある。 そうしたときに使えるのが5 minute forkだ。 しかも使い方がすごく簡単で、「https://github.com」を、「http://5minfork.com」に書き換えるだけだ（誰かブックマークレットはよｗ）。 ちょっと使ってみたが驚くほど便利である。なお、名前のとおり、5分間なにもいじらないと自動的に消去されるのも素敵である。 Githubの公式機能でもいいんじゃないか、と思わないでもないぐらい便利なので是非試してみて貰いたい。

    気になるGithubのリポジトリを5分間だけforkしてくれる『5 minute fork』 | 100SHIKI
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2025 Hatena. All Rights Reserved.