[Git] 개발자가 나쁘지않아을 표현하는 법, Github - 2 볼께요

>

지난 포스팅에서는 git 로컬 저장소를 github 원격 저장소로 push하는 것까지 무사히 성공했습니다.​ 이 git라는 버전 관리 시스템은 똑똑하기 때문에 새로운 commit이 추가되더라도 파업 리이 변경되지 않은 파 1버전은 당싱로 유지된다.

>

이 기록을 토대로, 이 파일은 어느 commit때에 변경되어 무엇이 변경되었는지 한눈에 비교할 수 있다. 설령 잘못 날아간 코드가 나중에 발견됐을 때 누가 언제, 어떤 이유로 사라졌는지 추적이 가능하다는 의미입니다.그래서 commit는 가능한 한 소규모 기능별로 짧게 하는 것이 좋다.어떤 6가끔 동안 기능을 열뎃게을 쉴 새 없이 코딩하고 커밋 메시지에서 "완성"이런보다 기능 단위 모듈 단위로 commit을 계속했다 그 다소리, 가장 마지막으로 github에 관여하는 것이 낫다는 의미입니다.

>

>

위의 코밋 비결은 정답이 아니다.같은 프로젝트를 진행하는 멤버와 commit 메시지 양식을 통해 따르는 것이 가장 좋고, 그렇지 않으면 기능 구현 순으로 입력해주는 것이 좋다.

사양 git의 꽃이며 가장 어려운 부분인 branch에 대해 설명하고 싶다.개발을 하다 보면 어느 부분을 수정해서 잘 된 모두 코드가 돌아가지 않는 경우도 있고, SI/SM 현업에서는 뿌리가 같은 모듈을 조금씩 커스터마이즈해서 다른 방법으로 사용하는 경우가 많다.이를 브랜치를 사용하여 사용하면 오리지널 버전을 건드리지 않고 자신만의 개발환경을 설정하여 마음대로 수정을 한 후 나중에 그 부분이 완료되면 오리지널을 다시 적용하는 방식을 사용하는 것이 좋다.특히 겟니다와 같은 경우, 실제로 겟니다가 서비스되고 있는 Live branch, 테스트 서버 중의 Test branch, 새로운 기능을 개발하는 dev branch, live branch의 갑작스러운 버그를 수정하는 hox fix branch 등 브랜치를 나누어 개발을 진행하고 있다. 각자의 영역이 최대한 피해가지 못하게 하는 방식이에요.​ 엄청난 규모의 프로젝트의 경우 구현하려는 기능 단위의 브랜치에서도 나누기도 하지만 1반과 같은 경우에는 배포/개발/테스트 등의 역할 구분에 많이 사용하게 된다.​ 현재까지 작업 중이던 master브랜치는 주 작업 영역이며 default로 생성되어 있는 단 1브랜치입니다.

>

현재의 master 브랜치 상태는 아래 그림과 같다.

>

여기서 README.md 를 추가해 주는 commit 를 하면, 다시 아래와 같은 그림이 된다.

>

일종의 branch는 현재 작업 중인 위치를 알려주는 포인터와 같은 역할을 한다고도 할 수 있다.우리는 곧 브런치를 다시 만들 것이다 git bash에서 현재 브런치를 확인하는 것은 향후 명령어를 사용한다.

>

그래서 새로 브런치를 만들고 싶다면 더서리에 사용할 이름을 추가하면 된다.

testing이란 이름의 branch를 만들어 봤다. 이 시점에서 testing 브랜치는 master 브랜치와 같은 commit을 가리키고 있다.

>

testing 브런치는 만들고는 있지만 여전히 사용 중인 브런치는 master 브랜치였다 여기서 testing 브랜치를 사용하려면 이후의 명령어를 사용해 준다.

testing 브랜치로 넘어오면 이 브런치에서 code.cpp을 제거한 후 커밋을 수행합니다.그 후 다음 상황이 된다.

>

재미있는 것은, 이쪽에서 다시 master 브랜치로 복귀하면, 분명 이미 전에 지웠던 code.cpp이 다시 예토전생하여, 눈을 부릅뜨고 살고 있는 것이다.

>

이것이 버전 관리 시스템 git의 강력한 강점입니다. git기록만 살아 있으면, 잘못 지운 코드와 파 1을 이이에킥무하에 원점의 방 복시 킬 수 있다는 것입니다. 물론 이것은 commit을 원활하게 진행하면 가능한 일입니다. master 브랜치로 돌아온 김에 살아 돌아온 code.cpp에 떨리는 심정을 잡고 다시 돌아온 것에 대한 인사를 남기자. 그래야 이 친구가 자신을 1프로파일 지우지 않은 것으로 알고 우리를 원망하지는 않죠.

>

이것을 커밋해 준다면, 현재 git 상황은 이런 상태입니다.

>

