-
Notifications
You must be signed in to change notification settings - Fork 0
/
git_basics.txt
158 lines (105 loc) · 6.55 KB
/
git_basics.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
an SSH key is a secure identifier used to identify your machine, and its used to upload your rep
without having to enter UN and pass every time
an SSH key for you machine can be created using
ssh-keygen -t ed25519
enter the pass if you want to for it
SSH uses assymetric encryption where a public and private key is generated for both of the users
sharing the message, the key is generated using RSA algo and these keys are mathematically linked
So what happens is that user 1 uses the public key of user 2 to encrypt the message and then
user 2 uses his private key to decrypt it, the same goes other way around too. Just that initially
both users must exhange their public keys
git is nothing but a version control system, there are local, centralised and distributed VCS
where git is a DVCS as any developer has a full copy of the file system and any developer can
merge his file system into the main branch.
git thinks about data in different versions as snapshots not differences, which were the case
with other VCS, and all of this is local
in git, the file can exist in 3 states: modified, staged, committed
modified means that changes have been made to the file but they have not been committed in the database
yet
staged means that we have marked a modified file to go into the next commit snapshot
committed means that the staged file has been stored in the database
corresponding to this we get three main sections of a git project: working tree, staging area,
git directory
The working tree is where a single copy of a version of the project is pulled from the database
to be worked with and made changes to, the working tree is in the local disc
The staging area is where info is contained about what will go into your next commit, the staging
area is in the git directory itself
the git directory is where git stores metadata and obj database for your project
the repository is the special database that actually stores all the changes
the thing with git is that its local and all we can do is modify, bring it to stage and commit the
change to the one and only branch we have, but with github, which is an online platform, we can do
the same across various users and computers, where we can create a branch of the main one and
do they stuff with git that we would do and when we are satisfied, can merge this branch to the
main one. The process of creating a branch is called "pulling" from the main branch
dont confuse pulling with pull request, where pull request is a github feature which allows the
moderators of the main branch to see what changes you have made to your local branch and also
lets them decide if they want to allow you to push this local branch of yours to the main or no
to clone a repository from github(essentially make your own local branch) type in
git clone [email protected]:USER-NAME/REPOSITORY-NAME.git
where [email protected]:USER-NAME/REPOSITORY-NAME.git is the ssh url of that repo
the rep it has been clones from is the main branch also known as remote rep, which is generally
referred to as origin
git add file: will add that file to staging area
git status: gives the status of all the files under the local branch
git log: gives the log of all the commits that happened within the local branch, to exit this
window, press "q"
git push origin main: pushes the local branch to the main one
any basic git syntax is program | action | destination
git commit -m "message" to commit something to the local branch
a good commit message has a subject and a body(all limited to 72 chars)
in the body of the commit message, explain the why and what instead of the how
git log --oneline just shows the subject line of the commits
git shortlog gives the log based on the users who made commits to the current branch
git log --graph --oneline --decorate is used to give a beautified version of the log
make sure to write *subject* of the commit in imperative statements, ie statements that convey instructions
directly, for egs, instead of writing
added fluid functionality
write
add fluid functionality
make it seem as if you are giving instructions to do something, and that conveys the change better
the commit subject should answer the question
if applied, the commit will , [subject]
when writing the body, more descriptive words can be used
in general the commit messages should look like:
<type>[optional scope]: <subject description>
[optional body]
[optional footer for metadata]
<type> can be "fix" for bugs or "feats" to add features
if we ever want to detach a folder from git, we need to remove the .git file which tracks all
whats happening in that folder, to do so, simply do
rm -rf .git
-r is recursive since rm removes a file and .git is a folder so all files from the folder
needs to be removed, -f is force option, these two options are combined to make -rf
to go back to a certain state of the project, we use
git checkout [hash code of that version]
this takes us back to the prev version, but in a diff branch wrt the current working one
say if we have a folder on our desktop that we want to make a repo of, so we need to have a .git
folder in it which can track all of the versions of the project in the folder, so we do
git init
then to add a README.md to it
git add README.md
then since README.md is in the staging area along with other files in the folder, we commit to the same branch
git commit -m "message"
then we get a remote connection to the origin
git remote add origin [your github url/repo_name.git]
this way we start a remote connection to repo_name.git repo
then to push this branch that we have been working with to the origin
git push origin main
to make a new branch
git checkout -b "branch_name"
when we do this we automatically go to the new branch made
to go to some other branch
git checkout "branch_name"
we can check out all the branches available and which we are at by the * to the left of that branch's
name
git branch
here we can do whatever changes we want to do, then merge it to main
git push origin main
(given they have established the remote origin connection to the repo they want to push to)
then they write a pull request on github explaining what they have done differently on their
branch and I controlling the main branch can review it and decide whether or not to merge the pull
request to the main branch or no
this pull request acceptance into the main branch is done in github "up", so to make sure
that the change also reflects locally in the computer, we say
git pull origin main
now the pull request changes also are shown locally in the computer