Appendix 1. Github 활용하기

버전관리 시스템(VCS, Version Control System)은 소프트웨어 개발에서 필수적인 파일의 변경사항에 대한 기록들을 보관, 저장하는 시스템이다. 보통은 버전 관리, 형상 관리 시스템이라고 표현한다.

오래전에는 CVS나 SVN과 같은 중앙 서버에 변경 기록을 저장하고, 네트웍으로 수정 반영된 파일을 내려받는 형태로 개발을 진행하였으나, 파일이 커질수록 느려지고 네트웍 단절등과 같은 문제에서 자유롭지 못하게 되므로 DVCS(Distributed Version Control System)와 같은 분산 저장 시스템이 도입되기 시작했다. 그 중 가장 대표적인것인 Github(https://github.com) 이다.

Github와 같은 분산 버전 관리 시스템은 로컬에 복제하여 파일의 변경관리를 가능하게 하고 가볍고 빠른 속도로 인기가 급상승하였고 요즘에는 대형 오픈 소스 프로젝트들이나 스타 개발자들이 개발 소스들을 이곳에 모아 관리하게 되면서 개발자들의 인기를 끌게 되었다.

Github 자체는 무료이고 다른 기업용 솔루션이나 프로젝트 관리도구, AI와 ML을 이용한 코드파일럿과 같은 다양한 제품군들이 서비스되고 있으며 현재는 MS에 인수되어 운영 중이다.

Github를 이용하기 위해서는 각종 개발툴에서 지원하는 플러그인이나 소스트리 (https://www.sourcetreeapp.com), Github Desktop(https://desktop.github.com)과 같은 UI 도구들을 이용하는 방법이 있고 Terminal을 통해 명령어를 조작함으로써 소스 관리를 하는 방식등이 지원된다.

문서 작성에는 Markdown 문법을 (https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) 이용하여 HTML로 표현하는 방식을 사용하므로, Git의 명령어와 MD 파일의 설명서를 익히는 것을 추천한다.

이 문서에서는 깃허브를 잘 모르는 사용자를 대상으로 사용 방법과 명령어를 이해하는 방향으로 설명을 하게 될 것이다.

참고 링크

깃허브 - https://github.com

Markdown Syntax - https://www.markdownguide.org/cheat-sheet

깃허브 독스 - https://docs.github.com/ko

깃 SCM - https://git-scm.com

1-1 GitHub 가입하기

깃 메인 화면에서 Sign up 버튼을 클릭하여 계정을 만들 수 있다.

상단 메뉴 Product에서 Documentation(https://docs.github.com/ko) 이나 Github Skills(https://skills.github.com) 문서 등을 통해 학습할 수 있다. 영문 독해에 익숙하다면 다른 문서보다는 공식 Doc이나 Skill 문서를 살펴보길 추천한다.

이 내용들이 좋기는 하지만 다 번역해서 제공할 필요는 없어서 핵심적인 내용만 이 페이지에서 다루려고 한다.

일단 먼저 가입 한 뒤에, 소스 버전 관리용 샘플을 통해 사용법을 차근차근 익혀 보도록 하자.

첫 번째로 계정을 만들도록 하자. 이메일로 로그인 계정을 만들 수 있다.

패스워드를 입력한 후, 깃허브에서 사용하는 유저명 (이 유저명이 URL의 경로로도 쓰이므로 신중하게 작성하도록 하자)을 등록한다.

update 메일을 받을 건지에 대해서 입력하는 란이 나온다. 받으려면 y, 받지 않으려면 n을 입력한다.

스팸을 막기 위해 간단한 퍼즐 선택 후 가입을 위한 활성화 코드 입력 단계로 넘어간다.

가입이 정상적으로 완료되었다면 이메일로 launch code가 전송된다. 이 활성화 코드를 화면에 입력하면 가입은 완료되고, 간단한 사용자 설문 화면이 등장한다.

몇 명이 사용할지, 사용자의 성격 (학생, 선생님) 등을 선택하면 되고 깃허브의 어떤 기능을 사용하려고 하는지 몇 가지 선택하면 회원 가입은 정상적으로 완료된다.

사용자 선택에 따라 몇 가지 추가적인 옵션들이 나오는데 Continue for free를 선택하면 깃의 개인화면으로 이동하게 된다.

최초에는 아무런 저장소(Repository라고 부른다)가 없으므로 아래와 같은 화면처럼 나올 것이다.

Create repository를 눌러 Repo를 생성해 보자.

간단히 리파지토리명과 설명을 입력한 후 Public (깃허브에 오픈되어 자유롭게 사용자들이 접근가능하다), Add a README file 정도만 선택한 후 생성 버튼을 클릭하면 정상적으로 깃허브의 Repository가 만들어진다.

👏 이제 깃 허브에 첫 깃발을 꽂았다. 👏👏👏

보통 깃허브는 주소 뒤에 Path로 사용자 ID, 그 뒤에 Repository명 형식으로 URL이 완성된다.

여기서는 https://github.com/USER-ID/git-sample 이라는 주소가 Repository인 것이다.

Repository 메인 화면에는 Repository를 조작하는 기본 버튼 몇 개와 README.md 파일이 설명문으로 나올 것이다. 캡처상으로는 내용이 있지만 아마 빈 값이 나오게 될 것이다.

먼저 Code버튼을 클릭하면 URL로 접근하는 깃 저장소 주소가 나올 것이고 SSH(PC에 public key를 생성해서 등록해야 한다)나 CLI를 이용한 주소도 선택하면 사용할 수 있다.

소스 자체를 zip으로 다운로드도 가능하다.

사용법이나 주의사항 등을 적는 용도인 readme 영역을 보면 우측에 펜으로 된 아이콘이 해당 내용을 수정할 수 있는 기능이므로, 클릭한 후 간단히 마크 다운 문법으로 내용을 적어보자.

내용을 입력한 후 Commit changes에 무엇을 수정한 건지 기록한 후 commit을 누르면 화면에 수정한 내용이 반영된 것을 확인할 수 있을 것이다.

그리고 이 내용은 메인화면의 파일 리스트에서 변경 내역이 마킹되어 반영된 것을 확인할 수 있다.

이제 기본적인 첫 스텝은 마무리되었다.

1-2 PC에 Git 설치하기

윈도 PC는 별다른 특이사항이 없이 git scm(https://git-scm.com/download/win)에서 PC 사양에 맞는 인스톨러를 다운로드하고 설치하면 끝나지만 (윈도의 경우 구글링으로 간단히 설치할 수 있는 문서들이 많이 나와있으므로 참고하기 바란다) Mac의 경우 최초 실행 시에 몇 가지 사전 작업들이 필요하다.

1) 기본 환경 설정

먼저 Git이 설치 되어 있는지 확인해 보자.

git --version

깃이 설치되어있다면 버전이 출력될 것이고, 버전이 안 나온다면 Git을 homebrew를 통해 추가로 설치해줘야 한다.

또한 맥의 경우 보통은 Git Repository의 소스를 Clone 하는 형태로 작업을 많이 하는데, 실제로 깃이 깔려 있지 않은 경우에는 Terminal에서 아래의 명령어를 입력하게 되면 Xcode Command Line Tools의 설치가 필요하다고 나오게 된다.

git clone https://github.com/[User-name]/GitRepositoryName.git

터미널을 열고 본인의 git 리포를 입력해 보자.

최초 실행 시에 xcode가 존재하지 않아서 다운로드하여 설치해야 한다.

git clone https://github.com/[user-name]/git-sample.git
xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.

git 명령어 실행 후 Xcode Command Line Tools이 없으면 아래와 같이 설치 모달창이 나오므로 설치를 먼저 한 뒤, Homebrew (맥용 패키지 관리자)를 설치해 주도록 하자.

2) homebrew 설치하기

https://brew.sh 에 접속하여 아래의 명령어를 입력한다.

Install Homebrew 명령어를 복사한 뒤 터미널에서 입력하면 설치가 될 것이다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

입력이 끝나면 자동으로 brew를 설치한다.

Installation successful이라는 메시지가 뜬다면 설치에 성공 한 것이다.

3) git 설치하기

정상적으로 homebrew 가 설치가 되면 터미널에 아래의 명령어를 입력하여 git을 설치할 수 있다.

brew install git

만약 brew install 이 제대로 안된 경우 아래와 같이 brew 명령어를 실행할 수 없다는 에러 메시지가 나올 것이다. 그럴 경우 다시 homebrew install 명령어를 실행해 보거나, 맥의 칩셋에 따라 경로가 다른 케이스도 존재하므로 하단의 명령어를 통해 경로를 다시 조정해주어야 한다.

zsh: command not found: brew

2023년 1월 필자의 노트북은 M1칩이므로 Intel 계열 칩의 맥북이 아닐 경우 brew 설치가 제대로 안될 수 있다. homebrew가 intel 칩 기준이라 경로를 바꿔주어야 한다. 터미널을 열어 아래의 명령어를 입력한다.

<MAC_USER_ID>는 맥의 사용자 계정이므로 본인의 계정에 맞게 입력해 주면 되고, 잘 모를 경우 터미널에서 pwd를 입력하면 기본 계정의 명이 출력될 것이다. 해당 계정으로 아래의 명령어를 수정한 뒤 엔터를 누른다.

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/<MAC_USER_ID>/.zprofile

Users 경로에 본인 맥 계정 하위에 .zprofile 파일을 생성된 것을 확인할 수 있다. (이미 존재한다면 VI로 열어 eval "$(/opt/homebrew/bin/brew shellenv)" 명령어를 추가해 주도록 한다)

brew help 명령어가 동작하는지 확인해 보자.

brew help

아래와 같이 명령어 help가 출력되면 brew가 성공적으로 깔린 것이다.

brew install git 을 통해 git을 설치해 보자.

설치가 완료되었다면 가볍게 워크용 디렉토리를 만든 후 git을 사용해 보도록 한다.

먼저 작업용 워크 디렉토리를 만든 후 이동한다.

mkdir git-workspace
cd git-workspace

이 디렉토리가 작업 디렉토리의 최상위 폴더가 되고, 이 하위에서 git 소스를 clone할 예정이다.

git clone https://github.com/[user_name]/git-sample.git

이제 git-sample 디렉토리가 생긴 것을 확인할 수 있으며, 해당 디렉토리에 로컬에 변경사항이 발생한다면 git status로 상태를 확인할 수 있다.

git-sample 코드를 받고 이동 후 git status를 입력하면 현재 워크트리의 변경사항이 존재하지 않으므로 위와 같은 메시지가 나올 것이다.

이제 이 작업 폴더에서 파일을 수정(추가) 한 뒤 commit을 해보도록 하자.

만약 최초 git repository 설정 시에 README.md 파일을 만들었다면 에디터로 파일을 열어서 간단하게 수정한 뒤 저장을 하면 된다.

여기서는 맥용 VScode(https://code.visualstudio.com)를 사용하여 커밋용 파일을 수정하였다.

만약 README 파일을 만들지 않았다면 아래의 명령어로 파일을 만들어 주면 된다. 이미 README.md를 만들었다면 README-TEST.md라는 별도의 파일을 만들어서 테스트해도 무방하다.

touch README.md

이 파일을 수정(아무 내용이나 입력한다)한 뒤에 깃이 파일을 tracking 할 수 있도록 추가해주면 된다.

git add README.md

이제 깃에 파일 수정한 부분을 추가해주었으므로, 커밋 메시지를 작성하면 된다.

git commit -m “첫 번째 커밋입니다.” 입력 후 엔터를 누르면 아래와 같은 메시지가 출력될 것이다.

[main cfb96d3] 첫번째 커밋입니다.
 Committer: User Name <mac_user@MacBookPro.local>
이름과 전자메일 주소를 사용자 이름과 호스트 이름을 이용해서 자동으로 설정했습니다. 이 정보가 맞는지 확인하십시오. 이 메시지를 보지 않으려면 정보를 명시적으로 설정하십시오. 다음 명령어를 실행하고 편집기의 안내에 따라 설정
파일을 편집하십시오:

    git config --global --edit

이렇게 한 다음, 이 커밋에 사용한 신원 정보를 다음과 같이 해서 바꿀 수 있습니다:

    git commit --amend --reset-author

 1 file changed, 2 insertions(+)

최초 설정이 (user name이나 password) 존재하지 않으므로 메시지가 나오는 것인데, 안내한 대로 config 파일을 고치고 저장해 주면 된다.

git config --global --edit

글로벌 설정에서 name, email 항목을 주석 제거한 후 사용자 계정으로 변경한다. (vi를 써야 하므로 주의하기 바란다. 만약 vi 가 익숙하지 않다면 Git 전용 에디터를 별도로 지정하는 게 편하다)

사용자 이름과 이메일 수정 후 ESC키를 누르고 :wq! 입력한 뒤 나오면 저장될 것이다.

이제 수정한 내역을 원격 Git에 반영해 보자.

git push origin main

원격 브랜치(main 브랜치)에 변경사항을 push 하는 명령어이다. 입력 후 엔터를 치면 Username과 Password를 입력하라고 아래와 같이 나올 것이다.

여기서는 명령어 실행 후 Username과 Password 입력하면 에러가 난다. 기존의 Github에서는 로그인 패스워드 기반으로 동작이 가능했는데 보안 정책이 바뀌어서 다른 설정들을 추가로 해주어야 한다.

Username for 'https://github.com': [user_name]
Password for 'https://[user_name]@github.com': 
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/[user_name]/git-sample.git/'

메시지를 읽어보면 Git의 https 보안 정책이 바뀌어서 personal access token을 발급받아야 하고, password 방식의 접근은 2021년 8월부터 지원되지 않는다고 나온다.

전반적인 안내에 대해서는 공식 페이지 (링크 참고 https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) 를 참고하기 바란다.

우리에게 필요한 것은 Personal access token인데, Personal access tokens는 HTTPS URL 형태의 작업에만 사용할 수 있다.

깃의 메인 화면에서(그림 1-28) Code 메뉴에 보면 HTTPS로 접근할 건지, SSH로 접근할 건지를 선택할 수 있는데, 우리는 일단 가장 많이 쓰는 HTTPS로만 접근을 하게 될 것이다.

SSH로 할 경우는 token은 발행하지 않아도 되고, 주소 역시 HTTPS로 접근할 수 없다. 대신 SSH 주소 (git@github.com:user-id/Repository-Name.git) 형태로 접근해야 하고, SSH public key를 로컬에 생성해 둔 뒤 Github의 setting에서 SSH key를 추가해주어야 한다. token 발행 형식이든 SSH key 인증 방식이든 어떤 것이든 편한 방식을 선택하면 된다.

4) personal access token 생성하기

로그인 후 우측 상단의 계정 아이콘을 클릭하면 Settings라는 메뉴가 보일 것이다.

좌측 메뉴에서 계정, 빌링, 키 등의 메뉴들이 보이는데, 맨 하단에 Developer settings 메뉴에 들어가면 access token을 발급받을 수 있다.

Personal access tokens 발급 방식은 Fine-grained tokens과 classic Tokens 두 가지 형태가 존재한다.

공식 메뉴얼에서는 Fine-grained personal access tokens을 추천하는데, 이 방식은 조직 권한 관리 측면이나 리파지토리 별 접근 관리 측면에서 아래와 같은 이점이 존재한다고 나와있다.

각 토큰은 단일 사용자 또는 조직이 소유한 리소스에만 액세스 할 수 있습니다.
각 토큰은 특정 리포지토리에만 액세스 할 수 있습니다.
각 토큰에는 personal access tokens (classic)에 부여된 범위보다 더 많은 제어를 제공하는 특정 권한이 부여됩니다.

여기서는 개인 레파지토리라서 딱히 리파지토리별로 사용 권한을 부여해야 할 필요는 없으므로 Classic 방식의 Token을 발급받도록 하자. Fine-grained personal access tokens 방식은 추후에 조직(팀)을 세팅한다거나 리포별 별도 권한 체계를 가져가고 싶을 때 변경하면 된다.

Generate new token을 클릭한다.

토큰 생성 화면에서 이 토큰이 어떤 용도인지 Note를 적어놓아야 나중에 헷갈리지 않을 것이다. 기본적으로 터미널에서 접근하는 것과 개발툴도 존재할 것이고, 만료일도 설정하다 보니 어떤 토큰인지 나중에는 헷갈릴 수 있으므로 명확한 규칙을 가지고 생성하도록 한다.

repo를 선택한 후 (더 추가해 줄 권한이 있으면 해 줘도 된다) Generate token을 클릭한다.

정상적으로 생성된 것을 확인할 수 있다.

토큰이 생성되었다면 이 토큰을 복사해서 안전한 곳에 보관해 놓도록 하자.

만약 잊어버린다면 다시 토큰을 재생성해주어야 하고, 생각보다 귀찮은 일이므로 어딘가에 꼭 메모와 함께 저장해 두기를 추천한다.

이제 다시 push 해보자.

push 하기 전에 항상 유념해야 할 git의 작업 순서가 있다.

초심자들은 이 부분 때문에 git의 작업 오류를 많이 겪게 되는데 아래의 1,2,3 순서들을 push 하기 전에 꼭 기억해 두기 바란다.

(1) 리모트 서버의 저장소와 로컬 저장소의 동기화

만약 두 명 이상이 작업한 다고 가정하면 내 작업본이 로컬에 존재하고, 누군가 서버에 결과물을 push 한 경우 리모트 저장소가 내 commit 보다 버전이 높아 커밋히스토리가 서로 다를 것이다. 이때는 리모트 서버의 저장소와 내 로컬 저장소를 동기화해주어야 한다.

git fetch 명령어로 실행할 수 있다.

git fetch origin

(2) 리모트 소스와 병합

fetch는 정보만 가져오고 실제 로컬 저장소와 합쳐지지는 않은 상태(소스 머지라고 표현한다)라서, git pull 명령어로 로컬 저장소의 소스와 병합하는 작업을 해주어야 한다.

git pull origin main

(3) 병합된 소스를 커밋하고 push

로컬에 병합된 소스를 수정하거나 추가한 경우 git add와 git commit 명령어로 커밋한 뒤 push 해주어야 최종 머지된 결과물이 리모트 서버에 반영이 될 것이다.

git add README-TEST.md
git commit -m "커밋 메시지 작성" 
git push origin main

최초에 로컬 작업 버전을 커밋한 뒤 푸시를 하면 user name과 password를 추가로 입력해주어야 하고, 이때 password는 본인이 어딘가에 잘 보관해 둔 token을 복사해서 넣어주어야 한다.

만약, 다른 계정과 병행해서 써야 한다면 (개인 계정과 팀 계정이 서로 다를 경우) 해당 작업 소스의 root에서 사용자 설정을 변경해 주는 번거로움이 있을 수 있다.

아래는 지금까지 설명한 git 명령어를 통해 파일을 만들고 커밋, 푸시 한 순서를 캡처한 것이다. 사용자 계정이 기존에 사용하던 것과, 강의를 위해 새로 개설한 아이디를 병행해야 해서 사용자 설정을 추가적으로 해주었다.

아마 어렵지 않게 이해가 될 것으로 생각한다.

중간에 pull을 하지 않은 이유는 remote에서 clone 하자마자 작업을 해서 변경사항이 존재하지 않는 상황이라 진행했지만, 두 명 이상의 환경에서 작업 시간이 걸린다거나 변경이 발생할 가능성이 있다면 push 전에 반드시 fetch, pull 병합 작업을 해주어야 한다.

password에 토큰을 제대로 넣지 않았을 경우 혹은 토큰이 제대로 생성되지 않고 다른 권한으로 세팅이 되었을 경우에는 아래와 같은 메시지를 확인할 수 있다.

remote: Permission to user-id/git-sample.git denied to user-id.
fatal: unable to access 'https://github.com/[user_name]/git-sample.git/': The requested URL returned error: 403

Git에 push가 제대로 되었다면 아래와 같은 메시지가 확인될 것이다.

$ git push origin main
Username for 'https://github.com': [user_name]
Password for 'https://[user_name]@github.com': 
오브젝트 나열하는 중: 5, 완료.
오브젝트 개수 세는 중: 100% (5/5), 완료.
Delta compression using up to 10 threads
오브젝트 압축하는 중: 100% (2/2), 완료.
오브젝트 쓰는 중: 100% (3/3), 358 bytes | 358.00 KiB/s, 완료.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/[user_name]/git-sample.git
   9c7783c..cfb96d3  main -> main

여기까지가 기본적인 Git 사용법이다. 이제 좀 더 다양한 기능을 알아보도록 하자.

5) 브랜치 만들기

