깃, 깃허브 제대로 배우기 (기본 마스터편, 실무에서 꿀리지 말자)

드림코딩 구독자 16.2만명     view 7.6천

 

 

요즘 대중적으로 널리 쓰여지고 있는 깃은 대부분의 개발자들이라면 능숙하게 사용할 수 있을 뿐만 아니라 많은 기업에서도 깃을 선택해서 사용하고 있습니다. 

 

깃은 버전을 편리하게 관리할 수 있도록 도와주는 도구 인데요  우리가 타임머신을 타고 원하는 순간으로 가고 싶은 것처럼 우리가 작업하고 있는 파일들을 원하는 순간으로 다시 돌아갈 수 있게 만들어주는 도구입니다. 

 

많은 개발자들이 자신의 프로젝트를 깃헙에서 관리하고 있고 새로운 회사에 들어갔을 때 깃과 깃허브를 잘 알고 있다면 협업할 때 정말 멋지게 할 수 있기 때문에 선배들에게도 사랑을 받을 수가 있는데요 

 

이처럼 많은 사람들과 많은 기업에서 이용되어 지고 있는 깃을 잘 배워두시면 나의 경쟁력 향상에 도움이 되겠죠.

 

이쯤되면 깃 정말 배워보고 싶으시죠 

저와 함께 깃을 셋업해서 설치하는 것부터 깃을 제대로 배워보고 기초적인 명령어들을 익혀가고 또 깃헙을 통해서 협업하는 방법 뿐만 아니라 깃을 능수능란하게 쓸 수 있는 프로 팁까지 알려드리도록 하겠습니다. 

 

이번 강의는 터미널과 소스트리를 같이 병행해서 여러분들이 다 알아갈 수 있도록 진행해 볼 거예요 

 

우리가 본격적으로 깃을 알아보기 이전에 먼저 깃을 설치해 볼 건데요 

 

깃은 명령어를 기본으로 한 명령어 프로그램입니다.

그래서 터미널에서 커맨드로 배워야지 기술을 정확하게 사용하는 방법을 익힐 수가 있는데요.

물론 UI도 많이 있습니다. 여기 깃 공식 사이트에 오시면 사용할 수 있는 ui 어플리케이션에 대해서 알아볼 수 있는데요 

 

여러분들의 운영체제를 선택하신 다음에 이렇게 스크롤링해서 확인해 볼 수 있습니다.

 

깃허브에 호스트하는 경우라면 깃헙 데스크탑이라는 어플리케이션을 조금 들어보셨을 것 같은데요 

이 어플리케이션은 정말 할 수 있는게 많이 없어요 그래서 이 어플리케이션을 추천해 드리지는 않고요 그 다음으로 아틀라스안에서 만든 소스트리 어플리케이션이 전반적으로 많이 이용되어지고 있는데요

 

UI가 조금 클래식 하지만 간단하고 심플하지만 다양한 기능들을 포함하고 있기 때문에 여러분들이 쓰기에 정말 추천해 드리고요 

그래두 순수 명령어를 이용해서 할 수 있는 것보다는 기능들이 작게 포함이 되어져 있습니다. 

 

만약 화려한 ui를 좋아하신다면 깃크래킹 같은 어플리케이션을 이용하는것을 추천해 드려요

 

현업에서 일하는 대부분의 개발자들은 명령어를 이용해서 사용하는 경우가 많구요  소스트리도 전반적으로 많이 쓰이고 UI를 정말 좋아하는 개발자들은 긱크레켄 도 많이 이용하고 있습니다.

 

터미널을 써야지 진정한 개발자다 UI를 사용하면 좋지 않다 이런 얘기를 많이 하는데요 소스트리와 같은 어플리케이션만을 사용해도 깃에 전반적인 내용을 잘 이해하고 기능을 잘 활용해서 사용한다면 UI 어플리케이션을 쓰는 것도 나쁘지 않다고 생각합니다. 

 

깃을 얼마나 잘 이해하고 기능을 얼마나 잘 활용하느냐가 그것이 관건이겠죠.  하지만 깃을 제공하는 모든 기능을 다 메뉴에 담은 어플리케이션을 찾기도 힘들고요 버튼을 클릭했을 때 어떤 일이 발생하는지 정확하게 알기가 어렵기 때문에 깃을 처음 배울 때는 터미널을 이용해서 명령어로 하나씩 공부해 나가는 걸 추천해드립니다.

 

