IM 2일차

Gong Intaek·2021년 2월 23일
0

코드스테이츠

목록 보기
40/151
post-thumbnail

TIL

Git

DESCRIPTION
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.

See gittutorial[7] to get started, then see giteveryday[7] for a useful minimum set of commands. The Git User’s Manual has a more in-depth introduction.

After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about individual Git commands with "git help command". gitcli[7] manual page gives you an overview of the command-line command syntax.

A formatted and hyperlinked copy of the latest Git documentation can be viewed at https://git.github.io/htmldocs/git.html or https://git-scm.com/docs.

  • Git documentation 속의 git 명령어의 DESCRIPTION 에서 발췌. 개인적으로는 그저 프로그램 개발시 코드의 관리를 용이 하게 해주는 관리 프로그램 정도라는 인식이 현재 내가 가진 git 에 가진 인식의 전부이다.

remote

DESCRIPTION
Manage the set of repositories ("remotes") whose branches you track.

  • 주로 원격에 대한 정보 확인으로만 사용하였음. 이번에 스프린트를 진행하면서 추가적인 주소를 설정하고 자료를 가져오는 연습을 수행해봄.

checkout

DESCRIPTION
Updates files in the working tree to match the version in the index or the specified tree. If no pathspec was given, git checkout will also update HEAD to set the specified branch as the current branch.

  • 새로운 branch 형성후 이동 생성되어 있는 branch 이동시에만 활용. 이번 스프린트에서도 사용해본정도로만 활용.

branch

DESCRIPTION
If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. Any branches checked out in linked worktrees will be highlighted in cyan and marked with a plus sign. Option -r causes the remote-tracking branches to be listed, and option -a shows both local and remote branches.

If a <pattern> is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if it matches any of the patterns.

Note that when providing a <pattern>, you must use --list; otherwise the command may be interpreted as branch creation.

With --contains, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the named commit), --no-contains inverts it. With --merged, only branches merged into the named commit (i.e. the branches whose tip commits are reachable from the named commit) will be listed. With --no-merged only branches not merged into the named commit will be listed. If the <commit> argument is missing it defaults to HEAD (i.e. the tip of the current branch).

The command’s second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given. As a special case, for <start-point>, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.

Note that this will create the new branch, but it will not switch the working tree to it; use "git switch <newbranch>" to switch to the new branch.

When a local branch is started off a remote-tracking branch, Git sets up the branch (specifically the branch.<name>.remote and branch.<name>.merge configuration entries) so that git pull will appropriately merge from the remote-tracking branch. This behavior may be changed via the global branch.autoSetupMerge configuration flag. That setting can be overridden by using the --track and --no-track options, and changed later using git branch --set-upstream-to.

With a -m or -M option, <oldbranch> will be renamed to <newbranch>. If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming. If <newbranch> exists, -M must be used to force the rename to happen.

The -c and -C options have the exact same semantics as -m and -M, except instead of the branch being renamed it along with its config and reflog will be copied to a new name.

With a -d or -D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently has a reflog then the reflog will also be deleted.

Use -r together with -d to delete remote-tracking branches. Note, that it only makes sense to delete remote-tracking branches if they no longer exist in the remote repository or if git fetch was configured not to fetch them again. See also the prune subcommand of git-remote[1] for a way to clean up all obsolete remote-tracking branches.

  • 생각 이상으로 이부분에 해당하는 명령이 상세한 듯하다 설명의 양이 확 증가하였다. 하지만 현재 나는 만들어진 branch 의 삭제를 맡고있는 -d 옵션만 사용해본터라 세세한 설명은 아직 잘 모르겟다.

merge

DESCRIPTION
Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch. This command is used by git pull to incorporate changes from another repository and can be used by hand to merge changes from one branch into another.

Assume the following history exists and the current branch is "master":

Then "git merge topic" will replay the changes made on the topic branch since it diverged from master (i.e., E) until its current commit (C) on top of master, and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes.

The second syntax ("git merge --abort") can only be run after the merge has resulted in conflicts. git merge --abort will abort the merge process and try to reconstruct the pre-merge state. However, if there were uncommitted changes when the merge started (and especially if those changes were further modified after the merge was started), git merge --abort will in some cases be unable to reconstruct the original (pre-merge) changes. Therefore:

Warning: Running git merge with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict.

The third syntax ("git merge --continue") can only be run after the merge has resulted in conflicts.

  • check으로 나누었던 내용을 본래 가지에 합칠때 사용 사용뒤 병합하려던 가지는 남아있으므로 필요없는 가지의 삭제는 별도로 진행해야함.

git-workflow

  • 오늘 진행한 스프린트의 주요 내용 이후다른 스프린트 진행시 깃을 활용한 작업이 어떻게 진행될것인지 아주 간단하게 예습 작성된 내용의 충동상황에 따른 대처방법을 연습

오늘 한 일

  • git-workflow 수행
  • 30 분 산책

오늘은...

깃을 활용한 workflow sprint만 진행 많은 시행착오를 예상한것인지 널널하게 주었다 페어분과는 빠르게 끝내버렸고 남은 시간은 개인 자습으로 활용하는것으로 하였으나 나의경우는 그저 휴식 시간이 되어버렸다. 딱히 하는것없이 스프린트 리뷰 시간까지 되었고 리뷰 시간 마치고 30분좀 넘은 간단한 산책 이후 다시 자리를 잡았으나 딱히 공부 하지는 않고 깃이나 훝어 봄.

profile
개발자가 되기위해 공부중

0개의 댓글