여러 작업자가 코드를 개발해야 한다고 가정해 보자. 각각 다른 Feature를 하나의 저장소에 반영할 경우 소스의 원본이 빈번하게 바뀌고 fetch, pull, push 가 하루에도 수십 번씩 이뤄지게 되면서 소스의 conflict가 시도 때도 없이 발생할 것이다. 이때 소수의 공통 성격을 가진 개발 소스를 별도로 따서 관리하면 효율적일 것이다. 이때 원본과 동일 버전의 분기 저장소를 별도로 생성하여 관리하는 것이 바로 브랜치이다. 기존 원본의 작업 내용에서 새 작업 내용은 분리하여 관리할 수 있고, 여러 명이 여러 가지 다른 작업을 하게 될 때에도 브랜치를 여러 개 생성하여 독립적으로 운영한 뒤 머지하게 되면 충돌이 그만큼 적게 발생할 수 있는 것이다.

Git은 자유롭게 브랜치를 만들고, 쉽게 브랜치 간 이동을 할 수 있으며, 빠르게 메인 소스와 머지할 수 있는 장점이 있는 분산저장소이다.

이제 별도의 브랜치를 만들고 파일을 수정한 후, 메인 브랜치에 병합(merge)을 해보도록 하자.

git branch develop

여기서는 git branch [브랜치명] 으로 develop 브랜치를 생성하였다.

