'IT 지식/Git'에 해당되는 글 11건

IT 지식/Git

git ssh로 받은 프로젝트를 https 방식으로 변경하기.

회사에서 ssh 방식으로 git을 사용하고 있었으나 정책상 ssh가 막혀서 https로 전환해야 했다.


근데 사실 ssh로만 주로 사용했지 이를 바꿔서 진행해본적이 없어서 난감했다.(기존에 작업중이던거 어떻게 ...)


그래서 알아보던중 같은팀 개발자분이 힌트를 주셔서 그대로 해보니 해결되었다. ㅋㅋ


간단하게 정리해보자.


- 프로젝트 내에 .git의 config파일 열어서 수정

터미널을 이용하든 편집기를 이용해서 config파일을 열어본다.

그럼 밑줄 친 부분과 같이 ssh주소로 되어있는데 이를 repository의 https 주소로 바꿔주고 저장한다.


그리고 다시한번 git 명령어를 시도해보면 다음과 같이 계정 정보를 입력하라고 나오는데 이곳에는 해당 레포지토리가 있는 github이나 gitlab의 계정정보를 입력하면된다.


그럼 끝!

아주 간단하다.


IT 지식/Git

travis ci에서 "./gradlew assemble" failed 에러 수정

git에 연동해놓았던 travis ci에서 어느순간부터 계속 오류를 감지하였다.

그냥 귀찮아서 넘겼지만 보기싫어서 오류내용을 확인해봤다.

./gradlew assemble 오류는 gradlew 실행이 실패해서 발생하는 오류이다.

우선 locale에서 정상적으로 동작하는지 확인해보자.

1
./gradlew build
cs

오류가 발생한다. 왜그럴까.. 구글링 하다 보니 gradle wrapper가 실행될때 필요한 gradle-wrapper.jar 파일이 없어서 라고 한다. gradle-wrapper.jar 파일에 경우 gradle/wrapper 폴더에 들어있어야 하는데 없었다. 

그래서 gradle wrapper 명령어를 실행시켜서 생성해주었다.


그럼 다시 빌드해보자.

1
./gradlew build
cs


성공했다.

그럼 git에도 gradle/wrapper/gradle-wrapper.jar 파일을 올려보자.  

그런데 source tree에 변경된 리스트에 출력이 되질 않아서 명령어로 commit 하려는데 다음과 같은 문구가 나왔다.


확인해보니 .gitignore에 *.jar가 추가되어 있어서 안보이는 것 같다. 그래서 git repository에 올라가지 않아서 clone 받을 때 없었나보다.

그냥 -f 명령어를 넣어서 올려버렸다. 


흠 그래서 이번에 다시 travis ci 에서 재 빌드 하였는데 이런 오류가 떴다.

/home/travis/.travis/job_stages: line 266: ./gradlew: Permission denied

모지 권한오류라니.... 
또 구글링해서 알아보니 권한을 수정해줘야 한다는 것이다. 쩝
그래서 하라는대로 실행권한을 주었다. 그리고 확인하니 권한이 755로 올라갔다.



그리고 다시 빌드 시도

성공


참고

https://stackoverflow.com/questions/33820638/travis-yml-gradlew-permission-denied

IT 지식/Git

Git 저장소 Fork 후 Pull Request 및 최신 내용 갱신 방법

이전직장에서도 SVN을 사용했다. 물론 GtitLab을 1년반정도 사용했으나 아쉽게도 협업하여 진행하지를 않아서 모두 master에 직접 커밋을 하였다.

그래서 이번에는 협업한다고 생각하고 시나리오를 만들어서 테스트를 진행해보자.

Github 저장소에서 상대방 Repository를 Fork하고 Pull Request를 요청해보고 변경된 최신내용을 Local에 반영하는 작업을 진행해보자.

1. 우선 Repository를 Fork 한다.


fork를 진행할 계정을 선택하고 확인을 누르면 내 Repository에 Fork된 저장소가 보이는 것을 확인할 수 있다.


2. SourceTree에 추가

Git을 Command를 사용해서 멋지게 사용하면 좋지만 실력이 부족하기 때문에 SourceTree를 사용해서 진행해보자.
SourceTree에 방금 Fork 했던 저장소를 추가해보자.


3. 소스코드 변경

Clone을 받은 코드를 내가 원했던 내용대로 수정하고 커밋과 push를 진행한다.


작업을 완료한 후 내 저장소에 가보면 정상적으로 커밋과 푸시가 완료된것을 확인 할 수 있다.


4. 변경사항 Pull Request
지금까지 진행한 내용은 내 개인 Repository에만 반영되어있다. 실제로 원래 저장소에 가보면 원래 상태 그대로인것을 확인할 수 있다.

그럼 위에 그림에서 New pull request 버튼을 누르고 비교할 브랜치를 선택 해준다.

그러면 아래와 같이 변경사항과 함께 Pull request를 만들 수 있는 화면이 나온다

그럼 코멘트를 작성하고 Pull Request를 만들어보자.

요청이 완료되었고  이제 저장소의 원래 소유자가 요청을 받아주면 작업을 완료 할 수 있습니다.


5. Pull Request 수락.

