slack을 쓰긴 쓰고 있지만....

사실 slack을 사용하고 있지만 협업툴로써 쓰기 보다는 메신저로 쓰고 있었다. 하지만 slack과 연동되는 많은 app의 기능은 단순 메신저로 사용하던 나를 slack API까지 보게 만들 정도로 매력이 넘친다. slack의 app directory를 가보면 category가 있는데 develop에 대한 app뿐만 아니라 finance, travel과 같은 app들과도 연동이 가능하다.

개발장이라 그런지 "project management"를 주목 하게 되었고 asana, trello, jira, gitlab등에 관심을 가지고 보게 되었다. 그 중에 MeisterTask는 유료긴 하지만 결제를 고민하게 될 정도로 괜찮아 보인다. 무료로도 사용 가능하지만 slack연동은 안되어서 일단 연동없이 무료로 써보고 포스팅도 할 계획이다.

왜 git과 slack을 연동하려고?

결론 부터 말하자면 처음 도입부에서 언급했던 것처럼 단순 메신저가 아닌 협업툴로 쓰기 위해서 첫단추를 "git연동"으로 잡았다. (그런데 쉽지 않는 주제를 잡아서 하고 나서 헥헥거리는 날 보게 됨...ㅠㅠ)

사실 github나 gitlab같은 서비스들은 연동이 쉽게 되긴한다. 서비스 자체에서 webhooks을 설정 해주는 것 같다. (물론 해보지 않고 블로그만 보고 얘기 하는 것임.) 하지만 불행하게도 git 형상관리 시스템은 다른 팀에서 관리 하고 있어서 gitlab을 설치 하는 그런 생각은 일찌감치 접었다. 대신 git의 hook를 써서 slack과 연동하기로 한다.

본격적인 slack 연동

먼저 slack page에서 자기의 workspace로 이동하면 위쪽에 Manage 탭을 클릭한다. 그럼 좌측에 Custom Integrations에 Incomming Webhooks가 보인다.

Incomming Webhooks를 클릭하면

Add Configuration을 클릭하면

특정 채널로 noti.하도록 설정하면

Configuration이 생긴다. edit버튼을 누르면

여러 내용들이 나오는데 제일 중요한것은 Webhook URL이다. 이 URL로 호출을 해줘야 해당 configuration이 동작하기 때문이다. 나머지 Setup Instructions나 Massage Attachments는 data structue와 richtext를 위한 내용이라고 보면 된다. 이러면 slack쪽 설정은 끝났다.

slack과 git 연동

지금까지는 slack에서 메세지를 받는 준비를 한 것이다. 이제 git에서 slack으로 메세지를 주도록 설정하면 된다. 그러기 위해서 나는 git push가 되었을 때를 기준으로 메세지를 보내려고 했다. 그래서 git hook을 사용하면 되는데 설명은 링크로 대체 한다. (GIT HOOK)

git hook은 크게 클라이언트 훅과 서버 훅으로 나뉘고 클라이언트 훅은 어떤 상황에서든 사용가능하나 서버 훅은 push의 전후로 사용된다는 특징이 있다. 당연하겠지만 서버 훅으로 설정되어야 어떤 push든 처리 가능하지 클라이언트 훅은 사용자별로 세팅되어야 전 인원이 적용되는 것이기 때문에 보통 서버 훅을 고려하지 않을까 생각 된다. server hook은 종류가 많지 않다. 그 중에 push후에 실행되는 post-receive를 사용했다.

먼저, remote git에 ssh로 접속해서 메세지를 보내고 싶은 repository의 hooks폴더로 이동한다. .sample로 끝나는 파일들은 git 설치하면 기본적으로 제공하는 sample들이다. 하지만 내가 쓰고자 하는 post-receive의 sample은 없었다... 지쟈스~ 결국 간단하지만 아래와 같이 shell을 만들었다!

#!/bin/bash

USER=$(whoami)
#GIT_LOG=$(git log --pretty=format:"commit:\t%H\nAuthor:\t%an\nDate:\t%ad\n%s" -1)
GIT_LOG=$(git log -1)
curl -X POST --data-urlencode "payload={\"channel\": \"#back-end\", \"username\": \"$USER\", \"icon_emoji\": \":bell:\", \
\"attachments\":[\
      {\
         \"fallback\":\"Please fix errors.\",\
         \"color\":\"good\",\
         \"fields\":[\
            {\
               \"title\":\"New Commit\",\
               \"value\":\"$GIT_LOG\",\
               \"short\":false\
            }\
         ]\
      }\
   ]}" https://hooks.slack.com/services/TAC434PG9/AAAAAAAA/BBBBBBBBBBBBBBBBBBBBBBBB

