[temp] 03. Git / GitHub

temp.WUI·2021년 8월 1일
gitgitflowgithub
0

temp

목록 보기
3/12
post-thumbnail

GIT

VCS (Version Control System)

  • 빠른 속도, 단순한 구조
  • 분산형 저장소 지원
  • 비선형적 개발 가능 (수천개의 브랜치)

git objects

  • Blob : 파일 하나의 내용에 대한 정보
  • Tree : 해당 Blob의 기록들 (메타데이터)
  • Commit : 모음, 의미 있는 변동사항들의 덩어리

git file status

깃으로 추적하는 4가지 파일의 상태

추적안됨, 수정함, 수정없음, 스테이지됨

  • $git add는 수정함과 추적안됨 파일을 스테이지로 업로드 할 수 있는데

    add하면 스테이지됨 파일상태가 된다.

  • $git commit 을 하면 수정없음 상태로 돌아가 다시 파일을 수정할 수 있음.

깃은 변경사항의 모음이 아닌 모든 전체의 모음이다.

그럼에도 용량이 무겁지 않은 이유는 변경되지 않은 파일은 변경되지 않음만을 표시해 저장하기에 같은 파일이 두 번이상 저장되지 않기 때문이다.

한번 스테이지에 올라간 파일들은 수정되지 않아 add를 하지 않아도 계속 스테이지에 존재 하기 때문에 커밋을 전체의 묶음으로 볼 수 있다.

기록해야 하는 변경사항 두개가 있을 때 add 를 사용해서 특별한 것만 stage에 올리고 commit 을 찍어 두번으로 나눠줄 수 있다.

빈 디렉토리

원래 git은 빈 디렉토리를 Tracking 하지 않는다.

그렇기에 폴더안에 어떠한 파일이라도 존재하고 그 파일이

커밋이 되어야 remote repo에 올릴 수 있다.

git process

작업해서 메모한 뒤 넘긴다.

오프라인 (local)

  1. working directory : 코딩 및 작업 단계

  2. staging area : git에 올라갈 파일들을 설정

  3. local repo : commit으로 기록을 남김

    → 인터넷에 연결되어 있지 않아도 개발자가 언제 무엇을 했는지 기록을 저장해 둔다.

온라인 (remote)

  1. remote repo : github에 업로드 한다.

github

git ≠ github

git을 이용한 클라우드 서비스

라이센스

  • MIT : 자유로운 수정 재배포 가능

  • Apache : 수정배포 가능하나 원작자 표기

  • GNU GPL 라이센스가 전염

    → 이 라이센스가 들어간 코드를 사용하면 무조건 GPL 라이센스를 사용해야 함

커밋 컨벤션

commit write in english....

  • 제목은 50자 이내로

    모든 내용을 한 눈에 파악할 수 있게 핵심적인 구나 절의 형태로

  • 제목과 내용 사이는 한칸 줄바꿈 공간을 두기.

  • prefix를 사용하여 커밋의 용도를 작성해 둔다.

    • PREFIX

      feat (features) - 기능이 추가 되었을 때
      docs (documentations) - README.md 같은 텍스트 작업
      conf (configurations)
      test (test) - 테스트를 돌린 결과물
      fix (bug-fix) - 디버그를 하거나 이슈가 해결되었을 때
      refactor (refactoring) - 문법적인 개선점을 주었을 때 (5줄의 실행을 1줄로 줄이거나)

      ci (Continuous Integration)
      build (Build) - 배포 전 마무리 단계
      perf (Performance) - 성능개선
      asset (asset) - 파일 업로드
      style (style) - 코드 포맷팅, 세미콜론 누락, 코드 변경 없음

git commit

기본 설정

$git config — list 목록들을 확인할 수 있음

$git config —global user.email {email.-@email.com} "{이메일}"

$git config —global user.name {name} "{이름}"

$git config —global core.editor "vim"

$git config —global core.pager "cat"

local과 remote의 repo 이름은 통일 시킨다.

