이 기사는?

・ GitHub에 대해 조사를 했는데 왠지 잘 모르는 사람이 쓴다.
· 전부 글로 설명해도 엉망진창이 되어 사람이 쓰는 줄은 몰랐다.
어쨌거나 앞으로 지식을 습득할 테니 큰 틀은 사람이 쓰는 것이라는 것만 이해해 주세요.
・초초보자를 위한 나의 메모 채용이다.

GitHub

어병과 뜻의 편차가 있을 수 있으니 용서해 주십시오.
GitHub에 대한 조사는 여러 가지 용어, 명령, 관계성이 나와 잘 모르겠지만 중요한 것은 한마디로 말하면 실패하고 싶지 않기 때문에 두려워하면서 설치된 부품을 조금씩 결합하는 서비스입니다.
더 쉽게 이해할 수 있는 것은'온몸에 용주 손오공의 그림을 그린다'고 하지만 종이 한 장에 한 번에 그릴 수 있다는 자신감은 없다. 중간에 얼굴과 몸의 균형이 나빠지고 손가락 모양이 변하며 거북이의 로고는 잊어버렸다.얼굴, 팔, 발, 몸을 좋아하는 부분으로 나누어 각각 만든 것을 붙인다
이렇게 할 수 있는 서비스.

로컬 및 원격 저장소

상술한 큰 프레임워크를 바탕으로 로컬과 원격 저장소의 역할은
로컬 저장소는 초안이고 원격 저장소는 실제 표시된 부분입니다.
좀 더 간단하게 말하자면 로컬 저장소는 얼굴은 얼굴로, 팔은 팔로 가장 좋은 완성형을 만들기 전에 반복적으로 실험하는 부분이고, 원격 저장소는 로컬 저장소에서 만든 각자의 완성형을 배치한 곳에서 최종적으로 그것들을 결합시켜 하나의 작품을 만드는 부분이다.

로컬 저장소와 원격 저장소의 제작 방법은 여기 있습니다.

예를 들어 위와 같은 이미지처럼 오공체를 만드는 코드를 쓰면서 브라우저에서'지금 어떤 느낌으로 보이나요','어, 여기 생각한 것처럼 안 보이네요','아, 오류가 발생했어요'를 확인하고 로컬 데이터 라이브러리를 진행한다.rails로 말하자면 종점에서 "rails"명령을 입력하고 브라우저에서 "localhost:3000"페이지를 여는 것입니다.그것은 원래 로컬 환경이라고 불리는데, 로컬 데이터 라이브러리에서 그 로컬 환경을 이용하여 개발한다.

제출 및 푸시

예를 들어 개발의 일부분으로'상반신'으로 분리한다.'상반신'과 오른팔, 왼팔을 분리해서 만든다.그리고 각자 완성한 부품을 잠시 두는 곳이 "제출"입니다.그런 다음 커밋에 배치된 최종 품목을 원격 저장소에 버리는 작업을 Push라고 합니다.

합병

위의 그림에서 알 수 있듯이 푸시는 결합을 가리키는 것이 아니라 푸시는 시종 원격 저장소로 가져오기 위한 작업이다.원격 저장소로 가져온 오공의'상반신'과 이미 원격 저장소에 있는'얼굴','하반신'을 연결하는 작업을 합병이라고 합니다.

당기는 게 뭐예요?

당기기는 원격 저장소의 데이터를 로컬 저장소에 반영하는 작업이다.
반영도 좋고 원래 로컬 라이브러리에서 직접 만든 데이터이기 때문에 로컬 라이브러리에 있다고 생각할 수 있습니다.그게 팀 개발이 되면 어떨까요?다른 구성원이 각자의 로컬 저장소에서 작성하여 원격 저장소에 업로드한 데이터는 자신의 로컬 저장소에 없습니다.
따라서 원격 저장소의 데이터를 하나하나 자신의 로컬 저장소에 포함시켜 불일치를 없애야 한다.
또 다른 멤버들이 만든 얼굴의 목 부분과 자신이 만든 가슴 주위의 목 부분이 빗나갔는지 등을 확인하면서 잡아당기는 작업도 중요하다.
또한 상기 이미지에서는 당기는 동작으로 얼굴만 있는 것처럼 보이지만 당기는 단계에서 원격 저장소의 데이터는 모두 로컬 저장소로 이동합니다.이 그림으로 말하자면 하반신도 당겨졌다.
또한 원격 자료 파일 라이브러리를 이동하는 데이터는 반영된다는 뜻으로 원본을 반영하는 원격 자료 파일 라이브러리의 데이터는 원격 자료 파일 라이브러리에서 직접 사라지지 않는다.

