某草草2017-05-02 09:49:26
皆さんはパブリック開発ブランチを持っていませんか?
dev から開発ブランチをプルします。開発が完了したら、全員がそれを dev にマージします。
競合と競合の解決があります。
高洛峰2017-05-02 09:49:26
まず第一に、ネイティブ git はブランチの作成とマージをサポートしています 1 そのため、git に基づくすべてのコード バージョン管理ツール (gitlab/github など) もデフォルトでブランチ機能をサポートしています(gitlabには権限管理機能も追加されます)
さらに、対象プロジェクトの大きな問題は @52lidan が言ったように dev ブランチがないため、コードのバージョン管理 (ブランチ A かどうか) が混乱します。 B または C が最良のメインですか?) したがって、件名への提案は次のとおりです: dev分支导致代码版本管理混乱(到底是A还是B还是C分支是最主要的?), 所以给题主的建议是:
项目要有如下的分支
master: 正式可以发布到生产环境的代码分支(protected)2
dev: 经过开发与初步测试后, 可以正常工作的代码分支, 用以合并所有人的工作以及已经修复的bug(protected)
每一个任务新建一个分支, 人跟着任务走而不是任务跟着人走. 也就是说, 在远程库上, 该任务只有一个分支, 并且所有人都拉取到本地上. 所有人关于该任务的工作都需要在本地commit后再推送到任务分支. (不建议一个任务有多于三人协作, 否则分解任务为更多的分支)
protected, 该分支只有项目中获得owner/master权限的人才能合并别人提交的merge request
<オル>
<リ>
master: 運用環境に正式にリリースできるコード ブランチ (保護されています) #🎜🎜#2#🎜🎜##🎜🎜##🎜🎜#
dev: 開発と予備テストの後、コード ブランチは正常に動作し、全員の作業と修正されたバグをマージするために使用されます (保護されています)#🎜🎜## 🎜🎜#
protected に設定できます。このブランチの owner/master 権限を取得したユーザーのみが送信をマージできます。他の人によって送信された マージ リクエスト ↩
#🎜🎜#
#🎜🎜#
曾经蜡笔没有小新2017-05-02 09:49:26
マージが先着順である場合でも、更新をリモート エンドにプッシュせずにローカル開発が完了した場合、どうやってマージを行うことができますか? 少なくともリモート エンドに b が存在する必要があります。そうでない場合は、それを a にマージします。しかし、これは良くありません
仅有的幸福2017-05-02 09:49:26
分岐には分岐点が必要です。分岐点から遠ざかるほど、理論上の矛盾が大きくなり、マージには人間の介入が必要になります。人間の介入なしにはマージできない分岐はありません。
