개발자 취업 필수 개념 2주차 개발일지(Git, GitHub, Branch)

 

개발자 취업 필수 개념 2주 차에는 협업 도구인 Git과 협업 커뮤니티인 Github를 배웠다.

 

 

목차

1. Git

2. Git 구조

3. Git 실습

4. GitHub

5. Branch

6. Pull Request

 

 

---

1. Git

---

 

규모가 큰 프로젝트, 현업에서는 여러 명의 개발자들과 협업하는 일은 기피할 수 없다.

이렇게 여러 명의 개발자들이 하나의 프로젝트를 동시에 개발할 때 어떤 식으로 협업을 할까?

 

 

차례대로 한 사람씩 돌아가면서  기능을 구현하면서 완성된 결과물은 카톡으로 공유하는 방법을 사용할까?

생각만 해도 끔찍하다..

 

이런 방식으로 협업을 하는 것은 비효율적이며 동시에 여러 명이 같은 프로젝트를 할 수 없을 것이다.

 

그래서 많은 개발자들은

 

동시에 여러 명이 프로젝트를 관여해도 문제가 없고,

무엇이 달라졌는지 확인하기 쉬우며,

과거에 올렸던 코드도 다시 확인할 수 있는,

 

마치 프로젝트를 버전별로 관리할 수 있게 만드게 해주는 버전 관리 시스템인 Git을 사용하고 있다.

 

Git이 너무나 편리하고 많은 이점이 있어 이제는 필수 개념으로 알아야 한다.

 

정리하자면 Git은

 

버전 관리 시스템 : 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의
버전을 다시 꺼내올 수 있는 시스템
Git : 버전 관리 시스템 중 하나. 소스코드를 여러 개발 PC와 저장소에 분산
해서 저장할 수 있으며, 가장 대중적인 방식이다.

 

Git을 배우면 협업이 수월해질 것이다!

 

Git을 사용하는 방법에 느 두 가지가 있다.

 

CLI : Command Line Interface 

GUI : Graphic User Interfcae 

 

 

 

 

CLI는 쉽게 말해서 cmd창하고 똑같다 보시면 된다.

필요한 기능이나 동작을 명령어로 수행한다.

 

 

GUI는 눈에 보기 편하고 여러 가지 기능들이 직접적인 인터페이스를 통해 수행된다.

 

그럼 누가 봐도 이쁘게 보이는 GUI에서 Git을 다루지 않나요?

 

당연히 그렇지 않다.

CLI와 GUI은 각각의 장단점이 있다.

 

CLI는 GUI보다는 현재의 상황을 이해하기 힘들다는 단점이 있지만

GUI보다 더 많은 기능을 지원한다.

 

GUI는 CLI보다는 기능이 제한되어 있다는 단점이 있지만

CLI보다 그래픽으로 보여지기 때문에 현재 상황을 확인하기 쉽다.

 

각각 장단점이 있어서 하나를 다루기보단 CLI, GUI를 모두 다룰 줄 알아야 한다.

 

 

 

 

 

---

2. Git 구조

---

 

 

 Git 은 크게 4가지 작업 공간으로 나뉘어 있다.

 

Working Directory : 현재 작업하고 있는 폴더 

Staging Area: 버전을 기록할 것들을 옮겨 놓는 장소 

Local Repository : 내 PC에 파일이 저장되는 개인 전용 저장소 

Remote Repository : 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소

 

 

 

 

 

---

3. Git 실습

---

 

 

 

git을 시작하려면 당연히 git홈페이지에서 설치한 후 

 

git 설치하러 가기[클릭]

 

 자신이 작업하고 싶은 폴더에 가서 오른쪽 마우스 클릭 후 Git Bash here을 선택한다.

 

 

그럼 이런 터미널 창이 뜨는데 Git을 시작하겠다는 의미로

git init 을 입력한다

 

 

그럼 이렇게 .git폴더가 뜬다. 이 .git 폴더는 이제 앞으로 이 현재 폴더는 Git 으로써 관리하겠다는 메시지와 같으며 앞으로 폴더 안에 변경 사항을 저 .git 폴더에 저장한다. 

 

 

이렇게 .git 폴더가 있는 작업공간에서 a.txt 를 만들면

 

 

이렇게 Working Directory 의 a.txt 존재하게 되는 것이다.

 그런데 .git 폴더와 함께 있다고 Git 이 관리하진 않는다.

 

Git 이 관리해주려면 관리받고 싶은 파일들을 Staging Area 공간으로 보내줘야 한다.

Staging Area 공간으로 보내려면 git add a.txt (a.txt를 스테이징 해줘~) 또는 git add . (현재 작업 폴더에 있는 모든 변경사항들을 스테이징 해줘~) 명령어를 써야 한다.

