많은 분들이 깃허브 관련해서 레포지토리를 만들고 initialize 하는 방법까지는 알 것 같습니다만, 다른 부분은 헷갈려 하시는 분들도 게시는 것 같습니다. 네 그렇습니다. 제 이야기입니다. (머쓱) 이번 참에 공부하면서 한번 적어보았습니다.
보통 CLI 기반으로 많이 하는데 저는 헷갈려서(...) 데스크탑을 깔아봤는데 좋더군요! 0.0)b
리눅스를 배웠어도 GUI 기반이 아니면 혼란스러운 저주받은 세대
그래서 깃허브 데스크탑 기준으로 작성하게 되었습니다.
(참, 만약 CLI 기반을 해보시고 싶은 분은 인터넷에 그쪽 가이드가 더 많습니다! 참고사히면 될 것 같습니다.)
0. Fork 하기
fork를 하시게 되면 해당 프로젝트의 저장소를 자신의 저장소로 가져옵니다.
Github 사이트에서 해당 레포지토리로 가보시면 우측 상단에 Fork가 존재합니다.
눌러주시면 자신의 계정에 새로운 저장소가 생기게 됩니다. (여러분의 계정에서 확인해보실 수 있습니다)
1. 레포지토리(Repository) 생성하기
만약 타 레포지토리를 가져와 작업하는 것이 아니고 자신이 만드는 상황이라면 Create newe repository를 이용해 생성할 수 있습니다.
간단하게 Add 옆의 삼각형을 누른 후 새로운 레포지토리 생성(Create new repository)를 선택해주시면 됩니다.
이후 등장한 화면에서 원하시는 내용을 기입해주시면 됩니다.
눈치 채셨겠지만 Name은 레포지토리의 이름, Description은 설명. Local path는 로컬 저장장치 내 경로입니다.
Git ignore은 만약 사용하면 프로젝트의 잡다한 파일들(백업 파일, 로그 파일 등)을 깃에서 제외합니다.
나머지 하나는 라이센스입니다.
2. 레포지토리 불러오기(Clone)
이미 존재하는 원격 레포지토리를 로컬로 가져오기 위해서는 clone을 이용해서 깃허브 서버에서 소스파일을 로컬 폴더로 복제 가능합니다. (아무것도 없는 상태에서 원격 저장소의 내용 가져오기)
많은 분들이 아시듯 깃은 이를 이용해 협업을 보다 간편하게 해줍니다.
위와 마찬가지로 Add 옆의 삼각형을 누른 후 이번에는 Clone Repository를 선택합니다.
선택하시면 다음과 같은 창이 보이는데, URL을 눌러주신 후 Clone 하고 싶으신 깃허브 레포지토리로 가셔서
녹색 Code 버튼을 누르신 후 URL을 복사해주시면 됩니다.
이후 URL 란에 붙어넣기 해주세요.
Clone 작업은 파일 크기에 따라 시간이 다소 걸릴 수도 있습니다. 제 경우 프로젝트 기본 파일 용량도 상당한지 시간이 제법 걸렸습니다.
각자 다른 팀원이 동시에 맡은 일을 하기 위해 branch가 존재하는 점은 알고 계실겁니다. 작업 전 자신의 branch로 이동 해 주세요.
만약 branch를 생성해야한다면 위 스크린샷의 branch 버튼 우측에 작은 화살표가 보이실 겁니다.
누르시고 New를 누르시면 branch를 만들 수 있는 창이 등장합니다.
3. 커밋(Commit)하기
변경 내용이 있으면 이를 적용해야겠지요.
자신의 branch로 이동하셨으면, 클론하신 프로젝트를 불러와 작업을 해 주세요.
앞서 지정한 해당 로컬 경로에서 프로젝트 파일을 찾으실 수 있습니다.
평소대로 작업하신 후 깃허브 데스크톱으로 돌아와주시면
변경 내역이 붉게 나타나는 것을 확인하실 수 있습니다.
좌측을 보시면 Summary와 Description이 보이실 겁니다. 알맞게 내용을 기입해주시고 Commit to (브랜치명) 버튼을 눌러주시면 커밋이 완료됩니다.
4. Commit 했으니 Push!
Commit은 로컬에 데이터를 패키징해서 저장합니다. (개인적으로 처음에 가장 헷갈렸던 부분입니다 :P)
이제 바뀐 부분의 코드를 업로드하기 위해서는 Push까지 완수해야 합니다.
상단의 Publish branch를 눌러서 Push합니다. (상단 Repository - Push도 존재하던데 다른게 있는지는 잘 모르겠네요 :'D 찾아봐도 나오지는 않고... 자주 쓰는 거라 그냥 버튼으로 잘 보이게 빼논건가?)
Push후 github에 해당 레포지토리로 들어오시면 Compare & Pull Request(PR) 버튼을 보실 수 있을 겁니다.
클릭해주신 뒤 PR을 생성하시면 됩니다.
5. Pull
Github Desktop의 상단 메뉴바를 보시면 Repository 탭 아래에 Pull이 있으니 눌러주시면 됩니다.
pull은 원격 저장소의 정보를 가져오면서 로컬 브랜치에 병합까지 해주는 작업입니다.
(로컬에 무언가 있는 상태에서 원격저장소의 수정상태를 가져오기 위해 사용)
마지막으로 브랜치 삭제는 간단하게 작은 화살표 누르신 후 해당 브랜치에서 우클릭해서 나오는 박스를 통해 삭제 가능합니다. 만약 작업하신 내용이 승인 된 후 원본 저장소에 머지가 완료됬으면 브랜치는 필요 없으니 지우시면 됩니다.
여담)
맨 처음에 깃을 잘못 이해해서 어 갱신만 하고 내 브랜치에서 계속 작업하는거 아닌가? 왜 번거롭게 지우는거지? 하고 있었는데, 생각해보니 실제 개발 환경에서는 기능 개발 하나 끝내고 확인하고 머지시키고- 그렇게 진행하지 개발되다 만 코드를 보낼 일은 없는(....) ㅋㅋㅋㅋ 이제보니 저 브랜치도 범위를 너무 크게 잡은 것 같습니다.
이번에 깃을 공부하면서 왜 깃이 강력한지 한번 더 머리에 들어와 유익한 시간이었습니다.
실제 상황에서 배포된 코드와 작업중인 코드는 다르고, 만약 개발하다가 버그 픽스 요청이 들어왔을 때 개발중인 코드와 새로운 버그 픽스 코드가 섞이는 일이 없어야 하니까요. 만약 제가 마스터 브랜치에서 만든 1번 브랜치에서 새로운 기능을 만들고 있었는데, 갑자기 누군가 버그를 고쳐달라고 요구한다면, 2번 브랜치를 만들어서 버그를 고친 후 마스터에 병합하면 코드가 섞일 일이 없지요. 또 나중에 1번 브랜치를 다 작업한 후 마스터에 병합하면 고쳤던 버그 내용도 함께 이어지니까요. (당연하다고요? 그러게요... (쭈글))
어쨌든 다시는 깃을 헷갈리는 일이 없었음 좋겠습니다.
읽어주셔서 감사합니다!