TIL.11 | Git에 대하여

원용현·2023년 1월 30일
0

TIL

목록 보기
11/18

프로젝트를 진행하면서 여러 명의 사람이 하나의 프로젝트 코드를 공유하여 각자 맡은 부분의 코드를 작성한다고 할 때, 작업이 끝나면 모든 사람들이 코드를 하나로 합치고, 코드를 다시 나누어 가져야하는 과정이 필요할 것이다.

이 과정이 드물게 일어난다면 상관이 없겠지만, 매일매일 일어난다고 하면 매우 귀찮은 작업이 될 것이다. 또, 최신화되지 않은 코드로 작성을 하고 하나로 합치게되면 문제가 발생할 것이며, 또 하나의 작업공간에 대해서 여려 명이 작업을 하는 경우에 여러 코드들이 충돌을 일으켜 문제가 발생할 수 있다.

위의 것들을 제외하더라도 여러 문제점과 편의성을 개선하기위해서 작업공간을 하나로 관리할 필요성이 필요해졌고 그로 인해서 git이 등장하였다.

git 이란?

git

git은 형상 관리 도구 중의 하나이다. 버전 관리 시스템이라고도 하는데, 소스코드를 효과적으로 관리할 수 있게 도와주는 공개 소프트웨어이다.

git의 장점

프로젝트를 진행하는 개발자들 사이에서 따로 소스코드를 주고 받을 필요가 없이 같은 파일을 동시에 작업하는 병렬 개발이 가능해진다. 브랜치(branch)를 각자 만들어 개발한 후에 각각의 브랜치를 병합(merge)하는 과정을 통해서 개발을 진행한다. 분산 관리 시스템을 채택하기 때문에 각각의 로컬이 하나의 저장소가 되어 인터넷이 연결되지 않더라도 개발을 진행할 수 있다는 장점이 있다.

SVN과의 차이점

둘은 소스코드를 효과적으로 관리한다는 목적에서 같지만, git은 분산형 관리 시스템을 채택했다는 점에서 차이점을 보인다. SVN의 경우 중앙 서버에 소스코드와 히스토리들을 모두 관리하기 때문에 서버에 문제가 생기면 모든 사용자들에게 문제가 발생할 수 있지만, git의 경우에는 소스코드들 개발하는 여러 PC들에 모두 분산하여 각각 저장하여 개발을 진행하기 때문에 중앙 서버에 문제가 발생하여도 로컬 저장소에 커밋을 하는 것이 가능하며, 또 각각의 PC에 저장된 소스코드들을 통해서 쉽게 중앙서버를 백업할 수도 있다. SVN의 경우 히스토리 로그 하나를 접근하는 것도 중앙서버를 거쳐서 확인하기 때문에 속도적인 면에서 로컬에서 바로바로 확인하는 git보다 훨씬 느리다는 단점이 있어서 SVN으로 개발을 진행하던 기업들도 많이 git으로 마이그레이션 하는 추세이다.

git 사용해보기

실제 git을 연결해서 저장소를 만들고 소스코드를 관리하는 것까지 써보려고 한다. git 계정에 대해서는 github에 접속하여 계정을 생성하면 되기 때문에 그 과정에 대해서는 생략하고 vscode에서 해야할 작업에 대해서 기술하겠다.

1. git 저장소 생성

github에서 새로운 저장소를 생성한다. 생성된 저장소는 url로 나타내는 것이 가능하다.
예를 들어 https://github.com/'사용자 이름'/'저장소 이름'.git 과 같은 형식으로 생성된다.

2. remote 연결

vscode에서 가장 먼저 해야할 일은 계정을 연동하여 원격 저장소를 연결해야한다.

git remote -v

위의 명령어를 통해서 현재 연결된 저장소를 확인할 수 있다. 연결된 것이 없다면 아무것도 없이 빈칸만 출력된다.

git remote add 'alias' 'url'

git remote -v
origin https://github.com/git이름/git저장소.git (fetch)
origin https://github.com/git이름/git저장소.git (push)

