2일차 수업 깃허브(3)
깃허브 Merge
프로젝트를 진행하다보면 실험을 위하거나 협업을 위해 브랜치를 나누기도 합니다.
그때 나누어진 브랜치를 합쳐주는 것이 merge입니다.
깃 충돌(comflict)
브랜치를 나누고 여러 사람들이 프로젝트 내에 같은 이름의 파일을 수정 후에 해당 브랜치들을 merge하게 된다면 충돌(comflict)가 발생합니다. 이 경우 Base와 브런치들을 대면하여 어디서 충돌이 났는지 확인할 수 있습니다. 만약 Base(브랜치들의 공통 부모라고 생가가하고 있음) 와 비교했을 때 수정사항이 있으면 수정된 사항을 반영합니다.(자동으로 해주는 아주 좋은 기능!)
단, 브런치들 모두가 프로젝트 내에 같은 파일을 변경했을 때, comflict가 발생합니다.
자동으로 충돌이 없다면 병합해주고 충돌이 있다면 병합해주지 않습니다.
이렇게 상세하게 어디 파일에서 충돌되었는지 확인 가능합니다. 오른쪽 위에가 내가 작업한 파일이고 왼쪽이 협업한 사람의 파일입니다. 아래는 이제 Base의 수정전 내용을 확인할 수 있습니다. 그래서 아래에 있는 Result에서 코드를 수정하고 Complete Merge을 누르게 되면 merge가 진행되고 commit을 누르게 되면 충돌이 해결된 상태사 commit됩니다.
협업에서 git사용
※일단 저는 협업에서 git을 사용해본 적이 없습니다 수업내용을 토대로 정리하는 것이라 댓글 남겨주시면 수정하도록 하겠습니다.※
협업의 파트너가 먼저 다른 파일을 만들고 push를 하게 되면 rejected가 발생하면서 push에 실패하게 됩니다.(원격저장소에서 가리키고 있는 버전이 달라서 발생하는 에러)
따라서 이런 에러를 피하긴 위해서는 작업전에 pull을 통해서 원격저장소를 먼저 프로젝트를 끌어온 후 push를 하면 됩니다. 여기서 pull은 fetch와merge의 작업을 동시에 하는 역할을 수행합니다.
만약 pull대신에 fetch를 사용하게 되면 merge가 되지 않은 새로운 브랜치가 생성됩니다.
그래서 협업할 때 소통도 중요하고 빨르게 pull하고 push하는 고수가 되고 싶다고 느꼈습니다.
※orign/main을 remote tracking branch라고 합니다. -> 어디까지 push했는지 마킹해주는 것! (깃이 알아서 관리함)
2일차 수업 깃에 대해 정리해 보았습니다. fetch에 대해 자세히 설명해주셨는데 추후에 다시 정리해서 업데이트 해보도록 하겠습니다. 아직 갈 길이 많이 남았는데 꾸준히 수업을 정리하고 복습하여 다 제 것으로 만들 수 있도록 하겠습니다. 공부하시는 모든분들 화이팅입니다.
※공부하고 있어 다소 틀린점이 있을 수 있습니다. 언제든지 말해주시면 수정하도록 하겠습니다.
※용어에 대해 조금 공부 더 해서 수정하겠습니다.
