以前大多个是一个的使用 Git, 到 Github 上提交的场景, 对多人开发合并项目经验不多,
现在遇到的是在 Github 上存在主分支, 本地需要修改多个功能和 bug 等等,
我是按以前实习回来的同学提示, 在多个分支开发不同的功能, 然后合并提交..
合并和提交的顺序不是确定的, 因此不能简单直接用 merge 每次一个个叠加.
有时我用 rebase, 但有发现 commit 顺序不是时间顺序, 到线上被 merge 以后也不是非常清晰
于是我想问一下面对这样的场景, 用怎样的方式管理会更合适?
有在 Google, 但一些细节不清晰.. 比如 commit 显示顺序.. 还有再次被 merge 后的细节..
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Git은 다양한 종류의 워크플로를 지원합니다. 기본 브랜치를 원격으로 생성하고 로컬에서 기능 브랜치를 생성하는 방법은 다음과 같습니다.
자신의 작업 지점으로 이동
$ git checkout work일
....작업 지점에 변경 사항 제출
$ git commit -a본점으로 돌아가기
$ git checkout master최신 원격 수정을 받으십시오. 현재로서는 충돌이 발생하지 않습니다
$ git pull작업 지점으로 돌아가기
$ git checkout work리베이스를 사용하여 변경 사항을 트렁크에 병합하고 이때 충돌을 해결합니다.
$ git rebase master본점으로 돌아가기
$ git checkout master작업 지점의 수정 사항을 병합하면 현재로서는 충돌이 발생하지 않습니다.
$ git merge work원격 트렁크에 커밋
$ git push이것의 장점은 원격 트렁크의 기록이 항상 선형적이라는 것입니다. 모든 사람은 로컬 브랜치에서 충돌을 해결하고 트렁크에서는 충돌을 일으키지 않습니다.
위 친구의 답변이 매우 좋습니다. 포스터 참고용으로 여기에 또 다른 정보를 추가하겠습니다. 이것은 Ruan 형제가 쓴 [git 지점 관리 전략](http://www.ruanyifeng.com/blog/2012/0...)입니다.
브랜치에서 함께 개발할 수 있습니다. 변경 시 제출하기 전에
을 사용하세요. 으아아아이런 방식으로 모든 로컬 수정 사항이 스택에 캐시된 다음 다른 사람의 수정 사항이 동기화됩니다.
으아아아다음 단계는 변경 사항을 최신 노드로 되돌리는 것입니다
으아아아그런 다음 git commit을 사용하여 제출하면 스웨터를 뜨개질하는 것처럼 브랜치의 버전이 계속해서 순서대로 개발됩니다. 이 방법을 사용하기 전과 후를 비교해 볼 수 있습니다
이전:
이후
