Git

2022. 3. 2. 10:40Study/etc

Git

깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.

 

 

 

Git Working Flow - 작업 흐름

여러분의 로컬 저장소는 git이 관리하는 세 그루의 나무로 구성되어 있습니다. 

첫번째 나무인 작업 디렉토리(Working directory)는 로컬(실제) 파일들로 이루어져있고, 두번째 나무인 인덱스(Index)는 준비 영역(staging area)의 역할을 하며, 마지막 나무인 HEAD는 최종 확정본(commit)을 나타냅니다.

 

출처 - https://webclub.tistory.com/317

 

 


 

 

VScode를 이용한 Git 초기 세팅

1. 먼저 https://git-scm.com/ 사이트에서 Git을 설치한다.

https://git-scm.com/

 

2. 로컬 저장소가 될 폴더를 만든다. ex) D:\git_sample\git_ex

3. git_ex 폴더에서 우측마우스 클릭. 팝업메뉴에서 Git Bash Here를 선택한다.

4. vscode 에서 확장 Git History를 설치한다.

vscode 확장 Git History 설치

 

 

5. git_ex폴더를 작업영역폴더로 추가한 후, 터미널>새터미널을 연다. 

vscode에서 작업폴더 잡은 후 터미널열기

 

6. 터미널 창 우측에 +버튼을 클릭 해 Git Bash를 선택한다.

우측 + 설정 Git Bash로 변경

 

7. 제대로 세팅된 화면에 $ git status 명령어를 쳐봤다.

폴더 경로를 꼭 확인한다!!

 

 

 

 


 

 

Git 명령어

 

1. Git 저장소 만들기

Git 저장소를 만드는 방법은 두 가지입니다. 
기존 프로젝트를 Git 저장소로 만드는 방법과 다른 서버에 있는 저장소를 Clone하는 방법이 있습니다.

Clone방법은 GitHub에서 포스팅에서 다루기로

 

 

1-1. 기존 디렉토리를 Git 저장소로 만들기

기존 프로젝트를 Git으로 관리하고 싶을 때, 프로젝트의 디렉토리로 이동해서 아래과 같은 명령을 실행합니다.

$ git init

이 명령은 .git이라는 하위 디렉토리를 만든다.

 

생성되면 (master)가 붙는다.
$ git init

새로운 git 저장소가 만들어집니다.


.git 디렉토리에는 저장소에 필요한 뼈대 파일(Skeleton)이 들어있다. 이 명령만으로는 아직 프로젝트의 어떤 파일도 관리하지는 않습니다.

 

1-2. Git 정보 등록

필수사항은 아니다.

$ git config --global user.name "miok"
$ git config --global user.email "aluvy_@naver.com"

 

 

 

 

2. 수정하고 저장소에 저장하기

위와 같이 진행했다면 만질 수 있는 Git 저장소를 하나 만들고 워킹 디렉토리에 Checkout도 했을 것입니다.(master)

이제는 파일을 수정하고 파일의 스냅샷을 커밋해 봅니다. 파일을 수정하다가 저장하고 싶으면 스냅샷을 커밋합니다. 

워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나누어 집니다.

Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이고, Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋하면 저장소에 기록되는) 상태 중 하나입니다.

그리고 나머지 파일은 모두 Untracked 파일이다. Untracked 파일은 워킹 디렉토리에 있는 모든 파일이 스냅샷에 포함돼 있는 것은 아니고 Staging Area에 있는 것도 아닙니다.

 

 

2-1. git status - 파일의 상태 확인하기

파일의 상태를 확인하려면 git status 명령을 사용한다.

$ git status

위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해줍니다. Tracked나 Modified 상태인 파일이 없다는 의미이고, Untracked 파일은 아직 없어서 목록에 나타나지 않습니다. 

그리고 현재 작업 중인 브랜치를 알려줍니다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것입니다. 

 

 

2-2. git add - 파일을 인덱스에 추가하기

git add 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받고 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들을 재귀적으로 추가할 것입니다.