저는 터미널과 소스트리와 다양한 ui를 병행해서 쓰는데요 .

어떤 경우에 터미널을 쓰고 어떨때 ui를 쓰는지 강의를 통해서 하나씩 알려드리도록 할게요.

 

그리고 강의 마지막에는 제가 정말 좋아하는 어플리케이션 좋아하는 툴 그리고 저의 최애 단축키도 알려드리도록 하겠습니다. 

 

깃을 설치하기에 앞서서 터미널이 필요한데요

저는 맥북에서 iTem2 툴을 이용하고 있습니다. 

 

맥이나 윈도우에서 기본적으로 내장되어 있는 터미널을 이용하셔도 되구요

저처럼 조금 더 편리한 기능이 포함 되어져 있는 터미널을 사용하고 싶다면 맥이라면 iTerm2 를 윈도우라면 cmder 를 추천해 드립니다. 

윈도우에서 cmder 은 기본적으로 포함되어져서 설치되기 때문에 따로 깃을 설치할 필요는 없을것 같아요

 

여러분이 마음에 드는 터미널을 준비해 주시고요 

나의 컴퓨터에 깃이 이미 설치되어 있는지 확인해 보시려면 터미널에서 git --version 을 입력하시면 깃의 버전을 확인해 볼 수 있습니다.

 

만약 깃이 설치 되어져 있지 않다면  git 공식 사이트에서 다운로드 탭에 보시면 여러분들의 운영체제에 맞게 다운로드 하실 수 있습니다. 

UI 어플리케이션은 소스트리 웹사이트에 오시면 여러분들 운영체제에 맞는 것을 다운로드 받을 수 있습니다. 

 

이렇게 터미널과 소스트리까지 준비해 주시고 한번 셋업해 볼까요?

 

깃이 설치하게 되면 깃에 관련된 모든 환경 설정이  .gitconfig 파일안에 저장이 되는데 터미널에서도 간단하게 확인해 볼 수 있습니다. 

git config --list 를 작성하게 되면 모든 설정들을 확인해 볼 수 있구요  

 

터미널로 돌아와서 내가 파일로 열어보고 싶다고 하면  git config --global -e  에딧모드로 열게 되면 터미널에서도 확인해 볼 수 있어요.

 

나는 텍스트 에디터로 열어보고 싶다 이렇게 터미널에서 작성하는 것이 불편하다고 하신다면 여러분들이 쓰기 편한 텍스트 에디터를 연결할 수 있는데 저는 Visual Studio Code를 연결해 보도록 하겠습니다. 

 

code .

 

저는 터미널에서 code . 누르게 되면 현재 디렉토리가 Visual Studio Code로 열어지게 되는데요 이렇게 터미널에서 코드라는 명령어를 통해서 비주얼 스튜디오를 열고 싶다면 여러분들 운영체제에 맞게 설정할 수 있는 방법이 약간 달라지는데 그 부분은 인터넷에서 한번 검색해 보시고요  보통은 이렇게 커맨드 팔레트(command+shift+P)에서 코드라고 검색을 하시면 이렇게 쉘 커맨드 에 설정할 수 있는 명령어가 나옵니다. 

이것을 클릭하면 자동으로 설정이 되구요 .  이 코드를 에디터와 연동해서 서 보도록 할게요.

 

git config --global user.name "Kelly"

git config --blobal user.email "coder@gmail.com" 

 

여러분들은 여러분들 이름과 이메일로 설정하셔야 되요. 자 이렇게 설정하게 되면 원하는 속성도 이렇게 출력해 볼 수가 있습니다. 

 

git config user.name

git config user.email

 

자 이제 마지막으로 하나 더 설정해 볼건데요. 

 

git config --global  core.autocrlf  input (맥 사용자)   작성해 볼게요 

git config --global  core.autocrlf  true (윈도우 사용자) 

 

이것은 운영체제마다 에디터에서 새로운 줄바꿈을 할 때 들어가는 문자열이 달라지는데요 

윈도우 같은 경우는 캐리지리턴과 라인피드가 \r\n 가 동시에 들어가는 반면에  맥에서는 라인피드 하나만 들어가게 됩니다.

 

