[Git] 프로그램 버전 관리와 코드 공유 및 협업을 위한 Git & Github에 대해 알아보자

개발자라면 반드시 Git과 Github에 대해 숙지하고 있어야 합니다.

 

회사에서 협업을 할 때에도 각자의 Branch(개발 환경)에서 각자의 업무를 담당하게 되는데요, 이제 Git과 Github에 대해 확실하게 숙지하고 가볍게 정리하는 시간을 가져보려고 합니다.

 

Git은 VCS 종류의 프로그램들 중 하나로서 프로그램 버전 관리를 위한 도구입니다. 버전 관리라고 하면 프로젝트의 시간과 차원을 관리하는 것입니다. 시간과 차원에 대한 이슈에 대해 설명드리겠습니다.

 

시간과 관련된 이슈

• 개발자들이 프로그래밍을 해서 소프트웨어를 만들 때 첫 결과물로 마무리되지 않습니다. 새 기능을 넣고 오류를 수정하고 성능을 개선하면서 계속해서 새로운 버전이 나오게 됩니다.
• 그런데, 이러한 것들을 진행하다 보면 했던 작업을 취소해야 하는 경우가 있습니다 (ver5에 추가한 기능에 결함이 생겨 vere4로 되돌아 가야 하는 경우, ver2에서 뒤늦게 작업한 내용이 잘못된 경우를 발견한 경우)

 

차원과 관련된 이슈

• 프로젝트 폴더를 복사할 필요도 없고, 압축해서 백업을 할 필요도 없이 차원을 넘나드는 것

 

Git은 마치 시간 여행을 하는 것 처럼, 프로젝트의 버전들을 언제든 되돌릴 수 있고, 여러 차원을 넘나드는 것처럼 프로젝트의 내용들을 마치 다른 폴더인 것 처럼 여러 모드를 자유롭게 전환하고 변경사항들을 쉽게 이동할 수 있게 됩니다.

 

CLI VS GUI

• CLI: 커맨드 라인 인터페이스로서 명령줄을 입력해서 사용(Git Command)
• GUI: 그래픽 유저 인터페이스로서 사용자들이 쓰기 편하도록 그래픽 요소를 활용한 인터페이스(SourceTree)

 

Git 최초 설정

git config --global user.name "(본인 이름)"

git config --global user.email "(본인 이메일)"

git config --global init.defaultBranch main

git init: Git 저장소 생성(.git)

git status: 현재 폴더 상황을 기대 관점으로 보여줌

Git이 관리하는 저장소 새로 만들기
1. .git 폴더 삭제 후 진행
2. 소스트리에 폴더를 드래그하거나, 로컬 저장소 생성

 

 Git의 관리에서 특정 파일/폴더를 배제해야 할 경우

• 포함할 필요가 없을 때
  • 자동으로 생성 또는 다운로드되는 파일들(빌드 결과물, 라이브러리)
• 포함하지 말아야 할 때
  • 보안상 민감한 정보를 담은 파일
• .gitignore 파일을 사용해서 배제할 요소들을 지정

 

프로젝트의 변경 사항들을 타임 캡슐에 담기

git status (변경사항 확인)

git add tigers.yaml (파일 하나 담기)

git add . (모든 파일 담기)

git status로 확인


타임캡슐 묻기 (커밋 메세지와 함께 작성)

git commit -m "FIRST COMMIT"

소스트리로 확인

git log

add 와 commit을 한꺼번에 

git commit -am "(메세지)" (새로 추가된(untracked) 파일이 없을 때 한정

SourceTree로 프로젝트의 변경 사항들을 확인할 수 있습니다.

 

Git에서 이전 시점으로 되돌아가는 방식

• reset: 원하는 시점으로 돌아간 뒤 이후 내역 삭제 (내역 삭제 O)
• revert: 되돌리기 원하는 시점의 커밋을 거꾸로 실행 (내역 삭제 X)

reset 사용해서 이전 커밋 단계로 돌아가기

git log

git reset --hard (돌아갈 커밋 해시, 일부분만 복사 가능)

git revert (되돌릴 커밋 해시)

-> 충돌날 경우
git rm leopards.yaml
git revert --continue
:wq로 커밋 메세지 저장

git revert --no-commit (되돌릴 커밋 해시, 커밋하지 않고 revert)

git reset --hard (해시 없는 경우 전 시점으로 복구)

 

Branch: 분기된 가지(다른 차원 및 개발 환경)

• 프로젝트 하나 이상의 모습을 관리해야 할 때
  • ex) 실배포용, 테스트 서버용, 새로운 시도용
