Git 개념 및 사용 2

 

이전 포스팅에서 Git에 대한 개요와 소규모 프로젝트에서 Git을 활용하는 방법에 대해 간단히 설명했다.

 

dbstndi6316.tistory.com/200

Git 개념 및 사용법 1

이번 포스팅에서는 조금 더 심화된 개념과 대규모 프로젝트에서의 활용방안에 대해 이야기 해보고자 한다.

 

 

---

 

 

1. Git 사용자 구분

 

이전의 소규모 프로젝트에서는 사용자 구분이 딱히 필요하지 않았다.

 

왜냐하면 내가 곧 관리자이자 collaborator 였기 때문이다.

 

개인프로젝트가 아닌 경우에도 내가 collaborator 개발자이기 때문에 clone 받아서 push pull 하면 그만일 수 있었다.

 

Git 의 사용자는 크게

 

"관리자 - collaborator - contributor - 일반사용자" 로 나눌 수 있다.

 

관리자 : 

 

프로젝트를 생성한 사람으로 push pull 삭제 등의 모든 권한을 가진다.

 

Collaborator : 

 

관리자가 초대한 사람으로 프로젝트를 공동 개발하는 핵심 개발자이다. collaborator도 push 의 권한이있다.

 

Contributor : 

 

위의 사용자들과는 다르게 직접 push 권한이 없다. 내가 코드를 바꿨어도 원본 repository에 코드를 집어넣을 수 없다는 뜻이다.

 

그래도 contributor는 기여자로써 해당 repository에 기여할 수 있다. PR (pull request) 로 말이다.

 

자신이 소스코드를 고치고 상위 단의 권한을 가진 사람에게 "제가 이부분 이상한거같아서 고쳐왔는데 어때요? 괜찮죠? 반영해주세요!" 라고 pull request 를 보내면, 받은 사람이 보고 괜찮다 싶으면 merge 시켜준다.

 

본래의 repository 에 merge 된다면 이 사람은 일반 사용자가 아닌 프로젝트에 기여한 contributor 가 되는 것이다.

 

일반 사용자 : 

 

User 이다. 정확한 용어는 모르겠지만 fork 해서 쓰던, clone 해서 쓰던 소스코드를 사용은 하는데 기여는 하지 않는 일반 사용자이다.

 

 

---

 

 

Git을 통한 협업의 Flow

 

 

위 사진은 Vincent Driessen 이 제시한 브랜칭 모델로 이 모델에는 5개의 브랜치가 사용된다.

Master

Develop

Feature

Release

Hotfix

 

협업을 생각하면서 위 그래프를 보면 조금이라도 감이 오는게 있는분도 계실것이다.

 

개발과정을 아래에서 배우기 전에 여기서는 감만 잡고 가자. 용어는 몰라도 된다. 느낌만.

 

 

---

 

 

우선 앞 포스팅에서 혹은 알고있는 명령어 중에 아래와 같은 명령어가 있을 것이다.

 

git push origin master

 

 

여기서 origin 은 내가 Remote Repository (깃헙에 올라가있는 레퍼지토리) 를 clone (내 local로 복제) 해 왔을 때 해당 Remote Repository 를 지칭하는 이름이 origin 이 되는 것이다. (실제 이름은 ABC 라고 해도 git 저장소를 지칭하는 이름이 origin)

 

 

그리고 여기서 말하는 master는 위 사진에서의 master와 같다.

 

 

---

 

 

평소에 git clone 후 add, commit, push, pull 만 사용해 왔다면 기본적인 작업공간 (branch) 만 쓰고 있던 것이고 이것의 이름은 master 이다. (master branch)

 

위 사진에서 master는 프로젝트가 진행됨에 따라 일자로 뻗어나가는데, 다른 이름을 가진 곁가지 (anothor branches) 들이 계속 생기는 것을 알 수 있다.

 

만약 혼자 개발하면서 가지를 뻗지 않는다면 위 사진과는 다르게 master만 일자로 계속 뻗어나갈 것이다.

 

 

---

 

 

협업을 할 때 가지치기를 하는데에 더 비슷한 사진은 아래 사진이 될 것 이다.

 

Remote repository 자체를 자신의 이름으로 설정해주었고 origin repository에서 fork, clone 후 가지치기를 통해 같이 개발을 진행해 나갈 것이다.

 

그리고 자신이 맡은 부분의 개발이 완성된다면 PR을 통해 프로젝트에 기여할 수 있을 것이다.

 

 

---

 

 

아직 용어가 너무 와닿지 않아서 감이 안오시는 분이 계실 것이다. 용어 설명을 보고 다시 돌아와서 읽어보도록 하자.

 

 

 

---

 

용어 정리

 

init : 현재 공간을 git 저장소로 설정해준다.

 

git 저장소로 설정해준다는 뜻은 현재 공간에서 작업하는 내용들은 .git 숨김폴더에 이력이 기록된다는 뜻이다.

 

프로젝트 관리를 시작할 수 있다.

 

git init

 

 

 

 

remote : 리모트 저장소이다.

 

흔히 git clone 으로 프로젝트를 불러오게되면 remote 저장소는 자동으로 origin 으로 네이밍된다.

 

만약 다른 사람과는 다른 리모트 저장소를 만들고 싶다면 (내가 origin 이 아닌경우)

 

git remote add myname <해당 깃헙 주소>

 

위 명령어를 통해 내 리모트 저장소를 생성하며 네이밍 할 수 있다.

 

 

 

 

