반응형

push하기 전 commit 수정하기

 

push 하기전에 commit을 잘못한 경우라면 아래 명령어를 통해 수정할 수 있다.

git commit --amend

 해당 명령어를 입력하면 최근에 입력했던 commit 메시지가 출력되고 에디터 수정 모드를 통해 변경하면 된다.

 

 

commit후 push까지 해버린 경우 수정하기

이미 push까지 해버린 경우라면 조금 위험할 수 있지만 아래와 같이 처리할 수 있다.

 

1. 수정할 커밋 정보 찾기

먼저 rebase를 통해 몇번째 커밋을 수정할 것인지 입력한다.

git rebase HEAD~1 -i

 제일 최근의 push한 커밋 메시지를 수정한다면 HEAD~1이고 2번째라면 ~2, 3, 4 차례대로 숫자가 올라가면 된다.

rebase로 수정할 커밋의 번호를 입력한다.

 

2. pick 텍스트를 reword로 변경하고 저장하기

reabse를 실행하면 아래와 같은 출력창이 발생하는데, pickreword로 수정(i로 입력모드)하고 저장(wq!)해준다.

노란색부분은 커밋의 첫번째 줄이 보인다.
pick을 reword로 변경하고 저장한다!

빨간색으로 처리한 pick부분만 reword로 변경하고 저장하면 아래와 같이 새로 입력할 수 있는 창이 나온다.

 

 

3. 커밋 메시지가 나오면 수정하기

이런식으로 최근에 입력한 전체 커밋 메시지가 보이는데, 여기서 잘 못 입력한 부분을 수정(i로 입력모드에 들어간다.)하고 저장(wq!)한다.

 

4. push --force처리로 덮어쓰기

다음 아래 명령어로 다시 push처리를 하면 수정된 commit message로 반영된다.

git push --force

 

5. 결과

추가된 메시지가 잘보인다. 

반응형
반응형

Git은 협업도구이지만 주로 프로젝트를 혼자하다보니 협업에 어울리게 제대로 사용하지 못하고 있다는걸 알게되었다.

열심히 commit을 해주고 있었지만, 스스로가 나중에 찾아보더라도 각각 올려진 메시지의 내용을 파악하기 힘들다는 문제점도 자각하게 되고 해당 방식을 고치고자 찾아보니 커밋컨벤션이라는 방식이 있었다.

 

메시지의 구조

제목(title)
\n(개행)
본문(body) > 생략가능
\n(개행)
꼬리말(footer) > 생략가능

위의 형태의 구조로 사용한다.

 

 

커밋의 종류

Type Description Example
chore 기타 작업 chore: 빌드시 자동 설정 옵션 추가
design css 관련 UI 디자인 작업 design: 회원가입 양식 디자인 추가
docs
주석 작업, 문서 추가 관련 docs: 검증 api 관련 docs추가
feat 새로운 기능을 추가 feat: 회원 가입 기능 추가
fix  버그 수정 fix: 비밀번호 유효성 검사 오류 수정
refactor 프로덕트 리팩토링 refactor: userJoin 메소드를 유효성부분과 분기처리
remove 디렉토리, 파일을 삭제하는 경우 remove: 유효성 test모듈 삭제
rename 디렉토리, 파일명만 수정, 경로 변경 등 rename: Join디렉토리에 관련 소스 정리
test 테스트 관련 작업 test: 회원가입 테스트 추가

 

 

작성 규칙

타입 종류들과 성격을 파악했으니 사용법을 알아보겠습니다.

  • 제목은 50자 이내로 작성
  • 본문은 한 줄당 72자 이내로 작성
  • 제목과 본문 사이는 개행 한줄을 넣어서 분리
  • 문장에 끝에 마침표(.)를 사용하지 않음
  • 문장은 명사로 끝냄

 

 

작성 팁

제목

  • 간결하고 요약하여 작성한다.
  • 마침표나 특수기호는 사용하지 않는다.
  • 과거시제를 사용하지 않는다.

 

본문

  • 최대한 상세하게 작성한다.
  • 본문 작성시 변경 내용에 대한 것보단 왜 변경되었는지, 무엇을 바꾸었는지 초첨을 둔다.

 

 