브랜치를 만들었으면 해당 브랜치로 이동해서 코드 수정이나 삭제, 추가 등의 개발 작업들을 메인 저장소와는 독립적으로 진행할 수 있다. git checkout 이라는 명령어로 branch 간 전환을 할 수 있다.

git checkout develop

믈론 브랜치를 생성하면서 해당 브랜치에 바로 이동(checkout)을 할 수도 있다.

git checkout -b [브랜치명]

브랜치로 이동한 뒤 파일을 추가하여 소스를 머지한다.

먼저 에디터를 열어서 현재 경로에 html 파일을 만든다. 여기서는 index.html 파일을 만들었다.

html 파일을 저장한 후 git 저장소에 추가해주고 commit 메시지를 작성하자.

git add index.html

현재는 develop 브랜치이고, 커밋 후 이 브랜치를 원격 저장소에 등록할 것이다.

git commit -m "develop 브랜치에 html 파일을 추가 했어요"

커밋 메시지가 작성되었다면 원격 저장소에 push 해보도록 하자.

git push -u origin develop

결과는 아래와 같이 나올 것이다.

$ git push -u origin develop
오브젝트 나열하는 중: 5, 완료.
오브젝트 개수 세는 중: 100% (5/5), 완료.
Delta compression using up to 10 threads
오브젝트 압축하는 중: 100% (3/3), 완료.
오브젝트 쓰는 중: 100% (3/3), 349 bytes | 349.00 KiB/s, 완료.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: 
remote: Create a pull request for 'develop' on GitHub by visiting:
remote:      https://github.com/[user-name]/git-sample/pull/new/develop
remote: 
To https://github.com/[user-name]/git-sample.git
 * [new branch]      develop -> develop
