개발자입니다
[비트캠프] 12일차(3주차2일) - 리눅스 명령어, git 명령어, git(충돌, 브랜치) 본문
[비트캠프] 12일차(3주차2일) - 리눅스 명령어, git 명령어, git(충돌, 브랜치)
끈기JK 2022. 11. 22. 12:05
리눅스 명령어
file
파일의 유형을 알려준다.
[vagrant@host1 bitcamp-ncp]$ file .gitignore
.gitignore: ASCII text
less
내용물을 보는데 한 페이지만 확인한다. 스페이스 바 누르면 다음 페이지로 넘어간다.
[vagrant@host1 bitcamp-ncp]$ less .gitignore
touch
파일을 생성한다.
[vagrant@host1 tmp]$ touch hello.txt
파일 권한
ls -al에서 나오는 권한 정보는 다음과 같다.
drwxrwxr-x| d | rwx | rwx | r-x |
| 디렉토리 여부 | 소유주 권한 | 소유주 소속 그룹 권한 | 소유주와 상관없는 사람의 권한 |
폴더가 파일을 직접 담는게 아니라 다른 파일의 링크 정보를 담는다.
폴더의 크기는 파일 크기의 총합이 아니라 담고 있는 파일의 정보에 대한 크기이다.
Git 명령어
git checkout [파일]
작업 디렉토리의 파일을 변경한 후 변경 전으로 되돌릴때 사용한다.
Staging Area의 파일은 checkout 대상이 아니다.
Staging Area에 등록된 것이 없다면, 최종 커밋한 버전으로 되돌린다.
Staging Area에 등록된 것이 있다면, 현재 Staging Area에 기록된 버전으로 되돌린다.
git checkout
git rm
git rm [파일] 입력시 Staging Area에 삭제 파일 정보를 등록한다.
commit 시 파일 삭제된다.
git rm a.txt
Linux에서 git 버전 업데이트
wandisco 저장소를 설치한다.
sudo yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-1.noarch.rpm참고 : https://dololgun.github.io/linux/centos7-git-install/
Staged → Committed 로 되돌리기(Staged → Modified → Committed)
한 번에 되돌리는건 안되고 두 번에 걸쳐서 되돌릴 수 있다.
1) Staged → Modified 로 상태 변경
git reset HEAD [파일]
Staging Area의 현재 스냅샷에서 빼고 싶은 파일이 있을때 사용한다. (Staged → Modified)
HEAD 없이 git reset [파일] 도 가능한 경우 있다.
[vagrant@host1 bitcamp-ncp]$ git status --short
M b.txt
[vagrant@host1 bitcamp-ncp]$ git reset HEAD b.txt # 현재 스냅샷에서 제거
Unstaged changes after reset:
M b.txt
[vagrant@host1 bitcamp-ncp]$ git status --short
M b.txtHEAD : 작업 디렉토리에 로딩한 브랜치를 가리킨다.
2) Modified → Committed 로 상태 변경
git checkout [파일]
Modified 파일을 최종 로컬 저장소의 commit 버전으로 돌릴때 사용한다.
[vagrant@host1 bitcamp-ncp]$ git checkout b.txt
git fetch
pull = fetch + merge 로 fetch는 다운로드만 받는다.
[vagrant@host2 bitcamp-ncp]$ git fetch
[vagrant@host2 bitcamp-ncp]$ git log --oneline --graph --all
* 19271a2 (origin/main, origin/HEAD) 13
* 4c879d2 (HEAD -> main) 12
* be9028c 11
* 08b3bda Merge branch 'main' of https://github.com/jongkwangyun/bitcamp-ncp
|\
| * 4ad13d8 Initial commit
* 0dfb218 6
* afce3ff 5
* 82582e7 4
* 238344b 3
* 5117279 2
* 2b432db 1git pull : 서버의 버전을 가져온 다음에 로컬 버전과 합쳐서 로컬의 HEAD가 마지막 버전을 가르키도록 한다.
git fetch : 서버의 버전을 가져온다. 합치지는 않는다.
git merge
merge시(또는 pull시) 파일 상태에 따라 2가지 방법으로 진행된다.
Fast-forward
로컬에 있는 이전 버전이 서버의 버전 순서와 같을 경우 합치기 쉽다. 그대로 이어 붙이고 HEAD를 마지막 버전으로 이동시키면 된다.
다운받은 파일과 합치며, 로컬의 HEAD가 가리키는 곳이 12 → 13 로 변경된다.
[vagrant@host2 bitcamp-ncp]$ git merge
[vagrant@host2 bitcamp-ncp]$ git log --oneline --graph --all
* 19271a2 (HEAD -> main, origin/main, origin/HEAD) 13
* 4c879d2 12
* be9028c 11
* 08b3bda Merge branch 'main' of https://github.com/jongkwangyun/bitcamp-ncp
|\
| * 4ad13d8 Initial commit
* 0dfb218 6
* afce3ff 5
* 82582e7 4
* 238344b 3
* 5117279 2
* 2b432db 1
각기 다른 파일 편집 후 merge
서버에 b.txt가 있고 로컬에 a.txt가 있을때 pull 할 경우 병합 해야한다.
[vagrant@host1 bitcamp-ncp]$ git log --oneline --graph --all
* d383a70 (HEAD -> main, origin/main) 18
[vagrant@host1 bitcamp-ncp]$ git pull
# fast-forward 불가하여 병합 해야함. vi 에디터에서 21 입력
[vagrant@host1 bitcamp-ncp]$ git log --oneline --graph --all
* bb3c142 (HEAD -> main, origin/main) 21
Source Tree 다운로드
git client 검색 - 다운로드
mercurial 체크 해제한다.
ssh 키 아니오 선택한다.
conflict 상황
파일 편집 후 pull시 충돌하는 상황이다.
host1에서 a.txt를 편집하고 서버에 push 했다.
# 추가
host1=>xxx
host2에서 a.txt를 다음과 같이 편집했다.
# 추가
host2=>yyy
git merge시 CONFLICT 발생한다.
[vagrant@host2 bitcamp-ncp]$ git merge
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.
[vagrant@host2 bitcamp-ncp]$ git log --oneline --graph --all
* de9090e (HEAD -> main) 23
| * 2f572f5 (origin/main, origin/HEAD) 22
|/
* bb3c142 21
변경된 파일 확인하면 아래와 같이 나온다.
======= 부분을 중심으로 위쪽은 로컬, 아래쪽은 리모트 내용이다.
개발자가 직접 편집하고 push 해야한다.
[vagrant@host2 bitcamp-ncp]$ cat a.txt
1111
2222
3333
4444
5555
6666
7777
8888
9999
<<<<<<< HEAD
host2=>yyy
=======
host1=>xxx
>>>>>>> refs/remotes/origin/main현재 편집중일때는 pull이 안된다.
branch
HEAD는 현재 작업 브랜치를 가리킨다.
git branch [이름]
새 branch 생성시 사용하는 명령어이다.
git branch -d [브랜치 명]
브랜치 삭제시 사용하는 명령어이다.
git branch -vv
브랜치의 상태를 자세하게 나타내는 명령어이다.
[vagrant@host1 bitcamp-ncp]$ git branch -vv
b1 7fb3083 a.txt 커밋
* main 7fb3083 [origin/main: ahead 1] a.txt 커밋
checkout
HEAD가 다른 브랜치를 가리키면 그 브랜치의 최신 버전 파일을 작업 디렉토리에 꺼낸다.
checkout : HEAD가 가리키는 브랜치의 최신 버전을 작업 디렉토리에 꺼낸다.
git checkout [브랜치명]
입력하면 HEAD는 해당 브랜치를 가리킨다.
[vagrant@host1 bitcamp-ncp]$ git checkout b1 # HEAD 옮기기
Switched to branch 'b1'
[vagrant@host1 bitcamp-ncp]$ git branch
* b1
main
[vagrant@host1 bitcamp-ncp]$ git log --oneline
9bb31ad (HEAD -> b1, origin/main, main) 24
de9090e 23
2f572f5 22
b1 branch를 26까지 진행하고 git checkout main하면 main의 마지막 버전인 24를 작업 디렉토리에 꺼낸다.
merge
git merge [브랜치 이름]
현재 브랜치에서 해당 브랜치를 병합한다.
main에서 merge시 27번이 안생긴 이유?
→ main의 24번은 b1의 분기 이후에 변경된 적이 없다. 따라서 b1 브랜치의 버전을 main 24번 이후에 그대로 이어붙여도 문제가 되지 않는다. 쓸데없이 새 스냅샷을 만들지 않는다.
→ Fast-Forward
일반적으로 b1 브랜치를 main에 합치면 b1을 지워야 한다.
팀 branch 사용 예
git 작업 순서
① 서버에서 clone or pull
② b1 브랜치 생성
③ main으로 merge
④ 서버의 23번 pull
⑤ 3번+23번 => 24번 merge
⑥ 서버로 push
⑦ b1 브랜치 삭제
git ls-remote
원격 레퍼런스 조회 명령어
[vagrant@host1 bitcamp-ncp]$ git ls-remote
From https://github.com/jongkwangyun/bitcamp-ncp
15449eadbad44aaaa539ecd34eb9681d9e038f4f HEAD
15449eadbad44aaaa539ecd34eb9681d9e038f4f refs/heads/main
조언
*기술 역량을 확보했다 = 이해한 상태이며 책을 보면 빨리 할 수 있다.
*리눅스 만든 리누스 토발즈 "최대한 브랜치를 활용하라"
*기술을 받아들일때 왜 이렇게 쓰는지 이의 제기 하지 마라. 다른 모든 사람들은 잘 쓰고 있다.
과제
팀 리파지토리 작업하기
*테스트용 리파지토리 만들기
bitcamp-test로 리파지토리 만든다. (README 체크)
해당 리파지토리 - Settings - Collaborators - Add people - 이름 입력하여 초대
1) 팀을 구성한다.
2) 팀원 중 한 명이 github 사이트에 팀 프로젝트용 깃 저장소를 생성한다.
깃 저장소 이름 : bitcamp-test
3) 깃 저장소를 다른 팀원들이 쓸 수 있도록 협력자(Collaborator)로 등록한다.
4) 각 팀원은 팀 프로젝트용으로 만든 깃 저장소를 로커롤 clone 한다.
5) 각 팀원은 브랜치를 생성한 후 임의의 파일 생성, 변경, 삭제 작업을 진행한다.
6) 각 팀원은 브랜치에서 작업한 내용을 최소 3번 이상 커밋을 수행한다.
7) 각 팀원은 브랜치로 작업한 내용을 로컬 main 브랜치에 합친다.
8) 각 팀원은 로컬 main 브랜치의 커밋 내용을 팀 공유 서버 저장소에 push 한다.
- push 하다가 충돌 발생 시, 충돌 내용을 로컬에 병합한 후 서버 저장소에 올려야 한다.
[과제 제출 내용]
1) 수강생 깃 이름:
2) 팀 공유 깃 저장소 URL:
