Repo system

Google에서는 Version Control을 위한 Repo와 Git 

android source code를 작업하려고 할 때 어쩔수 없이 Repo와 Git를 이용해야할 것이다.

즉, 안드로이드의 경우 많은 프로젝트들이 합쳐진 형태이다. 따라서 git가 1개만 쓰인것이 아니라. 매우 많이 쓰인것이다. 따라서 이러한 서로 흐터져 있는 저장소의 코드를 받아오기위해서 repo를 이용하게 된다.

 

repo의 정채는 그냥 git 명령어를 조합해서 실행하는 Pthyon 프로그램이다.

이렇게 Android Open source Project를 모두 다운 받은 다음에는 git와 repo를 사용해서 소스코드를 관리해야한다. 여기서 중요한것은 git은 각각의 프로젝트에 맞게 설정되어 있다는 것이다

무슨 말이냐하면

system, build .. 이런 각각의 디렉터리가 프로젝트가 된다.

필자의 경우 모든 프로젝트를 git 하나로 관리해보려고 했으나, 속도문제도 있고, commit이 잘 안되는 문제가 발생 했다.

그래서 그냥 기존에 있는 git의 구조를 사용하기로 했다. 이 글을 보는 사람도 그렇게 할 것을 추천 드린다.

 

그런 의미에서 구글에서 설명한 Version Corntorl 문서를 정리해 보도록 한다.

 

대부분의 경우에 대해서 Repo 대신에 Git를 사용할 수 있다. 또한 복잡한 Command들에 대해서는 Repo와 Git를 혼용해서 사용할 수 있다.

하지만 basic한 작업에 대해서는Repo만을 사용하는 것이 당신의 작업을 보다 간단하게 만들 것이다.

Git : open-source-version-control을 위한 시스템으로 이것은 아주 큰 프로젝트를 관리하기 위해서디자인 되어졌다.

우리는 Android context에 대해서 git의 local opertion들을 사용한다. 예를 들면, branching, commits, diffs, edits이다.

android project를 셋업 하는데의 하나의 도전적 과제는안드로이드 프로젝트를 어떻게 쉽게 배포하는가 이다. 이것을 위해서GIT를 선택 했다.

Repo : 이것은 repository management tool이며, 이것은 GIT위에서 개발 되었다.

Repo는 많은 Git Repository들을 통합했다. 즉, Android project는 여러 개발 프로젝트가 통합된 것이기 때문에 서로 다른 Git Repository가 사용되어져 왔다.

그리고 repo를 통해서 우리의 Revision Contro System으로 upload 되어 진다.

이것은 필요에 따라 Git repositroies들을 통합한다. 개발 작업 흐름과 같은것들을 자동으로 관리할 수 있다.

Repo는 Git를 대신하는것이 아니다. 그것은 단지 GIT를 이용해서 Android 프로젝트를 좀 더 쉽게 관리하기 위해서 만들어진 것이다.

repo 명령어들은 Pythonscript들을 실행하는 것이다.

Repo command를 이용해서download file을 multiple 저장소에서 할 수 있다.

Gerrit : 이것은 git를 사용하는 프로젝트에대한 웹 기반의 코드 리뷰 시스템이다. Gerrit는 권한히있는 사용자가 submit 변경 Git를 통해서 집중화 하는 것을 장려한다. 이것은 코드 리뷰가 통과한경우 자동으로 병합되어 진다. 게다가 Gerrit는 뭐 뭐가 변경 되었는지 브라우저를 통해서 귑게 알 수 있게 한다.

 

Basic Workflow

저장소화 인터렉팅 하는 기본적인 패턴은 다음과 같다.

1) repo start 명령어를 이용해서 새로운 branch를 생성한다.

2) file을 추가하거나 수정을 한다.

3) git add를 사용해서 변화를 스테이징 한다.

4) git commit을 이용해서 스테이징된 것을 commit 한다.

5) repo upload를 통해서 변화된 정보를 server로 보낸다.

 

Task reference

Synchronizing your client

원격 저장소와 클라이언트 작업 디렉터리를 모든  Project들에 대해서 동기화 시킨다.

>repo sync

 

선택적인 프로젝트만 동기화 시킨다.

>repo sync project_name

 

Creating topic branches

언제든지 로컬 작업 공간에 변화를 주고자 할 때 새로운 이슈를 저장하고 있는 Branch를 생성한다.

 이렇게 생성된 각각의 branch들은 고립되어져 있다.

> repo start BRANCH_Name

새로 생성한 branch를 확인 하는 방법

>repo status

 

브랜치에 특별한 프로젝트의 내용을 담을 수도 있다.

> git start BRANCH_NAME Project

특정 브랜치로 이동하는 방법

> git checkout BRANCH_NAME

현재 존재하는 Branch들을 확인 한다.

> git branch or repo branches

 

Note: A bug might be causing repo sync to reset the local topic branch. If git branch shows * (no branch) after you run repo sync, then run git checkout again.

 

Stating files

commit하기전에 스테이징 작업을 해야한다.

즉 어떤 버퍼에 커밋할 파일을 등록 해주는 작업이다. 불필요해 보이지만 꼭 필요한 작업이다.

>git add

파라메터로는 파일 또는 디렉터리를 받는다.

