들어가기에 앞서, 가장 궁금할
Git Commands
Git
버전컨트롤 시스템
소스코드 버전 관리
버전관리를 통해 협업 편하게
Github
깃을 인터넷에서 관리할 수 잇는 중앙관리 시스템
Github의 repository 저장소
10명 개발자가 같이 개발할때, 기준이 되는 소스 필요
이 기준 = repository 저장소 (인터넷에서 접근되기에 편함)
없다면, 서버를 하나 만들어서 올려야 함 (비용 많이 들기에 안 씀)
Git vs. Github 차이점
깃허브는 중앙서버,
깃은 내 컴퓨터(로컬 환경)에서 쓰는 것
깃허브와 깃은 분리된 환경, 중앙서버와 로컬 환경라는 명확한 차이!!
Git ➡ 프로젝트의 버전관리를 도와주는 시스템
GitHub ➡ Git을 이용해 버전관리를 한 프로젝트들을 관리하게 해주는 호스팅 서비스
Github 개념
clone, push, pull
깃허브에 있는 기준코드를 내 로컬 환경에 다운받는 것 = clone 복제한다.
다운 받아 작업한 내용을 중앙서버에 업로드 = push 밀어넣는다 (내 로컬에 있는 소스 수정 내용을 중앙 서버로 밀어넣는다)
다른 개발자가, 내가 수정해서 업로드 한 사항을 다운 받으려면 다시 pull
다운 받을 때의 Pull 과 clone의 차이
Clone: 처음 소스를 다운 받을 때
Pull: 이미 다운 받은 소스의 변동 사항을 다운 받을 때
0→ 깃허브에서 일어나는게 아니라, 내 컴퓨터에서 일어나는 일
깃으로 버전 컨트롤 할 때 3가지 상태
- 처음 수정 일어나서 변화 감지 modified file (수정된 파일, 아직 comit 되지 않은 파일)
- Staged file : modified file에서 한 단계 더 나아가서 곧 commit 될 거라고 mark 해놓은 상태 ( modified 와 committed의 중간 상태)
- 중간 상태가 존재하는 이유: commit하기 전에 중간 상태 저장하고, 혹시 잘못 수정됐을 경우 다시 되돌릴 수 있도록 임시 저장 기능
- Staged = 곧 commit을 할 수 있다는 의미
3. Committed = 마지막 상태 (비로소 push할 준비 됐다는 의미)
<git을 사용한 버전관리 flow>
- 소스코드 clone 한다 (전체 다운로드, git repository를 checkout한다)
- 수정한다 (= 개발; 소스코드의 파일들 수정)
- Stage 한다
4. 완료될때까지, 계속 수정-stage 반복 (소스코드의 파일들)
5. Commit
<Git 기본 명령어 / Basic Git Commands>
0. Repository 저장소
Git으로 관리하는 프로젝트 저장소 (=폴더)
- local repository - 본인의 컴퓨터 저장된 로컬 버전의 프로젝트 저장소
- remote repository - 외부 (원격 서버) 버전의 프로젝트 저장소 (팀 협업에 유용, 코드 공유, 다른 사람 코드 확인, 로컬 버전 프로젝트 병합/변경사항 적용)
1. git init
새 저장소 만들고 git으로 프로젝트 관리 시작
프로젝트 폴더로 이동 후 git init 명령어
프로젝트를 git repository로 만들기 위해서 사용 (프로젝트= 개발하고자하는 소스코드들이 있는 빈 디렉토리)
mkdir project #아무것도 없는 directory
cd project
git init
master 이름표 달림 (project 디렉토리는 이제 git 이 관리)
cd .git (project 폴더 안에 깃 생성됨 - project 안의 모든 작업이 깃에의해서 관리된다)
Git [흐름정리]
1) init (파일 작성, 수정, 삭제)
2) add (동작이 하나 끝났다면, 변경 이력 남길 준비)
3) commit (실제로 버전1에 대한 내용 기록)
4) push (remote 공간으로 내 코드를 올린다)
<작업 폴더> -(add)- <staging area 임시 보관소>- (commit) - <repository 저장소>
<Git> Git에서 commit 이란,
프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷
현재 버전의 코드를 커밋에 저장
커밋 히스토리에 필요한만큼 커밋을 생성 할 수 있으며, 커밋 간 앞뒤로 이동하여 프로젝트 코드의 다른 변경사항을 확인할 수 있습니다. 이를 통해 프로젝트의 진행 상황을 효율적으로 관리할 수 있게 됩니다.
일반적으로 커밋을 남기는 시점은 특정 내용, 기능을 추가한 후 또는 수정 사항을 적용한 후 정도로 들 수 있습니다.
📌 코드를 커밋하려면 --> 우선 코드를 staging area 에 추가
Checking the status (상태 확인)
터미널에서 (프로젝트 폴더 내) 다음 명령어를 입력하여 repository의 현재 상태를 확인
git status
어떤 파일이 변경되었는지, 어떤 파일이 추가되었는지 등을 전부 보여줌
Git 으로 관리(추적)되고 있지 않던 파일(들)이 있다면 해당 파일들을 staging area 로 추가해줄 수
모든 파일이 Git으로 관리되고 있는 시점에서는,
git status 명령어를 통해 모든 변경사항을 확인할 수 있고, 커밋을 남기기 위해 staging area 로 추가해줘야
프로젝트 폴더에서, git add 라는 명령어를 통해 우리가 원하는 파일들을 staging area 로 추가
Making commits (커밋 남기기)
커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남게됩니다.
git add 명령어를 사용하여 모든 파일을 staging area에 추가 = 커밋을 남길 준비 완료아래 명령어를 통해 staging area에 있는 파일들을 커밋
git commit -m "Commit message"
- 식별을 위해 큰 따옴표안에 커밋 메세지를 작성해야
- 커밋 메시지는 repository에 커밋하는 변경 사항을 설명하는 짧은 summary 여야 합니다.
- 위 명령어를 실행하면, 터미널에 방금 남긴 커밋에 대한 세부 내용이 보여지게 됩니다.
Commit history : 프로젝트의 모든 커밋 내역 보기
git log #각 커밋에 대한 자세한 정보를 담고 있습니다. (작성자, hash 값, 날짜와 시간, 그리고 커밋 메세지)
만약 특정 커밋 시점의 코드로 되돌리고 싶다면, 아래 명령어를 사용할 수 있습니다.
2. git add
수정된 사항들 (modified 파일들을) staged상태로 옮기고자할때 사용
수정하면, 그것에 대해 중간저장을 하기 위해, commit하기 직전에 add를 먼저 해야함.
add를 하지 않으면 commit을 할 수 없음
project폴더에서 git add 명령어로 우리가 원하는 파일들을 staging area로 추가
- git add <파일/디렉토리> : 변경 내용 일부만 staging 영역에 넘기고 싶을 때
git add file.js #특정 파일만 추가
git add file.js file2.js file3.js. #여러 개 파일 추가(띄어쓰기)
git add . # 모든 파일 한번에 추가
- git add . : 현재 디렉토리의 모든 변경 내용을 staging 영역에 넘기고 싶을 때 (명령어 실행한 디렉토리 이하에서 발생한 변경 내용만, 상위 디렉토리 변경 내용은 포함 안함)
- git add -A : 작업 디렉토리 내의 모든 변경 내용을 몽땅 staging 영역으로 넘기고 싶을 때 (작업 디렉토리 어디에 위치하든 항상 동일하게 모든 변경 내용을 staging으로 넘김)
- git add -p : 각 변경 사항을 터미널에서 직접 하나씩 확인하면 staging 영역으로 넘기거나 제외 가능
수정한 파일의 이력(기록)을 남길 준비를 하는 명령어 (commit을 할 준비)
장바구니 개념
<명령어> (띄어쓰기 해야 _)
1. 특정 파일만 이력을 남기고 싶을 때 : git add [파일 이름]
2. 변경된 파일 전체의 이력을 남기고 싶을 때 : git add .
Cf. 변경 이력을 남긴다 (추적) vs 파일 저장 (ctrl + s)
3. git commit:
add 된 사항들을 하나의 commit으로 만들어서, commit 메세지를 부여하고 commit을 하는 작업
Git commit
파일 수정 이력 기록/ 수정한 파일의 이력을 남기는 명령어
명령어
1. 한 줄로 커밋 메세지를 남기고 싶을 때 : git commit -m “메세지”
git commit -m ‘메세지’ + enter
2. 여러 줄의 커밋 메세지를 남기고 싶을 때 : git commit + enter → vin editor 파일 공간 뜸
거기에 쓰고 나오면 됨
무슨 행위가 생겼는지 기록
Ex. “기능 1 개발" 근데 기능1에 여러 개 추가될 수 (구동되는 기능이 여러개 생겼다 → 여러 줄 쓰고 싶을 떄 2번)
4. git diff :
modified 상태에서만 결과물이 나오는데, 수정사항들 보여줌 (modifed된 파일들만 git diff로 볼 수 있음)
어떤 수정사항들이 적용됐는지 볼 때
5. git status:
현재 git repository 안에 있는 상태를 보여줌 (현재 상태가 modified 인지 staged 되었는ㄴ지, 전체적인 상황)
깃이 어떻게 추적하는지 (수정했는지, 삭제했는지)
git 상태 확인 (이 파일에서 무슨 일이 일어나고 있는거야 할 때 찍어보는)
디렉토리에서 일어나고 있는 상태를 확인 할 수 있는 명령어 (명령어 : git status)
6. git log:
commit 내역, commit history (여태까지 커밋 내역 전부 볼 수 )
Git log: commit을 어떻게 확인
Git status: 변경을 어떻게 했는지 확인
7. git rm:
git에 등록된 파일을 삭제할 때
8. git mv:
git에 있는 파일 이동시킬 때 (주로 rename할때 사용)
Branch
git branch:
프로젝트에 존재하는 모든 브랜치를 확인
(branch를 생성/ 삭제/ 관리)
원하는 브랜치로 이동하면,
해당 브랜치 안에 있는 마지막 커밋 내용이 작업 트리에 펼쳐집니다.
브랜치가 전환 되었으므로
이후에 남기는 커밋은 전환한 브랜치에 추가 (해당 브랜치에만 영향)
다음 다른 브랜치로 이동하여 작업 할 수 있음 (이전 브랜치의 변경 사항 및 커밋의 영향을 받지 않음)
git checkout:
branch를 이동할 때
git checkout -b :
브랜치 생성 후 거기로 이동
Merging branches 브랜치 병합
git merge
A 라는 브랜치에서 작업한 내용을
B 라는 브랜치에 적용하고 싶을 때, 브랜치 A 와 브랜치 B 를 병합(merge)
예를 들어, 특정 브랜치에서 새로운 기능을 완벽하게 구현하고 테스트까지 완료한 시점이면,
기준이 되는 master 브랜치에 구현내용을 적용시켜야겠죠? 이럴 때 merge 를 사용
Deleting a branch 브랜치 삭제
git branch -d
11. git push:
작성한 코드를 원격 저장소(remote)에 업로드
코드를 배포
이력을 남긴 코드들을 github에 올리고 싶을 때 사용하는 명령어
명령어 : git push origin [브랜치이름]
원래는 git push [http://원격저장소 주소] --> 매번 쓰기 귀찮은니 Origin이라는 변수에 담겠다.
cf. origin: 저장소(github 주소)
내가 작업하고 있는 작업공간의 코드를,
내 remote공간(원격공간)의 작업공간에 올리겠다.
12 .gitignore file
git repository 에 있는 모든 파일 중 원하지 않는 파일이 포함되는 걸 막기 위해 (전부 commit 하지 않아도 됨. )
.gitignore file 생성하고, 그 안에 들어가지 않았으면 하는 파일들을 명시
<Branch & Merging>
Branch: 가지
git은 commit 내역을 tree 형태으로 관리
- 기준이 되는 history = master (이용하는 소스 가지)
- 수정하고 싶을 떈, master에서 하지 않고, branch를 새로 만들어서 작업 (기존에 있는 소스가 영향을 받지 않게 하고, 안전하게 관리하기 위해서/ 여러 사람들이 동시에 master에 수정하게 되면, 변동사항에 대해 즉각적으로 영향을 받게 되어, 문제가 자주 발생)
→ branch 를 생성해서 작업해야!! (생성하는 branch = feature branch = 기능 branch)
- branch 생성 시 branch 명칭: feature/ 를 붙임
- merge: 기존의 코드 + 수정사항 commit 합치는 과정 (master branch에 기능branch 에 작업한 commit을 병합)
- 병합과정에 따라 ‘충돌’이 일어날 수도 = ‘conflict’
- conflict는 error가 아니라, 소스를 수정하고 합치는 과정에서 필연적 과정
(conflict 일어나면, 해당부분을 깃에서 가이드해줌, 해당 가이드 부분 확인하고 수정한 뒤 merge 하면 됨)
→ branch 충돌을 local에서 해결하는건 맞지만,
협업과정에서 서로 눈으로 확인하면서 합치는 과정은 github에서 제공 = ‘pull request’
정리
- 기준 = master branch
- Master branch를 checkout
- Master branch로부터 자신만의 branch (= feature branch)만듦
- Feature branch 기반으로 개발, 개발 완료되면 commit
- 자신의 feature branch를 master branch로 합한다(=merge)
<git branch 생성하는 시현>
Master에 작업물 존재해야 branch 딸 수 있음 → master에 아무것도 존재 안 하니, 수정 사항 만든 뒤에, 작업
touch abcd #수정사항
git add adbcd #중간저장
git commit -m “add abcd”
#commit-m + “원하는 문장", git commit(안에 들어가서 원하는 메세지 입력, 저장 종료 :wq)
#commit 완료
이제 branch 생성
git branch feature/edit #생성시 git branch feature/이름
branch 정상적으로 생성됐는지 확인
git branch #현재 존재하는 branch 종류 모두 나오고,
# 현재 위치한 branch에 * 표시됨 (현재 master에 있으니 *master)
나의 오류 : 무엇이 잘못되었을까.. 똑같이 따라해도 나만 다르게 나오는..
(동기들이 매번 하는 말 ㅎ)
그리고 사실 .git을 확인하기 위해서는 ls 이 아닌 ls -al 을 했어야 했다.
feature/edit으로 이동해보자
git checkout feature/edit #checkout : branch 간 이동
'Wecode - Foundation 1 (부트캠프) > Git, Github' 카테고리의 다른 글
| [GitHub] 깃허브 활용 (0) | 2023.09.04 |
|---|---|
| [Git/Github] 명령어 - 실습 이용 (0) | 2023.09.04 |