SW Dev

SW Dev

Fight with your fears

[Git]Git 시작하기

Updated:

Git 사용법

Git에 입문하기 위해 기본적인 Git 키워드와 원리들을 설명한다


1. Git 최초 설정

Git 전역으로 사용자 이름 & 이메일 주소 설정(GitHub계정과 별개)

// 설정
git config --global user.name '본인이름'
git config --global user.email '본인이메일'
git config --global init.defaultBranch '브랜치명'

// 확인
git config --global user.name
git config --global user.email

-> 주브랜치명은 과거 master로 사용하다가 최근엔 main으로 사용함



2. 프로젝트 생성 & Git 관리 시작

Git으로 관리할 폴더 설정

git init			// git으로 관리하기 위한 키워드
git status		// 해당 폴더 내에서 변경사항 있는지 check

-> Git 으로 관리하고자 하는 폴더의 위치에서 vsc 실행 후 터미널에 git init 명령어 입력하면 .git폴더가 생성됨
-> git으로 관리되고 있는 폴더에 특정 파일이 추가되었을 경우, git status 명령어를 통해 변화를 확인해볼 수 있음


git1

위의 오류발생시 해당 폴더가 git으로 관리되고 있지 않는거라고 생각하면됨

주의!!!) .git 폴더는 지금껏 Git으로 관리한 버전 내역들이 들어있는 폴더로 삭제시 이전 버전들이 날아감


Git으로 관리하지 않을 것들

-> 보안상 민감하여 포함하지 말아야하는 경우 or 빌드결과물 등 굳이 포함할 필요가 없는 경우에 한해 .gitignore 파일을 사용하여 git으로 관리하지 않을 수 있음
-> .gitignore 파일 만들어서 관리하지 않을 파일 적어놓으면 해당 파일은 git status 목록에 뜨지 않음을 알 수 있음

file.c			// 모든 file.c
./file.c		// 현재 폴더의 file.c
*.c					// .c 확장자명을 가진 파일
log/				// log폴더와 그 내용들

-> .gitignore 사용예시. 추가로 필요하면 git 공식문서 참조



3. 시간을 넘어 버전관리하기

프로젝트 변경사항 추가하기(add)

git2

-> 빨간색으로 보여지는 파일 모두 Git의 관리를 받지 않는 상태
-> Git으로 관리하기 위해 먼저 git add 명령어에 대해 알아보자

git add async.js			// 파일 하나 추가
git add .							// 모든 파일 추가
git status						// Git 상태확인

git3

-> git status 명령어로 확인하면, 초록색으로 바뀌면서 commit을 기다린다는 메시지가 뜸


변화를 특정버전에 담기(commit)

git commit -m '작성할 메세지'	// 변경사항 묻기

-> git commit 명령어를 사용하여 git add를 통해 추가한 변경사항을 버전에 묻을 수 있음

git4

git log	// 커밋내역 확인

-> 이후 git log 명령어를 통해 확인해보면, 메세지와 함께 커밋이 되었음을 확인가능


차이점 확인하기(diff)

git diff	// 이전과의 차이점 check

-> git diff 명령어를 사용하여 이전과 달라진 차이점을 구체적으로 확인가능

git5

-> git status를 통해서는 파일 수정, 삭제, 추가에 따라 변경사항을 볼 수 있음

git6

-> 변경사항 git add, git commit 후 git log로 확인하면 변경되었음을 확인할 수 있음



4. 과거로 돌아가기

reset

-> 현재내역은 삭제하고 과거로 돌아가는 방식

git reset --hard '돌아가려는 커밋해시값'	// 해당 커밋시점으로 돌아감
git reset --hard										// 아직 커밋되지 않은 내역을 지우고 최종 커밋의 상태로 돌아감

-> git log를 통해 돌아갈 커밋 해시값을 찾아 git reset 하면 해당 시점으로 돌아갈 수 있음
-> 다만, 프로젝트 협업시 공유된 공간에 한번 이미 커밋된 내역을 reset해버리면 충돌문제가 발생할 수 있음 => 한번 공유가 된 커밋내역은 revert를 이용하여 되돌리자!!!


revert

-> reset과 다르게 시점은 현재인데, 특정 커밋값을 삭제하는 방식

git revert '돌아가려는 커밋해시값'

-> 현재상태에서 입력한 커밋해시값에 해당하는 커밋만을 취소하여 반영한 상태라고 생각하면됨
-> 마찬가지로 git log를 통해 돌아갈 커밋 해시값을 찾아 입력하면, 새로운 버전을 만들어 해당 내역을 추가할 수 있음
-> 특정시점 이전의 커밋내역은 놔두고, 특정시점의 커밋내역만 수정해야할 경우에 사용함
-> 이때, 커밋 메세지 default값은 ‘Revert (이전 메세지)’ 인데, 원한다면 수정가능
-> 충돌이 발생할 수 있는데, ‘git rm’을 통해 충돌파일을 삭제하고 ‘git revert –coninue’를 해주면됨