이런 차이점 때문에 깃 레파지토리가 다양한 운영체제에서 쓰는 경웨 내가 수정하지 않았음에도 불구하고 줄바꿈 문자열이 달라져서 깃 히스토리나 깃블레임을 보는데 문제가 있을 수 있습니다. 

 

이것을 수정할 수 있는 속성이 바로 autocrlf 설정인데요 윈도우에서 true로 설정하게 되면  깃에 저장할 때는 캐리지리턴 \r을 삭제하게 되고 다시 깃에서 윈도우로 가져올 때는 자동으로 캐리지리턴 \r 을 붙여줍니다. 

 

맥에서는 input으로 설정하게 되면 깃에서 받아올 때는 별다른 수정이 일어나지 않지만 저장할 때는 캐리지리턴 \r을 삭제해 줍니다.

맥에서는 \r이 붙지 않음에도 불구하고 이렇게 처리해 주는 것은 맥에서 이메일을 받아 온 텍스트를 복사해서 붙여넣을 때 실수로 \r이 들어갈 수 있기 때문이에요. 그래서 윈도우라면 true로 맥이라면 input으로 설정하는것이  좋습니다. 

 

앞으로 저와 함께 깃을 공부하실 때 어떻게 포인트를 잡고 나가시면 좋냐면 깃에 관련된 전체적인 명령어에 대해서 이해하고 사용하는 연습을 해 볼거예요.

 

깃은 명령어 단위로 이루어진 간단한 프로그램이라고 설명해 드렸는데요  터미널에서 깃을 이용하는 연습을 해볼 거에요

 

자 여기서 깃은 정말 간단하게 깃 다음에 명령어 형식으로 이루어져 있습니다. 깃 config면 config에 관련된 명령어를 수행할 수 있구요 

git add 이런식으로 깃 다음에 나오는 이 명령어는 무엇인지 어떤 일을 하는 아이인지 어떨 때 쓰면 좋은지를 위주로 알려드리고요  보통은 명령어 다음에 옵션들이 여러가지가 있어서 같은 명령어를 수행하더라도 어떤 옵션을 붙이냐에 따라서 조금씩 다른 방식으로 진행할 수 있기 때문에 자주 쓰이는 명령어와 또 자주 쓰이는 옵션들을 위주로 알려드릴거에요.

 

그렇다고 너무 샛까만 터미널에서만 공부하면 여러분들이 지칠 수 있기 때문에 UI 어플리케이션을 이용해서 조금 더 시각적으로 어떻게 활용할 수 있는지도 알려 드릴 거예요. 

 

깃 공식 사이트에서 다큐멘테이션안에 레퍼런스에 오시면 깃에서 이용이 가능한 모든 명령어들을 다 확인해 볼 수가 있어요 

그래서 어떤 일을 하냐에 따라서 깃 다음에 add, status, diff 이런 명령어들을 붙이시면 되구요  또 각각의 명령어를 클릭해서 들어가 보시면 사용 가능한 모든 옵션들을 확인해 볼 수가 있습니다. 

 

모든 명령어를 다 공부하실 필요는 없구요 저와 함께 강의를 통해서 자주 쓰이는 명령어 위주로 함께 공부해 나갈거예요.

 

그리고 각 챕터마다 제가 자주 쓰는 명령어를 정리해서 노션 노트나 또는 pdf로 여러분들이 함께 정리하면서 따라올 수 있도록 문서를 공유해 드릴 거니깐요 그 문서를 함께 병행하면서 강의를 진행하시면 더 좋을 것 같습니다. 

 

깃은 어떤 폴더든 초기화해서 사용할 수 있는데요 저는 대부분의 프로젝트들은 projects라는 폴더안에서 이용하고 있어요

여기에 새로운 깃이라는 디렉토리를 만들어 보도록 하겠습니다. 

 

제가 깃 다음에 쓰는 명령어는 우리가 함께 공부해 나오지만 그냥 터미널에서 이용하고 있는 이런 명령어들은 잘 모르신다면 이런 터미널 명령어들을 공부해 보시면 좋을 것 같아요

 

자 git이라는 디렉토리를 만들고 그 안으로 들어가 보면 깃이라는 폴더안에 지금은 아무런 파일들이 없는 것을 확인해 볼 수가 있어요.