어차피 폴더 안에 a.txt밖에 없으니 git add . 무관하다.

 

보통 git add . 명령어는 실행 후 아무런 반응이 없다 

 스테이징에 잘 올라갔는지(Staging Area 공간으로 잘 보내졌는지) 확인하고 싶다면

현재 폴더의 상태를 보여주는  git status 명령어를 사용해야 한다.

 

Staging Area 공간으로 들어가지 않았다면 빨간색 들어갔다면 초록색으로 파일명이 표시된다.

 

 

 

 그럼 지금 이 상태가 된 것이다.

Staging Area공간으로 들어간 a.txt 는 이제 Git의 관리대상이 된 것이다.

 

 이렇게 텍스트 내용이 달라지면

 

 

이렇게 git status 명령어를 통해 수정되었다는 이력이 생긴다.

 

 

 

하지만 우리의 목표는 변경 내용을 보는 것이 아닌 파일들을 버전별로 관리하겠다는 것이다.

 마치 안드로이드 버전이나 게임 패치 버전처럼 말이다

 

 

어떤 하나의 기능이 완성되었고 하나의 버전으로 남기고 싶다면 git commit 을 사용하자

 

 

 

git commit -m '커밋 메세지'

git commit의 -m은 message의 약자로 버전의 간단한 설명을 남길 수 있다.

커밋 메시지는 유의미해야 한다. 왜냐하면 나중에 우리는 수많은 커밋 중에 메시지를 보고 그 버전을 찾아갈 수 있기 때문이다. 

 

 

 

 그러면 이렇게 커밋 메시지와 함께 버전으로 저장이 되며,

 

a.txt를 Staging Area에서 Local Repository로 옮긴 것이다. 

또 commit을 하게 되면 commit마다 고유의 해쉬 번호가 주어진다.

 

 

commit을 할 때 7자리 숫자로 알려준다.

 

 

하지만 정확히는 30자리나 되는 숫자이며 이 숫자는 나중에 원하는 커밋으로 돌아가고 싶을 때 사용되는 숫자이다.

 

 

 

 

---

4. GitHub

---

 

다른 사람과의 협업을 할 때 Git만으로는 한계가 있다.

왜냐하면 Git은 어디까지나 로컬 저장소 즉 내 컴퓨터 내에서만 작업이 이루어지는 것이다.

