본문 바로가기
BackEnd

Git & GitHub

by SoriKim 2023. 10. 2.
반응형

1. Git 이란? 


Git 공식 명칭은 분산 버전 관리 시스템(VCS)입니다. 

프로젝트 파일의 변경사항을 추적하며 개발자들은 프로젝트 변경사항을 기록 및 관리를 하며 기록이 있을 시에는 특정 시점의 버전으로 언제든 돌아갈 수 있습니다. 

이런 버전 관리 시스템은 많은 사람들이 함께 효율적으로 작업하며 협업할 때 사용할 수 있습니다. 

 

2. 사용 방법


2-1. 설치 

Git은 주로 command-line interface(CLI) 를 통해 사용하며 컴퓨터에 Git을 설치해야 합니다. 

Git 다운로드 사이트

 

Git - Downloads

Downloads macOS Windows Linux/Unix Older releases are available and the Git source repository is on GitHub. GUI Clients Git comes with built-in GUI tools (git-gui, gitk), but there are several third-party tools for users looking for a platform-specific exp

git-scm.com

위의 사이트에 접속하여 본인 컴퓨터의 해당하는 OS를 선택해 설치를 하면 됩니다. 

설치가 끝난 뒤 Git 의 설치 여부 확인을 위해 터미널 창을 띄워 아래의 명령어를 입력하여 Git 버전 출력 확인을 통해 정상적으로 설치가 되었는지 확인합니다. 

git --version

 

이제 Git 이름과 이메일을 설정해 보겠습니다. 

해당 컴퓨터에서 사용될 본인의 Git 정보를 등록하기 위해서는 아래와 같이 입력하면 됩니다. 

git config --global user.name "이름"
git config --global user.email "이메일"

git "이름" 확인은 git 사이트에 로그인하여 프로필을 클릭하면 창에 나오는 굵은 글씨가 user.name입니다. 

 

2-2. Repositories (저장소)

Git repository는 Git으로 관리하는 프로젝트 저장소이며 크게 두 가지의 종류가 있습니다. 

1. ) Local repository

- 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소 

 

2. ) Remote repository

- 로컬 repository 와는 반대로 내 컴퓨터가 아닌 외부(일반적으로 원격 서버) 버전의 프로젝트 저장소로

팀에서 작업할 때 특히 유용합니다. 이곳에 프로젝트 코드를 공유할 수 있으며 다른 사람의 코드를 확인할 수 있습니다. 

또한 로컬 버전의 프로젝트와 병합하고 변경사항을 적용할 수 있는 곳입니다. 

 

2-3. Initializing a repository 

새 저장소(repository)를 만들어 Git에 프로젝트 관리를 시작하려면 본인 컴퓨터에 터미널에서 프로젝트 폴더로 이동한 후 

git init

위의 명령어를 입력 합니다. git init의 명령어는 프로젝트 폴더 내. git이라는 숨겨진 디렉토리를 생성하여 현재 저장소에 대한 

모든 변경사항을 추적 및 관리합니다. 

 

2-4. Staging and committing code 

Git에서 commit이란 프로젝트 현재 상태를 나타내는 체크 포인트 또는 스냅샷으로 생각할 수 있습니다. 

내 컴퓨터 상 현재 버전의 코드를 커밋에 저장한다고 생각하면 됩니다. 

commit의 히스토리에 필요한 만큼 생성할 수 있으며 commit을 한 시점 앞 뒤로 이동해 프로젝트 코드의 다른 변경사항을 확인할 수 있습니다. 이를 통해 프로젝트의 진행상황을 효율적으로 관리할 수 있게 됩니다. 

 

1. ) 상태 확인

터미널에서 git status를 입력하면 repository 현 상태를 확인할 수 있습니다. 

어떤 파일이 변경 및 추가되었는지를 보여주며 git으로 관리되고 있지 않던 파일들이 있다면 해당 파일들을 

Staging area로 추가해 줄 수 있습니다. 

 

2. ) Staging area에 파일 추가 

 git add  라는 명령어를 통해 우리가 원하는 파일을 staging area로 추가할 수 있습니다. 

