例如,我在开发 feature/user
用户管理模块,提供用户的名称,信息等等, 我的同事在开发 feature/login
登录系统,他需要我的用户模块来检测是否可以登录,获取用户信息等等。
问题1:
假设我已经完成了用户系统,那么怎么给我的同事让他使用?
难道是我先 finish
, 同事再 finish
, 同事再 start
么?不太现实。
问题2:
假设我没有完成用户系统,但是我完成了同事所需要的内容,那怎么给他使用?
难道是我先 finish
, 同事再 finish
, 我和同事再 start
,分别继续开发么?
这些有什么好的解决方案么?
补充:首先主要是时间太紧张了,一个人肯定写不来,所以要多个人一起,可是多个人又会牵扯依赖问题。所以想知道如何解决这个问题。
同じプロジェクトで開発しているかどうかについては触れていないので、同じプロジェクトで作業していると仮定して説明します。以下の点を理解しているかどうかを確認してください。
git のノードは等しい
git は ssh、http、file およびその他のプロトコルをサポートします
私の提案:
ジョンとジェーンが同じプロジェクトで共同作業しているとします。
リーリージョンはプロジェクトのデモを作成し、それは彼の個人ディレクトリにあります。
リーリージェーンとジョンが同じ開発マシン上にある場合、彼女はジョンのコードを自分の家に直接複製できます
リーリーこれで、ジョンは開発を続けることができ、ジェーンも開発を続けることができ、両方とも提出を続けることができます。
Jane は John のコードを直接複製したため、git は当然、Jane のディレクトリに別の開発者のアドレスを記録し、その具体的な内容は .git/config にあります。Jane は、origin を直接取得できます。元のソースからのすべての更新を彼女自身のコードに変換します;
- 問題は、John も Jane のコードを必要とする場合はどうなるかということです。John の git プロジェクトには他の開発ノード情報がないため、追加後にいつでも Jane の更新を取得することができます。
これで、ジョンとジェーンはお互いのコードを自分のフォルダーに取り込んで楽しく開発できるようになりました。リーリー
この要件は分業と矛盾すると思います
モジュールは別のモジュールに強く依存しているため、待機する必要があります。
それでは、ニーズを調整してください
これが標準的な手順です完了後にユーザーモジュールを送信できます
この時点で、モジュールを分岐して続行します
あなたの同僚はモジュールを分岐して続行します#🎜 🎜 #
この種の環境に対処するために、下方向に拡張する概念を参照できます。
へ
この状況では、この方法をお勧めします:
feature/user
ブランチから新しいブランチfeature/user_login
を開きますfeature/user
開発が使用可能な段階に入ったとき feature/user_login が使用されている場合は、コードをfeature/user_login
にマージします。場合は
feature/user_login
を直接テストできます。 code>feature/user_login が開発されました 完了したら、feature/user
にマージします最後に
feature/user
を完成
しますfeature/user
分支上开出一个新的分支feature/user_login
当
feature/user
开发进入到可用的阶段时, 把代码往feature/user_login
上合并这样
feature/user_login
可以直接进行测试当
feature/user_login
开发完毕后,合并到feature/user
上最后
finish
feature/user
这样是将
このように、feature/user_login
作为feature/user
的一个子功能开发的如果再做功能的时候不是这样设计的, 那最好还是将
feature/user
finish
后再开发feature/login
feature/user_login
はfeature/user
のサブ関数として開発されます関数がこのように設計されていない場合は、次を使用するのが最善です
機能/ユーザー
終了
し、機能/ログイン
を開発します🎜