Github 적용 예시

처음 적용하다보니 개행 실수가 있어서 git commit --amend로 내용을 수정해주었다.

상세 내용을 펼치기전에는 제목만 보이며 상세 내용을 펼치면 body부분이 보인다.

(캡처에도 개행하나가 제대로 안들어가있네요... 적응하도록 노력해야겠습니다.) 

반응형
반응형

최근 프론트엔드로 전향하기 위해 리액트를 학습하기로 마음을 먹었습니다.

노마드 코더 영상을 보면서 기초부터 나중에 유료버전도 결제하면서 추가 학습을 할 예정인데, 이런 내용들을 정리하고 공부하는 흔적을 남기고 싶어서 티스토리 블로그도 좋지만 깃허브에 잔디심기를 해보는것으로 마음먹었습니다.

 

기존 회사에서도 깃을 사용해왔기에 깃허브정도는 어렵지 않게 사용할 수 있고, 깃 명령어나 사용법도 잊지 않기에 괜찮다고 생각이 들어서 어제부터 저장소를 생성하고 학습한 내용을 하나씩 올리고 오늘도 추가로 학습한 내용을 올리고 있는데, 잔디심기가 되지 않고 있었습니다.

 

확인해보니 깃허브의 메일주소와 로컬의 메일주소가 달라서 발생하는 현상이라고 합니다.

예전에 로컬에는 간단하게 깃 테스트정보로 마구 입력을 해둔값이라 전혀 유효한 값이 아닌 메일 값이 있었고,

git bash에서 아래 명령어를 입력하여 수정하였습니다.

git config user.email "이메일 주소"

 

변경된 이메일 주소는 아래 명령어로 확인 가능합니다.

git config --list

 

이제 귀염뽀짝한 2일차 잔디심기 현황입니다...

앞으로도 열심히 달려봐야겠습니다.

 

반응형
반응형

branch 정보를 보기 위해 git branch입력을 해보면 로컬 저장소에 등록된 브랜치 리스트만 출력이 됩니다.

 

원격저장소에서 데이터를 가져오는 방법을 알아보겠습니다.

 

원격저장소에서 브랜치 정보 가져오기

원격 저장소 업데이트

먼저 원격 저장소를 업데이트를 해줍니다.

git remote update

새로운 저장소 정보를 가져왔다!

 

 

원격 저장소의 브랜치 정보 확인하기

다음으로 브랜치 정보를 확인합니다.

-r 옵션은 저장소의 브랜치 리스트만 -a옵션은 모든 브랜치 리스트를 확인합니다.(로컬 + 원격)

git branch -a  //원격 + 로컬
git branch -r  //원격

원격 저장소의 브랜치 정보들

 

 

원격 저장소에서 브랜치 가져오기

-t 옵션과 checkout을 사용하여 브랜치를 가져옵니다.

git checkout -t [브랜치명]

git checkout -t [원격 저장소 브랜치명]
//ex
git checkout -t origin/rts_list

반응형
반응형

과거 svn을 사용할때, 소스가 꼬였거나 잘 못된 개발로 되돌아가야할 일이 생길 경우 리비전을 통해 되돌아가고 재작업을 진행하고 그랬는데, git에서는 리비전이라는 용어대신 특정 commit으로 되돌아 가는 방식을 사용해야 했습니다.

 

 

이러한 형태로 git작업이 되어있다고 칩시다...

너무 복잡한 예시는 오히려 이해하는데 방해가 될 것 같아서 최대한 간단하게 해보려고 합니다.

index.js추가 ~ cal메소드 추가부분을 봐주시면 됩니다.

 

fork를 사용 중이라면 되돌아가고자 하는 commit부분에 오른쪽 클릭 후 checkout commit 을 해주면 간단하게 되돌아갑니다.

역시 gui가 한 눈에 잘보이고 편합니다...

이 후 브랜치를 새로 생성하고 소스를 수정한다음 merge까지 진행하면 새롭게 변경할 수 있습니다.

