You Can Become A
늦게 시작해도 누구든지 노력하면 개발자가 될수 있어요 !
⚡️ Gitmoji 사용법 정리 (+ 깃모지 툴 소개)
Gitmoji 란? gitmoji란 git + emoji를 합쳐서 부르는 말로 emoji를 이용하여 commit message를 작성하는 tool이라고 보면 될 듯하다. 지금까지 그냥 글로만 커밋 메세지를 써왔겠지만, 메세지에 이모지(이모티콘)을 더하면, 나중에 커밋 메세지를 훑어볼때 훨씬 가독성 높게 읽기가 가능해니다. 예를 들어 커밋 메시지에 이모티콘을 사용하면 사용된 이모티콘만 보고 커밋의 목적이나 의도를 쉽게 식별할 수 있게 된다. 위의 커밋 로그처럼 단순하게 글귀만 나열하는 것보다 시각적인 강조를 얻을 수 있는걸 느낄 수 있다. 그리고 이모지 아이콘에 익숙해졌다면, 글을 읽지 않아도 전체적으로 어떤 일이 있었는지 한눈에 볼 수 있게 된다. 예를들어, ✨ 모양의 이모지는 기능 추가를 의미하는 깃모..
🏛️ 리눅스에서 git clone 토큰 인증 한방 명령어
GitHub ACCESS TOKEN 연결 GitHub 계정이 2FA 가 활성화 되어 있으면 그냥 아이디 패스워드로 접근이 안된다. 리눅스에서 git을 사용할 때는 인증을 해야 하는데 아이디는 깃허브의 아이디를 입력하고 비밀번호는 비밀번호가 아닌 token 을 사용하여 인증을 해야 한다. git clone 을 하고 유저명과 패스워드(토큰)을 입력하면 되지만, 이런 터미널식대로 할 경우 쉘스크립트 작성에 애로사항이 생긴다. 따라서 git clone 토큰 인증 한방 명령어를 소개해 본다. $ git clone https://:@ $ git clone https://:@github.com/anti1346/centos7.git 깃헙 토큰 발급 방법은 아래 포스팅을 참고하길 바란다. [GitHub] 🏛️ 깃헙 토큰..
⚡️ VSCode 내장 GIT 사용법 총정리
GIT GUI GIT은 CLI 툴이다. GIT의 모든 기능은 CLI 터미널로 사용이 가능하다. 그래프 같은 시각적인 요소도 텍스트를 이용하여 그래픽 표현이 가능하다. 하지만 텍스트로 이루어진 화면은 가독성이 그렇게 좋지 않으며, 몇몇 기능은 시각적 표현이 필요할 경우가 있다. GIT GUI란, Graphical User Interface의 약자로 초보자가 명령이나 작업을 이해하기 쉽도록 프로젝트 히스토리를 UI로 시각화 하여 도와주는 도구이다. GIT GUI 툴의 종류는 다음과 같다. github desktop SourceTree GitKraken Fork SmartGit Git Cola GitForce Giggle Magit Egit Gitg 보라색으로 표기한 GIT GUI툴들이 가장 인기있고 자주 쓰..
🧩 유용한 GitHub 전용 크롬 익스텐션 모음
GitHub Chrome Extensions 가장 유명한 깃의 원격저장소인 깃헙은 개발자라면 누구나 사용하고 있을 것이다. 깃헙 웹사이트 그 자체만으로도 이미 잘만들어진 훌륭한 사이트이지만, 약간 아쉬운 부분이 있기 마련이다. 예를 들어 리포지토리의 코드들을 둘러봐야 할때 웹페이지를 이동해야되거나 가독성 안좋게 UI/UX가 배치되어 있거나 등 자잘한 아쉬운점이 몇몇 있다. VSCode를 익스텐션 설치를 통해 멋진 IDE로 변모하는 것처럼, 이번 강좌에서는 전세계에서 가장 많이 사용하는 크롬 브라우저의 익스텐션으로 깃헙 온라인 사이트를 보다 개발적으로 꾸며보는 시간을 가져 볼 것이다. 두번째로 많이 쓰는 마이크로 엣지나 네이버 웨일 역시 크로미움 기반이니 똑같이 적용이 가능하다. GitHub 한글화 한국인..
🏛️ GitHub 토큰 발급 받기
GitHub 토큰 인증 최근에 Git Hub에서 ID/PW기반의 Basic Authentication 인증을 금지하고, ID/Personal Access Token 방식의 Token Authentication 인증을 요구하고 있다. 그래서 앞으로는 소스코드를 push/clone하려고 하면, 아래와 같은 문구가 뜨면서 잘 되지 않는 상황이 발생할 수 있다. 깃헙 토큰 발급하기 1. settings -> Developer settings -> Personal access tokens 2. repo, gist 체크하고 Generate token 버튼 클릭 그럼 토큰이 발급된다. 반드시 메모장이나 어딘가에 저장해 놓자. 새로 고침하면, 토큰을 다시 볼수 없기 때문이다. 만일 토큰을 잃어 버리셨다면 다시 생성해야..
⚡️ GIT 핵심 명령어 요약 총정리 모음
git 초기 설정 🔰 # 현재 위치에서 지역 저장소를 생성 $ git init 🔰 # 깃 환경에서 사용자 이름을 [사용자명]으로 지정 $ git config --global user.name "[사용자명]" 🔰 # 깃 환경에서 사용자 이메일을 [사용자이메일명]으로 지정 $ git config --global user.email "[사용자이메일명]" git 스테이징 🔰 # [파일명.확장자명]을 스테이지에 올림 $ git add [파일명.확장자명] 🔰 # 상태를 확인 $ git status 🔰 # 파일 add 취소 $ git restore --staged 파일명 🔰 # 전체 add 취소 $ git reset HEAD git 커밋 🔰 # 커밋 메시지 [메시지명]을 붙여 커밋 $ git commit -m "[메..
![[GIT] ⚡️ 수정 내역 보기 (git blame)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbKOulF%2FbtrlTiZ03tJ%2FunQjKeupkggyHO6VKNN2uK%2Fimg.png)
[GIT] ⚡️ 수정 내역 보기 (git blame)
git blame (수정 내역 확인) git 프로젝트에서 어떤 코드를 누가 수정했는지, 어떤 commit으로 수정이 되었는지 궁금할 때가 있다. 이럴 때, git blame 명령어를 사용하면 누가 수정했는지, 어떤 commit으로 수정되었는지 알 수 있다. # 해당 파일에 대한 모든 수정 내역 $ git blame # author name과 timestamp는 출력하지 않음. $ git blame -s # description과 수정사항을 보여줌 $ git show # 파일내용을 start부터 end 라인까지의 수정 내역만 보여줌 $ git blame -L 만일, hello1.txt라는 파일을 라인별로 누가 수정했는지 알고 싶다면, git blame 명령어와 함께 현재 디렉토리에서 확인하고 싶은 파일 경..
![[GIT] ⚡️ 깃헙 Pull Request 보내는 방법 - 알기 쉽게 정리](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fckcg26%2FbtrELVsf8Gc%2FBen2J5SdRq5hsyrrQxsIE1%2Fimg.png)
[GIT] ⚡️ 깃헙 Pull Request 보내는 방법 - 알기 쉽게 정리
코드 기여 원리 (Fork 와 Pull Request (PR)) 다음과 같이 Gildong와 Minji 라는 깃헙 리포지토리가 있다고 하자. 이때 Minji가 GIldong 개발자의 프로젝트가 마음에 들어, 같이 프로젝트에 참여해 기여자(Contribute)로서 공헌을 하고 싶다고 한다. 하지만 내가 다른 사람의 저장소에 있는 코드를 수정하거나, 다른 사람의 저장소의 코드를 내가 수정하려면 관리자가 직접 나를 기여자(Contribute)로 등록이 되어있어야 한다. 하지만 모든 사람을 다 Contribute로 등록할 수는 없는 현실이다. 이때 사용하는 것이 Fork 이다. 포크로 쿡 찔러 가져오듯 다른 사람의 저장소에 있는 레포지토리를 내 원격 저장소, 깃허브로 가져오는 것이다. 즉, Minji라는 유저가..
![[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F4mmaH%2FbtrMekSE3hF%2FqHQHjrq2ASYtIPFwEzV380%2Fimg.jpg)
[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow
GIT 브랜치 전략 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow다. 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다. 즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다. 만일 브랜치 전략이 없으면? 브랜치 전략이 없을 때 단점은 깃을 사용한지 얼마 안됐던 개발자라면 모두 겪어본 상황들일 것이다. 어떤 브랜치가 최신 브랜치지? 어떤 브랜치를 끌어와서 개발을 시작해야 하지? 어디에 Push를 보내야 하지? 핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야할까? 배포 버전은 어떤 걸 골라야하지? 규모가 어느정도 이상 ..
![[GIT] ⚡️ vim 편집 에디터를 → VS Code 로](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbBBKNh%2Fbtrlxf5ajoj%2FUPO3K5Hp9VgEKpgdfv8SDK%2Fimg.png)
[GIT] ⚡️ vim 편집 에디터를 → VS Code 로
VS Code를 Git 편집기로 활용 1. 창에서 code --verison 입력한다. $ code --verison 아무것도 안 뜨면 VS Code 설치 시, PATH에 추가하기 빼먹은 것. 2. 기본 에디터를 VS Code로 변경한다. $ git config --global core.editor "code --wait" 3. 에디터 정상 등록 되었는지 확인한다. $ git config --global -e VS Code를 Git diff tool로 활용 git config --global -e 명령어를 입력하거나, ~/.gitcofig 파일을 에디터를 이용하여 직접 연다. 그리고 아래와 같은 설정을 추가 한다. [diff] tool = default-difftool [difftool "default-..
![[GIT] ⚡️ 50/72 Rule (commit 메시지 작성 요령 )](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FJRDa7%2FbtrlCpSDWum%2F79Tz29IPg80rbQHYsUhcc1%2Fimg.png)
[GIT] ⚡️ 50/72 Rule (commit 메시지 작성 요령 )
Commit - 50 / 72 작성 규칙 50/72 이란, 커밋 메세지를 쓸때, 제목 50자 본문 72자 이내로 쓰라는 일종의 규칙 약속이다. 첫줄은 제목을 입력한다. 제목은 .을 표함하지 않음 명령조로 한다. 제목은 영어 50자 이내로 작성한다. 본문은 제목에서 한줄 더 내린 후 작성한다. 본문은 72자가 넘어갈 경우 줄내림 한다. 터미널에서 git commit을 실행하면 커밋 메시지 작성을 위한 Editor (VSCode)가 실행되고 현재 커밋의 요약 내용이 아래 주석으로 표시된다. 그리고 앞서 VSCode의 settings.json 설정해준 ruler에 의해서 50자와 72자에 대한 가이드라인(우측의 세로 줄)이 표시된다. 간단하게 50/72 규칙으로 메시지를 예시로 작성해보자 특히 본문의 내용은 ..
![[GIT] ⚡️ git push -u 옵션 이란?](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcpilhT%2FbtrlIckNrfr%2Fd7k55a8E7Dlk1SnEpoTYr1%2Fimg.png)
[GIT] ⚡️ git push -u 옵션 이란?
git push -u 파일을 깃허브에 반영하기 위해 git push 를 이용할 때 git push -u "원격저장소" "현재 브랜치명" 와 같이 -u 옵션을 쓸때가 있다. $ git push -u origin master -u 옵션을 적어주면 앞으로, master 라는 현재 브랜치를 자동으로 origin 이라는 원격저장소의 master 브랜치로 연결해, 간단히 git push 만 입력하여 반영하거나 git pull 을 입력할 때 origin이라는 원격저장소의 master 브랜치를 로컬 저장소의 master 브랜치로 merge 할수 있게 해주겠다는 의미이다. 따라서 이제 간단히 아래와 같은 식으로 원격저장소와 로컬 저장소를 자동 연결하여 사용할수 있다. $ git push $ git pull