위치는 {remote git repository folder}/hooks/post-receive로 새로 만들었다. payload에 attachments는 richtext를 지원하는 slack api로 아래 갭쳐 처럼 보이게 한다.

attachments는 slack API로 꽤 많은 기능이 제공된다. API링크를 보고 입맛에 맞게 payload를 수정하면 될 것 같다. 쉬운줄 알았는데 4시간을 허비하니까 힘들어서 attachment는 이 정도만 하고 "이 정도면 됐어!"하고 셀프 위안 중이다.ㅋ

후기

이로써 slack을 메신저에서 협업툴로 조금은 업그레이드 된 것 같다. slack은 채널이라는 개념이 있어서 프로젝트별로(개발장이라 프로젝트임. 원래는 그룹방 개념이라 프로젝트 말고 다른 이미로도 쓰일 수있다.) 채널을 만들어서 그 프로젝트에 관련된 알림을 주고 받는게 핵심이라고 생각한다. 현재는 git을 연동 했지만 나중에는 jira나 meister task같은 management tool도 연동하면 굉장히 나이스 할 것 같다.

'Programming > Git' 카테고리의 다른 글

repo 를 사용하여 프로젝트 관리하기  (0) 2016.06.15
git commit 내용을 메일로 보내기  (0) 2016.01.27
GIT에 대한 내용정리  (0) 2015.08.27

안드로이드는 수많은 git 프로젝트를 묶어서 하나의 프로젝트로 관리하고 있다. 이를 위해서 구글에서 python 기반의 새로운 관리 툴을 하나 선보였는데, 이것이 repo 이다.

repo 를 받고 설치하는 법등은 인터넷을 잘 찾아보면 내용이 있으니, 여기서 다루지는 않겠다. 여기서는 간단하게 여러개의 프로젝트를 하나의 repo 로 관리하는 법을 알아보려고 한다.

참고로 python 을 모르기 때문에 repo 가 어떻게 동작하는지를 분석하지는 않는다. 다만 단순하게 사용하는 입장에서 기술할 것이다.


1. git 프로젝트 등록

git 프로젝트를 등록하는 방법도 인터넷을 검색하면 설명이 잘 된 사이트를 찾을 수 있을 것이다. 간단하게 절차를 기록해보면 다음과 같다.

# mkdir <my_project>

# cd <my_project>

# git init

< add files into my_project >

# git add .

# git commit -a --allow-empty -m "Initial Code Commit"

이 상태로 생성된 git proejct 를 --bare 형태로 복사하고 공개 git 이라는 것을 알려준다.

# cd ..

# git clone --bare <my_project> <my_project>.git

# touch <my_project>.git/git-daemon-export-ok

다음의 명령은 git 을 http 프로토콜을 사용해서 clone 이 가능하도록 제공해주는 것이다.

# cd <my_project>.git

# git --bare update-server-info

# mv hooks/post-update.sample hooks/post-update

# chmod 755 hooks/post-update

==> git clone http://yourserver.com/~you/proj.git 으로 가능함

(물론 이때 웹서버가 사용자별 웹페이지에 접근 할 수 있도록 설정되어 있어야 한다. 그렇지 않다면, 기본 웹서버 위치에 git 프로젝트를 cloning 시켜야 한다)

아래 사이트를 참고하도록 한다.

참고 : 

http://khmirage.tistory.com/309

http://wiki.kldp.org/Translations/html/Git-User-Manual/


2. manifest git 만들기

우선 repo 프로젝트를 만들기 위해서 manifest.xml 이라는 파일을 만들어야 한다. repo 는 manifest.xml 파일을 갖는 git 프로젝트가 있는지를 확인하기 때문이다. 우선 default.xml 파일을 가지는 manifest 라는 프로젝트를 만들도록 한다.

# mkdir manifest

# cd manifest

# git init

# touch default.xml

# git add .

# git commit -a --allow-empty -m "Initial Code Commit"

