Git4 - CLI (4)Collaboration

https://opentutorials.org/course/3842

GIT CLI - 협업 - 생활코딩

https://youtube.com/playlist?list=PLuHgQVnccGMA4LgLoH07e7uEbRbi92Dd2 

GIT4 - CLI 협업

 

--------------------------------------------------------------------------------------------------------------------

@1. 수업 소개

git은 여러개의 저장소를 연결시켜 상호간에 동기화 시킬 수 있다.

 

여러사람들이 각각의 저장소에서 작업을 하고

이것을 모아 하나의 프로젝트를 할 수 있는

즉 협업의 도구로 깃을 사용 가능

이때 내부적으로는 브랜치가 사용이 된다.

 

동시에 작업만 안 한다면 백업과 똑같은 방법으로 협업을 할 수 있지만

동시에 작업할 때 펼쳐지는 지옥이 있다.

협업파트에선 동시에 진행되는 작업으로 인해 발생하는 충돌을 방지하는 방법을 배운다

 

--------------------------------------------------------------------------------------------------------------------
@2. 혼자 작업하기

혼자 작업하다가 다른사람이랑 같이 하게 될 것

git init a

작업하고

git add work.txt

git commit -m "work 1"

 

원격저장소 만들고

git remote add origin 주소 --origin은 별명

 

 

 

 

git push : 그냥 하면 안됨 우리 지역저장소의 master와, 원격저장소의 master브랜치를 우리가 직접 페어링, 트랙킹, 연결을 시켜줘야함. 한번만

git push -u origin master : 이러면 지역저장소의 마스터와 오리진의 마스터가 연결 + push까지 한번에 됨

 

▽git push --set-upstream origin master는왜 안써?

 : 이건 git remote add로 원격저장소를 추가한 상태에서,

처음에 딱 한번만 우리의 지역저장소와 어떤 원격 저장소를 기본적으로 연결시킬 것인가를 세팅하는 것. 이건 push까진 안되고 나머진 같은듯?

 

--------------------------------------------------------------------------------------------------------------------
@3. 같이 작업하기

우리에게 동료가 생겨서 같이 작업을 하려고 함 - 슥 협업 주제로 넘어감

 

깃허브에서 퍼블릭이든 프라이빗이든 승인을 해야 버전을 올릴 수 있다.

오픈소스는 누구나 다운로드는 받을 수 있지만 아무나 푸시를 할 순 없다.

 

Settings > Collaborators & teams >

추가가 되면 이메일이 초대된 사람에게 전달됨

수락하면

초대 + 승인이니 양자간에 승인이 체결되면서 협업자 관계를 맺게 됨

권한 지정은 여기서

 

한대의 컴퓨터에서 두개의 저장소를 만들고 그 두개가 서로 다른 사용자라고 간주하고 실습할 것. 똑같습니다.

 

협업자의 컴퓨터 세팅은

git clone ~~ 폴더명

cd 폴더명

 

--------------------------------------------------------------------------------------------------------------------
@4. push & pull

협업 상황에서 일어날 수 있는 경우의 수

(1)

->A가 작업하고 버전만들고 푸시함

->B가 원래 pull하고 작업을 시작해야되는데 깜빡, 작업하고 버전만듦, 이러고 푸시하면?

 : rejected, remote에 다른 사람이 작업한 게 있는데 그것을 당신은 아직 로컬로 가져오지 않았기 때문입니다.

이 문제를 해결하려면 git pull을 통해 가져오고

그걸 하나의 타임라인으로 잘 정리정돈해서

충돌이 일어나면 충돌을 해결하시고

다시 푸시를 시도하십쇼.

 

그럼 이 상태에서 pull하면

▽파일에는 반영이 하시겠습니까?이런거 없이 바로 되네.

 

- 병합도구를 사용하고 싶으면 git mergetool- 수동으로 수정하고 싶다면 nano work.txt 이런식으로

HEAD가 나

커밋아이디가 적힌건 다른 사람

 

깃의 메시지가 파일에 남음. 그거 다 양쪽 파일 내용 보면서 손으로 수정하면서 결국 내가 원하는 파일이 되게 한 후 저장.

 

충돌 해결하면

git add work.txt

git status로 상태 볼 수 있고

commit해야하는데

충돌 해결하고 git commit이라고만 하면

충돌했었다는 사실을 깃이 알고 있기 때문에

커밋 메시지를 자동으로 만들어줌, 내가 내용 추가 가능,

 

이 메시지를 끄면 커밋이 되고

git log로 확인할 수 있음.

두개를 조상으로 갖는 새로운 버전이 생긴거고이제 git push하면 잘 올라감

 

이 다음부터 풀 작업 푸시 반복

 

=>최대한 작업을 빨리 끝내고 push를 자주 해야지만 서로 충돌이 일어나지 않는다.작업할 때 반드시 pull을 통해서 혹시나 다른사람이 업데이트 한 게 없는지 확인하는건 너무나 좋은 습관

 

