例如，我在开发 feature/user 用户管理模块，提供用户的名称，信息等等， 我的同事在开发 feature/login 登录系统，他需要我的用户模块来检测是否可以登录，获取用户信息等等。
问题1：
假设我已经完成了用户系统，那么怎么给我的同事让他使用？
难道是我先 finish， 同事再 finish， 同事再 start 么？不太现实。
问题2：
假设我没有完成用户系统，但是我完成了同事所需要的内容，那怎么给他使用？
难道是我先 finish， 同事再 finish， 我和同事再 start，分别继续开发么？
这些有什么好的解决方案么？
补充：首先主要是时间太紧张了，一个人肯定写不来，所以要多个人一起，可是多个人又会牵扯依赖问题。所以想知道如何解决这个问题。
巴扎黑2017-05-02 09:30:14
同じプロジェクトで開発しているかどうかについては触れていないので、同じプロジェクトで作業していると仮定して説明します。以下の点を理解しているかどうかを確認してください。
git のノードは等しい
git は ssh、http、file およびその他のプロトコルをサポートします
私の提案:
ジョンとジェーンが同じプロジェクトで共同作業しているとします。
ジョンはプロジェクトのデモを作成し、それは彼の個人ディレクトリにあります。
ジェーンとジョンが同じ開発マシン上にある場合、彼女はジョンのコードを自分の家に直接複製できます
これで、ジョンは開発を続けることができ、ジェーンも開発を続けることができ、両方とも提出を続けることができます。
Jane は John のコードを直接複製したため、git は当然、Jane のディレクトリに別の開発者のアドレスを記録し、その具体的な内容は .git/config にあります。Jane は、origin を直接取得できます。元のソースからのすべての更新を彼女自身のコードに変換します;
リーリー
高洛峰2017-05-02 09:30:14
この要件は分業と矛盾すると思います
モジュールは別のモジュールに強く依存しているため、待機する必要があります。
それでは、ニーズを調整してください
完了後にユーザーモジュールを送信できます
この時点で、モジュールを分岐して続行します
あなたの同僚はモジュールを分岐して続行します#🎜 🎜 #
継続的インテグレーションと呼ばれる概念があります。統合操作が早く実行されるほど、コードにとって有利になります。
この種の環境に対処するために、下方向に拡張する概念を参照できます。
へ
我想大声告诉你2017-05-02 09:30:14
この状況では、この方法をお勧めします:
feature/user ブランチから新しいブランチ feature/user_login を開きます feature/user 開発が使用可能な段階に入ったとき < code>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 のサブ関数として開発されます機能/ユーザー 終了し、機能/ログインを開発します🎜