Git은 소스코드의 버전을 관리해주는 시스템이다.
대학교에서 ppt를 만들 때, 여러차례 수정을 가해본 적이 있을 것이다. 작업이 완전히 끝나면 우리 바탕화면에는 '최종', '진짜최종', '이게진짜' 등의 다양한 버전의 ppt가 남는 경험을 해봤을 것이다.
git은 이런 수정사항에 대한 버전을 따로 파일로 만들지 않고 버전화 하여 관리해주는 편리한 시스템이다.
깃은 왜편한가?
깃이 단순히 소스코드의 버전만 관리를 해줬다면 다른 대안이 많을 것이다.
하지만 깃은 버전컨트롤 그 이상 핵심적인 기능인 협업의 편의성을 제공한다.
깃은 왜 협업하기 좋은가?
이를 이해가위해서는 깃프로젝트의 모든 버전이 모이는 깃허브를 알아야한다.
깃허브는 깃을 중앙에 띄워주는 중앙서버로 기준이 되는 코드베이스가 올라가 있어 같은 프로젝트를 진행하는 맴버들이 전원 공유한다.
이렇게 많은 프로젝트의 최신버전이 모이는 hub에서 다양한 오픈소스 프로젝트를 열람할 수 있다.
local과 server의 이해
깃과 깃허브를 이해하고 작업에서의 혼동을 막기위해서 local에서 일어나는 일과 server에서 일어나는 일을 정확하게 구분해야한다.
중앙 서버인 github에는 기준이되는 코드가 올라온다. 처음 프로젝트에 투입이 되면 기준 코드를 통째로 clone한다.
clone해온 코드를 내컴퓨터(local)에서 작업을 시작하고 완료가 되면 git push를 통해서 중앙서버인 github로 올라가 기준 코드에 반영된다.
이후에 이어서 프로젝트를 진행 할 때는 git pull을 통해 다른 맴버가 작업해서 업데이트된 기준코드에서 업데에트된 사항을 가져온다.
이런 local환경에서의 작업을 통해서 서버에 올라가있는 기준코드에 영향을 주지 않게되고 다른사람의 문제에서 영향을 받지 않을 수 있다.
만약 깃허브 다운되면?
다른개인사용자 컴터(이미 프로젝트 클론해온)를 서버한다.
Git commandline
modified - 내가 작업하여 수정이 된 상태의 코드. 일반적인 파일 save를 한 상태이다.
stage - git에서의 중간저장. modified 된 것을 중간저장 해주는 단계이다
commit - 깃에 완벽하게 버전을 저장시키고, 깃허브 중앙서버에 푸시할 준비가 되었다.
#중간세이브를 하는 이유
commit은 중앙서버로 가기전의 상태이기 때문에 작업도중에 커밋에 반영하고 싶지 않은 사항은 중간저장 단계에서 제거가 가능하다. 그리고 작업 도중 이전으로 돌아가고 싶은 경우에도 중간저장을 해두었다면 가능한 일이다.
git init - 이 프로젝트를 깃의 관리하에 두겠다는 명령어
git add : commit하기 전의 중간저장 단계
git diff : modified stage에 있는 것중에서 어떤 부분이 수정되었는지 알려주고, 내가 어떤 brance에 있는지 알려준다.
git log : git commit history를 알려준다.
git rm : 깃상에서 내가 지우고싶은 파일.
git branch branch_name: 새로운 branch를 만든다
git checkout branch_name : 내가만든 branch로 들어간다branch와 merging
github에 올라가있는 기준프로젝트의 코드가 나무의 줄기(master branch)라고 하면
branch는 곁가지라고 할 수 있다.
작업을 할 때 메인 프로젝트에 영향을 주지 않는 feature branch를 만들어 작업을 수행하고, 작업이 끝나면 merging하는 작업을 통해서 master branch에 내 작업결과를 합쳐준다.
merge : feature branch를 내 컴퓨터에 있는 master branch에 합쳐주는 작업으로 merge또한 로컬에서 일어남. merge하고 푸시하면 깃허브 기준프로젝트에 반영된다.
Git과 Github를 통한 프로젝트 과정
- git clone으로 중앙서버에서 메인프로젝트를 받아온다.
- 내가 맡은 기능에 해당하는 branch를 생성하여 코드를 작성한다.
- add, commit, push를 통해서 깃허브에 올려준다.
git push origin(깃허브서버) feature/branch_name(내가있는브랜치 이름)을 수행한다.
4. 이제 내 로컬 branch가 깃허브 서버의 master branch의 branch로 생성되었다. 그리고 깃허브 홈페이지에가서 pull request(서버 마스터브랜치 관리자에게 내가만든 브랜치를 merge해달라는 요청)을 보낸다.
5. 서버 관리자가 서버 마스터브랜치에 내가 만든 branch를 merge승낙하면
git pull origin(깃허브서버) master(깃허브마스터브랜치)를 command해서 내 로컬 마스터브랜치를 업데이트한다. 우선 현재 나의 위치는 feature브랜치 이기 때문에 checkout master을 통해서 master branch로 이동해서 pull commandline을 수행해준다.(이 때, 내 로컬 feature branch는 업데이트 되지 않는다.)
충돌
내가 feature branch에서 작업한 결과를 반영한master branch를 push할 때를 생각해보자.
프로젝트의 다른 맴버 또한 자기 컴퓨터에 깃허브 서버의 메인프로젝트를 클론해서 작업을 진행하고 깃허브에 올라간 기준 프로젝트에 그 결과를 반영 할 것이다.
내가 깃허브서버의 기준코드에 내 마스터브랜치를 반영할 때의 시점이 만약 내가 작업을 시작하기 전의 기준코드와 다르게 이미 다른 맴버에 의해서 업데이트되어진 상태라면 어떻게 될까?
내가 깃허브 메인코드에 내마스터브랜치를 push를 시행하면 자동으로 pull요청이 오고 승낙하면 내 master branch를 업데이트한다.
이 때, 내가 수정한 파일의 라인과, pull해서 들어온 파일의 수정값이 일치하면 충돌이 발생하여 충돌을 해결하고 push가 가능하다.
참고로 충돌은 내가 한 브랜치에 오래 머물러있으면 발생할 확률이 높다. 오랜기간 local영역에 머물러 있을 동안 깃허브 서버의 메인코드에는 많은 변화가 있었을 것이기 때문이다.
충돌해결하기
-
충돌은 내로컬 브랜치에서 작업을 끝내고 git push origin feature/branch_name을 하고 깃허브서버에서 pull request를 수행했을 때 일어난다. 만약 내가 작업한 브랜치 내용과 서버의 마스터브랜치 내용이 충돌 할 경우 서버에서 아래와 같은 메세지를 보여준다.
-
conflict를 해결하기 위해서 내 로컬브랜치에 서버의 마스터브랜치를 업데이트 해줘야한다.
git pull origin(깃허브서버) master(서버마스터브랜치)위의 명령어를 내 로컬 feature/branch 에서 시행해서 내로컬브랜치에서 충돌을 만들어준다.
- 충돌을 내 로컬 feature branch에서 해결하고 다시 push해준다.
git push origin(깃허브서버) feature/branch_name(내브랜치이름)이제 conflict가 해결되었다면 merge승낙을 기다린다.
커밋은 책임이 따르는 행동이다. 내가 커밋한 결과가 서버에 공유되고 전체 코드, 서비스의 기능에 영향을 미치기 때문이다.
git diff로 add하기전에 내가 수정하고 저장했던거(modified 되었던거)가 어떤 영역이 수정되었는지 확인하고 add-> commit과정을 밟을 것.