깃이 이래서 사람들이 커밋을 자주하고 푸시를 자주하고 풀을 자주하게 촉진, 커뮤니케이션을 더 활발하게 하는 장치가 됐다.

 

--------------------------------------------------------------------------------------------------------------------
@5. 원격 브랜치와 FETCH

git l(생활코딩이 알리아스 한 명령어, 전 수업들에서 한번 나옴)에서

초록색 master는 내 지역 저장소의 master브랜치

빨간색 origin/master는 내 원격 저장소중에 origin이란 이름의 저장소의 master 브랜치,

노란색은 마지막으로 마스터브랜치의 어떤 버전을 가져왔는가.

 

여기서 버전을 하나 더 만들고 git log

내 현재브랜치는 마스터고, 내 마스터 브랜치는 work 3a를 가리킴

그러나 origin/master는 여전히 이전에 있었던 abf35d9를 가리킴

즉 우리의 master브랜치가 origin/master브랜치보다 하나의 버전이 앞서있다.   

 

git status를 때려보면

앞서있으니 push를 하셔야 합니다 라고 써있다.

 

push하면

이제 master와 origin/master가 같은 브랜치(버전이겠지?)를 가리키고 있는걸 볼 수 있다.

이 상황

 

 

 

여기서 협업자인 다른애로 가서 하나 더 배울것이 있는데.

풀 커밋 푸시 와 똑같은 일을 할 수 있는게 있다.

fetch -> merge FETCH_HEAD -> commit -> push

 

git fetch를 해보면 땡겼으니 1, 2ab, 3a가 있어야될 것 같지만

만 있다.

git log 해보면

fetch전엔 원격과 같은줄,

fetch후엔 현재 내 저장소가 리모트보다 전 버전이다.

 

▽pull할 때 원격에 있는 저장소를 로컬로 복사한 다음에 머지까지하는건가? 맞는 것 같은데 그래야 내 log에 저렇게 뜨지

 

희한하게 origin/master가 master보다 한칸 더 앞선다.

왼쪽을 참고해보면 왼쪽이 푸쉬한 최종버전으로 원격저장소가 업데이트 돼 있다.

 

git status해보면

너의 master 브랜치가 origin/master보다 하나의 커밋만큼 뒤쳐져있다. git pull을 해라

 

여기서

git pull 을 하셔도 되고요

origin/master를 내 master브랜치로 merge해도 됨.

 

git merge origin/master하고 git log해보면

git pull을 한것과 똑같은 상태

 

즉 fetch를 한다는 것은 원격저장소만 update를 때리는 것.

 

git pull은 = git fetch; git merge origin/master(원격브랜치가 master라고 한다면) 이 두개를 한 것과 똑같다.

▽그 말은 pull이 원격저장소를 로컬로 복사한다는 것도 포함돼있다 라고 말하는 것과 같은듯? 그래야 git log를 했을 때 원격의 버전이 어디에 있는질 알지

 

▽저러면 fetch는 그냥 로컬 FETCH_HEAD에 한번 불러와본 것 뿐이고,

git merge origin/master면 원격이랑 머지를 한건데 사실상 pull이랑 똑같은거 아냐? (아니 원격이랑 머지를 한 게 아니고 원격의 내용을 내 저장소에 복사를 한다음에 그거랑 머지를 한것인듯)

https://ssaemo.tistory.com/74

[git] merge, git pull, branch 팁/노하우

(1)머지 해도 기존 브랜치 사라지는 거 아님.

(2)merge는 로컬에서만 이네, 

여기보면 origin/master라고 돼 있네 로컬에 있는 이게 origin master인것 같아

 

 

항상 이렇게 내가 어떤 브랜치를 병합할 것인가 신경쓰는게 귀찮으면

git은 fetch를 할 때마다 .git디렉토리 안에 FETCH_HEAD라는 파일을 만듦

cat해보면

699버전은 원격 저장소의 가장 최근에 merge한 내용. 이 적혀있다

그래서

git fetch; 하고

git merge FETCH_HEAD : 저 파일의 내용을 참고해서 가장 최근에 fetch했던 내용을 merge하는 것. git merge origin/master와 기능상으론 똑같다

 

remote branch만 가져오는 방법인 git fetch 래

▽remote branch는 가져와진 다음 활용되는거구나..?

 

신중하게 깃의 데이터를 가져오고 싶을 때 결합은 나중에하고 일단은 가져오는 것부터 하려고 할 때 fetch를 쓴다.

--------------------------------------------------------------------------------------------------------------------

- fetch가 정확히 뭐지?https://m.blog.naver.com/dejavuhyo/222380249570

Git Fetch

fetch는 원격 저장소의 데이터를 로컬에 가져오기만 한다.

pull을 실행하면, 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행하게 된다. 그러나 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용할 수 있다.

 

- origin/HEAD 가 뭐야?

https://stackoverflow.com/questions/8839958/how-does-origin-head-get-set

How does origin/HEAD get set?

origin/HEAD is set automatically when you clone a repository, and that's about it.

 

--------------------------------------------------------------------------------------------------------------------
@6. 수업을 마치며