git 연결을 추가한다. alias 부분에 아무런 이름을 작성하고 url 부분에 git 저장소의 url 주소를 적는다. alias 부분은 대개 자신의 것이라면 origin이라는 이름으로 많이 짓는다. add에 성공한 뒤에 다시 원격 연결이 되었는지 git remote -v 명령어를 통해서 확인해보면 자신이 연결한 결과를 확인할 수 있다.

3. add

프로젝트에서 코드를 작성하며 만들어진 파일들을 git 저장소에 옮겨야 할 때 add 명령어를 사용한다. add 명령어를 사용하면 현재 프로젝트에서의 변경사항들을 스테이징 영역에 추가한다.

git add '파일 경로'

프로젝트에서 add 명령어를 실행하는데 추가하기 원하는 파일이 있는 경로에 대해서 파일 경로를 지정해준다. 예외적으로 모든 파일에 대해서 추가하기를 원한다면 프로젝트 최상위 경로에서 git add . 을 통해서 모든 파일을 추가할 수 있다.

4. commit

프로젝트의 로컬 저장소(local repository)에 코드 변경 이력을 남기기 위해서 사용된다. 코드의 변경 사항에 대해서 로그를 함께 남겨 해당 코드의 변경 내용에 대해서 메모를 남길 수 있다.

git commit -m '커밋 메시지'

git add로 스테이징 영역에 추가된 파일들에 대해서 코드 변경 이력과 메시지를 함께 남긴다. 해당 명령어는 커밋 메시지를 적지 않으면 오류가 발생해서 commit에 실패하므로 항상 메시지를 함께 남길 수 있도록하며, 만약 커밋 메시지 없이 commit을 실행하고 싶다면 git commit --allow-empty-message -m "" 을 통해 메시지 없이 commit이 가능하다.

5. push

push 명령어는 원격 저장소(remote repository)에 코드 변경분을 업로드하기 위해서 사용하는 명령어이다. commit 명령어를 통해 로컬 저장소에 아무리 많은 코드 변경 로그를 남겨도 원격 저장소에는 변화가 없다. 따라서 반드시 git push를 통해서 로컬 저장소에 남긴 코드 변경 이력들을 원격 저장소에 전송을 해야한다.

git push <저장소명> <브랜치명>

저장소명에는 초기 remote를 설정할 때 사용했던 alias의 이름을 그대로 사용하면 된다. 브랜치명에는 코드를 작성하며 commit을 하면 현재 branch에 코드 변경 이력이 남게되는데 이 branch를 인자로 사용해서 코드 변경 이력을 원격 저장소로 전달한다.

예를 들어 feature-#13 이라는 브랜치에 남겨 놓은 코드 변경 이력을 origin 이라는 저장소에 올리기 위한 명령어는 git push origin feature-#13 이 될 것이다.

만약 자신이 연결되어 있는 원격 저장소의 이름이 생각나지 않는다면 git clone을 통해서 연결했다면 일반적으로 origin이며 git remote 명령어를 통해서 현재 원격 저장소 이름을 알 수 있다.

6. pull

pull 명령어는 원격 저장소(remote repository)에 저장되어 있는 소스코드를 로컬 저장소(local repository)로 받아올 때 사용하는 명령어이다. 기본적으로는 내 소스코드를 업로드하는 형식이기 때문에 로컬 저장소와 원격 저장소의 내용이 같아 pull을 받지 않아도 둘의 내용이 같다.

하지만 여러 사람이 함께 프로젝트를 진행할 때 각각의 개발자들이 하나의 원격 저장소에 push를 진행하게 될텐데, 버그가 없는 코드는 합쳐지고 버그가 없는 코드는 합쳐지지 않는 과정을 거치게 될 것이다. 이렇게 여러 명이 작업중인 코드가 하나로 합쳐지면 그것이 다시 개발자 개개인에게 나누어져야하는데 이때 사용하는 명령어가 pull 명령어이다.

git pull <저장소명> <브랜치명>

에를 들어 git pull origin main 을 수행하면 remote 에 연결된 origin 이라는 이름을 가진 원격 저장소에서 main branch의 소스코드를 내 로컬 저장소로 가져올 수 있다.

심화

git을 사용함에 있어서 git add, commit, push, pull만 사용할 줄 알아도 가지고 있는 소스 코드를 업로드하고 받아오는 것은 조금만 익숙해진다면 쉽게 할 수 있을 것이다.