내가 작업한 Git을 다른 컴퓨터에게 공유를 하려면 GitHub를 사용해야 한다.

 

 자신이 작업한 Git을 GitHub에 올리려면 의 repsitory(일명 레포지토리 또는 레포라는 원격 작업공간을 만들어야 한다. 

 

 

 

 

 

 

레포지토리를 만들었다면 Git에게 레포지토리의 링크를 알려줘야 한다.

명령어는 git remote add 사용할원격레포지토리이름 레포지토리주소 이다

git remote add origin https://~~.git 명령어는

https://~~.git 주소의 원격저장소를 origin 이란 이름을 사용해서 Git에 추가하겠다 라는 뜻이다.

 

 

git remote add origin을 해주면 아무런 반응이 없는데 잘 되었는지 확인하려면 git remote를 입력하여 현재 연결된 레포지토리의 이름을 확인할 수 도 있고 git remote -v 를 통해 현재 연결된 레포지토리의 주소를 확인할 수도 있다.

 

링크를 연결했으면 이제 원격 레포지토리의 넣을 차례이다.

 

 

git push (원격저장소이름) (저장소에넣을브랜치이름)이다

 

git push origin master는

현재 master 브랜치를 origin이란 원격저장소에 커밋을 넣겠다는 뜻이다.

master는 Git을 처음 만들 때 자동으로 부여되는 브랜치 이름이고

origin은 관례적으로 사용되는 원격저장소 이름이다.

 

명령어가 성공했으면 원격저장소에 올라가진 것을 볼 수 있다. 

 

 

Push 명령어를 통해 LocalRepository에 있는 것이 RemoteRepository로 복사가 된 것이다.

push 이후에도  LocalRepository에 있는 파일들은 그대로 남아있다.

 

 

 

---

5. Branch

---

 

Git을 통해 예전 코드들로 왔다 갔다 할 수 있는 기능을 타임머신에 비유할 수 있다면

Branch는 평행우주라고 비유될 수 있다.

 

Branch의 뜻은 나뭇가지이다.

Git에서 사용되는 의미는 '구분된 작업 공간'을 의미하며

기존의 이력들은 유지된 채로 새로운 기능을 펼치고 싶을 때 사용되는 기능이다.

 

 

 

Branch의 사용목적을 예를 들어보자면 위와 같이 모 사이트의 메인 페이지 개발이 끝난 후

 이제 로그인 기능과 자유게시판 기능을 넣어야 하는데 작업하는 개발자가 2명이라면

한 명은 로그인, 한 명은 자유게시판 기능을 구현해야 하는데 하나의 작업공간에서 동시에 개발한다면

나중에 수많은 충돌과 이력 관리가 많이 꼬여질 것이다.

 

 

그래서 현재 브랜치의 이력을 갖고 있는 상태로 두 개의 작업공간 분리시켜

각자 개발하도록 만드는 것이 Branch이다. 

 

 

Branch을 만드는 명령어는 git branch 브랜치이름 이며

이렇게 생성된 브랜치는 현재 있는 브랜치의 이력들을 복사가 된다.

 

 

Branch 생성과 함께 checkout하고 싶다면 git checkout -b 브랜치이름 명령어를 써도 된다.

 

 

먼저 board Branch의 게시판 구현을 구현하고 add와 commit을 했다.

 그다음 login Branch로 checkout하면

login Branch에는 board Branch의 이력들이 있지 않다.

두 개의 Branch는 독립적이다 라는 뜻이다.

 

  GUI로 보면 이렇게 master Branch에서 두 가지의 Branch가 나온다는 걸 알 수 있다.

이 브랜치를 다시 master브랜치로 붙이려면 merge와 Pull Request가 있는데 

이 둘의 차이는 merge는 말 그대로 바로 병합해주는 것이고 Pull Request는 다른 개발자들에게 변경 이력들의 대한 의견을 물은 후 merge를 해주는 것이다.

 

혼자 개발을 하는 거라면 병합할 때 merge를 하고

여러 명이서 협업을 하는 거라면 병합할 때 Pull Request를 통해 merge를 해야 한다.

 

 

 

 

Pull Request 실습을 위해 login, board를 원격 저장소로 push를 했다.

 

브랜치로 나눈 후에 push를 해주면 GitHub가 알아서 compare & pull request 할 건지를 물어봐준다.

 

너 branch 새로 만들어서 push 해줬네?

그럼 기존 branch랑 뭐가 달라졌는지 확인해야겠네

 

이렇게 GitHub가 미리 물어보는 것이다.

 

저 compare & pull request를 통해 Pull Request를 진행해도 된다.

하지만 정석적으로 배워보자

 

 

상단에서 Pull Request메뉴를 고른 후 New pull request 버튼을 누르다

 

 

그럼 위의 base branch와 compare branch를 확인하자

base branch가 기준이다. base branch에서 compare branch를 서로 비교해 달라졌는지를 화면에 띄워준다.

지금은 base branch와 compare branch가 모두 master branch이니 달라져있는 게 없다고 한다.  

 

 

 

compare branch를 달리해주면 상단에 달라진 점과 merge가 가능한지의 여부를 알려준다.

merge가 가능할 때는 Fast-forward가 가능할 때이다.

한마디로 base branch의  compare branch가 덧붙여지는 게 가능한지이다.

서로의 브랜치가 충돌 현상이 일어나 병합이 불가능하면 병합이 해결한 후 merge를 해줘야 한다.

 

merge가 가능하니 create pull request를 눌러주자

 

 

 자신이 만든 기능이 무엇인지 간략 요약한 제목을 설정하고

내용에는 상세히 적어주고 create pull request를 눌러주자

 

 

 

그럼 이렇게 다른 사람들에게 자신이 변경한 이력을 공손하게 물어보듯이 메시지가 남겨지게 된다.

그러면 다른 개발자들이 댓글창을 통해 의견을 남기거나 

 

 

코드 확인 메뉴에 들어가서 직접 코드 밑에 의견을 남길 수 있다. 

그리고 프로젝트 관리자나 혹은 기능을 만든 자신이 Merge pull request를 하면 master branch에 붙여지는 것이다.

 

이번엔 board branch를 Pull Request해보자

 

 

 

안타깝게도 board branch가 병합이 안된다고 한다.

Fast-forward가 안되니까 말이다.

그럼 로컬에서 병합을 해결하고 Pull Request 하는 방법도 있지만

Create Pull Request 버튼을 누른 후 

 

 

 Resolve conflicts에서 원격에서 고치는 방법도 있다.

 

 

들어가면 우리가 로컬에서 Merge 할 때 많이 봤던 것들이 보인다

 

 

맞게 고쳐지면  오른쪽 상단에 Commit merge를 누르고

 

 

 

Merge pull request를 누르면 login branch와 master branch가 병합이 되는 것이다.

 

 

 

그림으로 정리하자면은 이렇다.