티스토리 뷰
05-2. 원격 브랜치 정보 가져오기
git pull 명령은 원격 저장소의 최선 커밋을 지역 저장소에 합쳐준다.
하지만 커밋을 무조건 합치는 것이 아닌 원격 브랜치에서 정보를 가져와 확인 후 필요한 커밋만을 합칠 수 있다.
원격(=깃허브) main 브랜치
지역 저장소의 main 브랜치처럼 원격 저장소를 만들 때도 main 브랜치가 기본적으로 만들어 진다.
깃허브의 저장소에 접속 후 커밋 개수가 표시된 부분을 클릭하면 아래와 같은 화면을 볼 수 있다.
맨 마지막에 저장된 것이 add d라는 것을 알 수 있는데 이때 add d는 최종 커밋을 가르킨다.
터미널 창에서 git_home으로 이동한 후 log를 확인하여 add d가 최종 커밋을 것을 확인하여 위와 아래의 결과가 같다는 것을 알 수 있다.
아래의 사진을 확인하면 head -> main 이 있는데 이것은 이전에 말했던것과 같이 최종 커밋이라는 듯이다. origin/main은 원격 저장소의 최종 커밋이라는 뜻인데 이것을 보아 아직 git_home(로컬 저장소)의 디렉터리가 원격 저장소를 복제한 상태 그대로 더이상 커밋을 발생하지 않았다는 것을 알 수 있다.
git_home 디렉터리에 새로운 커밋을 만들기 위해 touch 명령어를 사용했다.
생성 후 a를 입력하고 저장했다.
저장하면 스테이징하고 커밋을 해야하기 때문에 아래와 같이 실행해주었다.
UserK@DESKTOP-MQJVP8M MINGW64 ~/git_home (main)
$ touch f3.txt
UserK@DESKTOP-MQJVP8M MINGW64 ~/git_home (main)
$ git add f3.txt
$ git commit -m "create f3.txt"
커밋한 후 로그를 확인해보면 main에서 방금 커밋을 새로 발생시켰으므로 create f3.txt를 가리키고 있다.
이 말은 즉 create f3.txt커밋이 최종 커밋이라는 뜻이다.
그릴고 origin/main 의 최종커밋은 아직 add d커밋이라는 것 또한 알 수 있다.
(아직 동기화 되지 않음)
$ git log --oneline
이러한 상태에서 git status를 명령을 실행한다.
이러면 현재 지역 저장소의 main 브랜치가 원격 main 브랜치의 버전보다 하나 앞서 있다는 것을 알 수 있다.
그리고 git push 명령을 사용해 지역 저종소의 커밋을 원격 저장소로 올려야한다고 메시지를 보여준다.
$ git status
지역 저장소의 커밋을 원격 저장소로 올리기 위해 git push 명령을 사용한다.
그리고 다시 로그를 확인하면 main과 origin/main 브랜치가 같은 커밋을 가리키고 있는 것을 볼 수 있다.
$ git push
$ git log --oneline
원격 브랜치 정보 가져오기 - git fetch
git fertch 명령은 원격 저장소의 정보를 가져오는 명령으로 불러오다 가져오다는 뜻이다.
이것은 pull과 비슷한데 차이점이 있다. pull 명령을 사용할 경우 무조건 합쳐진다.
하지만 fetch는 원격 저장소에서 수정한 내용을 가져와서 훑어본 후에 필요할 대만 지역 저장소에 합친다.
1. 깃허브 저장소에는 create f3.txt 커밋까지 올라가 있다.
이번에는 git_office로 이동하여 git fetch 명령을 입력해 원격 저장소에서 가져와보았다.
UserK@DESKTOP-MQJVP8M MINGW64 ~/git_home (main)
$ cd ..
UserK@DESKTOP-MQJVP8M MINGW64 ~
$ cd git_office
UserK@DESKTOP-MQJVP8M MINGW64 ~/git_office (main)
$ git fetch
2. git fetch 명령을 실행 후 로그를 확인해보았다.
그럼 head -> main 만 보이고 원격 저장소의 origin/main 은 보이지 않는데
이것의 이유는 원격 저장소의 최신 커밋은 가져왔지만 아직 지역 저장소에 합쳐지지 않았기 때문이다.
$ git log --oneline
3. git status 명령을 사용해 현재 깃의 상태를 확인했다.
그럼 현재 브랜치가 origin/main에 비해 1개 커밋이 뒤쳐져 있다고 메시지가 보인다.
그리고 git pull 명령을 사용해 지역 저장소를 업데이트 할 수 있다고 메시지가 보인다.
$ git status
5. 패치로 가져온 커밋 정보를 확인하는 명령어로 git diff 명령을 사용해 현재 최신 커밋과 원격 저장소에서 가져온 커밋의 차이를 볼 수 있다.
$ git diff HEAD origin/main
아래의 결과를 보면 +a를 보고 작성된 것을 확인할 수 있다.
이전에 a를 입력하고 저장했기 때문에 +a 라고 표기되어 있다.
6. 원격 저장소의 커밋을 확인하고 지역 저장소에 합치겠다고 결정하면 merge 명령을 사용해 합칠 수 있다.
$ git merge origin/main
7. 그 후 다시 로그를 확인하면 f3.txt 파일이 새로 생긴 것을 볼 수있다.
$ git log --oneline
* git pull 명령은 git fetch 명령과 git merge origin.main 명령을 합친것과 같다.
하지만 강제적으로 값을 넣어준다.
05-3 협업의 기본 알아보기
깃허브원격 저장소는 협업 도구로 많이 사용한다.
하나의 작업을 여러 사용자가 나누어서 진행할 때는 사용자마다 자신으 지역 저장소에서 커밋을 만들고 원격 저장소로 올리는데 이후 서로 공유한다.
이와 같이 깃허브를 통해 협업을 하려면 미리 여러 가지 약속이 필요하다.
1. 브랜치 이름을 정해야한다.
2. 레이블은 어떤 것을 사용할 것인지 정해야한다. (규칙을 정해야함 ex) -m)
3. 이슈 관리는 어떻게 할 것인지 정해야한다.
협업 과정을 실행하려면 2대 이상의 다른 컴퓨터와 다른 깃허브 계정이 필요하다.
또한, 컴퓨터마다 서로 다른 깃허브 계정을 사용해야 한다.
협업을 위한 저장소 만들기
깃허브의 공개 저장소는 주소만 알면 누구든지 접속해 모든 소스를 볼 수 있고 오픈 소스 프로젝트의 소스를 내려받을 수 있다. 하지만 누구나 저장소에 커밋을 푸시할 수는 없다.
소스 코드가 무분별하게 수정되는 일을 막기 위해 푸시를 하려면 승인된 공동 작업자여만 커밋을 할 수 있는 권한을 가질 수 있다.
협업 저장소를 만들기 위해 새로운 저장소를 만들어주었다.
아래를 보면 새로 만드는 창을 볼 수 있는데 이전의 실습과 차이점이 존재한다.
이름을 'manuls'로 설정하고 다른 것은 다 똑같지만 아래에 'Add a README file' 을 체크해야만 한다.
체크를 한 후 Create repository 를 클릭하여 저장소를 만들어준다.
* 단순히 저장소만 만들었을 경우에는 최초의 커밋이 등록되지 않으면 main 브랜치가 생기지 않는다.
저장소에 브랜치 만들기
공동 작업을 위한 저장소를 사용할 시 여러 사람이 소스를 올리기 때문에 잘못하면 커밋이 서로 꼬일 수 있고 누가 어떤 작업을 했는지 구별하기 힘들다.
그렇기 때문에 협업을 위한 저장소는 사용자별로 브랜치를 만들어 푸시한다.
각자 자신의 브랜치에 커밋을 올리고 팀장의 허가를 받아 main 브랜치를 합친다.
1. 깃허브 저장소에서 main이라는 브랜치가 표시되었는지 확인하고 표시된 부분을 클릭하면 브랜치를 추가하거나 전환할 수 있다.
새로 추가할 apple과 ms를 입력한 후 create branch apple for main 을 클릭하여 추가해주면 아래와 같은 화면을 볼 수 있다.
공동 작업자 추가하기
원격 저장소와 브랜치를 만들었으니 같이 작업할 공동 작업자를 추가한다.
원격 저장소를 관리하는 사람(=팀장)이 manuals 저장소에서 settings를 클릭한다.
그 후 collaborators를 선택한 후 add people을 클릭해 원격 저장소를 같이 사용하고 커밋할 수 있는 작업자의 이메일을 입력하여 추가한다.
그 후 공동 작업자의 이메일로 협업자로 초대되었다는 이메일과 깃허브 메시지를 받게되는데 accept invitation을 클릭하면 초대를 수락하여 공동작업자로써의 권한을 가질 수 있다.
05-4. 원격 저장소에서 협업하기
관리자(=팀장)이 원격 저장소를 만들고 다른 사람을 공동 작업자로 추가했으면 이제 공동 작업자에게 원격 저장소에 푸시할 수 있는 권한이 생긴다.
이후로 공동 작업자가 협업하는 과정을 학습한다.
원격 저장소 복제하기
공동 작업자가 되었으면 원격 저장소를 사용해서 git clone 명령을 사용해 원격 저장소를 복제(clone)하는 것부터 시작한다.
clone 명령 하나로 지역 저장소를 만들고 원격 저장소에 연결해서 최시 ㄴ커밋을 내려 받는 것까지 한번에 할 수 있다.
1. 공동 작업자가 깃허브에 접속하면 저장소 목록에 협업 저장소도 함께 나타난다.
저장소 목록에서 저장소 이름 앞에 자신의 아이디가 붙은 것은 자기가 직접 만든 저장소이고, 다른 사람의 아이디가 붙은 저장소는 협업 저장소이다.
아래를 화면을 보면 teazim 아이디를 가진 사람이 만든 manuals라는 협업 저장소라는 것을 알 수 있다.
* 협업 저장소는 '소유자 아이디/저장소 이름' 형태로 표시된다.
2. 주소창에 협업 저장소의 주소가 나타난다. 이 주소 뒤에 .git을 붙이면 저장소 주소가 된다.
3. 터미널로 돌아와 git clone 명령 뒤에 원격 저장소 주소를 붙여 넣고 지역 저장소 디렉터리 이름을 적으면 그 디렉터리로 저장소가 복제된다.
* 이때 작업은 ~(home) 디렉터리에서 실행한다.
$ git clone 원격_저장소_주소 디렉터리명
복제를 했다면 manuals 디렉터리 (지역 저장소)로 이동하여 ls -al 을 하면 README.md 파일이 생성된 것을 볼 수 있다.
윈도우에서도 manuals 디렉터리에 README 파일이 생성된 것을 볼 수 있다.
4. 원격 저장소를 복제한 후는 앞으로 자신이 직접 커밋을 만들고 깃허브로 푸시할 수 있다. 그전에 아무나 입력하면 안되니까 어떤 사람인지 구별하기 위해 커밋할 때 사용할 이름과 이메일 주소를 설정해야한다.
지역 저장소 디렉터리(manuals)로 이동한 후 git config 명령을 사용해 이름과 주소를 지정한다.
* git config명령에 --global 옵션을 붙이면 모든 저장소에서 같은 이메일 주소와 이름을 사용하게 된다.
(global 안하면 현재 폴더에서만 사용한다.)
$ git config user.name "사용자 이름"
$ git config user.email "메일 주소"
원격 저장소에 커밋 푸시하기
깃허브에 있는 manuals 저장소에는 main 브랜치외에도 apple, ms 브랜치가 존재한다.
이 저장소를 복제했다면 팀원의 지역 저장소에도 apple 브랜치와 ms 브랜치가 복제된다.
1. 공동 작업을 할 때는 내가 커밋을 올리기 전에 누군가가 우너격 저장소에 커밋을 푸시 했을 수도 있기 때문에 git pull 을 먼저 해주어야한다.
pull을 한 후 변경 사항이 있다면 내려받아서 지역 저장소에 병합해주고 없다면 'Already up to date'라고 표시된다.
$ git pull (올린 것이 없기 때문에 already up to date문구가 뜬다)
2. 사용할 브랜치로 전환 후 텍스트 파일을 만들어 작성하고 저장한다. 그리고 스테이징을 하고 '초안작성'이라는 메시지와 함께 커밋한다.
$ git switch apple
$ git add ms.txt
$ git commit -m "초안작성"
3. igt push 명령을 사용해 만든 커밋을 깃허브에 올린다.
처음 푸시할 때는 -u 옵션과 'origin apple' 처럼 브랜치 이름을 넣어 준다.
(origin 뒤에는 현재 브랜치 이름을 작성해주어야함)
$ git push -u origin apple
위와 같이 작성한 후에는 manuals 저장소에서 apple 브랜치로 클릭하여 전환하면 아래와 같이 푸시한 커밋이 올라온 것을 볼 수 있다.
풀 리퀘스트 보내기 및 병합하기
공동 작업에서 커밋을 푸시한 후에는 자신이 푸시한 커밋에 메시지를 남겨야 한다.
이러한 작업을 깃허브에서는 풀 리퀘스트라고 한다.
풀 리퀘스트를 하는 이유는 여러 사람들이 같이 작업을 하기때문에 서로 의견을 남기고 확인한 후에 커밋을 병합하는 것이다.
1. apple 브랜치에서 파일 목록 위에 있는 contribute를 클릭한 후 open pull request를 클릭한다.
그럼 풀 리퀘스트 메시지를 작성할 수 있는 창이 보이는데 메시지를 작성한 후 create pull request를 클릭하면 협업 중인 저장소에 풀 리퀘스트가 전송된다.
2. 이후로는 관리자의 화면에서 진행을 한다.
main 브랜치로 전환한 후 puu requests 를 클릭하면 아래와 같은 화면을 볼 수 있는데 보고자하는 풀 리퀘스트를 선택한다.
3. 풀 리퀘스트 메시지를 보고 내용에 문제가 없으면 merge pull request를 클릭해 병합한다.
커밋을 병합하는 것도 하나의 커밋이기 때문에 커밋 메시지를 입력해야 한다.
메시지를 입력한 후 confirm merge를 클릭한다.
그럼 open 상태였던 풀 리퀘스트가 merged 상태로 바뀐다.
4. code를 클릭하여 파일 목록으로 돌아가면 apple 브랜치로 푸시했던 '초안작성' 커밋이 main 브랜치로 병합된 것을 볼 수 있다.
'코딩 > Git' 카테고리의 다른 글
[14주 5일차] 비주얼 스튜디오 코드로 다루는 깃과 깃허브 (0) | 2024.01.13 |
---|---|
[14주 3일차] 깃허브로 협업하기 (0) | 2024.01.10 |
[14주 3일차] 깃허브 시작하기 (0) | 2024.01.10 |
[14주 3일차] 깃과 브랜치 (0) | 2024.01.10 |
[14주 2일차] Git으로 버전 관리하기 (1) | 2024.01.09 |
- Total
- Today
- Yesterday