1. Git & Github 개념
- Git은 VCS (Version Control System) 입니다. 여기서 version은 소스코드(sourcecode) 파일의 version을 뜻하니다. 즉 소스코드(soruce code)의 변경사항 내역을 관리하는 시스템입니다.
- Github는 개발자간의 협업을 위해 중앙 서버 역할을 하는 서비스입니다. 협업을 위한 code review, documentation 생성 및 관리 등 개발 프로젝트 운영에 필요한 여러 가지 기능을 제공합니다.
2. Git 명령어
1) 주요 명령어
> git init # git 시작하기
> git add . 혹은 대상파일 # git staged 상태로 옮기기
> git commit # commit 하기
> git diff # Modified된 수정사항 확인
> git status # 어떤 파일이 modified, 어떤 파일이 staged되었는지 전체상황 보여줌
> git log # commit한 히스토리 보여줌
> git rm # 원하는 파일 git repo에서 삭제
> git mv # 원하는 파일 git repor로 이동
> git remote remove origin # 기존에 연동된 레포지토리 연결 끊기2) 작업 순서별 명령어 목록
> git remote add origin (repositoy url) # 리모트 repository로 연결
> git remote -v # 연결된 github 확인
> git branch feature/이름 # 브랜치 생성
> git checkout feature/이름 # 브랜치로 이동
> git add . # 해당 브랜치에서 모든 변화내역 담기
> git status # staging된 상태면 변화내역 알려줌
> git commit (-m "message")
> git status # git하고 나면 변화내역이 나오지 않음. 이미 깃했기 때문에
> git push origin feature/이름 # 로컬에서 작업한 브랜치 작업을 github로 푸쉬
> git pull origin master # 리모트 마스터 파일 다운로드
> (branch 이동후) git merge masterQ) 왜 remote master에서 master 파일을 받은 후 신규 브랜치에 merge해 줘야 하는가?
- 우리가 브랜치를 만들어서 작업을 하고 푸쉬를 한다는 것은 해당 브랜치에서 작업한 변동내역이 remote master로 전달되는 것이다. (전체 코드가 업데이트되는 것이 아니다)
- 이렇게 여러 사람이 작업한 것들이 푸쉬가 되고 merge가 된 전체 코드의 최신 버전은 remote master에서 계속 업데이트가 된다. 따라서 이후 충돌을 방지하기 위해 다른 사람이 작업한 버전까지 반영된 remote master를 받아서, 다시 작업을 이어 가면 코드의 큰 충돌 없이 프로젝트를 진행할 수가 있다.
Q) 현재 잘못된 브랜치/마스터에서 작업하고 있어서 새로운 브랜치 열어서 하고 싶을 때는 어떻게 하나?
git checkout -b "final_fix"
# 현재 작업한 내역들을 final_fix란 브랜치를 만들어서 그곳으로 옮김Q) 현재 브랜치명을 변경하고 싶을 경우는?
> git branch -m Old_branch_name New_branch_name
# Old_branch와 New_branch 2개가 존재함
> git push origin :Old_branch_name # Old_branch 제거
> git branch # 확인하기3. 프로젝트 위한 Git/Github 이용법
1) 프로젝트 진행시 Git 사용 Flow
2) 프로젝트 진행 시 주의사항
- 작업자끼리 작업 영역(앱 단위, 파일 단위)을 명확히 해서 사전에 코드 충돌날 일을 막자
- 현재 내가 어디에서 작업하고 있는지, 마스터는 어떤 상태인지 체크하면서 일하자
4. Git rebase
1) rebase란?
rebase란 feature branch에서 작업하는 동안 (다른 개발자가 작업한 결과들이 합쳐져) 최신화된 origin master를 받아서, 나의 feature branch의 기준점을 바꿔주는 작업이다.
merge 방식은 origin master와 feature branch를 합쳐주는 것이었다면, rebase 방식은 기준점을 바꾼 상태에서 이후 나의 commit들을 합쳐주는 것이기 때문에 merge commit이 따로 남지 않아 단순한 history를 유지할 수 있다.
이 덕분에 우리는 커밋 상태를 일직선으로 파악할 수 있고, 히스토리 지점이 브랜치로 분산되어 있지 않기 때문에 이후에 roll-back하는 지점이 명확해서 roll-back이 쉽다.
[merge하는 경우]
[rebase하는 경우]
- 이미지 출처 : https://im-developer.tistory.com/182
- 이미지 외에 설명도 상세하게 잘 되어 있으니, merge와 rebase가 더 궁금한 분들은 위의 블로그를 참조해 주세요.
하지만 내가 커밋을 여러 번 했을 때 rebase에서 충돌상황이 발생하면 여러 번의 커밋들의 충돌상황을 일일이 해결해 줘야 한다는 단점이 있습니다.
2) 사용방법
git pull origin master해서 마스터를 최신화한 후에, git rebase를 진행하면 된다. 마스터에서 진행해도 되고, 해당 브랜치에서 실행을 해도 된다.
> git rebase -i master feature/branch # 마스터에서 실행 (기준 => 적용할 브랜치)
> git rebase -i master # 해당브랜치에서 실행
* 충돌 해결하라는 에러 메세지가 표시되면,
# 파일 수정 및 충돌 해결
> git add . # commit은 하지 않음
> git rebase --continue
# interactive 화면에서 pick and squash, commit message 작성 실행
> git push origin feature/branch -f # -f는 force로서 수정해서 다시 푸쉬할 때 필요함- Commit이 여러 개일 경우, 첫 번째는 Pick으로 그대로 두고, 나머지 것들은 squash(s)를 선택해서 commit이 1개로 합쳐지도록 한다.
- 충돌이 나면 여러 개의 commit들의 충돌을 다 해결한 뒤 git rebase를 진행한다.
- 충돌이 일어난 후 rebase를 진행할 경우, 꼭 master를 최신화한다.
- 충돌 해결 중의 커밋 메시지는 WIP와 같이 임의로 지정하고 final 커밋할 때 제대로 된 커밋 메시지를 남긴다.
git rebase --continue # 계속 진행
git rebase --abort # 이전 건 취소실제 충돌 사례 해결 케이스 보러 가기 : https://velog.io/@rosewwross/git-rebase
5. Git 되돌리기
[참고 링크]
(문제 요약)
master가 아닌 branch에서 git pull origin master 한 뒤 rebase를 완료해 버림. rebase하기 전 단계로 회귀할 필요가 있었음
# Git 내역보기 : merge, rebase, commit, pull, push 등
> tig
# Git 내역 되돌리고자 하는 커밋의 HEAD 확인
> git reflog (브랜치명)
# 되돌리고자 하는 시점으로 Git 되돌리기
> git reset --hard 1c64000위 작업하기 전에 코드를 백업해 놓은 뒤 제대로 다 되돌려 졌는지 확인하고, 그 다음부터 다시 작업해놓은 코드를 복사해서 커밋하고 다음 작업들을 이어나가면 됨