여기에 git init이라는 명령어를 이용하게 되면 깃이 초기화 되었다고 나오는데요.

다시 안에 내용들을 확인해 보면 이렇게 깃이라는 숨겨진 폴더가 있는 것을 확인해 볼 수 있어요. 

폴더나 파일 앞에 . 이 있으면 숨겨진 파일입니다. 

 

그냥 ls 명령어를 입력하면 나오지 않습니다. 

ls -al을 입력하면 숨겨진 파일까지 출력됩니다. 

 

숨겨진 .git 파일을 확인해 보면 깃 레파지토리에 들어 있는 다양한 정보들이 들어 있는 것을 확인해 볼 수 있어요.

이곳은 깃의 내부 구현 사항이 될 수 있겠죠. 

 

깃에 관련된 모든 정보들이 여기 폴더 안에 저장이 되는 것을 확인해 볼 수가 있겠죠. 

그리고 이렇게 깃을 초기화하게 되면 기본적으로 master 브랜치가 생성이 되는데요 

기본적으로 커밋해서 버전을 관리하는 우리의 브랜치는 master 브랜치 입니다. 

 

여기에서 깃을 삭제하고 싶다면 간단하게  rm -rf .git  입력하면 숨겨진 깃을 삭제해 주면 더 이상 깃 프로젝트가 아닌것을 확인해 볼 수가 있습니다. 

 

그리고 git status 로 상태도 확인할 수 있습니다. 

이제 이렇게 반복적으로 쓰이는 명령어를 조금 단축해서 쓰고 싶다면 글로벌안에 엘리아스라는 것을 이용할 수 있는데요 이제 엘리아스를 이용해서 status 타이핑 하기가 귀찮다면 

git config --global alias.st status 로 입력하면 st로 명령어를 내릴 수가 있어요.

 

git st

 

이렇게 명령어를 간단하게 활용할 수 있어요.

 

이렇게 깃에는 명령어와 그리고 명령어에서 쓸 수 있는 다양한 속성값들이 있는데요 이제 이런 것을 확인해 보고 싶을 때는 명령어 다음에 --h 라고 입력하면 간단하게 정보들을 확인해 볼 수가 있습니다. 

 

터미널에서도 확인해 볼 수 있지만 깃 레퍼런스 공식 사이트 탭에 오시면 명령어들을 다 확인해 볼 수 있고요.

 

우리가 살펴보았던 config에 관련된 다양한 속성 값들을 확인해 볼 수가 있어요. 

이제 조금 더 자세히 보고 싶다면 여기 오셔서 확인해 보시면 됩니다. 

 

여기까지 깃을 위해서 셋업하는 시간을 가져봤는데요 이어지는 베이직 파트에서 만나도록 할게요.

 

이제 저와 함께 깃에 바다에 퐁당 빠진 준비가 되셨나요? 

깃의 기술을 정확하게 이해하고 잘 활용하기 위해서는 워크플로워를 이해하는 것이 정말 중요한데요. 깃에는 크게 총 3가지의 작업 환경이 나눠져 있습니다. 

 

첫번째는 우리가 프로젝트의 파일들을 수정하고 작업하고 있는 워킹디렉토리가 있구요  어느정도 작업하다가 버전 히스토리에 저장할 준비가 되어 있는 파일들을 옮겨놓는 스테이징 area와 버전에 히스토리를 가지로 있는 깃레파지토리 또는 깃디렉토리로 나누어져 있습니다. 

 

예를 들어서 프로젝트 폴더에서 파일들을 수정하고 있다가 b.txt와 c.txt가 작업이 어느정도 완료가 되었다면 b.txt와 c.txt을 staging area로 옮겨 두게 되구요  그리고 커밋이라는 명령어를 이용해서 스테이징 에리아에 있는 파일들을 깃 버전 히스토리에 저장하게 됩니다. 

그리고 a.txt을 수정하게 되다가 이제  a 파일도 준비가 되면 다시 스테이징 에리아로 옮겨서 커밋 명령어를 이용해서 다시 히스토리에 저장할 수 있습니다. 

 

이렇게 깃 디렉토리에 저장된 버전들은 체크아웃이라는 명령어를 이용해서 언제든지 원하는 버전으로 돌아갈 수가 있어요

 

