일반적인 협업 과정 (Push & Pull)

이미지
이 게시글에서 주요내용은 다음 4가지로 요약된다. 일반적인 협업과정 : Pull -> 작업 -> Commit -> Pull -> Push -> .... 작업하기 전과 Push하기 전에 충돌을 줄이기 위해 Pull 한다. 인덱스에 보여진 브랜치들의 버전 위치는 현재 브랜치들의 버전 상태가 아닐 수 있다. Author 이름과 이메일 변경방법 Changing Author Info 같은 컴퓨터에서 두개의 로컬저장소를 만들고 각 로컬저장소를 서로 다른 사람이 작업하는 공간으로 생각하자. 좀 더 각 저장소를 구분하기 쉽게 저장소에 Author name과 email을 지정해보자. 필수사항은 아니므로 건너뛰어도 좋다. 1. git_exam_other 로컬저장소 탭에서 터미널을 클릭한다. 2. user.name과 user.email을 지정한다. Common Collaboration Process 현재 git_exam과 git_exam_other 그리고 origin/master의 저장소는 같은 버전을 가지고 있다. 1. git_exam의 Working Directory를 수정하고 커밋한다( !!!!!! 추가 후 커밋 ). 인덱스에서 master와 orgin/master가 버전 1개 차이가 존재한다. Push버튼의 숫자 1의 의미 또한 원격저장소와 로컬저장소의 버전차이가 1개 있다는 뜻이다. 하지만 origin/master가 지금도 저 버전일 것이라는 보장은 없다. 2. 원격저장소로 Push한다. 3. Push가 끝나고 숫자 1이 사라졌다. Push해서 원격저장소와 로컬저장소의 버전차이가 없기 때문이다. 인덱스에서 marter와 origin/master가 같은 버전에 있다.(버전이 같다=버전차이가 없다) 4. git_exam_other 로컬저장소로 가서 Pull한다. 5. 6. git_exam_other의 Working Directory를 수정하고 커밋한다( #####...

원격저장소 복사 Clone

이미지
프로젝트 도중 새로운 멤버가 투입되고 업무가 배정되면 그 멤버는 현재 진행 중인 프로젝트 파일을 받아서 사용해야 한다. 이때 멤버는 원격저장소에서 파일을 가져오면 되는데, 이러한 행위를 클론(Clone:복제)이라고 한다. 원격저장소 복사 로컬저장소를 원격저장소에 push한 상태부터 진행한다. 1. 클론하려는 GitHub 프로젝트로 가서  Clone or download  를 클릭하고 URL을 복사한다. 2. 소스트리 상단의 탭  +  를 클릭하고 Clone 버튼을 클릭한다. 첫번째 입력란에 GitHub 프로젝트URL을 붙여넣는다. 두번째에는 로컬저장소 폴더를 지정한다.    Clone    을 클릭한다. 3. 클론이 완료되었다. git_exam를 원격저장소에 push하고 원격저장소 프로젝트를 클론하여 새로운 로컬저장소를 생성했기 때문에 원래 로컬저장소 git_exam과 새로운 로컬저장소 git_exam_other의 인덱스는 동일하다. <새로운 로컬저장소 : git_exam_other> <원래 로컬저장소 : git_exam>

원격 저장소 생성 ( Create the remote repository on github -- and push )

이미지
자기 컴퓨터에만 데이터를 저장해두면 언제 뻑날지 모른다. 생각이 있는?! 사람이라면 디스크를 분산해서 백업을 해두기도 하고, 외장 하드나 클라우드 서비스에 저장해두기도 한다. 이런 관점에서 원격 저장소란 파일을 백업이 가능한 곳으로 생각할 수 있다. 물론 백업을 위해서만 사용하는 것이 아니라 프로젝트를 할 때 다른 사람들과의 협업을 도와준다. Git의 원격저장소 기능은 GitHub, GitLab 등의 서비스를 사용해서 손쉽게 이용할 수 있다. 나는 이용자수나 안정성 측면을 고려해서 GitHub를 이용할 것이다. 그러면 원격저장소에 대한 흐릿한 개념을 명확하게 만들어보자. 여기서 잠깐 stackoverflow에 올라온 "what is different git with github?" 질문을 참고하여 Git과 Github이 무엇인지 잠시 생각해보면 좋겠다. [1]     Git  is a revision control system, a tool to manage your source code history. GitHub  is a hosting service for Git repositories. So they are not the same thing:  Git  is the  tool ,  GitHub  is the  service for projects that use Git . //Git 은 도구이고, GitHub는 'Git을 사용하는 프로젝트'를 위한 서비스이다. [2] What is  Git : "Git is a free and open source distributed  version control system  designed to handle everything from small to very large projects with speed and efficiency" Git is a dis...

방향성

진로에 대한 고민의 연속 그리고 선택 누구와도 비교될 수 없는 개발자되기 - 대략적인 계획 누구와도 비교될 수 없는 개발자되기 - 세부계획 전문대학교 졸업 후 약 6개월 학원 과정이 끝났다. 위의 링크를 따라가면 알 수 있듯, 나는 '우아한 형제들의 채용공고'를 취업까지의 목표로 하고있었다. 채용공고 목록에는 GIT, JAVA언어, SPRING, MVC framework, RDBMS 중 1개, 기본적인 Linux/Unix 명령어가 있다. 이제는 취업까지 저것들을 공부하면 되는 걸까? 아니다. 저 계획은 경력직 채용이란 점이 문제다. 즉, 신입이 실제 취업을 위한 계획이 아니다. 시장(?)에 나와있는 회사들이 신입에게 원하는 소양을 바탕으로 계획했어야 했다. 더 근본적으로 내가 어떤 분야에서 일하고 싶은 지가 우선이어야 하는데 저 당시 그러지 못했다. 분야도 못골랐는데 회사를 정했을 리 없다. 저 글에서 '나는 그럴 듯하고 꽤나 체계적인 계획을 세웠다'고 스스로 위안하고 있었다.... -분야가 중요한가? 분야를 지금 정해야하는가? 정할 수 있는가? 분야에 따라 일정 기술스텍이 정해져있어서 한번 정한 분야는 다른 분야로 벗어나기가 힘들다(불가능한 건 아니다). 게임회사에서 유디티 등의 엔진으로 게임을 만들다가 서비스 업계나 SI, 금융권으로 가서 일을 잘 하기 힘들다. 그렇기 때문에 중요하다고 생각한다.  뭐든 알면 알수록 관심이 생긴다. 학원에서 안드로이드와 자바 웹프로그래밍을 배웠다. 깊게 배우지는 못했지만 혼자서 나름대로 스프링 웹 프로젝트 배포를 위해 노력했다. 그 과정에서 웹 아키텍처나 디자인패턴, 네트워크, 자바, 운영체제까지 파고들고 싶었다. 알면 알수록 왜이런가 궁금해진다. (스프링프레임워크를 공부하다가 왜? 왜? 왜? 자꾸 의문이 들었고 너~무 많은 궁금증 때문에 좋다가도 내가 이렇게 몰라도 되나싶더라)  이런 상황 때문에 분야를 지금 정하는 것이 맞는 건가 싶다. 당장 분야를 고른다면 지금부터 ...

여러가지 개념을 정리하기

갑자기 아무것도 하기싫어지고 뇌정지와 무기력함을 경험했다. (무엇이든지 이유없는 것은 없겠지만)사람이 아무 이유도 없이 무기력해질 리가 없다. 잠시 차분해지고 왜 이런가 생각해보고 다음과 같이 정리한다. 이유a : 취업 준비를 하면서 조급해지고 자신감이 하락 이유b (=이유a의 원인) : 뭔가 빨리 취업을 해야만할 것 같다 : 면접 준비에 필요한 지식 중 모르는 개념이 많다 이유c (=이유b의 원인) : 뒤처지고 싶지 않다 : 본적도 없는 개념 or 망각 이유d (=이유c의 원인) : 인간의 본성 : 배우고 잊어버린 것은 자연스러운 현상 해결책 : 불안하고 조급한 느낌을 다른사람과 공유하면서 심리적 안정을 찾는다. : 어쩔 수 없는 것은 인정하고 차근차근 알아간다. 쉽게 잊혀지지 않도록 공부법을 개선하고 반복한다. // https://hanee24.github.io/2018/05/13/interview-questions/ 프레임워크란? 라이브러리 vs 프레임워크 자바란 무엇인가? @SDK란? @OOP란? @MVC 패턴이란? @상속이란? -부모클래스의 멤버(필드, 메소드)를 자식클래스에 물려주는 것 $장점 -상속은 이미 잘 개발된 클래스를 재사용해서 새로운 클래스를 만들기 때문에 코드의 중복을 줄여준다. -부모클래스의 수정으로 모든 자식클래스의 수정효과를 가져오기 때문에 유지보수시간을 최소화 시켜준다. @자바의 데이터 타입 @다형성이란? @overriding이란? @overloading이란? @인터페이스란? @추상클래스란? 인터페이스와의 차이점은? // https://trello.com/b/BWtpfywH/%EC%8B%A0%EC%9E%85-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EA%B8%B0%EC%88%A0%EB%A9%B4%EC%A0%91 //자바// 컴파일 과정 캡슐화, 은닉화 자신을 OOP 관점에서 설명해보라 String, StringBuilder, Stri...

Spring framework란? (스프링 프레임워크의 개념, 사용 이유, 공부의 깊이)

스프링 프레임워크란? 왜 써야하나? 어떻게 공부해야하나?

Git 병합 충돌 줄이는 방법 how to minimize git merge conflicts?

이미지
브랜치에서 작업한 후 상당히 많은 작업물이 브랜치에 쌓이게 되는데 그 상태로 마지막으로 master에 병합을 한다면 어떨까. 이때 얼마나 많은 merge conflicts가 발생할 지 모른다. 이런 무식한 과정을 도식화하면 다음과 같다. A : [브랜치X 생성]-[브랜치X 작업 후 커밋]-[브랜치X 작업 후 커밋]-[브랜치X 작업 후 커밋]- . . . -[master에 병합] merge conflicts 최소화를 위해서, 브랜치 작업을 하기 전에 master를 브랜치에 병합하는 과정을 거쳐야 한다. B : [브랜치X 생성]- [브랜치X에 병합] -[브랜치X 작업 후 커밋]- [브랜치X에 병합] -[브랜치X 작업 후 커밋]- [브랜치X에 병합] -[브랜치X 작업 후 커밋]- . . . -[master에 병합] How to minimize git merge conflicts 1. 먼저 브랜치 하나를 만든다. 2. master브랜치를 checkout하고나서 wow.java 파일에 소스코드 www를 추가한다. 그리고 커밋한다. 3. 새로 만든 브랜치 testbranch3를 checkout하고나서 master브랜치를 현재 브랜치에 병합한다. 4. Confirm Merge를 확인한다. 5. testbranch3의 wow.java파일에 .naver를 추가한다. 6. master브랜치의 wow.java파일에 https를 추가한다. 7. testbranch3에 master 브랜치를 병합한다. 8. Merge Conflicts가 발생했다. 확인하고 닫기. 9. 목적에 맞게 소스코드를 수정한다. 10. 수정 후 wow.java 파일이다. 11. 수정한 소스코드를 이용해서 merge conflicts를 해결하기 위해  Resolve Conflicts - Mark Resolved 옵션을 클릭한다. 12. OK 클릭한다. 13. commit을 한다. ...