Simple Git Workflow(Pair)
Sprint Office Hour(Zoom)
Simple Git Workflow(Pair)
Git Command Checkpoint
Sprint Review(Zoom)
Course Reflection(Zoom)
Weekly Self Check & Reflection(Survey)
Pair Review, Sprint Feedback(Survey)
Simple Git Workflow(Pair)
오늘은 어제 작성한 혼자 작업 workflow에 이어서 pair와 함께 작업 workflow를
Simple Git Workflow라는 sprint를 통해 진행한다.
근데 생각해보니 pair와 같이 하면서 써야하는 Git workflow 실습 레파지토리를
clone후 변경하여 나의 remote repository에 push했기에 pair와 함께 실습하려면 reset을 해야한다.
9시에 pair programming이 시작이기때문에 얼른 reset을 시작했다. (7분 남았다.)
Reset for pair programming(commit message) 왼쪽의 profile name을 클릭하면 아래 사진과 같은 화면이 나타난다.
저기서 Reset for pair programming을 클릭하면 변경사항을 볼 수 있다.
이렇게 내나름대로 reset이랍시고 reset을 했는데 sprint office hour를 통해 알게된 것은
github에서 나의 remote repository에서 settings(바퀴모양)을 눌러 delete this repository를 클릭하면 한방에 없어진다.
나는 프로 삽질러다. 허무하지만 이렇게 solo workflow를 복습할 수 있었다.ㅎㅎ
사진은 아래와 같다.
Simple Git Workflow(Pair 실습)
: 충돌이 생기지 않는 과정과 충돌이 생기는 과정, merge가 되는 경우를 소개한다.
- 나의 작업 Directory를 init을 통해 Git의 관리 아래(Local Repository) 들어가게 만듦.
- Git Directory(Local Repository)를 remote add(origin 본인의repository주소)를 통해 본인의 Remote Repository와 연결해줌.
- remote add를 활용해서 다른 사람의 Repository와 연결 가능.
- remote add 상대의repository이름 상대의repository주소로 상대방의 Repository와 연결.
- remote -v로 연결 확인.
- pull 상대의repository이름 master로 상대의 Remote Repository에 있는 작업내용을 받아올 수 있음.
- 이때 충돌이 발생할 수 있음. 해결.
충돌이 생기지 않는 과정
: simple git workflow를 위한 fork과정과 clone 과정은 생략되었음을 알려드림.
git remote add pair repository주소 명령어로pair의 repository와 연결한 후 git remote -v로 연결을 확인하였다.
내가 먼저 파일을 수정하여 git add, git commit -m, git push하여 나의 remote repository에 commit을 남기고
이를 페어님이 git pull pair master하였다.
아래 사진은 수정부터 push까지의 과정이다. 생략하기는 그래서 사진을 이어붙이겠다.
아래 사진부터는 pair님의 화면을 캡쳐한 것이다.
pair님은 git pull pair master로 나의 수정본 파일(Fixed v 1.0.0)을 가져 갈 수 있었고, git log로 pull한 기록을 볼 수 있었다.
git pull 후에 git status를 하면 commit할 수 있는 것이 없다고 나오며 pair가 수정하기 전 push를 진행하였다.
그 이후 github을 들어가보면 내가 수정하였던 Fixed v1.0.0을 pair의 화면에서도 확인할 수가 있다.
(sprint할 때 파일을 디스코드로 보내주던 시절이여 잘가라!! 이제는 git으로 update내용을 서로 공유하고 협업할 수 있다. )
아래 사진을 참고하자.
이제는 pair님이 나의 Fixed v1.0.0을 수정하여 파일을 update하고 내가 그것을 받기로 하였다.
nano로 수정, git add, git commit, git push
(많이 쓰다보니 지겨울것 같지만 이렇게 공유한 적이 처음이라 페어님과 나 둘다 재밌게 했다.)
아래 사진으로 push가 정상적으로 되었음을 알 수 있다.
다시 나의 차례가 되었다.
git pull pair master로 fixed v1.0.1을 당겨오고 이를 push하여 fixed v1.0.1을 나의 remote repository로 넣고 이를 확인했다.
이와 같이 충돌이 생기지 않는 정상적인 상황을 pair님과 함께 실습해보았다.
이후 충돌을 유도하기 위하여 pair님과 함께 이상한 짓을 많이 하게 됬다.
의도적인 충돌은 쉽지않았고 우여곡절 끝에 성공했다.
아래에서 충돌 유도과정 및 충돌 시 해결 방법을 알아보자.
충돌이 생기는 과정
: 여기서 git pull, git add, git commit, git push 과정은 말로만 설명하고 사진은 생략하겠음
충돌을 시도했던 첫번째인 fixed v1.0.2는 실패로 돌아갔다.(사진이 너무 많아서 생략)
여기서 멈출수 없다. 무엇이 잘못됬을까 생각하다가 IM Full 29기 디스코드방에 올라온 링크를 보고 힌트를 얻었다.
아래를 참고하면 되겠다.
Git으로 버전제어: 충돌 (Conflicts)
사람들이 병렬로 작업을 할 수 있게 됨에 따라, 누군가 다른 사람 작업영역에 발을 들여 넣을 가능성이 생겼다. 혼자서 작업할 경우에도 이런 현상이 발생한다: 소프트웨어 개발을 개인 노트북
statkclee.github.io
충돌 재도전!
핵심은 pair님과 나 둘의 업데이트 싱크를 맞추어놓고 각자 파일상 같은 줄에 다른말을 적고 이를 각자 push해놓고 pull 해 보자는 것.
페어님의 작업화면은 아래와 같다.
나의 작업화면이다.
충돌을 위한 각자의 염원을 담아 파일을 수정하고 push까지 마쳤다.
이제 서로 에게서 pull을 해보자!
결과는 아래와 같다.
pair님께서 먼저 충돌 파일을 병합하고 본인의 remote repository로 push하셨다.
위처럼 pair님이 병합하고 push하신 파일을 내가 pull만 해오면 충돌은 해결이 되는 것이다.
하지만 나도 똑같이 pair님 처럼 그대로 수정을 해야하는 줄 알고 다 수정하고 pull을 하는 어마어마한 삽질을 했다.
병합을 양쪽에서 해야하는 거면 git을 불편한거 같은데라고도 생각했다.(참으로 무지했다.)
상대가 병합하고 올려 놓은 것을 pull만 하면 끝난다는 것을 sprint review 시간에서야 알게됬다.. ㅎㅎ
그래도 알았으니 됬다!
충돌을 진행하면서 나만의 언어로 git에서의 충돌을 정의하였는데 그것은 아래와 같다.
conflict
본인이 작업한 변경사항이 다른 사람이 작업한 변경사항과 겹치는 것을 Git이 알아채고,
앞에서 작업한 서로의 코드들이 뭉쳐지지 않도록 지켜주는 것.
추가로 sprint review에서 짚어준 것을 적고자 한다.
그것은 바로 merge와 conflict가 일어나는 조건? 상황?이다.
merge : 서로가 같은 줄에 작업하지 않는 것을 전제로 한다.
A : 변경사항을 A본인의 local repository에 commit 단계까지 완수한다.
B : 변경사항을 B 본인의 remote repository에 push하는 단계까지 완수한다.
이때 A가 B의 remote repository에 있는 파일을 git pull pair master(이 명령어는 바뀔 수 있다.) 한다면
merge가 일어나게 되고 자동으로 commit된다.
conflict : 서로가 같은 줄에 작업하는 것을 전제로 한다.
A : 변경사항을 A본인의 local repository에 commit 단계까지 완수한다.
B : 변경사항을 B 본인의 remote repository에 push하는 단계까지 완수한다.
이때 A가 B의 remote repository에 있는 파일을 git pull pair master(이 명령어는 바뀔 수 있다.) 한다면 conflict가 일어난다.
여기서 A가 병합 후 git add, git commit, git push하여 A 본인의 remote repository에 올려놓은 파일을 B가 pull한다면
더이상 conflict는 발생하지 않고 A의 병합된 파일을 받게 된다.
이렇게 오늘은 git에서의 협업 workflow를 익혀보았다.
개발자라면 달고살아야하는 git.
그것을 배웠다.
충돌일으킨다고 별의별 짓 다한게 재밌는 추억이 될 것이다.
p.s. 오늘 sprint office hour에서 1일 1커밋 / 깃헙 잔디 이야기를 들었다. 1일 1커밋의 개념으로 블로깅을 하고 있었지만,
개발자가 되려면 그들처럼 되어야한다. 1일1커밋 운동을 실천할 수 있는 계획을 주말에 수립해 보아야겠다.
'코드스테이츠' 카테고리의 다른 글
| 2021년 4월 20일 코드스테이츠 DAY-16(객체 코플릿) + twittler mock-up 계획(wireframe) + figma 사용법 숙지(인강) (0) | 2021.04.20 |
|---|---|
| 2021년 4월 19일 코드스테이츠 DAY-15(배열, 객체) (0) | 2021.04.19 |
| 2021년 4월 15일 코드스테이츠 DAY-11(Linux 기초, Git 기초) (0) | 2021.04.15 |
| 2021년 4월 14일 코드스테이츠 DAY-10(Linux 기초) (0) | 2021.04.14 |
| 2021년 4월 13일 코드스테이츠 DAY-9(계산기)(calculator)#2 (0) | 2021.04.14 |