fork사용자는 이렇게 편하지만 git bash를 쓰고 있는분들을 위해 명령어와 함께 설명을 추가해보겠습니다.

 

git bash에서 과거 commit으로 회귀하기

git log

git log

commit된 히스토리들을 봐야 되돌아가고 할텐데 이때 사용하는 명령어는 "git log"입니다.

-p옵션을 사용하면 어떤부분이 바뀌면서 올라갔는지 나오고 추가적으로 -2 와 같은 명령어를 입력하면 최근 2개만 출력해서 보여줍니다.

 

git log -p -2

git log

 

명령어를 입력해보면 노란글씨의 commit 부분이 보일텐데 앞 6자리를 기준으로 확인해주면 알아서 식별을 해줍니다.

git에 등록한 각각 commit의 고유번호들로 이 값을 통해 돌아갈 수 있습니다.

되돌아갈땐 브랜치를 바꿀 때 사용하였던 checkout 명령어를 사용합니다.

 

과거 commit으로 돌아가기

git checkout <commit번호>

"git checkout 0cd1df"를 입력해보겠습니다.

과거 commit으로 이동

 

 

되돌아오기

그럼 다시 원래대로 돌아올수도 있어야겠죠?

마지막 commit된 곳으로 해도되지만 마지막 브랜치인 master로 이동하겠습니다.

 

git checkout master

master로 되돌아오기

 

과거로 commit후 새롭게 브랜치 생성하기

cal()메소드가 존재하지 않던 과거로 돌아가고 거기서 브랜치를 만들어서 master를 진행해보겠습니다.

방금 전 과거 commit으로 돌아갔으니 거기서 소스 수정하고 다시 commit하면 되는게 아닐까 생각하시겠지만 그부분에서 commit을하고 push를 해도 브랜치를 만들어서 진행한게 아니기때문에 적용이 되질 않습니다.

 

 

git log

//돌아갈 commit 고유값 앞 6자리를 기억합니다.

git checkout 4385268

git log를 통해 commit 고유값을 알아낸 후 다시 과거로 돌아갑니다.

이제 브랜치를 새로 생성해줍니다.

 

 

git branch new_psw

과거로 돌아간 후 new_psw브랜치 생성

되돌아가서 브랜치까지 생성을 성공하셨다면 checkout을 통해 꼭 브랜치를 변경하시고 수정할 소스를 바꾸신 후 다시 commit을 처리해줍니다.

이제 브랜치가 생겼기때문에 commit을해도 정상적으로 처리가 됩니다.

 

 

new_psw브랜치로 새로운 소스 올리기

git checkout new_psw //새로 생성한 브랜치로 바꾼다.

git add . //변경된 소스를 올린다.

git commit -m "min메소드 추가" //commit처리

git push origin new_psw //서버에 new_psw브랜치로 올리기

새로운 브랜치를 따서 작업을 완료했으니 변경된 브랜치로 checkout을 하시고 변경된 소스를 올린 후

commit을 해줍니다.

new_psw브랜치에서 소스 올리기

 

push를 통해 서버까지 올리면 이제 master브랜치로 병합처리를 해보겠습니다.

 

 

master브랜치 병합하기

git checkout master

master브랜치로 변경합니다.

 

 

git merge new_psw

master브랜치로 바꿔놓은상태에서 new_psw브랜치를 병합합니다.

master브랜치로 병합하기 충돌발생!

merge failed라는 말과 할께 충돌이 났다는 메시지가 나옵니다.

충돌난 소스를 수정하겠습니다.

 

 

git 충돌!

충돌이 났고 필요없는 cal메소드는 삭제하였습니다.

 

충돌난 부분 수정

 

이제 완벽하게 merge를 끝내기 위해 다시 소스를 올립니다.

 

 

git add .

git commit -m "merge 완료"

git push origin master

merge를 위해 commit을 진행합니다.

 

 

 

정상적으로 merge까지 끝났다.

생각보다 복잡하다면 복잡하지만 branch과정을 한번 해보셨다면 그렇게 어렵지 않을겁니다.

이부분이 어려우신분은 branch부터 간단하게 예제를 한번 해보시면 쉽게 이해가 가능할 것 같습니다.

 

 

