0. git 기초

Git의 대표적인 브랜치 전략 

• Git Flow        … 유연한 브랜치 구성이지만 복잡
• GitHub Flow … master 브랜치는 deploy가능한 상태를 유지하기에 최소 구성
• GitLab Flow  … develop, staging, production 브랜치등의 상용 전개를 의식
  ※ GitHub과 함께 사용하기에 GitHub Flow를 소개한다.

branch / commit 

main은 기본 브랜치로, 새로운 기능은 별도의 브랜치(dev-1 등)를 만들어 개발합니다. 작업 중에는 자주 커밋하여 복구가 쉽게 하고, 같은 파일을 여러 브랜치에서 수정하면 충돌이 생길 수 있으므로 주의합니다. 기능 구현 후에는 main에 병합하며, 그 전에 최신 main을 pull 하여 충돌을 방지합니다. 병합이 완료된 브랜치는 삭제하여 관리합니다.

 

 

설명하는 내용은 리모트와 연결되지 않은 로컬PC내에서의 git 의 설명이다.

1. 새 리포지트리를 생성 (이 폴더는 버전관리를 하겠다)

    git init

2. 새 파일을 생성

    A.txt

A.txt 은 아직 트랙킹받지 않은 상태이고 브랜치는 아직 설정되지 않음

 

3. 스테이징(add) : commit  준비를 위해 인덱스를 생성

    git add .      점(.) 은 모든 화일 서브 디렉토리를 스테이징

A.txt 는 unstage 상태, new file 로 인식되었고 아직 commit 되진 않았다.

4. commit : 상태 변화의 표식

   git commit -m "first commit"  -m 은 메세지

commit 이 됨과 동시에 자동으로 master 브랜치가 생성 할당 되었다.

HEAD 는 현재의 작업 브랜치를 가르키고 현재의 브랜치는 master 이다.
detached HEAD 의 멧세지가 나는 경우는 HEAD가 어느 브랜치도 가르키지 않고 있는 상태이다.

 

5. 새 브랜치의 생성

이제 main 은 기초 브랜치로 두고 새로 브랜치 dev_1를 생성해서 수정을 하도록 하자.

신명령(git 2.23 이후)	구명령
git switch -c dev_1	git checkout -b dev_1

 

 

6. A.txt 의 내용을 변경한 후 원래 내용으로 되돌리기

A.txt 의 변경내용 보기

git diff -- A.txt

 

① 스테이징(add) 전의 상태

신명령(git 2.23 이후)	구명령
git restore A.txt	git checkout -- A.txt
전체를 되돌리기
git restore .	git checkout .

 

② 스테이징(add) 후, commit 전의 상태

    git restore --staged A.txt

    git restore A.txt

 

③ commit 된 상태

 

 

옵션1) 화일변경, 스테이징, commit 을 모두 버리고 바로전의 commit 으로 HEAD 를 이동

     git reset --hard HEAD~

     ※ commit 을 새로운 브랜치로 되살리는 방법
          git reflog   이력표시
          git checkout -b 새로운브랜치명 삭제된commit해시코드

 

옵션2) 변경화일은 남긴채 스테이징, commit 만 버리고 바로전의 commit 으로 HEAD 를 이동

     git reset HEAD~

    ※ 스테이징이 사라졌기 때문에 commit 만 실행하면 에러 발생

 

옵션3) 변경화일,스테이징은 남긴채 commit 만 버리고 바로전의 commit 으로 HEAD 를 이동

     git reset -- soft HEAD~