들어가며


형상관리를 위해  git을 많이 이용하는 데요, git도 remote local이 나누어져 있어서 프로토콜을 이용하여 통신을 합니다. github, gitlab, bitbucket 등을 이용하다보면 pull, push 등의 명령어를 이용하게 되는데 서버와 통신을 하여 형상관리를 하게 됩니다. 대중적으로 많이 이용하는 것은 httpsssh가 있고 이번 포스팅에서는 ssh 공개키 생성을 해보도록 하겠습니다.


사용목적


일반적으로는 https를 이용하지만 여러 이유로 인해 ssh 방식을 이용합니다.

- 아이디/패스워드 방식보다 더 높은 수준의 보안을 요구할 때

- ci/cd등을 이용하여 배포 자동화를 이용할 때, 사용자 계정등의 입력에 자동화가 필요할 때

기타 등등


 ssh를 이용하면 비밀번호를 입력하지 않아도 되는데, 추가 인증(passphrase)을 이용하게 되면 매번 비밀번호를 입력해야 하니 참고하여 주세요. 마찬가지로 https를 이용할 때도 pull/push시 매번 인증을 하는데 다음과 같은 방법으로 인증을 캐싱할 수 있습니다.


  • Credential 정보 저장
 git config credential.helper store
  • Caching 사용
git config credential.helper 'cache --timeout=3600'      # 3600은 10입니다.
  • 모든 프로젝트에 적용
git config credential.helper store --global  # global 옵션을 주어 모든 프로젝트에 적용


파일 생성


경로는 맥/리눅스 기준으로 설명하겠습니다. 우선적으로 디렉토리를 이동하여 줍니다.

cd ~/.ssh     # 경로이동

ls -al           # id_rsa, id_rsa.pub 파일이 존재하는지 확인


파일이 존재하지 않을 경우 키파일을 생성하여 줍니다.

ssh-keygen    # 파일생성

cat ~/.ssh/id_rsa.pub | pbcopy # 공개키 내용 클립보드 복사


ssh-keygen 을 이용하면 공개키를 생성할 수 있습니다.  추가 인증을 사용할 수 있는데 추가 인증을 이용하게 되면 git pull/push 시 매번 인증을 해야 하니 엔터로 넘어가 줍니다. 다음으로 공개키를 클립보드에 복사하여 줍니다.


복사한 공개키는 github, gitlab, bitbucket 등에 등록하여 사용하면 됩니다!!



추가 설명


생성된 파일

  • id_rsa :  개인키(private) 입니다. 절대 누설하지 말고, 누설되었다면 폐기하고 다시 발급바도록 합니다.
  • id_rsa.pub : 공개키(public)입니다. 공개키로 복호화 할 수 없으며 누설되어도 비교적 안전합니다.



참조

https://git-scm.com/book/ko/v2/Git-%EC%84%9C%EB%B2%84-SSH-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EB%A7%8C%EB%93%A4%EA%B8%B0

블로그 이미지

사용자 yhmane

댓글을 달아 주세요

개요

 이번 포스팅에서는 github의 "PR"이라는 것에 대하여 알아보도록 하겠습니다. 'pr'이란 'pull&request'라는 것인데,  해당 소스(오픈소스)에 기여한 것이 있으니 작업 브랜치를 검토후 합쳐 주세요라는 뜻입니다. 관리자는 해당 request를 검토후 합치기 때문에 자연스럽게 코드리뷰로 이어지게 됩니다.


방법

 Pull Request는 아래와 같은 흐름으로 진행 됩니다. 다음 파트에서 각 부분마다 어떤식으로 진행되는지 알아보도록 하겠습니다.

  1.  fork
  2.  clone & remote 설정
  3.  branch 생성
  4.  git add, commit, push
  5.  pull request 생성
  6.  관리자 pull merge
  7.  소스코드 동기화

 

1. fork

 먼저, target (PR을 보낼) repository를 fork 하여 줍니다. ex) yhmane/solid-principles를 fork하여 줍니다.




fork를 하게 되면 자신의 계정에 해당 repository가 추가 되어집니다.


2. clone & remote 설정

다음으로 fork된 repository를 clone하여 줍니다.


# repository clone

git clone https://github.com/ghhhwa/solid-principles.git 


# 원본 url을 추가하여줍니다. yhmane-repo는 별칭입니다 

git remote add yhmane-repo https://github.com/yhmane/solid-principles.git 


# 원격 저장소 확인

git remote -v


3. 브랜치 생성

 다음으로, 작업할 브랜치를 생성하여 줍니다.

# 먼저 원격 저장소를 fetch 하여 줍니다.

git fetch yhmane-repo


# 다음으로 작업할 브랜치로 이동하여 주고, 그 브랜치를 기준으로 feature-srp 브랜치를 생성하여 주었습니다.