이렇게 저장된 깃 히스토리는 나의 컴퓨터에만 보관되기 때문에 내 컴퓨터에 문제가 생기면 이런 히스토리를 다 잃어버릴 수가 있겠죠. 

그래서 보통은 이런 깃 디렉토리를 나의 pc에만 저장에 두는 것이 아니라 깃허브와 같은 서버에 푸쉬라는 명령어를 이용해서 나의 깃 디렉토리를 서버에 업로드 해 둘 수가 있습니다. 

그리고 서버에서 다시 로컬로 다운로드 받고 싶을 때는 pull 이라는 명령어를 이용할 수가 있어요 

 

자 여기에서 각각에 버전들이 어떤 정보가 들어 있는지 한번 살펴보면요  각각의 커밋에는 스냅샷된 정보들을 기반으로 해서 고유한 해시코드가 부가가 되는데요. 이 id를 이용해서 우리가 버전 정보를 참조할 수가 있습니다. 

 

그리고 이 커밋에는 id 뿐만 아니라 어떤 버전인지 저번에 관련된 메시지와 누가 작성했는지 날짜와 시간같은 이런 정보들도 함께 포함이 되어져 있어요.

 

자 이제 다시 깃 워크플로워로 돌아왔어요. 

워킹 디렉토리는 엄밀히 말하면 두가지로 나누어 볼 수 있습니다. 

 

바로 untracked, tracked 2가지로 나눌 수 있는데요 

깃이 이미 알고 있는, 깃이 트래킹하고 있는 파일이라면 tracked 카테고리에 나누어지게 되고 새로 만들어진 파일이거나 기존에 존재하던 프로젝트에서 깃을 초기화 하게 되면 깃이 파일에 대한 정보가 전혀 없는데 아직 트래킹이 되지 않는 파일들을 untracked으로 나누어 볼 수 있습니다. 

 

깃이 트래킹하고 있는 파일 중에서도 지금 이 시점에서 수정이 되었는지 유무에 따라서  수정이안된파일 unmodified, 수정이된파일modified 두가지로 나눠 볼 수가 있어요. 

unmodified 수정이 되지 않았다는 말은 이전 버전과 비교해서 수정 되지 않았기 때문에 오직 수정이 된 modified만 스테이징 area 옮겨달 수 있습니다. 자 이렇게만 보면 약간 헷갈릴 수 있으니까 실습을 통해서 정확하게 한번 알아보는 시간을 가져볼게요. 

 

자 지금부터 저와 함께 멋진 프로젝트를 만들어 볼 건데요. 어러분들이 사용하고 이쓴ㄴ 스펙과 상관없이 공통적으로 이해할 수 있도록 텍스트 파일로 프로젝트를 만들어 볼 거에요. 

 

git이라는 폴더안에 abc라는 총 3가지 파일을 만들어 볼 건데요. 

echo 라는 명령어를 이용해서 간단하게 만들어 볼 거에요. 

 

echo hello world! > a.txt 저장을 하고

 

이 명령어가 익숙하지 않으신 분들은 그냥 작업하는 폴더안에 여러분들이 사용하는 텍스트 에디터를 이용하셔서  

작성하셔도 괜찮아요. 자 터미널에서는 방향키 위 버튼을 누르면 이전에 작성했던 명령어들을 다시 활용할 수 있거든요. 여기에서 a 대신에 b, c 이렇게 동일하게 파일 3가지를 만들어 볼게요.

ls를 누르면 abc가 만들어진 걸 확인할 수 있죠.  그리고 master 브랜치가 초록색에서 주황색으로 변경되었어요. 이것은 워킹 디렉토리에 변경 사항이 발생했다라는것을, 아직 커밋되지 않은 변경사항이 생겼다는 것을 보여주는 거에요. 

여기에서 첫번째 명령어 git status를 이용하면 지금 현재 파일의 상태들을 확인해 볼 수 있어요. 

 

자 대략적인 정보들을 확인해 볼 수 있는데요. master 브랜치 위에서 작업을 하고 있고 아직 커밋은 없고 (No commits yet) 

Untracked files 은 3가지가 있다라고 나와 있고 여기 친절하게 설명이 되어져 있습니다.

 

아직 커밋할 것은 없지만 untracked files 이 있기 때문에 add라는 명령어를 이용해서 track할 수 있다라고 나와 있죠.

