[G-01] Git

1.Git이란

• Git : 개발을 진행하며 작성하는 소스코드가 업데이트 되는 버전을 기록하고 관리할 수 있는 버전관리 시스템 ( 로컬)

  • 파일의 변화를 감지하고 추적함
  • 파일의 각기 다른 버전을 가지고 있기 때문에 공통된 변화를 한번에 관리 가능

• Github : Git으로 관리하는 프로젝트를 호스팅하고, 시공간에 제약이 없이 협업할 수 있는 온라인 서비스 (원격 저장소)

2.Git / Github연결

$ git config --global user.eamil "my eamil"  
$ git config --global user.name "myname"    
$ git config -l   ### 등록된 config의 정보 확인

• --global 옵션은 default로 전체 깃에 적용. 특정 프로젝트에서 이름 다르게 하려면 --global 옵션 빼고 하면 된다.

한마디로 정리하면 위에는 본인의 로컬 터미널에서의 자신이 누구인지 밝히는 작업이라고 생각하면 된다.

로컬 저장소와 원격저장소 연결

$git remote add origin "레파지토리 주소"
$git remote set-url <name> <newurl>  # 원격 저장소 변경하는 명령어

처음 명령어를 통해서 레파지토리와 로컬저장소를 연결한다.

참고로 origin은 깃허브에 존재하는 repository 즉, remote를 뜻하는 단어입니다. 다만 remote에 origin이라는 이름을 붙인 것이다.

3.Git 명령어

3-1. init

$git init # 깃 저장소 초기화

• 처음 git을 하고자 하는 파일에서 git init사용한다.
• 자신이 관리하고자 하는 파일의 위치에서 git init을 수행 -> 깃이 해당 파일의 변화를 감지 및 추적( .git이라는 디렉토리가 생성된다.)

3-2.add

$git add (staging할 파일1) (staging할 파일2)
$git add . # 디렉토리내 모든 파일 올린다

• 그림 1에서의 staging area로 파일을 올리는 명령어이다.
• git add를 통해서 기록을 남기고 싶은 파일을 올리는 명령어

3-3. commit

$ git commit                             # staging area에서 local로 옮김
$ git commit -m "commit 후 출력할 메세지"    # commit 후 메세지 출력
$ git commit -a                          # add와 commit를 동시 진행
$ git commit -am "commit 후 출력할 메세지"   # -a와 -m을 함께 진행

• git commit -a는 한번도 진행하지 않은 파일은 add작업을 수행하여야 한다.

3-4. status

▶tracked와 untracked
git은 자신이 추적하는 디렉토리내의 파일이더라도 무조건 감시하고 추적하는 것이 아닌, 한번 add한 파일이나 commit를 진행한 파일을 감시 및 추적한다.

▶Modified와 Unmodified
이는 변경된 파일이냐 변경이 진행되지 않은 파일이냐로 나뉜다

▶ Staged

• Staging Area에서 file이 staged 되어 반영된 상태.
• Untracked : Git으로 버전 관리를 하지 않는 상태. 파일을 추적 관리하지 않는 상태
• Unmodified : git add로 파일이 Staging Area에 올라갔지만 파일에 변경은 없는 상태. Git은 이 파일을 추적 관리한다.
• Modified : 추적 관리하던 파일이 수정된 상태 (Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified 상태)
• Staged : Staging Area에서 file이 staged 되어 반영된 상태. (add가 진행된 상태)

$ git status       # 상태 확인
$ git status -s    # 상태를 간략히 확인

3-5. log

$ git log           # commit history를 조회하는 명령어
$ git log --all     # 모든 브렌치의 commit history를 조회
$ git log --online  # 로그를 한줄 약식으로 보여준다(많이 사용).

• --all뒤에 --decorate를 추가하면 각 브렌치가 어떻게 위치해 있는지 확인 가능

3-6. push

$ git push origin master(main)      # 로컬 저장소(local repository)에 
                                      있는 내용을 원격 저장소로 올린다.  
$ git push -u origin master(main)   # --set-upstram