branch 'develop' set up to track 'origin/develop'.

develop 브랜치가 추가되었다면 github의 메인 화면상에 브랜치 목록에 develop 브랜치가 추가된 것을 확인할 수 있다.

브랜치가 머지되어 생성됨과 동시에 메인 소스 트리에 머지할 수 있게 pull request 버튼이 생성되었다. 이 버튼을 통해서 메인 브랜치와 push로 등록된 소스 간 비교와 병합을 진행할 수 있다.

Compare & pull request를 누르면 main ← develop 브랜치 간에 소스 변경사항에 대해서 반영 요청을 하는 단계인 PR(Pull Request)을 올리릴 수 있도록 내용을 등록할 수 있다.

이 단계에서 변경 사항에 대해 논의하고, 소스 검토&리뷰를 진행하거나 추가적인 커밋등을 연결하여 하나의 완성본 (main 브랜치 source는 불완전한 형태로 유지하지 않는 편이 좋다) 이 병합되는 것이다.

첫 번째 리퀘스트라고 간단히 작성한 후 PR을 생성해 주었다.

타인의 소스라면 동료들이 검토하는 과정을 거쳐 PR을 Merge 하는 프로세스가 대부분이지만 여기서는 혼자 작업한 것이므로 Self PR을 올리고 Self Merge를 진행하였다.

