GitHub Pull Request

 

조금 쉽게 생각하자면 Pull Request는 거대한 프로젝트가 있다 가정할때 사람들이 일부분씩을 바꾸고 합칠때 효율적이고 올바르게 합칠 수 있는 좋은 도구인 것 같다.

 

(https://www.secmem.org/blog/2019/04/10/git_pr/)

 

 

내가 어떠한 프로젝트에 Pull Request를 하기위해서는

1. Fork
2. clone
3. branch 만들기
4. 코드 작성
5. add,commit,push
6. Pull Request 생성
7. Merge Pull Reqest
8. Merge이후 branch삭제

와 같은 과정을 통해 진행된다.

 

 

• Fork : 해당 프로젝트의 저장소를 자신의 git으로 가져온다. 해당 기능을 사용하면 다른 계정의 git을 내 저장소로 가져올 수 있다.
• clone : 결국 코드 작업을 하기 위해서는 로컬 환경에서 작업하므로, clone을 통해 저장소의 내용을 컴퓨터로 가져온다.
• branch 생성 : branch를 만들면 clone해온 코드와 독립적으로 코드를 개발진행할 수 있다.

 

위 사진과 같이 Master에서 시작되는 코드들이 있다고 생각해보자. 내가 파란색 일을 마친 후에 본래의 Master에 합칠때 누군가는 주황색 작업을 하고있을 수 있다. 이런과정에서 서로 혼동이 생길수도 있고 오류가 생길수도 있어 이를 효율적으로 관리하기 위해서 브런치가 필요하다.

 

• 작업이 끝난후에는 자신의 git에 올리는것과 똑같이 add, commit, push 작업을 통해서 자신의 git repo에 작업물을 반영한다.
• Fork한 작업이기에 push가 끝난 후 자신의 git을 보면 Compare & pull request 버튼을 선택하여 Pull request를 만들 수 있다. 여기엔 본인의 코드 수정 내역이나 설명등을 써서 보낼 수 있다. 마치 직원부하가 본인의 결재물을 상사한테 결재받는것과 비슷하다.
• 상사한테 결재받는것과 유사하다고 했는데, 해당 저장소의 관리자가 이 코드변경내역을 반영할지 Merge여부를 결정한다. 여기서 Merge란 갈라나간 부분을 다시 합치는 것으로 위의 파란색일을 마친 branch가 합쳐지는 부분이다.
• Merge가 성공적으로 진행되어 코드들이 완전히 동기화가 되면 로컬의 branch는 이제 삭제해도 될 것이다.

해당 과정들을 잘 활용하면 혼자 개발하는 것이 아닌 여럿이서 개발할때 효율적으로 개발할 수 있을거란 생각이 들었다.

 

 

 

 

그렇다면 commit과 push 사이에서는 어떤 일이 발생할까?

 

(https://velog.io/@terman/남-주기-전에-나부터-알자-Git-Github)

 

 

• 내 git저장소의 주소를 가져온 후 로컬 환경에 clone하면 저장소에 저장된것과 완벽히 똑같은 작업물들을 내 컴퓨터에 저장할 수 있다.
• 이후 가져온 코드들을 로컬 환경에서 작업을 한다. 코딩 작업이 끝난 후에는 가져왔을때와는 다른 코드 구성들을 가질 것이다.
• 다음 작업은 git에 내 작업물을 올려야 할 것이다. 그렇다면 우선 git의 영역을 어느 정도 아는것이 필요하다

(https://iseunghan.tistory.com/322)

내가 현재 작업하고 있는 컴퓨터 환경이 Working Directory, 커밋을 하기위해 모아둔 Area가 Staging Area이다. Staging Area가 있는 이유는 이를 활용하면 내가 수정한 모든부분을 저장소로 올리는 것이 아닌, 내가 보내고 싶은 부분만 보내는것도 가능하기 때문이다.

 

 

즉,

git add .

를 통해서 내가 수정한 부분 모두를 올리는것도 가능하지만, 파일 명을 특정해서 올리는것 또한 가능하다. 이를 commit하면 commit들이 모여져 있는 Repository로 올라가게 된다.

 

해당 과정 이후에 commit들을 push해주면 git 의 저장소에 내가 올린 commit들이 저장되게 되는 것이다!

 

 

 

 

 

 

 

 

그럼 이번에는 add와 commit을 할 경우 git 내부에서의 동작을 알아보자.

 

• 1번 질문에서 git의 영역에 대해서 간단히 설명을 했었다. 해당 부분의 설명을 활용하면 add와 commit의 차이점을 알 수 있다.
• add는 ‘수정된 Working Directory’를 Staging Area로 보내주는 역할을 한다.
• commit은 Staging Area에 있는 부분을 저장소로 옮기는 역할이다.

add와 commit에 조금더 알아보기전에 Git에 대해서 조금더 알아볼 필요가 있을 것 같다. 우선 Git은 로컬 버전 관리 시스템이다. GitHub는 이 Git을 클라우딩 시스템으로 관리할 수 있는 곳이다. 즉, 우리가 commit을 하고 저장소를 만드는것은 로컬 환경 아래에 있다. 이 로컬환경에서 만들어진 저장소를 클라우딩 환경에서 사용하고 싶을때 push를 사용해서 GitHub에 올리는 것이다.

그렇다면 commit으로 git을 만들고 이를 클라우딩으로 보내기 위해서 push를 사용하는것은 확인하였다. 그렇다면 add는 왜 필요한 것일까? add또한 내가 원하는것만 골라낼 수 있다면, 굳이 둘이 분리되어야 하는 궁금즘이 나에게도 생겼다. 공부를 해보니 꽤나 명료한 설명이 있었다.

 

 

 

다시 설명하지만, git은 버전관리 프로그램이다.

 

 

 

 

버전관리라 함은 하나의 commit은 하나의 의미를 가져야 한다는 의미이다. 내가 어떠한 프로젝트를 만들때 1가지 기능이 완성되지도 않았는데 commit을 해버린다거나, 3가지 기능이나 구현하고 commit을 해버린다면, 다른사람이 보거나 내가 보았을때 통일성이 없을 것이다.

 

add를 활용한다면 3가지 기능을 해버렸을때 3개로 나누어서 commit하는것도, 1가지 기능이 안되어도 쌓아가다가 그 기능이 완성되었을때 commit하는것이 가능하다. 즉, git의 본연의 임무인 버전관리를 용이하게 하기 위해서 지원되는 아주 좋은 기능인 것이다.