본문 바로가기

Git

Git CLI 협업2

지난 시간에 두개의 컴퓨터로 가정하고 a,b 라는 디렉토리를 만들었습니다.

bash창을 두개를 켜서 각각의 컴퓨터라고 가정을 하고 실습해보겠습니다.

 

 

a라는 디렉토리에 2a 라는 내용을 추가해주었고요.

 

커밋까지 완료 해주었습니다.

 

 

push 까지 해주겠습니다.

 

 

그리고 원래라면 b라는 디렉토리에서 원격저장소에 pull로 당겨온 후에 작업을 해야하는데

깜박해서 그냥 b에서도 똑같이 작업을 했다고 가정해보겠습니다.

 

 

 

그리고 커밋을 해주겠습니다.

 

그렇다면 a에서 최신버전으로 작업을 했는데 b에서 pull을 안하고 작업을 해서 최신버전이 갱신되었죠?

둘이 동시에 작업하는 경우일 수도 있겠고요. 그럼 작업을 끝냈으니 push을 하게 되면 어떤 상황이 벌어지는지

보겠습니다.

 

 

git에서 reject [거절] 하였습니다. 

그리고 pull로 가져오고 타임라인으로 잘 정리정돈 하라고 말해주네요.

그럼 말대로 git pull을 해보고 cat으로 내용을 확인해보겠습니다.

 

 

a에서 같은 2번째 줄을 수정하였고, b도 2번째 줄을 수정하여서 충돌이 일어났습니다.

여기서 툴로 수정을 하고 싶다면 

git mergetool

 

수동으로 수정을 한다면 

nano work.txt

 

저는 수동으로 수정을 하겠습니다.

2ab 라는 내용으로 수정을 하였습니다.

 

 

다음은 add로 git에게 충돌을 해결했다고 말해줍시다.

 

 

해결하였으니, 커밋도 해줘야겠죠?

git은 저희가 충돌했던 사실을 알기 때문에 자동으로 메세지를 만들어줄 것 입니다.

git commit

 

이렇게 로그를 확인해보시면 방금 만든 버전이 잘 올라간 것을 확인할 수 있습니다.

 

이렇게 a라는 사람이 수정한 work 2a (3d6a7fb) 와 b가 작업한 work 2b (c87a570) 을 동시에 조상으로 갖는

a208cb라는 새로운 버전이 생성되고 원격저장소로 push하게 되면 올라가게 됩니다.

 

 

그럼 a라는 사람은 git pull로 작업한 내용을 가져와야겠죠?

사진은 pull 하기 전의 모습과 pull을 한 후의 모습입니다.

 

before

 

after

 

이렇게 되면 a컴퓨터와 b컴퓨터의 버전내용이 똑같아졌습니다.

그리고 여기서 우리가 얻을 수 있는 교훈은

 

최대한 작업을 빨리 끝내고 push을 자주해야지 서로 충돌이 일어나지 않겠죠?

그리고 작업전에 항상 pull을 통해서 다른사람이 업데이트를 했는지 확인하는 것이 중요하고

그리고 git의 이러한 특성으로 인해서 커밋과 푸쉬 풀을 자주하게 촉진하고 

팀의 커뮤니케이션을 더욱 활발하게 만드는데 기여하겠습니다.

'Git' 카테고리의 다른 글

Git cherry-pick & rebase  (0) 2024.01.31
Git CLI 협업3 (fetch)  (1) 2024.01.31
Git CLI 협업  (1) 2024.01.31
Git CLI merge & conflict 병합  (1) 2024.01.23
Git CLI branch  (1) 2024.01.22