[GitLab/BFW 스튜디오 #1] 간단 Pull Push 정리 Unstaged Changes, Add to Index, Replace with HEAD Revision, Push to origin 표준개발프레임워크 환경

깃을 처음 접했을 때는 복잡하고 불친절하다는 생각을 했다.

하지만 사용하다 보니, 나름의 방법을 알게 됐고, 어렵지 않게 사용할 수 있게 됐다.

그 썰을 풀어보려고 한다.

 

 

(---- 스킵 가능 시작 ----)

필자는 생각보다 나이가 적기도 하고, 많기도 하다.

IT 회사에 입사하면서 IBM 대형 컴퓨터에 더미 단말로, 게다가 코볼로 코딩을 시작했다.

다행히 회사에서는 발전하는 기술을 배울 수 있는 기회를 주기도 했지만,

이미 시기는 늦어버려서, 별로 영양가는 없었다고 생각된다.

그래도 지금까지 일할 수 있다는 것에 감사할 따름이다.

 

쨌든 Git이라는 것은 몇 년 전에 알게 됐다.

물론 IT 뉴스 등에서 옅들어보긴 했지만

뭔지는 모르고, 그저 그런 게 있나 보다 했다.

 

IBM 환경에서 일하던 실절에는 그저 SVN이 큰 충돌 없이 일할 수 있게 해줬기 때문에 아무런 고민없이, 일하는 데 별탈없이 일했던 것 같다.

하지만 세상은 바뀌고, 수많은 사람들이 Git을 쓰면서 환경이 점점 바뀌고, 결국 필자도 Git을 쓰지 않으면 안되는 상황이 되어버렸다.

 

옆에 있는 젊은 친구(개발자)가 간단히 알려줘서 배우긴 했지만, 그 친구도 거의 초보 수준이어서 도움이 됐는지, 헷갈리게 만들었는지 따져볼 일이다.

 

쨌든 나름의 방식을 익히게 됐다.

Git이 그리 어렵지 않게 만들어졌고,

수많은 개발자들이 취미든, 업무든, 다양한 방식으로 사용하고 있어서 상식적인 선에서 잘 해결할 수 있는 환경이 구축되어 있는 것 같아보였다.

 

하지만 기본적인 기능을 이해하기 전까지는 헤맬 수 밖에 없어서...

꼰대 같은 나이가 됐고, 그런 위치에 있지만, 기본적인 기능만 사용하고 나니, 별 어렵지 않게 사용할 수 있어서 그걸로 Git을 편하게 쓰게 된다.

 

(---- 스킵 가능 끝 ----)

 

 

 

1. Pull (당기다, 끌어당기다, 획득하다 등의 의미)

  Git Repository(저장소) 에 있는 최신 소스(파일)를 내 컴퓨터로 내려 받는 것을 말한다.

  가장 자주 하는 작업일 것 같다.

   Pull Result for ooo 창이 떠서 Fetch Result와 Update Result를 확인할 수 있다. 하루에도 몇 차례 씩 봐야하는 거라 익숙해질 거 같다.

  단, 충돌이 발생할 수 있는데, 그건 다음에 설명될 예정이다.

 

2. Push (밀다, 밀어넣다, [새것을 이전 것에] 더하다 등의 의미)

  Pull 과 반대 개념으로 Git Repository(저장소) 에다가 내 컴퓨터에 있는 최신 소스(파일)을 밀어넣어 올리는 것을 말한다.

  역시 자주 사용하는 작업이다.

  단, 이것도 충돌이 발생할 수 있어서, 간단하게 주의해줘야 할 것이 있다.

 

3. Git Staging

 Git의 상태를 파악할 수 있는 탭이다.

  Unstaged Changes

 

4. Add to Index

  Git Repository(저장소)에 추가하는 명령이다.

  Unstaged Changes 에 대상 목록이 뜨고, 거기에서 해당 소스 파일을 선택해서 건건이 올릴 수 있도록 되어 있다.

  아직 Push 하기 전 단계이므로 부담 없이 추가하자. 그리고, 또 수정이 발생하면 다시 추가해주면 Update된다.

 

5. Replace with HEAD Revision

  많이 사용하게 된다. 이미 Git Repository(저장소)에 저장되어 있는 버전으로 덮어버리겠다는 뜻으로 수정을 취소하겠다고 이해하면 되겠다. 

 

☆ 이 정도가 기본적으로 사용하는 기능들이다. 이것에서 벗어나는 것은 관리자(?)에게 도움을 요청해야 한다. 특정 버전으로 원복을 하고, 날아간 Push를 복원하는 것은 개인의 몫일 가능성이 높다.

  아쉬운 부분이다.

  하지만 저렴하게(?) 모든 유저의 Push를 제대로 반영해주는 Git으로서는 할일 다했다고 보는 것이 맞을 것이다. 그렇게 이해하는 것이 마음이 편한 것 같다.

  애시당초 사용법에 대해서 자세하게 안내해주면 될 일이겠지만, 어디 프로젝트에서 그렇게 해주나....

  힘들겠지만, 아쉽지만, 삽질로 극복해보자. 언젠가는 익숙해지고, 그러려니 하면서 맘껏 Push 때리는 날이 오게 될 것이다.

 

* Push 충돌 시 조치 방법

  - Git Stating 탭의 맨 밑에 있는 Push HEAD... 버튼을 눌러서 "저장소"에다가 밀어넣어야 하는데, 에러가 발생됐다고 창이 뜬다면 당황하지 말고 차근차근 풀어보자.

 

  (1) 내 컴퓨터에 있는 소스가 최신이 아닐 경우에 "저장소"에다가 Push할 수 없다. 그래서 에러가 난 것이다.

  (2) 그래서 Pull 로 내 컴퓨터에 있는 소스를 최신으로 만들어줘야 한다.

  (3) 그리고 다시 Push 해보자. 그럼 된다.

    - 허걱... Push HEAD... 버튼을 누를 수 없게 됐다? 놀라지 말자. 이건 이미 Push가 준비되었다는 말이다.

    -> Package 의 최상단에 있는 master를 선택한 뒤 오른쪽 마우스를 클릭하고,

    1) Team - Pull 클릭해서 컴퓨터 소스를 최신 버전으로 내려받고,

    2) Team - Push to origin 을 클릭해서 이미 Push HEAD... 해 둔 내용을 "저장소"에 밀어넣어 보자.

    3) 앗, 만일 그래도 안된다면 그 사이에 누군가가 Push를 해서 "저장소"가 바뀌었기 때문이다.

  - 퇴근시간에 자주 일어나는 증상이므로, 1,2분 정도만 기다렸다가 하거나, 만일 직원들이 보인다면 미어캣처럼 고개를 들어서 둘러보자. 최악의 경우 눈치 게임처럼 될 수도 있지만, 곧 Push에 성공할 가능성이 높다.

 

