[지옥에서온git] 완강!에 대한 소회와 필기한 강의노트

소회는 아래 링크를 참조해주세요 ㅎㅅㅎ

[git] 'Git From Hell' 완강에 대한 간단한 소회 (tistory.com)

[git] 'Git From Hell' 완강에 대한 간단한 소회

 

---

<밑으론 정리하지 않은 단순 필기입니다>

필요하신 부분이 있다면 ctrl+f로 찾아주시고 모든 필기는 영어로 작성되었다는 점을 미리 말씀드립니다.

 

cd FN : name : move to FN

mkdir : make folder in current directory

ls -al : shows current directory’s file list 

git init : make .git directory

vim FN: i’ll create FN with program vim

• i : insert
• KEY esc : escape
• :wq : write quit

cat FM : want to see whats in FN

git status : look current git status what’s managed

git add FN : make FN managed by git, if there is a temporary file used at testing we doesn’t want to include in version. so we have to always tell git what to save. and color changes red to green

작업이 완결된 상태가 version 

git commit : have to write a message why i changed the version and whats changed 

git log 

 

when i change content of file and enter git status. terminal shows me modified : FN. if i want to change version with this content i have to use git add to add version manage system AND commit

So there is two function in add if there is new file and i want to manage, use add. if there is existing file managed by git use add before commit.

 

cp FN NFN : copy FN and make new file named NFN

 

git makes add to select what to commit and this is different from programs before so what i added means i’ll put it in commit waiting stage

 

git have notion of stage and repository. stage means where file is waiting for commit and repository is where commited file goes.

 

git log -p : --FN means earlier version file +++FN menas later version (show content by version)

git log ADDRESS it shows only version before the address version 

 

git diff ADDRESS1..ADDRESS2 : -content include things in address1 +content include things in address2

git reset ADDRESS - -hard : this makes delete versions after ADDRESS vesion

 

if i uploaded commits online i must not reset!!!! reset command have to work on files only on my computer

 

• git commit -a : commit midified or deleted file automatically
• git commit -am “N” : can name version inline and add at the same time

 

———

 

git points same object even if filename is different. it works like pointer and i suspect this kind of work saves recources

directory of file’s content is made by particular pattern named SHA1(hash) so if i put git add, git see the content of my file. if its ‘a’ it adds up with other information, zip it with SHA1 use it to filename. 

 

the content is stored at objects. link of objects(blob) is combined with file name and stored in index

 

i commit, git make file with parent and tree. tree contains link combined with filename -its kind of list of blob+index. parent contains earlier commited directory which also contains tree. each vesion of commit have different tree. it changes because content of file have changed 

 

object have three forms - blob, tree, commit. blob contains content of each file, tree contain filename and content(blob) which is kind of list of blob+index

index always shows us current status of added file. so we can suspect base on the difference of index and commited tree git tells us to commit 

 

working directory(each files) -> (after adding)index(staging area, cache)->r(after commit) repository(commited objects which contains tree and parent)

—————

 

i’m using master branch(basic branch)

 

git branch - see current branch

git branch N - make branch named N

git checkout N - chenckout basic current branch and enter N branch

if i make new branch new branch copies current branch as it is now

git log - -branches 

most recent commit of master is 8b8, most recent commit of exp is a152, most recent commit of mine is 866 and we are checkin in mine(HEAD->mine)

 

 

git log show us current branches commit

git log - -branches - - decoreate - -graph

 

master 2->6

mine 3->4->5

exp 3->4

git log - -branches - - decoreate - -graph - -oneline

stree - current directory is showed by GUI(sourcetree)

git log N..NN - differnce between N and NN, what NN has and N has not

- git log -p N..NN : diffence between N and NN which include difference of code too.

file f3 is included and its content is ‘a’

[merge exp to master (move exp’s content to master)]

• have to checkout to master and merge
• git checkout master -> git merge exp
• move to branch which we want to make as main branch and merge

exp 2->3->4 

master 2->3->4-> +6

mine 2->3->4->5

git branch -d N : delete N

git checkout -b N : this is shorthand for make branch N and checkout to N

 

first case(fast forward): master merged to hotfix, don’t make different commit, just change address where master is pointing.

second case(resursive) : iss53 merged to master, search common ancestor and create snapshot includes c4,c5 ,difference from fastforward is making new merge commit

if i finish working, didn’t commit and want to checkout the job i was doing in earlier branch effect to current branch which i have checkedout. this case i can use stash

git stash -s : hide the file which is in working area WIP means working in process

git stash -list 

git stash -m

git stash apply : what i had hidden shows again

git stash list

git reset - -hard HEAD : make our woking directory same as resent commit. so it means every status same as recent commit

even if i run reset —hard HEAD and make work directory the same as commit, when i enter stash list the stash exist in the list. stash doesn’t disappear unless i remove directly

 

if i stash one more file and see stash list, the upper one is most recent file. so {0} is most recent always

git stash apply

git stash apply : apply’s most recent stash -> git stash drop : remove most recent stash if i want to apply recent file 0 and apply 1 too. i have to demand apply for file 0 and make if disapear. so file 1 can apply.

git stash pop : git stash apply+git stash drop 

git stash apply to only files which is managed as version(once added)

when i first make git, HEAD file is made automatically. and master file is in HEAD. master file points most recent commit. through this we can know the mechanisom of git. the way git can show us the latest file is through head/ref:masters file. so branch in git means file included in maters

if i delete exp file through rm ./git/refs/heads/exp, we can’t see exp branch in git

if i checkout to exp the head file points ref:exp

 

———

if i merge two branches with same filename with different content it is put together on a single basis

 

—— 

if i reset commit ‘3’ ref:master’s point address is changed. but commit ‘4’ still alives. its in orighead(if we order something dangerous it stores address pointed by HEAD to orighead) and we can search in log/ref:masters. there is all log about what we’ve done. even reset

git reset - -hard ORIG_HEAD : HEAD points address in ORIG_HEAD again

git reflog : see all the logs. it shows us whats in log/ref:master

 

[not that important.. i think..]if we enter git checkout ADDRESS HEAD points commit. normally it points ref:master. but if i enter that command branch is not made but point directly commit

 

	working directory  working tree working copy	index staging area cache	repository history tree
			git reset —soft
		“	git reset —mixed
	“	“	git reset —hard
f1.txt (did commit)	init(text)	init(text)	init(text)
f1.txt (did commit)	repository(text)	repository(text) -which in index	-ref:master>tree> is repository(text)
f1.txt (did added)	index(text)	index(text)	repository(text)
f1.txt (did nothing only modfy)	working copy(text)	index(text)	repository(text)
f1.txt (did reset soft)	working copy(text)	index(text) -used git diff : difference between working copy and index	init(text) -changed to earlier commit used log -p(show diff by commit version) to check repository
f1.txt (did reset soft ORIGHEAD)	working copy(text) used cat to check	index(text)	repository(text)
f1.txt (did reset mixed)	working copy(text)	init(text)	init(text)

 

used git diff : -- means earlier ++means later. i enter index first and working copy last. so index(text) is in index, working copy(text) is in working copy.

if i enter reset! only it automaticlly resets with mixed option ORIG HEAD stores only earlier commited state

———————

 

first one ‘1’ is earlier file. second file is main file. third file is need to be merged file. we can solve this three merge problem (because their is 3files kk) either edit myself or with kdiif3

 

f1backup shows <<<<HEAD >>>>exp f1common shows return common(the base) f1local show return master(the mainbranch) f1remote shows return remote(the merging branch)

 

 

ME	Base	Other	2way merge	3way
A	A		? A:	=>
B	B	B	=>   B	=>  B
1	C	2	? 1:2	? 1:2
	D	D	?  :D	=>

in 3way the content of person who made a correction are reflected

 

—————————

