[Git] - 기본적인 Git 사용법

Git & GitHub

 

1. Git & GitHub

(1) Git은 소스 코드의 형상 관리를 할 수 있는 도구이다.

 

(2) 형상 관리(Software Configuration Management)란, 소프트웨어의 변경 사항을 체계적으로 추적하고 통제하는 개념을 의미한다. 여러 사람이 협업하는 프로젝트에서 작업의 일관성, 안정성을 유지하는 데 도움을 주는 도구라고 보면 된다.

 

(3) 이러한 Git을 웹에서 온라인 환경으로 사용할 수 있는 공간이 GitHub이다.

 

(4) GitHub는 프로젝트의 형상 관리뿐만이 아닌 많은 개발자들 사이에서 거대한 커뮤니티를 형성하고 있고, 자신의 프로젝트는 물론 다른 개발자들의 오픈소스로 풀려있는 프로젝트들을 모두 볼 수 있다. 다른 프로젝트를 보고 이슈를 제기하거나, 수정하고 발전시키는 데에도 참여할 수 있는 데 이 부분을 Open-source Contribution이라고 한다.

 

 

 

 

2. 기본적인 Git Command, 동작 방식

2-1. git init

(1) Git 저장소 초기화, 해당 명령 실행 시 현재 설정된 디렉토리로 새로운 Git Repository 생성

 

 

 

 

(1) Remote Repository

- 원격 저장소의 경우 전용 서버에서 소스코드들이 관리되며 여러 사람이 함께 공유하기 위한 별도의 저장소를 뜻한다.

 

(2) Local Repository

- 로컬 저장소는 소스코드 및 파일들이 개인 로컬 컴퓨터에서 관리된다.

 

(3) Flowcharts

- 로컬에서 작업한 내용을 Staging Area에 로드하고(add) 최종적인 변경사항을 로컬 저장소에 커밋(Commit), 최종적으로 Push하여 원격 저장소에 반영한다.

 

 

 

2-2. git add

(1) 변경한 파일 목록 중, 프로젝트의 모든 변경사항을 Git Staging area에 추가하는 명령

 

(2) git add .은 파일 전체를 Staging area에 추가한다.

 

 

 

2-3. 파일의 상태에 따른 Untracked, Tracked 분류

(1) Untracked의 경우 관리 대상이 아닌 상태로, 파일 생성 후 git add가 진행되지 않은 상태를 의미

 

(2) Tracked의 경우 Git이 직접 관리하는 대상임을 나타낸다.

- Unmodified : 최근 Commit과 비교 시, 변경된 내용이 없는 상태

- Modified : 최근 Commit과 변경 시, 변경된 내용이 있는 상태

- Staged : 파일 수정 후 Staging area에 로드된 상태

 

 

 

2-4. git diff

(1) 변경 사항을 확인하는 명령 

 

(2) 최근 커밋한 내용과 현재 폴더의 변경 사항을 확인할 수 있다.

 

 

 

2-5. git log

(1) Commit History를 조회하는 명령

 

 

 

3. Create a new repository

(1) Repository name 작성

(2) Description 작성

(3) README.md 생성 여부 체크 / 미체크 (선택)

 

 

(4) git commit -m "commit message"

- Staging area에 존재하는 변경 사항을 저장하고 커밋하는 명령

 

(5) git push

- 로컬 저장소의 Commit 사항을 원격 저장소로 업로드하는 데 사용된다

 

 

 

 

 

 

4. Git Branch

Git Branch Workflow

 

4-1. Branch

(1) 브랜치는 쉽게 말하면 프로젝트에서 특정 시점에서의 작업을 가르키는 포인터 역할을 한다. 브랜치를 활용해 협업 시 각자 맡은 부분을 작업함으로써 여러 개발자들과 협업할 수 있다.

 

(2) 여러 개발자가 동시에 작업할 수도 있고, 각각의 작업 내용을 분리해서 관리할 수도 있다.

 

 

 

4-2. Branch 활용

(1) 새로운 기능 추가 & 버그 수정

- 새로운 기능을 개발할 때 기존 코드를 변경하지 않고 새로운 브랜치에서 작업할 수 있다.

 

(2) 특정 기능에 대한 새로운 테스트

- 새로운 기능 등을 테스트하고 싶을 때 기존 코드를 건드리지 않고 테스트를 할 수 있다.

 

(3) 브랜치 작업 이후 Merge

- Merge란 합치다라는 의미를 가지며, 각 작업의 진행 상황을 하나로 합쳐서 하나의 기능을 완성할 수도 있다.

 

 

 

4-3. git branch

(1) 현재 브랜치를 확인할 수 있다.

 

 

 