fork : 다른 사람의 repo (repository) 를 내 Github repo 로 그대로 복제하는 것

 

clone 과 다른점을 아래 그림으로 이해할 수 있다.

 

내 Github에 있는 repo를 Local로 가져오고 싶다면 clone

 

다른 사람의 Github에 있는 repo를 내 Github로 가져오고 싶다면 fork

( 그걸 다시 내 Local로 가져오고 싶다면 clone)

 

그렇다면 다른사람의 Github에 있는 repo를 clone 한다면?

내 Local로 들어올 것이다. 하지만 내가 그 repo의 collaborator가 아니라면 push가 불가능 할 것이므로 기여를 할 수 없다. (그냥 실행시키거나 보는것은 가능)

 

 

 

 

branch : 버전관리의 핵심

 

독립적으로 어떤 작업을 진행하기 위한 개념.

 

가지치기라고 생각하면 편하다. 내가 master 라는 가지에서 "사진을 캡쳐하는 기능"을 추가하고 싶다.

 

그런데 master에서 직접 바꾸면 그동안 동작하지 않을 수도 있고, 원본을 건드리는 느낌이라고 보면된다.

 

그래서 "기능개발" 이라는 가지를 쳐서 이 branch 에서 기능을 개발한다.

 

개발이 완료되면 merge를 통해 이 기능을 master에서도 돌아갈 수 있게 업그레이드 하는 것이다.

 

브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러개의 작업을 동시에 진행할 수 있다. (협업의 핵심)

 

git branch dev

위 명령어는 master 에서 실행하였고 이는 곧 master 가지에서 dev 가지로 가지를 친 것으로 해석된다.

 

 

 

 

checkout : 해당 branch 로 이동하자

 

git checkout dev

생성한 브랜치로 환경을 switch하는 명령이다.

 

 

 

 

fetch : 원격 저장소로부터 필요한 파일을 Local로 다운

 

병합은 따로 해야된다. 그냥 오로지 다운받 받아와서 FETCH_HEAD branch를 생성한다.

 

이후 merge 하여 병합해야지 비로소 적용된다.

 

git fetch

 

원격 저장소의 커밋정보를 로컬저장소에 가져온다.

 

 

 

 

merge : fetch 해 온 파일을 병합하는 명령어이다.

 

또는 굳이 fetch 해온 것이 아닌 크게보면 branch 를 병합하는데에 의의가 있다.

 

git merge dev

 

위의 명령을 master 브랜치에서 실행했다면 dev 브랜치를 master로 병합하는 것이다.

 

 

=> git pull = fetch + merge 라고 생각하면 된다.

 

 

 

협업을 통한 개발 과정

 

용어정리가 끝났으니 이제 개발 하는 과정을 flow로 보려고 한다.

 

이와 같이 브랜치를 나누어 개발하려고 한다.

 

1. 개발할 Repo를 가서 해당 Repo를 내 Github로 fork 해온다.

 

2. 내 Github에 있는 Repo를 Local로 clone 해온다. (remote = origin / branch = master)

 

3. branch 를 나누어 개발한다.

 

Big, Little 로 branch 를 나누어서 개발하고 결국에는 master 로 merge 해줄 것이다.

 

--현재 branch : master--

--branch 들을 생성한다.--
git branch Little_Feature
git branch Big_Feature

--Littel_feature branch 에 접근--
git checkout Little_feature

--Little_feature 개발후--
git add little.c
git commit -m 'little.c를 만들었습니다'

--Big_Feature branch 에 접근--
git checkout Big_feature

--Big_feature 개발후--
git add big.c
git commit -m 'big.c를 만들었습니다.'

--master branch 로 돌아온다--
git checkout master

--두 branch 들을 master branch에 merge 한다
git merge Little_feature
git merge Big_feature

--개발에 사용한 branch가 필요없다면 삭제한다.--
git branch -d Little_feature
git branch -d Big_feature

 

이렇게 기능별로 branch 를 나누어 개발한 후에 새로운 기능을 포함해 master 를 완성시켰다.

 

 

 

이것을 원래의 Repo에 기여하고 싶다면 어떻게 해야될까?

 

우선 내 remote channel 에 push 한다.

--origin remote 에 master branch 를 push한다 --
--big branch 도 push 할수있었지만 local에서 작업하는 branch는 굳이 올리지않는다--

git push origin master

 

 

Pull Request 

 

Push 완료 후에 본인의 github의 해당 Repo 에 들어가면 Compare & pull request 버튼이 초록색으로 존재한다.

 

버튼을 클릭하고 메시지를 작성하여 Pull Request 를 생성한다.

 

이제 관리자에게 메일이 전송되고 나는 merge를 기다린다. 내 코드가 반영이 되면 나는 이제 해당 Repo의 contributor가 되는 것이다!

 

 

---

 

 

 

깃에 대한 포스팅을 마쳤지만, 물론 이 포스팅에 있는 것이 깃의 모든것이 아니다.

 

협업을 하기 위한 최소한의 개념과 지식을 적어 놓은 것일 뿐이고

 

사용하면서 여러 충돌이 날 수도, 이에 여러 옵션들을 사용할 수 있을 것이다. (push -u / --no--ff 등등)

 

또한 본문에선 설명하지 않았던 git add한걸 지우는 git rm을 사용할 경우도 있을것이다.

 

결론은! 더 삽질하고 공부하자!