Git 기초
Git은 왜 중요한가
"_*깃([긷])*은 컴퓨터 파일의 변화를 추적하고 여러 사람들 사이에서 그 파일을 조정하는 버전 관리 시스템입니다."
즉 여러 팀에게 동시에 같은 프로젝트로 코드를 더하게 (그리고 통합)하게 허용한다는 걸 의미합니다. 이러한 능력을 프로젝트에 더함으로써 팀을 더 효율적이게 하고 더 큰 규모의 프로젝트나 더 복잡한 문제들에 일할 수 있는 능력을 제공합니다.
※ ' .git '
깃이 정말 잘하는 또 다른 많은 것들이 있습니다: 변경점을 원복, 새로운 기능을 더하기 위한 새 브랜치(branches) 생성, 병합 시 발생하는 충돌(conflict) 해결 등을 허용합니다.
('git' 과 'github'는 다르다)
git을 잘한다? : 원하는대로 이동을 마구잡이로 할 수 있는 사람.
ex) crud 게시판
list, write, view
write > view
이후에 변경할려한다
write > list
다시 원복 할려고 한다면
write > view 즉 소스코드 터치 없이 버전을 원복을 원한다면 사용하는 기술이 Git이다.
homepage 프로젝트 디렉토리
$ git init : 새로운 깃 저장소 초기 설정 즉 모든 코드 내용은 저장소 안에 추적됩니다. 깃 저장소를 초기 설정하려면 해당 프로젝트 폴더 안에 이 명령어를 사용하세요. 이 것이 .git 폴도를 만들어 줄 것입니다.$ git add : 이명령어는 하나 또는 모든 변경 파일들을 본 무대 영역으로 더 합니다.git add filename.py : 어떤 하나의 특정 파일을 올리기 위해git add -A : 신규 또는 수정되거나 삭제된 파일들을 올리기 위해git add . : 신규 또는 수정 파일들을 올리기 위해git add -u : 수정 또는 삭제된 파일들을 올리기 위해
Git 사용자 이름과 이메일 설정
$ git config --global user.name "[사용할 이름]"
$ git config --global user.name "[이메일]"
$ git config --global init.defaultBranch main
열심히 코드를 작성하다가 커밋을 해야하는 순간이 오면 git add . 를 통해 커밋할 파일들을 추가합니다.
이 파일은 바로 Repository에 올라가지 않고, Staging Area에 올라가게 됩니다.
Staging Area에 추가한 파일들을 Commit을 한다면 최종적으로 저장소(Repository)로 저장 되게 됩니다.
File 관점에서는 다시 4가지 단계로 나뉜다.
Untracked : Working Directory에 있는 파일이지만 Git으로 버잔관리를 하지 않는 상태
Unmodified : 신규로 파일이 추가되었을 때, new file 상태 같다 ($ git add 상태)
Modified : 파일이 추가된 이후 해당 파일이 수정되었을 때의 상태
Staged : Staging Area에 반영된 상태
working directory(작업 풀더)
작업풀더(Working Directory) 는 git 에 의해 관리되고 있는 상태이며, 나의 작업 폴더 안에는 하나의 파일당 2가지의 상태를 표현합니다.
- Untracked: 추적되지 않음(한번도 git 에 의해 관리된적이 없는 파일을 뜻함)
- Tracked : 추적 (한번이라도 git 에 관리가 된적이 있다고 하는 파일)
Stagin Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간
Repository : 커밋들이 모여있는 저장
Git commit
이 명령어는 버전 이력을 파일 안에 기록합니다. -m이 뜻하는 것은 어떤 커밋 메세지가 뒤따른다는 의미입니다. 이 메세지는 커스텀이며 반드시 이것을 동료에게 알리는 용도로 또는 미래의 스스로에게 무엇이 해당 커밋 안에 더해졌는지 알리기 위해 사용해야 합니다.
git commit -m "your text"
Git status
이 명령어는 파일들을 초록색과 빨간색으로 리스트해 줄 것입니다. 초록색 파일들은 무대로 올려졌지만 아직 커밋되지 않은 것들입니다. 빨간색으로 표시된 파일들은 무대로 아직 올려지지 않은 것들입니다.
git status
git log: 저장소에 있는 Commit 이력을 조회할 경우 git log 명령을 사용한다
스냅샷 : HEAD가 가리키는 커밋을 기반으로 사진을 찍습니다. 그리고 이를 스테이지 영역과 비교하여 새로운 커밋으로 기록합니다. 이처럼 깃은 스냅샷 방식을 이용하여 빠르게 버전의 차이점을 처리하고, 용량을 적게 사용합니다.(하나의 점)
.gitignire 파일이란
.gitignore 파일은 Git 의 root 디렉토리에 저장되어, Git Repository 나 Stating Area에 추가되지 말아야 하는 (무시되어야 하는) 폴더나 파일을 정의하는 파일이다. .gitignore에 정의된 파일은 Staging Area에 올라가지 않기 때문에 tracking 되지 않는다. 따라서 git status 를 이용했을 때 보이지 않는다.
다음 줄을 추가함으로써 특정 폴더에 있는 전체 파일을 무시할 수 있다.
[folder name]
예를 들어 kotlin이라는 폴더가 있다고 했을 때 이 내부에 있는 파일을 모두 무시하기 위해서는 아래 줄을 .gitignore에 추가하면 된다.
Kotlin/
.gitignore이용해 특정 확장자 전체 무시하기
다음줄을 추가함으로써 특정 확장자 전체를 무시할 수 있다.
*.[확장자]
예를 들어 모든 log 확장자 파일을 무시하고 싶을 경우 아래 줄을 .gitignore에 작성하면 된다.
*.log
.gitignore 이용해 특정 파일 무시하기다음 줄을 추가함으로써 특정 파일을 무시할 수 있다.
[디렉토리 명]/[파일 명]
만약 루트 디렉터리(git의 최상위 디렉터리)에 있는 파일을 무시하고 싶은 경우 다음 줄을 추가하면 된다.
[파일 명]
예를 들어 kotlin 디렉터리의 kotlin.log 파일을 무시하고 싶은 경우 다음과 같이 작성하면 되며
Kotlin/Kotline.log
루트 디렉터리에 있는 .DS_STORE 파일을 무시하고 싶은 경우 아래와 같이 작성하면 된다.
.DS_STORE
※주의
이미 Stating Area나 Repository에 커밋으로 올라간 파일은 gitignore을 하기 위해서는 먼저 파일을 제거 해야한다. 파일 제거는 다음 명령어로 가능하다.
git rm [파일명]
git commit -m [메시지]
예를 들어 루트 디렉토리의 app.log 파일이 이미 커밋으로 올라간 경우 다음 명령어를 통해 제거가 가능하다.
git rm app.log
git commit -m "app log 제거"
위와 같이 제거한 후에는 .gitignore가 정상 동작한다.
커밋메시지 컨벤션
☆commit Message 구조
type(타입): title(제목)
body(본문, 생략 가능)
Resolves : #issueNo, ...(해결한 이슈, 생략 가능)
See also : #issueNo, ...(참고 이슈, 생략 가능)
Type 키워드
- feat: 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 수정
- style: style 코드 수정(코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우
- design : 사용자 UI 디자인 변경(CSS 등)
- test : 테스트 코드, 리펙토링 테스트 코드 추가
- build : 빌드 파일 수정
- ci : CI 설정 파일 수정
- perf : 성능 개선
- chor : 빌드 업무 수정 , 패키지 매니저 수정 (gitignore 수정 등)
- refactor : 코드 리팩토링
- rename : 파일 혹은 폴더명을 수정만 한 경우
- remove : 파일을 삭제만 한 경우
대부분 가장 많이 사용하는 것은 feat 와 fix 입니다. style, design처럼 로직적인 변화가 없을 경우에 커밋 메세지에 명시해주는 것만으로 추후 오류를 찾을 때 많은 도움이 됩니다.타입 뒤에 변경된 함수나 메소드를 직접적으로 명시하기도 합니다.ex) fix(tab):..