Git 학습 일지

# 학습 경험

이틀 동안 git에 대한 것을 배웠다. 학교에서 OSS를 들었던 경험이 있어서 github에 대한 것이 어렵거나 그러지 않았다.

다만 git과 github를 나눠서 인식해야 하는데 정확하지 않게 인식을 하고 있다가

이번 수업과 강의를 통해 정확하게 인식 할 수 있어서 좋았다. (feat.최주호 강사님)

 

그리고 협업에 맞춰서 git강의가 구성되어 있었는데 그것도 좋았다.

 

이번 학습 일지는 다른 학습 일지와 다르게 내가 알았던 내용을 적을 예정이다.

이미 알았거나 익숙하게 사용하고 있는 내용은 적지 않을 예정이다.

그럼 시작한다. ()

# 공부 내용

git -> 파일 관리 시스템

github -> 로컬에서 했던 파일 관리를 협업을 할 수 있도록 도와주는 도구(OSS)

[완벽한 정의는 아니지만 나의 기존 이해를 바탕으로 정의를 내렸으니 반박시 님말이 맞습니다]

 

Github에서 버전 관리를 무시하고 싶은 경우

.gitignore

위 사진에 있는 것 처럼 .gitignore 파일을 이용한다. 이 파일 안에 추적하지 않을 파일을 적어두면 된다.

특히 맥북은 github에 올리지 않아도 되는 DS파일 관리를 할 때 이용하면 편리하다.

 

Git 정리 (내가 몰랐던 것 위주 정리)

git init

상위 폴더에는 하지 않는다. 개별 폴더 단위로 git init명령어를 사용해야 한다.

git add

예전에 git add 명령어를 쓸때 git add [파일명] 주로 이렇게 사용했는데 수업들으니까 주로 git add . 이렇게 쓰셨다.

파일명 하나하나 입력할 정도로 git add [파일명]를 사용했다는 것은 commit을 밀렸다는 이야기... 앞으로 잘 사용해보자

git reset

우선 reset에 대해 이야기 하전에 git revert에 대해 이야기하며 비교 해보자.

 

git reset - 이전 기록을 완전히 취소하면서 전 단계로 돌아가기

git revert - 이전 기록을 취소하지 않는 대신 돌아간다는 기록을 추가하고 전 단계로 돌아가기

 

본격적으로 reset을 알아보자

1. git reset --soft <해시 4자리>

• local repo에 commit된 것을 취소.
• 다시 git commit을 해줘야 함.
• 내가 원하는 곳으로 특정 해더를 이동시켰다고 생각.

2. git reset --mixed <해시 4자리>

• 스테이징 영역까지 취소.
• 다시 git add를 해줘야 함.

3. git reset --hard <해시 4자리>

• 워킹 디렉토리 영역까지 취소.
• 이걸 쓰면 워킹 디렉토리에 있는 파일자체가 날라간다.
• 자주 사용 되는 것

4. git reflog

git에서 commit한 내용은 복구해준다는 것 잊지 말기!!

(완전 유용하니까 혹시라도 잘못 reset 하거나 잘못 merge했을 때 이용하기!!)

• 사용 방법

$ git relog		# 돌아갈 해시 번호를 확인하기 위해

$ git reset --hard <돌아갈 해시 4자리>		# 원하는 곳으로 돌아가기

+비슷한 명령어

바로 이전의 커밋을 덮어쓴다.

$ git commit --amend -m [커밋 메시지]

HEAD

commit이 많아지면 지금 내가 어떤 작업 영역에 위치하고 있는지 포인터가 필요한데 HEAD가 그 포인터라고 생각하면 됨.

• 작업 트리 마지막 커밋을 가르키는 포인터
• 현재 작업 중인 커밋

Checkout

개인적으로 checkout명령어를 사용하면서 신기했던 브랜치가 달라지면 있던 파일도 사라지는게 신기했다.

이전에는 git을 보면서 이게 왜 버전 관리이지? 그냥 클라우드 상에 올리는 도구가 아닌가 생각을 했지만

checkout명령어 덕분에 git이 왜 명령어 관리 툴인지 알게 되었다.

 

작업할 브랜치 지정, 헤드의 위치를 변경.

현재 작업 브랜치의 HEAD위치를 변경한다.

