[TIL] git & github_200401

이민석·2020년 4월 2일
0

TIL

목록 보기
4/14

대망의 git

 
우선 git, 그리고 github이 뭔지 알아보자.
Linux를 만든 Linus Torvalds의 다른 작품인 git은 VCS, 즉 Version Control System이다.
말그대로 버전을 관리하는 시스템이라는 의미인데 여기서 버전이랑 코드파일들의 버전들을 의미한다. 마치 게임이나 앱의 ver 2.0과 같은 의미의 버전인데 이는 쉽게 생각해서 코드파일들의 변경 사항들을 의미한다. (word에서 draft와 같은 의미라고 생각하면 될듯하다.)

여기서 git은 VCS중에서도 local computer에 위치한 것이다. 물론 git 그 자체로도 유용하겠지만 개발이란 혼자보다는 여러명이서 팀 단위로 진행하는 경우가 많고 협업이 필수인데 이때는 아무래도 같이 공유할 수 있는 저장소가 있어야할 것이다. 이렇게 하기 위해서는 version들이 모여있는 version database를 서버에 올려놓고 같이 공유를 하면 되겠다고 생각할 것이다. 하지만 이런 방법은 서버를 구축하고 보안시스템을 구축하고 해야하는 등등 배보다 배꼽이 커지는 매우 번거로운 상황이 생길뿐 아니라 비용 또한 만만치 않을 것이다.

그래서 사용하게 되는 것이 바로 github이다. github이 바로 앞에서 언급한 version database가 있는 서버를 제공하는 서비스이다. 개발자들 사이에서 코드리뷰라던지 협업은 필수이므로 github을 쓰지 않는 개발자는 거의 없을 것이다. github은 단순히 중앙서버 역할만을 하는 것 이외에도 여러 기능들을 제공한다.

/
아직 아무것도 없는 내 깃헙......
https://github.com/MSL-J
/

개념 정리

  • **Modified** : 말그대로 수정된 상태. 아직 commit되지 않는 파일이다. oh-my-zsh의 agnoster 테마를 사용하는데 빨간색으로 뜬다. ![](https://velog.velcdn.com/images%2Fmslee1996%2Fpost%2F1279ab4e-1da5-433e-a56c-6f15a5773c8e%2F%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%2C%202020-04-01%2023-14-47.png)
  • **Commited** : 수정이 완료되어 git에 저장된 상태. 이러한 행위를 commit이라고 한다. Modified 상태인 파일과 다르게 초록색으로 나타난다. ![](https://velog.velcdn.com/images%2Fmslee1996%2Fpost%2F67df646b-b1ed-4cc4-94c1-5db546bf6ee9%2F%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%2C%202020-04-01%2023-20-19.png)
  • **Staged** : Modified와 Commited의 중간 상태. 이러한 상태가 존재하는 이유는 commit이라는 것이 영어 의미 그대로 매우 무거운 의미의 완료이기 때문에, 즉 정말로 final draft일 때 사용하게 되는 상태이기 때문이다. 따라서 우선적으로 완료가 되었다고 생각되는 파일들을 임시로 "완료" 상태로 두어야할 때 사용하는 것이 staging이다. Staging 상태는 완전 완료 상태가 아니기 때문에 수정이 commited 상태일 때보다 쉽다.
  • **Branch** : 말그대로 가지이다. 이는 git이 각 소스코드의 버전을 저장할 떄 tree형태로 저장하기 때문에 각각의 버전이 하나의 branch가 된다고 생각하면 될것 같다. 하나의 브랜치에는 여러 소스코드의 각 변경사항의 스냅샷들이 저장된다. ![](https://velog.velcdn.com/images%2Fmslee1996%2Fpost%2Fe7cbcb23-b499-400e-92f5-9e330872b5d6%2Fimage.png)
  • **Merging** : 나의 feature branch를 master branch에 합치는 것을 의미한다. git의 장점 중 하나인데 여러사람이 같은 소스코드를 수정할 때 하나의 branch에서 같이 수정하는 것이 아닌 수정하고 싶은 순간의 master branch에서 feature branch로 가지를 뻗어나가 그 feature branch에서 수정을 완료하고 commit한 후 다시 master branch에 merge 시키는 방식이다. ![](https://velog.velcdn.com/images%2Fmslee1996%2Fpost%2Fd17e4dd6-0b66-4ae9-85b4-1474f46b0610%2Fimage.png)
  • **Conflict** : 이는 하나의 master branch에 서로 각자의 feature branch를 merge하고자 할 때, 만약 수정한 부분이 같고 그 수정 내용이 다르다면 merge할 수 없는 상황이 발생하는데 이런 상황을 conflict가 발생했다고 한다. 충돌이 일어나게 되면 git에서 개발자가 직접 충돌이난 부분을 확인하고 수정해주어야 한다.

 

명령어 정리

  • **git init** : .git 저장소를 만든다.
  • **git add** : 파일을 staging한다.
  • **git commit** : 파일을 commit한다. 완료상태로 git에 저장한다. (-m "커밋설명")
  • **git clone** : 다른 소스코드를 받아올때
  • **git status** : 현재 git의 각각 파일의 상태를 보여준다.
  • **git branch** : Branch를 생성한다.
  • **git checkout** : 해당 branch로 이동한다. 이때 commit하지 않은 파일이 있다면 checkout할 수 없는데 아직 완료하지 않은 파일이 있는데 checkout을 하고 싶은 경우 stash 명령을 통해 임시 저장한 후 checkout할 수 있다.
  • **git stash** : 새로운 stash가 만들어지며 working directory를 클리어해 넘어갈 수 있게 한다. _git stash list_를 통해 저장한 stash 목록을 확인하고 _git stash apply []_을 통해 다시 가져온다. 하지만 apply 명령어는 적용하기만하고 stash 자체는 아직 남아 있기 때문에 _git stash drop[]_을 통해 제거한다.
  • **git push** : git을 서버로 push 한다. 만약 클론해서 가져온 원격 저장소가 아니라면 _git remote add origin <주소>_를 통해 알려주고 push해야한다.
  • **git pull** : 다른 저장소나 가지의 변경 내용이 받아지고 병합된다.
  • **touch** : 파일을 생성한다.
  • **vi** : 파일을 git에서 열어본다.
  • **:wq**: vi를 한 상태에서 수정한 후 저장하고 나올때.

 

git을 다뤄보면서 느낀점은 상당히 staging하고 commit하고 push하고 등등 상당히 반복적인 일을 하게 된다는 점이 었다. 처음에는 terminal이라는 환경자체도 상당히 원시적인것 같고 git의 구조가 머리속에서 잘 그려지지 않아 어려웠지만 계속 반복적인 일을 하다보니 나름 익숙해진 것 같다. 하지만 아직까지 충돌이 일어나서 그것을 해소하는 부분은 완벽히 이해되지는 않는다....

profile
Still learning

0개의 댓글