[내배캠] GIT 기초 특강 1차

내일 배움 캠프의 정식 개강 OT를 하고 첫 시작은 'Git 기초' 특강이었어요.

이전 사전 캠프 팀 과제에서 git을 활용해보려 했는데 잘 몰라서 결국 활용하지 못해서 아쉬웠는데 첫 특강부터 필요했던 부분에 대해서 배울 수 있을 것이라는 생각에 기대가 되었습니다.

Git 특강은 총 두 번 배정되어 있었는데 오늘은 첫 강의였어요.

 

이제부터 첫 강의에 배웠던 내용을 정리해보려고 합니다.

 

기본 배경 지식 - CLI 명령어 익히기

GIT은 명령어 기반 인터페이스(CLI) 도구이다.

명령어를 기반으로 동작할 수 있는 도구라고 할 수 있다. 때문에 명령어 만으로 컴퓨터를 동작할 수 있는 방법을 알아야 한다.

GIT을 설치했다면 윈도우에는 git bash, mac에는 terminal이 설치되었을 것이다.

 

명령어는 마우스의 클릭과 같다. 암기의 대상이 아니라 숙달의 대상입니다. 쓰면서 익숙해져야 한다.

 

명령어 정리

- pwd : 현재 경로 확인하기

경로에는 절대 경로(전체 경로)와 상대 경로(현재의 경로를 기준으로 나타내는 경로)가 있다.

현재의 경로는 '.'으로 지칭합니다. 이 부분은 개발 전반에서 많이 언급되므로 기억하는 것이 좋다.

상위의 경로는 '..'으로 나타냅니다.

 

- ls : 현재 경로의 파일 및 폴더 조회하기

- ls -al : 현재 경로의 숨김 파일 및 폴더까지 모두 목록으로 조회하기

숨김 파일과 폴더는 파일 이름 앞에 '.'이 붙는다.

 

- cd <경로> : <경로>로 이동하기

이때 경로는 상대 경로, 절대 경로 모두가 올 수 있다.

- cd .. : 상위 디렉터리로 이동하기

- cd . : 현재 디렉터리로 이동하기

- cd ~ : 홈 디렉터리로 이동하기

 

- touch <파일명> : <파일명> 이름으로 비어 있는 파일 생성하기

    ex) touch abc.txt

 

- cat <파일명> : <파일명>의 파일 내용을 명령어 창에서 확인하기

 

- vi <파일명> : <파일명> 편집하기

   가장 중요한 명령어에 속한다.

   메모장, 코드 편집기 등도 다 편집기라고 할 수 있다.

   vi <파일명> 을 누르면 아래의 창이 나온다.

이 창을 자주 보게 될 것이다. 왜냐하면 git에서 vi편집기 기능을 자동으로 제공해주기 때문이다. 

해당 창이 처음 열리면 해당 창에 어떤 것도 입력하지 못할 것이다. vi 편집기에서 어떤 것을 입력하려면 입력 모드로 바꾸어야 한다.

'a' or 'i'를 눌러 입력모드로 바꿔줘야 한다.

입력이 다 끝난 뒤 입력모드에서 빠져나와야 한다. -> Esc 키

그리고 내용을 저장하려면 ':w"를 눌러주면 된다. w는 write의 준말이다.

그리고 vi 편집기 창을 닫으려면':q'로 닫아주면 된다.

':wq'로 한 번에 저장하고 닫을 수 있다.

 

- rm <파일명> : <파일명> 삭제하

 

- mkdir(make directory) <디렉터리 이름> : <디렉터리 이름>(폴더) 생성하기

 

- rmdir <디렉터리 이름> : 비어있는 <디렉터리 이름>(폴더) 삭제하기

 

- rm -rf <디렉터리 이름> : 비어 있지 않은 <디렉터리 이름> 삭제하기

 

 

깃이 무엇이고 왜 배워야 할까?

깃이 없으면

1. 변경 내역 확인이 어렵다.

2. 작업을 되돌리기 어렵다.

 

수정을 거쳤을 때 버그가 있거나 피드백이 안 좋을 때 이전 버전으로 돌아가야 한다.

그 과정에서 하나의 소스코드만 하더라도 여러 번의 삭제, 수정, 추가가 이루어졌을 것이고 이러한 소스코드도 많을 것이다.

변경 사항들을 기억하지 않으면 이전의 버전으로 돌아가기 쉽지 않을 것이다.

3. 협력하기 어렵다.

깃이 존재하는 목적이라고도 할 수 있다.

깃이 없다면 각각의 사람이 어떤 작업을 했는지 서로 다 맞춰보고 다 알아야 한다. 그러한 과정은 굉장히 번거로울 것이다.

그래서 생겨난 도구가 Git 이다.

