개발이라는 것을 처음 시작하면서 2주 동안 들었던 단어인 "GIT"
Blog를 gatsby를 통해 GitHub에 올리기도 하고, Westagram을 GitHub에 올리는 것도 했다. (이해를 하지 못하고 따라하기만 했다.....)
오늘의 GIT에 대한 이해와 실습을 통해 많은 것을 알게 되었고 혼자서도 간단히 할 수 있을 것이라고 생각된다.
강의 내용
GIT이란?
버젼 관리하는 것이다.
버젼관리는 왜 해? 문제가 생겼을 때 다시 돌아갈 수 있기 위해, 보수 유지를 위해
예를들어 대학에서 논문쓴다 했을 때, word file을 작성하는데,
과제.docx를 제작하는데, 처음에는 과제 초본.docx하고 그 다음에는 최종본.docx해서 다른이름으로 저장한다.
그런데, 내가 만약 한달 전에 저장했던 file을 찾기 힘들 것이다.
찾으려고 한다면 날짜를 적겠지. 과제_30days-ago.docx이렇게.
그러면 이러한 파일이 너무 많고 복잡할텐데 어떻게 하냐면 날짜별로 폴더에 정리하겠지.
이러면 날짜과 버젼을 알 수 있긴 한데, 안에 뭘 수정했는지 알 수 없다.
excel파일에 변경사항, 저장된 위치 해서 정리를 많이들 해둔다.
E.g. 변경사항 내역: a.xls
파일이름/날짜 버젼/변경내용
가능하긴 하지만, 이건 나 혼자 확인 할 때, 가능하고 5명의 팀이 보기에는 힘드니,
Google drive같은 곳에 share하면 된다.
문제는, 2명이 같은 것을 수정하면 충돌할 수 있다. 그러면 합의를 해서 누구는 어디를 수정하고 누구는 어디를 수정하는지 입을 맞춰야 한다.
지금까지 위의 기능을 체계적으로 하는 것이 GIT이다.
코드 내역 관리를 해주는 거다.
———————————————————
사실 version control system은 GIT말고도 여러가지가 있다.
지금은 GIT이 많이 쓰인다.
Repository(소스코드 저장소)
우리가 작성하는 코드가 Repository에 저장된다.
History가 있는데, 이것은 코드가 수정된 내역들이다.
수정을 우리는 Commit이라고 하는데, History는 commit의 내역이다.
Branch는 commit의 줄기이다.
Branch의 default는 master이고 이 master안에 수정 코드의 역사가 있다.
————————————————————
또 GIT이 각광받는 특징 중 하나는
GIT은 1사람이 코드를 올리면 3명의 작업자의 컴퓨터에 코드가 복제가 된다. 즉, 완전 clone이 된다.
이전까지는 중앙 repository에서 수정할 코드만 뽑아서 수정하고 다시 올리는 형식이었다. 그러나
이제는 개개인이 컴퓨터 코드를 local에서 수정하고 나중에 공유하면 된다.
git과 git-hub은 분리되어있다. git은 오프라인으로 가능하다. Local에서 이뤄지고 git-hub은 내 코드를
공유하는 것이다. 모든 사람이 접근할 수 있는 중앙 repository가 된다는 의미이다. 그럴려면 공유할 때는 online이 필요하다.
—————————————————————
git은 기본적으로 내역관리니까 수정함으로써 시작된다. 수정할 것이 없으면 내역관리 안하겠지?
Modified git에 있는 코드를 수정하면 modified단계로 넘어간다.
staged git add를 통해 중간에 수정을 중간 저장하는데 이 단계가 staged라고 한다. (역사에 남기기 전에 마지막 수정을 위해 되돌리기 위해 중간 세이브를 한다.)
Commit git commit을 통해 history에 남긴다. 즉, 자취를 남긴다. Local에 남긴다. 공유를 할 준비가 되어있다.
———————————————————————
repository는 코드를 담고 있는 저장소이다. document에 여러 코드가 저장되어 있는데 이제 git init을 통해
그 document의 파일을 git의 repository가 조종하겠다고 하는 것이다.
로그인 기능을 만들려고 작업하려면, git repository의 master branch에서 하진 않고, feature/login이라는 branch를 따로 만든다. 거기서 로그인 기능을 만들어야한다. 왜 master branch에서 바로 작업해서 commit안 하냐면 5명의 사람이 각자의 pace로 코드를 수정하는데 내가 70%한 작업을 commit했는데, 누군가 20%한 작업을 올리면 내 작업이 무너진다. 그래서 각자 다른 branch를 따고 작업한 다음, 끝나면 Master branch에 올린다.
이 것을 merging이라고 한다.
이렇게 하면 다 좋은데, 문제가 날 수 있는게, 내가 1번 commit history에서 코드를 따서 수정하고 5번째에 완성본을 내면, 누군가 2번 commit history에서 코드를 따서 수정하고 5번째에 완성본을 내면 git이 둘 중 누구의 완성본을 5번째에 저장해야하는지 헤깔려서 conflict error를 낸다. 그러면 2명이 합의해서 어떤 파일을 내야 할 지 상의해야한다.
——————————————————————————
Git diff는 modified상태의 실제 수정 사항을 보여준다.
Git status는 어떤 파일이 modified 인지 staged인지 보여준다.
Git log는 역사를 보여준다.
Git checkout은 master branch에 있다가 feature branch로 옮길 때 사용한다.
————————————————————————————
.gitignore file
git앞에 .이 붙으면 hidden이다.
내 개인 기록이 저장된 데이터 베이스같은 경우는 git에 올려서 공유하면 안되니,
이 것은 .gitignore을 통해 숨겨야 한다.
—————————————————————————————
기존에 존재하는 repository에
내 컴퓨터(local computer)
Git clone하면 기존에 존재하는 repository의 복사본을 따서
branch따서 작업하다가 내가 이제 남들과 공유할 준비가 되었다 하면
Git push를 한다.
Git add는 처음 만드는 repository에 들어가기 위할 때 사용한다는 점에서 차이가 있다.
Git pull은 다른 사람이 수정한 git repository의 코드를 내 컴퓨터로 가져오는 기능이다.
이 때, 내가 clone해서 수정한 코드가 있다면 pull하는 것이랑 다르니 conflict가 날 수도 있다.
한달 전에 내 컴퓨터에 아무것도 없는 것이 있는데, clone을 해서 내 컴퓨터에 처음
복제해서 가져온다. 그리고 한달 후에 내 컴퓨터에 한달동안 다른사람이 수정한 내용이
내 컴퓨터에 반영이 안되어 있으니 git pull을 통해 가져와야한다. 그래서 차이를
없애고 push를 해야한다.
실습
- terminal을 통해 GIT에 올라온 url을 clone한다.
- GIT에 올라온 Master branch에서 version control하면 안되니 feature/ykim branch를 따로 만들어야 한다.
- Feature/ykim branch는 내 컴퓨터의 환경에서 수정할 수 있게 만드는 것이다.
- clone한 file의 코드를 수정해야하는데, vim file.md으로 들어가서 수정하고 저장한뒤 add, commit, push하면 된다. (이때, feature/ykim branch에서 push해야한다.)
- pull request를 GIT website에가서 Master branch의 developer에게 merging 승인을 요청하면 된다. (받아들이면 수정이 완성된다)
현재 directory에 gittraining이라는 folder를 mkdir을 통해 만들었다.
여기에 git clone "https//:asvdsafdsaf"를 해서 clone을 받으면 안에 hello_git을 받는다. 받고나서 다음과 같이 branch를 만들어야 한다.
git branch를 누르면 현재 내 branch 상태가 나온다. (default는 master) 그래서 새로 만든 branch에 들어가려면 git checkout feature/ykim_2를 만들어야 한다.
git origin master를 통해 아까 clone했던 hello.git이라는 file을 master branch 즉, 내 컴퓨터의 master branch,에서 feature/ykim_2 branch로 받아와야한다.
(지훈님께서 올린 hello.git을 Master branch라고 하면, 내 컴퓨터에 clone한 곳도 Master branch인데 왜 내 컴퓨터에서 feature/ykim_2 branch를 만들지?
Remote Master branch과 local Master branch는 같은게 아닌데, 걍 local Master branch에서 수정하고 push하면 Remote master branch의 개발자가 검사하면 안되나? Remote master branch가 최종본이라면 그 것을 위한 많은 branch에 내 master branch를 올리면 되지 않나? 왜 굳이 conflict위험이 똑같은 master과 feature branch를 나누지?)
예리님의 설명에 의하면, remote branch에는 완성본만 들어가야 한다.
clone한 파일을 내 컴퓨터(local)의 master branch에서 수정하고 push하면 git의
master branch의 최종본에 넣을 수 밖에 없다. 최종본을 위한 예비 branch에 검토를 위해 넣을 수 없다. 그러니 featrue/login이라는 local branch를 만들어서 수정하고 이것을 develop branch에 push하면 개발자가 develop branch를 검토하고 master branch에 올리게 된다.
예를 들어, 네이버에서 3년 뒤에 개발공개할과, 2년뒤에 개발공개할 기능등, 오랜기간 프로젝트를 구분하는데, 많은 개발자가 공동개발을 하면서, 바로 master branch에 올리면 안되기 때문이다.
그리고 git과 git-hub의 차이를 보면 git은 오늘 한 서버 관리 전체 시스템을 의미하고
git-hub은 이 시스템을 이용한 서비스일 뿐이다.
feature/ykim_2의 branch에 접속해서 master에 있던 file을 가져왔다면, 이제 vim을 통해 파일을 수정하면 된다.
들어가면 이렇게 업데이트 된 파일이 나오는데, vim에서 i를 누르면 편집이 가능하고
내 이름을 입력한 뒤, esc눌러서 편집기능을 나오고, :wq를 통해 vim에서 나오면 된다.
:q는 나오는 것이고 :w는 편집한 것 저장이다. ctr+s이다.
다 수정이 완료 되었으니 modified되었다.
그 다음 과정은 git add, git commit, git push하면 된다.
commit할때는 file명 앞에 comment를 달라고 하는데, 걍 commit -m"" README.md
하면 된다. -m은 message니까
commit이 완성되면, git push origin feature/ykim_2하면 된다.
git push origin master하지 않는 것은 일단 git에서 feature/ykim_2 branch 수정본을 받고 master에 merging시킬지 안 시킬지, pull requesting을 결정하게 된다.
Pull requesting은 git 웹사이트에서 할 수 있는데, branch에서 보면 내가 아까 push한 branch가 올라와 있다. 이제 개발자에게 승인 받으면 수정된 내용이 저기 master에 올라온다.