• git push -u origin master(main)을 설명하기에 앞서 upstream과 downstream을 설명해야 하는데 여기서는 간단하게 설명한다.
  
  upstream과 downstream은 상대적인 개념이라 origin과 local을 기준으로 생각하면 origin이 upstream, local이 downstream이 된다. 그 이유는 push와 pull을 기준으로 생각했을 때 origin으로부터 local로 흐르는 관계가 형성되기 때문이다.
  다시 넘어와서 CLI로 push를 했을 때 git push -u origin -u master을 설정하는 코드를 본적이 있을 것이다.
  여기서 -u옵션이 --set-upstream의 줄임으로 upstream을 설정한다는 뜻이다. 한번 설정하고 나면 다음부터는 git push나 git pull만 입력하여도 자동으로origin의 main 브랜치로부터 push와 pull을 진행하게 된다.

3-7. pull

$ git pull [원격저장소이름] [branch이름] # 원격저장소의 내용을 가져와 기존 파일과 병합

• 여기서 병합이라는 것은 기존의 파일은 유지하면서 업데이트를 하는것이다.
  만약 본인이 프로젝트를 처음 진행하는 것이 아닌 진행중인 프로젝트가 있다면 pull을 해야하는 것이다.

3-8. clone

$ git clone "clone 할 저장소의 주소" [dir] # 저장소의 내용을 가져와서 
                                          로컬 저장소와 일치시킴

• pull과의 다른점은 기존의 파일이 없어지기에 보통 프로젝트를 처음 시작할 때 사용한다.

3-9. fetch

git fetch [원격저장소 이름]  # 원격저장소에 변동사항만을 가져온다
git merge FETCH_HEAD     # FETCH_HEAD에 업데이트된 원격저장소의 
                           최신 커밋이 현재 브랜치에 병합된다
git fetch; git merge FETCH_HEAD 

• 만약 fetch를 하지않고 push를 할 경우 꼬여서 에러가 날 수 있다. 그럴 경우 pull을 한 후에 push를 한다.
• git fetch; git merge FETCH_HEAD : git fetch + merge FETCH_HEAD 명령어를 한 번에 사용

3-10 . branch

branch란 의미 그대로처럼 가지라고 생각하면 된다.

branch를 하는 이유는 나무처럼 가지가 부러지거나 한다고 해서 나무의 본 뼈대는 문제가 없다. 이것처럼 복사본을 만들어서 변경을 하고 실행을 하는 것이다. 그 후 이상이 없다면 원본 파일에 변경을 하는 것이다

$ git branch 브렌치명    # branch 생성
$ git switch 브렌치명    # branch 전환
$ git restore branch   # 작업중인 파일 되돌린다

조금 더 정확하게 들어가보면 위에서 브랜치는 가지라고 표현하였다.

하지만 가지끼리 병합하는 것등에 대해서 정확하게 왜 사용하는지 궁금할 경우가 있다.

위에 그림처럼 마지막 commit가 f30ab라고 할때 master branch(자동으로 생성되는 branch)가 생성인 된다 (버전에 따라서 main) 이때 새로운 branch가 생성된다고 하자.

생성을 하게 되면 위의 그림처럼 새로운 testing branch가 생성된다.

이떄 head는 현재 나의 branch 위치를 가리키는 인자

위에 그림처럼 생성만 될뿐 위치는 아직 master이다.

이때 위치를 옮기고 싶으면 checkout 이나 switch를 사용하는데 switch를 사용하자

(checkout은 옵션도 많으면 다른 부분에서도 사용되고 switch와는 다르게 restore의 기능도 같이 내장 되어있기 때문이다)

어쨋든 testing으로 위치를 전환하고 다르게 작업하던 것을 작업후에 commit했다고 해보자.

위의 그림처럼 master의 위치는 f30ab로 고정되어있고 새롭게 87ab2가 생성이된다. 이후에 master에서 새롭게 commit를 하면 아래의 그림처럼 새롭게 c2b9e로 생성이 된다. 이처럼 서로 가치를 치며 작업을 수행하면서 나중에 병합을 하는 것이다.

하지만 이때 주의할 점은 만약 저상태에서 병합을 하면 에러가 날 확률이 증가한다.
만약 위의 상황이 아닌 master branch는 고정되어있고 a 와 b로 bracnh가 나누어져 나중에 병합을 한다고 가정해보자.

그럼 나중에 병합할 때 a를 먼저 병합하고 b가 병합을 했을 시 서로 다른 코드를 병합하면 문제가 발생하지 않지만 같은 코드 혹은 같은 줄을 병합을 할 경우에는 높은 확률로 conflict(충돌)가 발생한다. 충돌을 해결하는 방법은 다음에 다루도록 하겠다.