이클립스에서 git- commit, pull, push 를 알 것 같은데, 애매한 사람 추천 글!

git

by Sam_Park 2022. 2. 10. 22:48

이클립스 git, github와 관련해서 좋은 블로그 글 찾았다!

성질 급하신 분을 위한! (~~함정)~~ https://m.blog.naver.com/PostList.naver?blogId=special9486 (해당 블로거의 홈 주소)

( 맨 밑에 요약 있어요 ㅋㅋㅋㅋ)

현재 나는 1차 팀 프로젝트를 진행하면서 작업을 git으로 관리하고 있다.

이전에 미니 프로젝트 때는 공용저장소 정도로만 사용했었다. 그 때는 로컬 깃을 알고만 있었고, 사용해보지를 않아서 팀원 그까지 제안하지는 못했다.

( "자, 팀원 여러분, 저도 잘 모르지만 같이 로컬 깃을 설치 해봅시다! 잘 되면 편하다고 하더라구요! 아마 다같이 빠르면 1시간 길면 3시간이면 에러 폭발하고 쌤한테 해결해달라고 할 수 있을 겁니다! 같이 잘 모르는 로컬 깃을 설치해봅시다!" 이렇게 속으로만 한 두 세 번 생각한 것 같다. 어쨌든, )

스마트인재개발원에서는 1차 프로젝트에 들어갈 무렵에 깃허브 관련 수업을 했다. 깃허브 가입을 공지하고, 이메일을 받아서 원생들을 모두 초대하고, 전체 프로젝트를 모아서 볼 수 있는 페이지를 만들었다. 그리고 관련해서 커밋, 풀, 푸쉬, 클론 등에 대해 사용법 위주로 간략하게 설명해주었다.

그리고 실제로 몇 번 충돌을 내고, 팀원끼리 궁리해보고, 이것 저것 눌러보다가, 진짜로 문제가 커질 것 같을 때 쯤, 혹은 급하게 처리해야 할 때, 선생님께 도움을 요청하기를 두 세 번 하니, 어떤 경우에 충돌이 나고, 어떻게 해결해야 할지 어느 정도 감이 잡혔다. ~~역시 보험이 있을 때는 실전이 최고 빠르다.~~ 이제 개념과 사용에서 commit, pull, push 를 알 것 같은데, 애매한 구석이 남았었다.

[내 머릿 속] 정리에는

★ 팀원이랑 같은 파일 작업 동시에 절.대. 안하기 : 가장 중요

★ 안 겹치는 것 확인했으면, 내 작업 커밋&푸쉬 / 다른 사람 거는 그냥 풀

★ 충돌이 나면, 맞는 형상으로 고치고 commit 또는 merge 또는 push 또는 셋 다.

이랬다. 실제로 맞는 형상으로 고치기만 하면 되는 경우, 그리고 그렇게 할 수 있으면, 이렇게 해도 문제 없다.(지금 내 이해로는 ㅇㅇ...)

하지만, 수업 중에 그런 말이 있었다. '커밋하고, 풀 받고, 푸쉬하시면 됩니다.' ~~(일단 이게 결론이긴 한데)~~ 그런데 내가 해본 경험에서 커밋은 아무 것도 아니었고, 푸쉬만 의미가 있었으며, 작업만 안 겹치게 하면, 풀은 천천히 몰아서 받아도 아무 문제가 없다. 그런데 왜 저렇게 해야 하느냐, 그것은 아래 블로그 링크를 가서 읽어보면 이해할 수 있다.

<Checkout과 Commit 그리고 Push와 Pull>
- https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=special9486&logNo=220201517482

<Push와 Pull 과정에서의 충돌 문제>
- https://m.blog.naver.com/PostView.naver?blogId=special9486&logNo=220204145669&targetKeyword=&targetRecommendationCode=1

"최승헌님의 블로그"라는 네이버 블로그로 2014년도 11월 12월에 작성되었다. 아마 이 당시에는 SVN이라는 중앙집중관리형 시스템이 널리 사용되던 시기인 것 같다. 새로 등장한 분산형상관리 시스템 github의 장단점을 설명해주시고 있다... 그래서 조금 길고, 적당히 자세하다. 이런 분들께 시간 내서 읽으시라 권장하고 싶다.

1. 사용법을 알겠는데 개념이 조금 애매하다.

2. 나도 그냥 푸쉬하는데, 왜 굳이 커밋하고, 풀 받고 나서 해라는지 잘 모르겠다.

3. 조금 자세히 보고 싶다.

여튼, 이해한 걸 음슴체로 요약하자면,

* 커밋 - 풀 - 푸쉬의 순서가 맞음.
** 커밋 - 풀까지 했을 때, 깃허브가 아닌 내 로컬 컴퓨터에서 충돌이 발생하여 안전하게 관리됨.
*** 내가 정리한 뒤에 깃허브에 푸쉬할 수 있도록 함.

***수정***

실제 프로젝트 중에 순서ㅜㅜ: 커밋-풀-푸쉬 XX

받을 때, 그냥 풀 : 파일이 안 겹치는 전제 하에, 아니면 커밋하고 풀 받은 다음 전부 새로 받은 것으로 merge 하면 됨(편집됨)
올릴 때, 커밋 - 푸쉬 [어차피 버튼이 커밋& 푸쉬]
이유: 로컬에서 싱크로 작업을 해주는 게 가장 안전하지만, 그렇게 까지 하기에는 시간 촉박/ 그 정도의 대규모 복잡한 프로그램이 아님. 이클립스의 깃으로 풀 푸쉬를 하면서 생기는 편의성이 사라짐...
현업에서는 브랜치를 사용하고, 상급자가 그걸 확인한 후 머지한다 하지만 지금 나의 현재 프로젝트 진행은 모두 master branch에 바로 커밋 중임

***수정***

블로그 글에서 내 이해를 도운 배경지식이 이것이었다. 전혀 모르는 것은 아니었지만, 파편화된 지식을 연결시켜주었다.

1. github 이전에 중앙관리시스템(SVN 등)을 쓰고 있었다.

2. github는 원격저장소(remote repository)뿐만 아니라 각각의 로컬 컴퓨터에도 저장하는 방식이다.
3. 이클립스에서 하는 commit은 내 로컬에 현재 형상을 저장하는 기능이다.
4. commit 후, pull을 받는 것은 내 로컬 커밋이 원격(깃허브)의 최신 형상(코드 내용)과 충돌이 없는지 확인 하는 것이다.
5. 이후 충돌이 없는 것을 확인하면 커밋했던 내용들을 푸쉬하는 것이다. (이게 정석인 듯.)

6. 혹시 충돌이 있다면, 내가 커밋했던 내 로컬의 과거 이력을 통해 되돌릴 수 있다.

[참고 캡쳐 본]