2023.05.18 79일차 Git

79일차

어떻게 협업할 수 있는지?
버전관리 툴 깃 을 사용
나혼자할게 아니라 여러사람과 하고싶다.
여러사람의 버전관리를 중계해주는 github를 배우고 있다.

gitlab bitbucket등등도 있다.

git이 관리하는 프로젝트 폴더가 온라인에 있는 것뿐이다.
그것을 따로따로하는 분산형 버전관리 시스템이다.

6.4 github 연습

팀장과 팀원

팀장 :
새로 리포지터리생성
프로젝트 폴더만들고 git init
아무파일이나 생성하고 커밋하기
이 히스토리를 온라인으로 깃허브에 반영

온라인이 어디인지 로컬 깃에게 알려줘야한다.
origin이라는 별칭으로 주소에 넣는 것이다.

git remote add origin 주소.git

다음 명령어로 fetch위치와 push위치를 알 수 있다.

git remote -v
origin  https://github.com/ChunPingE/collabo2.git (fetch)
origin  https://github.com/ChunPingE/collabo2.git (push)

여기에 푸쉬를 해야한다.
다음명령어를 입력하면 현재 브랜치와 현재 있는 commit을 알 수 있다.

git branch -vv

이 브랜치와 원격 브랜치가 짝을 맡고 있다는 것을 git에게알려줘야한다.
push하면된다. 그냥하면 짝을 맞춰달라해서 다음과 같이 입력해야한다.
git이 origin과 master를 연동해달라 요구하기

git push -u origin master

branch 'master' set up to track 'origin/master'라고 나온다.
새 branch를 올릴땐 추적하도록 이걸 해줘야한다.

협업하기로 햇으면 협업하려는 상대를 초대해야한다.

Setting - Collaborators - add people id,이메일,유저이름 등으로 초대가능

처음에는 awaiting상태 수락누르면 Collaborator가 된다.

팀원 :
처음은 awaiting상태 수락누르면 Collaborator가 된다.
git bash키고 clone

git clone .git링크코드

github -collabo2라는 리포지터리에
팀장 로컬 collabo2 팀원 로컬 collabo2로 주소를 알고 있는 것이다.

6.5 협업 - 2

팀장:
팀장도 팀원도 master에서 branch새로만들어서 일해야한다.
브랜치명도 push되면서 섞인다. 그래서 자기이름/브랜치명으로 지어준다.
브랜치명도 특별히 하는 일을 나타내주면 좋다.

기능이 끝나면 git에 push하면되는데
다른사람이 이미 작업해서 master가 옮겨갓을 수도 있다.
push하기전에 master로 옮겨서 업데이트 되었는지 확인해야한다.

Switched to branch 'master'
Your branch is up to date with 'origin/master'.

이것만 보고 다시 일하던 브랜치로 가서 push하면된다.
github의 어떤 것을 추적할지 모르니 -u origin해줘야한다.

git push -u origin branch이름

로컬에서하면 fast foward해서 conplict날일이 없지만
여기선 날수도 있다.
확인하고 confirm merge

git fetch

깃허브의 내용을 가져오고
github에서 날린 commit인 origin/master와 이 로컬의 master를 merge하기

로컬의 필요없는 branch와 삭제한 origin branch삭제(가지치기)

git branch -d branch이름
git fetch origin --prune
git fetch -p(패치와 가지치기한번에)

팀원
일하기전 통합 branch의 변경사항을 받아야한다.

git fetch

변경사항이 있다면 pull하라고 한다. pull은 git fetch와 git merge를 한번에 한것이다.

git pull

팀원은 여기서 branch를따서 일을 하면된다.

바로올리면 안되고 git fetch로 master가 항상변경되었는지 확인하고
origin/master와 master가 같은것을 가리키고 있는지 확인 후 push해야한다.

팀장
github에서 팀원이 올린 pull request 확인하고 commit확정해줘야한다.
-> 통합 branch만드는 것이니 같이 모여서 하자.

이렇게 아름답게 끝나는 경우도 있고 아름답지 않은 경우도 있다.

연습
팀장 본인 github에 collabo3 만들고 로컬에 collabo3에 git init
로컬에 있는것 -> 리모트 remotes add, push
팀원초대

master에서 fetch merge(pull)
master에서 브랜치 따서 작업
작업 완료 후
branch push
pull request 생성 github에서 merge

팀원 초대수락 remote의 collabo3 clone

master에서 fetch merge(pull)
master에서 브랜치 따서 작업
작업 완료 후
branch push
pull request 생성 github에서 merge

6.6 협업 -3

이런 일들이 나눠서 일어나면 좋겠지만 동시에 일어나는 일이다.
master에서 master가 최신버전인지 확인하고 fetch, pull
브랜치 따서 작업 따로 진행
작업 완료 후

내가 작업 중에 누군가 pull request날렷을수도잇으니 확인해야한다.
master에서 fetch , merge(pull)하기
내가 작업하는 feat1에 master통합
내가 작업하는 중에 나한테 반영을 해야한다.
CONFLICT나면 난리나게 될것이다.