fork에서 확인하니 더 잘보입니다.

 

여기서 한단계 더 나아가면 더이상 사용하지 않는 new_psw브랜치까지 삭제해주시면 좋을 것 같습니다.

 

반응형
반응형

최근 git을 사용하면서 추가버전을 롤백하게 되어 과거버전으로 돌아가야 할 일이 생겼습니다.

기존에 사용하던 svn은 여러가지 기능 중 히스토리를 확인하여 날짜를 선택하고 손쉽게 과거로 돌아가 그때부터 다시 commit을 치고 update를하면서 사용 할 수 있었지만 지금 사용하는 git은 그런방법으로 처리하는게 쉽지 않았고 처리 방법으론 과거 commit을 찾아서 해당 commit영역을 checkout 한 후 branch를 새롭게 만들어서 사용하는 방법을 채택하여 사용중에 있습니다.

 

이 과정을 겪으면서 branch에 대해 알아볼 필요성이 생겼고, 간단하게 branch의 사용법을 확인 후 처리했던 방법을 포스팅 해보고자 합니다.

 

GIT - branch

branch만들기

git branch <name>

"git branch 브랜치명"를 통해 브랜치 생성할 수 있습니다.

브랜치 생성

 

 

branch 목록 확인하기

git branch

"git branch"를 통해 브랜치 리스트를 확인 할 수 있습니다.

브랜치 목록 확인

 

 

사용하는 branch 변경하기

git checkout <branch>

"git checkout 브랜치명"을 통해 사용할 브랜치를 바꿀 수 있습니다.

브랜치 변경

 

 

새 브랜치에 소스 올리기

브랜치를 새로 만들어서 변경까지 했다는건 이 부분부터 새로운 소스로 개발을 진행하겠다는 뜻이겠죠?

여기서 소스를 약간 수정하고 add 후 commit을 해서 push까지 진행해보겠습니다.

 

저는 index.html만 약간의 수정을 했습니다.

index.html수정

 

아래 명령을 통해 전부 add해주시고 commit 메시지를 남깁니다.

git add .
git commit -m "브랜치 변경"

소스를 수정 후 commit

push도 진행합니다.

git push origin psw

이번엔 변경된 브랜치명인 psw로 올립니다. (master -> psw)

전 저장소를 연결할 때, origin으로 만들었습니다.

git서버에 push

정상적으로 변경된 branch로 올라간 모습을 확인 할 수 있습니다.

 

 

fork툴을 활용한 git 처리 확인

fork라는 툴을 활용해서 git을 사용하고 있는데 아무래도 gui를 제공하다보니 commit 메시지도 보기 좋고 현재의 브랜치상태나 올린사람등을 쉽게 파악할 수 있어 애용하고 있는 프로그램입니다.

 

이렇게 새로운 브랜치를 만들어서 추가된 것을 볼 수 있습니다.

 

 

브랜치 병합하기(merge)

git merge <commit>

병합을 할 땐, "git merge 브랜치명"의 명령어를 통해 merge합니다.

 

 

git checkout master

지금까지 따라오셨다면 commit의 헤드는 psw에 처리되어 있을텐데, 다시 master로 변경해보겠습니다.

 

 

git merge psw

아까 branch를 변경할땐 checkout이라고 했었죠? master로 브랜치를 바꿨으면 합병을 해보겠습니다.

합병 명령어를 입력합니다.

 

 

그러면 아까 psw에서 처리했던 commit이 합병되는 것을 볼 수 있습니다.

비어있던 index.html

위 캡처처럼 master브랜치의 index.html은 비어있었는데, merge를 하자 아래처럼 바뀌어있습니다.

master 브랜치로 합병

 

master 브랜치로 psw 브랜치에서 처리했던 소스가 합병된 모습을 볼 수 있습니다.

 

 

브랜치 삭제하기

psw의 소스는 합병도 되었고 더이상 쓸모가 없어졌을 경우 브랜치를 지워줘야겠죠?

