Git을 쓰는 이유는?
-
버전 관리(형상 관리)를 함으로써 코드의 보수, 유지를 원활하게 하고자
-
코드를 수정하고 저장한 파일들을 폴더에 정리하고 그 폴더를 카테고리 별로 만들어 관리해도 파일들 하나 하나를 봤을 때 따로 변경사항들만 정리하지 않는 이상 변경사항을 파악하기 힘들다는 문제가 발생.
-
그런데 그 폴더와 파일 관리를 나 혼자 하는 게 아니라 공동관리를 해야 한다면?
=> 다같이 자료를 공유해야 한다
=> 그런데 같은 파일을 동시에 수정한다면? 충돌 발생 -
이 모든 문제점들을 해결하고자 Git을 사용, 그리고 이 모든 기능
** Git이 각광을 받는 이유
- 모든 내역들을 모든 구성원들이 받고 가져올 수 있음(모든 컴퓨터에 복제가 그대로 됨).
그 전 시스템들은 하나의 중앙 컴퓨터가 있고 그게 필요한 부분들만 받아오는 시스템이었다면 Git은 모두가 받아올 수 있음. - 코드의 수정사항은 본인의 컴퓨터에서만 수정이 되고 공유하고자 할 때는 'push'를 통해 모두에게 공유가 됨.
- Git 자체는 인터넷이 없어도 가능함.
- 모든 내역들을 모든 구성원들이 받고 가져올 수 있음(모든 컴퓨터에 복제가 그대로 됨).
Git의 중요한 요소
- git repository: 저장소
- 모든 파일들이 저장되는 곳
- 'history' 기능: 수정한 것들의 역사, 수정한 내역들이 모두 저장되어 있음.
수정된 시점(commit)으로 저장 됨.
-
branch: commit들이 쭉 나열되어 있는 것. 모든 branch들을 묶는 건 'master branch(나무의 뿌리)' 가지.
-
GitHub: 모든 사람들이 접속해서 이용할 수 있는 중앙 서버 역할, 중앙 repository.
Git stage
Git을 사용해서 파일 버전 관리를 할때 파일은 다음 3개의 상태중 하나의 상태에 있게 됨.
- modified: 내용 수정
- staged: 변경된 내용을 중간 save => git add .
'commit' 되기엔 완벽하지 않고 임시 저장하는 것, 추가 수정. 되돌리기가 가능 - commit: 해당 브랜치에 내용이 저장됨=> history 생성.
local repository에 저장 => git commit -m "something typed"
Git's commands
-git init : git을 레퍼지토리로 사용하겠다고 시작하는 것.
-git add : 수정 사항들, 즉 modified 파일들을 staged 상태로 옮기고자 할때 사용하는 명령어. 또한, git repo에 새로이 추가된 파일들을 'staged' 상태로 옮길때도 사용.
-git commit: 'staged' 된 파일들을 'commit' 하고자 할때 사용하는 명령어.
-git push & git pull: 변경사항들을 원격으로 'push'&'pull'하는 것. 변경사항들을 add, commit했다면 원격으로 push, 최신내용이 업데이트 되서 원격에서 받길 원하면 'pull'.
- How to : git pull <:remote:> <:branch:> and git push <:remote:> <:branch:>
-git diff: 어떤 수정 사항들이 적용됬는지 보고자 할때 사용하는 명령어. 'staged' 된 수정 사항들은 git diff로 볼 수 없고 'Modified' 된 파일들만 git diff로 확인 가능.
-git status: 현재 상태를 보여주는 명령어. 어떠한 파일들이 'modified'가 되었고 어떠한 파일들이 'staged'가 되었는지 등의 전체적인 상황을 보여줌.
-git log: 'commit' 내역들을 보여줌(commit history). git log를 통해 이제까지 커밋 내역들을 전부 볼 수 있음. 다만 출력되는 포맷이 보기가 쉽지가 않아서 'tig' 같은 tool을 사용하면 훨씬 편리.
(sudo apt-get install tig)
-git rm: 원하는 파일을 git repo에서 삭제.
-git mv: 원하는 파일을 git repo 상에서 이동 시킬때 사용. 주로 rename 할때 사용.
Git branch & mersing
- 'master branch'에서 작업한다고 가정했을 때, 작은 가지 'branch' 생성 => git branch
- 예를 들어, 'feature branch'(master branch에서 나온, 작업 branch)를 생성해서 로그인 하는 코드를 작성하고 저장을 해 'master branch'에 합하는 것. for 다른 사람들과 적업을 하기 위해 'featrue branch' 생성. 공동 작업자들의 작업에 영향을 받지 않으면서 작업을 하고자. 자신만의 브랜치를 따서 작업을 하고 마지막에 끝났을 때 'master branch'에 합함. 그리고 그 과정을 'mersing'이라고 함.
- 작업자들 서로 'pull' 받는 시점이 다르고 같은 부분에서 수정 사항이 두개 이상이 되면 어떤 부분을 반영해야 할지 git 시스템에서 결정을 못해 수정사항을 저장하고 'mersing'하게 되면 'conflict(충돌)' 발생.
- 그 어떠한 내용도 받지 못하므로 작업자들끼리 최종적으로 반영햘 내용을 상의해서 다시 'git add'와 'git commit'을 해야 함.
- 충돌이 일어날 때 버그가 많이 발생하므로 이럴때일수록 차분히 코드를 확인해 문제가 없는지 파악해야 함.
git commit,git diff를 자주 확인해야 함.
GitHub, 중앙서버
'Github'는 중앙서버의 역활을 하는 서비스. 개발자가 직접 git 중앙서버를 구현하여 운영할 수 도 있지만 여러가지 비용과 구현하는 시간이 걸리는 불편함이 발생. 그래서 대신에 가성비 좋고 튼튼한 github를 사용.
- 내 local(내 컴퓨터)에 있는 'master branch'를 'GitHub'(모든 작업자들의 컴퓨터)으로 'push'.
- 나의 'master branch'와 'Github'에 있는 'master branch'를 비교해 수정사항 반영.
- 다른 작업자가 업데이트한 내용을 확인하려면 'git pull'을 해야 함.
- 'pull'을 할 때 conflict(충돌) 발생 => 왜냐하면 누군가의 수정사항을 반영해 'mersing'한 파일을 내가 다시 받아오고, 나의 코드에도 수정사항이 있게 되면 2개 이상의 수정사항이 생기므로 'conflict' 발생.
- 'push'를 할 때도 'conflict' 발생 => 'push' 할 때 내가 한 수정사항이 'github'에 있는 코드와 다르게 되면 'github'의 'master branch'를 일단 'pull'하고 'local branch'를 'push'하라고 뜸.
- 각 'feature branch'별로 작업을 해야 함. 로그인 작업은 로그인 feature branch, 로그아웃 작업은 로그아웃 feature branch에.
- 'feature branch'는 'master branch'에 'mersing' 하면 지워도 됨 => 'feature branch'는 short lived.
<git 실습>
git pull origin master => master branch에서 최신 코드 받기
git branch feature/기능 이름 => feature branch 만들기 => 그러면 내 로컬 브랜치로 저장
git checkout feature/기능 이름 => feature branch로 이동
git status
git add .
git comment -m "something typed"
git push origin feature/기능 이름 => feature branch로 push => 내 로컬 브랜치에서 깃허브 마스터 브랜치로 저장
pull request, 사이트에서 하기 => mersing 이 되면 내 코드 업로드, 안 되면 충돌