default.xml 파일 내용은 다음과 같은 형식으로 구성한다. 추가하고 싶은 프로젝트를 <project> 태그 사이에 아래와 같은 형식으로 추가한다. 

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote  name="origin"  : 원격 저장소 이름
           fetch=".."
           review="git://yourserver.com/" /> : 저장소 주소 --> repo upload 에 의해서 review 시스템에 upload 할 gerrit 의 호스트네임 입니다.

  <default revision="master"  : 브랜치명
           remote="origin" />
  <project path="your/path" name="your/path" />

  : path : 로컬에 저장될 path, name: git 저장소 이름
  <project path="your/path2" name="your/path2" />
...

...

</manifest>


3. repo 를 사용하기 전에 git daemon 을 설정해준다. 간단하게 git daemon 명령을 실행해도 되고, 데몬 실행 스크립트에 추가하여 자동으로 실행하게 하도록 해도 된다.

# git daemon --verbose --export-all --base-path=/your/base_path --enable=receive-pack &

--export-all : 이 옵션이 없는 경우 git-daemon-export-ok 파일이 있는 git 프로젝트에 한해서 git 프로토콜을 지원해준다.

--enable=receive-pack : 이 옵션이 없는 경우, 외부에서 push 가 불가능하다.


4. repo init 

위와 같이 manifest git 프로젝트가 만들어지면, repo 를 사용해서 초기화 할 수 있다.

# repo init -u git://yourserver.com/your_manifest_path/manifest

# repo sync

이제 부터 repo 를 사용하 프로젝트 관리가 가능해졌다. 필요한 프로젝트를 manifest 에 추가하면 repo 에서 관리가 가능해진다.


- 출처 : http://pinocc.tistory.com/137

'Programming > Git' 카테고리의 다른 글

Git Slack을 webhooks로 연동  (0) 2018.12.05
git commit 내용을 메일로 보내기  (0) 2016.01.27
GIT에 대한 내용정리  (0) 2015.08.27

How to Use git send-email

The preferred way to send patches is by email, using git send-email (more information about sending patches can be found on the Community page). This page explains how to use git send-email.

Installing send-email

You probably already have git already installed, but that's not necessarily enough to have also the send-email command available. You can check if send-email is available by running "git send-email --help". If it shows the man page for send-email, then send-email is available. Otherwise, you need to install the send-email command. Your distribution probably has a package for it; on Debian the package name is "git-email".

Configuring Your Name and Email Address

You should tell git your name and email address. You have probably done this already, but if not, run these commands:

git config --global user.name "My Name"
git config --global user.email "myemail@example.com"

Configuring the Mail Sending Options

git send-email sends the emails through your SMTP server, so you need to configure the server parameters. Refer to your email provider documentation to find the right parameters. This is how I would configure my mail settings:

git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserver mail.messagingengine.com
git config --global sendemail.smtpuser tanuk@fastmail.fm
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtppass hackme

Storing the password in the git configuration file is obviously a security risk. It's not mandatory to configure the password. If it's not configured, git send-email will ask it every time the command is used.

Configuring the Default Destination Address

For PulseAudio, the patches should be sent to our mailing list. In order to avoid having to remember it and retyping it all the time, you can configure the address to be used by default by git send-email. As you may contribute to many projects using git, it does not make sense to set this option globally so instead we'll only set it in our clone of the PulseAudio code.

git config sendemail.to pulseaudio-discuss@lists.freedesktop.org

Avoiding sending mail to yourself

By default, git send-email will add the author of the patch to the Cc: field. When you send patches that you have written yourself, this means that a copy of each patch will be sent to your email address. If you don't like this, you can avoid this by setting this configuration option (see "git send-email --help" for the full list of possible values):

git config --global sendemail.suppresscc self

Using the send-email Command

See "git send-email --help" for the full reference. I'll go through only the basic usage here.

git send-email will ask a few questions before the patches are sent (update: newer git versions ask fewer questions, sometimes no questions at all). Most of the questions have a sensible default value shown in square brackets. Just press enter to use the default value. Type the answer to the question if you don't want to use the default answer. The questions are:

  • Who should the emails appear to be from?
    • This will be used as the "From" header. You should have configured your name and email address earlier, so the default is usually correct.
  • Who should the emails be sent to?
  • Message-ID to be used as In-Reply-To for the first email?
    • This should usually be left empty. Don't send patches as replies to regular discussion, that makes it harder to keep track of the patches.
  • Send this email?
    • The mail headers are visible above the question, so that you can check that everything looks OK.