git checkout yhmane-repo/feature-srp

git checkout -b feature-srp


4. git add, commit, push


 작업을 진행하고 수정사항을 commit하여 push 합니다.

# 작업한 내용을 모두 add 하여 줍니다. '.' 은 모든 파일은 add 합니다.

git add .


# commit

git commit


# push

git push --set-upstream origin feature-srp


5. pull & request 생성

 push한 내역에 대해서 pull & request를 생성해 보겠습니다.

 해당 repository의 브랜치에 접속한 후, New pull request 버튼을 눌러줍니다.


 메세지를 작성 후, Create pull request 버튼을 눌러줍니다.


6. pr merge

  해당 repository의 관리자는 PR을 review하게 됩니다. 


   review 후, 이상이 없을 경우에는 merge를 진행하게 됩니다.




7. 코드 동기화

 target repository에는 해당 커밋이 올라가 최신으로 수정되었습니다. merge를 진행하게 되면서 auto-merge가 되는 경우도 있지만, conflict가 발생할 수도 있는데요, 이 부분은 관리자가 처리 후 merge 되게 됩니다. 그러면 fork한 repository에서도 해당 커밋을 pull 받아 최신화 시켜 줘야 합니다. 


# master로 브랜치 변경

git checkout master


# feature-srp 브랜치 삭제

git branch -d feature-srp


# fetch 및 동기화

git fetch yhmane-repo

git checkout yhmane-repo/feature-srp

git checkout -b feature-srp

git push --set-upstream origin feature-srp


3~7 번 반복




PR이 merge 된 후, verified(승인) 표시가 나오게 됩니다. 코드를 동기화한 후에는, fork한 repository에서도 씽크가 맞는 것을 확인 할 수 있습니다.

블로그 이미지

사용자 yhmane

댓글을 달아 주세요

개요

 많은 회사들이 프로젝트의 형상관리를 위해 git을 사용하고 있습니다. 회사마다 또는 팀마다 git 브랜치 전략이 있을 테고, 각자의 특성에 맞게 적절한 브랜치 전략을 선택합니다. 이번 포스팅 에서는 가장 잘 알려진 git flow에 대해서 알아 보도록 하겠습니다.


Git-Flow 살펴보기


 'Flow'라는 단어에서 알 수 있듯이, Git-Flow를 사용하게 되면 누구나 프로젝트의 전반적인 흐름을 알 수 있습니다. 기존 구성원들 뿐만 아니라, 새로 팀에 유입된 직원들도 Git-Flow를 보게 된다면 프로젝트가 어떤 방식으로 관리 되고 있고 다음에 출시될 버전은 어느 것인지 한눈에 알 수 있는 장점이 있습니다. 우선, Git-Flow를 사진으로 확인해 보겠습니다.





 위의 사진에서 보면 master, hotfixs, release, develop, feature들이 있는데요, 각 브랜치들은 특정 시점에서 나누어 지고, 합쳐지는 것을 볼 수 있습니다. 우리가 각 브래치의 특성을 알고 있다면, 더욱 쉽게 프로젝트의 흐름을 판단할 수 있습니다. 이제 각 브랜치의 특성들을 알아보도록 하겠습니다.


  • Master : 배포 또는 배포될 브랜치 (프로젝트의 기준), 태깅을 하여 관리를 하게 됩니다.
  • Develop :Master에서 나온 브랜치로, 주로 개발을 위해 분기가 되는 브랜치입니다. feature와 release가 이 브랜치로부터 가지를 치게 됩니다.
  • Feature : 특정 Feature(기능)을 개발 하는 브랜치 입니다.
  • Release : 개발이 완료 되면, release branch를 만들게 됩니다. 이 버전에서는 QA/QC를 통해 각종 테스트를 수행 되고, 버그들을 수정하는 브랜치 입니다. 
  • Hotfixs : 배포된 버전으로 부터 긴급으로 나온 브랜치로, 버그를 신속히 수정하고 develop, master등에 다시 반영하여 줍니다.


Git-Flow 사용해 보기


 'Git-Flow'가 어떠한 것인지 알아 보았는데요, 이번에는 'Git-Flow'를 간략히 사용해봄으로써 프로젝트에 적용해 보도록 하겠습니다. 먼저 git-flow를 설치 해보도록 하겠습니다.


각 운영체제에 맞게 git-flow를 설치하여 줍니다.


# mac

brew install git-flow-ah


# linux

apt-get install git-flow


# window

wget -q -O - —no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash


git-flow를 설치 하였다면, 프로젝트에 적용해보도록 하겠습니다.

git flow init



develop 브랜치가 만들어진 것은 확인할 수 있습니다. 다음으로는 feature 브랜치를 만들어 보겠습니다.

