이번에는 Git 연결과 push/pull을 해보겠다
분명 코딩을 하다 보면 프로젝트나 백업 등등 여러 가지 많은 이유로 코드를 공유해야 할 일이 존재할 것이다.
이럴 때 그냥 코드를 보여주거나 다른 방식으로 공유하는 것도 좋지만 Git이라는 좋은 툴이 존재하기에 다루는 방법을
알고 있다면 공유 시에 매우 편리함을 느낄 수 있다.
일단 이 Git이라는 것은 간단히 말해서 버전 관리 시스템이다.
말 그대로 버전을 관리해 준다고 이해하면 편할 것이다.
예를 들어 하나의 프로그램을 여러 명의 포지션별로 나뉘어 코딩을 한다고 가정하자
그럼 A와 B의 프로그램이 생길 것이고 이를 나중에 합쳐야 할 텐데 이때 하나씩 합친다면 아마 엄청난 시간이 걸릴 것이다.
또한 버전을 관리한다고 했는데 예를 들어 v1이라는 기존의 버전 프로그램이 존재하는데, 이를 개선하기 위해 디버깅을
할 때, 분명 이 v1이라는 프로그램을 그대로 백업하고 새로운 버전의 프로그램으로 개선해야 할 것이다.
만약 디버깅을 하다가 실패할 경우를 대비하기 위해서이다.
그래서 Git이 필요하다. 기존의 프로그램은 놔두고 기존의 프로그램에서 새롭게 디버깅을 한 다음 기존과 합쳐서 새로운
버전을 만들 수 있기 때문이다. 또한 Git은 기존의 프로그램에서 수행하고 싶은 새로운 실험이나 새로운 기능을 다른 공간에서 실행 가능케 해 준다. 이에 Git은 매우 유용한 툴이라고 볼 수 있다.
가장 많이 사용하는 VScode를 사용하여 Git에 연결 및 push/pull 하는 방법을 설명하겠다.
일단 처음에는 Git에 저장하는 방법을 설명하겠다.
처음에 VScode를 열고 File -> Open new Folder를 선택하여 새로운 폴더를 생성 및 선택하여 열어준다.(파일 이름은 한글이 포함되면 안 된다.)
그리고 왼쪽의 소스제어 버튼을 눌러서 initialize Repositoory(저장소 초기화)를 눌어주어야 한다.
그리고 코딩을 한다.(여기서는 그냥 아무 파일이나 만들고 내용도 아무렇게 작성했다.)
그리고 다시 소스제어로 가서 Commit을 누르면 된다. 그럼 아래와 같이 터미널에 이름과 이메일을 입력하라고 나올 것이다.
그전에 터미널의 오른쪽 부분을 보면 터미널에서 실행할 여러 명령창을 선택할 수 있는데 여기서 Git Bash를 선택하면 된다.
Git Bash를 누르고 본인의 이름과 이메일을 작성하고 Enter를 누르면 이제 Git에서 이 코드를 누가 작성했는지 표시해 준다.
여기서는 간단하게 name = p1, email = p1@naver.com으로 작성하였다.
그리고 이제 소스제어(source control)에 들어가서 Staged Changes에 add(커밋 대기 상태)하고, Commit을 하며 Git에 기록된다.
respository(기계영역)과 working directory(사람의 영역)으로 나누어 볼 수 있는데, 여기서 working directory는 staged changes
즉 stage area라고 볼 수 있다.
그리고 이제 터미널에서 git log 명령어를 넣어주면 언제 Bash 하였는지 그리고 누가 하였는지 나오게 된다.
그리고 이제 여기서 중요한 개념이 등장한다. 바로 HEAD와 MAIN이다. HEAD와 MAIN을 얘기하면 매우 길어서 간단하게 개념을
표현하면 HEAD는 현재의 버전을, MAIN은 마지막 버전을 가리키고 있다고 생각하면 된다.
즉 예를 들어서 v1을 마지막 버전으로 작성했다고 하자. 그러면 HEAD는 v1을 가리켜야 하며, MAIN 또한 마지막 버전인 v1을 가르켜야 한다. 이떄 HEAD는 MAIN을 가리키고 MAIN은 마지막 버전인 v1을 가르켜야 지금 현재 실행 하려는 v1을 실행 할 수 있을 것이다.
그럼 여기서 다른 버전인 v2를 생성했다고 하자. 그럼 HEAD는 현재의 버전을 가르켜야 하기에 v2를 가리키고, v2의 부모버전은 v1을 가리킨다. 즉, 새로 생성되는 버전은 현재 HEAD가 가리키는 버전이 된다고 보면 된다. v2가 생성이 되면, HEAD는 현재의 버전인 v2를 가리키고, MAIN은 자연스럽게 v2를 가리키게 된다. 그럼 여기서 어차피 둘 다 v2를 가리키게 되므로 HEAD는 MAIN을 가리키고 이 MAIN은
마지막 버전인 v2를 가리키게 된다. 이렇게 따로 HEAD와 MAIN을 두는 이유는 버전을 따로 관리하기 위해서이다. 만약 현재의 버전이
실패하면, 그전의 성공했던 버전으로 돌아가면 되기 때문이다. HEAD를 각각 실행하고 싶은 버전으로 옮겨가면서 말이다.
물론 이러한 행동에는 위험성도 존재한다. 예를 들어 HEAD와 MAIN을 서로 다르게 두고 실행하면, 나중에 혼동이 발생하고 이는 버전의 휘발까지 이어질 수 있기 때문이다.
그럼 여기서 버전을 여러 개 동시에 보거나, HEAD와 MAIN을 좀 더 직관적이고 알기 쉽게 보면서 이러한 HEAD와 MAIN의 현재 가리키고 있는 버전을 보는 방법이 있다.
먼저 왼쪽 사이드바에 있는 Extensions에 가서 git graph를 선택하고 이를 설치한다.
설치한 다음 하단의 왼쪽 부분을 보면 git graph가 새로 생긴 것을 확인할 수 있다.
이를 누르면 지금 현재 git에 commit 되어있는 버전과 해당 버전에 관해서 여러 정보들을 볼 수 있고, 여기서 HEAD와 MAIN을 제어할 수 있다.
위와 같이 현재 버전과 HEAD, MAIN 그리고 Commit ID와 Parents가 나오며, 작성한 사람과 Commit 날짜가 나오게 된다.
그럼 여기서 새로운 버전을 만들고 다시 Commit을 해보자. 새로운 파일 이름은 work2라고 하고 내용은 간단하게 작성했다.
그리고 wor1 내용에 추가를 하고 저장을 했다. 항상 Commit을 하기 전에는 저장을 해야 Commit이 가능하다.
그럼 소스제어에 변경된 파일 개수가 커밋가능하다고 표시가 된다.
그리고 Commit을 v2로 하게 되면, 이전의 버전 v1 위에 새로운 버전 v2가 생기게 되고 이 v2는 Parents를 v1으로 갖는다.
Parents ID를 보면 v1과 같은 것을 볼 수 있다. 그리고 버전에 저장된 파일에 대해서도 나타나고 있다.
버전은 항상 생성 일시의 스냅숏과 같다.
그리고 이제 여기서 HEAD를 옮기는 방법은 간단하다. 일단 HEAD가 무엇인지 보자
HEAD는 색이 채워지지 않은 파란색 원으로 표시된다. 즉 현재 버전을 의미하고, 이는 현재 실행하려는 버전을 의미한다.
만약 실행하고 싶은 버전이 있다면 해당 버전에 오른쪽을 클릭하면 다음과 같은 메뉴가 나오고 여기서 checkout을 누르면 해당 버전으로
HEAD가 옮겨가고 실행을 하면 해당 버전이 실행이 된다.
지금까지는 같은 MAIN에서 여러 가지 버전의 프로그램을 만들어 보았다. 이전의 생성된 버전을 부모로 가지고 자식의 버전이 부모를 상속하면서 말이다. 근데 이렇게 계속하면 문제가 생긴다. 예를 들어서 코딩이 간단하면 큰 문제가 없는데 점점 코드가 많아지고, 기능이 추가된다면 분명 중간중간 실패할 때도 생길 것이다. 이때 실패 할 때마다, 현재 버전을 버리고 이전 버전으로 돌아가야 하는데 매번 이러면 매우 많은 시간과 노력을 들여야 할 것이다. 또한 작성 중이던 성공했던 나머지 코드줄도 버려야 할것이고, 잘못된 checkout으로 인해 작성중이던
버전이 날아갈 수도 있다. 예를 들어 v2에서 실패를 해서 v1으로 HEAD를 옮겨서 작성하다가 성공한 코드가 있어서 새로운 버전으로 옮겨가고자 한다. 이때 새로운 버전으로 저장하면 v2에는 HEAD도 MAIN도 가리키고 있지도 않다. 결국 프로그램에서는 아무것도 가리키지
않으니 큰 의미가 없다고 생각하고 날려버릴 수 있다. 물론 그전에 물어보겠지만 사용자의 부주의로 경고 메시지를 무시한다면 해당 버전이
사라질 것이다. 물론 해당 버전의 ID를 가지고 있다면 복구가 가능할 수 있겠지만, 매우 복잡하다. 이러한 절차를 밟을 바에는 새로운 branch를 생성해서 실험을 하고, 병합을 할 것인지 삭제할 것인지 결정하는 게 훨씬 더 정신적으로, 육체적으로 나을 것이다.
그럼 이제 branch(가지)를 만드는 방법을 설명하겠다.
원하는 버전에서 오른쪽 클릭을 하면, Create Branch 옵션이 있고 이를 클릭하면 다음과 같이 branch를 생성할 수 있다.
branch 이름은 exp로 만들었다. 그럼 v2에 새로운 branch가 생기고, HEAD는 exp를 가리키고 있는 것을 볼 수 있다.
또한 MAIN은 v2에 되어있는 것을 볼 수 있다. 즉 현재 실행을 하면, exp가 실행되고 여기서 실험을 하다가, 실패하면 다시 MAIN으로 돌아오면 된다.
그럼 이제 여기서 조금 더 깊게 들어가 보자. 바로 MAIN과 exp를 넘나들면서 버전을 만드는 것이다.
일단 위에서 한 것처럼 새로운 폴더를 만들고 파일도 새롭게 만들어준다.
그리고 새로운 파일 work1을 m1으로 메인에 커밋한다.
그리고 새로운 branch를 만들고 이를 exp로 저장한 다음 HEAD를 exp로 옮긴 다음에 exp에 기존의 파일 work1을 v1으로 커밋한다.
그럼 아래와 같은 git graph를 얻게 된다.
그리고 여기서 이제 exp에 HEAD를 두고, 새로운 파일(exp)을 만들어서 새로운 버전인 e1으로 저장하고 커밋하면 아래와 같이
MAIN과 exp가 각각 서로 다른 방향으로 가고 있는 것을 볼 수 있다. 결국 이 말은 서로 영향을 끼치지 않지만 v1을 상속받은
버전이라는 것을 알 수 있다. 이렇게 하면 exp와 MAIN을 넘나들면서 실험과 그 결과를 얻을 수 있다.
이제 이렇게 실험을 할 수 있는 환경이 만들어졌다. 그럼 이제 실험을 하다가 MAIN과 혹은 MAIN에서 exp와 병합하는 것을 해보자
일단 위의 상황을 이어서 가보겠다. 위의 상황에서 실험이 성공적으로 결과가 나왔다고 가정하자.
그리고 이제 합병하고자 하는 버전 위에 마우스를 놓고, 오른쪽 클릭을 누르면 아래처럼 Merge를 누르면 현재 branch를 기준으로 병합이
된다.
병합을 하면 MAIN을 기준으로 exp가 병합된 것을 볼 수 있다.
그리고 이렇게 합병된 것을 취소하려면 합병된 것의 바로 밑 버전에서 Reset을 눌러주면 기존의 합병이 취소된다.
그리고 합병된 버전의 부모 ID와 합병취소를 하는 버전의 ID를 보면 동일한 것을 볼 수 있다.
합병은 이렇게 간단하다. 그럼 이제 팀원들과의 협업을 할 때 push/pull을 할 텐데 이때 발생하는 충돌을 해결하는 방법을 설명하겠다.
아래와 같이 파일의 내용이 존재한다고 가정하자. 내용은 1-,2,-,3,-,4이고, MAIN에 branch가 생성되어 있다.
그리고 여기서 e2로 내용을 수정(기존 2에서 e2로 수정)하고 MAIN에 커밋한다.
그리고 exp의 v1내용을 (3에서 e3로 수정)하고 e3로 커밋한다.
그리고 여기서 e3의 내용을 수정(4에서 e4로 수정)하고 e4로 커밋한다.
그리고 e4의 내용을 수정(e4에서 ee4로 수정)하고 커밋해 준다. 이렇게 여러 파일을 만드는 것은 같은 행에 여러 파일이 똑같이 변경되었을 때 충돌이 발생할 수 있게 하기 위함이다.
그리고 여기서 합병을 하면 아래와 같이 충돌을 한다. 충돌을 하는 이유는 기본 원본 파일과 변경된 다른 파일을 동시에 비교하였는데
이때 변경된 파일에서 같은 위치의 데이터가 변경되었기에 어떤 위치의 어떤 데이터가 어떻게 변경되었는지 알 수 없기에 프로그램에서
스스로 판단하여 한쪽으로 치우쳐 병합할 수 없기 때문이다. 아래를 보면 어디서 충돌이 발생했는지 위치를 보여주고 있다.
충돌이 발생하면 아래와 같이 Merge Editor 버튼이 발생한다. 이를 누르면 병합 편집기를 실행할 수 있다.
그럼 위와 같이 충돌이 발생한 파일을 보여주고 아래에서는 충돌이 발생한 부분에 대해서 직접 수정이 가능하다.
eee4로 수정하고 저장한 다음, 커밋을 하면 아래와 같이 새로운 버전이 커밋된 것을 볼 수 있다.
그럼 이제 정말 git에 저장하고 공유하는 방법을 알아보자. 일단 git에 가입해야 한다. git에 가입하면 아래와 같은 초기 화면이 나오고
여기서 Create a new repository를 생성해 준다. 이름은 아무렇게나 만들었다.
그리고 새로운 저장소를 만들면 아래와 같이 주소가 생기는데 이를 복사해 준다.
그리고 다시 VScode로 가서 소스제어 옆의... 을 누르면 Push가 보인다. 이를 누르면 주소를 넣으라는 칸이 나오고 여기에 아까 저장한
저장소 주소를 넣어주자
그럼 Git Graph에 아래와 같이 작은 칸이 생기고 이는 git 저장소의 이름이 나온다. 만약 이렇게 이름이 나온다면 push에 성공한 것이다.
이번에는 글 내용이 매우 길었다. 하지만 만약 git을 이 정도로만 다루게 되어도 git으로 협업하는 데에는 큰 문제가 없다고 생각한다.