원래 Repository의 주인인 dauns 계정으로 들어가 보면 Pull Request가 하나 있는것을 확인할 수 있다.
여기서 이 요청을 거절할 수도 있고, merge 할수도 있고 rebase 할수도 있다.

테스트이기 때문에 Merge 해보자.

Merge를 하고 나면 저장소에 내용이 변경되었고 Pull Request도 사라진것을 확인할 수 있다.

6. 원격 저장소 변경사항 Local에 반영

내가 fork를 진행한 원격 저장소 내용이 변경되어서 내가 fork를 진행한 저장소와 달라졌다고 가정해보자. 

위에 그림에 보면 tt.java라는 파일이 추가되었고 내 저장소에는 저 내용이 반영되어 있지 않다.

이를 반영하기 위해서는 먼저 원래 저장소를 upstream의 이름으로 원격저장소로 추가해줍니다.


그리고 추가된 upstream에서 우측클릭을 한 후  "upstream에서 가져와 병합하기"를 선택합니다.

그러면 원격저장소의 내용이 내 Local Repository에 반영이 되었습니다. 


이 내용을 commit & push 하여 내 원격 저장소에도 반영을 해주면 완료됩니다.

확실히 GIT이 더 어렵다. 

지금이야 간단하지 꼬이면 참 귀찮아질 것 같다. 사례를 많이 만들어봐서 연습해봐야겠다.

IT 지식/Git

Git Rebase 도중 한번 이상 충돌 해결 방법

Git에서 브랜치를 rebase 하는 도중에 충돌이 여러번 발생하였을때 해결하는 방법에 대해 알아보자.

먼저 기준이 되는 브랜치 master에 test.txt라는 파일을 만들고 내용을 작성하고 커밋을 진행하자.

 

그리고 리베이스를 진행할 브랜치인 conflict 브랜치에 test.txt를 생성하고 두번 커밋을 진행하자.

그리고 master에 리베이스를 진행하면 먼저 첫번째 충돌이 발생한다.

그러면 test.txt 파일을 수정하고 나서 스테이지에 다시 올리고 액션 메뉴에서 재배치 계속을 눌러 진행한다.

그러면 두번째 충돌이 발생하고 마찬가지로 해결 후 재배치 계속을 누르면 성공적으로 리베이스가 진행된것을 확인할 수 있다.

이렇게 두번의 충돌이 발생하는 이유는 아래의 그림을 살펴보면 알겠지만 변경이 델타 1, 델타 2 두번이 이루어져있고 이를 마스터에 적용을 진행을 하면서 여러번 같은 파일에 충돌을 해소해야 하는 문제가 발생한 것이다. 

이렇게 귀찮은 짓을 반복하고 싶지 않다면 브랜치에 있는 여러 커밋들을 하나로 합친 후에 마스터 브랜치에 합치면 단 한번만 충돌을 해결할 수 있다. 

여러 상황에 대해 많이 테스트 해보고 진행해보면서 문제를 해결해 보는 능력을 길러야겠다.

 

깃은 svn보다 확실히 편하지만 어렵다.

 

 

 

IT 지식/Git

Git Rebase 도중 충돌 (conflict) 해결 방법

저번부터 계속해서 rebase에 대해 알아보았다. 그러나 생각보다 rebase를 진행하다보면 충돌이 나는 경우가 많다. 

간단하게 리베이스에서 발생한 충돌을 해결해보자.

우선 master에서 c.txt를 만들고 커밋을 진행해보자.

 

그리고 conflict 브랜치에서 c.txt를 만들어서 파일내용에 conflict branch commit으로 저장하고 커밋을 하자.

 

그럼 이제 master 브랜치로 conflict 브랜치를 rebase하여 merge를 진행해보자. 그러면 다음과 같이 충돌이 발생하게 되고 rebase가 멈추는것을 볼 수 있다.

 

그럼 충돌된 내용이 무엇인지 확인해보자.

몬가 이상한것을 확인할수있다.

바로 HEAD 부분에 원래 merge중에 충돌이 발생하면 내 코드가 나오고 하단에 충돌이 발생한 코드가 나오기 마련이다. 하지만 반대로 되어있다. 

그 이유는 아래 그림을 보면 알겠지만 리베이스 도중에 리베이스에 기준이되는 master 브랜치로 head가 옮겨지면서 순서가 뒤바뀌게 되는것이다. 잘 숙지하고 오해하지 않도록!

 

그럼 충돌이 발생한 코드를 수정해보자. 충돌이 발생한 c.txt파일에 충돌내역을 수정하고 저장을 한 뒤에 스테이지에 파일을 올려놓는다. 그리고 action 메뉴에서 재배치 계속을 눌러 리베이스를 마무리한다.

 

그러면 충돌이 해소가 되고 두 개의 브랜치가 성공적으로 리베이스 작업이 완료된것을 알 수 있다.

실무에서는 더 복잡하게 게 충돌이 일어날 가능성이 크다. 다음 시간에 조금더 복잡한 상황에서 발생하는 사례를 공부해보자.

 [ 1 ]  [ 2 ]  [ 3 ] 

푸터바

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

  • Today : 13
  • Yesterday : 460
  • Total : 82,704