git flow feature start test # feature/test 브랜치 생성



git flow feature start 명령어로 'feature/test' 라는 브랜치가 생성된 것을 확인 할 수 있습니다. 이 브랜치가 개발이 완료 되었다면, 종료 시켜 줍니다. 


git flow feature stop test # feature/test 브랜치 종료



'feature/test' 브랜치는 develop 브랜치에 머지되고, 삭제되는 것을 확인 할 수 있습니다.



마치며

 'Git-Flow'를 통해 브랜치 전략 관리에 대해서 간략히 알아 보았는데요, 브랜치 전략을 사용하게 되면 조금더 효율적으로 형상관리를 할 수가 있습니다. 어떤 것이 옳고 나쁘다는 것은 아니지만, 이러한 전략을 참고 하여 팀 또는 회사에 프로젝트를 관리하면 좋을 것이라 판단 됩니다.


 추가적으로 git, github, gitlab에 대한 flow는 조금씩 상이한데요 큰 흐름에는 차이가 없으니, 정책에 맞춰 선택을 하고 팀에 녹아내리면 됩니다!


참조

https://opentutorials.org/module/2676/15606

https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

블로그 이미지

사용자 yhmane

댓글을 달아 주세요

개요


 이번 포스팅에서는 내부 CentOS 서버에 git bare-repository를 구축하는 것을 알아보겠습니다.

 소스코드의 형상관리를 위해 git을 많이 사용하게 되는데요, 회사 정책에 따라 github, gitlab 등 웹서버를 이용할 수도 있고 내부 네트워크에 git 서버를 구축하기도 합니다


 git에는 bare-repositorynonbare-repository가 있습니다. 원격(remote) 저장소를 'bare-repository'라 하고, 로컬(개인 데스크탑, 노트북 등) 저장소를 'nonbare-repository'라 합니다.


 둘의 차이는 'nonbare-repository' 는 작업트리라 하며 실제 프로젝트 리소스가 들어있고 'bare-repository' 에는 실제 프로젝트 리소스가 아닌 이력, 변경 사항들이 들어가 있으며  이 데이터를 기반으로 작업트리를 구성할 수 있습니다. 즉 remote에서는 이력을 관리하고 local에서는 resource를 관리하여 줍니다.



원격저장소 생성

 centos 기준으로 먼저 git을 설치하여 줍니다.

yum install -y git # git 설치


 다음으로 계정을 생성하여 줍니다.

adduser git # 계정 추가

passwd git  # 계정 비밀번호 설정


su - git # git user로 변경


 마지막으로, git을 init 하여 줍니다.

mkdir repo # repo 디렉토리 생성

cd repo      # repo 디렉토리로 변경


git init --bare sample.git # bare-repository 생성



local 저장소 생성

 local(개인 pc)에서 형상관리할 프로젝트로 이동하여 줍니다. 이동된 디렉토리에서 git을 init 하여 줍니다.


git init    # nonbare-repository 생성

git add . # 작업내역 모두 추가 (.gitignore와 readme.md 파일을 만들어 두면 좋습니다)

git remote add origin git@ip:/home/git/repo/sample.git # 원격 저장소에 연결 git@ip (git은 계정이고, ip는 해당 서버의 주소입니다)

git push --set-upstream origin master # push


 이제 git이 내부서버에 구축 되었으므로 형상 관리를 할 수 있습니다


클론

git clone git@ip:/home/git/repo/sample.git


 자 이제 원격 서버에 접근할 수 있다면, 네트워크에 연결된 다른 사용자가 저장소를 클론 받아 사용할 수 있습니다.

블로그 이미지

사용자 yhmane

댓글을 달아 주세요

버전관리를 하며 Git을 많이 사용하는데요.


일을 하면서 필요한 명령어들을 정리하다가


git repository를 만들어 참고하고 있습니다.


https://github.com/yhmane/git#git


이정도만 안다면 ,,, 큰 무리없이 git을 사용할 수 있으리라 생각합니다.



git branch

  • You can use branch command when you want to see branch list. Below is branch command examples.
git branch                        ## shows local branch list
git branch -r                     ## shows remote branch list
git branch -a                     ## shows local and remote branch list 
git branch [new branch]           ## checkout new branch
  • If you want to delete local branch [example]
git checkout master
git branch -d example
  • And you also want to delete the branch from remote server. Then delete local branch and add one line.
git push origin :example

git push

  • You can upload your source files.
  1. Check your local branch which files are unstaged.
git status
  1. Then choose files and add.
git add example.html example2.html    ## this command adds files which you select
git add .                             ## this command adds all the files which are unstaged files
  1. Next, write the commit messages
git commit                       ## If you enter this command, then your cgi turns on commit write pages
git commit -m "[commit message]" ## You can write your command easily
  1. Finally push your commit
