일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 프록시배포구조
- 러스트기초
- ethers websocket
- 스마트 컨트렉트 함수이름 중복
- SBT표준
- git rebase
- chainlink 설명
- Vue
- ethers
- 티스토리챌린지
- 오블완
- nest.js설명
- 체인의정석
- 머신러닝기초
- 컨트렉트 동일한 함수이름 호출
- ethers type
- Vue.js
- ethers v6
- rust 기초
- 스마트컨트렉트 함수이름 중복 호출
- 러스트 기초
- 스마트컨트렉트테스트
- 컨트렉트 배포 자동화
- multicall
- ambiguous function description
- 스마트컨트렉트 예약어 함수이름 중복
- 러스트 기초 학습
- 스마트컨트렉트프록시
- ethers typescript
- vue기초
- Today
- Total
체인의정석
git 사용하기 3) 팀원간 같은 소스에서 작업할 시, 깃허브 업데이트 방법 본문
1. develop 브랜치에서 작업한다.
2. 작업이 끝나면 스태시 위치로 올려둔다.
3. develop 브랜치에서 새로운 브랜치를 만든다.
4. 스태시 위치에 있는 코드를 불러온다.
5. 새 브랜치에 푸시 후 머지 리퀘스트를 보낸다.
6. 코드리뷰를 다 받고 머지가 되면 develop 브랜치 소스가 업데이트 된다.
7. develop 브랜치에서 업데이트 된 코드를 pull 받는다.
위의 1~7번 프로세스로 작업하는게 가장 좋다고 한다.
이때 요점은 develop은 내가 건드리면 안되는 상황이기 때문에, 팀장님만 관리하는 브랜치로서 남겨두어야 하고, 나는 여기에 어떠한 커밋도 하지 말고 특히 push를 하면 안된다는 것이다. 기본적으로 권한을 보통 막아 놓지만 그래도 혹시 모르니 안하는게 좋은것 같다.
근데 나는 develop 브랜치에서 작업 후 브랜치를 만들때
커밋을 먼저 하세요 하는 문구를 보고 진짜 커밋을 해버렸다.
물론 push는 안해서 괜찮긴 했다.
내로컬에서 일어난 일이 리모트 환경 깃허브 저장소에 안붙는다면 나 혼자 다시 되돌리면 된다.
실제로는 스태시 위치로 옮기고 하면되었는데 다음부턴 유의해야 겠다.
이런식으로 커밋이 쌓이다보니 어느세 17개 만큼 쌓여버렸고 이걸 해결해야 되는 상황이다.
먼저 몇개가 안된다면
git reset HEAD~2
이렇게 해도 된다고 하는데 지금처럼 커밋 내용이 많다면?
초기화를 한번 시켜줘야 한다.
git fetch origin
git reset --hard origin/HEAD
git clean -f
먼저 origin 브랜치에 fetch를 해주고
reset을 origin/HEAD 까지해서 현재 origin 그대로로 만들어준다.
마지막으로 origin에 없는 파일들을 제거하기 위해 git clean -f 까지 해준다.
이제 이 이후로는 업데이트 사항이 있을때마다 git pull 만 하면 된다.
'개발 > git' 카테고리의 다른 글
Git) 브랜치 rebase 하기 (0) | 2021.09.09 |
---|---|
Git) Patch 설명 및 명령어 정리 (0) | 2021.09.09 |
git 사용하기 2) 브랜치가 꼬였을때 어떻게 해야 할까? (0) | 2021.08.10 |
Git)Mac KeyChain to store GitHub repos (0) | 2021.08.04 |
git - 폴더명 대소문자 관리 (0) | 2021.08.03 |