git & github에 대해 배운 걸 복습해 보고자 블로깅을 해보려고 한다!
Git의 공식 명칭은 분산 버전 관리 시스템 (VCS) 입니다.
쉽게 말해, 프로젝트 파일의 변경 사항을 추적하는 시스템입니다. 이를 통해 개발자들은 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있습니다. 이런 버전 관리 시스템은 많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있습니다. 각 개발자가 자신만의 프로젝트 버전을 본인 컴퓨터에 갖게됩니다. 나중에 이러한 개별 버전의 프로젝트를 병합하여 기준이 되는 버전의 프로젝트에 적용 할 수 있게 됩니다.
Git은 개인 혹은 팀 간의 프로젝트를 관리하는 데 가장 널리 사용되고 있는 툴입니다. 따라서 Git을 다룰 줄 아는 것은 요즘 모든 개발자들에게 가장 중요한 기술 중 하나입니다.
GitHub은 Git을 사용하는 프로젝트를 위한 호스팅 서비스입니다.
GitHub 은 개발자들의 SNS 라고 해도 과언이 아닙니다. GitHub 유저들은 서로 follow 하고, 협업하기도 하면서, 다양한 방법으로 교류할 수 있습니다.
GitHub repository는 모든 프로젝트 파일들과 코드의 히스토리를 관리할 수 있게 해주고, public 혹은 private 하게 협업할 수 있게 해줍니다.
다른 사람들이 나의 GitHub 계정을 통해 내가 어떤 개발자인지도 알 수 있고, 내가 진행했던 프로젝트를 확인할 수도 있으므로, 개발자로서 GitHub 은 정말로 중요한 플랫폼입니다.
GitHub을 사용하여 로컬 프로젝트 repository를 원격 클라우드 기반 GitHub 저장소에 업로드 할 수 있고, public repository 들을 통해 다른 개발자들과 교류할 수도 있습니다.
git init
이 명령어는 프로젝트 폴더 내에 숨겨진 .git 디렉토리를 생성합니다. 이제 Git은 현재 저장소에 대한 모든 변경사항을 추적/관리하게 됩니다.
git status
위 명령어는 Git으로 작업 할 때 굉장히 자주 사용되는 명령어입니다. 어떤 파일이 변경되었는지, 어떤 파일이 추가되었는지 등을 전부 보여줍니다.
git status 명령어를 통해 Git 으로 관리(추적)되고 있지 않던 파일(들)이 있다면 해당 파일들을 staging area 로 추가해줄 수 있습니다.
모든 파일이 Git으로 관리되고 있는 시점에서는, git status 명령어를 통해 모든 변경사항을 확인할 수 있고, 커밋을 남기기 위해 staging area 로 추가해줘야 합니다.
git add & git add .
프로젝트 폴더에서, git add 라는 명령어를 통해 우리가 원하는 파일들을 staging area 로 추가해줄 수 있습니다.
'git add 파일명' 을 통해 특정 파일만 추가할 수도 있고 'git add .' 를 사용하면 현재 디렉토리부터 모든 하위 디렉토리에 있는 파일을 추가한다는 뜻입니다.
git commit
커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남게됩니다. git add 명령어를 사용하여 모든 파일을 staging area에 추가 해주었다면 이제 커밋을 남길 수 있습니다. 커밋은 말그대로 git add로 추가한 파일들을 저장시켜주는 역할을 합니다 커밋 후 github에 push를 이용해서 작성중인 브랜치를 저장할 수 있습니다.
git log
프로젝트의 모든 커밋 내역을 볼 수 있습니다.
git log 명령어를 통해 보여지는 log는 각 커밋에 대한 자세한 정보를 담고 있습니다. (작성자, hash 값, 날짜와 시간, 그리고 커밋 메세지)
만약 특정 커밋 시점의 코드로 되돌리고 싶다면, 아래 명령어를 사용할 수 있습니다.
git checkout <commit-hash>
- <commit-hash> 를 git log 에서 보이는 커밋의 실제 hash 값으로 대체해야 합니다.
git branch 'branch-name'
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.
여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다.
이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.
저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둡니다. 이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.
'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 집니다.
새로 만들어진 브랜치는 현재 프로젝트의 코드를 그대로 반영하여 생성됩니다.
master브랜치 대신 master이름을 main으로 바꿔서 많이 사용한다고 한다.
git checkout 'branch-name'
checkout 명령어는 원하는 브랜치로 이동할 수 있는 명령어 입니다.
'git chcekout 브랜치이름' 을 이용해 작업하고자 하는 브랜치로 이동 할 수 있습니다. 'git checkout -b 브랜치이름' 을 통해 브랜치를 생성한 후 생성한 브랜치로 바로 이동할 수도 있습니다.
git merge 'branch-name'
A 라는 브랜치에서 작업한 내용을 B 라는 브랜치에 적용하고 싶을 때, 브랜치 A 와 브랜치 B 를 병합(merge) 할 수 있습니다. 예를 들어, 특정 브랜치에서 새로운 기능을 완벽하게 구현하고 테스트까지 완료한 시점이면, 기준이 되는 master 브랜치에 구현내용을 적용시켜야겠죠? 이럴 때 merge 를 사용합니다. 기본적으로는 github에 푸시후 pr을 한후 merge를 해준 후에 main 브랜치르 pull로 업데이트 시킨후 main브랜치랑 merge를 한후에 업데이트 시키는 방향으로 브랜치 관리를 한다.
git push origin 'branch-name'
이 명령어는 지금까지 작업한 커밋을한 파일들을 github로 보내는 작업 즉 푸시하는 작업을 한다.
git pull origin 'branch-name'
이 명령어는 깃허브 레파지토리에 있는 브랜치를 로컬 브랜치에 정보를 가져오는 즉 최신화 시켜주는 명령어이다.
깃허브 에서 로그인을 한 후에 우측 상단에 플러스 버튼을 클릭하면 new repository가 나온다. 클릭한 후 레파지토리명 을 입력해 새로운 레파지토리를 만들 수 있다.
새로운 레파지토리를 만든 후에 이 레파지토리를 로컬 레파지토리랑 연동 시켜주어야 한다.
여기서 remote 명령어를 통해 로컬 레파지토리랑 연동 시켜주면 된다.
.gitignore파일이란 Git 버전 관리에서 제외할 파일 목록을 지정하는 파일이다. git으로 프로젝트를 관리할 때, 그 프로젝트 안의 특정파일들은 Git으로 관리할 필요가 없는 경우가 있다.
사용법은 이러하다 우선 프로젝트 폴더로 이동한 후에 touch .gitignore 파일을 만든후에 vi .gitignore를 이용해 에디터를 연다음에 gitignore.io 사이트로 이동후에 보안관련 아니면 제외할 목록을 입력한후 생성을 한후 페이지에 있는 모든 내용을 복사한후 에디터에 추가후 저장해주면 된다. gitignore파일에는 my_settings.py같은 github에 올리면 안되는 파일들도 추가 해준다.