[Git] Git Commands

yujuck·2021년 3월 15일
0

Git

목록 보기
2/5
post-thumbnail
post-custom-banner

Git Commands

git config

git의 사용 환경에 대한 설정

사용자 정보

Git을 설치하고 나서 가장 먼저 해야하는 것은 사용자 이름이메일 주소를 설정하는 것이다.
설정하지 않으면 로컬에서 git을 사용할 수는 있어도 원격 저장소에 올릴 수 없다.
커밋할 때마다 이 정보를 사용하고, 한 번 커밋한 후에는 정보를 변경할 수 없다.

[필수]
user.name - 사용자 이름
user.email - 사용자 이메일

설정 범위 선택

시스템 / 전역 / 프로젝트 단위로 설정이 가능하다.

[시스템 설정]
git config --system

[전역 설정]
git config --global

[프로젝트 설정]
git config

// 우선 순위
프로젝트 > 전역 > 시스템

설정 확인 및 추가

git config --list // config에 설정되어있는 정보를 가져옴

git config <key>  // 입력한 key에 해당하는 value를 보여줌

git config <key> <value>  // key-value 값을 config에 설정함

git config -e(--edit)  // 편집기를 통해 편집할 수 있음

유용한 설정

1. core.autocrlf = false (기본) | true | input

일반적으로 OS마다 line ending을 처리하는 방법이 다르다.
만약 linux/mac을 사용하는 개발자와 window를 사용하는 개발자가 협업을 하게 되면
line ending을 처리하는 방법이 달라 실제 코드는 달라진 게 없는데
CR (Carriage Return) 또는 LF (Line Feed) 때문에 변경으로 착각해 commit을 하게 될 수 있다.

(윈도우는 CR 및 LF를 쓸 수 있는데 리눅스 OS는 LF만 사용함)

core.autocrlfcommit할 때 자동으로 CRLFLF로 변환해주고 반대로 checkout 할 때 LFCRLF로 변환해줄 수 있다.

Window에서 이 값을 true로 설정하면 checkout할 때 LF 문자가 CRLF로 변환된다.

Linux/Mac에서는 checkout할 때 LF를 CRLF로 변환할 필요가 없기 때문에 input 설정값을 사용해서 commit할 때만 CRLF를 LF로 변환한다.

줄바꿈의 종류, CR / LF
CR (Carriage Return): 현재 위치에서 바로 아래로 이동
LF (Line Feed): 커서의 위치를 앞으로 이동

2. core.editor = command | "path"

커밋할 때나 태그 메세지 작성 등 git을 통한 편집에 사용할 에디터를 설정한다.
기본은 vi로 실행되며 설정한 커맨드나 경로를 찾을 수 없는 경우에도 vi로 실행된다.

3. commit.template = "path"

커밋할 때 git이 보여주는 커밋 메세지를 설정할 수 있게 해주는 옵션이다.
팀에서 정한 커밋 메세지 규칙이 존재할 경우 해당 옵션을 사용하면 유용하다.

4. alias.<key> command

단축 명령어를 설정할 수 있다.
예를 들어 checkout을 짧게 쓰고 싶은 경우!

git config --global alias.co checkout

이라고 설정해두면 checkout 대신 co를 사용해 checkout을 할 수 있다.

Create Project

git init

Remote (원격) 저장소 없이 로컬에 생성. 신규 Git 저장소 생성!

git init을 입력하면 .git 폴더가 생성되며, git을 사용하기 위한 세팅이 완료된다.
로컬 git 저장소 생성 후 remote 저장소와 연결하려면 다음과 같이 입력하면 된다.
git remote add origin <git-server-address>


생성된 .git 폴더 내에는 다른 폴더 및 파일이 존재한다.

1) hooks/ : 클라이언트나 서버의 훅을 넣어두는 곳
2) info/ : .gitignore처럼 무시할 파일의 패턴을 적어두는 곳
3) objects/ : 모든 컨텐츠를 저자하는 데이터 베이스
등 여러개가 있다.