code review도구들

Gerrit : 구글에서 안드로이드 프로젝트를 진행할 때 필요해서 만듦

개발자들의 코드품질을 상호검증하는 도구

작업한 버전을 서버로 푸시하면 투표소로감. 동료들에게 새로운 버전이 푸시된게 전파되고

동료들은 투표를 통해 그 버전이괜찮은지 어떤 개선점이 있을 수 있는지 의논함

투표가 끝나면 거절 반영 유보 가 자동화

 

코드뿐만 아니라 문서작업에도 가능해요

 

github, gutlab에도 협업을 위한 다양한 도구들을 제공

github는 issues 가 있다

버그가 있다, 어떤 개선사항을 누가 해줬으면 좋겠다 등의 커뮤니케이션을 

이메일과 게시판과 같은걸로 하는것보다

훨씬더 체계적으로 업무를 진행 가능.

insight와 같은 통계 기능을 이용하면 업무가 얼마나 활발하게 이렁나고 있는지도 하눈넹 파악

wiki와 같은 지식 공유 기능을 활용해도 좋고요

 

 

어떻게 우리팀에 깃을 도입할 것인가? 에 대한 생활코딩의 생각

버전관리와 같은 도구를 팀에 도입하려고 하면 엄청난 반발을 만나게 될 것.

협업의 중추가돼서 반발이 생기기 쉬움

포크레인이나 중장비 같은것들은 보자마자 효율이 보임

정보기술은 경험해본 사람에겐 신세계

아닌사람에겐 배워야할 귀찮은 존재. 배우는 것 자체가 일

서로 다른 맥락에서 같은 대상을완전히 다르고 보고 있는걸 이해하고 인정해야함.

 

왜 좋은걸 안쓰지?

왜 공부하는걸 싫엏지?

왜우린 후진적 으로 일을하지?

이런생각이 드는순간부터 뭔가 잘못되고 있는 것일 수도 있다 생각

 

생코는 소개할 때

이런거 보여주고 안그래도 된다는 걸 보여줌. 연차가 높을수록 감동함.

 

버전과의 차이점을 비교할 수 있고

checkout을 통해 언제든지 과거로 또는 현재로 돌아갈 수 있다는 걸 보여주면 경험이 많은 사람들은 좋아함

 

이 과정을 보여주는 시간을 전체 5분을 넘기지 않는게 좋다. 연습을 많이 하세요

 

 

알려주는 님들은 저렇게 간단한거 말고 가장 최근에 배운걸 알려주는게 신나겠지. 

그럴 땐 생택쥐베리의 말을

완벽함이란 더이상 더할것이 없는게 아니라 뺼 것이 없는 것이다.

 

나한테 신기한 것이 아니라 배우는 사람이 신기해할 걸 얘기해야함.

 

 

내가 아무리 연습한다고 해도 바로 나도 하고 싶어 라는 생각이 들 거라는 기대는내려놓으세요

절대그런일은 일어나지 낳아요

그때는 소소하게 마음이 열려잇는 사람들과 시작해보는게 좋은것같아요

그렇게 서서히 확산을 해서 미사용자들을 둘러싸

주의할점은 그분들이 소외감을 갖지 않도록 언제나 참여할 수 있는 문을 열어두기 친절하게 맞이

 

희망자가 나오면 깃을 그분들에겐 굉장히 낯선 도구이기 때문에 익숙한것처럼 포장해서 알려주기

예를 들어 dropbox쓰는 사람한텐 이거 dropbox랑 똑같아~ 근데 수동으로 버전관리를 할수 있어서 아주 정교하게 작업을 할 수가 있어~!

 

이건 이래서 좋고 간단하게 이렇게하면 하면~~ 정말좋지? 홈쇼핑처럼

 

이럴 때 중요한건 절대 어려운얘기하면안된다

reset checkout branch working copy 이런 얘기 보이는 순간에 어렵게 마음을 연 희망자들은 놀란토끼처럼 도망감

 

간단하게 저장소를 만들어주고 알려줄것은 PULL COMMIT PUSH 만

최대한 짧게짧게하면 아무 문제도 생기지 않는다 라고 얘기를 해주기

충돌이 일어나면 여러분이 직접 도와주고

 

그분들은 익숙해짐에 따라 스스로 문제점을 겪게될것

그 문제점을 해결할 수 있는 지식, 테크닉들을 최소한으로 슬쩍 옆에다 놔주는 것

 

이제 그 분들은 주인공이 된 기분을 느낄 것. 질책하면 그냥 머리가복잡할 것.

교육 끝나면 많은걸 배운것 같지만 뭐부터해야하지 이런 생각이 드는 경우가 그런경우

 

이렇게 동료들을 돕다보면 여러분이 자연스럽게 그 프로젝트의 기술적 정신적 리더가 돼 있을 것

이런방식의 리더십이 좋은건 정치를 하지 않아도 된다는 것.

 

협업을 하는 이유는 협업이 쉽기 때문이 아니라 가치 있기 때문.