nothing added to commit but untracked files present (use "git add" to track)

 

자 지금 워킹디렉토리에서 untracked된 부분에 abc 파일이 있습니다. 

git이 tracked할 수 있도록 스테이징 area에 옮기려면  git add라는 명령어를 이용하면 됩니다. 

a라는 파일을 만들었고 이제 커밋할 준비가 되어 있어  그래서 이렇게 a라는 파일을 추가하게 되면  다시 git status를 하게 되면  

여기 커밋할 준비가 되어 있는 변경사항 새로운 파일 a.txt 있고, b와 c는 untracked 파일에 있는 것을 확인 할 수가 있어요. 

 

이렇게 add라는 명령어를 이용하면 아 이제 이 파일은 준비가 되었어 스테이징erea에 옮겨야지 라고 확인하는 작업인데요. 

이렇게 b.txt, c.txt 다양하게 여러 가지를 작성하셔도 되구요

 

git add b.txt c.txt

 

*.txt 존재하는 txt로 끝나는 모든 파일을 추가하고 싶다면 이렇게 작성하면 b와 c 가 추가될 수 있어요. 

 

git add *.txt 

 

이제 abc 모두 커밋할 준비가 되어져 있죠. 

 

echo raspberry >> a.txt 

 

여기에서 새로운 문자  raspberry 을 a.txt에 추가를 하게 되면요, 다시 git status를 확인해 보면 총 3가지 파일은 커밋할 준비가 되어 있는데 이제는 a라는 파일이 수정되어져 있는 것을 확인해 볼 수 있어요

 

3가지 파일들은 커밋할 준비가 되어 있는데 a라는 파일은 수정되어져 있는 것을 확인해 볼 수 있어요. 각가의 파일의 상태를 조금 더 자세히 확인할 수 있는 명령어는 뒤에서 배우는데 조금 시각적으로 소스트리를 이용해서 보여 드리면 우리가 방금 추가한 레파지토리를 더블 클릭하시면 이렇게 상세한 정보를 확인해 보실수가 있어요.  여기에서 스테이지 뷰 나누기를 클릭하시면 전체적인 상태를 확인해 볼 수 있는데요

 

 

 

윗부분이 스테이징 area 에 해당하구요, 아래부분이 워킹 디렉토리에 해당합니다.  자 이점을 감안해서 보시면  스테이징 area는 우리가 add라는 명령어를 이용해서 추가할 당시 그 상태의 파일들이 저장되어져 있는 것을 확인해 볼 수가 있죠.  

그 이후에 a.txt파일에 raspberry 라른 것을 추가했습니다.  추가된 이 부분은 스테이징 area에 포함되지 않기 때문에 동일한 파일이라고 하더라도 스테이징된 이후에 수정된 내용들은 modified라고 나오는걸 확인할 수 있어요.

 

좀 더 시각적으로 보면 아래 그림과 같은것을 확인해 볼 수 있어요.

여기서 동일하게 git add라는 명령어을 이용해서 a.txt 파일을 추가해서 스테이징에 확인해 보면  a 파일이 스테이징에 옮겨진것을 확인해 볼 수가 있죠. 

그리고 여기에 보시면 git rm cached를 이용해서 다시 스테이징에서 워킹디렉토리로 옮겨갈 수 있다는 걸 확인해 볼 수 있는데요 

git rm --cached  *   전체 파일들을 스테이징 area에서 제거를 하게 되면 다시 git status를 확인해 보시면 

'

다시 untracked된 상태로 돌아온 것을 확인해 볼 수가 있어요.

마지막으로 끝내기 전에 git add에 관련해서 한 가지만 알려드리면 

 

git add . 를 사용하게 되면 모든 파일들을 포함해서 스테이징 area에 추가되는 것을 확인할 수 있어요. 

 

그리고 하나 더 유용한 것은 .gitignore 파일은  깃이나 깃허브에 올리고 싶지 않은 파일들은 명시하는 파일입니다.  만약 log파일을 추가하고 싶지 않다면 .gitignore 파일을 만들어서 추가하시면 됩니다. 

 

echo *.log > .gitignore 

 

.git 깃에 관련된 모든 정보를 가지고 있는 숨겨긴 git 폴더와 

.gitignore 파일에 추가하고 싶지 않은 파일들 정보가 있어요.

 