** .gitignore
.gitignore는 git에 관리되지 않을 파일 리스트를 관리하는 파일이다.
여기에 폴더 또는 파일명을 적으면 git으로 관리하지 않기 때문에 저장소에 올릴 때 해당 파일들을 제외하고 올리게 된다.

git repository에 올라와 있는 파일을 .gitignore에 추가하고 싶은 경우에는 추가적인 조치가 필요하다.
이미 올라와 있는 파일은 계속 trackign되고 있기 때문에 이 tracking을 제거해줘야한다.

//.gitignore 파일 수정 후
git rm -r --cached  // cache에 기록된 tracking 중인 파일 리스트 삭제. cached 없이 삭제하면 망...함..
git add .
git commit -m "refactor:remove ignored file"
git push origin branch

.gitignore에 어떤 것들을 추가해야할지 잘 모를 때 이곳을 참고해도 좋을 것 같다.

git clone

Remote(원격) 저장소를 통한 로컬에 생성

원격 레포지토리가 이미 존재할 경우 clone을 통해 로컬에 생성할 수 있다.

git clone <remote repository url>

해당 repository의 default branch를 기준으로 새로운 신규 브런치를 생성 후 작업하는 습관을 갖는게 좋다!

Snapshotting

Git의 핵심 기능으로서, 파일들의 스냅샷을 관리하는 명령어들

lifecycle

Working Directory의 모든 파일은 크게 Tracked(관리 대상)Untracked(관리 대상 아님)으로 나눌 수 있다.

Tracked 파일은 이미 스냅샷에 포함되어 있던 파일이고, unmodified, modified, staged 상태 중 하나이다.

맨 처음 우리가 코드를 작성하고 아무것도 하지 않으면 untracked상태이다.
아무 커맨드도 날리지 않았기 때문에 git은 아직 그 파일들을 tracking하지 않는다.

우리가 git add .이라는 커맨드를 날리는 순간, 해당 파일들은 tracking상태가 되고,
git commit이 되면 staged된 상태로 본다.
push하는 파일들은 항상 staged된 파일들을 push하는 것이다.

commit이 되면 unmodified 상태가 되고, 수정이 되면 modified가 된다.

위의 라이프사이클을 계속 반복하게 된다.

commands

git add file  // 변경 파일들 또는 신규 추가된 파일을 staged 상태로 변경

git commit  // staged 상태의 파일들을 포함해 스냅샷을 생성

git reset 옵션 돌아갈커밋ID  // 돌아가려는 커밋으로 repository를 재설정 후 옵션에 따른 파일 처리를 함

git staus  // 파일의 상태를 확인

** reset의 옵션 종류

--hard : 돌아가려는 이력의 이후 커밋 내용을 모두 삭제, 돌아간 커밋 기준으로 모두 초기화
--soft : 돌아가려는 이력으로 되돌아가며, 이후 커밋 내용이 삭제되지 않고 남아있으며 이후 커밋 파일들이 staged 되어있는 상태
--mixed(default) : 돌아가려는 이력으로 되돌아가며, 이후 커밋 내용이 삭제되지 않고 남아있으며, 이후 커밋 파일들이 staged되어 있지 않는 상태

Branch & Merge

git branch <브런치명>

: 새로운 브런치 생성

git checkout <브런치|태그>

: 지정된 브런치 또는 태그로 변경

git merge <작업브런치>

: 다른 브런치의 작업 내역 합치기
(옵션)
default : 대상 프런치에 작업브런치가 merge되고 새로운 commit을 대상 브런치에 생성하고
작업 브런치의 히스토리를 공유
--squash : 작업 브런치의 작업 내역(commit)들을 하나의 커밋으로 합쳐 새로운 commit을 만든 후 대상 브런치에 merge
ex ) features 브런치에 commit이 3개가 있었는데 해당 브런치를 dev 브런치에 merge 시킬 때
features의 commit 3개를 1개의 commit으로 합쳐서 merge시킴.

git tag

: 현재의 스냅상태를 tag로 저장

