Now Loading ...
-
Git 기초
Git 기초
Git 기본 이용 사이클
Git 저장소 선언하기 (Initialization & Repository)
Git 저장소를 흔히 Repo(레포)라고 부르며, Repo는 git으로 관리하는 하나의 메인 저장소를 뜻함
사용자가 변경한 모든 내용 추적 가능
현재 상태, 변경 시점, 변경한 사용자, 설명 텍스트 등
관리할 폴더에서 git init 을 통해 선언
주목할 특징
Git은 이제 Local에서 모든 것을 저장 및 버전 관리 가능하고 나중에 원격 서버에 올려도 상관 없음
Git은 데이터를 추가만 할 수 있음
파일 삭제 == 삭제 기록 추가 (물론 온전한 삭제도 가능하지만, 버전 관리에서는 삭제 기록도 매우 중요)
Git은 파일을 추적하지 않음
파일의 내용 단위로 각 문자와 줄을 추적
빈 디렉토리는 추적하지 않음
파일 추가/수정/삭제
변경 사항 선택
파일 상태
파일은 추적 여부로 구분해 tracked, untracked 파일로 나눌 수 있음
tracked 파일은 Unmodified(수정 없음), Modified(수정 있음), Staged(저장(커밋)을 위해 준비됨) 상태로 구분됨
스테이징(Staging)을 통해 커밋하고 싶은 파일 선택
스테이징이 필요한 이유?
여러 작업 중 일부분만 커밋해야 할 때
커밋 전 상태를 수정 또는 체크할 때 (안전하게 커밋하기 위함)
상태 업데이트
커밋(Commit)을 통해 새로운 버전으로 업로드
커밋을 하면, 각 버전마다 40자리의 숫자 + 알파벳 조합으로 이루어진 해시값이 존재
해시 값은 버전의 주소(Key)
해시값은 내용(파일 구조)을 사용해 생성됨 (파일이 어떤 폴더 밑에 있고, 어떤 내용이다 등의 상태를 40자리로 표현)
Commit Hash 값으로 Checkout하면 버전 이동 가능
Git Branch
소프트웨어 버전 넘버링 상식
보통 세가지 숫자로 표현되며, 위 그림과 같이 각각 의미가 다름
마지막에 알파벳이 들어가는 경우도 있지만, 보통은 모두 숫자로 사용
1.1, 2.1 같이 두 개로 표현된 경우, 1.0.1, 2.0.1을 뜻함
브랜치 (Branch)
버전 관리시 수많은 오류를 개발자들이 각각 따로 처리하는 상황이 발생하는데, 이를 위해 브랜치 개념이 등장
브랜치는 시간의 흐름의 축
Git 명령어
프로젝트 총 관리자 및 시작자 관점
프로젝트 시작 선언
git init
.git 파일이 생성됨 (처음엔 숨김 상태라 안보임)
모든 버전 관리 정보가 담겨있으므로 조심해야 함 (버전을 초기화하고 싶을 땐, 이 폴더를 통째로 삭제하면 됨)
로컬에서 Git 초기화 진행
시작 버전은 master branch에 기록
.gitignore 파일을 생성해 양식(정규표현식)에 맞춰 작성하면, 저장하고 싶지 않은 파일들을 무시할 수 있음
README.md 파일 작성
Repo의 메인 페이지 역할
프로젝트 설명 및 사용방법, 라이센스 등을 기술
유저 이름과 이메일 등록하기 (log에 남기는 용도)
git config --global user.name="[이름]" : 깃 설정 파일을 내 모든 컴퓨터에 적용, 그 중 이름 정보 입력하겠다.
git config --global user.email="[이메일]" : 깃 설정 파일을 내 모든 컴퓨터에 적용, 그 중 이메일 정보 입력하겠다.
파일 스테이지로 올리기
git add [file]
[file]을 스테이지로 올림 (폴더나 전체도 가능)
스테이지에서 내리기
git restore --staged [file]
파일 상태 체크하기 (습관적으로)
git status
git diff
스테이지에 있는 내용 커밋
git commit -m "add README.md"
간단한 설명과 함께 커밋
커밋 기록 살펴보기
git log
조금 더 시각적으로 편하게 살펴보는 방법
git log --all --decorate --graph --oneline
위 방법에 간단한 별명을 붙이는 방법
git config --global alias.adog "log --all --decorate --graph --oneline"
원격 저장소와 연결
git remote add origin [url]
origin이라는 이름으로 [url]과 연결 (origin은 원격 저장소에 관용 표현이므로 변경 가능)
연결 여부를 확인하는 명령어
git remote -v
원격 저장소로 올리기
git push origin master
원격 저장소 master branch에 업데이트
로컬과 원격 저장소가 동기화됨!
버전 이동하기
git log 로 원하는 버전의 해시값 확인
만일 과거로 돌아와 미래 로그가 안보인다면, git log --all
git checkout [40자리 해시값의 앞 7자리]
예시
git checkout a703380
git checkout master
협업하는 개발자 시점
원격 저장소 다운받기
git clone [url]
파일 구조, 로그를 포함한 모든 것이 다운로드됨
기능별로 개발하기
master 브랜치는 배포 버전이므로 함부로 커밋하기 어려움… 필요한 기능은 병렬적으로 가지쳐서 개발하자!
git branch [name]
처음에는 master를 가리키는 것처럼 보이지만 커밋하면 branch를 가리키는 것을 확인할 수 있음
[name] 없이 git branch를 쓰면, 현재 브랜치가 무엇인지 확인 가능
브랜치/버전 이동하기
git checkout [name]
브랜치 합치기
git merge [name]
[name] 브랜치를 현재 브랜치로 합치기
기능 완성 후, master와 합치는데 주로 이용
같은 파일만 건드리지 않았으면 문제 없이 병합 가능!
가지가 복잡한 브랜치 합치기
git rebase master - 자주 사용!!
base(기준점)를 master의 끝 점으로 re-base(재설정)해서 그래프를 한 줄로 만듬
브랜치 지우기
git branch -d [name]
완료했거나 필요가 없어진 브랜치를 삭제
프로젝트 리더 시점
다른 개발자가 원격에 메인 버전을 업데이트 하면, 최신 버전을 다운받아 오고 싶음
원격에서 기록 가져오기
git fetch - 자주 사용!!
원격 저장소와 동기화하지만 merge는 하지 않음
동일 파일을 건드리는 Conflict를 방지하기 위해 미리 체크할 수 있음
원격에서 기록 가져오고 합치기
git pull
원격 저장소와 동기화하고 merge까지 진행
충돌을 일으킨 개발자 시점
같은 파일의 같은 부분을 수정하고 합칠 때는 충돌(Conflict)이 발생함
커밋 되돌리기(reset, revert), 직접 충돌 부분 수정하기 등 다양한 해결법 존재
실수한 커밋을 RESET하기
git reset [option] [commit의 7자리 해시값]
해당 커밋 이후 기록을 없애기 (Hard, Mixed, Soft)
커밋으로 프로젝트가 망하면, 원하는 커밋으로 reset 가능
이미 원격 저장소에 올라가 있는 경우 사용해서는 안됨! 다른 개발자들과 버전이 달라져버린다…
실수한 커밋도 내 커밋, 기록하자!
git revert [commit의 7자리 해시값] - 가장 좋음!!
되돌릴 커밋이 여러개라면 범위를 주어 한번에 되돌릴 수 있음
git revert [commit의 7자리 해시값]..[commit의 7자리 해시값]
선택한 커밋 하나만 되돌리고 다른 커밋 내용은 그대로 둠, 수정한 기록도 남김
협업하는데 커밋 로그를 함부로 지우면 서로 버전이 이상해질 수 있으니 revert로 수정 기록 남기자!
다만, revert 쓰는 것 보다도 가장 좋은건 수정해서 그냥 커밋을 하는 것이 아닐까?
브랜치 바꿔야하는데 커밋은 하기 싫을 때
현재 무언가 작업 중일 때 브랜치를 바꾸면, 작업 중인 내용이 바뀐 브랜치로 따라옴
git stash
현재 작업하고 있는 작업물을 따로 추적하지 않는 저장파일에 저장하기
Reference
티아카데미 Git & GitHub page 블로그 만들기
초보용 git 되돌리기
-
Git의 발전 과정
Git의 발전 과정
Git 탄생 배경
Git은 분산형 버전 관리 시스템 (DVCS, Distributed Version Control System)
처음엔 리눅스 오픈 커뮤니티에서 BitKeeper(회사)의 DVCS를 사용했으나, 이익을 추구하는 기업과 오픈 커뮤니티와의 상충이 발생
리눅스 창시자 Linus Tovalds를 중심으로 2005년 리눅스 오픈 커뮤니티에서 자체 툴로서 제작
버전 관리 시스템 (VCS, Version Control System)
파일의 변경 사항을 저장하고, 원하는 시점의 버전을 다시 꺼내올 수 있는 시스템
CVCS(중앙집중식 VCS) VS DVCS(분산형 VCS)
중앙집중식 버전 관리 시스템 (CVCS, Central Version Control System)
하나의 중앙 서버를 두고, 해당 서버에서 버전을 관리
최신 버전으로 업그레이드하기 위해, 최상단의 버전을 다운받고 수정해 업데이트하는 방식
메인 서버에 접속하지 않으면 로컬에서 개발 불가
메인 서버가 폭파되면 큰일남
효율적이지만, 여전히 협업의 불편함이 있음
분산형 버전 관리 시스템 (DVCS, Distributed Version Control System)
메인 서버와 개발자들의 컴퓨터 각각에 모든 코드와 파일 변경 정보들이 분산되어 버전을 관리
메인 서버에 파일들이 어떻게 수정되었고, 누가 변경했는지 등의 정보가 저장됨
로컬에서 버전 관리하고 메인 서버에 올릴 수 있음
메인 서버가 폭파되어도 버전들 생존 가능
보다 효율적인 협업 가능
Subversion (SVN) - CVCS
CVCS의 대표적인 시스템 중 하나
파일의 모든 변경 사항을 저장
초기에 File A, B, C를 각각 만든다면, 각각의 파일마다 변경 사항 델타를 따로 저장
특정 버전을 다운 받을 때, 초깃값에서 해당 버전까지의 델타들을 합한 값인 파일을 다운받아 관리
Git - DVCS
특정 버전에 해당하는 모든 정보와 파일들을 스냅샷으로 찍어 관리
버전이 수정된 파일은 수정본을 올리고, 수정되지 않은 파일은 해당 파일이 존재하는 버전으로 연결되는 링크를 저장
최신 버전의 스냅샷만 유지하고 이전 버전은 델타로 관리
Reference
티아카데미 Git & GitHub page 블로그 만들기
-
Touch background to close
Lucian Log
