728x90
반응형

Branching

 git을 잘 사용하기 위해서는 branching을 잘 관리해야 한다. branching을 잘 사용하면 선형적인 개발이 아닌 비선형적인 개발을 할 수 있으며 버전 관리를 하는 것이 더 용이해진다. 따라서 복잡한 branch를 잘 관리할 수 있도록 해야 한다.

 branching 개념을 소개하기 전에 HEAD와 master가 무엇인지 알아야 한다. master는 기본적으로 생성되어 있는 branch다. 그리고 HEAD는 pointer로 가장 마지막으로 commit 한 곳이 어딘지를 가리키는 pointer다.(추후 이 HEAD를 임의로 옮길 수 있긴 하다.)

git의 master와 HEAD

branch의 생성, 이동, merge

 

git의 흐름도와 실제 폴더

 위와 같이 default인 branch가 있다고 하자. c0과 c1은 commit이며 숫자가 작을수록 더 오래된 commit이다. 따라서 c1이 더 최신 commit이므로  defult와 HEAD가 c1을 가리키고 있다.

 branch를 만드는 명령어는 branch이다. git branch <만들 branch명> 명령어를 입력해서 branch를 만들 수 있다. 따라서 git branch experiment를 입력해서 새 branch를 만들도록 하자.

 

branch를 만들어도 master

 

 branch를 만들어도 HEAD를 옮긴 것이 아니므로 experiment로 branch가 이동한 상태는 아니다. 아직 HEAD가 master(default)에 있는 것이므로 지금 commit을 한다면 master에 c2가 쌓이게 될 것이다. 따라서 새로 만든 experiment branch로 이동하기 위해서 checkout이라는 명령어를 사용한다. git checkout <이동할 branch명> 명령어를 입력해서 branch를 이동할 수 있다. 따라서 git checkout experiment를 입력해서 이동하도록 하자.

 

experiment로의 이동

 

 branch를 이동했다면 다음과 같이 푸른색 master가 experiment로 바뀐 것을 알 수 있다. 따라서 이 상태에서 commit을 두 번 한다면 experiment 가지에서 증가하게 될 것이다.

 

 

experiment에서의 commit

 

 이제 다시 master(default)로 돌아간다면 어떻게 바뀌게 될까? default에서 commit3.txt와 commit4.txt를 만든 기록이 없으므로 test.txt와 commit2.txt만 가지고 있을 것이다. 

 

이전 사진 재탕한 것이 아닙니다.

 

 merge란 두 개의 branch를 합치는 것을 의미한다. 실생활 예시로 설명한다면 한 프로그램이 A라는 사람이 로그인 기능을 구현하고 B라는 사람이 회원가입을 하는 기능을 구현했다 하자, 각자 branch를 생성해서 기능을 구현했고, 완성했다면 이를 합쳐야 할 것이다. 이때 사용하는 것이 merge라는 기능이다. merge를 설명하기 위해서 commit을 몇 번 더했다. 

 

 

좌상단_현재 상태, 우상단_experiment branch, 아래_default branch

 

 다음과 같은 상태라고 할 때 experiment branch를 이제 default를 합치기 위해서 default(master) branch로 이동을 해야 한다. 그 다음에는 git merge experiment를 하면 experiment가 default에 합쳐지게 된다. 

 

master에 모든 파일이 합쳐졌다.

 

 하지만 merge를 수행했다고 experiment가 사라진 것은 아니다 experiment에 존재하는 변경사항들이 master에 합쳐진 것이지 branch 자체가 사라진 것은 아니다. 따라서 experiment로 변경 후 다시 commit을 하면 다음과 같이 만들어지게 될 것이다.

 

 

 

 

 이렇게 branch를 생성,이동하고 이를 merge를 함으로써 비선형적(병렬적)으로 프로젝트를 진행할 수 있게 된다. 따라서 branch를 잘 사용해서 프로젝트 진행에 효율성을 높이도록 해보자.

728x90
반응형

'Language > Git' 카테고리의 다른 글

[Git 빨]4. Remote Repository  (1) 2019.08.02
[Git 빨] 2. Git의 사용 이유와 기본적인 흐름  (0) 2019.07.19
[Git 빨]1. Git 설치하기  (0) 2019.07.12
728x90
반응형