tag ? 
commit을 참조하기 쉽도록 알기 쉬운 이름을 붙이는 것.
한번 붙인 태그는 브런치처럼 위치가 이동하지 않고 고정됨.
git에서는 일반태그 / 주석 태그를 사용할 수 있음

일반 태그 : 이름만 붙일 수 있음
주석 태그 : 이름을 붙일 수 있고, 태그에 대한 설명, 서명, 만든 사람 이름, 이메일, 날짜 정보도 포함시킬 수 있음.

[태그 리스트 조회]
git tag

[태그 생성]
git tag <태그명>
git tag <태그명> <체크섬>  // commit 지정해서 tag 생성

git stash

: Working Directory에서 tracked 파일이면서 수정된 파일을 임시로 저장
git stash는 작업 중인 내용이 있는 와중에 다른 요청이 들어와서 다른 브런치로 이동하려면 무조건 commit을 해야하는데 commit을 하긴 애매한 상황에서 사용할 수 있다.
git stash로 내가 작업한 내용을 임시 저장한 후,
다른 요청 작업을 수행한 후에 다시 돌아가서 저장해둔 내용을 가져올 수 있다.

// stash 잘 쓰면 유용할 것 같아서 더 찾아봄
git stash                  // 현재 수정 중인 상태에서 이전 HEAD의 커밋 상태로 돌아감
git stash save NAME        // 해당 이름으로 git stash 수행
git stash pop              // 임시 저장했던 상태로 되돌림. 저장된 스택 중 가장 위에 있는 것을 pop
git stash list             // 현재 보관되어진 리스트 보여줌
git stash apply stash@{0}  // stash 이름들은 기본적으로 stash@{0}으로 지정됨.
git stash drop stash@{0}   // 지정된 stash 중 해당 이름으로 되어있는 것 삭제. 생략하면 맨 위에 있는 것 삭제
git stash clear            // 모든 stash 리스트 삭제

Patching

git revert <commit hash>

: 특정 커밋을 되돌린다. 여러개의 커밋을 되돌릴 수 있고, 범위 지정도 가능하다.

reset vs revert
이미 push한 코드라면 reset 보다는 revert를 하는 것을 권장한다.
push한 이후 reset을 하고 다시 push를 하게 되면 
로컬의 commit과 원격 저장소의 commit 내역에 차이가 생겨 충돌이 발생하게 된다.

revert는..
push 이후에 revert를 사용하면 어떤 커밋에 대해 revert를 했는지가 로그에 남기도 하고
다른 사람이 내가 지운 commit 이후에 작업을 했더라도, 해당 commit을 건드리지 않기 때문에 문제가 생기지 않는다.

이미 push한 코드라면 미련없이 revert를 하자~!

git rebase <branch>

: 브런치의 공통 조상이 되는 다른 브런치의 커밋 지점으로 변경한다.

작업하던 브런치를 main 브런치에 합칠 때,
현재 작업한 브런치를 남겨두는 것이 아니라 main 브런치의 한 줄기로 만들 수 있다.

Sharing

git fetch

: 원격 저장소의 최신 이력 (변경 사항들)을 가져온다. 로컬 데이터와 merge하지는 않는다.

git pull

: 원격 저장소의 변경된 데이터를 가져와서 현재 로컬 데이터에 merge시킴

git push

: 로컬 저장소에 변경된 이력을 원격 저장소로 업로드
staged 상태의 파일들만 push가 된다

git remote

: 원격 저장소 관련 설정

[등록된 원격 저장소 확인]
git remote 
git remote -v  // 저장소 이름과 url 확인 가능

[원격 저장소 연결]
git remote add <이름> <경로>
ex) git remote add origin https://github.com/~~

[원격 저장소 정보 표시]
git remote show <이름>
ex) git remote show origin

[원격 저장소 경로 제거]
git remote rm <이름>


참고
- git 공식 문서
- 팀장님의 완벽한(ㅎㅎ) 발표 자료
profile
알게 된 내용 부담 없이 남기기
post-custom-banner

0개의 댓글