하나의 파일을 추가할 때

- git add file.js

 

여러 개의 파일들을 추가할 때 

- git add file.js file2.js file3.js 

 

파일을 개별적으로 추가하지 않고 모든 파일을 한 번에 추가할 때

- git add .

 

위 명령어들을 통해 파일들을 staging area에 추가하고 커밋을 남길 수 있게 해 줍니다. 

 

3. ) commit 남기기 

commit은 특정 시간의 추가한 코드들을 해당 repository의 커밋 기록에 남게 됩니다. 

git add 명령어를 사용해 staging area에 추가했다면 commit을 남길 준비가 된 것입니다. 

git commit -m "Commit message" 

위 명령어를 통해 staging area에 있는 파일들을 commit 할 수 있습니다. 

큰 따옴표 안에 commit 메시지를 작성해야 하며 커밋하는 변경사항을 설명하는 짧은 요약문이어야 합니다. 

 

4. ) commit log 

프로젝트의 모든 커밋 내역을 확인하려면 git log  명령어를 사용하면 됩니다. 

해당 명령어는 각 commit에 대한 자세한 정보(작성자, hash 값, 날짜와 시간, 그리고 커밋 메시지)를 담고 있으며

특정 commit 시점의 코드로 되돌리고 싶다면 git checkout <commit-hash>의 명령어를 사용할 수 있습니다. 

 <commit-hash>는 git log에서 보이는 commit의 실제 hash 값입니다. 

 

5. ) Ignoring files 

staging area에 추가하고 싶지 않고 git에서 관리되지 않아도 되는 파일이 있다면. gitignore 파일을 프로젝트 폴더 내에 생성하여. gitignore 해당 파일 안에 파일명, 폴더명을 나열하면 됩니다. (각 파일 폴더가 새로운 줄에 입력되어야 합니다. ) 

# 예시 
# schema.sql
schema.sql

 

2-5.  Branches

git branch 란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 

각각의 브랜치는 다른 브랜치의 영향을 받지 않아 여러 작업을 동시에 진행할 수 있습니다. 

여러 명이서 동시에 작업을 진행할 때 다른 사람의 작업에 영향을 주고받지 않도록 메인 브랜치에 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후 작업이 먼저 끝난 사람은 메인 브랜치에 자신의 브랜치 변경사항을 적용합니다. 

 

이렇게 진행함으로 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하며 이런 작업 단위 즉 브랜치로 작업 기록을 중간중간 남기게 되면 문제가 발생할 경우 원인이 되는 작업을 찾아내거나 이에 따른 대책을 세우기 쉬워집니다. 

 

git 저장소를 처음 만들게 되면 git은 바로 master라는 이름의 브랜치를 만들게 되며 이 새로운 저장소에 새로운 파일을 추가한다거나 추가한 파일의 내용을 변경해 그 내용을 저장(commit)하는 것은 모두 master라는 이름의 브랜치를 통해 처리할 수 있습니다. 

 

master 가 아닌 새로운 브랜치를 만들어 해당 브랜치를 사용하겠다고 선언하는 명령어 Checkout 를 입력하지 않는 이상 모든 작업은 master 브랜치에서 이루어집니다. 

 

1. ) 브랜치 생성 명령어

git branch <new-branch-name>

 

2. ) 브랜치 전환 명령어

git checkout <branch-name>

위의 명령어를 통하여 원하는 브랜치로 이동하면 해당 브랜치 안에 있는 마지막 commit 내용이 작업 트리에 남아있습니다. 브랜치가 전환되었으므로 이후에 남기는 commit은 전환한 브랜치에 추가되며 해당 브랜치에만 영향을 주게 됩니다. 

다른 브랜치로 이동하여 작업 시 git add, commit 완료 후 작업할 수 있으며 이전 브랜치의 변경사항 및 commit에는 영향을 받지 않습니다. 

브랜치 생성과 동시 생성된 브랜치로 이동하려면 -b만 명령어에 추가하여 아래 명령어로 사용하시면 됩니다.

git checkout -b <new-branch-name>

 