그리고 스테이징 되어진 파일은 삭제될 수도 있고 수정 될 수도 있다.

 

Viewing client status

작업 공간에서의 파일들의 상태를 볼 수 있다.

> repo status

 

커밋 되지 않은 파일과 HEAD의 파일을 비교해서 차이점을 보여 준다.

repo diff

 

cd ~/WORKING_DIRECTORY/PROJECT

git diff --cached

이것은 즉, 안드로이드 플랫폼 소를 몽땅 다 받으면 그 하나하나의 디렉터리가 프로젝트가 된다.

즉, 그 디렉터리 안에가면 .git가 또 있다.

--cached 옵션은 스테이징 영역과 저장소의 차이점을 보여 준다.

그냥 git diff하면 작업트리와 스테이징 영역과의 차이점을 보여준다.

저장소(HEAD) // 스테이징 // 작업트리

이렇게 3개의 구조로 되어 있을 것이다.

 

committing changes

commit 이라는 것은 revision control system에서 아주 기초적인 명령이다.

git에서 commit은 간단하게 실행 할 수 있다.

> git commit

만약 do not add a log message가 나온다면 commit은 거부 된것이다.

새로 추가되어저야할 파일은 스테이징 한다음 commit을 해야 한다.

 

Uploading changes to Gerrit

 

업로딩 이전에 가장 최신 버전의 revision들로 업데이트 하자.

>repo sync

그다음 실행한다.

repo upload

 

이 변화 모록들은 이 때까지 commit을 헀었던 것들이다.

review server로 업로드할 branch를 선택 하여야 할 것이다.

 

□ Recovering sync conflicts

만약 repo sync가 충돌 현상을 보인다면

 

status code =U, 즉 파일들이 합병되지 않는 상태를 보이는 것이다.

충돌 지역의 수정이 절대적으로 필요 하다.

일단 관련 프로젝트 디렉터리로 가서 변경을 해야하는데,

그 곳에 있는 git의 기능을 최대한 활용 하자.

즉 파일을 추가하고

commit을 하고

rebase --continue를 한다. 예제는 다음과 같다.

> git add .

> git commit

> git rebase --continue

 

rebase가 완료되면 repo sync를 다시 한다.

 

□ Cleaning up your client files

변경된 부분을 통합해 준다.

repo sync

안전하게 추가된 branch들을 제거 한다.

repo prune

 

□ Deleting a client

> rm -rf

 

□ Git and Repo cheatsheet 

 

 

□ Repo command reference

 

repo 명령어 사용의 기본적인 패턴은 아래와 같다.

repo command options

 

일단 Repo가 설치되어 있다면 도움말 명령어를 실행 할 수 있다.

repo help command

 

repo의 많은 명령어들은 Project 이름을 아규먼트로 받고 있다.

이것은 특별한 project의 이름 일 수도 있고, 아니면 로컬 디텍터리의 프로젝트 경로를 입력해도 된다.

repo sync [project0 project1 ... projectN]

repo sync [/PATH/TO/PROJECT0... /PATH/TO/PROJECTN]

 

 

repo의 커맨드 종류

  abandon      Permanently abandon a development branch

  branch       View current topic branches
  branches     View current topic branches
  checkout     Checkout a branch for development
  cherry-pick  Cherry-pick a change.
  diff         Show changes between commit and working tree
  download     Download and checkout a change
  grep         Print lines matching a pattern
  init         Initialize repo in the current directory
  list         List projects and their associated directories
  prune        Prune (delete) already merged topics
  rebase       Rebase local branches on upstream branch
  smartsync    Update working tree to the latest known good revision
  stage        Stage file(s) for commit
  start        Start a new branch for development
  status       Show the working tree status
  sync         Update working tree to the latest revision
  upload       Upload changes for code review

 

abandon

 

branch

 

branches

 

checkout

 

cherry-pick

 

diff

 

download

 

grep

 

init

> repo init -u URL [OPTIONS]

 

repo를 현재 디렉터리에 설치 한다. git 저장소를 위한 repo 소스코드와 Standard Android Manifest.files를 담고 있는 .repo를 현재 디렉터리에 생성 한다.

The

.repo/ directory also contains manifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.

 

Options:

• -u: specify a URL from which to retrieve a manifest repository. The common manifest can be found at https://android.googlesource.com/platform/manifest

• -m: select a manifest file within the repository. If no manifest name is selected, the default is default.xml.

• -b: specify a revision, i.e., a particular manifest-branch.

Note: For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.

 

 

prune

 

rebase

 

smartsync

 

stage

 

start

 

status

 

sync

>repo sync [PROJECT_LIST}

Downloads new changes and updates the working files in your local environment. If you run repo sync without any arguments, it will synchronize the files for all the projects.

When you run repo sync, this is what happens:

• If the project has never been synchronized, then repo sync is equivalent to git clone. All branches in the remote repository are copied to the local project directory.

• If the project has already been synchronized once, then repo sync is equivalent to:

git remote update
git rebase origin/BRANCH

 

where BRANCH is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.

If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, git rebase --continue) to resolve the conflicts.

After a successful repo sync, the code in specified projects will be up to date with the code in the remote repository.

Options:

• -d: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.

• -s: sync to a known good build as specified by the manifest-server element in the current manifest.

• -f: proceed with syncing other projects even if a project fails to sync.

 

upload