초보자 중 한 명의 엔지니어가 팀 개발에서 배운 github의 사용 방법!

배경.


나는 프로그래밍에 흥미가 있어서 혼자서 rails로 웹 응용 프로그램을 개발한다.
헤로쿠 등을 사용하기 위해github를 사용하지만, 사용법을 이해하지 못하면 항상 사용하고 있다고 느낀다.
github의 사용법을 검색하면git의 지령 등을 설명하는 기사가 자주 나오지만,hub의 사용법과 공동 개발의 절차에 대한 설명은 의외로 적다.
최근 팀 개발을 체험할 기회가 생겼는데, 그때 지아이허브 활용법을 조금 배웠기 때문에 메모와 의미를 담아 기사로 정리했다.
마지막으로 나는git분지를 실제적으로 정리할 때의 절차와 주의사항을 썼다.

지금까지의 용법


혼자 개발하면 공동 작업이 없기 때문에 아무리 지저분하게 창고와 지점을 만들어도 기본적으로 스스로 기억하기 때문에 곤란해하지 않는다.
지금까지 저의github사용방법은heroku의 서버에 먼저 떠넘겼습니다. 이동할 때 오류가 발생하면 한 개의 이전 제출 제작 지점에서 그를HEAD로 계속 개발하고 오류가 발생하면 한 개의 이전 제출에서... 라는 느낌으로 지점을 사용했습니다.
그 결과 지점이 20개가 넘고 마스터는 먼 옛날 상태에 머물렀다.
나 같은 사람이 개발한 초보자 중에는 비슷한 경우가 있을 것 같아.

배운 정확한 용법


제목은 올바른 사용법이지만 사실은 옳다!이런 견해는 존재하지 않고 회사와 팀에 따라 사용 방법도 다르다.
이번 보도는 내가 배운 방법이자 많은 방법 중의 하나이다.

분지의 구성


기본적으로 정식 환경의master와 개발 환경의development 두 가지로 구성되어 있다.그리고 개발자는 기본적으로 마스터의 복사본이다.
그리고 다음과 같은 절차에 따라 개발을 진행한다.
1. 로컬pull 원격 개발자
2. 로컬 개발자로부터 기능명과 이름으로 작업 지점을 만든다.
3. 작업 지점에서 기능을 완성한 후 로컬 개발자에서marge를 사용합니다.
4. 로컬 개발자를 원격 개발자로 확장합니다.
5. 원격 개발자를 통해 테스트를 진행하고 문제가 없으면 정식 환경에 들어갑니다.
그림에서 보듯이 아래와 같다.(잘 표현하기 어려워...)

이번 방법은 마스터와 개발자의 2층으로 팀에 따라 증가하거나 완전히 다른 방법을 사용했다.

소감(실제로 하기 전)


이번 보도의 방법은 이해하기 쉽고 간단하기 때문에 한 사람이 개발할 때도 채택할 수 있다고 생각합니다.
앞으로 나는 자신의 개발 환경을 조정하고 싶다.

실제로 해보세요. (주의)


본고는git의 구성과 자신의 환경을 정리하기 위해 합병 작업을 할 때의 절차가 고전하는 부분을 총결하였다.(생각보다 힘들다)
소스 트리를 사용했기 때문에 마침내 방법이 생겼다.
검은색 화면(명령행?)나는 일할 때 상당히 엄격하다고 생각한다.
다음은 실제 진행 단계입니다.

1. 과거에 방치했던 마스터를 현재의 최신 지점 테스트에 통합한다.


이 일을 할 때 나는 먼저 합병의 개념을 오해했다.
오해: 마스터를 테스트에 합치면 테스트의 내용이 마스터로 복사됩니다
이것은 완전히 오해다.
내 경우는 오류가 발생하면 이전 제출에서 새로운 분기를 만들어 주 분기(HEAD)로 삼기 때문에 이런 생각을 합치면 테스트 내용뿐만 아니라대량의 불필요한 코드(test 분기를 차단한 후 마스터로 오류 원인이 된 코드를 추가)가 마스터에 대량으로 추가되었다.
네!
병합은 여러 편집 컨텐트를 병합한다는 뜻입니다.
통합 시 같은 곳을 편집해 충돌이 발생하지 않는 한 변경은 계속 추가된다.
팀이 개발할 때의 개발 방법을 생각해 보는 것은 당연하다.
아니면, 원래git는 차별을 관리하는 도구였는데...
이에 따라 합병 후 약속을 취소하고 테스트 지점을 마스터 지점(이름 변경)으로 변경하는 작전을 강제로 실시한다.

2. 테스트 이외의 지점 삭제(매우 위험한 방법)


상당히 강경한 방법이었지만 다른 방법을 생각하지 못해 현재 HEAD의 테스트 이외의 지점을 로컬이든 원격이든 삭제했다.

3. 테스트의 지점 이름을 마스터로 변경


이전 절차에 따라 마스터 지점을 삭제했기 때문에 마스터 이름 대신 테스트 지점을 사용합니다.
git branch -m test master
이렇게 되면 주요 지점이 순조롭게 마스터 지점으로 바뀌었다!

4. 마스터 지점에서 개발자 지점 만들기


마스터 지점에서 개발자 지점을 만듭니다.
그리고 원격으로 두 개의 지점을 밀어낸다.

5.development 지점에서 작업 지점 만들기


로컬 개발자 지점에서 작업용 지점(work-station 지점 등)을 만듭니다.

개발 방법


이렇게 되면 지부 정리가 순조롭게 끝난다!!!
향후의 개발 방법으로 삼다
1. 작업 지점으로 편집
2. 로컬 개발자에 통합
3. 개발자 원격으로 누르기
4.github에서 개발자 지점에서 마스터에게 요청을 만들고 통합합니다.
이런 느낌.
마스터에 로컬로 통합하지 않도록 주의하십시오.
로컬에서는 github에서master에 통합하기 위해 작업 지점과 개발자 지점만 사용합니다.
이렇게 되면 개발자가 여러 개가 돼도 대응할 수 있다.

소감


나는 사전에 조사할 때 아주 간단해서 해낼 수 있을 것이라고 생각했지만 실제로는 매우 어려워서 마음이 혼란스러웠다.웃음(심장에 안 좋다)
상당한 고전을 겪었지만git는 공동 개발에 필요한 기술 중 하나인 만큼 이 기회를 빌려 깊이 이해할 수 있어서 다행이다.
이번에는 사진을 억지로 찍는 순서로 진행됐으니 더 좋은git정리방법이 있다면 댓글로 알려주세요.
그리고 이 기사가 나 같은git 초보자의 참고가 된다면 좋겠다.

좋은 웹페이지 즐겨찾기