Sending a Single Patch

Sending the last commit in the current branch:

git send-email -1

Sending some other commit:

git send-email -1 <commit reference>

Sending Multiple Patches

Sending the last 10 commits in the current branch:

git send-email -10 --cover-letter --annotate

The --cover-letter option creates an extra mail that will be sent before the actual patch mails. You can add write some introduction to the patch set in the cover letter. If you need to explain the patches, be sure to include the explanations also in the commit messages, because the cover letter text won't be recorded in the git history. If you don't think any introduction or explanation is necessary, it's fine to only have the shortlog that is included in the cover letter by default, and only set the "Subject" header to something sensible.

The --annotate option causes an editor to be started for each of the mails, allowing you to edit the mails. The option is always necessary, so that you can edit the cover letter's "Subject" header.

Adding Patch Version Information

By default the patch mails will have "[PATCH]" in the subject (or "[PATCH n/m]", where n is the sequence number of the patch and m is the total number of patches in the patch set). When sending updated versions of patches, the version should be indicated: "[PATCH v2]" or "[PATCH v2 n/m]". To do this, use the -v option (or the --annotate option and edit the "Subject" header of the mails).

Adding Extra Notes to Patch Mails

Sometimes it's convenient to annotate patches with some notes that are not meant to be included in the commit message. For example, one might want to write "I'm not sure if this should be committed yet, because..." in a patch, but the text doesn't make sense in the commit message. Such messages can be written below the three dashes "---" that are in every patch after the commit message. Use the --annotate option with git send-email to be able to edit the mails before they are sent.

Formatting and sending in two steps

Instead of using the --annotate option, one can first run "git format-patch" to create text file(s) (with the -o option to select a directory where the text files are stored). These files can be inspected and edited, and when that is done, one can then use "git send-email" (without the -1 option) to send them.


- 출처 : http://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/

'Programming > Git' 카테고리의 다른 글

Git Slack을 webhooks로 연동  (0) 2018.12.05
repo 를 사용하여 프로젝트 관리하기  (0) 2016.06.15
GIT에 대한 내용정리  (0) 2015.08.27
           http://dogfeet.github.com/articles/2012/progit.html (
 Pro Git 
 
번역)

개념 정리

1. Git의 데이터는 파일 시스템의 Snapshot이라 할 수 있으며, 크기가 아주 작다. Git은 Commit 하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여기며, 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 아래의 그림과 같이 동작한다.


2. Git은 파일을 Commited, Modified, Staged 세가지 상태로 관리한다. 
  - commited : 데이터가 로컬 저장소에 안전하게 저장됐다는 것을 의미함
  - modified : 수정한 파일을 아직 로컬 저장소에 commit하지 않은 것을 의미함
  - staged : 현재 수정한 파일을 곧 Commit할 것이라고 표시한 상태를 의미함.

3. Git은 Git Directory, Working Directory, Staging Area 세가지 영역으로 분리된다. 
  - Git Directory : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다.  (.git)
  - Working Directory : 수정할 파일들이 있는 디렉토리
  - Staging Area : Git Directory에 있으며, 단순한 파일이고 곧 commit할 파일에 대한 정보를 저장한다. 

 

4. Working Directory의 모든 파일은 Tracked와 Untracked로 나뉜다. 
  - Tracked 파일은 이미 Snapshot에 포함돼 있던 파일이며, Unmodified, Modified, Staged 상태중 하나의 상태를 갖는다. 
  - Tracked 파일이 아닌 모든 파일은 Untracked 파일이다.
  - Git의 파일 라이브 사이클은 아래의 그림과 같다. 


5. Git에서 branch는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다. git은 기본적으로 master 브랜치를 만든다.  Git은 최초로 커밋하면 master라는 이름의 브랜치를 만들고, 자동으로 master 브랜치가 가장 마지막 커밋을 가리키게 한다.

6. Git은 HEAD라는 특수한 포인터를 갖고 있다. 이 포인터는 지금 작업하고 있는 로컬 브랜치를 가리킨다. "git branch <brnach명>" 명령은 브랜치를 만들기만 하고 브랜치를 옮기지는 않는다. "git checkout <branch명>"명령으로 HEAD가 가리키는 브랜치로 이동할 수 있다.


7. Git의 commit Data 구조





Git 설치 후 초기 환경 설정 (~/.gitconfig 파일 설정)