원래대로라면 회사라면 CONFLICT해소를 본인이 하고 PUSH해서 github에 CONFLICT없게 해야한다.

그냥 github에 push를해라 그래서 팀원이랑 팀장이랑 같이 봐라
그리고 여럿이서 머리 맞대고 뭐가 맞는건지 설정해라
그런데 여기선 코드 수정 오타 등등해결못하니 조심해서 하기

master에서 pull
master 브랜치 따서 작업
작업완료후 push
pull request생성

---

같이 모니터 git hub통합
같이 merge
branch 삭제

---

자리로 돌아와서
쓸모없는 branch들 삭제

7. 팁

자주쓰는 명령어들이 줄여쓰고 싶다. alias별칭을 줄수잇다.
다음은 status를 별명 st로 부르겠다는 것이다.

git config --global alias.st status

띄어쓰기가 있다면 ""안에 넣기

git config --global alias.la "log --oneline --graph --all"

삭제

git config --unset --global 키

복잡한 commit이 발생하는 경우가 있다.

commit을 이쁘게 줄이고 싶다.

rebase 눌러담는다.
현재위치에서 실행

git rebase -i master(목적지)

현재위치에서 목적지까지를 합체시킨다.

p pick 남기는것
e edit 커밋메시지 변경
s squash 눌러담기

7.1 커밋변경 amend

commit을 잘했는데 커밋 메시지를 잘못썻다.
마지막 커밋 메시지를 변경하고 싶을때 사용할 수 있다.

git commit --amend

근데 커밋 메시지만 변경할 건데 커밋번호도 같이 변경된다.
커밋 번호가 어떻게 작성이 되는지?
누가 했는지 + 언제 했는지 + 커밋 메시지는 뭔지 + 이전커밋이 뭔지(parrent)
이것들을 모아서 만든게 커밋번호이다.
그래서 커밋 메시지만 변경해도 커밋번호가 바뀌게 된다.

예전커밋을 지우거나 수정한게 아니라 새로운 커밋을 한것이다.
그래서 예전 커밋이 어디엔가 숨어있다.

지워진게 아니라 branch붙이고 이동할 수 있다.
조그마한 변경사항이 있더라도 커밋이 새롭게 된다. 그래서 주의해야한다.

로컬에서는 새로운걸 만들고 rebase하고 아무런 상관이없다.
작업이 다끝나서 git push를 한다고 해보자.

git push -u origin branch이름

공개가 된 커밋이다. 누구든지 내 commit을 사용 할 수 있다.
이 상황에서 잘못 했다고 로컬에서 변경해버리면 문제가 생긴다.
이걸 다시 push하려고하면 reject당한다.

메시지만 변경햇을뿐인데 새로운commit이 생긴거고 누군가가 이걸로 merge등의 업무를 햇을 수도있다.
결론은 공개된 commit은 수정하면 안된다. 여기서부터 다른일을 해야할 뿐이다.
물론 방법은 있는데 이것을 수습하는게 더 큰일이 될 수 있으니 하지말자.

7.2 git reset

잘못 커밋해서 되돌리고 싶다. 이전커밋으로 돌리는 것
git reset엔 세가지 옵션이 있다. soft / mixed / hard

hard는 3개의 영역 working dirc, index, object repository가 모두 적용된다.
커밋만 바뀌는게 아니라 staged, working도 달라져서 깨끗한 상태가된다.
파일도 없어진다.

git reset --hard HEAD~1

soft는 3개의 영역중 object repository만 변경된다.
staged는 건들지 않는다.
수정한 파일이 staged된(add된) 상태로 commit을 기다리고 있다.

git reset --soft HEAD~1

mixded는 3개의 영역중 staged까지 영향을 미친다.
working directory까지 돌아가서 수정된 상태로 돌아가게 된다.
아직 add하지 않은 상태가 되게 된다.
기본값이 mixed이기때문에 그냥 reset을 하면된다.

git reset HEAD~1

공개한 이후에는 절대로 reset하지 말아라!

7.3 다시 push

request하고 merge하기 직전에 잘못올린것 같다.
올라간 pull request를 reject하지말고 다시올리지말자.
여기서 작업을 더 할게 남았다면 추가로 작업하고 같은 branch로 push하면된다.
마지막으로 push한게 반영이 된다. 이것까지 반영된 merge를 기다리게 된다.

8.sourcetree

git bash에서 하는게 어렵다면 gui툴인 sourcetree을 사용하면된다.
github push할때 로그인하는 방법이 조금 다르다.

프로젝트 maven
만들때 jsp사용할거면 무조건 War로 해야한다
group 보통 회사도메인 거꾸로
artifatct 프로젝트명

메일보내는거 java mail sender?

lombok springweb security 등등 추가하기

.git ignore 파일 맨윗줄
src/main/resources/custom.properties 추가하기

crsf태그를 활성화하면 포스트 요청할때마다 토큰을 줘야해서 난이도가 오른다.
permitAll()해놧으니 로그인만들때 지우고 처리하면된다.