실전에서 협업하는 방법
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 : 덮어씀, 업로드를 강제하면 깃랩서버에 있는 커밋을 덮어씀
그럼 이전커밋으로 돌아감
근데 이런식으로 하면 안된다고함.
'✍2021,2022 > git' 카테고리의 다른 글
Git 사용법2 (0) | 2021.07.06 |
---|---|
Git사용법 (0) | 2021.06.26 |