4. git 명령어 - 기초
로컬
저장소
commit
pull
사용자 PC
push
fetch 원격
저장소
add
reset
워크
스페이스
(Stage 영역)
워크
스페이스
(Unstage 영역)
1. 원격 저장소(Github)에 Project 저장소 만들기
2. 내 컴퓨터에 여기서 Git을 쓸거라는 초기화 명령어 내리기
3. Github에 만든 프로젝트 저장소 주소를 로컬 저장소에 알려주기
4. 내가 생성하고 변경한 파일에서 올리길 원하는거 선택하기
5. 선택한 파일을 한 덩어리로 만들어서 로컬 저장소에 올리기
6. 덩어리를 원격 저장소(Github)에 올리기
add
commit
push
init
remote
5. git 명령어 - 기초
1. git init
원격 저장소를 복제하여 로컬 저장소를 생성
2. git remote add [이름] [저장소 주소]
새로운 원격 저장소를 추가
3. git add
파일을 수정하고, stage영역에 올리는 명령어
4. git commit
Stage 영역에 올라가 있는 파일을 커밋함
5. git push
원격 저장소에 로컬 저장소에 있는 파일을 푸시
6. git 명령어 - 기초
1. git log
커밋 로그를 볼 수 있는 명령어
2. git status
커밋되지 않은 변경사항을 조회
3. git init
현재 디렉토리에 git 저장소를 생성
4. git diff
스테이징 영역과 현재 작업트리의 차이점을 보여줌
8. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
원격
저장소
A 개발자
B 개발자
Master
9. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
2. A개발자가 혼자 개발하기 힘들어서 B개발자가 합류함
3. B개발자가 원격 저장소를 가져와서 본인도 코드를 수정함
원격
저장소
A 개발자
B 개발자
Master
10. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
2. A개발자가 혼자 개발하기 힘들어서 B개발자가 합류함
3. B개발자가 원격 저장소를 가져와서 본인도 코드를 수정함
4. B개발자가 수정한 코드를 머지함
원격
저장소
A 개발자
B 개발자
Master
11. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
2. A개발자가 혼자 개발하기 힘들어서 B개발자가 합류함
3. B개발자가 원격 저장소를 가져와서 본인도 코드를 수정함
4. B개발자가 수정한 코드를 머지함
5. A개발자도 동일한 파일을 수정함
원격
저장소
A 개발자
B 개발자
Origin/
Master
Master
12. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
2. A개발자가 혼자 개발하기 힘들어서 B개발자가 합류함
3. B개발자가 원격 저장소를 가져와서 본인도 코드를 수정함
4. B개발자가 수정한 코드를 머지함
5. A개발자도 동일한 파일을 수정함
6. A개발자가 수정한 파일을 머지하려고 보니까 충돌이 발생함.
원격
저장소
A 개발자
B 개발자
Origin/
Master
Master
Conflict!
13. Git으로 공동작업하기
1. A개발자가 Master 브랜치에 변경 내용을 commi하고 github 에 push함
2. A개발자가 혼자 개발하기 힘들어서 B개발자가 합류함
3. B개발자가 원격 저장소를 가져와서 본인도 코드를 수정함
4. B개발자가 수정한 코드를 머지함
5. A개발자도 동일한 파일을 수정함
6. A개발자가 수정한 파일을 머지하려고 보니까 충돌이 발생함.
7. 원격 저장소 변경 내용을 가져와서 변경 내용을 합치거나(Merge) 재배열(Rebase)해
서 다시 원격 저장소로 푸시함
원격
저장소
A 개발자
B 개발자
Origin/
Master
Master
14. 브랜치(Branch)란?
1. 한 저장소에서 다른 개발자와 같이 작업하고 싶을 때 브랜치를 생성하여 작업
2. 한 줄로 쌓이던 커밋을 병렬로 여러 개 동시에 쌓을 수 있음
3. 한 줄에서 작업할 경우 동일한 코드를 수정하여 충돌이 날 수 있는 부분을 해결
4. 작업이 끝나면 병합(merge)하여 브랜치를 합침
원격
저장소
Origin/
Master
Feature/a
19. Merge vs Rebase
원격
저장소
Rebase (재배열)
원격
저장소
Merge (병합)
1 2 3
master
feature/a
5 4 6
1 2 3
Origin/
Master
5
4 5 feature/a
6
20. git 명령어 - 실습
로컬
저장소
commit
pull
사용자 PC
push
fetch 원격
저장소
add
reset
워크
스페이스
(Stage 영역)
워크
스페이스
(Unstage 영역)
1. 동료 개발자가 본인 컴퓨터에 저장소를 받는다
2. 동료 개발자가 master 브랜치에서 README 파일을 수정하고
원격 저장소에 넣는다.
3. 동료 개발자가 변경한 내용을 내 로컬 저장소에 반영한다.
clone
push
pull
Push 권한이
없다면?
21. git 명령어 - 실습
로컬
저장소
commit
pull
사용자 PC
push
fetch 원격
저장소
add
reset
워크
스페이스
(Stage 영역)
워크
스페이스
(Unstage 영역)
1. B 개발자가 A개발자가 만든 프로젝트를 복사(fork)해서 내 계정에서
새로 프로젝트를 생성한다.
2. B 개발자가 feature/jiae 브랜치를 생성해서 새 파일을 생성한다.
3. B 개발자가 feature/jiae 브랜치에서 작업이 끝나면 master 브랜치와
병합I(pull-request)을 요청한다.
4. A 개발자는 B 개발자가 수정한 내용을 확인하고, master에 병합한다
22. git 명령어 - 협업
1. A개발자 프로젝트 포크해오기
$ git clone [복사한 url]
23. git 명령어 - 협업
2. 브랜치 생성하기
$ git checkout –b feature/jiae
3. Visual studio code에서 폴더 열기
30. git 명령어 - 실습
로컬
저장소
commit
pull
사용자 PC
push
fetch 원격
저장소
add
reset
워크
스페이스
(Stage 영역)
워크
스페이스
(Unstage 영역)
1. B 개발자가 A개발자가 만든 프로젝트를 복사(fork)해서 내 계정에서 새
로 프로젝트를 생성한다.
2. B 개발자가 feature/jiae 브랜치를 생성해서 새 파일을 생성한다.
3. B 개발자가 feature/jiae 브랜치에서 작업이 끝나면 master 브랜치와
병합I(pull-request)을 요청한다.
4. A 개발자는 B 개발자가 수정한 내용을 확인하고, master에 병합한다
부제: Conflict 없던 행복한 커밋
31. git 명령어 - 협업
1. git clone
원격 저장소를 복제하여 로컬 저장소를 생성
2. git fetch
원격 저장소의 변경사항을 가져와서 원격 브랜치를 갱신
3. git pull
git fretch에서 하는 원격 저장소의 변경사항을 가져와서 로컬 브랜
치에 합침
4. git checkout
다른 브랜치로 이동함. (새로운 브랜치를 생성하려면 –b 옵션 사용)
5. git branch
브랜치를 조회하고 삭제하는 명령어
6. git merge [브랜치]
[브랜치]를 현재 브랜치로 합치는 명령어
부제: Conflict 없던 행복한 커밋
32. git 명령어 - 실습
1. A개발자가 B개발자가 올린 파일을 수정하고 싶어서 master 브랜치에서 jiae.c파
일을 수정해서 commit을 push함.
2. B개발자는 feature/jiae 브랜치에서 계속 jiae.c파일을 수정함.
3. B개발자가 수정한 commit을 master에 머지하려고 보니까 conflict가 남.
4. B개발자는 다시 conflic를 해결해서 머지를 요청함.
1. [방법1] Master 브랜치에 feature/jiae 브랜치를 merge하면서 conflict를 해결한다.
2. [방법2] feature/jiae 브랜치에 master 브랜치를 rebase한 뒤에 push하고, 그 이후에 pull request를 요청함.
부제: Conflict을 해결해야 하는 골치아픈 커밋
원격
저장소
A 개발자
B 개발자
Origin/
Master
feature/
jiae
33. 1. A개발가 B개발자가 올린 파일을 수정하고 싶어서 master 브랜치에서 jiae.c파일을 수
정해서 commit을 push함.
git 명령어 - merge
부제: Conflict을 해결해야 하는 골치아픈 커밋
2. B개발자는 feature/jiae 브랜치에서 계속 jiae.c파일을 수정함.
34. git 명령어 - merge
부제: Conflict을 해결해야 하는 골치아픈 커밋
3. B개발자가 수정한 commi을 master에 머지하려고 보니까 conflict가 남.
$ git merge master
$ git merge --abort
** 참고: merge 취소
현재 브랜치
(feature/jiae)
머지할 대상 브랜치
(master)
35. git 명령어 - merge
부제: Conflict을 해결해야 하는 골치아픈 커밋
4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법1] master 브랜치에 feature/jiae 브랜치를 merge하면서 conflict를 해결한다.
.
HEAD만 남기든
Master만 남기든
둘다 합치든..
컨플릭을 해결할 것!
컨플릭 수정했으면 수정한 파일 add하기
36. 4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법1] master 브랜치에 feature/jiae 브랜치를 merge하면서 conflict를 해결한다.
.
git 명령어 - merge
부제: Conflict을 해결해야 하는 골치아픈 커밋
Conflict 해결한 것 Commit하고 push 하고 pull request 요청하기
37. 4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법2] feature/jiae 브랜치에 master 브랜치를 rebase한 뒤에 push하고, 그 이후에 pull request를 요청함.
git 명령어 - rebase
부제: Conflict을 해결해야 하는 골치아픈 커밋
- Master 브랜치 수정
-
$ git checkout master
- 수정한 파일 add, commit
38. 4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법2] feature/jiae 브랜치에 master 브랜치를 rebase한 뒤에 push하고, 그 이후에 pull request를 요청함.
git 명령어 - rebase
부제: Conflict을 해결해야 하는 골치아픈 커밋
- feature/jiae 브랜치로 이동
- 파일 수정해서 add, commit
$ git checkout feature/jiae
39. 4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법2] feature/jiae 브랜치에 master 브랜치를 rebase한 뒤에 push하고, 그 이후에 pull request를 요청함.
git 명령어 - rebase
부제: Conflict을 해결해야 하는 골치아픈 커밋
- feature/jiae 브랜치에서 master 브랜치를 rebase
$ git rebase –I master
이대로 저장하려면 :wq를 누르면 됨! (안되면 esc누르고 하기)
40. 4. B개발자는 다시 conflict를 해결해서 머지를 요청함.
[방법2] feature/jiae 브랜치에 master 브랜치를 rebase한 뒤에 push하고, 그 이후에 pull request를 요청함.
git 명령어 - rebase
부제: Conflict을 해결해야 하는 골치아픈 커밋
- 컨플릭 해결하고 수정한 파일 add하고 commit, push하기
다했으면 Master에 pull request를 요청하면 됨.
41. ** Commit을 되돌리고 싶을때.
git 명령어 – 참고
부제: Conflict을 해결해야 하는 골치아픈 커밋
- 본의아닌 속마음을 commit 메시지에 작성하거나 잘못된 파일을 올렸을 때
$ git commit --amend
수정한 커밋 저장은 :wq를 쓰면 됨.
(안써지면 esc누르고 쓰기)
42. ** add를 취소하고 싶을 때 (Stage 영역 -> Unstage 영역)
git 명령어 – 참고
부제: Conflict을 해결해야 하는 골치아픈 커밋
$ git reset HEAD [file]
** commit을 취소하고 싶을 때
$ git reset –soft HEAD^
$ git reset –mixed HEAD^
$ git reset –head HEAD^
방법1. commit을 취소하고 stage상태로 워킹 디렉터리에 보존
방법2. commit을 취소하고 unstage상태로 워킹 디렉터리에 보존 (default)
방법1. commit을 취소하고 unstage상태로 워킹 디렉터리에서 삭제
43. ** push를 취소하고 싶을 때
git 명령어 – 참고
부제: Conflict을 해결해야 하는 골치아픈 커밋
$ git reflog
$ git commit –m “Commit message”
$ git push origin [branch name] -f
3. 되돌려진 상태에서 다시 commit
4. 원격 저장소에 강제로 push
1. 브랜치와 HEAD가 가리켰던 커밋들의 리스트를 확인
$ git reset [commit id]
2. 원하는 시점으로 워킹 디렉토리를 되돌림
(remote에 강제로 덮어쓰기 때문에 추천하지는 않는 방법)
** 브랜치를 삭제하고 싶을 때
$ git branch –D [브랜치 이름]
44. Git 마무리
https://www.nicepng.com/maxp/u2w7o0i1u2e6a9w7/
1. Git vs Github
Git: 각 컴퓨터(local)에 설치되어 소스 코드 관리가 가능한 프로그램
Github: 원격저장소(remote)가 있는 외부 서버
2. Add vs Commit vs Push
Add: 로컬 작업폴더(stage 영역)에 commit할 파일을 추가하는 것
Commit: 로컬 작업폴더에 history를 쌓는 것
Push: 원격 저장소에 history를 쌓는 것
3. Fetch vs Pull
Fetch: Remote 저장소로부터 commit정보를 가져와서 임시폴더(.git)에 저장
Pull: Remote 저장소로부터 commit 정보를 가져와서 현재 브랜치에 Merge
4. Rebase vs Merge
둘다 두 branch의 차이점(commits)을 합치는 것은 똑같지만
Rebase는 합치기 전에 현재 브랜치의 작업내역에 합치려는 브랜치의 최신
commit을 끼워넣고 (commit 히스토리가 깔끔해짐)
Merge는 합치려는 브랜치를 그대로 가져와서 합친다.