Git에 대한 자세한 설명 - 팀이 신속하게 아티팩트를 개발함

저는 학부에 재학 중인 학생입니다. 프로젝트 개발 과정에서 개발 효율성을 높이기 위해 Git 기술을 사용했습니다. 이제 git을 요약하겠습니다. 모두가 서로 소통할 수 있습니다.

git을 배우기에 앞서 먼저 git의 기본 개념

아래 그림과 같이 git의 작업흐름을 살펴보겠습니다

2. 몇 가지 기본 개념

• .git 디렉토리: git init를 사용하여 git Warehouse를 초기화할 때 생성됩니다. git 숨겨진 디렉터리에는 프로젝트 전체의 파일 변경 기록 등의 정보가 저장됩니다.

• Workspace: 로컬 git Warehouse가 위치한 디렉터리로 이해될 수 있으며, 프로젝트 디렉터리이기도 합니다.

• 스테이징 영역: git add 명령을 통해 추가된 모든 파일은 실제로 .git 디렉터리 아래의 인덱스 파일인 스테이징 영역에 저장됩니다.

• 저장소: 즉, 전체 Git 창고입니다.

• 세 가지 관계: 작업 공간은 개발 디렉터리이고, 편집된 모든 파일은 git add를 통해 준비 영역에 추가된 다음 git commit을 통해 로컬 git 저장소에 제출됩니다. 명령을 입력한 다음 git push를 통해 원격 git 저장소로 푸시합니다.

일반적인 git Warehouse 구조는 다음과 같습니다

git@git.xxx.com:user/project_name.git
|-master (마스터 브랜치, 온라인 코드와 동기화)
|-develop (development 브랜치, 기능 개발이 완료된 후 먼저 development로 병합되고 그 후 development가 master로 병합됩니다)
|-feature (임시 브랜치(함수 브랜치), 예를 들어 특정 기능을 개발하려면 새 기능 브랜치를 생성하고 완료 후 기능 브랜치를 개발에 병합할 수 있습니다)
|———— 기능/update_online_pay_api
|———— 기능/추가_새_기능..
|———— …
|-release (임시 브랜치(pre-release 브랜치), 개발 및 테스트 후, 테스트용 새 릴리스 브랜치를 생성하고 마스터에 병합하고 완료 후 개발)
|———— release/update_online_pay_api
|———— …
|-hotfix (임시 브랜치(핫 수정 브랜치), 일반적으로 버그 브랜치 등 단기 작업의 긴급 수정에 사용되며, 수정 완료 후 마스터에 병합하여 개발)

|———— hotfix /handler_pay_bug
|————…

브랜치 명명 규칙에 대해: 이름을 보고 이름을 알아두세요. 임시 브랜치는 '/' 또는 '-' 등으로 구분할 수 있습니다. 필수 요구사항은 없습니다.

제품 요구 사항을 받고 개발을 시작하면 git 프로세스는 다음과 같습니다.

먼저 원격 Git 웨어하우스에 있는 프로젝트를 로컬 프로젝트와 동기화해야 합니다.

cd ~/workspace/git/ // 进入你个人的工作目录
mkdir project_name // 新建一个目录用于存放代码，名称可以和远程仓库名称一样
cd project_name // 进入你新建的目录
git init // 使用git初始化这个目录为一个git仓库
git remote add origin git@github.com:22th/oh-my-zsh.git // 关联本地仓库到一个远程仓库
git fetch --depth=1 // 更新远程仓库的一些信息到本地，比如分支信息等
git checkout -b master origin/master // 检出一个分支master并关联远程的master分支
git pull // 更新本地仓库代码