git init - -bare N(name of remote repository) : no working directory, only things in .git, make remote repository, can’t revise

pwd : show address

git remote add  origin ADDRESS(’address of remote repository) : add remote repository in local directory. and origin become a nickname of following address

git remote -v : check its well connected

git remote remove N(origin) : want to delete remote repository

 

push : upload local info to remote repository

if i push this warning shows

 

git push - -set-upstream origin master : use this command and if i push info git push it to origin master

 

—————

git clone ‘https://github.com/git/git.git') N  

git log - -reverse : see reverse

git checkout ADDRESS (commit address) : this is not making the new branch. this temporarily shows the incidence at that commited time

 

—————

 

 

1.make new remote repository and clone it to make local repository. work on local

2.you were already working on local so push it to remote repository

 

git remote add N(nickname) ADDRESS(adress) :add remote repository to current local repository 

git remote : origin repository is made

git remote -v : view details

[once] git push -u NN(origin) N(branch) : connect local branch to remote NN(repository’s) N(branch). -u means if i push it automatically goes to remote

 

usally write origin as the storage that is mainly symchronized

out standard is always my local

 

 

————————

 

git clone ADDRESS .(means current directory)/ N(make the folder of local repository that you wants to connect with git)

git commit - -amend  :revise commit message

ssh-keygen : make ssh passward.. keep enter ‘\n’ until end

—————————

 

fetch, where to take info and from 

 

upstream, the repository which is connect with my local repository

so this means local branch is not connected with remote repository

git push —set-upstream N(name of repository) N(branch name) : set my branch to remote branch (branch name have to be the same

 

——————

difference of git fetch and pull. remote repo and local repo’s pointing commit is different. when i do pull, local download’s remote info and merge!(which is the main essence of difference) remote repo and local repo’s commit is the same which is most recent commit. put when i do fetch my local download’s remote’s info and finish. remote repo is pointing the most recent but local repo doesn’t. the good point of fetch, i can check different of remote repo and local repo. 

git diff HEAD(my current head branch) N(origin/main : reponame/branchnamon) : can see the difference of local commit and remote commit 

 

after fetch we have to merge remote repo’s commit to my local which i have to enter command git merge origin/master

 

———————

git tag N(tag name) : make current(HEAD) commit as version num

git tag N(tag name) ADDRESS : make commit adress as version num

git tag : show tag list

git checkout N(tag name) : see the state of tag commit  

if i want to include more info in tag, have to use annotated tag. no info,only tagging is light weight tag

git tag -a N -m N(ex:azzzz) N(branch) : make annotated tag named azzzz

git tag -v N(tag name): show detailed tag 

git push —tags : push tags toooooo

git tag -d N(tag name) : delete tags

branch and tag is very similar. tag points particular commit and branch point most recent commit id

————

after merge and rebase two of them has same content dfferent is, when merge it’s hard to see history but stable and easy. when rebase history is linear so easy to see history but risky and hard.

 

if i am co-working have to git pull->rebase->push.

 

git rebase N(branch) : the parent commit of rb is commit 1 but i will change it to m1 so rb can accept the concept of master

the patches-difference of code 1 and r1, r1 and2, r2 and r3(parent and child commit)- is stored at temporary storage >> the patches 

 

git log —branches —oneline —all —graph : all shows conflicted rebases

 

—————

 git push origin --delete N

git push --force-with-lease

 

in feature branch its better to merge in develop branch and merge to develop branch later, in develop branch it better not have code same with feature branch. release branch have to push often

 git push origin --delete N

git push --force-with-lease

git push —tags 

 

git tag -d N

git push —tags 

git tag -a N -m N

git tag N(tag name) ADDRESS 

git tag N

 

git diff HEAD(my current head branch).. N(origin/main : reponame/branchnamon)

 

git clone ADDRESS .(means current directory)orN

 

git remote add N ADDRESS

git remote

git remote -v 

[once] git push -u NN(origin) N(branch)

 

git stash apply

git stash pop

git stash -m

git stash -s