3. ) 모든 브랜치 확인 명령어

git checkout -b <new-branch-name>

 

4. ) 브랜치 병합하는 명령어

특정 브랜치에서 새로운 기능을 완벽하게 구현 및 테스트가 완료되었다면 기준이 되는 master 브랜치에 구현 내용을 적용시킬 때 사용하는 명령어입니다. 

git merge <branch-name>

위의 명령어를 사용하여 다른 브랜치와 현재 브랜치를 병합할 수 있습니다. 

 

5. ) 브랜치 삭제하기

아래 명령어를 통해 브랜치를 삭제할 수 있습니다. 해당 브랜치의 코드 전부가 삭제되므로 사용 시 필요한 코드가 있거나 없어지면 안 되는 코드가 있을 경우 백업을 미리 해두고 해당 브랜치를 삭제하시길 추천합니다. 

git branch -d <branch-name>

여기까지는 Git에 대해 알아봤습니다. 

여기서부터는 GitHub에 대해서 알아보겠습니다. 

 

1. GitHub 란? 


GitHub는 Git repository를 위한 호스팅 플랫폼입니다. GitHub 없이 Git을 사용할 수는 있지만 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 로컬 컴퓨터에서 작성한 코드를 공유하기는 어렵습니다.

 

📍 Git  vs GitHub

🔵 Git은 버전 관리 시스템으로 시간이 지남에 따라 파일의 변경 사항을 추적하는 도구입니다. 

 

🔵 GitHub는 Git을 사용하는 프로젝트를 위한 호스팅 서비스입니다. 

 

GitHub를 사용하여 로컬 프로젝트 repository를 원격 클라우드 기반 GitHub 저장소에 업로드할 수 있고,

Public repository 들을 통해 다른 개발자들과 교류할 수 있습니다. 

GitHub repository는 모든 프로젝트의 파일과 코드의 히스토리를 관리할 수 있게 해 주며 public 또는 private 하게 협업할 수 있게 해 줍니다. 

 

2.  사용하기 


내 로컬 Repository를 GitHub에 push 하기 

1. 로컬에 add/ commit을 진행

 

2. GitHub로 이동 후 새 repository를 생성

GitHub repository를 생성하려면 github.com 으로 이동하여 로그인 후 우측 상단 + 버튼을 클릭하여 

New repository를 클릭합니다. 

repository를 생성하는 페이지에서 repository name을 설정하여 

 

README file이 필요할 시 해당 체크란을 클릭하고 Create repository를 클릭하여 생성합니다. 

3. 나의 로컬 repository를 GitHub repository와 연결( remote를 추가) 

생성이 완료되면 GitHub repository의 첫 페이지로 이동하게 되며 GitHub에서 제공해 주는 remote 관련 팁을 볼 수 있습니다. 

로컬 환경에 이미 Git repository가 있으면.. or push an existing repository from the command line 아래 

GitHub에서 제공해 주는 명령어를 터미널에 입력하여 순서대로 진행해 주시면 됩니다. 

git remote add origin 명령어는 내 컴퓨터에 있는 로컬 repository와 방금 만든 GitHub repository를 연결해 줍니다. 

git push 명령어는 로컬 Git repository의 코드를 GitHub repository로 업로드해 줍니다. 

 

 

4. 새 remote를 이용해 코드를 push

git remote add origin https://github.com/<your-username>/<your-repo-name>.git
git push -u origin master

git push 명령어를 실행하면 GitHub 유저네임과 비밀번호를 입력하라는 prompt 가 뜨게 됩니다.

repository 가 성공적으로 push 되었다면, 전에 만든 GitHub repo 페이지로 가서 새로고침 하면 로컬에서 push 한 코드가 해당 remote repository로 업로드된 것을 확인할 수 있습니다

 

3. git clone 하기


위에서는 로컬에서 git repo를 생성하여 remote git repo를 생성해 연결해 주는 것을 알아보았습니다.

다른 방법으로 github repo를 먼저 생성한 뒤 clone을 받아 내 로컬 환경에 다운로드하는 방법을 알아보겠습니다. 

 

 