git revert --no-commit '돌아가려는 커밋해시값'

-> 위 명령어를 통해 커밋되지 않은 상태의 해당버전으로 돌아갈 수 있음



5. 차원 넘나들기

하나의 프로젝트를 ‘실제배포용, 테스트용, 새로운 시도용’ 등등 다양한 모습으로 관리하여야 할때 각각 다른 Branch에서 관리하고 확정된 것만 메인차원에 통합하는 방식을 사용한다!!!

Branch 생성하기

// Branch 생성
git branch '생성할 브랜치명'

// Branch 목록확인
git branch

// 해당 Branch로 이동
git swtich '브랜치명'

// 첫번째와 세번째 줄의 코드를 한번에 실행
git switch -c '생성할 브랜치명'

// Branch 삭제
git branch -d '삭제할 브랜치명'

// Branch 이름변경
git branch -m '기존 브랜치명'	'변경할 브랜치명'

// 모든 브랜치의 커밋내역 확인
git log --all --decorate --oneline --graph

-> 생성된 브랜치는 각각 독립적인 git log를 가진다. 각각의 브랜치에서 수행한 커밋내역은 다른 브랜치에 적용되지 않음을 명심하자
-> ‘git log –all –decorate –oneline –graph’ 를 통해 다른 브랜치에서 수행한 커밋내역까지 모두 확인가능하다


Branch 병합하기

-> 여러가지 Branch를 병합하는 방법에는 Merge와 Rebase 2가지가 존재한다

  1. Merge
    -> 2개의 Brunch를 merge 한다고 예를 들면, 2개의 Brunch는 그대로 냅둔채로 끄트머리만 병합하는 방식이 바로 Merge이다
    -> Brunch의 사용내역을 남겨둘 필요가 있는 프로젝트에서 사용한다. 단, Brunch가 그대로 남아있기 때문에, 지저분할 수 있다

    git merge '병합할 브랜치명'

    -> 여기서 ‘병합할 브랜치명’은 메인 브랜치에서 함께 병합할 또다른 브랜치명을 의미한다. 예를 들어, master에서 branch1을 병합하려고 하면, master branch로 swich해서 ‘git merge branch1’를 수행하면 된다
    -> Merge에 의해 끄트머리에 새로 생성되는 것도 하나의 커밋이기 때문에 reset으로 되돌리기가 가능하다
    -> Merge을 마친후 ‘git branch -d’를 통해 merge 완료한 브랜치를 삭제해주면 된다

  2. Rebase
    -> 2개의 Brunch를 rebase 한다고 예를 들면, Brunch를 없애고 기존의 Brunch에 제거한 Brunch에 있던 커밋내역들을 이어붙이는 방식이다
    -> Brunch의 사용내역을 남겨둘 필요가 없고 커밋내역을 깔끔히 정리해야 하는 프로젝트에서 사용된다
    -> 협업시에 이미 공유된 커밋내역에 관해서는 rebase를 사용하지 않는 것이 권장된다

    // rebase작업
git rebase '현재 브랜치를 포함시킬 브랜치명'
   
// master브랜치를 rebase한 마지막 커밋내역으로 위치시키기 위한 코드
git merge '함께 rebase한 브랜치명'

    -> Merge와 다르게 Rebase수행시에 적을 브랜치명은 ‘어디로 현재 브랜치를 이어붙일 것인지’에서 ‘어디’에 해당한다
    -> branch2를 master에 rebase시킨다고 가정할때, 위 명령어를 실행하면 branch2는 마지막 커밋내역에 위치하는 반면, master는 branch2의 커밋내역들을 이어붙이기 전의 커밋에 위치한다. 그러므로 추가적으로 master브랜치에서 branch2를 merge하는 작업이 요구된다
    -> 마찬가지로 Rebase을 마친후 ‘git branch -d’를 통해 rebase 완료한 브랜치를 삭제해주면 된다


Branch 병합시 충돌문제

-> 위의 예시는 다른 파일간 혹은 같은 파일이라도 다른부분을 수정할 경우의 예시이다. 만약, 같은 파일의 같은 위치에 다른 내용이 있는 브랜치들끼리 병합할 경우, 충돌문제가 발생한다

Merge 충돌

-> 같은 파일의 같은 위치에 다른 내용이 있다면 둘 중 하나를 선택하거나, 둘 모두를 적용시킬 수 있다. 본인이 원하는대로 처리한 후에 ‘git add .’, ‘git commit’을 해주면 최종적으로 병합에 성공한 것이다

git merge --abort	// Merge 중지

-> 만약 즉각적인 충돌 해결이 어려울 경우, 위 명령어를 통해 Merge를 잠시 중지하는 방법도 존재한다

Rebase 충돌

