어떤 파일이 마지막 파일인지, 여러명이 하나의 앱을 개발할 때 수정한 코드를 어떻게 합칠 지,
협업툴의 기능을 가지고 있다고 생각한다.
1. 설치, 구동
먼저 깃허브에 가입한다.그리고 cmd를 연다.
우리는 강사님이 만들어둔 깃허브 파일이 있어서 그것을 가져오는 형식으로 실습을 진행했다.
우리 컴퓨터 cmd 기본 경로
맨 위 코드로 git_practice 폴더를 만들고 cd 로 그 안에 들어간다. 그리고 git clone [강사님이 지정해준 사이트] 를 입력하면 git_practice 폴더 안에 저 내용들을 그대로 가져온다.
1. 폴더 생성 - md git_2 2. 폴더 진입 - cd
3. 깃 가져오기 = git clone [사이트명] . (띄어쓰기 한개 이후 콤마) 나는 한번 실수해서 파일 경로가 git_2이다. 이름, 이메일 확인
이건 우리가 입력해줘야 한다. 그런데 문자열이기 때문에 맞지 않아도 상관없다, 그저 관리의 차원이기 때문에 이게 안 맞는다고 뭐 다른건 없다
이 이후 생성한 위치에 파일에 변경된 사항이 있는지, 그 파일을 저장해둘 것인지, 그 파일을 로컬 저장소에 올릴건지 이 세가지 행동들을 수행한다.
1. 파일이 변경, 수정, 추가된 사항 확인 -먼저 경로상에 txt파일 아무거나 만들어준다. 그리고 git status 명령어를 입력하면
이렇게 경로상에서 변경되고, 추가된 파일 이름이 빨간색으로 나온다. 파일 이름은 그냥 정한거다.
2. 파일을 추가할것인가? git add . 명령어를 사용하면 파일을 추가하게 된다. 변경된 파일이 있으면 그 파일들을 스테이징 영역으로 모아둔다. 이는 commit 하기전에 잠시 모아두는 임시공간이다.
같은 파일이 초록색으로 나온다. 이게 스테이지 영역으로 들어간것이다.
3. 로컬 저장소에 저장 git commit -m "[주석, 새로 추가한 데이터의 변경 내용 등을 여기에 적는다]"
git commit 을 통해서 파일을 저장소에 확실하게 변경된 사항을 올렸다. 이제 git status를 해보면 변경된 파일 등이 아무것도 없는것을 볼 수 있다. 현재 파일 상태가 최신화된것이다.
git push origin main 이것이 서버에 이 내용을 업로드하는거다. 이를 서버상으로 하면 모두가 변경된 사항, 파일을 볼 수 있고 그런것을 공유하는게 깃의 목적이다.
gitreadme.txt가 생겼다
2. 기능 단위 branch 생성
branch는 쉽게 말해서 나뭇가지라고 생각하면 된다. 추후 기술하겠다.
cmd에서 git branch [브랜치명] 을 해주면 브랜치가 생성된다.
git branch 로 현재 branch를 확인 할 수 있고 뒤에 브랜치명을 붙이면 그 브랜치가 생성이 된다.
git checkout [브랜치명]으로 현재 브랜치를 전환한다.
브랜치는 가지, 평행세계 같은거다. 개발을 여러사람이 한다면 누구는 a기능, 누구는 b기능을 개발할 것이다. 마스터 앱 개발 메인 파일이 있고, 이것을 베이스로 다른 기능을 개발해서 덧붙여야 한다면 그 때 a 기능 개발하는 사람이 branch밑에서 개발하고, 그 개발한 내용을 마스터와 합치는게 merge이다.
git push origin [branch명] 이게 제일 중요한 개념인데 origin과 branch만 알면 된다. 우리는 로컬에서 개발을 하고 있다, 예를 들어 우리의 노트북, 컴퓨터 등등 모두가 메인이 되는 웹에 올라간 파일로 개발하면 문제가 무조건 생길거 아니냐 이 메인이 되는 파일이 origin에 웹서버에 있는거다. 그리고 우리가 branch로 가지를 타고 origin에서 나가서 로컬에서 개발을 하는거다. 그리고 그 기능이 개발이 완성이 되면 origin에 merge 하는것이다.
merge의 설명
비슷한 기능이지만 merge는 통으로 합쳐버리는거다, 예를 들어 3가지 기능을 개발했는데 두번째 기능만 가져오고 나머지는 필요 없을수도 있다, 이 때 사용하는것이 cherry pick이다.
필요한 기능만 가져옴으로써 오류를 최소화할 수 있다.
conflict
충돌은 파일을 합치다 보니 main 파일 기준으로 a와 b 파일을 동시에 합친다 가정하면 a와 b 값이 다른점이 있을것이다. 이 때 main은 어떤걸 합쳐야 할 지 모르니 오류가 나고 이게 conflict이다. 이는 merge, 혹은 cherrypick을 중단하는 명령어 abort로 다시 뒤로 돌아가서 수정하면 되니 큰 문제는 아니라고 한다. 저 사진은 참고하라고 보여주셨는데 아직 무슨소린지 잘 모르겠다.
rebase, squash
작업 시에 conflict를 줄이기 위한 기법이 바로 rebase이다.
내가 어떠한 부분에서 브랜치를 꺼내서 작업하고 있는데, 이후 붙이려는 과정에서 master가 수정되었을수도 있잖아?
그러면 내가 작업한 브랜치의 master부분을 최신화 한 이후에 작업을 merge, 혹은 cherry pick 하는거다.
이 명령어가 rebase이다. 내가 작업한 branch = Feature 브랜치
reset, revert
실수로 올린 커밋을 되돌리고 싶을때 사용하는 명령어다,
reset. 내가 작업하던 브랜치의 뒤로 돌아가는것이고
revert. a, b, c 의 feature를 만들었는데 이중에 오류가 있다면 하나씩 revert 해보며 오류가 어디서 났는지 등을 체크하는 기능이다 예를 들면 b의 기능을 반대로 하는 b? 들었는데 잘 이해가 안된다
아무튼 5명이 개발했을 때 각자 개발한거 하나씩 꺼보는거라고 하셨
