커밋해시와 태그
커밋 해시: 각각의 커밋에 주어진 고유한 정보 (가독성을 위해서 앞부분만들 따서 짧게 쓰기도 한다)
태그: 특정 커밋을 더 가독성있게 지칭할 때 사용 (커밋에 붙이는 꼬리표)
-해시로 커밋을 지칭할 수 있는데 왜 태그를 사용하나?
유의미한 커밋에 달아주어 분기를 표시 할 수 있다.
사용자들에게 배포하기 전 마지막 커밋같은 곳에 붙인다.
ex)
0
0
0
0
0
0 <- v1.0.0 (이런식으로 태그 붙여준다)
0
0
0
0 <- v1.0.1 (분기점이 되어준다)
태그 붙이는 법
태그 붙이고 싶은 커밋을 오른쪽 클릭 → 태그 클릭 → 태그 이름 정하기 → 명시된 커밋이 이미 있다 → 태그 추가 클릭
위의 메뉴에 태그 아이콘 클릭→ 태그 이름 정하기 → 명시된 컷밋 ...눌러서 선택 → 태그 추가 클릭
태그 삭제하는 법
왼쪽 카테고리에 태그클릭하면 만들어진 태그들이 보인다 → 마우스 오른쪽 클릭 → 삭제 클릭
git 브랜치 관리하기
브랜치 나누기
#브랜치 이름 짓는 팁
메뉴 기능 추가 브랜치
feature/menu 브랜치
로그인 기능을 급하게 수정 브랜치
hotfix/login 브랜치
2.3.0버전 릴리스를 위한 브랜치
release/2.3.0브랜치
HEAD와 체크아웃
#HEAD
현재 작업 중인 브랜치의 커밋(일반적으로 최신 커밋)
내가 지금 어디서 작업 중인가?를 가리킴
이렇게 되어 있으면 foo 브랜치에는 5개 커밋
bar 브랜치에는 6개 커밋
master branch에는 4개의 커밋이 쌓여있다
#체크아웃
특정 브랜치에서 작업할 수 있도록 작업환경을 바꾼는 것
HEAD의 위치를 특정브랜치의 최신 커밋으로 옮김.
소스트리에서 실습
이름지어주고 브랜치 생성 클릭
브랜치 삭제
삭제하려는 브랜치에서 체크아웃한 상태에서
삭제하려는 브랜치 마우스 우클릭 삭제클릭
브랜치 합치기
#빨리감기 병합 (fast forward merge)
마스터 브랜치에 추가적인 커밋이 없는 상태에서
새로운 브랜치의 커밋들을 머지하는 것
#일반적인 병합 (머지)
머지할 때 기준이 되는 브랜치로 체크아웃해준다.
머지될 브랜치를 선택 마우스 우클릭
현재브랜치로 병합 클릭
브랜치 머지할 때 충돌 해결하기
#충돌이 발생했을 때 대처법
1. 충돌을 해결한다 (어떤 브랜치의 내용을 반영할지 직접 선별한다)
2. 다시 커밋한다
충돌했을 때 해결하라는 창
내것을 이용하여 해결-지금 선택된 master 브랜치 것을 이용하여 해결
저장소것을 이용하여 해결 foo 브랜치 것을 이용하여 해결
파일 상태에 들어가면 자동으로 커밋 메세지가 써져있는 것을 볼 수 있다. 커밋 누르면 완료
브랜치 재배치
rebase
↓ 재배치 (다른 브랜치의 시작 커밋을 다르게 바꿔준다)
재배치 해주고 싶은 브랜치로 체크아웃 한다.
재배치 해주고 싶은 커밋에 우클릭
재배치 클릭
foo 브랜치가 master 2 커밋에서 뻗어나올 때
foo 브랜치 파일 모습
foo 브랜치가 master 4 커밋으로 재배치 되었을 때
foo 브랜치 파일 모습
Github로 협업하기
github의 이용
#원격저장소 호스팅 서비스
repository는 프로젝트의 원격 저장소
issue 프로젝트에 대한 문의 사항, 문제점, 버그 제보, 앞으로 개발해야할 것들을 명시
star = 좋아요같은 기능
#원격저장소를 사용하는 이유
백업
협업
#README.md
md = markdown
프로젝트의 설명서
github 와 sourcetree 연동하기
#SSH (Secure Shell)
깃허브와 내 컴퓨터가 안전하게 통신을 주고받을 수 있는 방법
두개의 키(암호) 생성
공개키, 개인키
gitbash 에
ssh-keygen 엔터
Enter passphrase (비밀번호를 안 만들려면 비우고 엔터)
Enter same passphrase
어디에 만들어졌는지 위치 알려준다.
cat 퍼블릭키 위치 엔터
깃허브에 등록하는 SSH키는 여러개가 될 수 있다
setting 에 들어가서
SSH and GPG keys 클릭
나오는 비번 복사해서
github key 자리에 붙여넣기
Add SSH key
소스트리
도구에서 옵션 클릭
SSH 클라이언트 Open SSH 클릭하면 자동으로 SSH 키가 들어간다
호스팅 서비스 github 선택
선호 프로토콜 SSH 선택
OAuth 토큰 새로고침 클릭
연결창 뜬다
호스팅 계정 편집에 가면 인증 성공이라고 뜨고
확인
원격저장소와 네가지 상호작용
클론(clone):원격 저장소를 복제하기
푸시(push): 원격 저장소에 밀어넣기
패치(fetch): 원격 저장소를 일단 가져만 오기
풀(pull): 원격 저장소를 가져와서 합치기
클론실습
원하는 레파지토리로 들어간다.
code 클릭
SSH 클릭
복사 버튼 클릭
소스트리로 돌아와서
clone 클릭
소스 경로에 SSH 복사한거 붙여넣어주기
복제했을 때
내가 복제한 프로젝트의 .git 폴더까지 같이 복제된다
원격 저장소 github의 브랜치 이름
main 브랜치 : master 브랜치랑 같은거 이름만 github가 다르게 지어줬다(master의 의미가 별로라나?)
origin : 원격 저장소에 붙은 일종의 별명 (매번 긴 URL 주소를 불러주기는 불편하니까)
origin/HEAD : 원격저장소 origin의 HEAD
orgin/main : 원격저장소 origin의 main
소스트리에서 삭제하기
컴퓨터에서도 삭제해주려면 디스크에 있는 저장소를 삭제하세요를 선택
푸시실습
빈 레파지토리에
새로운 커밋들을 만들어서 넣기
리모트에 들어가서 내가 원하는 레파지토리를 선택하고 클론
빈 레파지토리에
로컬에서 많이 쌓아놓은 커밋들을 넣어주기
설정에 들어가서 추가 클릭
원격 이름과 url에 SSH를 복사해서 가져온다
확인 클릭
강사님과 미묘하게 달라서 보니까 원격 브랜치가 선택되어 있었다. 저 박스에 체크를 없애줘야 로컬 브랜치가 보인다.
패치실습 fetch
원격 저장소에 올라온 내용을 내 로컬에 합쳐주는게 아니라 받아만 보고 싶을 때
내가 지금까지 했던 작업에는 영향을 주고 싶지 않을 때
일단 github 에서도 commit을 할 수 있으니 그렇게 해줘서
로컬과 원격의 상태가 다르도록 한다.
패치를 눌러줘서 원격의 내용을 가져온다.
위는 원격 브랜치고
아래는 로컬 브랜치인가
commit 하나가 차이가 나있는 것을 볼 수 있다.
여기에서 pull을 해주거나
원격에 origin안에 있는 main을 찾아서 우클릭 하고
origin/main 을 현재 브랜치에 가져와 병합하기를 해주어도
로컬과 원격의 상태가 같아진다
풀 실습 pull
pull은 fetch 와 merge 가 동시에 되는 것이다.
아까처럼 github에서 commit 해주어
로컬과 원격의 상태를 다르게 해준다.
pull 버튼을 누르면 바로 로컬과 원격의 상태가 같아진다
풀 리퀘스트 pull request
협업을 하기 위한 방법
일반적으로 내가 소유하지 않은 원격 저장소에 푸시할 수 있을까?
일반적으로는 불가능한데
레파지토리 setting에 들어가서 collaborator에 추가해놓으면 가능하다
저번이 우리가 github 쓸 때 이 방법을 이용하였다.
아무거나 확인없이 commit하여 push하면 코드가 엉망진창이 될 수 있다.
그렇기 때문에 원격 저장소가 내 변경사항을 pull 해서 가져가도록 요청 request 하는 것
풀 리퀘스트 pull request 실습
1. 기여하려는 저장소를 본인 계정으로 포크 fork하기
2. 포크한 저장소를 클론하기
3. 브랜치 생성 후 생성한 브랜치에서 작업하기
4. 작업한 브랜치 푸시하기
5. 풀 리퀘스트 하기
fork란 내가 기여하려는 레파지토리의 복사본이 나의 계정으로 들어온다
↓
create fork 버튼 클릭
↓
내 계정에 fork 된 모습
포크를 하는 이유
내 계정의 레파지토리가 아니기 때문에 push가 불가능 했다
그러나 포크를 하게 되면 그 저장소의 주인은 나!
내가 포크한 저장소에는 push 가능
가져온 레파지토리를 소스코드에 클론하고
새로운 브랜치를 만들고
그 브랜치에 버전을 커밋한다. (이것은 이전에 배운 것이라 특별할 것이 없다)
하지만 push 할 때 꼭 내가 만든 브랜치를 포함해서 push해야한다.
풀 리퀘스트 버튼 클릭
↓
포크해온 저장소의 브랜치 add_myname에서의 버전을 원본 저장소의 main 브랜치에 적용해주세요 하는 요청
강사님 원본 저장소에 가면 pull request가 하나 들어가있는 것을 볼 수있다.
원본 저장소 주인은 pull request을 받아줄지 안 받아줄지 결정할 수 있고
그에 대한 댓글을 달아 줄 수 있다.
괜찮으면은 Confirm merge 눌러주면 된다.
그러면 open 이었던 초록색 버튼이 merge 보라색 버튼으로 바뀐다.
받아들여지거나 거절한 pull request는 closed 된다.