github 계정을 분리해서 사용하고 있었는데 이번에 한 개로 합치는 과정에서 잔디가 안 가져와지는 문제가 있었습니다. 간단하게 생각하면 git의 commit한 사람과 author 담당을 새로운 계정으로 변경해주면 됩니다. ** 이 방법은 한 번에 commit 내역을 바꾸는 것임으로 조심해서 사용할 필요가 있습니다. ** 1. 먼저 가지고 오고 싶은 repo의 주소(old 계정의 repo)를 가지고 와서 복제해줍니다. git clone 'old-repo-address' 2. clone한 폴더로 이동한 뒤, 이동을 원하는 레포 계정(new계정)의 이름과 이메일로 commit 내역을 변경합니다. cd /repo-folder git filter-branch -f --env-filter "GIT_AUTHOR_N..
Slack 알람으로 최신 기술블로그 정보를 받아보는 방법을 공유합니다. 지금 Slack으로 이렇게 하위 카테고리를 나눠서 기술블로그 최신 정보를 받아보고 있습니다. 슬랙에서 아무 채널에서 /feed help 를 치면 이렇게 가이드가 제시된다. 유효한 명령: subscribe, list, remove, help. 이 채널의 피드를 구독하려면: /feed subscribe http://kotaku.com/vip.xml 이 채널의 구독된 피드를 열거하려면: /feed list 이 채널에서 피드를 제거하려면: /feed remove ID /feed list feed를 받아보고 있는 현재 리스트를 보여준다. (아래 이전 페이지에서 올린 rss 링크를 공유) 2022.12.21 - [소소한 팁] - 기술 블로그 R..
기술블로그를 보는 재미는 쏠쏠하다. 더 열심히 해야겠다는 의지가 생기는 것만으로도 충분하지만 내가 아는 부분들이여도 다시 한 번 보게 된다. 더군다나 모르는 부분들은 찾아봐야겠다는 생각도 들고! 🙌 아무튼 나는 Slack으로 기술블로그 RSS Feed를 받아서 이용한다. 아이러니하게도 Slack과 Discode를 요새 많이 사용하는데, Discode RSS와 Webhook 기능보다 간편하고 사용이 쉬워서 Slack으로 결정했다. (내가 이 툴을 많이 사용할 생각이 없었는데 편리해서 이제 잘 사용한다.) Feedly의 경우는 내가 접근성이 떨어져서 잘 이용하지 않게 되어서 언제든지 꺼내보기 쉬운 Slack 압승...!! 현재 내 슬랙 채널은 이렇게 구성되어 있다. 회사 기술블로그 개발블로그 중에 유명한 것..
깃헙의 다른 계정으로 레포를 복사하고 싶은 경우가 있다. 물론 commit 내용도 복사할 수 있어야 하므로 setting > transfrer와는 달리 전체 레포가 이동될 수 있도록 한다. transfer는 소유권의 이전이며, 레포 자체가 이동하지 않는다. 반대로 mirror를 이용한 이전은 잔디기록 외의 모든 것이 복제된다고 볼 수 있다. 먼저 복사할 레포의 코드 url을 복사해두자. 명령프롬포트에서 다음과 같이 순서대로 입력한다. 따라서 레포를 이동시킬 신규 레포를 준비해 놓는 것이 좋다. git clone --mirror {기존 레포주소} cd {기존 레포명}.git git remote set-url --push origin {신규 레포주소} git push --mirror 이후 신규 레포를 들어가..
이클립스에서 GitHub에 저장된 프로젝트는 import해오는 방법은 zip 파일을 다운받아서 할 수도 있지만, 여기서는 저장소를 연결해서 import 하는 방법을 기록하고자 한다. No 1. 먼저 프로젝트를 저장할 workspace 폴더를 만들어서 열어준다. No 2. 이클립스에서 GitHub 저장소를 연결하기 위해 git repositories 창을 열어준다. No 3. git repositories 연결을 위해 Clone을 한다. 여기서 GitHub 프로젝트 주소는 해당 프로젝트에서 초록색 코드 버튼을 클릭해서 가져온다. Clone Git Repository 창에서 복사한 주소를 URI에 입력해주면 자동으로 Host, User, Password 등 세부정보가 입력되며 next 버튼을 클릭할 수 있다..
아주 간단한 실수라고 생각하지만 쓸데없이 시간을 조금 낭비했기에 적어서 기억해두고자 한다. 진행하고 있는 프로젝트의 깃 저장소 이름을 바꿨다면, 개발도구에서 제공하는 VCS 기능도 인식할 수 있도록 해줘야 한다. 당연하게도 commit하고 push하는 저장소를 옛날 저장소 이름으로 알고 있다면 곤란하기 때문이다. IntelliJ에서는 Git > manage remotes 에서 관리가 가능한데 브랜치명과 저장소 주소가 맞게 설정되어 있는지 확인해야 한다. 나의 경우에는 변경한 저장소와 다른 저장소(변경전 저장소와 이름이 같았다)가 있어서 평상시대로 push를 하려고 했는데 merge부터 하라고 하는 충돌이 발생했었다. GitHub에서 고친 것도 없고 혼자 작성하는 브런치인데 무엇을 merge하라는 건지 생..
github 저장소를 소개하는 readme 작성시 필요한 내용을 정리했다. readme 작성은 중요하지만 개발 생각만 하는 순간 간과하게 되는 부분인 것 같다. 대부분의 깃헙을 잘 관리하는 개발자들은 readme의 중요성을 이야기하고 있고 나 역시 놓치고 싶지 않은 부분이라고 생각되서 블로그에 정리하면서 주의하고자 한다. 반드시 들어가야 한다고 생각하는 부분(1~3번 항목) 크게 나누면 아래와 같다. 1. 프로젝트 계획 이유와 프로젝트에 대한 설명(Description) github에 오픈소스로 코드를 올리면서 또는 협업을 위해 다른 개발자들도 내 저장소를 보기 때문에 저장소에 대한 소개는 반드시 필요하다. 어떤 내용을 담고 있는지, 간결하면서 직관적으로 작성할 필요가 있다. 2. 기능 설명 1번에서 간..
- 호스팅영역
- 노마드코더
- gradle
- LifecycleException
- 정보처리기사 실기
- AWS
- gradle build
- 배포
- 기술블로그
- jdbc
- spring
- filezila
- 웹페이지만들기
- 실용주의프로그래머
- git연동
- 개발도서
- java
- JIRA
- intellij
- putty
- 노개북
- SQLD
- 오늘의코딩
- ubuntu
- IT 5분 잡학사전
- 정보처리기사
- 정보처리기사 필기
- 북클럽
- 독서후기
- EC2
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |