-
Notifications
You must be signed in to change notification settings - Fork 0
/
docs.txt
245 lines (201 loc) · 15 KB
/
docs.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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
1. What is Git?
Git is a version control system
=> Records changes made to our code overtime and store them in a repository.
* Centralized: all team members are connected to a single center server
* Distributed: every team member has a copy of the project
2. Using Git:
-> Command line
-> Code Editer
-> Graphical user interfaces
3. Creating Snapshots:
git init ==> Initialize a repository
rm .git ==> Remove .git file (losing project history)
git add ... ==> Add files to the staging area
(We review our changes, if everything is good)
git commit -m "MESAGE..." ==> Take a snapshot of our code and store it in the repository
(after committing the changes, the staging area contains the same snapshot in our repository)
git commit -am "Message..." ==> Skipping staging area
git ls-files ==> Get all files in the staging area
rm fileName ==> Removes fileName only from working directory (not a git command)
git rm fileName ==> Removes fileName from both working directory and staging area
git mv fileName newFileName ==> Rename a file in one go (deletion & adding)
git rm --cached logss/ ==> Remove logss folder from staging area
git status ==> Show the status of the project
git status -s ==> Show short statuses in two colomns (staging area | working directory)
M: Modified
A: Added
?: Untracked
git diff --staged ==> View staged changes
git diff ==> Compares working directory with staging area (unstaged changes)
git difftool ==> Compares working directory with staging area in VSCode
git log ==> Show commits from latest to oldest
git log --oneline ==> Short description of the commits
git log --oneline --reverse ==> Short description of the commits from oldest
git show ... ==> Shows a specific commit details
(here we specify the commit identifier or we use the HEAD pointer)
git ls-tree ... ==> Shows files & folders in a commit
(here we specify the commit identifier or we use the HEAD pointer)
git restore --staged fileName ==> Restore changes from staging area to working directory
(when restoring, git takes a snapshot from the last commit and put it in the staging area)
git restore ... ==> Undo local changes
(git takes a snapshot of these files in the staging area and put them in our working directory)
git clean -fd ==> Undo local changes (for untracked files)
git restore --source=HEAD~1 fileName ==> Restore fileName from a specific commit
*** Git Objects:
-> Commits
-> Blobs (files)
-> Trees (directories)
-> Tags
4. Browsing History:
git log --stat ==> Shows details of the commits with number of insertions & deletions for each one
git log --patch ==> Shows details of the commits line by line
git log -3 ==> View last 3 commits
git log --author="name" ==> Filter commits by name
git log --after="date" ==> Filter commits by date (after, before)
git log --grep="word" ==> Filter commits by the words message
git log --pretty=format:"" ==> Format log output
-> %an = author name
-> %H = commit hash
-> %h = abbreviated commit hash
-> %cd = commit date
git config --global alias.name "log --pretty=format:''" ==> Create custom console logs / actions...
git diff HEAD~2 HEAD ==> Get changes between these two commits
git blame fileName ==> View who made changes to fileName
HEAD -> master -> last commit -> before last commit -> ... -> first commit
git checkout (identifier) ==> HEAD now points to (indentifier). In our working directory, we have a copy of this commit (identifier)
git checkout (identifier) fileName ==> Restore fileName from the commit (identifier)
(detached HEAD state HEAD detached from master, in this situation we should not create new commits, only view the code)
git checkout master ==> Return HEAD -> master
git tag tagName (identifier) ==> Create bookmarks (lightweight tags)
git tag -a tagName -m "Message..." ==> Create bookmarks (annotated tag)
git tag ==> View created tags
git tag -n ==> View created tags with their messages
--> We must provide a message for annotated Tags
--> The message for lightweight tags is the message of the commit it points to
git tag -d tagName ==> Delete a tag
5. Branching:
-> Our main workspace is the master, branching allows us to create isolated workspaces. After testing, we merge the new workspace with the master.
-> Creating a branch is just creating another pointer to the last commit.
-> HEAD pointer points to the current branch where we're working right now.
git branch branchName ==> Create a new branch
git branch ==> Shows our list of branches
git switch branchName ==> Switch to branchName (HEAD now points to last commit in branchName)
git branch -m branchName newBranchName ==> Rename a branch
git branch -d branchName ==> Delete a branch after merging
git branch -D branchName ==> Force the deletion of branchName
git log master..branchName ==> Compare branchName with master branch and show the commits in branchName that aren't in master branch.
git diff master..branchName ==> Compare and show actual changes
(if you are in master branch, dont specify master.., use branchName directly)
git stash push -m "Message..." ==> Save changes in a safe place so we can switch branches
git stash push -am "Message..." ==> Save all changes
git stash list ==> Show stashes list
git stash show (identifier) ==> Show the details of a specific stash
git stash apply (identifier) ==> Apply the changes in stash (identifier)
git stash drop (identifier) ==> Delete stash (identifier)
git stash clear ==> Delete all stashes
-> Merging is bringing changes from one branch to another
* Fast-forward merges (if branches have not diverged):
After creating a new branch and apply the changes, master pointer is left behind. Fast-forward merges works by moving the master pointer forward to the new branch position.
* 3-way merges (if branches have diverged):
master contains some changes that are not in the new branch (they are diverged).
Git creates a commit (merge commit) that combines the changes for these two branches.
3-way merges ==> 1 commit before code changes, the 2 tips of our branches after code changes
git merge branchName ==> Merge branchName with master branch (run in master)
git switch -C branchName ==> Create a branch and switch to it
git merge --no-ff branchName ==> Merge branchName not using fast-forward merges
git config ff no ==> Disable fast-forward merges for this repository.
git branch --merged ==> Show merged branches
git branch --no-merged ==> Show unmerged branches
*** Conflicts:
- Same code changes in different ways in two branches
- Change in one branch, Delete in other one
- Same file added twice in different branches, but different content
git merge --abort ==> Abort merging, go back to state before start merge process
git reset --hard HEAD~2 ==> Undo faulty merges (Only if the history is not shared with others)
* hard: working directory, staging area and last snapshot are all affected
* mixed: working directory is not affected, only staging area and last snapshot
* soft: working directory and staging area are not affected, only last snapshot
git revert -m 1(first parent) HEAD ==> Revert a commit (if the history is shared)
git merge --squash branchName ==> Squash merge
git rebase master ==> Change the base of a new branch to the latest commit in master branch
- master and the new branch are diverged
- Rebasing rewrites history
- Used only in local repositories
*** Conflicts when Rebasing:
git rebase --continue ==> Continue the rebase process
git rebase --skip ==> Skip current commit and move to the next one
git rebase --abort ==> Abort the rebase process
git cherry-pick (identifier) ==> Apply a specific commit from certain branch to the master branch
git restore --source=branchName -- fileName ==> Restore fileName in our directory from its latest version in the branchName
6. Collaboration:
*) Workflows: (How to synchronize our working directory with each other)
<-> In Centralized Workflow (often for private projects), every dev has a copy of the repository.
-> And there is also a central repository that they use to synchronize their work.
-> This central repo could be in a private server or in the cloud (Github, Gitlab...).
-> So, to collaboration with others, we start by cloning the central repo.
<-> Integration Manager (often for open-source projects):
-> In an open-source project, we have 1 or more maintainers and a lot of contributors.
-> 1) To contribute on a project, first fork the project (make a copy in the cloud (so a maintainer can review it))
-> 2) Clone this repo and make your changes
-> 3) Push changes to the forked repo
-> 4) Send a pull request to a maintainer
-> 5) A maintainer pull our changes and review them
-> 6) If its good, they merge the changes into their local repo
-> 7) And then they push the changes to the official repo
*) Cloning a repo:
git clone repo_url ==> Clone the repo_url repository
origin ==> When we clone a repo, git names the source repo origin
origin/master (remote tracking branch) ==> git tells us where is the master branch in the origin repo
origin/HEAD ==> git tells us where is the HEAD pointer in the origin repo
git remote ==> Show the list of remote repositories
git remote -v ==> v for verbose -> gives us the url that git uses when we talk to this remote repo
git remote set-url origin https://github.com/Choaib-ELMADI/getting-started-with-git.git ==> Update a repo's name
*) Fetching:
git fetch repo(origin) branch(optional) ==> Fetch the changes from the origin repo (not merged)
git branch -vv ==> Show how our local and remote tracking branch are diverging
git merge origin/master ==> Merge the origin repo changes with our local branch
git pull ==> pull = fetch + merge (using merge commit)
git pull --rebase ==> pull = fetch + merge using Rebasing (git is gonna rebase master on top of origin/master)
*) Pushing:
git push origin branchToPush ==> Push the local changes to the origin repo
git push origin tagName ==> Push a tag to the origin repo
git push origin --delete tagName ==> Remove a tag from the origin repo (tag still available in local repo, just delete it if you dont need it)
*) Releases:
- Releases are a Github feature
- When we create a release, Github addes it to the last commit as a tag
*) Sharing branches:
- When we create a new branch, we can't directly push it to origin
git branch -r ==> Show all the remote tracking branches
git push -u origin newBranchName ==> Link the new branch to a branch in origin (use this only in the first time --> git push)
git push -d origin newBranchName ==> Delete the newBranchName, after completion (newBranchName is not deleted from our directory)
*) Collaboration workflow:
git switch -C newBranchName origin/branchToMapToInGithub ==> Create (& switch to) a private branch that maps to an already existing branch in origin
git push -d origin newBranchName ==> Remove the branch from origin as well as its remote tracking branch in my local repo (still need to delete the local branch)
git remote prune origin ==> Remove the tracking branches that aren't under remote
*) Pull requests:
- With pull requests, we open a discussion with team members
1) Create a new branch and make your changes
2) Push the new branch
3) In Github, create a new pull request
4) Create a pull request
5) Add reviewers (sends an email to a reviewer to review our changes)
6) Reviewer gets the email and start the review then finish it
7) Make other changes and push them
8) In Github, request a reviewer again
9) Reviewer reviews the new changes and submit them
10) Merge pull request
11) Delete branch after merging
12) In your local machine, pull the changes from origin, delete tracking branches that aren't under remote and delete the new created branch
*) Resolve conflicts:
*) Issues:
- Issues are a Github feature
- To track the progress of verious issues, we use Milestones
*) Keeping a forked repo up to date:
- The forked repo is not connected to the base repo. So, from times to times, it can get out of sync with the base repo.
- In our machine, the local repo has a reference to the forked repo, we add another one to the base repo
git remote add newRefToBaseName(upstream, base) base_repo_url ==> Add another reference to the base repo so we can pull the changes and push them to the forked repo
git remote rename oldName newName ==> Rename a remote repo
git remote rm remoteRepoName ==> Delete a remote repo
7. Rewriting History:
* Dont rewrite public history
* Dont rewrite public history