/ DEVOPS

Git and github

DevOps 관련 포스팅

VCS (Version Control System)

CVS (Centralized Version Control)

  • 서버에서 히스토리를 관리
  • 즉각적인 동기화
  • 서버에 문제가 생길시 업무가 중단됨
  • 오프라인에서 인터넷이 없으면 사용 불가

DVC (Distributed Version Control)

  • 서버 뿐만 아니라 모든 개발자들이 동일한 히스토리 정보를 가짐
  • 서버에 문제가 생겨도 서로의 정보를 이용해 서버를 복원한 뒤 업무를 이어나갈 수 있음
  • 오프라인에서도 업무 진행 가능
  • private 또는 cloud 이용 가능
  • github이 가장 대중적

Git

  • 변경 사항만 저장하는 delta-based version control과는 다르게, project의 전체적인 내용을 snapshot해서 가지고 있음
  • 변경되지 않은 내용은 서로 link를 형성하고 있어서 snap shot이 매우 가벼움
  • 버전별, branch별 이동이 자유로움
  • 무료, 오픈소스임
  • 가볍고, 가장 대중적임
  • 오프라인에서도 사용 가능함
  • 실수를 수정하기 쉬우며 branch를 이용한 협업에서 효율적으로 사용됨

Git 명령어

→ git 공식 사이트에서 모든 명령어 확인 가능
→ git 명령어 -option 형식

  • version 확인
    git --version
  • 설정 확인
    git config --list
  • ‘file’로 설정 확인
    git config --global -e

  • carrage-return과 line feed 설정(windows에서는 true, mac에서는 input)
    git config --global core.autocrlf true image

  • git 초기화(기본적으로 master branch 형성)
    git init
  • git 상태 보기
    git status
  • git 명령어 관련 속성값 확인하기
    git 명령어 --h
    e.g.) git status --h, git add --h

Git workflow 이해

1. Working directory

→ project 파일을 작업하는 곳
→ git의 추적 여부에 따라 untracked와 tracked로 나뉨

  • untracked: 새로 만들어진 파일이거나 git을 초기화했을 경우
  • tracked: git의 추척이 이루어지는 파일
    → 수정 여부에 따라 unmodified와 modified로 나뉨(이전 버전과의 비교)
    image
  • modified 버전만 staging area로 이동 가능

관련 명령어

  • git add 특정 파일 이름
    → 해당 파일을 working directory에서 staging area로 옮김
  • git add *.특정 확장자
    → 특정한 확장자의 모든 파일을 staging area로 옮김
  • git add *
    → directory의 모든 파일을 staging area로 옮김
    → .으로 시작하는 이름의 파일(e.g.) .gitignore)은 제외
  • git add .
    → directory의 모든 파일을 staging area로 옮김
    → 예외 파일 없음

git add * vs. git add .
참고 stackoverflow 글

  • add 후(= staging 이후) 파일을 변경하게 되면, 수정된 내용에 대해서는 tracked modified 상태가 됨(이전에 staging한 내용은 그대로 있음)
    image

  • git rm --cached 파일이름
    → staging area에서 working directory의 untracked 상태로 옮김
  • git tracking하고 싶지 않은 파일은 .gitignore파일을 생성해 명시하면 됨 
      log.log
  *.log
  build/ <- 특정 directory안의 파일들
  build/*.log

  • git status
    → 기본적으로 git status --long으로 실행됨
    image

    → 간단하게 보려면, git status -s 입력
    (A: adding, M: modified, ??: tracking이전 상태로 working directory에 존재) image

  • git diff
    → working directory의 변경 사항을 보여줌
    → terminal이 아닌 다른 UI(e.g.)vscode)를 연결해 보고 싶다면,
    git config --global -e를 실행해 .gitconfig 파일에 다음 내용을 추가한 뒤,
    git difftool나 git difftool --staged를 입력하면 vscode에서 실행됨 
      [diff]
  tool = vscode
  [difftool "vscode"]
  cmd = code --wait --diff $LOCAL $REMOTE
  • git diff --staged (git diff --cached)
    → staging area의 변경 사항을 보여줌(q로 escape)

2. Staging area

  • version history에 저장할 준비가 된 파일을 옮겨놓은 곳
  • commit 명령어로 staging area의 파일을 git repository에 옮김
  • 각 commit에는 snapshot된 정보를 기반으로 고유한 hashcode가 부여되며, 이를 통해 version 정보를 참조함
  • application 전체를 한꺼번에 commit하기 보다는 application을 기능적인 작은 단위로 나누어 commit하면, 이후에 원하는 변경 사항을 찾아 보기 쉬움
  • commit message는 보통, 현재시제 동사로 만듦
  • commit message에 해당하는 코드만 commit 하기!
    !주의!
    commit message를 벗어나 여러 내용이 추가된 코드를 commit하면, 코드 리뷰시 혼동이 오며 commit history를 읽기 어려워짐

관련 명령어

  • git log
    → git의 전체적인 history확인
    → 누가, 언제 commit했으며, commit의 title과 description을 확인 할 수 있음
  • git commit -m "commit message"
    → 간단히 commit message를 입력해 commit 실행
  • git commit -am "commit message"
    → working directory의 모든 변경 사항을 포함해(working directory의 파일을 staging area로 옮기는 git add명령어의 사용을 건너 뜀) commit message를 입력해 commit 실행

3. .git directory(.git repositor)

  • git version history를 가지는 곳
  • checkout 명령어로 언제든 원하는 version으로 돌아갈 수 있음
  • push 명령어로 local의 git directory를 server에 upload
  • pull 명령어로 server의 git directory를 local로 download

< 출처 >

“깃, 깃허브 이건 알고 사용하자,” 유튜브 비디오, 06:49, 게시자 “드림코딩 by 엘리,” 2020년 11월 10일, https://youtu.be/lPrxhA4PLoA

“깃, 깃허브 제대로 배우기 (기본 마스터편, 실무에서 꿀리지 말자),” 유튜브 비디오, 47:13, 게시자 “드림코딩 by 엘리,” 2020년 11월 17일,https://youtu.be/Z9dvM7qgN9s