以前大多个是一个的使用 Git, 到 Github 上提交的场景, 对多人开发合并项目经验不多,
现在遇到的是在 Github 上存在主分支, 本地需要修改多个功能和 bug 等等,
我是按以前实习回来的同学提示, 在多个分支开发不同的功能, 然后合并提交..
合并和提交的顺序不是确定的, 因此不能简单直接用 merge 每次一个个叠加.
有时我用 rebase, 但有发现 commit 顺序不是时间顺序, 到线上被 merge 以后也不是非常清晰
于是我想问一下面对这样的场景, 用怎样的方式管理会更合适?
有在 Google, 但一些细节不清晰.. 比如 commit 显示顺序.. 还有再次被 merge 后的细节..
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Git はさまざまな種類のワークフローをサポートしています。私たちが一般的に使用するのは、リモートでメイン ブランチを作成し、ローカルで機能するブランチを作成することです。
自分の作業ブランチに移動します$ git checkout work$ git checkout work工作
....提交工作分支的修改
$ git commit -a回到主分支
$ git checkout master获取远程最新的修改，此时不会产生冲突
$ git pull回到工作分支
$ git checkout work用rebase合并主干的修改，如果有冲突在此时解决
$ git rebase master回到主分支
$ git checkout master合并工作分支的修改，此时不会产生冲突。
$ git merge work提交到远程主干
$ git push仕事....
作業ブランチに変更を送信します🎜$ git commit -a🎜 🎜master ブランチに戻る🎜$ git checkout master🎜 🎜最新のリモート変更を取得します。現時点では競合は発生しません🎜$ git pull🎜 🎜作業ブランチに戻る🎜$ git checkout work🎜 🎜リベースを使用して変更をトランクにマージします。競合がある場合は、この時点で解決してください🎜$ git rebase master🎜 🎜master ブランチに戻る🎜$ git checkout master🎜 🎜現時点では競合することなく作業ブランチの変更をマージします。 🎜$ git マージ作業🎜 🎜リモートトランクにコミット🎜$ git Push🎜 🎜この利点は、リモート トランク上の履歴が常に線形であることです。誰もがローカル ブランチ上で競合を解決し、トランク上で競合を作成しません。 🎜上記の友人が与えた答えは非常に優れており、投稿者の参考のためにここにもう1つの情報を追加します。これは、Brother Ruan によって書かれたものです、[git ブランチ管理戦略](http://www.ruanyifeng.com/blog/2012/0...)。
変更を行う場合は、送信する前に
を使用してブランチ上で共同開発できます。 リーリーこのようにして、ローカルの変更はすべてスタックにキャッシュされ、他の人の変更は同期されます
リーリー次のステップは、変更を最新のノードに復元することです
リーリーその後、git commit を使用して送信すると、セーターを編むのではなく、ブランチのバージョンが順番に開発され続けます。この方法を使用する前と後の比較表を見てください。
前:
その後