깃허브 가입 및 설치
깃허브는 명령행 인터페이스 프로그램과 깃허브 웹사이트를 통해 형상 관리를 지원한다.
깃허브 사용을 위해 다음 링크 클릭해 가입하고, 깃허브 프로그램을 설치한다.
- github.com 가입
- git 설치 (윈도우 버전 설치)
형상관리는 소프트웨어나 문서의 변경사항을 체계적으로 추적 관리하는 것이다. 깃은 형상관리 플랫폼이다. 다음 그림은 새 소스파일을 생성해 깃(git) 저장소에 저장하고 협업하는 과정을 보여준다. git은 크게 4개 git 관리 파일 DB를 가진다. git은 각 DB들을 갱신하며 파일 형상을 관리한다.
- workspace: 컴퓨터 로컬 작업 폴더
- staging: 컴퓨터 로컬 폴더 내 파일 인덱스 DB
- local repository: 컴퓨터 로컬 폴더 내 파일 저장소
- remote repository: 협업용 원격 깃 저장소
git process(Diego C Martin)
깃 프로세스는 다음과 같다. 이 과정에서 파일이 추가, 변경, 삭제된 이력과 내용은 모두 깃허브에 기록된다. 이를 통해, 파일 내용을 특정 버전으로 되돌리거나(roll back), 다른 사람이 만든 파일과 병합(merge)하는 형상관리가 가능해진다. 앞의 그림은 이 과정을 잘 보여준다.
- 로컬 폴더 생성: 프로젝트 파일이 저장될 폴더를 생성한다.
- 깃 저장소 생성: 온라인 협업 작업을 위한 원격 작업할 깃 저장소를 생성한다.
- 로컬과 깃 저장소 연동: 원격 협업 작업을 위해 깃 저장소 연동 정보를 생성한다.
- 파일 생성 및 깃 저장소 추가(add): 파일 작업 후 해당 파일을 로컬 폴더 인덱스에 추가한다.
- 파일 커밋(commit)/푸시(push): 작업한 파일들을 커밋해 깃 저장소에 추가하고, 실제 파일 내용을 푸시하여 깃 저장소에 저장한다.
- 로컬 폴더 파일 갱신(PULL): 다른 사람들이 푸시한 깃 저장소 최신 버전 파일들을 로컬 폴더에 다운로드 받아 동기화한다.
깃은 형상관리를 위해, 로컬 폴더에 .git 이란 이름의 캐쉬 폴더를 관리한다. push하였을 때, 이 폴더에 있는 파일이 stage에 있는 파일로 취급되어, 리모트 서버에 업로드된다. 같은 이름의 파일이 서로 다르다면, 병합을 진행하는 데, 이 경우, 충돌이 발생된다면, 에러가 나므로, 사용에 주의해야 한다.
주요 사용 명령 예시
주로 다음과 같은 명령을 사용하게 된다.
git status
git add *.*
git commit -m 'update version'
git push origin main
git pull origin main
git은 소스코드를 push할때 리모트에 같은 소스의 수정본이 있다면, merge를 하려 시도하다가 충돌(conflict)이 발생할 수 있다(참고). 만약, 임시로 로컬에 생성되는 파일이나 폴더라면, 다음과 같이 .gitignore 파일을 만들어 merge를 피할 수 있다.
.gitignore
input/
output/
머지를 무조건 취소하려면 다음 명령을 입력한다.
git merge --abort
git reset --merge
git rm -r --cached .
이런 저런 시도를 해도 깃이 꼬일 경우, 작업한 파일만 백업해 놓은 후, git clone, git init로 초기화해서 다시 시작하는 것이 편하다.
git clone
git init
깃허브 로긴 후 개발 프로젝트 폴더에 해당하는 저장소(repository)를 생성한다.
- Repository 생성. README 생성 옵션은 체크하지 않음
- 로컬에 개발 폴더 생성
- 로컬 개발 폴더 내에 source.py 파일 생성 및 내용 입력
- git init 로 로컬 폴더 git 설정
- git add source.py 로 파일 인덱스를 추가함
- git commit -m "source.py" 로 파일 정보를 github에 저장
- git status 로 상태 확인
- 저장소 주소를 다음과 같이 이름과 연결. 주소와 이름은 적절히 수정할 것.
git remote add remoteName https://github.com/username/repositoryName
- git push remoteName master 로 현재 커밋 파일을 저장소에 저장
git push 시 아이디 및 암호 입력 화면
git push 화면
다시 source.py를 수정하하면, 다음 과정을 다시 거쳐야 한다.- git add source.py
- git commit -m "source.py"
만약, 로컬 작업 저장소 파일들을 git 저장소 파일들로 덮어쓸려면 다음 명령을 수행한다.
- git fetch --all
- git reset --hard origin/master
브랜치는 일정 기간 동안만 유지되는 개발 시 사용한다. 브랜치 사용법은 다음과 같다.
- git branch 로 브랜치 목록 보기
- git branch sub1 브랜치 만들기
- git checkout sub1 로컬 저장소의 브랜치 전환
- git branch
- git add source.py
- git commit -m "source.py"
- git push remoteName sub1
- git checkout sub1
- git pull
브랜치 병합은 다음과 같다.
- git checkout master 로컬 저장소 브랜치 전환
- git merge sub1 병합
- git push remoteName master 저장
브랜치 삭제는 다음과 같다.
- git branch -d sub1
- git branch
Rollback 하기
현재 파일을 수정하다, 깃 저장소에 최신 파일로 되돌리고 싶을 때 다음 명령어를 사용한다.
- git reset --hard {commit번호} : 특정 커밋으로 되돌리고, 이후 버전은 히스토리에서 삭제됨
- git reverse {commit번호}: 특정 커밋으로 되돌리고, 이후 버전 이력은 히스토리에 남아 있음
- git checkout . : 로컬 작업 폴더에서 수정한 모든 파일을 git add 이전의 현재 버전으로 되돌림
오픈소스 기여하기
특정 오픈소스에 기여하는 방법은 다음과 같다.
1. 해당 오픈소스 github의 fork 메뉴를 클릭한다.
2. fork 된 프로젝트는 나의 github 저장소에 복사된다.
3. 해당 github를 clone한다.
4. 로컬에서 작업한 후, add, commit, push 한다.
5. fork 된 github에 PR (pull request) 메뉴를 클릭하여, 원 개발자가 fork된 프로젝트의 수정 소스를 병합하도록 요청한다. 이때 수정 내용을 자세히 기술해 놓는다.
다음은 이를 보여주는 순서도이다.
상세한 메뉴얼은 다음을 참고한다.
깃허브 에러 대처 방법
git 진행 시 에러는 다음과 같이 해결한다.
- Updates were rejected because the remote contains work that you do not have locally: 저장소 생성 시 README를 체크하지 말거나, git pull 로 해결. 예) git pull origin master
- Updates were rejected because the tip of your current branch is behind: git pull 할 때 --allow-unrelated-histories 옵션을 추가.
git 에러 화면 예시
깃 주요 명령어 요약
앞에서 사용한 깃 주요 명령어는 다음과 같다.
git init : git 생성
git clone git_URL : 깃 저장소에서 파일들 다운로드
git checkout branch_name : 브랜치 선택
git checkout -t remote_path/branch_name : 원격 브랜치 선택
git branch branch_name : 브랜치 생성
git branch -r : 원격 브랜치 목록보기
git branch -a : 로컬 브랜치 목록보기
git branch -m branch_name change_branch_name : 브랜치 이름 바꾸기
git branch -d branch_name : 브랜치 삭제
git push remote_name - delete branch_name : 원격 브랜치 삭제하기
git add file_path : 수정한 코드 선택
git commit -m “commit_description” : 선택한 코드 설명 입력 ( git commit -m “내용”)
git push romote_name branch_name : add 후 commit 코드 git server에 전송 (git push origin master)
git pull : git서버에서 파일 다운로드 후 merge
git fetch : git서버에서 최신 파일 다운로드
git reset --hard HEAD^ : commit한 이전 파일 취소
git reset --merge : merge 취소
git reset --hard HEAD && git pull : git 파일 강제 모두 다운로드
git config --global user.name “user_name ” : git 계정 Name 변경
git config --global user.email “user_email” : git 계정 Mail 변경
1. 개요
GitHub는 다수의 개발자가 협업하여 하나의 소프트웨어를 개발할 수 있도록 지원하는 분산형 버전 관리 시스템이다. 각 개발자는 원격 저장소를 기반으로 자신의 로컬 환경에서 독립적으로 작업하며, 변경 사항을 병합하여 하나의 일관된 프로젝트를 유지한다. 이 문서는 다중 개발자 협업을 위한 GitHub의 기본 개념, 명령어의 역할, 그리고 실무적 절차를 체계적으로 기술한 것이다.
2. 주요 개념
2.1 Repository
Repository는 코드와 관련 이력을 저장하는 기본 단위이다. 원격 저장소(Remote Repository)는 GitHub 서버에 위치하며, 로컬 저장소(Local Repository)는 개발자 개인의 컴퓨터에 존재한다.
2.2 Fork
Fork는 원본 저장소를 복제하여 개인 계정에 새로운 저장소를 생성하는 기능이다. 공동 개발자는 Fork를 통해 원본 코드에 직접 접근하지 않고, 독립적인 환경에서 자유롭게 개발할 수 있다. Fork된 저장소는 원본과 연결되어 있어 필요 시 원본의 변경 사항을 가져올 수 있다.
2.3 Remote
Remote는 원격 저장소의 주소 정보를 저장하는 이름이다. 일반적으로 개인 저장소는 origin, 원본 프로젝트는 upstream으로 등록한다.
origin: 개인의 Fork 저장소
upstream: 원본 저장소
2.4 Branch
Branch는 독립적인 개발 흐름을 분리하기 위한 구조이다. 새로운 기능 개발, 실험, 버그 수정 등은 main 브랜치로부터 새로운 브랜치를 생성하여 진행한다.
2.5 Fetch
Fetch는 원격 저장소의 최신 커밋 정보를 로컬 저장소로 가져오는 명령이다. Fetch는 코드 병합을 수행하지 않으며, 원격의 변경 사항을 단순히 조회하고 비교할 수 있도록 한다.
2.6 Checkout
Checkout은 특정 브랜치나 커밋으로 작업 환경을 전환하는 명령이다. 브랜치를 이동하거나 새로 생성할 수 있으며, 명령 실행 시 작업 디렉터리의 파일이 해당 브랜치의 상태로 변경된다.
예시
git checkout -b feature-login
은 새로운 feature-login 브랜치를 만들고 그 브랜치로 이동한다.
2.7 Merge
Merge는 하나의 브랜치에서 발생한 변경 사항을 다른 브랜치로 통합하는 명령이다. 보통 기능이 완성된 후 main 브랜치로 병합하며, 충돌(conflict)이 발생할 경우 수동으로 해결한다.
2.8 Pull
Pull은 원격 저장소의 변경 사항을 로컬로 가져오고, 자동으로 병합하는 명령이다. 내부적으로 fetch와 merge를 순차적으로 수행한다. 협업 중에는 pull 대신 fetch 후 수동으로 merge하는 방식이 안전하다.
2.9 Push
Push는 로컬에서 수행한 변경 사항을 원격 저장소에 반영하는 명령이다. 일반적으로 origin 저장소에 푸시하며, upstream에는 직접 푸시하지 않는다.
2.10 Pull Request
Pull Request는 개인 Fork 또는 브랜치의 변경 내용을 원본 저장소에 반영하도록 요청하는 과정이다. 다른 개발자가 코드를 검토(review)하고 승인하면 main 브랜치에 병합된다.
3. 협업 절차
3.1 원본 저장소 복제
원본 저장소를 Fork하여 개인 계정으로 복제한다. Fork된 저장소를 로컬에 Clone한다.
git clone https://github.com/username/test.git
3.2 원본 저장소 연결
Fork된 저장소에는 기본적으로 origin만 존재한다. 원본 저장소를 upstream으로 등록한다.
git remote add upstream https://github.com/original-owner/test.git
git remote -v
3.3 원본 코드 동기화
원본 저장소가 갱신되면 다음 명령으로 최신 내용을 가져온다.
git fetch upstream
git checkout main
git merge upstream/main
GitHub는 다수의 개발자가 협업하여 하나의 소프트웨어를 개발할 수 있도록 지원하는 분산형 버전 관리 시스템이다. 각 개발자는 원격 저장소를 기반으로 자신의 로컬 환경에서 독립적으로 작업하며, 변경 사항을 병합하여 하나의 일관된 프로젝트를 유지한다. 이 문서는 다중 개발자 협업을 위한 GitHub의 기본 개념, 명령어의 역할, 그리고 실무적 절차를 체계적으로 기술한 것이다.
2. 주요 개념
2.1 Repository
Repository는 코드와 관련 이력을 저장하는 기본 단위이다. 원격 저장소(Remote Repository)는 GitHub 서버에 위치하며, 로컬 저장소(Local Repository)는 개발자 개인의 컴퓨터에 존재한다.
2.2 Fork
Fork는 원본 저장소를 복제하여 개인 계정에 새로운 저장소를 생성하는 기능이다. 공동 개발자는 Fork를 통해 원본 코드에 직접 접근하지 않고, 독립적인 환경에서 자유롭게 개발할 수 있다. Fork된 저장소는 원본과 연결되어 있어 필요 시 원본의 변경 사항을 가져올 수 있다.
2.3 Remote
Remote는 원격 저장소의 주소 정보를 저장하는 이름이다. 일반적으로 개인 저장소는 origin, 원본 프로젝트는 upstream으로 등록한다.
origin: 개인의 Fork 저장소
upstream: 원본 저장소
2.4 Branch
Branch는 독립적인 개발 흐름을 분리하기 위한 구조이다. 새로운 기능 개발, 실험, 버그 수정 등은 main 브랜치로부터 새로운 브랜치를 생성하여 진행한다.
2.5 Fetch
Fetch는 원격 저장소의 최신 커밋 정보를 로컬 저장소로 가져오는 명령이다. Fetch는 코드 병합을 수행하지 않으며, 원격의 변경 사항을 단순히 조회하고 비교할 수 있도록 한다.
2.6 Checkout
Checkout은 특정 브랜치나 커밋으로 작업 환경을 전환하는 명령이다. 브랜치를 이동하거나 새로 생성할 수 있으며, 명령 실행 시 작업 디렉터리의 파일이 해당 브랜치의 상태로 변경된다.
예시
git checkout -b feature-login
은 새로운 feature-login 브랜치를 만들고 그 브랜치로 이동한다.
2.7 Merge
Merge는 하나의 브랜치에서 발생한 변경 사항을 다른 브랜치로 통합하는 명령이다. 보통 기능이 완성된 후 main 브랜치로 병합하며, 충돌(conflict)이 발생할 경우 수동으로 해결한다.
2.8 Pull
Pull은 원격 저장소의 변경 사항을 로컬로 가져오고, 자동으로 병합하는 명령이다. 내부적으로 fetch와 merge를 순차적으로 수행한다. 협업 중에는 pull 대신 fetch 후 수동으로 merge하는 방식이 안전하다.
2.9 Push
Push는 로컬에서 수행한 변경 사항을 원격 저장소에 반영하는 명령이다. 일반적으로 origin 저장소에 푸시하며, upstream에는 직접 푸시하지 않는다.
2.10 Pull Request
Pull Request는 개인 Fork 또는 브랜치의 변경 내용을 원본 저장소에 반영하도록 요청하는 과정이다. 다른 개발자가 코드를 검토(review)하고 승인하면 main 브랜치에 병합된다.
3. 협업 절차
3.1 원본 저장소 복제
원본 저장소를 Fork하여 개인 계정으로 복제한다. Fork된 저장소를 로컬에 Clone한다.
git clone https://github.com/username/test.git
3.2 원본 저장소 연결
Fork된 저장소에는 기본적으로 origin만 존재한다. 원본 저장소를 upstream으로 등록한다.
git remote add upstream https://github.com/original-owner/test.git
git remote -v
3.3 원본 코드 동기화
원본 저장소가 갱신되면 다음 명령으로 최신 내용을 가져온다.
git fetch upstream
git checkout main
git merge upstream/main
이후, 현재 로컬 코드 파일들을 지정된 깃허브 저장소에 업로드 업데이트한다.
git push origin main
3.4 브랜치 생성 및 개발
만약, 새로운 기능 개발이나 위험이 있는 코드는 별도의 브랜치에서 수행한다.
git checkout -b feature-login
이후 변경 사항을 저장하고 커밋한다.
git add .
git commit -m "Add login feature"
3.5 개인 저장소로 푸시 및 Pull Request 생성
git push origin feature-login
GitHub 웹 페이지에서 Pull Request를 생성하여 원본 저장소에 변경 사항 반영을 요청한다.
4. 충돌 관리
병합 과정에서 동일 파일의 동일 부분을 여러 개발자가 수정한 경우 충돌이 발생한다. 충돌이 표시된 파일을 직접 수정하고 다음 명령으로 병합을 완료한다.
git add .
git commit
충돌 해결 후 다시 푸시하면 Pull Request가 갱신된다.
5. 브랜치 관리 전략
5.1 Main Branch
프로젝트의 안정적인 코드를 유지하는 중심 브랜치이다. 테스트를 완료한 코드만 병합한다.
5.2 Feature Branch
새로운 기능 개발을 위한 임시 브랜치이다. 기능 개발이 완료되면 main으로 병합하고 삭제한다.
5.3 Hotfix Branch
배포 후 발견된 긴급 오류를 수정하기 위한 브랜치이다. 수정 후 main과 release 브랜치 모두에 병합한다.
6. 개발자 간 협업 순서 예시
6.1 초기 개발 단계
프로젝트가 시작될 때 모든 개발자는 main 브랜치에서 코드를 공유한다. 초기 환경 설정, 폴더 구조, 빌드 설정 등은 main 브랜치에서 직접 관리한다.
6.2 기능 개발 단계
특정 기능이 추가되거나 위험 요소가 있는 코드는 main에서 직접 수정하지 않고 브랜치를 분리하여 개발한다. 예시 절차는 다음과 같다.
개발자는 main 브랜치에서 최신 코드를 동기화한다.
git fetch upstream
git checkout main
git merge upstream/main
새 기능을 위한 브랜치를 생성한다.
git checkout -b feature-payment
feature-payment 브랜치에서 기능을 구현하고 커밋한다.
git add .
git commit -m "Implement payment system"
모든 기능 구현 후 테스트를 진행한다. 테스트가 완료되면 origin으로 푸시한다.
git push origin feature-payment
GitHub에서 Pull Request를 생성하여 코드 리뷰를 요청한다.
6.3 코드 리뷰 및 병합 단계
다른 개발자들은 Pull Request를 검토하고 수정이 필요하면 댓글을 남긴다. 모든 검토가 끝나면 main 브랜치로 병합된다. 병합 후 개발자는 자신의 로컬 저장소에서 main을 다시 최신 상태로 맞춘다.
git checkout main
git pull upstream main
6.4 유지보수 및 핫픽스 단계
배포 후 버그가 발견되면 hotfix 브랜치를 생성하여 문제를 수정한다.
git checkout -b hotfix-login-bug
수정 후 테스트가 완료되면 main에 병합하고 브랜치를 삭제한다.
git checkout main
git merge hotfix-login-bug
git push origin main
git branch -d hotfix-login-bug
7. 권장 워크플로우
main 브랜치는 항상 배포 가능한 상태로 유지한다.
새로운 기능은 반드시 별도의 브랜치에서 개발한다. 작업 전에는 upstream에서 fetch를 통해 최신 코드를 반영한다. Pull Request를 통해 코드 리뷰를 수행하고 병합한다. 병합 후 브랜치는 삭제하여 관리 복잡도를 줄인다. 충돌 발생 시 즉시 해결하고 커밋을 정리한다.
8. 결론
GitHub는 다중 개발자가 동시에 안전하게 개발할 수 있는 환경을 제공한다. Fork, Branch, Fetch, Checkout, Merge, Pull Request 등의 기능을 올바르게 활용하면 협업 과정의 효율성과 안정성이 향상된다. 특히 위험이 있는 기능이나 테스트가 필요한 코드는 별도의 브랜치에서 관리하여 main 브랜치의 안정성을 보장해야 한다. 명확한 브랜치 전략과 주기적인 동기화는 공동 프로젝트의 품질을 유지하는 핵심 요소이다.
git push origin main
3.4 브랜치 생성 및 개발
만약, 새로운 기능 개발이나 위험이 있는 코드는 별도의 브랜치에서 수행한다.
git checkout -b feature-login
이후 변경 사항을 저장하고 커밋한다.
git add .
git commit -m "Add login feature"
3.5 개인 저장소로 푸시 및 Pull Request 생성
git push origin feature-login
GitHub 웹 페이지에서 Pull Request를 생성하여 원본 저장소에 변경 사항 반영을 요청한다.
4. 충돌 관리
병합 과정에서 동일 파일의 동일 부분을 여러 개발자가 수정한 경우 충돌이 발생한다. 충돌이 표시된 파일을 직접 수정하고 다음 명령으로 병합을 완료한다.
git add .
git commit
충돌 해결 후 다시 푸시하면 Pull Request가 갱신된다.
5. 브랜치 관리 전략
5.1 Main Branch
프로젝트의 안정적인 코드를 유지하는 중심 브랜치이다. 테스트를 완료한 코드만 병합한다.
5.2 Feature Branch
새로운 기능 개발을 위한 임시 브랜치이다. 기능 개발이 완료되면 main으로 병합하고 삭제한다.
5.3 Hotfix Branch
배포 후 발견된 긴급 오류를 수정하기 위한 브랜치이다. 수정 후 main과 release 브랜치 모두에 병합한다.
6. 개발자 간 협업 순서 예시
6.1 초기 개발 단계
프로젝트가 시작될 때 모든 개발자는 main 브랜치에서 코드를 공유한다. 초기 환경 설정, 폴더 구조, 빌드 설정 등은 main 브랜치에서 직접 관리한다.
6.2 기능 개발 단계
특정 기능이 추가되거나 위험 요소가 있는 코드는 main에서 직접 수정하지 않고 브랜치를 분리하여 개발한다. 예시 절차는 다음과 같다.
개발자는 main 브랜치에서 최신 코드를 동기화한다.
git fetch upstream
git checkout main
git merge upstream/main
새 기능을 위한 브랜치를 생성한다.
git checkout -b feature-payment
feature-payment 브랜치에서 기능을 구현하고 커밋한다.
git add .
git commit -m "Implement payment system"
모든 기능 구현 후 테스트를 진행한다. 테스트가 완료되면 origin으로 푸시한다.
git push origin feature-payment
GitHub에서 Pull Request를 생성하여 코드 리뷰를 요청한다.
6.3 코드 리뷰 및 병합 단계
다른 개발자들은 Pull Request를 검토하고 수정이 필요하면 댓글을 남긴다. 모든 검토가 끝나면 main 브랜치로 병합된다. 병합 후 개발자는 자신의 로컬 저장소에서 main을 다시 최신 상태로 맞춘다.
git checkout main
git pull upstream main
6.4 유지보수 및 핫픽스 단계
배포 후 버그가 발견되면 hotfix 브랜치를 생성하여 문제를 수정한다.
git checkout -b hotfix-login-bug
수정 후 테스트가 완료되면 main에 병합하고 브랜치를 삭제한다.
git checkout main
git merge hotfix-login-bug
git push origin main
git branch -d hotfix-login-bug
7. 권장 워크플로우
main 브랜치는 항상 배포 가능한 상태로 유지한다.
새로운 기능은 반드시 별도의 브랜치에서 개발한다. 작업 전에는 upstream에서 fetch를 통해 최신 코드를 반영한다. Pull Request를 통해 코드 리뷰를 수행하고 병합한다. 병합 후 브랜치는 삭제하여 관리 복잡도를 줄인다. 충돌 발생 시 즉시 해결하고 커밋을 정리한다.
8. 결론
GitHub는 다중 개발자가 동시에 안전하게 개발할 수 있는 환경을 제공한다. Fork, Branch, Fetch, Checkout, Merge, Pull Request 등의 기능을 올바르게 활용하면 협업 과정의 효율성과 안정성이 향상된다. 특히 위험이 있는 기능이나 테스트가 필요한 코드는 별도의 브랜치에서 관리하여 main 브랜치의 안정성을 보장해야 한다. 명확한 브랜치 전략과 주기적인 동기화는 공동 프로젝트의 품질을 유지하는 핵심 요소이다.
댓글 없음:
댓글 쓰기