1. gitconfig --global user.name dimdim  ==> 작업자 이름 설정

2. gitconfig --global user.email dimdim@test.com  ==> 작업자 email 설정

3. gitconfig --global --list ==> 설정값 확인


GIT 저장소 만드는 방법

1. 이미 존재하는 프로젝트 디렉토리에 git 저장소 생성
   - 
git init 명령은 
"master" 라는 이름을 갖는 local branch를 생성한다. 

$ git init             // CWD에 ".git" 하위 디렉토리 생성
$ git add *         // CWD의 모든 파일 및 하위 디렉토리를 staged 상태로 만든다.
$ git  commit -m 'initail project version'    // stage된 파일을 commit 한다. (commit message가 반드시 필요함!!!)
$ git commit -a -m 'commit message'     // 수정된 Tracked 파일들을 staging 단계 없이 바로 commit 함  


 2. 이미 존재하는 Repository로 부터 복사한다.
   - git clone 명령은 "origin" 이라는 이름을 갖는 remote 와 "master" 라는 이름을 갖는 local branch를 생성한다.
$ git clone  git://githuyb.com/schacon/grit.git   // CWD에 "grit"이라는 디렉토리를 만들고 그 안에 .git 디렉토리를 만든다.
 혹은
$ git clone  git://githuyb.com/schacon/grit.git mygrit // CWD에 "mygrit"이라는 디렉토리를 만들고 그 안에 .git 디렉토리를 만든다. 


Ignore 설정
-".gitignore" 파일 생성 후 ignore 할 파일 목록을 기록 (라인 분리)
- 예제(eclipse 설정파일 무시하기)

/.classpath

/.springBeans

/.project

/target/

/.settings 


용어 정리???

fast forward merge : A 브랜치에서 다른 B 브랜치를 Merge할 때 B가 A 이후의 커밋을 가리키고 있으면 A가 그저 B의 커밋을 가리키게 한다. 이런 머지를 Fast Forward 머지라고 한다.



명령어 정리 

