[개발지식] GIt / GIthub 공부하기 : Repositories/ 커밋/ 푸시/머지/브랜치

[국중독] git이란 무엇일까 ?

저번에 작성한 내용에 이어서 더욱 자세히  깃 / 깃허브에 대해서 공부를 하려고 한다. 

나는 무엇을 하기전에 이걸 왜? 해? 라는 궁금증이 먼저 들고,  왜 ? 하는지에 대해서 궁금증을 풀지 못하면 집중이 안된다. 

 

그렇다면 깃허브는 왜 쓸까 ? 

여러명의 개발자가 함께 개발을 할 경우가 많은데 이슈가 되는 부분은 작업하는 부분을 어떻게 통합을 할 것이냐 ? 이다. 

만일 압축파일로 파일을 주고 받는다고 했을때, 파일을 받아 프로젝트에 적용하는 사람이 까먹고 프로젝트에 적용하지 않았을 경우 파일을 보내는 사람은 몇개의 파일을 누락했을 경우나,  수정하지 않은 파일을 보냈을때 큰 문제가 될 수 있다. 잘못 받아 이전에 작업했던 파일을 모두 날려버릴 수 도 있으며, 날려버린 부분에 대해서 복구도 쉽지 않을 것이다. 

이러한 방법을 해결하기 위해서 깃 허브를 쓰는 것이다 !

 

 

앞에서 깃 허브를 왜 쓰는지 왜 필요한지 알게 되었으지 그럼 어떻게 사용할지 공부해보자! 

 

---

 

깃 허브 사용법 [간단]

GitHub: Let’s build from here

 

1. 사용을 하려면 가입을 해야한다. 일단 먼저 가입을 하고 오자.

 

2. Repositories

처음 가입하게 되면 처음 우리가 해야할일은 Repositories를 만드는 것이다. 

 

Repositories

: 프로젝트 하나를 저장하는 저장소이며 내가 만들고 있는 프로젝트를 관리하는 곳이다. 

Repositories안에 여러개의 프로젝트를 관리할 수 있지만 일대일 대응으로 1개의 프로젝트만 만든다라고 생각하면 된다. 

 

 

Repositories 만드는 법 

Repositories 다 만들었다면 깃허브데스크탑을 다운 받자. 

사이트에서 직접 업로드가 가능하지만, 한번에 올릴 수 있는 파일 개수가 100개로 제한되어 있기 때문에 

깃 허브 데스크탑을 이용하여 업로드 하기로 하자. 

 

3.GitHub Desktop다운로드

GitHub Desktop

 

1)경로 정하기 

다운로드 후 실행하여, 아까 가입한 계정으로 로그인하고

Current repositories >  Add > Clone a repositories >  경로를 지정 > Clone 

 

2)업로드 하기 

내가 만들어 놓은 경로 파일에 나의 파일을 올려주면 된다. 

그렇게 올리면 아래와 같이 확인할 수 있다. 

Summary에 어떤 내용에 대한 파일을 업로드 할지 설명을 적어주고

commit to main을 클릭하고 push origin을 하게 되면 

아래 이미지에서 확인 가능하듯이 파일이 업로드 된 것을 확인 가능할 것이다. 

 

깃 허브 기본 동작 

1. 커밋

: 프로젝트에서 수정한 사항 중에서 깃허브에 저장할 내용을 선택하는 것이다. 

커밋하고 싶은 줄만 선택할 수 있는데 아래와 같이 파란부분은 커밋할 내용이고, 초록객은 커밋하지 않는 부분이다. 

 

 

2. 푸시 

: 커밋한 내용을 깃 저장소에 업로드하는 동작이다. 

Push origin을 클릭하여 업로드 할 수 있다.

 

3. 풀 

: 다른사람이 푸시로 올린 변경된 내용을 다운로드 해서 로컬에 반영하는 방법이다. 

 

4. 머지 

: 풀로 가져온 변경사항과 자신의 변경사항이 충돌할때 어떤 커밋을 적용할지 결정하는 동작이며

커밋 간의 충돌을 제거하고 합치는 과정을 말한다. 

 

5.브랜치 

:  프로그램 소스 버전을 관리하는 개념으로 간단히 말하면 복사본이라고 생각하면 편하다. 

원본에서 가지치를 하여 복사한 소를 가지고 별도의 버전을 새로 생성하는 것이다. 

 

1) 메인브랜치 

처음 리포지토리를 만들었을대 가장 기본적으로 만들어지는 것은 '메인브랜치'이다. 

메인브랜치는 언제든지 배포 혹은 빌드되어 출시 가능한 버전인 검증된 코드만 올린다.  

 

2)디벨롭 브랜치

실제 개발 작업이 이루어지며 이 버전의 브랜치에서 빌드 된 프로그램은 내부 테스트를 통해 검증하게 되고 

검증이 완료된 코드를 메인 브랜치에 보내 출시와 배포가 이루워지는 방식이다. 

디벨롭 브랜치에서도 모든 개발자가 한 브랜치에서 작업하는게 아니라  작업자 / 기능추가 /버그 수정에 대한 브랜치를 딸 수 있다. 

 

∴ 브랜치를 이원화하여 검증된 작업만 메인 브랜치로 적용함으로 버그를 최소화할 수 있게 한다. 

 

 

 

 

출처