Git Seminar Summary

11291 단어 협업gitVCSVCS

git 공부에 유용한 링크

연습문제 링크

Git?

VCS(버전관리 시스템) : 좀 더 정확하게는 분산형 버전관리

  • 어떤 파일이 어떤 형식으로 변하는지 확인하는데 용이
  • 작업의 흐름을 쉽게 볼 수 있음

중앙 저장소를 하나 두고 모든 컴퓨터에 버전을 저장해둔다

각각의 커밋은 아이디를 가진다.(hash 형태로)

  • git checkout “hashnumber” : 이전 버전으로 롤백

파일의 상태

untracked

  • 추가가 안된 상태 - 현재 이 파일은 디렉토리에 있지만 git에서 관리 되고 있지는 않음

staged

  • 커밋의 후보를 정해줄 수 있음
  • 후보로 선택된 상태가 staged 상태이다.
  • 커밋 준비된 상태

unmodified

  • 커밋 됨

modifed

  • 커밋 됐고 수정 됨

명령어

git add 파일명

git commit -m 메세지

Git Tree

협업

  • 일자형 작업이 아니라 트리형으로 작업하는 방식
  • 나중에 하나로 합쳐짐

Head의 움직임

  • git checkout : 노드는 가만히 있고 head가 움직이게 됨

git tree를 갈라치기 하는 방법(분기하는 방법)

  • branch를 추가로 만들수 있다.
    • git branch 브랜치이름
  • 서로 다른 branch는 각자 다른 길을 간다.

checkout

  • 현재 내 헤드의 위치를 결정하는데 헤드의 위치를 정해서 내 커밋의 방향을 정한다.
  • git checkout 커밋id

⚠️Detached Head

커밋을 해주면 head는 main에서 분리된 상태로 커밋을 하는 족족 나아간다.

이때 checkout으로 main으로 돌아가면 그동안에 커밋 된 파일들은 날아간다. (가비지 콜렉터)

이를 방지하려면 새로운 branch를 만들어서 이를 참조하게 한다.

임시 생성된 branch는 나중에 없애면 된다.

상대 참조(^,~)

  • HEAD^^
    • ^ - 부모
  • HEAD~2
    • ~ - 한칸 위
  • 헤드 뿐만 아니라 브랜치도 가능하다
  • git checkout bugFix^

Merge, Rebase

  • merge : 마지막에 하나 노드 추가해서 합쳐줌
    • merge [내가 흡수할 branch]
  • rebase : 어떤 대상 뒤에 연결해서 합쳐줌
    • rebase [나를 흡수할 branch]

Merge Conflict

  • 같은 파일을 서로 다른 브랜치에서 커밋하고 나서 merge 할때 일어남
  • ->M<-
  • 충돌 상황

  • 충돌된 파일 수정

  • 다시 add하고 commit

커밋 수정

git reset

  • git reset —soft HEAD^
    • staged 상태로 되돌림
  • git reset —mixed HEAD^
    • 리셋의 디폴트
    • 헤드가 가리키고 있는 커밋을 add 직전의 상태로 만들어줌
  • git reset —hard HEAD^
    • 파일 자체를 삭제해버림 (디렉토리에서 삭제됨)
    • 위험 (웬만해선 비추)

git revert

  • 되돌리긴 하는데 새로운 커밋을 만들어서 되돌림

git amend

  • 가장 최근의 커밋에 덮어 씌우기

커밋 무시

.gitignore

위 사이트에서 원하는 gitignore을 설정할 수 있다.

폴더(디렉토리)의 커밋

일반적으로 폴더는 커밋이 불가능하다.

커밋은 되고 아무 기능 안하는 “빈 파일”을 만들어 놓자

.gitkeep


커밋 편집하기

git rebase —i

  • vi 창이 뜨면서 커밋번호, 기록이 주루룩 뜸
  • gitLens, sourceTree로 편리하게 작업 가능
  • reword : 커밋메세지를 바꾸기
  • squash : 자잘자잘한 여러가지 커밋을 한번에 합쳐버림
  • drop : 커밋 삭제
  • edit : 이 커밋을 수정하겠다.
  • git commit —amend : 현재 커밋에 수정한 것을 덮어쓰겠다.

git cherry-pick

  • 딱 하나의 커밋의 수정사항만 가져옴
  • 현재 헤드의 위치의 뒤에 가져오게 됨 (헤드의 위치 고려)

Git Branch 전략

Github-flow

  • 1개의 master(main)가 핵심, 항상 master(main)은 최신
  • 어떤 브랜치에서 main으로 merge 될 때는 항상 신중해야함
  • pull request
    • github-flow 전략에서 사용됨
    • 협업에서 합쳐도 되는지 요청하는 것
    • 코드 충돌 예방
    • 추가적인 기능들을 테스트 할 수 있음.

GitFlow (유명함)

  • SourceTree에서 초기 설정을 해주는 기능이 있음

  • 체계적으로 기능들을 세분화해서 나눈 전략. 역할에 따라 브랜치를 나눔

  • branch 구분

    master : 제품
    hotfixes : 버그수정
    release : 출시 후보(QA, 코드리뷰, 피드)
    develop : 다음 버전을 위해서 개발, 다음버전, 개발중...
    features : 기능 개발


WebHook

  • Webhook을 연동한 레포에서 commit을 하면 Discord에 알림이 온다.

CI/CD

  • CI : Continuous Integration

    • QA 과정을 자동화 해주는 개념
  • CD : Continuous Deploy

    • CI에 이어서 배포까지 해주는 개념
  • poolc-cicd/.github/workflows/node.js.yml

  • Heroku + Github Action 실습

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: Node.js CI

# 발동 조건
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

# 작업 환경
jobs:
  build:
    # 우분투에서 돌아감
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/
    
    # 동작 과정
    steps:
    - uses: actions/checkout@v2 # 두 개의 플러그인을 사용함
    - name: Use Node.js ${{ matrix.node-version }} # 확장기능 사용
      uses: actions/setup-node@v2
      with: # for each와 동일
        node-version: ${{ matrix.node-version }} 
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

https://zero-coke.herokuapp.com/

좋은 웹페이지 즐겨찾기