Merge pull requests를 보내면 어떤 파일을 누가 어떤 내용을 요청 보냈는지 확인할 수 있고, Confirm을 통해 최종 브랜치의 소스가 메인 브랜치에 병합된다.

물론 Confirm을 하였다고 해도 커밋 자체를 되돌릴 수(Revert) 있다.

confirm에 성공하면 1-43 그림과 같이 성공했다는 메시지가 나오고 기존에 작업한 브랜치를 삭제할 수도 있다. (보통은 히스토리 파악을 위해 일정 기간 정도는 보관한다)

메인 Repository를 확인해 보면 브랜치가 2개이고 최종 n분 전에 PR을 보낸 소스의 머지가 완료되어 Commit 내역이 반영된 것을 확인할 수 있다.

아래 이미지처럼 브랜치 목록도 정상적으로 보이고, push를 한 index.html 파일의 커밋 메시지도 정상적으로 보이면 성공한 것이다.

최대한 자세히 설명하려 신규 계정 가입부터 맥에서 돌아가는 새 환경에서의 프로그램 세팅까지를 진행하였고, 토큰 인증을 통해 원격 Repository에 Push 하는 방법에 대해서 알아보았다.

6) 인증 에러 (403)가 날 경우

최대한 자세히 설명하기 위해서 캡쳐 이미지를 많이 사용해 보았다. 그럼에도 불구하고, 사용자마다 에러가 나는 포인트들이 존재할 것이다.