버전(commit) : 유의미한 변화가 결과물로 나온 것

                       ex) 새로운 기능 추가, 버그 삭제, 수정

깃을 활용하면

1. 변경 내역들을 기억하며

2. 필요하다면 작업을 되돌리며

3. 여러 명의 코드를 쉽게 나누고 합치며

개발할 수 있다. 

 

깃허브

깃 허브는 '원격 저장소 호스팅 서비스'이다. 

-> 원격 깃으로 관리한 프로젝트 호스팅 서비스

-> 인터넷 상에서 깃으로 관리한 프로젝트 호스팅 서비스

-> 인터넷 상에서 깃으로 관리한 프로젝트 관리해주는 서비스

버전 관리의 큰 그림

깃이 관리하는 세 개의 공간

 

1. 작업 디렉터리(working directory, working tree) : 버전 관리의 대상이 위치하는 공간(.git(숨김폴더)이 있는 디렉터리)

     - 변경사항(추가, 수정, 삭제)들을 모두 다 버전으로 만들 필요는 없다. 

2. 스테이지(index) : 다음 버전이 될 후보가 올라가는 공간

     - '작업 디렉터리'에서의 변경사항 중 다음 버전이 될 후보를 선정해서 '스테이지'에 올려준다.(유의미한 변경사항)

3. 저장소(repo, repository) : 버전이 만들어지고 관리되는 공간

     저장소에는 크게 2가지가 있다.

      - 로컬 저장소(local repository) : 내 컴퓨터 속에만 존재하는 저장소(내 컴퓨터에서만 버전이 만들어지고 관리된다.)

      - 원격 저장(remote repository) : 깃 허브의 저장소처럼 인터넷 어딘가에서 버전이 만들어지고 관리되는 공간.

 

위의 3개 중 '스테이지'와 '저장소'는 깃이 관리하는 가상의 공간이다. 때문에 작업 디렉터리는 눈으로 볼 수 있고, 스테이지와 저장소는 눈으로 볼 수 없다.

Git을 이용해서 개발하는 과정은 위의 과정을 반복하는 것이다.

작업 디렉터리에서 변경사항을 만든다. -> 유의미한 변경사항을 스테이지에 추가한다. -> 버전을 만든다.

 

하나의 버전이 만들어지는 과정

- 작업 디렉터리 내에서 변경사항 생성

- 스테이지로 add

- 저장소로 commit

 

저장소와 버전 만들기

명령어 정리

우리가 만드는 모든 버전(commit)에는 짧은 커밋메시지를 남겨야 한다. 왜냐하면 커다란 프로그램은 commit이 많이 쌓일 것이다. 이 commit이 어떤 변경사항인지, 왜 만들었는지에 대한 내용을 담은 메시지를 남겨야 한다.

commit 메시지는 제목과 본문으로 이루어져 있고, 본문은 생략이 가능하다.

commit 메시지는 제목, 본문, 이해를 돕기 위해 오류 코드, 링크 등을 첨부할 수도 있다.

 

git commit -m 은 간단한 커밋메시지를 남기는 방법이다. 하지만 실무에서는 커밋메시지를 최대한 자세하게 남겨주는 것이 가장 좋다.

 

커밋 목록을 보는 다양한 방법

명령어 정리

위의 다섯 가지 중에 상단의 3개를 목록 조회에서 많이 사용한다.

아래의 두 개는 나중에 살펴보면 된다.

 

작업 내역 비교하기

명령어 정리

3번째 커밋과 커밋을 비교할 때는 유의사항이 있다. 커밋의 순서에 따라 결과가 달라질 수 있다. 때문에 커밋끼리 비교할 때는 커밋 해쉬 순서에 유의해야 한다.

 

브랜치 관리하기

Git이 존재하는 이유는 branch(브랜치) 때문이라고 해도 무방할만큼 브랜치는 Git의 꽃이라고 볼 수 있다. 동시에 알아햐 하는 내용이 가장 많은 부분이기도 하다.

브랜치는 여러 분기(갈래, 흐름)로 버전들을 만들고 관리하는 방법이다.

위의 그림에서 색깔 하나 당 하나의 분기라고 볼 수 있다. 그 분기를 브랜치라고 한다.

한 색깔의 브랜치에서 쌓이는 커밋들은 그 색깔과 관련된 커밋들만 쌓아올릴 수 있다. 그 색깔에서 쌓은 변경사항들은 다른 색깔의 브랜치의 커밋들과 무관하다.

그렇게 쌓아올린 다른 브랜치들이 완성되면 다시 합칠 수도 있다.

 

그렇다면 브랜치를 사용하는 이유는 무엇일까?

1. 브랜치가 없다면 합칠 때 문제가 발생할 수 있다.