• 여러 작업들이 각각 독립되어 진행될 때
  • ex) 신기능1, 신기능2, 코드 개선, 긴급 수정
  • 각각의 차원에서 작업한 뒤 확정된 것을 메인 차원에 통합
• 이 모든 것을 하나의 프로젝트 폴더에서 진행할 수 있도록 합니다.

// add-coach란 이름의 브랜치 생성
git branch add-coach

// 브랜치 목록 확인
git branch

// add-coach 브랜치로 이동
git switch add-coach

// 브랜치 생성과 동시에 이동하기
git switch -c new-teams = git checkout -b (새 브랜치명)

// 브랜치 삭제하기
git branch -d (삭제할 브랜치명)

// 브랜치 삭제할 때 커밋 내역이 있는 경우
git branch -D (강제 삭제할 브랜치명)

// 브랜치 이름 바꾸기
git branch -m (기존 브랜치명) (새 브랜치명)

// 결과 살펴보기
git log: 위치한 브랜치에서의 내역만 볼 수 있음

// 여러 브랜치의 내역 편리하게 보기
git log --all --decorate --oneline --graph

SourceTree에서 새로 만든 Branch 단에서의 커밋 내역 확인

이제 서로 다른 Branch들을 합치는 방식은 어떤게 있고, 각각의 방식에 대해서 설명드리겠습니다.

합치는 방식으로는 merge, rebase 두 가지가 있습니다. 

• merge: 두 브랜치를 한 커밋에 이어붙임
  • 브랜치 사용내역을 남길 필요가 있을 때 적합한 방식
  • 다른 형태의 merge에 대해서도 다룹니다.
• rebase: 브랜치를 다른 브랜치에 이어붙이는 방식
  • 한 줄로 깔끔히 정리된 내역을 유지할 때 적합
  • 이미 팀원과 공유된 커밋들에 대해서는 사용하지 않는 것이 좋습니다.

// branch 합치기 

git merge add-coach

merge는 reset으로 되돌리기 가능
- merge도 하나의 커밋
- merge 하기 전 해당 브랜치의 마지막 시점으로

병합된 브랜치는 삭제
삭제 전 소스트리에서 add-coach 위치 확인

git branch -d add-coach

//rebase로 합치기

new-teams 브랜치를 main 브랜치로 rebase
- new-teams 브랜치로 이동 (merge때와는 반대)
- 아래의 명령어로 병합

git rebase main
- 소스트리에서 상태 확인
- main 브랜치는 뒤쳐져 있는 상황

main branch로 이동 후 아래 명령어로 new-teams 시점으로 fast-forward

git merge new-teams

new-teams 브랜치 삭제

충돌 해결

// git merge <branch명> 진행시 merge가 되지 않으면,

// 당장 충돌 해결이 어려운 경우 아래 명령어로 merge 중단

git merge --abort

// 해결 가능 시 충돌 부분을 수정한 뒤 git add . , git commit으로 병합 완료

 

이제 Git이 무엇이고, 관련 명령어에 대해서도 숙지했으니, Github에 대해 알아보겠습니다. 

 

Github란?

• 개발자라면 이메일보다 더 많이 접속하게 될 서비스
• GitLab, BitBucket등 동종 존재
• 가장 널리 쓰이는 코드 공유 및 협업 서비스
• Github은 Git으로 관리하는 프로젝트들을 온라인 공간에 공유해서 프로젝트 구성원들이 함께 소프트웨어를 만들어갈 수 있도록 도와주는 서비스
• 프로젝트 내에서 같은 파일을 여럿이 수정해야 하는 상황이라면 일반적인 공유 방법으로는 어려움이 있지만, Github를 사용해서 해결
• Git 저장소는 모든 업로드의 다운로드를 커밋 단위로 주고 받습니다.
• 어떤 A라는 사람이 코드를 짜고 커밋을 해서 버전을 만들고 업로드를 하면 Github 상의 프로젝트는 최신화가 됩니다.

현재 학과 프로젝트도 코드 공유 및 협업 서비스를 제공해주는 Github를 활용하여 진행하고 있습니다. 협업을 원활하게 할 수 있는 개발자가 되기 위해선, 이보다 더 깊이 있게 알아야 된다고 생각합니다. 이상으로 Git & Github에 관한 포스팅을 마치도록 하겠습니다. 

 

<참고자료>

https://www.youtube.com/watch?v=1I3hMwQU6GU