1️⃣ 내가 다운로드하으려고 하는 github repo에 들어가 code를 클릭하여 clone 하는 곳의 repository 링크를 복사합니다. 

2️⃣ 해당 repo를 다운로드하고 싶은 경로로 이동하여 git clone <복사한 repo link> 해당 명령어를 사용하여 터미널에서 실행합니다. 

위의 과정을 모두 완료했다면 해당 경로에 clone 받은 GitHub repository의 이름으로 된 폴더가 생성되어 해당 폴더 내에는 repo에 올라간 폴더 및 파일들이 그대로 복제되어 있습니다. 

 

3-1. GitHub 브랜치 merge

일반적으로 GitHub repository의 master 브랜치는 항상 잘 동작하고 안정적인 버전의 코드를 포함하고 있어야 하며 아직 테스트가 안된 코드나 새로 추가할 기능을 해당 master 브랜치가 아닌 새로운 브랜치를 생성하여 추가해야 합니다. 

위에서 알아본 브랜치의 내용이며 위의 내용을 참고하여 새로운 브랜치를 생성할 수 있습니다. 

git chekcout -b <new-branch-name>

새로운 브랜치로 이동하여 새로운 기능을 추가하거나 수정하는 코드를 작성하여 해당 내용이 테스트들을 통하여 정상적으로 작동하는 것이 확인되면 해당 내용을 remote로 올려줍니다. 

아래는 해당 내용을 순차적으로 remote 해주는 명령어입니다. 

# 1. 
git add .
# 2. 
git commit -m "<commit message>"
# 3. 
git push origin <branch name>

위의 내용을 순차적으로 실행 시 방금 push 된 branch 가 추가 된 것을 확인할 수 있습니다. 

 

3-2. Pull Request(PR) 생성 

커스텀 브랜치를 push 하고 master 브랜치에 적용될 준비가 완료되었다면 Pull Request를 통해 프로젝트 오너 또는 리더에게 내가 작업한 브랜치의 작업 내용을 master 브랜치에 반영해 달라는 요청을 보낼 수 있습니다. 

Pull Request에서 해당 repository를 열람할 수 있는 권한이 있는 개발자들이 작업 내용에 대해 리뷰해 주거나 변경사항을 확인할 수 있으며 해당 링크를 클릭하여  Pull Request를 생성할 수 있는 페이지로 이동하여 해당 PR의 제목과 어떤 기능 및 내용을 담고 있는지 설명하는 Description을 작성할 수 있습니다. 

작성을 완료하고 하단에 Create pull request를 눌러 PR를 작성 완료 할 수 있으며

모든 내용이 리뷰가 완료되고 master 브랜치와 충돌이 발생하지 않았다면 해당 PR은 master 브랜치로 merger가 될 준비가 완료된 것입니다.

 

3-3. Conflicts (충돌) 

master 브랜치와 나의 브랜치와의 폴더 및 파일의 충돌이 생겼다면 내 로컬 컴퓨터에서 해당 Conflicts를 모두 해결 후 merge가 가능합니다.

 

3-4. GitHub으로부터 변경사항 pull 하기

PR을 통해 master 브랜치가 업데이트되었다면 이제 로컬 repository는 GitHub에 있는 master와 서로 다른 내용을 가지고 있게 됩니다. 이때 git pull이라는 명령어를 사용해 remote의 최신화된 코드를 내 로컬 환경에 반영할 수 있습니다.

우리는 GitHub remote repo 링크에 origin이라는 이름을 붙여줘서 아래 명령어를 통해 GitHub repo의 master 브랜치 내용을 받아올 수 있습니다. 

git pull origin < master branch name >

 

반응형

'BackEnd' 카테고리의 다른 글

Server Communication(HTTP/S)  (0) 2023.10.28
[AWS] EC2란?  (0) 2023.10.04
Wecode 3st Project 회고록  (0) 2023.09.24
Wecode 2st Project 회고록  (0) 2023.09.03
Wecode 1차 프로젝트 회고록  (0) 2023.08.20

댓글