엄청 많은 브랜치들이 존재하면 어떤건 개발이 끝난거고 어떤건 쓰는건지 구분이 안될 수 있을 것 같습니다.

git branch -d <name>

"git branch -d 브랜치명"을 통해서 브랜치를 삭제 할 수 있습니다.

psw를 삭제해보겠습니다.

 

 

git branch -d psw

psw브랜치 삭제

psw브랜치가 삭제되었습니다. 삭제가 되었는지 브랜치 리스트 확인 명령어를 통해 확인해보겠습니다.

 

 

git branch

master만 남아있다.

잘 삭제되어서 master만 남아있는 모습입니다.

 

 

gui툴인 fork에선 아래처럼 변화가 있습니다.

 

브랜치를 삭제하기 전 mster, psw가 같이 붙어있다.

 

합병으로 인해 브랜치가 지저분하게 붙어있습니다. 삭제 후에는 아래처럼 바뀝니다.

master브랜치만 남아있다.

 

 

여러개의 브랜치 사용하기

여러개의 브랜치 생성하기

psw1, 2를 만들어서 작업하는 상황을 만들어보겠습니다.

git branch psw1
git branch psw2


git checkout psw1

psw1, 2를 만들고 psw1의 브랜치를 사용하도록 하였습니다.

현재 브랜치 리스트

 

 

index2.html 추가

html을 추가하였고, 내부에 간단하게 소스를 작성하였습니다.

이제 서버에 올려보겠습니다.

 

git add .

git commit -m "index2.html 추가"

git push origin psw1

psw1브랜치에서 index2,html 생성 후 commit

psw1브랜치에서 파일을 생성하였고 commit까지 정상적으로 처리하였습니다.

 

psw2브랜치 사용하기

이제 psw2브랜치로 변경해보겠습니다.

git checkout psw2

index2.html이 사라졌다.

브랜치가 변경되었고 생성하였던 index2.html은 사라졌을겁니다. 동일하게 생성해서 psw1브랜치에서 생성했던 소스와 다르게 작성해보세요.

 

파일을 생성하고 소스를 다르게 작성하였다면, 서버에 동일하게 commit을 하겠습니다.

git add .

git commit -m "psw2 branch - index2.html 추가"

git push origin psw2

psw2브랜치에서 commit

 

여기까지 상황을 만들었으니 이제 master에 병합처리를 해보겠습니다.

 

 

여러개의 브랜치 병합과 충돌 발생 해결하기

master브랜치로 checkout합니다.

git checkout master

master 브랜치로 checkout

브랜치를 변경하였으니, 앞에서 배운 merge명령어를 통해 병합해보겠습니다.

 

 

git merge psw1

merge명령어를 통해 합병합니다. psw1의 브랜치부터 했습니다.

psw1브랜치 병합

바로 이어서 psw2브랜치도 병합해보겠습니다.

 

 

git merge psw2

psw2브랜치까지 병합

병합을 하고나면 index2.html이 정상적이지 않은 데이터로 병합된 걸 볼 수 있습니다.

 

충돌이 발생하였다!

바로 충돌이 발생하였기 때문입니다. psw1에서 합병할때는 문제없이 merge 되었을텐데, psw2의 브랜치를 병합하면서 먼저 받았던 index2.html의 소스부분이 서로 꼬였기 때문입니다.

<<<<<<<HEAD부분은 기존의 마스터가 가지고 있던 소스부분이고

=======기준부터

>>>>>>>psw2까지는 psw2의 브랜치를 받으면서 충돌이 발생한 부분입니다.

 

 

지금은 소스가 매우 간단하고 충돌난 부분이 해당 부분밖에 없어서 간단하게 해결이 가능하지만

여러부분이 충돌이 났을 경우엔 모든 충돌 위치를 찾아서 병합할 부분을 고쳐주셔야 합니다.

 

원하는 소스로 병합처리를 하고 소스를 다시 올려보도록 하겠습니다.

소스 병합처리 완료

 

 

git add .

git commit -m "merge end"

git push origin master

merge 종료

정상적으로 처리가 끝났습니다.

 

fork에서 작업내역 확인

gui툴인 fork에서 확인해보면 좀 더 한눈에 작업내역이 보입니다.

