(git) 13 - 협업하기 (혼자 / 소규모 / 대규모)

■ 혼자하기

 

Readme file 체크하면 자동으로 main 브랜치가 생기고 commit 도 한 개 생긴다.

 

 

git merge --no-ff (머지하고자 하는 브랜치)

fast-foward merge 는 원래 커밋로그 안남는데, 남기게 해주는게 --no-ff 이다.

 

 

git tag 태그이름 : 태그 이름 달아주기

 

 

태그가 달린 것 확인 가능

 

 

git tag -n : 어디에  tag  달렸는 지 확인

 

 

git push --tags origin main : 태그와 함께 올리기

 

■ 소규모 협업

* 팀장

 

환경 구성 후 dev 브랜치 만들고 올리기

 

최초에는 모든 브랜치 올리는 git push --all 해준다.

 

 

collaborators -> add people : 협업할 대상자 추가해주기

 

 

Branches 에서 이름이 main 인 것에 공통룰을 설정해준다.

Require a pull request before merging 을 하면 승인받은 사람만이 push 할 수 있다.  (보호받는 브랜치)

 

 

보호받는 브랜치에 merge 요청 -> PR 요청(pull request)

 

 

보통 dev에 올리지 않고 본인만의 topic 브랜치를 만들고

거기서 작업한 후에 PR 요청을 통해 dev 브랜치에 반영한다. 

 

dev에다가 join_topic 을 merge 해도 될지 pull request 를 한다. 

 

 

draft pull 은 중간 보고 코드 리뷰때 사용한다. 

 

 

보호받는 브랜치이기 때문에 merge 가 막혀있다.

따라서 권한 있는 아이디로 로그인해서 pull request 를 확인해본다.

 

 

참고로 권한 있는 아이디에서 email notification 을 설정해두면 push 가 있을 때 알 수 있다. 

※ webhook도 비슷하게 이벤트가 있을 때 알려준다. 

 

 

review changes 를 클릭하면 3가지 옵션이 뜬다.

 

1. comment : 코멘트 남기기(중간 보고일 경우 업무 지시 코멘트) -> draft

2. approve : 승인

3. request changes : 거절

 

 

merge pull request 를 팀원이 할 수 있는 상태가 된다. 

 

 

squash merge  하면 로그 1개로 압축해서 커밋

보통 승인하는 사람이 squash merge 하진 않는다. 

 

 

confirm merge 하면 pull request 가 사라지고 다음과 같이

dev 브랜치에 join_topic 에서 pull request 를 받은 기록을 볼 수 있다. 

 

 

다 사용한 브랜치는 일정 기간 유지하다가 사용이 완료되면 저장소에서 삭제 처리한다.

로컬저장소에는 가지고 있는다. (혹시 모를 상황에 대비하여)

 

 

다음과 같이 처리하면 내 dev 는 동기화 되지 않았다.

 

 

내 저장소에 dev 동기화 시켜주기

 

※ 3가지 merge 타입

 

1. merge

 

하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합치는 방법

commit a, b, c를 refer 하는 m이 생성되고 m 을 통해 a + b + c 가 master 브랜치에 추가된다.

 

2. squash and merge

commit a+b+c 를 합쳐서 새로운 commit, abc 가 만들어지고 master 에 추가된다.

abc는 1개의 parent 을 가진다.

feature 브랜치의 여러 개의 commit history를 합쳐서 하나로 깔끔하게 만들기 위해 사용한다.

 

3. rebase and merge

 

모든 commit들이 합쳐지지 않고 각각 master  브랜치에 추가된다.

각 commit 은 모두 하나의 parent 를 가진다. 

 

merge는 merge commit 기록이 추가로 남게 되지만,

rebase의 경우에는 branch 병합 시 merge commit 기록이 남지 않아

하나의 브랜치에서 작업한 것처럼 보인다.

 

※ 참고

https://im-developer.tistory.com/182

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)

 

■ 형상 안맞아서 나는 오류

 

github 에 있는 형상과 내가 로컬에서 rebase를 해서 형상이 맞지 않는다. 

 

 

따라서 우리가 rebase 처리한 것을 origin 에 push 처리하면 에러가 뜬다.

그래서 안내 창에는 pull 받고 push 를 하라고 하는데 그러면 이전에 rebase 했던 것이 다시 원복된다.

 

git push -f origin login_topic

따라서 이럴 경우에는 강제로 push 처리해준다.

※ rebase는 반드시 자기 topic 에서만 해야한다.

 

 

개발 완료 후 해당 토픽 브랜치 원격저장소에서 삭제처리하기

 

 

dev 에 업데이트된 2개의 커밋 받아오기

 