여기서 testing 브런치를 push할 수도 있다.브랜치의 용도에 따라 github에 올릴 수도, 안 올릴 수도 있지만 역할을 본인의 눈의 sub branch라면 올릴 수도 있고 본인이 개인적으로 실험을 하기 위한 branch라면 올릴 수도 없었다.일단 다시 testing branch로 이동하여 git push를 하면 다음과 같은 메시지가 나타난다.

>

로컬에는 우리가 git branch testing이라는 명령으로 testing 브랜치를 만들었는데, github의 원격 저장소에는 testing 브랜치가 없다는 뜻이었다. 그래서 명령어를 작성하면 원격저장소에 'testing'이라는 브런치를 만들면서 바로 push를 실행합니다.

>

명심할 것은 testing 브랜치만 push 된 것이며, master 브랜치는 여전히 마지막 push 하기 전의 commit을 가지고 있다.여기서는 그림을 따로 그리는 것이 아니라 GUI 툴인 Source Tree의 그림도 참고하고 싶다. (절대로 그리는 것은 귀찮지 않다.) 이런 좋은 툴이 있다는 것도 알려주기 위해서죠. 아무튼)

>

여기에서 "origin/"가 붙은 것은 github의 원격 브랜치가 가리키는 커밋이며, 붙어 있지 않은 것은 로컬 브랜치가 가리키는 커밋이다.master 브랜치는 "from hell" 커밋을 했지만, 아직 github에 push는 하지 않았기 때문에 origin/master는 아래에 있는 것을 볼 수 있다. tesing 브랜치는 push를 실시했기 때문에, 원격 브랜치와 로컬 브랜치가 같은 위치를 가리키고 있음을 알 수 있다.방금 전 칸막이가 된 브런치를 merge할 차례다. branch를 나눠서 진행한 작업을 아까 실제 master 브랜치에 반영할 차례인데 보통 문제가 되지 않는다면 merge를 하면 아무 문제없이 깨끗하게 작업이 진행된다.merge 명령어는 기준 branch로 진행하면 된다.

그러면 master 브랜치에 testing 브랜치의 스토리가 합쳐지는 방식입니다.그러나, 문제가 우리는 testing 브랜치에서 없어진 code.cpp 파일을 master로 수정했기 때문에 commit 상에서 상호 모순이 생긴다.

>

어느 파하나에서 CONFLICT가 나왔는지 메시지가 표시되므로 문재가 달린 코드를 열어 적절히 수정할 수 있다.

>

master에서는 code.cpp이 살아있고, testing에서는 code.cpp을 죽였기 때문에 우리는 살기 위해서 code.cpp을 add해서 commit 해준다. commit 메시지는 "commit testing"과 함께 써준다.만약 현재의 귀추, 같은 코드를 동시에 수정한 귀추라면 코드에 다른 부분이 표시되어 본인이 오게 된다.​

>

이상 merge와 conflict의 대처법까지 알아봤다.이는 merge는 다른 작업 브랜치에 영향을 주는 행위이므로 merge 작업 이전에 해당 브랜치에서 작업중인 사용자에게 미리 최종 작업내역을 commit 하여 push 해 두는 것을 공지하는 것이 좋다. 그리고 사용자는 관리자가 merge 작업을 마칠 때까지 가능한 한 작업을 자제하는 것이 좋다.기다리고, 과인면 고통의 merge 작업을 마친 관리자가 "pull"을 받도록 이야기 해줍니다. pull이 뭐냐면...

새로운 프로젝트를 만드는 것이 아니라 이미 존재하는 프로젝트를 불러들이는 방법과 프로젝트를 진행하다가 다른 사람에 의해 색다른 스토리를 불러오는 방법이 있다. 전자는 clone이고 후자는 pull이다.전자의 경우 프로젝트를 git 저장소별로 내 로컬로 복사해서 받아오는 것이다.

이런 명령어를 사용하면 되고, github의 경우 그 주소로 다소 음 얘기를 넣으면 된다.

>

정말 그래서 Download ZIP를 하면 git 없는 최종 커밋 상태의 프로젝트를 받을 수 있다. git 저장소별로 받아오기 때문에 굳이 새로운 폴더를 만들어 git init을 할 필요가 없다.최근 위에서 말한 풀(pull)을 받는 것이 있는데, 현재 접속되어 있는 원격 저장소의 최신 상태를 받아오는 것이다. 최신상태를 수신하려면 pull이외에도 하나 더 있는데

여기서 gitfetch는 최근의 상태를 취해오는데 로컬에 적용하지 않는 것이고, 받아온 것을 merge 해야 나의 로컬에도 원격 저장소와 동일한 상태로 할 수 있는 것이다.보통은 두 작업을 거의 매일 실행하므로 이 둘을 합쳐서 git pull을 사용하고 git pull이 더 많이 쓰인다. 단, merge 작업이 들어가기 때문에 CONFLICT가 발발하면 당연히 작업이 실행되지 않는다. pull 과정에서 문제가 생긴 CONFLICT를 처리해야 합니다.​​