-> Merge와 달리 Rebase는 해당 커밋내역들을 일일이 병합할 브랜치로 옮기는 것이기 때문에, 각각의 커밋내역들마다 충돌을 해결해줘야하는 번거로움이 있다. Rebase하려는 커밋내역 개수만큼 Merge충돌 과정을 반복해준다고 생각해주면 된다
-> 같은 파일의 같은 위치에 다른 내용이 있다면 둘 중 하나를 선택하거나, 둘 모두를 적용시킬 수 있다. 본인이 원하는대로 처리한 후에 ‘git add .’를 먼저 해준다. 이후 Merge와는 다르게 ‘git rebase –continue‘를 통해 다음 충돌을 해결해야 한다. 이 과정을 반복하다가 오류가 모두 해결되면 충돌이 해결된 것이다. 마지막으로 Rebase답게 ‘git merge’를 통해 master브랜치를 가장 최근 커밋내역으로 옮겨줘야한다

git rebase --abort	// Rebase 중지

-> Merge와 마찬가지로 즉각적인 충돌 해결이 어려울 경우, 위 명령어를 통해 Rebase를 잠시 중지하는 방법도 존재한다



6. GitHub 시작하기

-> Git으로 관리되는 프로젝트의 원격 저장소로 프로젝트 진행간 협업에 필수적인 tool

  1. Repository 생성 gitHub1

  2. 새작업 or 기존작업 Repository에 올리기 gitHub2 -> 첫 작업 시에는 위의 코드를, 기존 작업하던 것을 Repository에 올리려고 한다면 아래 코드를 입력해주면 됨

git remote add origin '원격 저장소 주소'	// local의 Git 저장소와 원격 저장소 연결(원격 저장소로 이름을 origin으로 설정)
git branch -M main	// 기존 브랜치명을 master에서 main으로(GitHub 권장사항)
git push -u origin main	// local의 커밋내역들을 origin 원격 저장소의 main브랜치로 업로드(한번 사용이후부턴 git push로 가능)
git remote	// 현재 어떤 원격저장소에 연결되어 있는지 확인

cf> 협업시에 GitHub 홈페이지 올린 프로젝트를 다운받을때, Download ZIP이 아니라 ‘git clone’ 명령어를 통해 받아와야 ‘.git’ 폴더까지 가져올 수 있음

git clone '가져올 원격 저장소 주소'

-> 여기서 주소는 아래 그림의 https주소를 복붙하면됨 gitHub3


push & pull

-> push 키워드를 통해 local의 커밋내역들을 원격 저장소로 올리고, pull을 통해 원격 저장소의 커밋내역을 local로 가져온다

git push	// 한번 -u 옵션 쓴 이후에는 이와 같이 사용해도 무방
git pull

=> 원격저장소의 커밋내역보다 local의 커밋내역이 최신이 아니라면 git push 명령어를 실행해도 아래와 같은 오류가 발생함 gitHub4

-> 이런 경우 git pull을 먼저 받아야 하는데, 2가지 방식으로 해결가능하다

git pull --no-rebase	// Merge방식
git pull --rebase	// Rebase방식

-> 위의 코드는 local과 원격저장소의 커밋내역을 2개의 Branch로 분기한 후 다시 하나로 Merge하는 방식이고, 아래의 코드는 원격의 커밋내역을 먼저 pull한후 local의 커밋내역을 그 이후에 이어붙이는 방식이다
-> 협업시에 Rebase 사용하지 않는 것이 좋다고 했지만, pull 상의 Rebase는 사용해도 O.K

git push --force

-> local의 커밋내역을 강제로 원격에 올리는 방식
-> 협업시 상의전에는 되도록이면 사용X(개인 Repository에서만 사용권고)


원격의 Branch

  1. local to 원격 
    git branch -a	// local과 원격의 모든 Branch 나열

    -> local에서 새로운 브랜치를 만들고 ‘git push -u origin 브랜치명’을 통해 원격에 올리면 원격에서도 새로운 브랜치가 생성된다

  2. 원격 to local
    gitHub5 -> 해당 창을 통해 원격에서 Branch를 만드는 것이 가능하다. 이는 다른 팀원이 생성한 브랜치와 다름없다
    -> 이후 ‘git branch -a’ 를 통해 확인해봐도 변경사항이 확인되지 않는데, 이는 아직 원격의 변경사항을 local이 인지하지 못했기 때문이다

    git fetch	// 원격의 변경사항 확인
git switch -t '원격명'/'브랜치명'	// fetch를 통해 확인한 원격의 브랜치 변경사항을 local의 브랜치에도 적용

    -> 위 명령어들을 통해 팀원들이 변경한 브랜치 내역들을 local에 적용하여 사용할 수 있다

git push '원격명' --delete '원격의 브랜치명'	// 원격의 해당 브랜치 삭제

Leave a comment

You may also enjoy