대표적으로는 이미 기존 Git 설치가 되어 있는 상태일 때 새롭게 계정을 추가하거나 변경하면 기존 저장키로 인해 토큰 인식이 안될 수 도 있다.

이 경우는 key chain에 git 계정 관련 값들을 삭제하여 초기화 한 뒤 진행하면 된다.

push를 시도할 때 여러 계정을 같이 사용하게 되면 키체인에 등록된 값으로 토큰이 인식되지 않을 경우 이 값을 리셋해주거나 토큰으로 업데이트 해주어야 한다.

맥 런치패드의 기타 항목이나 검색을 통해 키체인에 접근한 뒤, 해당 Git에 접근한 계정정보를 클릭하여 토큰을 업데이트 해준다.

github.com 리스트마다 계정정보가 다를것이므로 토큰을 업데이트 해줄 계정을 찾아 1-48 이미지처럼 암호보기를 체크한 후 토큰을 업데이트 해주면 정상적으로 동작하는것을 확인 할 수 있다.

이것으로 기본적인 Github의 설정방법과 사용법에 대한 설명을 마무리 하겠다.

1-3 Git 명령어 모음

1) 사용자 글로벌 세팅

최초에 GitHub와 연동하기 위해서 아래와 같이 입력해 주도록 한다.

git config --global user.name “UserName” # 유저명 
git config --global user.email xxx@gmail.com # 유저 이메일

글로벌 설정 후 git에서 clone을 하거나 pull 할 때 Username과 Password를 물어보는데 이때 패스워드에 위에서 설명한 token을 넣어주면 된다. 따라서 토큰은 본인만 알 수 있는 경로에 안전하게 복사/보관하도록 하자.

매번 붙여 넣기가 귀찮을 수 있는데 최초에 로컬에서 푸시한 후 cache를 적용하거나 로컬의 repository에 있는. git 디렉터리 밑에 config 파일의 remote origin 주소 형식을 바꿔주면 된다.

(1) cache 로 글로벌 설정 저장/해제

git config --global credential.helper cache  # token 글로벌 캐싱  
git config --global --unset credential.helper  # 캐싱 해제

