작업사항에 큰 변동사항이 없는 경우는 깃 클론, 풀, 브랜치 셋팅 까지는 CLI에서 하는게 더 편하고 직관적이다.
물론 그것도 어떤 브랜치에서 작업중인지, 커밋은 몇 개고 푸시해야하는건 몇 개고 수정해야하는 것은 몇 개인지
간략하게 보여주는 깃 설정을 깔았기 때문이지 아니었다면 비슷하긴 함.
그러나 협업이라는게 늘 그렇듯 암만 역할분담이 되었다고 해도 같은 파일을 고치는 경우가 분명 존재하기 마련
그리고 그 순간에 Conflict가 많이 발생한다고 가정했을 때,
CLI에서 그 컨플릭트를 확인하고 고칠 순 있겠지만
IDE가 충분히 직관적으로 잘 보여주고있는데 그런 작업을 굳이 CLI에서? 라는 생각을 한다.
IDE에서 제공하고있는 GIT 명령어들의 모습들이다.
해서 내가 CLI와 IDE를 쓰는 방식은 아래와 같다.
목차
1. 깃 pull, 로컬브랜치 생성
1-1. CLI
이 단계부터 IDE를 쓸 수도 있긴 하지만
나는 현재 브랜치 위치도 알고싶기도하고 이게 익숙해져서 CLI에서 진행한다.
>(dev) git pull
>(dev) git switch -c feat/new작업을 시작할 때 로컬 dev브랜치에 최신버전까지 pull땡겨놓고
만들려고 하는 기능관련된 로컬브랜치를 하나 생성하여 그 쪽으로 이동 후 작업을 한다.
1-2. IDE
물론 이와 같은 작업을 IDE에서도 충분히 할 수 있다.
현재 내 로컬 브랜치 위치는 인텔리제이 오른쪽 하단 구석에 표기되어있다.
그치만 열심히 예쁘게 꾸며둔 터미널도 좀 쓰자꾸나 ^^
추가로 브랜치를 생성하는 것도 CLI와 IDE중에선 CLI를 선호하긴 한다.
> git switch -c feat/order
2. 커밋작업
그러고 작업이 대강 다 끝난 후 커밋단계부터 IDE를 사용하고 있다.
CLI에서 파일을 나눠서 add하고 commit쓰기에는 너무 귀찮음..
>git add <경로 및 file명> <경로 및 file명> <경로 및 file명>
>git commit -m "[Feat] MemberController API추가"내가 어떤 파일을 수정했다고 가정하면 IDE에서 깃 플러그인이 설치되어있다는 전제 하에
왼쪽 탭에 Commit이 보이고 거기서 어떤 파일들이 변경되었는지 보여준다.
이 때 굳이 add 단계가 필요없다는 점이 IDE쓰는게 좋은 이유다.
사진 설명을 입력하세요.
커밋을 몰아서 하는 경우가 많을테니 묶어서 커밋메세지를 쓸 것들만 체크하고
하단부에 커밋메세지를 쓴 후 'COMMIT'까지만 하자.
COMMIT AND PUSH는 혼자 할때나 쓰도록^^..
3. MERGE / REBASE
이제 대망의 로컬dev(최신 커밋을 받아온 - git pull) 에다가 내가 작업한 로컬브랜치를 머지/리베이스 하는 작업을 해야한다.
이 부분은 좀 방식이 다르긴 한데 나는 안전제일주의라 커밋까지 다 해둔 로컬브랜치 하나 더 카피해서 만들고
해당 브랜치에다 dev를 머지/리베이스 하는 작업을 한다.
3-1. CLI
# feat/order2 를 dev에 rebase 하겠다.
>(dev) git rebase feat/order2 dev# dev를 feat/order2에 rebase하겠다.
>(feat/order2) git rebase dev feat/order2
3-2. IDE
상단에 보이는 Merge into [ 브랜치명 ] 의 브랜치명은 내 현재 브랜치가 뜬다고 보면 된다.
빠밤! 근데 Conflict가 났어요!!!
(위에 적힌 dev into branch feat/order2는 무시하자. 캡쳐를 생각날때마다 해놔서 캡쳐부분부분이 좀 기묘함)
받아오는 파일이 16개 정도가 됐는데 그 중에서 4개가 충돌이 났다.
그럼 우리는 이걸 깃에 올라온 마지막 커밋내용과 내 커밋내용을 잘 조합해서 고친 후 머지를 해줘야한다.
ACCEPT YOURS : 내 feat/order2의 내용으로 무조건!! 반영되어야 하면 이걸 누르자.
이 때 dev에 혹시 내가 작업하지 않은 변경분이 있다면 해당 내역은 다 날아간다.
ACCEPT THEIRS : 깃에 올라온 dev의 내용이 맞다면 이걸 누르자.
이 때 내 브랜치에 작업한 내용이 있다면 다 날아간다.
MERGE.... :
눈으로 보고서 직접 뭐가 맞는지 확인 후 고칠 수 있게 해준다.
보면 누를 수 있는 버튼이 세개가 있고 탭도 세개가 있다.
순서대로 왼쪽탭 - ACCEPT LEFT / 오른쪽탭 - ACCEPT RIGHT / 중간탭 - 최종 수정본
어쨌든 해당하는 것을 APPLY하거나 고친 후 APPLY를 누르면 아래와 같은 창이 뜬다.
아.. 이거 어떻게 했는지 갑자기 기억이 안나네??
Continue Merge를 누르면 아까 4개 Conflict가 났고 처음껄 고쳤던 상황인데 나머지 Conflict도 고칠 수 있는 창으로 돌아갔던 것 같고 (이번 변경분은 반영됨)
APPLY CHANGE AND MARK RESOLVED를 누르면 변경분이 반영되는 건 똑같은데 머지하던 창이 꺼졌던 것 같다? (다음에 하면 포스팅 수정하겠음)
아마 꺼지고나서 본문에 남아있는 Conflict난 3개의 파일에 들어가보면
<<<<<<<<<<<<<HEAD
내 작업내용~~~~~
========================
dev 내용~~~~~~ (여기선 없어서 공백)
>>>>>>>>>>>>>>>>> dev이런 흔적들이 남아있어서 알아서 잘 보고 고치면 된다. 이러고나서 컨플릭트 다 수정하고나면 푸시하면 됐던 것 같기도......?
*rebase랑 merge랑은 쓰기 나름이긴한데 보다 깔끔한 커밋히스토리를 위해서는 rebase를 좀 더 선호한다고 한다. 또한 merge는 merge commit history가 남는 것도 싫긴 함.
두개의 차이점 및 장단점 부분은 git rebase사용이유 를 참고해보면 좋겠다.
4. PUSH
위에서 잘 rebase든 merge든 했다고 치자. 사실 난 push 작업은 CLI에서 한다.
4-1. CLI
# git push [원격저장소별칭] [위에서 머지해놓은 브랜치]:[원격브랜치]
>(feat/order2) git push upstream feat/order2:dev보통은 dev 에다가 머지를 많이들 할테고
그 dev를 원격브랜치에 push할 때는 두개의 이름이 같아서 굳이 위와 같은 추가 명령어(?) 작업대신 깔끔하게 쓰고 끝날 수도 있다.
>(dev) git push upstream
4-2. IDE
지금은 내가 푸시를 싹 다 한 상태라 (IDE에서 안해서 캡쳐본이 없다 ㅎㅎ;) 깨끗한데
암튼 GIT - PUSH를 하면 커밋한 내용을 푸시할 수 있다.
캡쳐대로 푸시하면 아마 원격브랜치가 새로 생성이 돼 버릴 것임!
dev에다 올릴거면 upstream:옆을 수정해줘야한다.
5. Show Git Log
IDE에서 가장 행복한 기능이 깃 로그 보기다.
왼쪽 탭은 현재 내 로컬 브랜치는 뭐가 있고 원격 브랜치는 뭐가 있는지 보여준다.
Local main옆의 다운로드 모양은 - 추가된 커밋내용이 있으니 pull받아라.
그러면 우클릭하고 Update받아주면 된다. Pull과 똑같음!
이걸 CLI에서 작업하려면 기존 변경분을 커밋/스태시하고나서 switch 하라고 자꾸 떠서 귀찮은데
Update 딸깍이면 알아서 다 받아놓기때문에 좋다.
가운데 브랜치 모양 그래프는 어떤 커밋들이 어떤 브랜치들을 따라 머지되고 리베이스됐는지 볼 수 있다.
또한 커밋 내역을 클릭해보면 오른쪽 탭에 어떤 파일들이 수정됐는지 리스트가 떠서 확인하기 좋다.
커밋을 우클릭하면 CLI에서는 커밋 리버트나 메세지 수정 등의 작업을 위해
커밋코드도 알아야하고 명령어로 HEAD 어쩌고저쩌고 하는거 치면서 지지고볶고 해야하는데
여기서는 드래그로 한번에 Revert Commit이 가능하며 Edit Commit Message도 딸깍 한번이면 가능하다.
개꿀이니 다들 IDE쓰세용
Visual Studio Code도 충분히 잘 되어있다고 하니 쓰는 법은 얼추 비슷할 것이다!
'IT이야기 > GIT' 카테고리의 다른 글
| 맥 터미널 GIT 사용법 - 원격 브랜치, 로컬 브랜치, 깃플로우 등 협업의 시작부터 끝까지 깃허브 사용법 (1) | 2024.01.15 |
|---|
