본 게시글은 모두의 git,github(저자 : 강민철)의 내용을 개인적으로 정리하는 글입니다.
깃허브는 아래의 두 가지 쓰임새가 있다.
개발자의 SNS
개발자 간 협업을 가능케 하는 원격 저장소 호스팅 서비스
Git은 우리의 컴퓨터 속에만 존재하는 저장소이다.
이는 로컬에 있는 저장소, 즉 로컬 저장소라고 부른다.
반면 원격 저장소는 우리들의 컴퓨터 속에만 있는 저장소가 아닌, 인터넷 세상 어딘가에 있는 다른 컴퓨터 속의 저장소를 의미한다.
깃허브의 원격 저장소는 깃허브가 관리하는 컴퓨터 속의 저장소를 의미한다.
원격 저장소를 통해 백업과 협업에 이점이 있다.
원격 저장소와의 네 가지 상호작용
원격 저장소와의 상호 작용은 크게 네 가지이다.
clone : 원격 저장소 복제
push : 원격 저장소 밀어넣기
fetch : 원격 저장소를 merge 않고 가져오기
pull : 원격 저장소를 가져오고 merge
소스트리와 깃허브 연동하기
먼저 소스트리와 깃허브가 SSH 통신할 수 있도록 연동해야 한다.
SSH(Secure Shell)는 안전하게 정보를 주고받을 수 있는 통신 방법이다.
SSH 통신하려면 먼저 key 두 개를 생성해야 한다.
public key : 공개 키는 자신과 깃허브 둘 다 서로 가지고 있는 공개된 키를 말한다.
private key : 개인 키는 자신만 가지고 있어야 하는 개인적인 키를 말한다.
SSH 키는 ssh-keygen이라는 간단한 명령으로 생성할 수 있다.
git bash를 연다.
ssh-keygen을 입력하면 개인 키(id_rsa)를 저장할 경로를 선택하라는 문구가 나온다.
이미 SSH 키가 등록되어 있다면 아래의 명령어로 삭제하면 된다. rm -rf .ssh
id_rsa와 id_ed의 차이 아래의 사진과 같이 나는 id_ed파일이다.
그래서 GPT에게 물어보았다.
이후 패스워드를 입력해 준다. (두 번)
그러면 SSH 키가 생성되었다.
개인키는 id_rsa라는 파일이고, 공개 키는 id_ras.pub 파일이다.
소스트리에서 도구 - 옵션을 누른다.
SSH 클라이언트 설정에서 클라이언트 키를 OpenSSH로 바꾼다.
이후 SSH 키 추가를 해준다.
SSH키 경로는 위에 git bash에 적혀있다.
이 과정에서 cmd 창이 뜰 수 있는데 그때는 gitbash에서 설정한 암호를 입력하면 된다.
이후 깃허브 홈페이지에 들어가서 settings - access탭의 ssh and gpg keys를 선택한다.
new ssh key를 선택하고
이후 SSH 이름을 적고 key 항목에
공개 키 파일을 열어서 거기에 적혀있는 것을 죄다 복사해서 붙여 넣는다.
이러면 깃허브에게 공개키를 알려준 것이다.
다시 소스트리로 돌아가서 Remote 버튼을 눌러서 계정을 추가한다.
아래와 같은 화면이 나오면 아래로 스크롤해서
녹색 버튼을 누른다.
인증 성공이라는 표시가 뜨면 성공적으로 연동된 것이다.
이후 새로고침을 눌러서 원격 저장소를 선택하면 된다.
여기까지 순조롭게 완료되었다면 소스트리와 깃허브가 연동된 것이다.
clone
깃허브상에 존재하는 원격 저장소를 우리의 컴퓨터, 즉 로컬로 복사하여 가져와야 한다.
가져오고 싶은 깃허브 원격 저장소 주소를 복사한다.
이후 소스트리에 클론을 한다.
물론 자신의 원격 저장소를 클론 할 수도 있다.
브랜치 이름에 주목하자
깃에서 관리하는 기본 브랜치는 master 브랜치인데, main 브랜치는 master 브랜치와 같다.
깃허브에서는 기본 브랜치를 main 브랜치라고 부른다.
origin/HEAD 는 원격 저장소의 HEAD, origin/main 는 원격 저장소의 기본 브랜치를 말한다.
main은 원격 저장소를 로컬 저장소로 가져옴으로써 로컬 저장소의 기본 브랜치를 뜻하고, orign/main은 원격 저장소의 기본 브랜치를 뜻하고, orign/HEAD은 원격 저장소의 HEAD(작업 위치)를 뜻한다.
origin은 원격 저장소에 붙은 이름일 뿐이므로 언제든 수정할 수 있다.
push
push는 원격 저장소에 로컬 저장소의 변경 사항을 밀어 넣는 것을 의미한다.
작업 디렉터리에서 작업을 한 뒤 커밋을 하고
원격 저장소와 로컬 저장소를 동일하게 만들려면 변경 사항을 원격 저장소에 푸시해야 한다.
이렇게 푸시를 하고 나면 커밋이 추가되고 깃허브에도 커밋 수가 늘게 된다.
fetch
원격 저장소를 여러 개발자가 협업하여 개발하고 있는 상황이라면 다른 개발자가 언제든 새로운 변경 사항을 추가할 수 있기 때문에 해당 저장소는 시시각각 변할 수 있다.
다른 개발자가 푸시한 내용을 로컬로 가져오고 싶을 때 패치를 사용할 수 있다.
즉, 원격 저장소의 변경 사항을 로컬로 가져오고 싶을 때 패치를 사용한다.
소스트리에서 패치를 클릭
확인버튼 클릭
패치가 완료되면 깃허브에서 작성한 최근 커밋을 볼 수 있다.
로컬의 main 브랜치는 이전의 커밋을 가리키고, origin/main 브랜치는 최신 커밋을 가리킨다.
즉, 패치해도 원격 저장소의 내용이 로컬 저장소에 병합되지 않는다.
pull
fatch가 단순히 가져오는 것이라면 pull은 fatch와 merge가 같이 일어나는 것이다.
소스트리에서 Pull을 클릭한다.
이렇게 하면 원격 저장소의 변경 사항이 즉시 로컬로 병합된다.
pull request
자신이 소유하지 않은 원격 저장소에 특정한 방법으로 푸시를 할 수 있지만 일반적으로는 불가능하다.
원격 저장소에 누구나 푸시할 수 있다면 여러 문제가 발생할 수 있다.
푸시 권한이 없는 원격 저장소에 코드를 푸시하려면 풀 리퀘스트를 통해 할 수 있다.
원격 저장소가 내 변경사항을 풀(pull) 하도록 요청(request)하는 것이다.
풀 리퀘스트는 아래와 같은 단계로 이뤄진다.
기여하려는 저장소를 본인 계정으로 포크 하기
포크 한 저장소를 클론 하기
브랜치 생성 후 생성한 브랜치에서 작업하기
작업한 브랜치 푸시하기
풀 리퀘스트 보내기
풀 리퀘스트의 첫 번째 단계는 기여하려는 저장소를 본인 계정으로 포크 하는 것이다.
포크(fork)는 원격 저장소를 본인의 계정으로 복제하는 것이다.
포크를 하면 본인의 계정으로 해당 저장소가 복제된다.
소유하지 않은 원격 저장소에는 푸시할 수 없지만, 본인 계정으로 포크 한 원격 저장소에는 푸시할 수 있다.
이후 포크한 저장소를 클론 한다.
추가적으로 클론 뒤에 브랜치를 생성하고 해당 브랜치에서 작업을 해야 한다.
작업을 완료했다면 커밋을 하고, 브랜치를 푸시한다.
마지막으로 풀 리퀘스트를 보내야 한다.
깃허브로 돌아와서 포크 한 저장소로 들어가면 Compare & full request가 생성되었다.
이후 커밋 메시지와 풀 리퀘스트로 보낼 작업 내용을 확인할 수 있다.
확인했다면 Create pull request를 클릭하면 요청이 완료된다.
Collaborator로 추가하여 푸시 권한 주기 원격 저장소 소유자가 다른 사람을 Collaborator로 추가한 경우에는 소유하지 않은 계정의 원격 저장소에 풀리퀘스트 없이 푸시할 수 있다. Collaborator 추가할 계정을 입력하면 요청이 된다. 요청을 받은 계정이 이를 승인하면 해당 계정은 풀리퀘스트 없이 푸시할 수 있다.
본 게시글은 모두의 git,github(저자 : 강민철)의 내용을 개인적으로 정리하는 글입니다.
브랜치란?
브랜치는 마치 줄기에서 뻗어 나오는 나뭇가지와 같이 버전을 여러 흐름으로 나누어 관리하는 방법이다.
브랜치는 버전의 분기이다.
작업을 분기하고 싶을 때 브랜치를 나누면 된다.
버전을 나누어 관리하는 것은 아래의 3단계로 버전을 관리하는 것을 의미한다.
브랜치를 나눈다.
각자 브랜치에서 작업한다.
(필요할 경우) 나눈 브랜치를 합친다.
브랜치 나누고, 합치기
깃이 제공하는 가장 기본적인, 최초의 브랜치를 master 브랜치라고 한다.
가령 로컬 저장소를 만들고, 커밋 세 개를 만들었다고 가정하자
이 커밋 모두는 master 브랜치에 속한다.
master 브랜치에 만들어진 세 커밋을 master 1번 커밋, master 2번 커밋, master 3번 커밋이라고 한다면
마스터 브랜치는 아래와 같다.
master의 최신 커밋에서 foo라는 브랜치를 만들고, foo 브랜치에 커밋을 두 개 추가하면 아래의 왼쪽과 같다.
이후 master의 최신 커밋에서 새로운 커밋을 추가하면 아래의 오른쪽과 같다.
여기서 주목해야 할 점은 master 브랜치 입장에서는 커밋이 세 개 밖에 없다는 점이다. 반면, foo 브랜치 입장에서는 커밋이 5개이다. foo는 master 브랜치의 세 번째 커밋에서 뻗어 나온 브랜치이기 때문에 master 브랜치의 커밋 세 개를 모두 포함하고 있기 때문이다.
여기서 master의 4번 커밋에서 bar라는 브랜치를 나누고, bar에 두 개의 커밋을 추가하면 아래의 그림과 같다.
HEAD와 체크 아웃
HEAD는 현재 작업 중인 브랜치의 최신 커밋을 가리키는 일종의 표시이다.
보통은 현재 작업 중인 브랜치의 최신 커밋을 가리키지만, 브랜치를 나누고 합치는 과정에서 HEAD의 위치를 자유자재로 바꿀 수 있다.
체크아웃은 특정 브랜치에서 작업할 수 있도록 작업 환경을 바꾸는 것을 의미한다.
특정 브랜치로 체크아웃하게 되면 HEAD의 위치가 해당 브랜치의 최신 커밋을 가리키고, 작업 디렉터리는 체크아웃한 브랜치의 모습으로 바뀌게 된다.
브랜치 나누고, 합치기 소스트리 실습
브랜치 나누기
위 그림과 같이 브랜치를 나눠보자
현재 master 브랜치 3번째 커밋 상태이다.
여기서 상단의 브랜치 버튼을 누른다.
브랜치 이름을 입력하고, 새 브랜치 체크아웃을 체크한다.
foo 브랜치로 체크아웃한다는 뜻은 작업 환경을 foo 브랜치로 바꾼다는 의미이다.
마지막으로 브랜치생성 버튼을 누른다.
아래처럼 foo가 진하게 표시되어 있다면 현재 작업 환경이 foo 브랜치임을 나타낸다.
이후 foo 브랜치에서 커밋 두 개를 추가한다.
현재 상황은 아래와 같다.
위에서 언급했듯이 이 상황에서 foo 브랜치가 아니라 master 브랜치로 체크아웃하면 HEAD는 master 3번 커밋을 가리키게 되고, 작업 디렉터리의 파일들도 master 3번 커밋으로 되돌아가게 된다.
master의 최신 커밋인 4번 커밋에서 bar 브랜치를 추가하고, 커밋 세 개를 추가하자.
여기까지 완료했다면 현재 상황은 아래와 같다.
브랜치 병합
브랜치를 하나로 통합하는 것을 병합, 영어로 merge라고 한다.
빨리 감기 병합(fast-forward merge)
위에서 작업했던 브랜치를 예로 들면, master 브랜치와 foo 브랜치를 병합하면 아래와 같은 모양이 된다.
master 브랜치 입장에서는 자신의 브랜치가 마치 빨리 감기 하듯이 foo 브랜치와 동일하게 업데이트되었다.
이처럼 master 브랜치가 빨리 감기 하듯 foo와 동일해질 수 있었던 이유는, foo 브랜치가 master 브랜치에서부터 뻗어 나온 시점부터 병합되는 순간까지 master 브랜치에 어떤 변화도 없었기 때문이다.
그렇기 때문에 foo 브랜치를 master 브랜치로 병합할 때 master 브랜치는 그저 foo 브랜치에 새롭게 쌓인 커밋을 반영만 하면 된다.
이처럼 변화가 없었던 브랜치가 마치 빨리 감기 하듯 업데이트되는 병합 기법을 빨리 감기 병합(fast-forward merge)라고 한다.
빨리 감기 병합 소스트리 실습
먼저 master 브랜치로 체크아웃한다.
이후 foo 브랜치 위에 마우스를 두고 마우스 오른쪽 버튼을 클릭한다.
여기서 현재 브랜치로 foo 병합 버튼을 누르면 병합이 된다.
확인을 눌러준다.
이제 master 브랜치는 foo 브랜치와 같아졌다.
브랜치를 병합하고 나서 더 이상 브랜치에 남은 작업이 없다면 해당 브랜치를 삭제하는 것이 좋다.
foo 브랜치를 삭제해 보자.
브랜치를 삭제하려면 삭제하려는 브랜치가 아닌 다른 브랜치에 체크아웃되어 있어야 한다.
foo 브랜치 위에 마우스를 두고 마우스 우클릭을 한다.
확인 버튼을 누른다.
foo 브랜치가 삭제된 결과는 아래와 같다.
빨리 감기 병합이 아닌 병합
빨리 감기 병합이 아닌 병합은 bar 브랜치에는 없는 커밋이 master 브랜치에 있고, master 브랜치에는 없는 커밋이 bar 브랜치에 있는 상태에서 두 브랜치를 병합하는 것을 뜻한다.
즉, bar 브랜치가 master 브랜치에서부터 뻗어 나온 시점부터 병합되는 순간까지 master 브랜치에 어떤 변화가 있을 때 병합하는 것을 뜻한다.
이런 상황에서는 새로운 커밋이 생성된다.
master 브랜치와 bar 브랜치의 4번 커밋과 병합하면 아래와 같다.
이후 master 브랜치와 bar 브랜치의 6번 커밋과 병합하면 아래와 같다.
빨리 감기 병합이 아닌 병합 소스트리 실습
master 브랜치와 bar 브랜치의 4번 커밋과 병합해 보자.
상단의 병합에서도 브랜치를 병합할 수 있다.
master 브랜치에 병합할 브랜치의 커밋을 클릭한 뒤 확인을 누르면 해당 커밋이 병합된다.
위 그림처럼 bar 브랜치의 4번 커밋을 master 브랜치로 병합하려면 4번 커밋을 클릭한 뒤 확인을 클릭하면 된다.
결과는 아래와 같다.
이번에는 master 브랜치와 bar 브랜치의 6번 브랜치와 병합해 보자
상단의 병합 버튼을 누른 후, bar 브랜치의 6번 커밋을 선택하고 확인을 누른다.
결과는 아래와 같다.
충돌과 해결
충돌
충돌이란 병합하려는 두 브랜치가 서로 같은 내용을 다르게 수정한 상황을 의미한다.
충돌은 여럿이 협업하여 개발할 때 빈번히 발생하므로 언제 발생하고, 어떻게 해결할 수 있는지 꼭 알아야 한다.
예를 들어, master 브랜치에서 foo 브랜치가 뻗어 나왔다고 하자.
master 브랜치는 a.txt 파일의 첫 번째 줄을 B로 수정한 다음 커밋했고, foo 브랜치는 a.txt 파일의 첫 번째 줄을 C로 수정한 다음 커밋했다.
이런 상황에서 foo 브랜치를 master 브랜치에 병합한다면 a.txt 에서 충돌이 발생했다고 한다.
충돌이 발생하면 최종적으로 어떤 브랜치의 내용을 반영할지 우리가 직접 선택해야 한다.
위 상황을 소스트리로 나타내면 아래와 같다.
이제 병합하면 아래와 같이 오류가 뜬다.
a.txt에 변화가 생겼다.
충돌이 발생하면 커밋하지 않은 변경사항이 생기고, 스테이지에 올라가지 않은 파일과 스테이지에 올라간 파일 항목에는 충돌이 발생한 파일이 추가된다.
a.txt를 열어보면 아래와 같다.
해결
충돌이 발생한 파일들의 충돌을 해결한 뒤 다시 커밋해야 브랜치가 올바르게 병합된다.
충돌이 발생한 이유는 병합하려는 두 브랜치가 같은 내용을 서로 다르게 수정했기 때문이다.
따라서 충돌이 발생하면 충돌이 발생한 두 브랜치 중 어떤 브랜치의 내용을 병합 결과에 반영할지 선택하면 된다.
같은 내용을 다르게 수정한 브랜치 중 어떤 브랜치 내용을 최종적으로 반영할지를 직접 선택하는 것을 '충돌을 해결한다'라고 한다.
a.txt의 내용은 아래와 같다.
충돌이 발생한 파일에는 <<<<<<<<<<<<<<, >>>>>>>>>>>, ========== 기호가 표기된다.
이 기호는 일종의 영역 표기이다.
=======를 기준으로 윗부분은 HEAD가 가리키는 브랜치, 즉 현재 체크아웃한 브랜치의 내용이 적혀있고
아랫부분은 병합하려는 브랜치, 즉 foo 브랜치의 내용이 적혀있다.
이 두 영역 중 반영할 부분을 직접 선택해 충돌을 해결해야 한다.
나는 master 브랜치의 내용을 반영하겠다.
스테이지에 올라가지 않은 파일 항목에 있는 a.txt 파일에서 충돌 해결을 클릭하면 '내 것'을 이용해 해결 항목과 '저장소'것을 사용하여 해결 항목이 있다.
'내것'은 현재 체크 아웃된 브랜치의 내용을 병합에 반영하겠다는 의미이다
'저장소'는 병합하려는 브랜치의 내용을 병합에 반영하겠다는 의미이다.
나는 master 브랜치의 내용을 반영할 것이고, 현재 master에 체크아웃되어있기 때문에 '내 것'을 선택하겠다.
확인 버튼을 누른다.
이제 소스트리에는 아래와 같이 표기된다.
이제 충돌이 해결되었으니 커밋을 해주어야 한다.
커밋까지 완료하면 아래와 같이 된다.
브랜치 재배치하기
브랜치 재배치는 브랜치가 뻗어 나온 기준점을 변경하는 것을 말하고, rebase라고 한다.
아래의 상황은 위 그림의 왼쪽과 같다.
우리는 위 그림의 오른쪽이 되는 것이 목표이다.
브랜치를 rebase 하려면 재배치하려는 브랜치로 체크아웃해야 한다.
따라서 foo 브랜치로 체크아웃한다.
이후 master 브랜치의 4번 커밋으로 브랜치를 재배치할 예정이므로 master의 네 번째 커밋에서 마우스 오른쪽 버튼을 클릭 후 재배치를 클릭한다.
본 게시글은 모두의 git,github(저자 : 강민철)의 내용을 개인적으로 정리하는 글입니다.
로컬 저장소 만들기
소스트리 실행 후 Create를 누른다.
버전을 관리할 작업 디렉터리를 설정한다.
이렇게 설정하면 C:\git-test가 작업 디렉터리가 된 것이다.
이후 해당 폴더에 a.txt, b.txt, c.txt를 추가하면 아래와 같은 화면이 뜬다.
모두 스테이지에 올리기 또는 선택 내용 스테이지에 올리기 버튼을 누르면 해당 파일은 스테이지로 올라가게 된다.
스테이지의 내용을 저장소에 올리는 것을 커밋이라고 한다.
커밋을 하기 전에 버전을 설명하는 메시지인 커밋 메시지를 작성해야 한다.
커밋 메시지는 제목과 본문으로 보통 작성한다.
커밋 메시지를 작성하였다면 커밋 버튼을 눌러서 스테이지의 내용을 저장소로 옮긴다.
만든 커밋 내역들은 History에서 볼 수 있다.
변경내용 확인하기
a.txt를 수정하고, c.txt를 삭제해보자.
이렇게 되면 파일 상태에서 변경된 내역을 확인할 수 있다.
이제 수정된 내용을 스테이지에 올리고 커밋을 해보자.
그래프를 보면 동그라미 두 개가 연결되어 있는 것을 볼 수 있다.
여기서 동그라미 하나는 커밋 하나, 즉 하나의 버전을 나타낸다.
두 번째 커밋의 동그라미가 첫 번째 커밋의 동그라미와 연결되어 있는 것은 두 번째 커밋이 첫 번째 커밋에서부터 만들어진 버전임을 나타낸다.
tracked 파일과 untracked 파일 d.txt를 추가해보자. d.txt를 추가하면 소스트리 파일 상태에 아래와 같은 모습을 볼 수 있다.
물음표 모양의 아이콘은 깃이 기존에 변경 사항을 추적하지 않았던 새로운 파일을 의미한다. 즉 untracked 파일인 것이다. 반면에 한 번이라도 스테이지에 올라 왔거나 커밋을 했다면 tracked 파일이다.
.gitignore로 무시하기 변경 사항을 추적하고 싶지 않은 파일이나 폴더가 있을 수 있다. 이러한 파일이나 폴더는 .gitignore로 무시할 수 있다.
메모장을 하나 만들고 파일 이름과 확장자를 모두 지우고 확장자를 .gitignore로 설정한다. .gitignore파일에 무시하고 싶은 파일을 적는다.
여기에 적힌 파일은 추적하지 않게 된다.
또한 폴더를 무시하고 싶다면 .gitignore파일에 무시하고 싶은 폴더명을 적되, 뒤에 /를 붙인다. 이렇게 하면 해당 폴더도 추적하지 않게 된다.