분지

지점은 설치된 장소를 분리하여 전체에 아무런 영향이 없는 상태에서 개발하는 방법을 말한다.
예를 들어 얼굴을 설치하기로 결정하면 얼굴을 절단한다.

분기 이미지

브랜치는 먼저 마스터 브랜치가 존재하며 마스터 브랜치로 향상된 데이터는 완성형 데이터입니다.
① 주 지점에서'얼굴 지점'을 만들어 분리
② 분리된 [페이스 브랜치]에서 얼굴 설치 완료
③ 마스터 브랜치에 다시 연결하여 마스터 브랜치에 반영합니다.
예를 들어 팀원 3명은'얼굴을 만드는 멤버','상반신을 만드는 멤버','하반신을 만드는 멤버'와 역할을 분담한다.
이때 각각 가르마를 잘라내'얼굴 만드는 멤버'는 얼굴 작업에 영향을 주지 않고'상체 만드는 멤버'는 상반신을 만들 수 있다.

충돌

충돌은 GitHub의 특성인 위기 회피 사양입니다.쉽게 말해'당신이 변경한 곳은 다른 사람도 변경했기 때문에 어떤 것을 채택해야 좋을지 모르겠다'는 것이다.구체적으로 어떤 상황에서 인상을 남기기 어려우므로 우선 주요 지점의 특징을 알려야 한다.

주 지점

주 지점은 새로운 데이터를 덮어쓰는 길이다.따라서 덮어쓰기 전과 덮어쓸 때의 데이터가 완전히 같은지 확인하는 토대에서 덮어쓰기 작업을 수행합니다.

왜 그런 방법이 필요합니까?

예를 들면 너는 가정주부다.지금 스튜를 만들고 있어요.도중에 너는 화장실에 갔다.그래서 안에서 자고 있던 남편은 벌떡 일어나 설탕을 천천히 넣었다.화장실에서 돌아온 너는 다시 맛을 보았다. "이게 뭐야!!! 내가 화장실에 가기 전과 돌아올 때와는 맛이 달라!!!"삭제합니다.화나겠지?이와 완전히 같은 상황을 피하기 위해 GitHub는 "당신이 주 지점을 떠날 때 주 지점의 데이터는 변화가 없습니다. 걱정하지 마세요."라고 알려 줍니다.

이 모드는 충돌이 없습니다.

설치가 끝나면 다음 설치가 시작되는 모드입니다.물론 얼굴 분지를 끊기 전과 돌아올 때의 얼굴 데이터는 같기 때문에 충돌이 일어나지 않는다.데이터의 변경은 자신이 만진 곳이 다른 사람이 만졌는지 확인하는 것이다. 자신의 설치 부위 이외의 부분은 끊임없이 덮여도 문제가 없다.

이 모드도 괜찮아요 ②

B의 관점에서 본 "자신의 설치가 끝나기 전에 데이터가 업데이트되는 모드"이런 상황에서 설치 부위가 덮어씌워지지 않았다. 즉, 자신이 만진 데이터가 사람이 만지지 않았기 때문에 다른 부분은 아무리 많은 주요 부분을 덮어씌워도 충돌이 일어나지 않았다.B의 덮어쓰기를 B2로 설정하면 A2의 데이터가 이 데이터와 결합되어 주요 지점의 데이터가 계속 커진다.

이 모드에서도 충돌 가능 ③

A의 관점에서 볼 때 "자신의 설치가 끝나기 전에 데이터가 업데이트되는 모드"입니다.방금 또 왔는데, 이번에는 자신의 설치 안에 다른 설치가 덮어씌워졌다.다만 이 부딪힌 곳도 각기 다르기 때문에 충돌은 일어나지 않는다.

이 모드는 충돌!!!

상반신과 하반신 각각의 멤버가 설치되어 있으며 허벅지 부분의 파일을 서로 만지며 변경하는 패턴이 충돌한다.이 경우 하체 브랜치의 [B]를 바디에 결합할 수 있습니다.단, [A]의 상반신 지점을 주 지점으로 합칠 때
GitHub "어? 이 A의 허벅지 부분의 파일은 잘랐을 때랑 달라요. 어? 이건 어떤 걸 써야 하지? 네, 충돌~!"하계.

마지막

여기서 끝내.GitHub의 존재 의미와 큰 틀이 아무것도 머릿속에 들어오지 않았던 과거를 향해 쓴 것이기 때문에 조작과 명령을 쓰지 않았다.충돌을 해결하는 절차를 포함해서 이 점에 관해서는 다른 일로 쓰고 싶습니다.