Git의 공식 명칭은 분산 버전관리 시스템(VCS)입니다. 쉽게 말해, 프로젝트 파일의 변경 사항을 추적하는 시스템이며 개인 혹은 팀 간의 프로젝트를 관리하는 데 가장 널리 사용되고 있는 툴입니다.
Git 다운로드 링크
설치를 마쳤으면, 터미널을 열고 Git이 정상적으로 설치되었는지 확인합니다.
git --version
이름 & 이메일 설정
git config --global user.name "이름"
git config --global user.email "이메일"
"이름"과 "이메일"은 실제 본인의 정보를 입력해주세요
Git을 관리하는 프로젝트 저장소입니다. Local과 Remote 두 종류가 있습니다.
Local repository: 본인 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소입니다.
Remote repository: 로컬 repository와는 반대로 내 컴퓨터가 아닌 외부(일반적으로 원격 서버)버전의 프로젝트 저장소입니다. 이 곳에서 프로젝트 코드를 공유하고 다른사람의 코드를 확인할 수도 있습니다. 로컬 버전의 프로젝트와 병합하고, 변경 사항을 적용할 수 있는 곳입니다. 따라서 팀에서 작업할 때 특히 유용합니다.
새 저장소(repository)를 만들고 Git으로 프로젝트 관리를 시작하려면 터미널에서 프로젝트 폴더로 이동 후 다음 명령어를 입력합니다.
git init
이 명령어는 프로젝트 폴더 내에 숨겨진 .git 디렉토리를 생성합니다. 이제 Git은 현재 저장소에 대한 모든 변경사항을 추적/관리하게 됩니다.
Git에서 commit이란, 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷으로 생각할 수 있습니다. 쉽게 말해, 현재 버전의 코드를 커밋에 저장한다고 생각하시면 됩니다. 일반적으로 커밋을 남기는 시점은 특정 내용, 기능을 추가한 후 또는 수정 사항을 적용한 후 정도로 들 수 있습니다.
터미널의 프로젝트 폴더 내에서 다음 명령어를 입력하여 repository의 현재 상태를 확인할 수 있습니다.
git status
위 명령어는 Git으로 작업할 때 굉장히 자주 사용되는 명령어입니다. 파일의 변경 및 추가내용을 모두 보여줍니다. 커밋을 남기기 위해 staging area로 추가해주어야 합니다.
프로젝트 폴더에서, git add라는 명령어를 통해 우리가 원하는 파일들을 staging area로 추가해줄 수 있습니다.
특정파일 추가: git add file.js
여러 파일 추가: git add file.js file2.js file3.js
모든파일 추가: git add .
커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남습니다. git add로 모든 파일을 staging area에 추가했다면 커밋하시면 됩니다.
git commit -m "Commit message"
프로젝트의 모든 커밋 내역을 보려면 다음 명령어를 입력합니다.
git log
특정 커밋 시점의 코드로 되돌리고 싶다면, 아래 명령어를 사용합니다.
git checkout <commit-hash>
<commit-hash>를 git log에서 보이는 커밋의 실제 hash값으로 대체합니다.
staging area에 추가하고 싶지 않거나, git에서 관리하지 않아도 되는 파일이 있다면, .gitignore파일을 프로젝트 폴더에 생성해주면 됩니다.
브랜치란 독립적으로 어떤 작업을 하기 위한 개념입니다. 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.
저장소를 처음 만들면 Git은 바로 'main'이라는 이름의 브랜치를 만들어 둡니다. 이 새로운 저장소에 새로운 파일을 추가하거나 추가한 파일의 내용을 변경하여 그 내용을 커밋하면 'main'이라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다. 마찬가지로 여러 명이 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록 자신의 작업 전용 브랜치를 만들 수 있습니다. 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다. 이 방식으로 여러 명이 하나의 프로젝트를 함께 작업할 수 있습니다. 최종적으로 버그가 없고, 사용할 준비가 되었으면 master 브랜치에 병합할 수 있습니다.
git branch <new-branch-name\>
git checkout <branch-name\> // 브랜치를 해당 branch-name으로 이동
git chechout -b <new-branch-name\> // 브랜치 생성과 동시에 해당 branch-name으로 이동
checkout을 통해 해당 브랜치로 이동하여 커밋하면 다른 브랜치의 변경사항 및 커밋의 영향을 받지 않습니다.
A 라는 브랜치에서 작업한 내용을 B라는 브랜치에 적용하고 싶을 때, 브랜치들을 병합할 수 있습니다.
git merge <branch-name>
아래 명령어를 통해, 브랜치를 삭제할 수 있습니다.
git branch -d <branch-name>
GitHub은 Git을 사용하는 프로젝트를 위한 호스팅 서비스입니다. 다른 개발자와 같은 프로젝트를 두고 협업하거나 코드를 공유하기 위해 사용합니다.
Common Workflow: 내 로컬 Repository를 GitHub에 push하기
1) 로컬에서 add / commit 한다.
2) Github으로 이동 후 새 repository를 생성한다.
3) 나의 로컬 repository를 GitHub repository와 연결한다. (remote추가)
4) 새 remote를 이용하여 코드를 Push한다.
깃허브 사이트로 이동 후 우측 상단의 + 버튼을 눌러 'New repository' 클릭합니다.
그 다음 생성 페이지에서 Repository 이름을 설정해주고 'Create repository'버튼 클릭합니다.
GitHub repository의 스타팅 페이지로 이동했을 겁니다. 로컬환경에 이미 Git repository가 있다면 페이지의 ...or push an existing repository from the command line의 내용을 순서대로 진행하면 됩니다.
git remote add origin <주소>
git push -u origin master
git remote add origin 명령어는 로컬 repository와 GitHub repository를 연결해주는 겁니다. git push 명령어는 로컬 Git repository의 코드를 GitHub repository로 업로드 해줍니다.
로컬 Git repository와 GitHub repository를 연결해서 push 했더라도 다음에 로컬에서 작업한 내용들이 자동으로 remote에 업로드 되지는 않습니다. 그래서 변경사항이 있으면 다시 push를 해주어야 GitHub repository가 업데이트 됩니다.
Git과 GitHub에 대해 어느정도 이해하고 익숙해지셨다면 다른사람들과 함께 작업하려면 어떻게 해야하는지 알아보겠습니다!!
1)Git clone
클론이란 해당 remote repository를 내 컴퓨터의 로컬 repository로 받아오는 작업입니다.
경로를 복사해서 클론해줍니다.
git clone <github-repo-link>
클론을 받으면 GitHub repository의 폴더가 생성되고 cd 명령어를 사용해서 해당 폴더로 이동하면 clone 시점에 remote repository에 존재했던 모든 폴더와 파일들이 복제되어 있습니다.
2) Branching and merging
git chechout -b feature/hi
git add .
git commit -m "Add: hi"
git push origin feature/hi
3) Pull Request (PR) 생성하기
클론받은 뒤, 내가 만든 branch에서 작업한 파일들을 추가하고 푸시까지 완료하면 Pull Request(PR)을 생성해서 프로젝트 오너에게 내가 작업한 브랜치의 작업내용을 main 브랜치에 반영해달라는 요청을 보낼 수 있습니다. PR에서는 해당 repo를 열람할 수 있는 권한이 있는 개발자들이 작업내용에 대한 리뷰를 해주거나, 변경 사항을 확인할 수 있습니다. GitHub repo 주소로 접속해서 상단 중간쪽에 Pull Request로 가서 내용에 대해 Description을 작성합니다. 'Create pull request'버튼을 눌러 마무리하면 함께 협업하는 개발자들이 방금 만든 PR을 리뷰 및 분석하고 댓글을 달 수 있게 됩니다.
4) Conflicts (충돌)
합병(merge)하기 전 종종 conflicts(충돌)가 발생할 수 있습니다. 충돌은 어떤 파일의 변경사항이 기준이 되는 main 브랜치와 겹쳐서 Git이 어떤 버전의 코드를 선택해야할지 모를 때 발생합니다. 이 때, 개발자는 직접 코드를 비교해서 충돌을 해결하고 merge를 마무리 해야합니다.
5) GitHub으로부터 변경사항 pull하기
PR을 통해 main 브랜치를 업데이트했다면, 로컬 repository는 GitHub의 main repository와 다른 내용을 가지게 됩니다. 이 때 git pull 명령어를 통해 remote의 최신화된 코드를 내 로컬 repo에 반영할 수 있습니다.
git pull origin master
앞으로의 프로젝트 또는 협업할 때 이루어지기 때문에 꼭 제대로 짚고 넘어가고 싶었다. 머릿속이 정리 됐을 때 적용하면 더 기억이 오래 남을 것 같다!!!
제이팍의 임시 저장글..