gitlab3

실전에서 협업하는 방법

 

1. 초대하기

레포지토리 화면 -> setting ->members->invitemember 

 

2. 등급 조절

 

3. 프로젝트 

1. git clone -> 컴퓨터로 가져오고, 작업한다음 ->git push

단점 : 한명의 개발자가 만든 새로운 커밋을 상의하는 절차없이 merge하게 됨

늘 완벽할 수 없기때문에 실전에서는 x

 

2. 원래의 프로젝트와 똑같은 프로젝트를 다른사람의 계정아래에 별도로 생성 (copied)

원본 프로젝트의 복제본을 만드는것 : Fork (~한다.뜬다)

그런다음 git clone -> 프로젝트에서 커밋생성~하고 -> git push

원본이 아닌, 복제본에 push한다는점

그런다음 merge request를 보냄

 

---

 

아무도 포크 안해서 아직은 0

 

- 포크하기 버튼 누름

---

어떻게 복제 프로젝트 만드는지 보여줌

- 일단 헷갈리지않게 디렉토리 생성

- git clone url주소 삽입

(복제본 프로젝트와 원본 프로젝트 url비교했을때 사용자 이름만 다름)

 

실행해보면

 

정보 요구함

 

복제본 프로젝트 다운로드

 

ls입력해서 내용물 확인해보기 ->잘있음

log살펴보기 git log --all --graph

원본과 같음을 확인할 수 있음.

 

브랜치 옮겨주기

git checkout 브랜치이름

git config user.name 이름

git config user.email 이메일

이렇게 정보 입력해놔야 누가했는지알 수 잇음

 

마이클의 디렉토리속 다운받은 복제 프로젝트 열어주기

몬스터가 등장하는 클래스 만들어줌 

Monster.js

class Monster {
	constructor(){
    }
}

git add .

git commit -m "Add Monster.js"

 

 

Item.js생성

class Item {
	constructor(){
    }
}

git add .

git commit -m "Add Item.js"

 

방금 생성한 두 커밋을 깃랩에 있는 복제본에도 반영

git push

 

우리의 헤드는 develop이기때무넹, git push는 자동으로 develop에 해당하는 것만 업로드됨

헤드가 가리키지않는 브랜치의 커밋들을 업로드 하려면 git push origin master 와 같이 뒤에 붙여줘야함.

---

gitlab에서 commit 확인해보면 develop에 잘 반영됨을 확인할 수 있음.

지금 우리는 복제본에 커밋을 반영했기때문에, 원본프로젝트에 반영하기 위해서는

 

머지 리퀘스트 보내기

브랜치 수정하려면 change branch눌러서 수정해주고  -> continue

 

원래 머지 리퀘스트의 제목을 적는 방식은 회사마다 정해진 규칙이 있음.

우린 없으니깐 맘대룽..

 

assignee는 담당자설정

 

submit해서 머지 리퀘스트 보내기!

 

머지 리퀘스트에 대해서 대화를 하고싶으면 discussion을 클릭해서 글 남기면됨

맘에드는 리퀘스트면 merge버튼 클릭

클릭하게 되면 develop브랜치에 파일 추가됨.

 

 

정리:

포크 -> git clone ,커밋 제작 -> git push -> mergerequest ->원본프로젝트에 적용

 

settings-> merge request 설정을 expand해주고 내용을 보면

 

 

3종류의 정책을 볼 수 있음

- merge commit은 어떠한 경우(패스트 포워드가 가능해도)라도 새로운 머지커밋생성하는거

- fast forward merge선택하면

fast 포워드 머지가 가능하면 이걸 생성

 

정책에 따라 원본프로젝트의 커밋로그가 다르게 나타남

근데 이건 깃에 익숙해진다음에 고민할 문제..임

실무에서 목적에 맞는 커밋로그를 만드는것도 굉장히 중요

---

원본프로젝트가 몇단계 앞서나간 상황에서

git push --force : 덮어씀, 업로드를 강제하면 깃랩서버에 있는 커밋을 덮어씀

그럼 이전커밋으로 돌아감

근데 이런식으로 하면 안된다고함.