- 서로의 작업과 전혀 관련 없는 부분도 확인해야 하며, 같은 코드를 다르게 수정한 부분 혼재할 수 있다.

                                                                                               -> 충돌이 발생했다고 한다.

- 일일이 수작업으로 합쳐야 함

- 때로는 서로의 코드를 합치다 실수가 생길 수도

 

2. 프로그램의 버전이 많아지면 요구사항은 더더욱 많아진다.

여러회사, 사용자에게 프로그램을 제작해서 제공하는 회사에 다닌다고 가정해보자.

당연하게도 우리가 제작한 프로그램에 대한 피드백이 있을 것이다. 때로는 그러한 피드백이 상충하는 경우가 생길 것이다.

만약 브랜치가 없다면 프로그램을 복사하여 각각의 커밋을 만들어 사용자에게 제공해야했을 것이다.

 

프로그램의 버전이 많아지면 요구사항은 더더욱 많아진다. 각 버전에 따른 요구사항이 생기기 때문이다.

그러한 모든 요구사항들을 모든 버전별로 복사에서 커밋을 만들어서 제공하는 것은 낭비라고 볼 수 있다.

 

이때, 브랜치가 있다면 이러한 문제를 해결할 수 있다.

- 브랜치는 버전의 분기

- 브랜치로 버전의 분기를 관리한다.

    a. 브랜치를 나눈다.

    b. 각자의 브랜치에서 작업한다.

    c. (필요하다면) 나눈 브랜치를 합친다.

위와 같이 합칠 때, 커밋들의 같은 부분을 다르게 수정한 부분만 보면 된다.

 

브랜치의 이름

최초의 브랜치, master브랜치

git log를 사용하면 브랜치에 쌓여 있는 커밋을 볼 수 있다.

 

이렇게 나누어진 브랜치 중 특정 브랜치에서 작업하는 방법을 알아보자.

1. head

    - 현재 작업 중인 브랜치의 커밋을 가리킨다.(포인터)

    - 일반적으로 현재 작업 중인 브랜치의 최신 커밋을 가리킨다.

    - 한 마디로 "내가 지금 어디에서 작업 중인가"를 가리킨다.

2. checkout

    - 특정 브랜치에서 작업할 수 있도록 작업 환경을 바꾸는 것

    - head의 위치를 특정 브랜치의 최신 커밋으로 옮김

    - git checkout <브랜치명> 을 사용하여 해당 브랜치의 head로 옮길 수 있다.

 

3. merge

    - 브랜치를 합친다 = 브랜치를 병합(merge)한다.

병합에는 크게 두 가지 방법이 있다.

    - 새로운 커밋을 만들지 않는 병합 -> 빨리감기 병합

    -  새로운 커밋을 생성하는 병합 -> 일반적인 병합

ㅐ

새로운 커밋이 만들어지는 상황에서 git merge bar라는 명령을 내리면 커밋 메시지를 입력할 수 있는 화면으로 넘어간다. 

왜냐하면 이러한 병합은 새로운 커밋을 만드는 병합이기 때문이다. 이것을 저장하고 닫아주면 병합이 이루어진다.

 

명령어 정리

충돌 해결하기

브랜치를 합칠 때 '같은 코드를 다르게 수정한 부분 혼재할 수 있다.'고 위에서 언급했다. 이러한 경우를 충돌이 발생했다고 도 했다.

이러한 충돌 해결하기는 충분히 연습해 주는 것이 좋다. 왜냐하면 현업에는 충돌이 빈번하게 발생한다. merge를 할 때 뿐만 아니라 pull 할 때 등 다양한 상황에서 충돌이 발생할 수 있다. 충돌이 발생하면 파일의 모양이 제멋대로 변경된다. 

이런 것들을 연습하지 않으면 충돌이 일어난 상황을 보고 당황할 수 있다. 하지만 충돌은 현업에서 일상적인 이슈이기 때문에 충돌을 마주치고 해결하는 것에 익숙해지도록 연습하는 것이 좋다.

 

그렇다면 이러한 충돌을 어떻게 해결할 수 있을까?

충돌이 발생했을 때는

1. 충돌을 해결한다. (어떤 브랜치의 내용을 반영할 지 직접 선별한다.)

    -> 반영할 내용만 두고 다 지워주면 된다.

2. 다시 커밋한다.

이와 같은 절차로 대처할 수 있다.

 

충돌은 다양한 상황에서 발생할 수 있지만, 그것을 해결하는 방법은 모두 같다. 위와 같은 절차로 해결하면 된다.

 

충돌은 방지하는 것보다 해결하는 것이 중요하다. 원천적으로 충돌은 흔하게 발생하는 문제이기 때문에 충돌을 최대한 줄이려면 커뮤니케이션을 잘해야 하겠지만 아예 방지할 수는 없다. 그보다 충돌을 잘 해결하는 것에 중점을 두자.