그리고 git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용합니다.

 

git add는 위 작업흐름 중 인덱스에 추가하는 것입니다. 아래 명령어 중 하나를 선택해서 사용할 수 있습니다.

$ git add <파일 이름>
$ git add *
$ git add *.*
$ git add .
$ git add -A

 

 

 

2-3. git commit - 변경사항 커밋하기

수정한 것을 커밋하기 위해 git add명령어로 Staging Area에 파일을 정리했습니다. Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야 합니다.

Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않습니다. 그 파일은 여전히 Modified 상태로 남아 있을 것입니다.
커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인하고 git commit을 실행하여 커밋하도록 합니다.


실제로 staged 변경 내용을 확정하려면 아래 명령을 실행해야 합니다.

$ git commit -m "변경된 메시지 내용을 입력"

git에서 커밋은 변경사항을 내 컴퓨터에 저장한다는 의미입니다. 위 명령어를 실행하면 이제 작업흐름상에 변경된 파일이 HEAD에 반영될 것입니다. 하지만, 원격 저장소에는 아직 반영이 되지는 않았습니다.

그리고 만약에 위 명령어중 -m 메세지 부분을 안적어주면 vim(내장 편집기)이 실행되니 주의바랍니다.

또한 git add 명령을 실행했을 지라도 git add 명령을 실행한 후에 또 파일을 수정하면 파일의 상태는 Ustaged 상태로 나옵니다. 

그렇기 때문에 파일을 수정한 후에는 git add 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 합니다.

이러한 사이클을 반복하지 않기 위해서 다음과 같은 명령을 실행합니다.

$ git commit -am "커밋 메시지 내용"

git commit 명령을 실행할 때 -a 옵션을 추가하면 Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣습니다. 그래서 git add 명령을 실행하는 수고를 덜 수 있을 것입니다.

 

git add 후 git commit -m '메세지' 실행

 

 

 

 

 

 

2-5. git log - 커밋 히스토리 조회하기

새로 저장소를 만들어서 몇 번 커밋을 했을 수도 있고, 커밋 히스토리가 있는 저장소를 Clone 했을 수도 있다. 어쨌든 가끔 저장소의 히스토리를 보고 싶을 때가 있다. Git에는 히스토리를 조회하는 명령어인 git log 가 있다.

이 예제에서는 “simplegit” 이라는 매우 단순한 프로젝트를 사용한다. 아래와 같이 이 프로젝트를 Clone 한다.

$ git log

 

 

 

 

3. 되돌리기

Git에서 이력을 되돌리는 방법은 여러가지가 있지만, 그 중에 대표적인게 Reset과 Revert 입니다. 단어 의미만 보고는 둘 사이의 차이를 알기 쉽지 않은데, 풀어서 설명해보면 Reset은 시계를 다시 맞추드시 이력을 그 당시로 되돌리는 것이고, Revert는 이전 이력은 그대로 두고, 그 되돌릴 커밋의 코드만 원복시킵니다.

 

 

3-1. git reset - 과거로 돌아가기(시간)

*복원할 여지없이 그 이후는 완전히 삭제

Reset은 시계를 다시 맞추는 것입니다. 돌아 가려는 커밋으로 리파지토리는 재설정되고, 해당 커밋 이후의 이력은 사라집니다.

$ git reset 일련번호6자리(git log시 일련번호) --hard
$ git reset <옵션> <돌아가고싶은 커밋>

여기에 옵션이 몇가지 있는데 자주 쓰는 것 hard, mixed, soft 세가지가 있습니다. 영화를 예매하고 검색한 이력인 a3bbb3c 이후에 발생했던 ( 표를 예매하고, 팝콘과 사이다를 구매 같은)변화에 대해서 어떻게 할지에 대한 것입니다.

 

3-1-1. hard

돌아가려는 이력이후의 모든 내용을 지워 버립니다. 이렇게 하면 모든 것들이 지워지고 모든것이 초기화 됩니다.

$ git reset --hard  a3bbb3c

 