위 과정을 통해 원격 프로젝트를 로컬에 동기화할 수 있습니다. 이제 기본적으로는 마스터 브랜치에서 코드를 수정할 수 없습니다. , 귀하에게는 이 권한이 없습니다. 코드를 로컬에 동기화한 후 비즈니스 요구에 따라 새 개발 브랜치를 생성해야 합니다. 예를 들어 새로운 기능을 개발하려면 feature-xxx를 생성합니다. 버그를 해결하려면 hotfix-xxx 브랜치를 빌드하면 됩니다. 로컬에서 새 브랜치를 생성하는 것은 권장되지 않습니다. Git 창고 관리 백그라운드에서 새 브랜치를 생성한 다음 로컬에서 체크아웃해야 합니다. 관리 백그라운드에서 새 브랜치를 생성하는 것은 매우 간단하므로 자세히 설명하지 않겠습니다.
그런 다음 새로 생성된 브랜치를 로컬에서 확인합니다. 명령은 다음과 같습니다. git checkout -b feature-xxx origin/feature-xxx

다음 단계는 행복한 개발 프로세스입니다. 자체 브랜치에서 개발하고 테스트한 후 제출하면 됩니다. 사용된 git 명령은 다음과 같습니다.

git add <file> // 将工作区修改添加到暂存区，加上 --all 参数表示将所有修改添加到暂存区
git commit -m “msg” // 将暂存区的修改添加到版本库
git push -u origin feature-xxx // 将本地仓库中的修改推送到远程
git status // 查看当前工作区间状态
git log // 查看历史commit
git checkout -- <file> // 用最后一次commit的文件替换当前工作区间的文件
git reset --hard // 丢弃工作区间所有修改，回滚到上一个commit状态
git checkout <版本号> // 回滚到指定版本

기능을 개발할 때 이를 온라인으로 테스트하고 게시해야 합니다.

1. 새 release-xxx 브랜치를 생성합니다. git 창고 관리 배경. feature-xxx 분기를 기반으로 하며 주로 테스트에 사용됩니다.

2. release-xxx 테스트가 성공하면 마스터로 병합하고 브랜치를 개발할 수 있습니다. 일반적으로 git 창고 관리 백그라운드를 통해 병합 요청을 제출하고 관련 관리 담당자의 확인을 기다립니다. , 마스터에 병합하고 병합 요청을 제출하기 전에 먼저 마스터 브랜치를 병합하여 마스터에서 새로 수정된 코드가 동기화되는지 확인하세요. 마스터를 병합할 때 충돌이 발생할 수 있습니다. 충돌하는 파일을 찾아 해결하고 커밋합니다. 충돌 형식은 다음과 같습니다.

<<<<<<< HEADln -s ../statics xxx
=======ln -s ../statics statics
>>>>>>> master

여기서 «<<< HEAD와 ======= 사이의 내용은 브랜치의 코드를 나타내고 ======= 및 »» »> master는 마스터 브랜치의 코드를 나타냅니다. 그런 다음 충돌을 수동으로 해결하는 과정은 유지하려는 코드를 확인하고 다른 을 삭제하는 것입니다. 즉, 로컬 코드를 유지하려면 다음과 같습니다.

<<<<<<< HEAD （删除）
ln -s ../statics xxx （保留）
======= （删除）
ln -s ../statics statics （删除）
>>>>>>> master （删除）

保留 «««git commit -am “解决冲突”。
3、好了，其他的工作就是运维人员来处理了。一般是这样的，release-xxx分支测试完成并解决所有冲突后，运维发布人员merge到master分支，然后通过 git d<a href="http://www.php.cn/wiki/109.html" target="_blank">if</a>f 608e120 4abe32e --name-only | xargs zip update.zip 命令打包差异文件，然后发布这个差异文件包就可以啦，不需要所有文件都覆盖线上文件。

---

到这里，整个git项目开发流程就已经非常清楚了。git还有很多高级功能，比如文件对比、文件历史修改记录、关联多个远程仓库等等需要你慢慢去摸索了。使用git要灵活运用分支，因为git新建切换分支的成本非常低，因为git新建分支不是想svn那样吧整个目录复制一遍，然后通过索引文件等更高级的方式来处理，效率高太多。

在推荐个git图形化管理工具：
source tree， mac和windows都有。

---

If you liked this article and think others should read it, please follow webff

위 내용은 Git에 대한 자세한 설명 - 팀이 신속하게 아티팩트를 개발함의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!