일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- EC2
- wetube
- 채팅
- Class
- SSA
- 카톡
- S3
- 중급파이썬
- TypeScript
- 튜플
- pandas
- SAA
- dict
- async
- flask
- Vue
- lambda
- git
- MongoDB
- react
- socket io
- 파이썬
- docker
- Props
- crud
- node
- NeXT
- AWS
- merge
- RDS
- Today
- Total
목록git (21)
초보 개발자
대부분의 되돌리기 작업을 하면 협업하는 다른 사람에게도 영향을 미칠 수 있다. 기본적으로 나만 작업하는 특정branch 하나에만 적용한다라고 생각하자. amend 작업하다가 commit 메시지에 오타가 났다거나 수정하고싶을 때가 있을 것이다. 이 때 최신의 commit을 수정하는 것을 amend라고 한다. amend로는 가장 최신의 commit만 고칠 수 있다는 것을 꼭 기억해두자. 그 전의 commit은 못고침 먼저 브랜치를 하나 만들어주고 파일을 2개 수정해보자. 그런 뒤 2개가 아닌 하나만 커밋을 해버렸다. 그럼 소스트리에서는 아래와 같을 것이다. 이를 수정해주기 위하여 소스트리의 파일상태로 가서 커밋을 정정해주자. 커밋 메시지도 변경할 수 있다. 변경후 history를 보면 아래와 같이 잘 수정이..
내가 주인이 아닌 다른 repo에 PR하려면 어떻게 해야할까?? 바로 fork(프로젝트 복사)가 필요하다. repo의 사용권한이 다른사람에게 있을 때 예를 들면 많은 사람들이 참여하는 오픈소스처럼, 내가 소유하고 있는 repo가 아니더라도 프로젝트를 제안할 때는 일단 프로젝트의 내용을 내 공간으로 가져와야 한다. 먼저 fork할 repo에 가서 fork버튼을 눌러주자 그럼 repo주소가 이렇게 바뀌는 것을 확인할 수가 있다. 이제 이걸 내 컴퓨터에 클론 해 온 다음에 거기서 작업을하고 푸쉬를 한 뒤 pr을 날려보자. 왜냐하면 우리는 저 repo에 작업권한이 없기 때문이다. 주소를 복사해 온 뒤 소스트리에 가서 주소를 복사하여 클론해보자. 그리고 브랜치를 생성하여 작업을 해보자. 작업을 한 뒤 커밋 후 푸..
merge를 할 때 경우에 따라 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. 이걸 PR후 merge라고 한다. PR(Pull Request)느 내 작업내역을 바로 merge하지 않고 참여하고 있는 프로젝트 내 작업(branch)을 merge해달라고 요청(Request)을 먼저 보내는 것이다. 작업한 내용에 대해 코드리뷰를 하거나 토론하면서 개선시킬 수 있는 기회가 생기는 것이다. 프로젝트 기준에 맞지 않는다면 PR은 거부될 수도 있다. 이렇게 리뷰한 후 작업내역을 최종 반영하면 프로젝트 퀄리티가 더 높아질 것이다. 또 기본적으로 프로젝트 품질을 관리해야 하는 회사에서 작업하거나, 여러 사람들이 참여하는 오픈소스에서는 PR후 merge하는 과정을 거치게 된다. 먼저 같은 repo안에서 기본 브랜..
원격 repo는 로컬 repo가 연결되어있다고 했다. 하지만 사실 이 연결은 로컬 repo의 브랜치와 원격 repo의 브랜치가 연결된 것과 같다. 따로 설정을 해주지 않는다면 기본적으로 로컬 repo의 브랜치명과 같게 원격 repo의 브랜치 명이 생성이 되어 tracking을 한다. commit history에 보여지는 orgin/main 혹은 origin/master이름표는 원격 repo의 main 혹은 master 브랜치라는 뜻이다. 원격 repo를 연결할 때 origin이라고 적어주었기 때문에 앞에 origin이 붙는다. origin/HEAD는 현재 어떤 것을 가리키고 있는지이다. 그림으로 나타내면 아래와 같다. pull과 push는 결국 특정 branch에 있는 commit을 여기와 연결되어 있는..
하나의 파일을 여러 브랜치에서 수정하고 하나의 branch에 merge하려고 할 때 merge conflict(병합 충돌)이 발생한다. 이 것은 오류가 아니다. 양 쪽에서 내용이 수정되었는데 어떤 내용을 반영해야 할지 사용자에게 물어보는 것이다. 국물 내는 비법을 추가하는 feature/stock브랜치와 르탄이의 가문의 김치찌개 비법을 추가할 jjigae_rtan 브랜치를 만들어서 작업하려고 한다. 다른 브랜치에서도 같은 파일을 수정해서 일부러 Merge conflict를 내고보 충돌을 해결해보려고 한다. 우리가할 작업은 아래와 같다. 먼저 main에서 브랜치 2개를 만들어 주었다. 그리고 feature/stock으로가서 2개의 커밋을 해주었다. 그리고 feature/jjigae_rtan으로 가서 같은 ..
각자 작업한 것을 프로젝트에 합치기 위해 Merge를 사용한다. 1단계, 누가 작업할 것인지 정한다. -issue 2단계, 각자 맡은 것을 작업한다. -branch 3단계 각자의 작업을 프로젝트에 합친다. -merge Merge는 브랜치를 다른 브랜치에 합치는 것이다. 즉 특정 브랜치의 commit들을 다른 브랜치의 commit 내역에 모두 반영하는 것이다. 기본적인 설정은 해당 브랜치의 모든 commit을 모두 다 반영한다고 생각하면 된다. 브랜치 하나를 Merge하기 먼저 합치기 위해선 먼저 합치려고 하는 브랜치에 checkout이 되어있어야 한다. 우린 main에 합치려니까 main으로 체크아웃을 해주자. 그리고 소스트리에서 병합을 누른다. 그리고 2_jjiage라는 브랜치를 선택해주자 옵션은 이 ..
새로 생긴 브랜치의 시작점은 기본적으로 갈라져 나온 브랜치(main)의 최신 commit부터이다. feature(기능추가)/2(이슈넘버)_jjigae(브랜치이름) 이런식으로 이름을 정해준 뒤 만들어 주고 체크아웃(브랜치로 이동 하는 것을 뜻함)해준 뒤 기존 파일을 수정하고 커밋을 해주면 아래와 같이 생긴다. 체크아웃된 브랜치에만 코밋이 반영이 된다. 이렇게 되면 현재 main 브랜치는 변경이 된 내용을 모르는 상태이다 여기서 한번 더 커밋을 해보자 그림으로 표현하자면 이렇게 된 상황이다. 브랜치를 이제는 삭제를 해보자. 브랜치를 삭제한다는 것은 그 동안 브랜치에 했던 작업 내역 즉, commit이 모두가 사라진다는 의미이다. 브랜치를 삭제하면 기본 브랜치인 main 브랜츠로 체크아웃 즉, 작업 브랜치가 ..
나는 깃에대해 두려움이 있었다. git은 어떻게 공부 해야할지 정말 막막하였다. 개발자가 되기 위해선 협업이 기본이고 협업의 기본은 곧 git을 다룰 줄 알아야 하기에 언젠간 꼭 해야했던 것인데 이번에 git의 산을 넘으면 자신감이 생길 것 같아 공부를 하였다. 유튜브에서 생활코딩님의 영상을 참고할 때가 많았다. 초심자의 입장에서 궁금할만한 것들을 놓치지 않고 꼼꼼히 집어주고 가기때문에 공부하기 수월하였다. 이 책을 바탕으로 깃 포스트를 진행하였다. 유명 인강사이트에서 git강의를 보고도 잘 이해가 가지 않았던 것을 이 책을 통해 공부하면서 깃에 ㄱ자는 알게 되었으니 나처럼 1도 모르는 사람들에게 이 책을 강력 추천한다. 심지어 52개의 유튜브 강의가 제공됨에도 불구하고 이해가 안되면 그때 봐야지 ~ 생..