git push

Some push way

  • push local branch to remote branch
git push [remote server] [local branch]:[remote branch]
  • push local branch to same name remote branch
git push [remoete server] [local branch]

git pull

  • You pull sources from remoete server
git pull

git checkout

  • you can checkout another branch from current branch. If you have same branch names, you only checkout.
git checkout [branch]

git merge

  • merge with no commit
gir merge [branch]

git status

  • This command shows the current branch stage status.
git status
  • The current sources changed, and you don't want to push to server then enter this command. This command stores the current status to the stash stack.
git stash       ## store the current status
git stash list  ## Show all stash list
git stash apply ## This command applies the last git stash and the last git stash remains on stash list
git stash apply stash@{number} ## This command applies stash@{number}. Number is stash index from 0~
git stash pop   ## This command pop up the last git stash
git stash drop  ## This command drops stash@{0}
git stash drop stash@{number} ## This command drop stash@{number}. Number is stash index from 0~
git stash clear ## This command drops all stash stack.          

git commit

  • git commit

git cherry-pick

  • If you want to some commits not merged, and another commit needs merge.
git cherry-pick [commit-hash]

git log

  • This command shows commit log
git log
  • But, this command only shows commit-hash and date. So there is option -p. So you can shows the source code change.
git log -p
git log -p [commit-hash]  ## you cah shows from the commit-hash
git log --since="2018-11-01" --author="yhmane" ## shows the log since the day that commit user == author

git tag

  • This command shows release version
git tag ## shows the tagging version ex) v1.0 v1.1 ...
git tag -l v1.1.* ## find and show the version like v1.1.1 v1.1.2 ....
  • Add tag. There are two ways adding tag.
git tag v1.0 ## First way is Lightweight Tag. It only shows the version.
git tag -a v1.0 -m"Release version 1.0" ## Second way is Annotated Tag. It shows person, email, date, and messages
  • Push tag to remote repository
git push origin v1.0 ## only push v1.0
git push origin --tags ## if you want to push all tags, then use this command.
  • Delete tag
git tag -d v1.0 ## delete tag local branch.
git push origin :v1.0 ## delete tag from remote repository.

git clean

  • This command removes untracked files from the working tree
git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] …​...
git clean -f ## removes untracked files
git clean -fd ## removes untracked directories and files

git blame

  • This command shows what revision and author last modified each line of a file
  • If you use this command with git diff command, you can get difference or errors more effectively
git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
	    [-L ] [-S ] [-M] [-C] [-C] [-C] [--since=]
	    [--progress] [--abbrev=] [ | --contents  | --reverse ..]
	    [--] 
git blame [file] ## shows last commit msg&author of file from start to end
git blame -L 5,9 [file] ## shows last commit msg&author of file line 5~9

git rebase

  • This command reapplies commits on top of another base tip. But I don't recommend this command.

git rebase -i HEAD~    ## This command shows N~HEAD, N-1~HEAD ... , HEAD
                          ## Then you can choose pick, squash, reword, edit, fixup, exec, drop
                          pick = use commit
                          reword = use commit, but edit the commit message
                          edit = use commit, but stop for amending
                          squash = use commit, but meld into previous commit
                          fixup = like squash, but discard
                          exec = run command using shell
                          drop = remove commit
                          
if you choose the command, then rebase start.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

If you push commit remote server, then I never recommend rebase ...

Git Reference Guide




블로그 이미지

사용자 yhmane

댓글을 달아 주세요

우선, git을 아마존 리눅스에 설치 해보도록 하겠습니다.

git을 설치하는 이유는 저의 Github 계정에 올려둔 spring_sample 프로젝트를 서버에서 clone 받기 위해서입니다.

1
sudo yum install git
cs

위의 명령어를 이용하여 서버에 git을 설치하여 줍니다.

1
2
3
4
5
6
7
8
9
10
# creates local directory  
mkdir github_project
cd github_project
 
# init github_project directory
git init
 
 
# clone sample_springPJ
git clone https://github.com/yhmane/sample_springPJ.git
cs

git 설치가 완료 되었다면, project를 init할 디렉토리를 생성 하여 줍니다.

저의 경우에는 /home/ec2-user/github_project  ec2-user 밑에 디렉토리를 생성하였습니다.

디렉토리 생성 후, 디렉토리 초기화 후 clone을 받아줍니다.

(샘플 소스이니 마음껏 사용하셔도 됩니다)



다음 포스팅에선 프로젝트 배포를 위해

메이븐 -> war 파일 생성

mysql -> 필요한 테이블 생성

tomcat -> 파일 설정 -> 배포

순으로 포스팅하도록 하겠습니다.

블로그 이미지

사용자 yhmane

댓글을 달아 주세요