open .gitignore 파일의 내용을 보면   log.log가 있는걸 보실 수 있어요. 

git status를 다시 보시면 새로 추가된 .gitignore라는 파일은 있지만 더 이상 로그파일은 확인해 볼 수가 있어요. 

 

이런식으로 파일 이름을 하나 작성하셔도 되구요. 아니면  모든 로그를 추가하고 싶지 않으면 *.log 이렇게 지정할 수도 있고 특정한 디렉토리 안에 있는 파일을 추가하고 싶지 않다면  build/ 이렇게 작성하셔도 되구요.  build안에 log들만 추가하고 싶지 않다  build/.log 이렇게 작성할 수도 있어요. 

예를 들어서 보여 드리면   dependencies 관련된 파일들은 절대 트레킹하지 말고 build할때 발생하는 것도 트래킹하면 안된다고 여러가지가 명시되어 있는 것을 볼 수가 있어요.

 

앞에서 보여드린 git status라는 명령어는 우리가 작업하고 모든 작업 내용들을 간단하게 확인해 볼수 있는데요  git status 에 대해서 조금 더 알고 싶다면  -h라는 옵션을 주어서 보시면 모든 옵션들에 대해서 확인해 보실 수가 있구요 git status라고 하면  기본적으로 --long이라는 옵션이 적용이 됩니다. -s 라고 붙이면 조금 더 간단하게 확인해 볼 수 있구요 -b 라고 붙이면 브랜치에 관련된 정보들을 확인해 볼 수가 있어요. 

 

맥에서는 command + k 

윈도우는 ctrl + k

 

를 선택하면 화면이 clear 됩니다. 

 

git status -s 라고 옵션을 주게 되면 간단한 버전으로 확인해 볼 수가 있는데요  앞에 알수없는 알파벳이 표시가 되는데요 

A 초록색은 스테이징 area에 추가된 정보들을 볼 수가 있어요. 

 

.gitignore는 아직 트래킹이 되지 않은 워킹디렉토리에만 있는 것을 볼수가 있어요. 

 

여기에서 c.txt를 바꾸어 보면  echo add >> c.txt 

git status -s 로 보면 c 텍스트는 스테이징 area에 추가가 되었고 워킹디렉토리에는 M 모디파이 수정이 되었다고 정보를 확인할 수가 있죠.  이렇게 간편하게 빠르게 확인하고 싶을때는 git status 뒤에 -s라는 옵션을 주시면 되구요 

조금더 상세한 정보를 알고 싶을때는 옵션 없이 실행하시면 조금 더 상세한 설명들을 보실 수가 있어요.

 

처음에 하실 때는 이렇게 상세한 정보들이 포함된 것을 이용해 보시구요 어느정도 적응이 되신다면 간단하게 확인하면서 진행하시면 좋습니다.  이렇게 git status를 이용해서 어떤 파일이 수정이 되었고 스테이징 area에 있는지 확인할 수 있지만 정확하게 어떤 내용이 수정이 되었는지는 확인할 수가 없어요.   그래서 정확하게 어떤 파일의 내용이 수정이 되었는지 확인해 보려면 git diff를 이용하시면 됩니다. 

 

 

자 이렇게 우리가 파일들을 수정하고 변경한 다음에 마음에 들면 스테이징 area에 옮겨놓고 드디어 첫번째 버전을 만들 준비가 되었습니다. 

 

버전을 만들 때는 커밋이라는 명령어를 이용할 수 있는데요  이제 스테이징 area에 있는 변경사항을 git 레파지토리에 옮겨주는 역할을 합니다.  아무런 옵션없이 그냥 이용하게 되면 이렇게 기본적인 템플릿이 나오는데요.

 

보통은 커밋에 있는 타이틀을 작성하고 그 다음 Description 상세설명 사항을 적는것으로 진행이 되고요.

이렇게 title과 description을 작성한 다음에 저장을 하시고 다시 git파일을 닫아 보시면  commit_editmsg 이렇게 타이틀과 디스크립션을 작성한 다음에 저장을 하시고 다시 파일을 닫아 보시면 파일 2개가 수정되었다는 것을 확인할 수가 있어요. 

 

나중에 뒤에서 자세히 알려드릴건데요. 이렇게 히스토리를 확인하기 위해서  git log을 이용해 보시면 이렇게 커밋과 전체적인 해시코드가 나오는 걸 보실 수 있죠.