3-1-2. soft

돌아가려 했던 이력으로 되돌아 갔지만, 이후의 내용이 지워지지 않고, 해당 내용의 인덱스(또는 스테이지)도 그대로 있습니다. 바로 다시 커밋할 수 있는 상태로 남아있는 것입니다.

$ git reset --sorf a2bbb3c

 

3-1-3. mixed (옵션을 적지 않으면 mixed로 동작합니다.)

역시 이력은 되돌려집니다. 이후에 변경된 내용에 대해서는 남아있지만, 인덱스는 초기화 됩니다. 커밋을 하려면 다시 변경된 내용은 추가해야 하는 상태입니다.

$ git reset --mixed a2bbb3c

 

 

3-2. git revert

*과거로 돌아갔다가 다시 돌아올 수 있는 방법

*돌아갈 시점이 아닌 취소할 시점을 선택한다

*그대로 저장하겠다는 vi명령어  =>  :wq 를 입력한다

Revert는 상태를 되돌린다고 볼 수 있습니다. 커밋을 revert하고 현재 작성중인 코드만 본다면 reset과 동일한 (hard 옵션 준거만 빼고) 결과를 가집니다. 하지만 이력은 같지 않습니다.

이전 이력은 그대로 있고, 커밋만을 되돌렸습니다.

$ git revert 2664ce8



3-3. 언제 reset을 하고 언제 revert를 해야하나?

단순하게 생각하면 reset을 하는 것이 revert를 하는 것보다 이력을 더 단순하게 만들어주기 때문에 revert의 장점이 많지 않아 보입니다. 하지만 이력 중간에 로그 출력하도록 한 커밋이 있고 그 커밋만을 취소하려고 한다면 reset을 사용하여 이후의 이력을 모두 제거하는 것은 이후 이력을 모두 날려버리는 결과를 나을 것입니다. 이런 때 revert를 사용하여 해당 커밋의 내용만 되돌릴 수 있습니다. 또한 이미 원격 리파지토리에 push 를 한 상태라면 reset을 사용하면 reset 하기 이전으로 되돌리기 전까지는 push 할 수 없게됩니다. (물론 force라는 무시무시한 옵션이 있기는 합니다. ) 그래서 이미 push 한 코드라면 미련을 버리고 revert를 하셔야 합니다.

 

 

 

 




Git Branch

모든 버전 관리 시스템은 브랜치를 지원합니다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치입니다.

단순히 브랜치를 "하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역"이라고 기억하시면 됩니다.

출처 -&amp;nbsp;https://webclub.tistory.com/321?category=546363

 

출처 -&amp;nbsp;https://webclub.tistory.com/321?category=546363

 

브랜치는 branch란 명령어로 만들 수 있습니다.

$ git branch 'branchname'

옵션을 지정하지 않고 branch 명령어를 실행하면 브랜치 목록 전체를 확인할 수 있습니다.

 

 

$ git branch '브랜치명'
$ git checkout '브랜치명'
$ git commit

위 명령어는 아래와 같이 한줄로 실행할 수도 있습니다.

위 명령어의 의미는 "브랜치명"라는 이름의 가지를 만들고 갈아탄다는 것을 의미합니다.. 즉, 새 브랜치로 이동하는 것입니다.

$ git checkout -b newData

 

 




Git Merge

Git의 합치기(merge)는 두 개의 부모(parent)를 가리키는 특별한 커밋을 만들어 냅니다. 

두개의 부모가 있는 커밋이라는 것은 "한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다"라는 의미가 있습니다.

브랜치를 땄다면 각 브랜치에는 독립된 커밋이 하나씩 있을 것이고 그 말은 이 저장소에 지금까지 작업한 내역이 나뉘어 담겨 있다는 얘기입니다. 

두 브랜치를 합쳐서(merge) 이 문제를 해결해 보겠습니다.  

아래는 bugFix라는 브랜치를 땄다는 가정하에 실행하도록 하겠습니다.