git add [Directory|파일 경로//Untracked 파일을 Tracked 파일로 변경하거나, Tracked&수정된 파일을 staging 한다.
git status  //현재 상태 보기 


git commit -m "commit message"  //로컬 저장소에 commit(저장)

git commit -a -m "commit message"  // staging area 생략 commit (git add 과정 생략)

git commit --amend //수정한 내용이 없으면 커밋 메세지만 변경하고 수정한 내용이 있으면 이전 커밋으로 수정내용을 포함하여 새로운 커밋으로 덮어쓴다.

git rebase -i HEAD~2 // HEAD으로 부터 2개의(HEAD 포함) commit을 합친다.


git rm <filename>  // 파일을 삭제한 후 staged 상태로 만든다. (work directory의 파일도 삭제됨)

git rm --cached <filename> // 해당 파일을 untracked 상태로 변경한다. (work directory의 파일은 그대로 있는다. ignore를 빼먹은 경우 사용)

git mv <origin_file> <target_file> // 히스토리를 유지한 상태로 파일이름을 변경하고, 해당 변경사항이 staged 상태가 된다. 

     ==> "mv <origin_file> <target_file>; git rm <origin_file>; git add <target_file>" 과 동일하다.

git log [-p] -5  [--pretty=online|short|full|fuller]  //commit 로그를 확인한다.(최근 5개의 로그 확인) (-p 옵션은 각 커밋의 diff 결과를 보여준다.)
git log --pretty=format:"%h %s" --graph // 브랜치/머지 히스토리를 아스키 그래프로 보여준다.

git log --stat // 히스토리 통계를 보여준다.


git checkout <commit_id> // 특정 커밋시점으로 되돌린다. 
git checkout <branch명>  //지정된 브랜치가 가리키는 커밋을 HEAD가 가리키게 한다. (작업 디렉토리의 파일은 그대로 유지됨)

git checkout -b <branch명> //새로운 브랜치를 만들고  해당 브랜치를 checkout 한다.

git checkout -b <new branch name> <server branch name> // 서버에서 생성되어 있는 브랜치 가져오기

git checkout  <commit_id> -- <file> // 특정 커밋시점의 특정 파일만 되돌린다.

git checkout -- <file>  // work directory의 변경된 unstaged 파일을 최신 커밋된 내용으로 덮어쓴다. (작업중이던 내용이 있으면 날라가며, 복구 불가!!!)

git checkout -f // 현재 HEAD가 가리키는 커밋으로 작업 디렉토리의 파일을 되돌려 놓는다. (작업중이던 내용이 있으면 날라가며, 복구 불가!!!)

git checkout -f <branch>//  branch가 가리키는 커밋으로 작업 디렉토리의 파일을 되돌려 놓는다. (작업중이던 내용이 있으면 날라가며, 복구 불가!!!)

git reset HEAD <staged_file> // staged file을 unstaged로 변경한다.


git reset HEAD^    // 최종 커밋을 취소. 워킹트리는 보존됨. (커밋은 했으나 push하지 않은 경우 유용)

git reset HEAD~2     //마지막 2개의 커밋을 취소. 워킹트리는 보존됨.

git reset --hard HEAD~2    // 마지막 2개의 커밋을 취소. index 및 워킹트리 모두 원복됨.

git reset --hard ORIG_HEAD    // 머지한 것을 이미 커밋했을 때,  그 커밋을 취소. (잘못된 머지를 이미 커밋한 경우 유용)

git revert HEAD    // HEAD에서 변경한 내역을 취소하는 새로운 커밋 발행(undo commit). (커밋을 이미 push 해버린 경우 유용)


git diff  // work directory와 staged 영역 비교

git diff --cached // staged 영역과 & 저장소 commit 간의 비교 ("git diff --staged" 명령과 동일)


git branch <branch명> //새로운 branch를 만든다

git branch [-a]  //branch 목록을 조회한다.
git branch -m [old_branch] [new_branch]

git branch -d <branch명> //브랜치 삭제

git tag [-l] [v.1.4.*]   //Tag 목록조회 [v1.4 버전들의 목록만 조회]
git tag -a <tag명> -m '[tag message]'  //주석 태그 추가   ex>git tag -a v1.0 -m 'add first release tag'
git tag -s <tag명> -m '[tag message]' //서명된주석 태그 추가
git tag <tag명>  //경량 버전 태그 추가 
git tag -a <tag명> [commit hash]  // 특정 commit의 태그 추가

git show <tag명>
  // 태그정보와 해당 태그의 commit 정보를 확인한다. 

git remote [-v] // 원격 저장소 정보 확인
git remote show <remote명> //리모트 저장소 살펴보기 
git remote add <remote명> <원격저장소URL> //원격 저장소를 추가한다.

git remote rename <old_name> <new_name> //remote repository 이름 변경
git remote rm <remote-name>  //remote repository 삭제 
git fetch [remote명]  //Remote Repository의 최신 변경사항을 Local Respository로 가져옮
git pull [remote명] [branch명]   //remote 저장소 브랜치에서 데이터를 가져와 자동으로 로컬 브랜치와 머지함
git push [remote명] [branch명] //local branch의 내용을 remote 저장소에 push 한다
git push [remote명] [tag명]  //local에 생성한 tag remote 에 추가한다.
git push [remote명] --tags  //local에 존재하는 tag중에 remote에 존재하지 않는 모든 태그들을 push 한다 

git push <remote명> <local branch>:<remote branch> // 내가 최초로 서버에 브랜치 만들기


git merge <from_branch> <to_branch> // from branch를 to branch와 머지한다.

git mergetool // merge할 툴을 실행시켜 준다.


git submodule add <Git Repository URL> <Directory Path>  // Git Submodule 추가

git submodule init  // Git Submodule 초기화 [init -> update]

git submodule update // Git Submodule 소스 코드 받아오기 [init -> update]


git hash-object -w <filename> // 파일을 Git에 저장하고 해쉬코드를 출력한다.

git cat-file -p <hashcode> // 해쉬코드에 해당하는 개체의 내용을 출력한다.

git cat-file -t <hashcode> // 해쉬코드에 해당하는 개체의 타입을 출력한다.

git cat-file -p master^{tree} // master 브랜치가 가리키는 Tree 개체의 내용을 출력한다.


- 출처 : http://dimdim.tistory.com/entry/GIT에-대한-내용정리-정리중

'Programming > Git' 카테고리의 다른 글

Git Slack을 webhooks로 연동  (0) 2018.12.05
repo 를 사용하여 프로젝트 관리하기  (0) 2016.06.15
git commit 내용을 메일로 보내기  (0) 2016.01.27

+ Recent posts