4-4. git checkout "브랜치명"

(1) 보통 checkout은 떠난다는 의미를 가지지만 Git에서는 해당 브랜치로 이동한다는 의미를 갖는다.

 

 

 

4-5. git branch -d "브랜치명"

(1) 특정 브랜치를 삭제한다.

 

 

 

4-6. git push --set -upstream origin "브랜치명"

(1) 로컬 저장소의 브랜치 정보는 원격 저장소에 자동으로 등록되고 추적되지 않는다.

 

(2) 해당 명령은 현재 작업 중인 브랜치를 원격 저장소의 브랜치와 연결하고 로컬 브랜치와 원격 저장소 브랜치 간의 추적 관계를 설정할 수 있게 된다.

 

(3) 해당 명령을 통해 처음으로 로컬 브랜치를 원격 저장소에 push할 때 사용한다.

 

 

 

 

 

5. Git Merge

(1) Merge(병합)의 경우 두 개의 다른 브랜치를 합치는 데 사용되는 명령이다. 주로 현재 작업 중인 브랜치에 다른 브랜치의 변경 사항을 통합하는 데 사용된다. 

- 다른 개발자가 작업한 변경 사항을 현재 브랜치로 병합하거나 다른 브랜치에서 가져온 변경 사항을 현재 브랜치에 통합할 때 사용하기도 한다.

 

(2) 다음과 같은 방식으로 사용된다.

 

 

5-1. 브랜치 전환 : main 브랜치로 전환하는 경우

- git checkout main

 

 

 

5-2. 현재 브랜치에서 다른 브랜치의 변경 사항을 통합하는 경우 : feature 브랜치를 main 브랜치에 통합

- git merge feature

 

 

 

 

 

6. Git Conflict

(1) Conflict(충돌, 컨플릭)은 두 개 이상의 변경 사항이 동일한 파일의 동일한 부분을 수정하거나, 삭제할 때 발생하는 문제이다.

 

(2) 이러한 상황에서 깃은 어떤 변경 사항을 우선적으로 적용해야 할지 모르기 때문에 컨플릭이 발생하는 것이다.

 

 

 

 

 

7. Git Fork

(1) 포크(Fork)는 전체 소스 코드를 복사해서 온 다음, 직접 코드를 수정하거나 추가하는 작업을 의미한다.

 

(2) Branch, Fork는 거의 비슷해 보이지만 엄연히 다르다. 차이점은 아래와 같다.

 

(3) Branch의 경우 하나의 저장소에서 브랜치를 각각 나누어 작업할 수 있고, Fork는 여러 저장소를 만들고 브랜치를 만들어 작업하는 방법이다.

 

 

 

 

 

8. Git Pull Request

(1) Pull Request의 경우 코드 변경 사항을 다른 개발자들과 리뷰하고 병합할 수 있는 메커니즘을 의미한다.

 

 

8-1. 기본적인 Pull Request(풀 리퀘스트) 방법

(1) 브랜치를 별도로 생성하여 새로운 기능을 개발하거나 또는 기존 코드를 수정한다. 

 

(2) 변경 사항을 커밋하고 원격 저장소로 Push한다.

 

(3) Pull Request를 생성하는데, 이때 변경 사항을 어떤 브랜치에 병합할 것인지 명시하고 이 부분에 대한 코멘트를 추가한다.

 

(4) 이후 코드 리뷰를 진행하며 변경 사항에 대한 피드백이 이루어진다. 코드 리뷰를 통해 버그를 예방하거나 코드 품질을 높이는 등 긍정적인 효과를 기대해 볼 수 있다.

 

(5) 코드 리뷰 완료 후, 변경 사항에 대한 모든 의견이 확인되고 정리됐다면원본 브랜치에 해당 변경 사항이 병합된다. Pull Request를 생성한 개발자나 프로젝트 관리자가 병합을 진행한다.

 

(7) 이처럼 Pull Request는 협업 프로젝트에서 중요한 역할을 하며 무조건 병합(Merge)하는 것을 피하고 병합 이전, 코드 리뷰를 통해 변경 사항에 대한 코드 품질을 높이고, 혹시 발생할지 모를 오류를 예방하면서 프로젝트롤 효율적으로 관리할 수 있는 방법이다.

 

 

 

 

 

 

 

※ 해당 포스팅에 대해 내용 추가가 필요하다고 생각되면 기존 포스팅 내용에 다른 내용이 추가될 수 있습니다.

개인적으로 공부하며 정리한 내용이기에 오타나 틀린 부분이 있을 수 있으며, 이에 대해 댓글로 알려주시면 감사하겠습니다!