Hello! Poko에 기획자 1명, 프론트엔드 1명과 협업을 하게 되어 생활 코딩 git 강의를 통해 실습한 내용을 정리한다.
- AWS lisgtsail에 docker로 서비스 배포하기
- 나는 현재 Product 서버와 Devlopment 서버 2개를 관리하고 있다.
- 기획자와 프론트엔드 개발자의 협업 전에는 혼자서 개발을 하니 Devlopment 서버는 없었고 프로젝트 소스 코드의 수정이 생기면 로컬에서 수정 후 git add commit push로 프로젝트의 버전을 관리했다.
- 하지만 기획자의 요구사항으로 Devlopment 서버를 생성한 상태
앞으로 프로젝트 소스 코드의 수정(기능추가, 오류수정, 디자인반영)을 주로 적용할 계획 - 이때 원격저정소-로컬-Product 서버-Development 서버 간의 Git 활용을 위해 학습 내용을 기록한다.
- 생활코딩 참고
Branch
같은 뿌리에서 나왔지만 서로 다른 수정이 이루어지고 있는 버젼들을 의미
Confilct
같은 파일인데 같은 부분을 수정했다면 git이 사용자에게 수동으로 수정을 요청한다.
-
각 브랜치의 서로 다른 파일이 존재하는 경우
- 자동으로 서로 다른 두 파일을 합쳐준다
-
같은 파일인데 서로 다른 부분이 수정된 경우
- 자동으로 하나의 파일로 생성한다.
Branch
기본 조작
(base) ui-seok/manual - (main) > git log
commit 1ecbb4b5fa00fcadfb287c7124fecbd6d92cdb82 (HEAD -> main)
Author: 김의석 <119546939+uiseokgeem@users.noreply.github.com>
Date: Mon Apr 8 15:33:10 2024 +0900
work1
(base) ui-seok/manual - (main) > git log -p
commit 1ecbb4b5fa00fcadfb287c7124fecbd6d92cdb82 (HEAD -> main)
Author: 김의석 <119546939+uiseokgeem@users.noreply.github.com>
Date: Mon Apr 8 15:33:10 2024 +0900
work1
diff --git a/context.txt b/context.txt
index 710415a..fa9850e 100644
--- a/context.txt
+++ b/context.txt
@@ -1,2 +1,3 @@
content 1
content 2
+content 3-
git log와 log -p의 사용
- git log 명령어는 현재 브랜치의 커밋 로그를 출력
-
git log --all --graph --oneline
- 생성되는 브랜치의 현황이 그래프와 함께 출력된다.
실습
- 브랜치 생성 : git branch [브랜치 이름]
- 브랜치 이동 : git checkout [이동할 브랜치 이름]
- 현재 head인 메인 브랜치에서 내용을 수정한 경우
- 현재 브랜치는 수정된 최신버젼(work 4)이 반영되고
- 나머지 브랜치들은 이전 버젼(work 3)이 반영됨을 확인.
- git checkout apple branch로 이동.
- 메인 브랜치를 제외한 나머지 브랜치치의 버젼은 work 3인 상태
- git checkout으로 변경된 head를 확인.
- work3 버젼으로 유지되고 있는 텍스트 파일 확인
- work4 버젼에서 수정 된 내용들이 확인되지 않는다.
- 다시 main 브랜치로 변경하고 nano로 텍스트 파일 확인
- main 브랜치의 버젼(work 4)이 반영된 텍스트 파일을 확인할 수 있다.
이전 버젼(work3)이 적용된 다른 브랜치에서 파일의 수정 및 추가
- apple 브랜치의 텍스트 파일 수정
- git satus로 브랜치 내의 수정사항 확인
- git commit 으로 apple work 4 버전 최신화
-
git log --all --graph --oneline으로 확인한 모든 브랜치의 커밋상태
- 최신 커밋은 apple 브랜치에서 수정한 apple work4가 반영 됨.
-
애플 브랜치와 메인 브랜치의 부모 브랜치인 work 3에서 그래프로 현재 브랜치의 수정상태를 확인할 수있다.
- 다른 브랜치에서도 동일하게 적용 후 그래프 상태
Merge
각 브랜치마다 커밋으로 버젼이 업데이트 되고 각 브랜치들의 부분들의 병합한 새로운 버전(merge commit)을 생성하는 것.
- base : 병합하려는 것에 공통의 조상
기본조작
git commit -am "work 2"- am 옵션은 git commit 명령어의 두 가지 옵션을 결합한 것입니다:
-a: 이 옵션은 "Staging Area"에 추가되지 않은 수정사항도 자동으로 모두 스테이징 영역에 추가하라는 것을 의미합니다. 이는 git add 명령어를 생략하고, 수정된 모든 파일을 한 번에 커밋하고자 할 때 사용됩니다.
-m "message": 이 옵션은 커밋 메시지를 지정하는 것입니다. 여기서 "message"는 커밋 메시지로 사용될 내용을 나타냅니다.
git commit --amend- 이미 작성된 커밋내용 수정
- vim 편집기
- i : 작성하기
- esc : 나가기
- :wq : w 저장 q 나가기
서로 다른 파일 병합
- 실습 브랜치에 있는 파일 현황
- 메인브랜치
- context.txt
- master.txt
- o2 브랜치
- context.txt
- o2.txt
- 메인브랜치
- 중요! 메인 브랜치에서 o2를 브랜치를 병합
- git merge [현재 브랜치(main)에 merge할 브랜치(o2)] 실행
- base는 work 1
- 결과
브랜치 o2에 있던 o2.txt가 메인브랜치에 병합됨
같은파일, 다른부분 병합
- 실습 브랜치에 있는 파일 현황
- 메인
- work.txt
- 부분 수정(master work 2)
- work.txt
- o2
- work.txt
- 부분수정(o2 work 2)
- work.txt
- 메인
- main 브랜치에 o2 브랜치를 병합!
- branch merge 후 work.txt의 내용을 cat으로 확인.
- 각각 브랜치에서 수정한 부분이 현재 커밋의 work.txt에 잘 반영되었다!
merge에서 conflict
???: 주인님 요기만 주인님이 알아서 처리해주세요. 호호호
- conflict를 무서워하지말자!
-
실습 브랜치에 있는 파일 현황
- 메인
- work.txt
- 같은 부분 수정(master work 2)
- work.txt
- o2
- work.txt
- 같은 부분 수정(o2 work 2)
- work.txt
- 메인
-
Conflict 발생
-
both modified : 양쪽 다 수정 되었다는 git의 친절한 안내문
-
coflict된 work.txt를 확인하자
- 구분자를 기준!
- HEAD의 내용을 사용할 경우 o2를 삭제
- o2의 내용을 사용할 경우 HEAD를 삭제
- 둘다 사용하는 경우의 수정
-
conflict 수정 후 git add - git status
-
수정된 work.txt
