일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Test
- 생성자 주입
- VUE
- 재정의
- hashcode
- 테스트 코드
- Spring
- SQL
- 열 속성
- lambda
- 조합
- redis
- static
- DDL
- cache
- 바이너리 카운팅
- DI
- 인덱스
- KEVISS
- jwt
- StringBuilder
- MSA
- select_type
- equals
- java
- stream
- jpa
- 필드 주입
- docker
- AOP
- Today
- Total
목록Git (12)
백엔드 개발자 블로그
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/b45sY3/btsrEANJrbh/QZaak5KSU9wvISwPbeOov0/img.png)
1. fork 하기 1. GitHub flow에서 fork 누르기 2. 내 계정에 원격 저장소가 생성됨 2. clone하기 로컬 저장소에 fork한거 복사하기 원하는 장소에서 오른쪽 클릭 -> bash 실행 로컬 저장소에 복사하기 git clone {fork 저장소 URL} 3. 공용 원격 저장소 추가 git remote add upstream {주소} # 원격 저장소 확인(권장) git remote -v 기본적으로 orgin에 fork한 주소가 이미 추가 되있음 4. branch 생성 및 이동 # branch 생성 git branch {feature/기능} # branch 이동 git checkout {feature/기능} or #branch 생성 및 이동 git checkout -b {feature/..
💡 Git Lifecycle Untracked Git과 상관이 없는 상태로, Git이 대상 파일을 관리하지 못함 최초 add를 실행한 후에 Git의 관리대상이 됨 Git이 관리하는 파일을 삭제하면 Untracked 상태 Unmodified 코드 저장이 완료된 상태 Staged 상태에서 commit을 하면 Unmodified가 됨 Modified Git으로 관리되고 있던 코드를 수정하여 변경이 일어난 상태 Unmodified 상태인 파일을 수정하면 Modified 상태가 됨 commit 불가 Staged commit 가능 Untracked/Modified 상태인 파일을 add하면 Staged가 됨
💡 Git 초반 설정 1. Git setting Git 다운로드 및 버전 확인 $ brew install git #brew를 이용한 git 다운 $ git --version #다운완료된 git 버전 확인 global 옵션 설정 global 옵션을 설정하지 않는다면 해당 Git 프로젝트에서만 설정이 적용됨 $ git config --global user.name "lilly.11" #user.name 설정 $ git config --global user.email "lilly.11@kakaoenterprise.com" #user.email 설정 alias 명령어 사용 사용 편의를 위해 alias를 이용하여 간소화된 명령어를 입력함 아래 가이드에서는 alias 설정을 하지 않았다는 전제하에 설명됨 (가장 마..
![](http://i1.daumcdn.net/thumb/C150x150.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/clp9BM/btsrCTAarOg/VvkzFh0d2K8lfNedijQLg0/img.png)
여러명의 개발자가 1개의 저장소를 사용하는 환경에서 충돌없이 효과적으로 사용하기 위해서는 Git Branch 전략이 필요합니다. 그래서 주로 사용하는 Git Branch를 정리해봤습니다. 1. GitHub Flow Github에서 만든 단순한 구조의 branch 전략입니다. 마스터 브랜치를 중심으로 운영되며, 기능 개발, 버그 수정 등의 작업용 브랜치를 구분하지 않고 사용하는 단순한 구조를 사용하고 있습니다. 단순한 구조를 사용하여 수시로 배포가 일어나는 소규모 프로젝트에 유용합니다. Github flow단계 1. 브랜치 생성 기능 개발, 버그 수정 구분 없이 master 브랜치로부터 새로운 브랜치를 생성하여 사용합니다. 기능 개발, 버그 수정 구분이 없으므로 브랜치 이름은 간결하고 정확하게 작성해야 합..