(2) Local Repository 폴더 / .git 하위의 config 수정

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = https://[user-id]:[token]@github.com//[계정명]/[깃레파지토리명].git   
        fetch = +refs/heads/*:refs/remotes/origin/*
# url = https://haru-note:gshadsfdasdfasdfasdf@github.com/haru-note/SpringBoot3-Rest.git
[branch "main"]
        remote = origin
        merge = refs/heads/main

번거롭지만 보안을 위해 git의 정책이 단체인 경우나 private 일 경우 공용 접근 사용자에 대한 보안으로 token을 이용하는 것으로 바뀌었기 때문에 설정해 두기 바란다.

아래는 처음 사용하는 유저가 알아두면 좋을 git 명령어이다.

2) Git 최초 설정을 위한 기본 명령어

글로벌 사용자 세팅이 등록되었다면 이제 아래의 명령어들을 살펴보자. 기초적인 내용이지만 소스트리나 개발툴에 내장된 Git 클라이언트를 사용하기 전에 한 번쯤은 기억할 필요가 있다.

mkdir [project] # 내 프로젝트용 로컬 폴더 만들기

cd project  # 폴더로 이동

git init # 해당 프로젝트 폴더를 기준으로 저장소를 생성한다.

git add README.md # README.md 파일을 추가

git status # 상태확인

git commit -m "첫번째 커밋" # 추가한 파일 커밋하기

3) Git 활용 명령어

브랜치 만들기

git branch [브랜치명] # 브랜치를 생성한다.

git branch newBranch # newBranch 브랜치 생성

git branch # 전체 브랜치 목록 확인

git branch -a # 로컬, 리모트 저장소의 모든 브랜치 확인 (-r 일 경우 리모트 확인, -l 일 경우 로컬 브랜치 확인)

git branch -M newName  # 브랜치명 변경, 기존에는 master 라는 컨벤션으로 중요 브랜치를 생성했으나 최근에는 main으로 변경되었다.

git branch -D localBranch # 로컬 브랜치 삭제

브랜치 전환하기

git checkout [브랜치명] # 브랜치 이동 (체크아웃)

git checkout -b [브랜치명] # 신규브랜치 생성하면서 체크아웃을 한번에

리모트 브랜치 전환하기

git remote add origin http://github.com/user-name/user-repository.git # origin 이라는 단축 이름 + url 형태로 원격 저장소를 추가할 수 있다.

git remote -v # 현재 등록된 저장소를 확인

git remote remove origin # 원격 origin 이라는 저장소 삭제

원격 브랜치 가져오기

git fetch --all

모든 브랜치 업데이트

git pull --all

원격 브랜치 확인

git branch -a

마스터에 머지

마스터 브랜치에 머지하기 위해서는 우선 마스터 브랜치로 이동한 후 머지하고자 하는 브랜치를 당겨와야 한다.

git checkout master # 마스터 브랜치로 이동

git merge newBranch # newBranch 브랜치를 master 브랜치로 머지 -> fast-forward 병합

리모트 브랜치에 반영하기

git pull [remote] [branch] # 원격 브랜치에서 현재 브랜치로 소스를 땡겨온다.

git push -u origin master # 현재 브랜치를 원격 저장소에 등록 (브랜치가 원격에 없으면 생성한다. 있을 경우 원격 브랜치에 반영한다.)

브랜치 삭제하기

git branch -d [브랜치명]

rebase 로 병합하기 (newBranch 브랜치에서 master 브랜치에 reabase 실행하기)

git checkout newBranch

git rebase master

충돌시 해당 파일을 수정 한후 add 하고 rebase 해주어야 함

git add file.txt

git rebase --continue # commit 대신 수행

master 로 머지 수행 (newBranch 에서 master로 병합 실행)

git checkout master

git merge newBranch

rebase 취소 하기

git rebase —abort

이전 명령으로 되돌리기

git reset —hard HEAD~

커밋 되돌리기

커밋만 되돌리고 싶을 때 (soft)
변경한 인덱스의 상태를 원래대로 되돌리고 싶을 때 (mixed)
최근의 커밋을 완전히 버리고 이전의 상태로 되돌리고 싶을 때 (hard)

cherry-pick을 이용하면 다른 브랜치에서 지정한 커밋을 복사하여 현재 브랜치로 가져올 수 있다.

특정 브랜치에 잘못 추가한 커밋을 올바른 브랜치로 옮기려고 할 때

다른 브랜치의 커밋을 현재 브랜치에도 추가하고 싶을 때

git log # 꺼내와야 할 커밋 로그 확인

git checkout master # 마스터로 이동

git cherry-pick 99daed2  # 특정 버전을 추가

브런치 상의 커밋을 하나로 모아서 병합할 때 (squash)

git checkout master

git merge --squash newBranch

commit 로그를 확인하고 싶을 때

git log

commit 메시지를 변경하고 싶을 때

git commit —amend

commit 취소

git revert HEAD

git reset HEAD^ # 최종 커밋을 취소. 워킹트리는 보존됨. (커밋은 했으나 push하지 않은 경우 유용)

git reset HEAD~2 # 마지막 2개의 커밋을 취소. 워킹트리는 보존됨.

git reset --hard HEAD~2 # 마지막 2개의 커밋을 취소. index 및 워킹트리 모두 원복됨.

git reset --hard ORIG_HEAD # 머지한 것을 이미 커밋했을 때, 그 커밋을 취소. (잘못된 머지를 이미 커밋한 경우 유용)

git revert HEAD # HEAD에서 변경한 내역을 취소하는 새로운 커밋 발행(undo commit). (커밋을 이미 push 해버린 경우 유용)

git reset --hard HEAD # 워킹트리 전체를 마지막 커밋 상태로 되돌림. 
# 마지막 커밋이후의 워킹트리와 index의 수정사항 모두 사라짐. (변경을 커밋하지 않았다면 유용)
# reset 전의 커밋으로 되돌려야 할 경우 (실수로 reset을 한 경우)

commit 삭제

2단계 전까지 삭제

git reset --hard HEAD~~

reset 전의 커밋으로 되돌려야 할 경우 (실수로 reset을 한 경우)

git reset --hard ORIG_HEAD # reset 실행전으로 상태를 되돌림

git remote repository url 변경

현재 git remote ( 원격저장소 ) url 확인

git remote -v

remote set-url 을 통하여 remote ( 원격저장소 ) url 변경하기

git remote set-url origin https://[저장소주소]/[저장소명].git

변경 결과 확인하기

git remote -v

git refusing histories 관련 에러 (- fatal: refusing to merge unrelated histories, 서로 연관관계가 없는 커밋 히스토리 병합할 때) : 두 브랜치간의 저장소 이력이 서로 다르기 때문에 (두 브랜치가 독립적으로 생성한 경우) 발생한다. 아래와 같이 현재 작업중인 브랜치에서 새 브랜치를 생성한 뒤 강제로 병합해주어야 한다.

git branch new-branch
git checkout new-branch 
git pull origin master --allow-unrelated-histories

현재 만든 브랜치 (new-branch 라고 생성)로 원격 저장소의 master 브랜치를 병합하는데, 서로 다른 이력을 가지고 있기 때문에 이를 허용해주는 옵션을 붙였다.

현재 브랜치에서 master에 있는 소스를 병합하기 위해서는 아래와 같이 수행하면 된다.

git merge --allow-unrelated-histories master

두 명령어 모두 --allow-unrelated-histories 옵션을 사용하여 서로 다른 이력을 가진 브랜치를 병합할 수 있게 한다.

원격 git에 기존 소스를 병합하려 할 때 error: src refspec main does not match any 와 같은 에러가 난다면 아래와 같은 이유일 가능성이 크다.

병합하려는 소스 브랜치가 존재하지 않는 경우:

병합하려는 소스 브랜치가 현재 로컬 저장소에 존재하지 않는 경우에는 해당 오류가 발생한다. 먼저 소스 브랜치가 있는지 확인하고, 존재하지 않는 경우 브랜치를 만들어야 한다.

병합하려는 소스 브랜치가 원격 저장소에 존재하지 않는 경우:

병합하려는 소스 브랜치가 원격 저장소에 존재하지 않는 경우에도 이 오류가 발생한다. 이 경우에는 원격 저장소에 해당 브랜치가 있는지 확인해고 원격 저장소에 없는 경우 로컬 저장소로부터 브랜치를 푸시하거나, 원격 저장소에 해당 브랜치를 생성해야 한다.

만약 위의 두 방식으로도 문제가 해결되지 않는다면 깃을 초기화 최초에 푸시를 수행하는 것처럼 세팅한 후 브랜치를 만들고 커밋해보자.

git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/USER-ID/git-repository-name.git
git push -u origin main

Github에 새로운 Repository 를 생성 하고 로컬에 연결할 때

코드 작성 전에 git 에 푸시하기
github 에 들어가서 repository 생성 (여기서는 HelloMessageQueue로 생성)
인텔리제이 로컬 터미널로 이동해서 아래와 같이 초기화 및 remote 설정 후 rebase 한 뒤 push

git init 
git remote -v  // 원격 url 확인 
git remote remove origin // 있을 경우 모든 원격 url 삭제 

git remote add origin https://github.com/[MyAccount]/HelloMessageQueue.git // 다시 연결 
git remote -v 
git add .
git commit -m "init"
git pull origin main --rebase // rebase 옵션은 로컬의 변경사항을 원격의 최신 변경사항 위에 재배치
git push origin main

2 Git의 브랜치 관리 전략

git의 브랜치를 운영하는 전략은 아마도 회사마다 다 다를것이다.

그러나 업계에서 가장 널리 쓰이는 전략은 존재하고, 이 전략을 보통은 git flow 전략 (방법) 이라는 이름으로 부르고 있다.

공식적인 명칭은 Git flow branch management strategy 라고 한다.

로컬, 개발 서버, 테스트 서버, 스테이징 서버 등의 Phase 단위로 머지 대상 브랜치를 가져감으로써 브랜치 규칙을 통해 소스 코드를 제어하는것이 핵심이다.

이 브랜치 관리 전략은 기본적으로 핵심적인 성격의 가지뻗기를 통해 5개의 브랜치로 관리하자는 내용인데, 각 브랜치를 살펴보면 아래와 같다.

일단 Git-flow는 총 5가지의 브랜치 전략으로 운영을 한다. 각각을 살펴보면

master : Production 환경에 배포가 되는 메인 브랜치이다. (Git의 기본 브랜치 였는데 현재는 main 이라는 이름으로 변경되었다)
항상 배포가 나간 최신 상태를 유지한다.

develop : 개발 브랜치로써 각 개발자들의 피처들을 이곳에 머지하여 테스트 환경에 배포하는 버전이다.

feature : 주요 기능 단위로 브랜치를 생성해서 관리하다 테스트 배포 시에 develop 브랜치에 머지한다.

release : master 버전에서 파생되는 실배포본(release_날짜, release_기능명 등)으로 실제 배포된 상태이며 QA 검수나 카나리 배포에 나가는 버전이다.

hotfix : master 브랜치에서 배포 후 버그 패치가 긴급하게 필요한 경우 생성하는 브랜치이다.

보통은 develop 브랜치를 기준으로 특정한 네이밍 룰을 적용하여 브랜치를 만든 뒤 개발을 진행하게 된다.

Jira 를 사용하고 있다면 이슈 트래킹 번호와 결합하여 feature 브랜치를 생성할 수 있을 것이다.

$ git checkout develop
$ git pull
$ git checkout -b feature/ticket-[번호]-[feature 명]

작업이 완료되면 develop 브랜치에서 fetch & pull 한 후 merge 한다. (daily merge)

변경 사항 반영 후 원격 브랜치로 push 한다.

작업이 완료되면 github에 접근하여 pr 을 생성 한다. (작업 브랜치 → develop)

develop을 기준으로 테스트 Phase 배포 후 테스트 진행

테스트가 완료되면 master 에 pr을 생성 한 후 merge 되면 Stage (Stand by 장비) Phase 에 배포 하여 테스트 한다.

Stage 서버에 배포 후 테스트를 진행하고 실제 Production에 하기 위해 배포본을 만든다.

$ git checkout master
$ git tag release/REL-2023-06-01-1330  // prefix + 날짜 시간 형태의 태그 생성

배포 브랜치 - master 기준으로 release 태그를 생성한 후 배포, 원격 저장소에 생성된 태그를 push 한다.

$ git push origin release/REL-2023-06-01-1330

hotfix - master 에서 파생되어 바로 작업 후 pr 을 생성한다. (hotfix branch → master)

태그는 항상 master 브랜치에서 생성한다.

깃 플로우는 개발자들이 지키는 하나의 룰로써 작동해야 한다. 이 때 개발버전이 develop 버전과 날짜가 지남에 따라 버전 차이가 벌어지는 것이 문제가 될 수 있기 때문에, Daily merge 를 해줌으로서 지속적인 소스 병합의 버전을 유지하는것을 권장한다.

또한 깃 플로우는 rebase를 권장하지 않는다.