■ main 에 반영하기

 

관리자가 마찬가지로 dev 에서 pull 로 모든 내용 가져온다.

 

 

커밋 로그 남기기 위해 git merge --no-ff dev 처리한다.

 

 

태그 붙이고 push 처리하기

 

■ ci/cd

 

코드 완료까지가 우리가 배운 것이다.

이렇게 완료된 코드를 지속적으로 바뀌었는지 감시하고 push 하는게 ci 도구가 도와준다.

 

ci : 지속적인 통합

cd : 지속적인 배포 

※ 지속적인 통합을 가능하게 하는 ci 도구로는 jenkins 와 trav 등이 있다.

 

테스트하고 jar 파일로 변경하여 배포한다.

aws 나 azure 클라우드에 배포한다.

 

 

배포스크립트의 내용을 참고하여 jar 파일을 실행해서 사용 가능하다.

 

aws 네트워크 개념, 리눅스 등을 알아야 ci 쓰는 것 docker 쓰는 법을 알 수 있다.

단계를 거쳐서 공부해야지 최신 기술만을 따라가면 안된다.

 

※ 참고

https://www.hanl.tech/blog/ci-cd-%EA%B8%B0%EB%B3%B8%EA%B0%9C%EB%85%90%EA%B3%BC-%EA%B0%80%EC%9E%A5-%EB%A7%8E%EC%9D%B4-%EC%93%B0%EC%9D%B4%EB%8A%94-%EB%8F%84%EA%B5%AC-5%EA%B0%80%EC%A7%80/

CI/CD 기본개념과 가장 많이 쓰이는 도구 5가지 | 하늘네트

 

■ 대규모 협업하기

 

* merge 순서(git rebase master 처리)

 

merge history 순서는 checkout 에 영향을 받는다. 

따라서 checkout 을 로그인을 먼저 해서 아무리 회원가입이 먼저 커밋로그를 남겨도

추후에 로그인을 merge 했을 때 로그인이 앞단에 놓게 돼여 우리가 보고자 하는 방향이랑 다르게 나온다.

 

 

따라서 HEAD 를 먼저 체크아웃 했던 브랜치에 둔 후 

git rebase master 해주면 master 에 있는 것을 그대로 가져와서 덮어쓴다. 

 

순서는 자연히 환경설정 -> 회원가입 -> 로그인 으로 된다.

다음으로 HEAD를 다시 master에 옮기고 로그인 토픽을 머지해준다. 

 

※ hotfix : 빠르게 서비스 되는 것을 수정

 

 

이미 먼저 처리된 것이 있다면 rebase 처리 해줘야 한다.

 

■ 체크아웃 상관 없이 merge 순서 맞추기

1. git checkout dev

2. git pull origin dev

3. git checkout feature/nunu

4. git rebase dev (머지 순서 맞추기) ★

※ feature는 rebase 해도 되지만 dev나 main 은 건드리면 안된다.(팀장만)

5. git push origin feature/nunu

 

 

누누까지 완성되면 release 버전 만들어주면 된다.

 

 

위와 마찬가지로 누누보다 야스오가 먼저 만들어졌기 때문에 yaso 를 그냥 push 하게 되면

checkout 순서로 인해 커밋로그가 꼬인다.

 

따라서 팀장이 이전에 올렸던 yaso PR 요청을 거절하고

다음과 같이 rebase 하도록 야스오 개발자 김대리에게 요청한다. 

 

먼저 업데이트된 dev로 checkout 후 pull 로 받고,

해당 내용을 야스오 브랜치로 checkout 한 뒤 rebase 하여 dev 를 덮어쓰고 강제로 push 한다. 

(강제 push 하는 이유는 이전과 형상이 다르기 때문이다.)

 

release 완료되면 dev 와 main 에 업데이트 해준다.

 

■ sourcetree 사용하기

 

작업한 브랜치들을 깔끔하게 볼 수 있다.

 

 

서비스중에 오류가 나면 hotfix 브랜치를 만들어서 버그수정하고 반영한다.

 

■ 기여하기

 

 

다른 사람의 레포지토리에 있는 것을 fork(복제)해서 새로운 기능 기여하기

복제한 곳이 orgin(=downstream) 다른 사람의 레포지토리는 upstream 이라 부른다.

 

 

fork 한다음에 내 저장소에 contribute 처리하면 해당 프로젝트에 기여할 수 있다. 

 

출처 : https://www.inflearn.com/course/%EA%B9%83-%EC%9E%85%EB%AC%B8/dashboard

[지금 무료] 지옥에서 온 관리자 Git 강의 | 최주호 - 인프런