GitHub: リポジトリ共有 or fork? - Qiita
はじめに githubのコラボレーションには、 チームメンバーでプロジェクトリポジトリを共有する 個々の開発者がプロジェクトリポジトリをforkする の２つの方法があると思います。 OSSプロジェクトのような見知らぬ人とコラボレーションするプロジェクトの場合はfork一択ですが、社内で使うときや外注先との共同作業などのときはどうするのが良いのでしょうか？ リポジトリ共有の場合 プロジェクトリポジトリ内にブランチが作られるので、マージ済みのブランチは定期的に削除するなどしないと、リポジトリのサイズが肥大する。 権限の管理ができない。基本的にプロジェクトリポジトリ内のすべてのブランチの権限がチームメンバーに与えられる。protected branchesに設定することもできるが、個々のブランチごとに設定する必要がある。protected branchesに設定すると、プルリクエストによる承認を
git rebase でヒストリを直線的にする方法と使う時の注意点
git rebase でヒストリを直線的にする方法と使う時の注意点 作成日 2018.08.13 更新日 2018.08.14 Git Git の強力なコマンド rebase を使ってヒストリを直線的にして見やすくする方法と, そのコマンドを使うときに知っておきたい, 知らないと他のコントリビュータの人たちから一斉に非難を浴びてしまう可能性がある注意点を紹介します. git rebase の使い方 git rebase はいくつかに分岐したブランチを直線的にして git log などでヒストリを見たときに見やすくしてくれるとても便利なコマンドです. ただ使用時には注意点もあるので, それも後々紹介させていただきたいと思います. まず git rebase の基本的な使い方を紹介します. 次のようなヒストリで:
DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD
Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
