[B! Development][git] flatbirdのブックマーク

flatbird id:flatbird

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

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

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

development
リンク
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
flatbird 2024/10/05
github

git

development

programming
リンク
結局 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 ブランチバグ修正など緊急時に対応するためのブ
flatbird 2024/09/29
github

git

development
リンク
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25
flatbird 2017/11/26
Git

development
リンク
分析チームのチーム開発 Mod
2024 Trend Updates: What Really Works In SEO & Content Marketing
flatbird 2017/04/20
Development

git

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

GitHub

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

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

Git

development

workflow
リンク
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
flatbird 2014/05/01
development

github

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

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

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

Git

development
リンク
1