Git은 왜 사용할까?

 프로젝트를 진행하다 보면 코드를 자주 수정하게 되고 그 코드를 저장하게 된다. 이럴 때마다 '하나의 버전이 생겼다.'라고 한다. (게임의 패치 버전과 같다고 생각하면 된다.) 버전을 나누면서 코드를 관리한다면 얻을 수 있는 장점이 많다. 만약 프로젝트를 진행하다가 실수로 파일을 지우게 되었다거나 컴퓨터가 고장이 난다면 다시 이 파일을 복구할 수 없는 방법이 없다. 또한 내가 계속해서 진행하던 프로젝트 방향이 옳지 못한 방향일 수도 있을 것이다. 버전을 나눠서 관리하지 않았다면 다시 이전으로 돌아갈 수 (undo) 없었을 것이다. 하지만 버전을 나눠서 관리해 저장했다면 필요한 버전으로 돌아가서 다시 진행하면 될 일이다. 따라서 버전을 나눠서 관리를 해야 한다. 

 그러면 매번 다른 이름으로 저장하기를 해서 버젼명을 적어주면 되지 않을까 생각할 수 있다. 하지만 대부분의 경우에는 프로젝트는 팀으로 진행하는 경우가 많다. 아무리 자주 버전을 자주 공유한다고 해도 같은 버전의 파일을 수정하고 있을 수도 있고, 서로 진행한 방향이 맞지 않아서 충돌이 발생할 수 있을 것이다. 그렇다고 해서 서로 시간을 나눠가며 프로젝트를 진행하기에는 매우 비효율적이다. 따라서 위의 문제를 모두 해결하기 위해 생겨난 것이 VCS(Version Control System)이다.

 VCS는 각 사용자들은 repositories라는 저장소를 가지고 있다. (CVS) 그리고 서로 공유하는 repository(git)를 만들어 자re신의 repo에 있는 파일들을 git의 repo에 올리고 내려받으면서 버전을 관리하겠다는 시스템이다.

 메일로 코드를 공유하는 것과 차이를 두기 위해서 Branching이라는 개념이 존재한다. 같은 repository안에 서로 다른 가지(branch)를 만들어서 서로 코드를 관리하고 나중에 이를 서로 merge를 해서 합칠 수 있도록 했다.

 

Git의 기본 개념

 Git을 본격적으로 사용하기에 앞서서 몇가지 개념을 알고 있어야 한다. git에는 크게 세 가지의 공간이 있다. 

local repository입니다.

1. working directory : 사용자가 실제로 작업을 하는 공간이다. 이 공간에서 파일을 수정, 추가, 삭제를 할 수 있다.

2. staging area : working directory에서 바뀐 상태(수정, 추가, 삭제)를 이 공간으로 올린다. (add 한다.)

3. git directory : staging area에 올린 상태들을 repository에 올림으로써 하나의 버전을 등록하게 된다. (commit 한다.)

 

git은 각 버젼에 대해 checksum을 만들어 놓았기 때문에 이전의 버전으로 돌아가는 것이 쉽다.

 

Git의 기본적인 흐름

Git을 사용하는 기본적인 흐름은 다음과 같다. 

 

1. Init a repo

우선 repository를 만들어야 한다. 따라서 내가 만들고 싶은 파일에서 우클릭을 해서 Git Bash를 사용해서 git command 창에 들어오고 이 창에 git init을 쳐서 repository를 만들도록 한다.

위와 같이 .git 파일이 만들어졌다면 성공

위 사진과 같이 .git 폴더가 만들어졌다면 성공적으로 repository를 만들게 되었다.(숨김 파일을 보이기로 설정해야 한다.)

 

2. Edit files

 .git이 있는 폴더 내에서 새로운 파일을 하나 만들어 보도록 하자. 즉 working directory에 새로운 파일을 만든다는 것이다.

아무 파일이나 하나 만들거나 가져와보자.

 

3. Stage the changes and Review your changes

 지금은 working directory에 있는 것이고 이를 staging area에 올려야 한다. 이를 확인하는 간단한 방법은 git status 명령어를 사용하는 것이다. git status를 사용하면 아래 왼쪽 사진과 같이 Untracked files 라며 staging area에 올려야 한다고 빨간 글씨로 알려준다. 

 따라서 이 파일을 staging area에 올리기 위해서는 git add <filename> 명령어를 사용해야 한다. 이 예시에서는 git add test.txt 와 같이 입력을 하였고, 이 명령어를 수행하고 나서 git status를 다시 쳐보니 초록색 글씨로 staging area에 올라와 있음을 알려준다. (오른쪽 사진)

[좌] add 하기 전, [우] add 한 후

 

4. Commit the changes

 이제 이 staging area에 있는 것을 repository에 올려야 하는데 이는 git commit 명령어를 사용한다. git commit 명령어를 사용하게 되면 commit message를 입력하라고 초기 설치했던 편집기로 이동하게 될 것이다.

 commit message는 repository에 등록을 할 때 어떠한 점이 바뀌었는지 간단히 써준다고 생각하면 된다.

따라서 우측 사진처럼 message를 입력하고 저장버튼을 누르고 닫는다면 commit이 완료될 것이다.

 

[좌] git commit 명령어 [우] commit message 입력하기

 

 만약 이렇게 편집기를 통해서 message를 입력하는 것이 귀찮다면 git commit -m "<message 내용>"을 통해서 위와 같은 작업을 수행할 수 있다. 이후 git status를 다시 입력하면 깔끔하게 staging area가 비워진 모습을 얻을 수 있을 것이다.

 

 지금까지 Git의 기본적인 흐름이었으며 이 큰 틀은 거의 바뀌지 않는다. 하지만 Git을 잘 사용하기 위해서는 branch를 잘 다뤄야 하며 다음 편에서는 branch와 관련된 명령어를 소개하겠습니다.

 

728x90
반응형

'Language > Git' 카테고리의 다른 글

[Git 빨]4. Remote Repository  (1) 2019.08.02
[Git 빨]3. Git Branching  (0) 2019.07.26
[Git 빨]1. Git 설치하기  (0) 2019.07.12

+ Recent posts