create repo

  1. git init

    $git init → $ git remote add origin {url}

    ▶ $git init 명령어로 현재 폴더에 local repo를 생성한다.

    한 폴더에 하나의 local repo만 유지해야 한다.

    상위 폴더 안에 들어 있는 하위 폴더에 repo를 생성하면 상위 폴더 repo에 종속된다.

    • repo가 생성되었는지 확인하는 방법

      1. $git status 수정된 파일이 있는 지 확인하는 명령어

        $git status -uall 수정된 파일이 어떤 파일인지 풀어서 설명

      2. ls -a

        .git 파일이 존재하면 repo가 생성된 것이다.

    ▶ $git remote add origin {url} 명령어로 remote repo와 연결해 준다.

    origin이라는 이름의 링크를 연결해 준다라는 뜻이다.

    origin은 clone 사용 시 자동으로 생성되는 이름이다.

  2. git clone

    $git clone {remote repo's url}

    git clone으로 remote repo를 복사한다면 repo의 이름으로 폴더가 생성된다.

    현재 폴대에 풀기 위해서는 $git clone {remote repo url} .

    (현재 폴더가 빈폴더일 때만 가능합니다.)

    자동으로 origin이라는 이름의 원격저장소가 등록되게 됩니다.

branch name

github의 branch default 설정은 main 이다.

local repo와 remote repo의 branch 이름을 통일 시켜야 한다.

$git branch 현재 브랜치의 이름을 확인하는 명령어

$git branch -M name 현재 브랜치의 이름을 바꾸는 명령어

commit

[offline]

  1. stage 에 수정 된 파일 올리기

    $git add file-name

    $git add . 전체파일 선택

    커밋 분기점을 자르기 어려워질 수 있으니 조심히 사용할 것

  2. stage 의 파일의 커밋 메세지 작성하기

    $git commit→ vim이 뜬다.

  3. commit 확인하기

    $git log 커밋된 목록과 내용을 확인 할 수 있는 명령어

커밋은 의미있는 수정을 분기로 작성하는 것이 좋다.

[online]

  1. $ git push -u origin {branch-name}

    -u 는 local과 remote의 repo를 연동시키는 명령어로

    해당 브랜치로 push 하는 처음 한번만 하면 된다.

    $git push origin main

push 는 최소 기능 단위로 올리는 것이 좋다.

code review

branch

메인 브렌치에서 만들어진 분기점 🌌평행 우주같은 느낌

  • 여러 사람이 개발하기에 좋다.

merge

새로운 코드가 작석된 compare(최신 브랜치)를 base(기존 브랜치)와 합친다.

  • $git merge (compare) 합집합

review → pull request

  1. 브랜치 생성

    $git branch 현재 브랜치 위치 확인

    $git branch {create branch} 새로운 브랜치 생성

    $git switch {branch} 브랜치 이동

→ 새로운 브랜치에서 커밋을 작성 후 push

  1. pull request

    • 리뷰어 설정하기

      repo의 setting → manage access → 리뷰어 추가

    • pull reguest 제출

    • review 해결 후 승인 요청

    • 스스로 혹은 리뷰어의 merge

      merge가 된 remote repo의 업데이트 상태를 local repo에 적용하기

      1. $git fetch origin main

        remote repo에 있는 내용을 임시 branch인 FETCH_HEAD 에 담는 명령어

        → switch FETCH_HEAD 로 이동해서 최신 내용을 확인할 수 있다.

      2. $git merge FETCH_HEAD FETCH_HEAD 에 있는 내용을 현재 local repo에 merge 해서 업데이트가 된다.

        ---

        == $git pull

        pull은 위의 두 명령어를 합친 것과 같은 기능을 한다.

        Branch

새로운 기능을 개발하거나 할 때 main brach 혹은 develop branch가 아닌 feature branch를 생성 후 작업을 해야 한다.

  1. create branch

    git branch {생성할 브랜치 이름}

  2. move branch

    git switch {이동할 브랜치 이름}

  3. merge branch

    main branch로 이동 후 → git merge {작업이 끝 난 feature branch}

  4. delete branch

    git branch -d {삭제할 브랜치 이름}

  • 브랜치에서 코드 리뷰가 필요하지 않는 이상 cli에서 merge 한 뒤 push는 main에서 진행한다.

    합치기 전 정상 작동이 된다는 것이 확인된 상태이기 때문에 굳이 깃헙에 새로운 브랜치를 추가하지 않기 위해서?

  • 파일 수정 후 add나 commit 없이 브랜치를 옮기게 된다면 수정 사항이 따라와서 브랜치를 더럽히게 된다.

    → 그럴 경우 다시 파일 수정이 일어난 브랜치로 이동 후 add나 commit 을 진행해준다.

Branch Collision

  • 같은 파일이 동시에 수정이 된 경우 발생하게 된다.

    자동으로 합쳐지지 않았기 때문에 직접 코드를 보고 합쳐서 사용할지, 이전 것을 사용할지, 새로운 것을 사용할 지 선택해야한다.

    가운데 선을 중심으로 위쪽은 이전 코드 아래쪽은 새로운 코드이다.

수정이 완료된 후에는 꼭 커밋을 찍어줘야 한다

Before Push 변경 및 수정

파일이동 혹은 이름을 바꿔야 한다면 git 명령어를 사용해서 이름을 바꿔야 한다.

  • git mv 바뀌기 전 이름 바뀔 이름

    해당 명령어를 사용하면 renamed라는 스테이지 상태를 확인할 수 있다.

  • git rm 은 스테이지에 있는 파일을 삭제할 때 사용

  • 스테이지에 있는 파일을 내릴 때

    git restore --staged 돌리고 싶은 파일 이름

  • 이전 커밋으로 돌아가기

    git checkout .

  • 갓 작성한 커밋 수정

    git commit --amend 푸쉬하기 전에만

이전 커밋으로 돌아가기 REVERT

그 전 시점으로 돌렸다고 기록을 남긴다.

git revert --no-commit HEAD~3

최신커밋으로부터 몇개를 돌릴 건지 하나전이면 HEAD~1

--no 는 커밋 한개로 여러개 돌릴 때 사용 (원래는 한 커밋당 하나 작성해야하기에)

  • 파일을 삭제해야 한다면 다른 팀원들에게도 알리기 위해서 기록을 남기는 것이다.

    reset은 지웠다는 기록도 삭제하게 된다.

    커밋도 파일도 삭제되지만 기록을 남길 수 있다면 revert

    [Git] reset과 revert 알고 사용하기

.gitignore

gitignore.io

gitignore.io 에서 만들어진 코드들을 .gitignore파일에 붙여 넣어준다.

gitignore 파일에서 설정된 파일들은 깃 스테이트가 안되기 때문에 깃헙의 파일 용량을 줄일 수 있다.

braching models

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

git-flow cheatsheet

git flow

  • master(main) : 제품으로 출시될 수 있는 브랜치
  • develop : 다음 출시 버전을 개발하는 브랜치
  • feature : 기능을 개발하는 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

  1. git flow init → main과 develop branch 생성 → develop으로 이동

  2. git flow feature start helloworld 개발용 feature 브랜치 생성 → feature이동

  3. git flow feature finish helloworld 닫고 develop에 머지 → 브랜치 지우기

  4. git flow release start {v0.1} develop에서 release branch 생성

  5. git flow release finish v0.1 main과 develop으로 합쳐짐

    • v1.0

      소수점 뒷자리 : 마이너한 업데이트 (버그 수정)

      앞자리: 큰 기능 업데이트 (게임 같은 경우 시즌이 달라진다.)

    → 1번째 머지 커밋 저장하고 나감 (main)

    → 태그를 적으라는 2번째 창이 뜸

    태깅을 위한 커밋창

    • === 패치 노트

    →3번째 디벨롭으로 머지 커밋창

    →각 브랜치 위에서 푸쉬로 remote

  6. git push --tagstag도 푸쉬

Summary of actions:
- Release branch 'release/v0.1' has been merged into 'main'
- The release was tagged 'v0.1'
- Release tag 'v0.1' has been back-merged into 'develop'
- Release branch 'release/v0.1' has been locally deleted
- You are now on branch 'develop'

위 창이 뜨면 성공적으로 합쳐졌다는 것이다!

→ develop은 자신의 remote develop에 push

→ main은 자신의 remote main 에 push

Squash Merge

메인 브렌치의 관점에서

메인 브렌치의 커밋을 통해 머지된 커밋들이 어떤 형상을 가진지 비교해보면 아래와 같습니다.

  • Merge

    • Merge : 커밋 m에서부터 뒤로 되돌아가면서 부모를 모두 찾아 브렌치를 구성. 커밋 m은 부모로 c, Init을 가지고 있으며, c는 b, b는 a, a는 Init을 다시 부모로 가짐. 이 형상을 모두 backtrace 하여, Init -> a -> b -> c -> m이라는 구조를 만들고 이 구조가 모두 히스토리에 남음.

  • Squash and Merge

    • Squash and Merge : 커밋 'a,b,c' 는 Init만을 부모로 가진 단일 커밋. 작업했던 브렌치의 a, b, c 커밋들은 머지 후의 메인 브렌치 커밋 Init, 'a,b,c' 와 아무런 연관을 가지지 않음.

  • Rebase and Merge

    • Rebase and Merge : 커밋 a, b, c 의 관계를 그대로 유지한 채, 메인 브렌치에 그대로 추가. 커밋 a는 부모로 커밋 e를 가짐. Rebase and Merge 작업 후에는, 작업했던 브렌치의 a, b, c 커밋들은 머지 후의 메인 브렌치의 Init, d, e, a, b, c 커밋들과 연관 관계를 가지지 않음.

Git Flow

  • Git Flow 를 따른다고 했을 때, 아래와 같이 정리할 수 있습니다.
    • develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지 후에 feature 브렌치를 삭제해버리는 점을 떠올려 보면, feature 브렌치의 커밋 히스토리를 모두 develop 브렌치에 직접 연관 지어 남길 필요가 없습니다.
    • main - develop 브렌치간 머지 : Rebase and Merge가 유용합니다. develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문입니다.
    • hotfix - develop, hotfix - master 브렌치간 머지 : Merge 또는 Squash and Merge 모두 유용합니다. 때에 따라 골라 사용하면 좋을 것 같습니다. hotfix 브렌치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용하면 됩니다.

협업

Collaboration보다는 주로 Fork를 사용하는 작업이 많다.

  • fork: 사본을 만들고 진행 (포크로 작업할 때도 원본의 양식을 지키는 것이 좋다.)
profile
temp.WUI
🧩 temp repo
이전 포스트

[temp] 02. MarkDown

다음 포스트

[temp] 04. HTML

0개의 댓글