하지만 git을 사용하는 이유에는 코드 관리를 쉽게하는 것도 있지만, 협업이라는 면에서 큰 강점을 가지고 있기 때문에 사용하는 것도 있다. 실제로 사용하게 된다면 어떻게 사용할지 예를 들어 설명해보려 한다.

fork

git에서는 fork 라는 기능을 사용해서 다른 사람의 원격 저장소를 내 원격 저장소로 복사해오는 것이 가능하다. 해당 기능을 통해서 실제 프로젝트가 위치하는 원격 저장소의 데이터를 내 원격 저장소로 복사한다.

일반적으로 실제 프로젝트가 위치하는 원격 저장소는 그 데이터의 추가, 수정, 삭제가 매우 중요하게 다루어져야 한다. 따라서 원본의 데이터를 직접 건들지 않고 내 원격 저장소의 데이터를 먼저 수정한 뒤에 수정 내용을 프로젝트가 위치하는 원격 저장소에 반영하는 식으로 작업이 이루어진다.

프로젝트가 위치하는 원격 저장소에서 fork 를 선택한 뒤에 Create a new fork를 통해서 내 소유의 새로운 원격 프로젝트를 생성한다.

branch / checkout

fork 받아온 소스코드를 git clone 하여 개발 환경을 갖추고 작업이 끝나면 해당 작업을 push 해서 원격 저장소에 저장을 한다. 해당 작업을 진행할 때 branch라고 하는 것을 인자로 저장을 실시하는데 이것을 이용하여 훨씬 좋게 git을 이용할 수 있다.

프로젝트를 진행하게 되면 어떤 작업에 대해서 하루동안 실시한 뒤에 해당 작업분을 업로드하고 오류나 에러가 없다면 해당 코드를 합치는 방식으로 작업이 진행된다. push 를 보낼 때 입력하는 것 중에 branch가 있는데 이것을 적절하게 활용하면 코드 관리를 쉽게 할 수 있다.

branch를 생성하기 전에 먼저 github에서 issue를 생성하고 issue number를 관리할 수 있어야 한다.

  1. 실제 프로젝트가 위치하는 github 원격 저장소로 이동한다.

  2. issue 태그를 찾아 들어간다.

  3. New issue 버튼을 클릭해 새로운 이슈를 생성한다. 이슈 내용은 해야할 내용에 대해서 작성한다.
    ex) 알림창 구현, 로그인 버그 수정 등

  4. 생성된 이슈에 부여되는 넘버를 확인한다. #2와 같이 #과 번호로 이루어진다.

이렇게 생성된 이슈 넘버를 가지고 branch 생성에 활용한다. branch는git checkout <브랜치명> 을 통해서 새로운 branch 생성이 가능하며,git checkout -D <브랜치명> 을 통해서 만들어진 branch를 삭제하는 것도 가능하다.

checkout 명령어를 통해서 branch를 새로 생성할 때 branch의 이름을 만들 때 일정한 규칙에 따라서 이름을 결정한다. 이 때, 프로젝트를 진행하는 각 팀이나 회사에 따라 존재하는 규칙을 따라서 branch를 생성한다. 여기서 보여주는 것은 예시이며 모두가 이렇게 하지 않는다는 것을 알아두기를 바란다.

Feature : 새로운 기능 추가 및 구현
Update : 기능에 대한 업데이트
Remove : 코드 삭제(주석 삭제 등)
Fix : 기능에 대한 오류, 버그 수정
Style : CSS 관련

위의 것을 가지고 branch 이름을 구성하는데 만약 내가 만들어낸 이슈가 로그인 기능 구현이며 그것에 대해서 할당 받은 이슈 넘버가 #16이라면 git checkout Feature-#16 과 같이 새로운 branch를 생성하여 이곳에서 작업을 실시한다.

이곳에서 작업이 종료되면 해당 코드를 업로드 하는데 commitpull 에서 branch 이름을 활용한다. commit 과정에서는 브랜치 이름과 작업한 내용을 통해서 로그를 남기도록한다. 로그인 기능 구현에 대한 commit 이므로 git add 후에 git commit -m 'Feature-#16 로그인 기능 구현' 과 같이 로그를 남기고 git pull origin Feature-#16을 통해서 업로드를 실시한다.