누가했는지, 언제했는지, 그리고 타이틀과 디스크립션이 나오는걸 확인할수가 있어요.

자 이런식으로 깃커밋을 이용하는 경우는 많이 없구요.   하나만 더 추가해 볼게요.

 

echo add >> c.txt

 

자 여기에서 변경된 사항이 있다면  git status - s  자. 나오죠. 

git add . 

전부다 추가해 준 다음에 

git commit 다음에 -m  "second commit"  이렇게 간단하게 커밋을 하실수가 있어요. 

 

git log을 확인해 보시면  두번째 커밋이 이루어진 걸 확인할 수 가 있어요.

자 q를 눌러서 밖으로 나온 다음에 이렇게 수정된 파일을 스테이징 area에 옮긴 다음에 커밋을 해야 되는데 나는 내 워킹디렉토리에 있는 변경사항이 모두 마음에 든다면 add 라는 것을 구지 사용하지 않고도 전부 다  메시지 옵션을 함께 해서 커밋을 할 수 있어요. 

 

git commit -am "third commit"

 

그러면 커밋을 어떤 정도의 규모로 해나가면 좋은지는 이어서 영상에서 알려드릴게요.

 

우리가 열심히 만들어서 커밋해 나가는 이 깃 레파지토리는 어떤 규모의 커밋을 해나가면 적당할까요

깃디렉토리에 있는 우리의 커밋들은 히스토리에 창고입니다. 

우리의 작업들을 버전별로 나눠서 관리할 수 있는 너무나 유용한 창고같은 아이이죠  그렇기 때문에 이 히스토리에 전체적인 어플리케이션을 만들어서 하나의 커밋으로 저장하게 되면 아무런 의미가 없습니다. 

 

이 히스토리에 우리가 어플리케이션을 만든다면 이 어플리케이션을 조금 더 세분화해서 기능별로 작은 단위로 만들어 나가는 것이 중요한데요 커다란 코끼리를 히스토리에 한번에 넣기 보다는 작은 단위로 나누어서 히스토리에 저장하는 것이 좋습니다. 

그렇다고 히스토리에 너무 의미가 없는 commit1, commit2 이런식으로 작성하기 보다는 조금 더 의미있는 이름을 지정해서 저장하는 것이 중요한데요. 예를들면, 프로젝트를 초기화하는 commit 하나 로그인 서비스 모듈을 하나 만들어서 다시 commit 을 해두고 그 다음 유저 레파지토리로직을 만들었다면 commit 을 해 놓은 다음에  Welcome page, about page, light theme commit 이런식으로 작은 단위로 그리고 의미있는 이름을 지정해서 히스토리를 바라봤을때 작업한 내용도 빠르게 확인해 볼 수 있고요. 

 

내가 원하는 변경사항을 빠르게 찾아서 자세히 확인해 볼 수도 있고 원하지 않는 커밋을 취소 하기가 편합니다. 

보통 커밋의 메시지는 현재형으로 그리고 동사로 만들어집니다.  init, fix, 이런 내용이 써지고요  커밋을 할때 한가지 주의해야 할 점은요 현업에서 일하는 많은 개발자들이 흔하게 실수하는 내용인데요.  커밋을 할때 내가 클래스를 고쳤다고 하면 정말 그 고친 내용만 포함해서 커밋을 만들어야지 이왕 하는김에 다른 버그도 고치고 리팩토링도 하고 새로운 기능도 넣어볼까 하고 커밋을 하게 되면 코드를 리뷰할때도 혼돈이 오지만 히스토리를 바라볼 때도 너무 너무 혼동이 옵니다. 그래서 커밋 메세지에 맞게 해당하는 그 내용만 포함해서 커밋하는 것이 정말 중요합니다. 

 

커밋은 너무 커도 문제가 되지만 또 너무 작은 단위로 해도 좋지가 않아요. 

이제 어느정도 의미 있는 단위로 나누는 것은 실제로 프로젝트를 하면서 커밋을 해나가면서 조금씩 감을 쌓을 수 있습니다. 

 

여러분에게 조금이나마 도움이 되었으면 합니다. 

 

(log, branch, merge, merge conflicts, github, open source project, pro tips)