$ git checkout [브랜치명 or 커밋의 해시]

$ git checkout c1
$ git checkout 6d94

 

 

상대 참조

많은 commit이 되었을 때 HEAD의 위치를 손 쉽게 바꿀 수 있는 유용한 방법.

상대적인 참조 제공 [캐럿(^), 틸드(~)]

• 캐럿(^) - 부모 commit을 나타내는 기호
  • 캐럿 1개(^) : 바로 1단게 부모 commit
  • 캐럿 2개(^^) : 부모 commit의 부모 commit

$ git checkout main^

• 틸드(~) - 주어진 숫자만큼 상위 commit으로 헤드 포인터 이동
  • ~1 : 1단계 부모 commit
  • ~2 : 2단계 부모 commit

$ git checkout main~1

git branch

독립적인 작업 공간.

• branch 생성

$ git branch [신규 브랜치 이름]
$ git checkout -b [신규 브랜치 이름]

밑에 있는 것은 새로운 브랜치를 생성하면서 HEAD를 거기로 이동한다.

• branch 이동

$ git checkout [브랜치명]

• branch 삭제

$ git branch -d [브랜치명]

git merge

$ git merge [작업한 브랜치]

이 명령어를 쓸때는 checkout된 브랜치에 있을때 git merge를 써야 한다.

ex) master 브랜치에 topic 브랜치를 merge하고 싶은 경우 -> master 브랜치에서 merge 사용

 

만약 충돌이 발생하면 충돌이 있는 파일을 수정하고 add, commit을 진행한다.

TIP -> ======= 이 줄이 있는 곳을 중심으로 위, 아래를 살피기

 

협업 관련 실무적인 TIP

• 처음 프로젝트를 진행 할 때 코드 구성 형식에 대해서도 논의를 해야한다. 같은 파일을 개발하는 경우 누가 어떻게 할지, 서로 merge할 때 충돌이 예상되는 지점은 없는지 등 본격적인 협업들어가기 전에 충돌 예상 포인트를 먼저 잡고 들어가야 효율적인 일처리가 가능하다.

Github정리

git clone

원격 저장소 등록 + pull 수행

git remote

$ git remote add [원격 저장소 이름 - 보통 origin] [원격 저장소 주소] # 원격 저장소 이름 등록
$ git remote rm [원격 저장소 이름] # 원격지 연결 삭제
$ git remote -v # 원격 저장소 정보 나옴

branch

원격으로 연결된 로컬 컴퓨터에는 아래와 비슷한 형식의 branch가 있다. - origin/master

그냥 로컬에만 있으면 - master

# 협업

샘플링 한 번 해보고 프로젝트 진행 할 것! → 어디에서 충돌이 일어날 지 예측등 전체적인 구조를 미리 먼저 짜기

 

우선 이정도만 작성하고 다음 포스트에서 fast-forward merge, 3 - way merge, git rebase(drop, reword, squash)에 대해 다루면서

협업과 관련된 github를 사용하는 PR에 관련해서는 다음 포스트에 다뤄보도록 하겠다.

# 여담

요즘 실습을하면서 느끼는건데 개발자는 맥북 사용하는게 정말 좋다는 것을 느낀다...

윈도우 여러모로 불편하다... 한국은 대부분 윈도우 환경이라 어쩔 수 없지만 처음 배울때 환경 세팅에 많은 시간을 쓰게되는 것 같다...

 

그리고 협업할 때 동기화가 중요하다는 것을 잊지 말고

작업하기전에 remote repo에서 업데이트 된 것은 없는지 git pull(fetch, merge)를 잘 이용하자!

 

한 번 git clone 했으면 git pull 이용하기!

# 취업 준비 특강

오늘 Ken 강사님이 오셔서 이야기를 해주셨다.

JD에 대해 이야기 해주셨는데 아직 명확하게 생각하고 있는게 없어서 나의 진로에 대해 더 구체적으로 생각해 봐야 겠다는 생각을 했다.

 

기억에 남는 것은 모집 공고를 보고 공고에 깔린 필요를 읽어내는 능력이 인상 깊었는데 이걸 많이 하려면 우선 공부를 많이하고 아는게 많아야 그게 가능하겠다는 생각을 한다.

 

문학 작품 읽으면 화자의 의도를 파악하는 것과 비슷한 느낌이었다.