이후에 내 github에 접속하면 각 branch별로 소스코드를 확인하는 것이 가능해지는데 이것을 통해서 일종의 시간별 백업의 기능을 수행하는 것도 가능하다.

pull request

위에 적힌 내용들을 통해서 현재 작업 branch를 변경하고 내 작업 내용을 변경한 branch 이름으로 내 원격 저장소에 업로드하는 것까지 성공했다. 이제 해당 내용들을 전체 프로젝트에 다시 업로드해서 각각의 개발자들이 작업한 내용들을 하나로 합치는 과정이 필요하다. 이 과정을 pull request 를 보낸다고 한다.

내가 업로드 한 branch 단위로 pull request 를 보내는 것이 가능한데 방법은 github의 내 원격 저장소에 접속하여 Pull requests 태그를 선택한다. New pull request 버튼을 선택하여 보내는데 base 부분에 본 프로젝트의 develop 을 선택하고 compare 부분에 내가 올린 branch를 선택한다.

마지막으로 Create pull request 를 선택하여 전송한다. 해당 과정을 통해서 개인 원격 저장소에서의 작업은 끝이고 마지막으로 merge 과정을 통해서 소스코드들을 합쳐준다.

merge

fork 받은 원격 저장소에서 프로젝트의 원격 저장소로 pull request를 보냈다면 프로젝트의 원격 저장소에서 받은 내용들을 merge 해야한다. merge 권한이 있는 사용자만 해당 작업을 수행할 수 있으며 여러 개발자들이 따로 작업한 것을 하나로 합치는 과정이기 때문에 중요하고 위험한 작업에 속한다.

merge 를 할 때 중요한 것은 소스코드가 위치한 파일에 대해서 여러 명이 작업을 동시에 진행하면 오류가 난다. 즉, 하나의 파일에 대해서는 변경된 소스코드를 develop 에서 pull 받기 전까지는 한 사람만 수정이 가능하다는 것이다. 만약 두 명 이상의 사람이 같이 작업한 후에 merge를 시도하면 첫 번째 소스코드는 정상적으로 merge 가 진행되지만, 두 번째 소스코드의 변경 내용에는 첫 번째 소스코드의 변경 내용이 반영되어 있지 않기 때문에 오류가 발생한다. 따라서 하나의 작업공간, 파일에 대해서는 한 사람만 동시에 작업을 진행하도록 해야한다.

주의할 점으로 필요에 의해서 다른 파일을 잠시 수정하였다면 해당 수정 내용을 원래대로 되돌리고 원격 저장소에 업로드를 진행하거나, 변경할 목적이 되는 해당 파일만 업로드를 진행해서 반영될 필요가 없는 부분은 업로드를 진행하지 않는다.(git add /pages/login/index.html 등 업로드 할 파일을 직접 선택한다.)

정리

  1. 프로젝트 전용 원격 저장소 생성

  2. develop 전용 branch 생성

  3. 각각의 개발자들은 해당 프로젝트를 fork

  4. 프로젝트에 대해서 remote를 연결
    (보통 내 원격 저장소는 origin, 프로젝트의 원격 저장소는 upstream으로 저장소 이름을 설정)

  5. 프로젝트에서 develop branch 생성(git checkout develop)

  6. 이슈 생성

  7. 할당된 이슈 넘버로 branch 생성(Feature-#16)

  8. 생성한 branch에 개발 진행

  9. 완료된 소스코드를 내 원격 저장소에 업로드(git pull origin Feature-#16)

  10. 해당 내용을 프로젝트의 원격 저장소에 pull request 전송
    (내 원격 저장소의 Feature-#16 -> 프로젝트의 원격 저장소의 develop)

  11. 버그나 코드의 충돌이 없다면 merge 를 진행

  12. 새로운 개발이 필요하다면 develop branch로 이동하여 git pull upstream develop 코드 실행

    이후에 6번부터 반복하여 실행해 프로젝트를 진행

  13. 마지막으로 개발이 완료되면 프로젝트의 원격 저장소에서 develop branch의 소스코드를 main branch에 pull request를 보내서 merge를 진행

0개의 댓글