300x250

* Pull 충돌 시 조치 방법

  - 누군가 다른 사람에 의해 발생되는 경우가 많다. 물론 내 잘못도 있을 수 있지만, 다행히 잘 피해가고 있다. 사실 기본만 지키면 피해를 주지 않을 수 있다. 하지만 기본을 지키지 않는 유저가 있다면 반복해서 문제를 일으키게 되고, Git 관리자는 실의에 빠지게 되는 것이다. 잘 도와주자.

 

  (1) Git Staging 탭 에서 조치

    - 알림창을 통해서 조치하는 방법도 나쁘지 않지만, 단순하게 파일을 찾아서 삭제하거나, 조치하는 방법은 뭔가를 모를 때가 해보는 작업이지, 자칫 잘못하면 더 문제를 일으킬 수 있다.

    - 그래서 Git Staging 탭을 잘 활용하자.

    - Unstaged Changes (?) ? 표에 나오는 숫자가 변경되어 있는 건수를 알려주고, 그 아래에 내역을 볼 수 있다.

    - Presentation 활용하자.

     -> List, Tree, Compact Tree 가 있어서 옵션을 잘 선택하면 어떤 것이 수정됐는지, 어떤 것이 잘못되어 남아있는 것인지 등을 파악하기 편하다. 개인적으로는 Tree 가 보기도, 관리하기도 편한 것 같다.

 

  (2) Replace with HEAD Revision

    - 내가 수정하지 않은 것은 Replace with HEAD Revision 하자.

    - 수정된 목록이 > 로 표시되어 목록에 보인다.

    - 내가 수정했으면 Add to Index 하고 나서 Push HEAD... 하면 된다.

     - ? 는 이건지 저건지 애매한 것이다. 개인적으로는 그냥 놔둔다.

     - x 는 이미 삭제된 쓰레기가 남아있는 것이다. 그래서 역시나 Replace with HEAD Revision 하면 사라진다.

 

    - 매우 정상적으로 Push 했다면 더이상 할 일이 없다. 하지만 꼭 누군가의 실수인지, 사고인지에 의해 Git 사용자들이 불편을 겪게 된다.

     - 다양한 사람들이, 개발자들이 함께 작업하는 환경이 많아져서, 잘 다스리고, 사용해야 할 것 같다. 피할 수 없으면..... 즐겨라...