psw1브랜치에서 index2.html을 생성하여 소스를 작성하고 올렸고

psw2브랜체에서도 동일하게 생성 후 소스를 올렸으며, master가 병합처리를 끝낸 히스토리를 컴밋 메시지를 통해 볼 수 있습니다.

반응형
반응형

요즘 svn이 아닌 git을 사용하고 있는데 egov에서 정상적으로 연동이 되질 않아 git bash를 통해 파일들을 받고 올리고 하면서 사용중에 있는데 스프링 구조의 target파일과 .springBeans, maven파일등이 올라가면서 꼬이는 현상이 발생하였습니다.

git으로 add ~ commit ~ push까지 진행하면서 이러한 일때문에 제외하고 올리고 싶은 파일들이 있을텐데 제외하는 방법을 알아보겠습니다.

 

.git디렉토리가 존재하는 같은 위치 최상단에 .gitignore라는 파일을 생성하고 데이터를 입력해시면 간단하게 해결됩니다.

 

파일을 생성하면 아무 에디터든 열어서 올리지 않을 확장자 또는 디렉토리등을 입력합니다.

 

저는 target, META-INF 디렉토리와 .springBeans 확장자의 파일은 올라가지 않도록 설정하였습니다.

target/*
META-INF/*
.springBeans

* 까지 처리해줘야 하위 생성하는 모든 것들을 무시합니다.

 

 

위 와같이 입력 후 저장하고 에디터를 종료합니다.

 

이후 git bash를 열고 push를 진행해주셔야 적용이 됩니다.

 

그전에 캐시를 키우고 올리도록 하겠습니다.

 

git rm -r --cached . //캐시 삭제
git add . //모든 파일을 적용
git commit -m "적용하는 메시지" //commit 처리

 

이후에는 프로젝트의 설정한 파일들이나 디렉토리 하위의 파일들이 바뀌어도 git status를 입력시 제외처리되어 인식하지 않는 것을 확인 할 수 있습니다.

 


*.extension   // 확장자로 시작하는 파일 제외

dirName/      //디렉토리 하위의 모든 파일은 제외
반응형
반응형

깃 저장소 등 디렉토리 위치를 변경할때는 cd 명령어

cd 저장소로 사용할 위치

 

해당 위치를 로컬저장소로 지정

git init

 

 

해당 위치 로컬저장소를 삭제

rm -r .git

 

 


해당 저장소의 상태를 확인

git status

 

 


저장소에 저장하기

git add 파일명.확장자

 

추가후 상태값 확인시 new File 추가된걸 볼 수 있다.

 

 

해당 디렉토리의 모든 파일 추가하기

git add .

 

 


저장 완료하기

git commit

 

완료 하면서 메시지 남기기

git commit -m "커밋 메시지"

 

 

 


외부 저장소에 연결하기

git remote add [외부저장소명] [연결정보]

//http, https의 경우
git remote add origin https://github.com/myhappyman/gitTests

//ssh의 경우
git remote add origin ssh://접속계정@ip정보:포트/디렉토리

 

 

외부 저장소 확인하기

git remote -v

 

 

외부 저장소에 프로젝트, 파일 올리기

git push [외부 저장소명] master

 

 

외부 저장소 삭제하기

git remote rm [저장소명]

git remote rm origin //origin저장소 삭제

 

 

 


외부 저장소에서 push, pull 동작을 하기 위한 준비

mkdir /git 디렉토리 파일 생성

1. 디렉토리를 먼저 만들어준다.

 

외부 저장소에서 push, pull 동작을 하기 위한 준비

2. 외부저장소 디렉토리를 bare 공유 외부저장소를 지정 및 만들어준다.

git init --bare [생성한 디렉토리]

//ex
git init --bare /git/example.git

 

 

외부 저장소에서 프로젝트, 파일 받기 - ssh접속 다운로드

git clone ssh://계정@연결IP:ssh접속포트/디렉토리/프로젝트명

 

 

 

 


외부 저장소에서 데이터 업데이트 받기

git pull [저장소명]

git pull origin
반응형