$ git merge bugFix master
$ git merge master bugFix

첫 번째 명령어를 실행하면 master가 두 부모가 있는 커밋을 가리키고 있을 것입니다. 이 말은 master 가지 상태와 bugFix 가지 상태가 하나로 합쳐집니다. 

하지만 이 상태는 가지를 bugFix의 가지를 master로 이동시킨 것 뿐입니다. 다시말해, 첫번째 명령어는 간단히 bugFix를 master가 붙어 있는 커밋으로 이동시켰을 뿐입니다. 

그 다음 두 번째 명령어를 실행하여 이 가지를 master로 합칠 수 있습니다.

브랜치를 합치지 않은 상태에서 브랜치 간에 이동할 수 있습니다.

$ git checkout master

 

다음의 명령으로는 가지를 삭제할 수 있습니다.

$ git branch -d bugFix

 

 

$ git checkout master master branch로 이동
$ git branch  
$ git merge my-job master branch 에서 my-job branch 의 내용을 가져와 병합한다

 

 

 

 

 


 

 

 

자주 사용되는 명령어 정리

$ git branch -> 로컬 branch 확인
$ git branch -r 서버 branch 확인
$ git checkout -b 브랜치명 브랜치를 만들고 바로 이동
$ git branch -d(D) test 브랜치 삭제
$ git status 현재상태(머지나 추가사항) 확인
$ git add 경로 에러를 해결하고 추가하여 에러해결
$ git stash 임시저장 $ git stash pop 임시저장한파일 불러오기
$ git remote prune origin 깃랩에서 삭제한거 서버와 동기화
$ git push origin :브랜치네임 서버에서 삭제하기
$ git remote $ git push origin dev
$ git config http.postBuffer 104857600 git오류시 해결
$ git merge --squash dev
$ git merge --no-ff feature- : 새로운 가지 따서 merge(관리상 용이)
$ git clone 주소 $ git remote set-url origin 주소 : gitlap 저장소 변경시 설정
$ git remote -v : gitlap 저장소 주소 확인

// 고아 브랜치 만드는 방법
$ git checkout master
$ git checkout --orphan c_YYMMDD_CAMPAIGNNAME
$ git rm -rf .
$ git push origin c_YYMMDD_CAMPAIGNNAM

 

 

 

 

 

 

 

참고:)

https://www.youtube.com/watch?v=lPrxhA4PLoA (개요)

 

https://yuja-kong.tistory.com/48

 

[Git] 메뉴얼 보는법, commit의 옵션, git의 3가지 공간

메뉴얼 보는법 git의 다양한 사용법을 알고 싶을 때 command창에서 git의 메뉴얼을 볼 수 있습니다. $ git --help git --help 명령어를 치면 명령어나 옵션에 대한 설명을 확인할 수 있습니다. (영어...라니

yuja-kong.tistory.com

 

https://rogerdudler.github.io/git-guide/index.ko.html

 

git - 간편 안내서 - 어렵지 않아요!

 

rogerdudler.github.io

 

https://webclub.tistory.com/317

 

Git 기초- 깃(git) 명령어 배워보기

Git Command Git을 사용해서 프로젝트 관리하는 것에 대한 명령어를 배워봅니다.  Git의 기본 개념인 push, pull, commit, branch 등에 대해 알아보며  windows에서의 실행을 전제로 합니다. Git Working Flow..

webclub.tistory.com

 

https://webclub.tistory.com/321?category=546363 

 

Git branch(브랜치)

Git 브랜치 모든 버전 관리 시스템은 브랜치를 지원합니다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생길 수 있습니다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없

webclub.tistory.com

 

 

 

 

 

 

 

'Study > etc' 카테고리의 다른 글

PWA와 하이브리드앱  (4) 2022.04.27
Github  (0) 2022.03.03
Service worker Navigation PreLoad  (0) 2022.01.21
SNS API 연동  (0) 2021.12.22
웹 개발을 하기 위한 PC 세팅  (0) 2021.12.13