Git and Github

Git

Git은 분산형 버전 관리 시스템으로 소스코드 기록을 관리하고 추적할수 있는 버전 관리 시스템이다. Git의 핵심 기능으로는 버전관리, 협업, 백업이 있다.

 

 

Github

깃을 이용하여 Repository를 관리할수 있는 클라우드 기반 서비스로 소스코드를 백업하거나 공유하는데 주로 쓰인다.

 

Fork를 통해 다른사용자의 Github의 이미 생성된 Repo(Repository)를 자신의 Github의 Repo로 복사하여 작업할수 있으며 

Pull Request를 통하여 메인 Repo의 관리자에게 자신의 Repo의 내용물을 병합해달라고 요청할수 있다.

 

 

Git의 영역

깃의 영역은 총 3단계이며 각각 Work space, Staging area, Local repository이다. 

처음 폴더나 파일이 만들어진 후 commit을 해야 Work space로 이동한다.

• Work space - 제일 기본인 상태이다. commit 이후 어떠한 행동도 하지 않은 상태의 파일들이 존재하는 영역이며 git add를 통해서 파일 혹은 폴더를 staging area로 보낸다.
• Staging area - 로컬 repo로 가기전의 중간 장소로 git commit으로 로컬 repo로 파일을 보낸다.
• Local repository - 로컬 안에서는 파일의 최종 목적지이다. 파일이 여기까지 도달했다면 파일의 버전이 기록되며 만약 새로운 파일이 추가되었다면 이때부터 비로소 생성된 파일이 추적상태(tracked)가 된다. 이후 git push를 통해 원격 repo로 이동하게 된다.

 

 

Git status

Git의 영역과는 다른, 상태의 정보를 나타낸다.

• Tracked(추적상태) - 새로운 파일 및 폴더는 commit이후에 추적상태가되며 추적상태인 파일 및 폴더는 수정되었을때 Git이 변경내용을 감지하며 추적상태에 따라 또 3가지의 상태로 나뉜다.
  • Unmodified - 파일의 수정이 Git에 의해 감지되지 않은 상태
  • Modified - 파일의 수정이 Git에 의해 감지된 상태
  • Stage - git add 명령어를 이용하여 Modified 상태인 파일을 Staging area로 옮겨진 상태
• Untracked(비추적상태) - 파일 및 폴더가 최초 생성된후 commit과정을 거치지 못한 상태이며 commit과정을 거처 Tracked 상태로 변경해주어야함

 

 

Git 명령어

기본명령어

git init : 현재 위치에 깃 생성

git remote add [깃에서 사용할 이름] [Github url] : 생성된 Git을 Github 원격 repo에 연결 ex) git remote add origin https~

git clone [Github url] : 이미 Github 원격 repo에 저장된 소스코드를 다운받음

git remote -v : 현재 연결된 원격 repo 확인

git add [file name] : 수정된 파일을 Staging area로 옮김

git commit -m "[message]" : staging area에 있는 파일들 Local repository로 옮김

git commit -am "[message]" : 수정된 파일이 커밋을 한번이라도 했었다면 (tracked 상태) add와 커밋을 한번에가능

git push [Git에서 사용될 이름] [브랜치명] : 로컬 repo에 수정된 파일들 원격 repo 브랜치에 업로드,

                                                                       ex) git push origin main(master)

git pull [Git에서 사용될 이름] [브랜치명] :  원격 repo 브랜치에서 로컬 repo로 다운로드, ex) git pull origin main(master)

 

 

현재 깃의 상태 및 로그 출력

git status : 현재 수정된 파일등의 상태를 볼수있으며 다음 행동을 위한 명령어 정보도 제공

git log : commit된 로그 출력 

git log --oneline : commit된 로그 간략히 출력

 

 

깃의 영역 및 이전 작업 복구

git checkout -- [file] : 수정된 파일을 수정전으로 복구

git reset HEAD file :  staging 에서 work space로 이동

git reset --hard HEAD^ : 최신 커밋을 삭제하고 이전의 커밋을 최신커밋으로 바꿔줌

 

 

브랜치 관리

git branch [branch name] : 새로운 브랜치 생성
git checkout [branch name] : 해당 브랜치로 이동
git checkout -b [branch name] : 새로운 브랜치를 생성하고 이동을 한번에

git merge [병합될 branch name] : (메인이 될 브랜치로 이동후 커맨드 입력), 브랜치 병합

 

 

git log 정보

HEAD - 최신 repo 

main - 현재 로컬 repo의 해당 브랜치에 commit이 저장되있음

origin/main - origin의 키워드를 가진 깃이 원격 repo의 main에 저장되있음

origin/HEAD - 최신 repo가 origin 키워드의 깃에 저장되있음

 

병합충돌

깃헙을 통해 협업을 하다보면 동일한 파일의 동일한 위치를 서로 수정해줫을때 일어난다.
pull한 파일이 충돌이 일어낫을때 발견한쪽 혹은 다른한쪽에서 수정후 커밋과 push
다른한쪽은 그냥 pull해주어 수정이 필요하면 수정을 해준뒤 커밋과 push

 

 

 

Git과 Github 작업 순서

1. Git 생성
   1. git init 이후 git remote add [깃에서 사용할 이름] [Github url], (협업을 한다면 git remote add를 통해 상대방의 깃허브도 등록), ex) git remote add origin (url), git remote add pair(url)
   2. 또는 깃헙에서 전체 프로젝트 repo를 fork 한뒤, git clone [깃헙 url] (협업을 한다면 git remote add를 통해 상대방의 깃허브도 등록)
2. 파일 수정후 로컬 repo로 커밋 - git add [파일명] 이후 git commit -m "[메세지]"
3. 로컬 repo를 원격 repo로 업로드 - git push [깃에 등록된 이름] [브랜치명], ex) git push origin main
4. 협업을 한다면 상대방의 repo 풀링 - git pull [깃에 등록된 이름] [브랜치명], ex) git pull origin main 
5. 2번~4번을 반복후 코드가 완성되면 깃헙에서 pull request