You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: c3_introduction_git_github/m3_working_with_remotes/notes/best_practices_for_collaboration.md
+2-5Lines changed: 2 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,11 +16,8 @@ To make the final merge of the feature branch easier, it makes sense to regularl
16
16
## 1:31 - 1:42
17
17
If you need to maintain more than one version of a project at the same time, it's common practice to have the latest version of the project in the master branch and a stable version of the project on a separate branch.
18
18
19
-
## 2:05 - 2:12
20
-
Rebasing can help a lot with identifying bugs, but use it with caution. Whenever we do a rebase, we're rewriting the history of our branch.
21
-
22
-
## 2:13 - 2:17 - 2:22
23
-
The old commits get replaced with new commits, and they'll have completely different hash sums.
19
+
## 2:05 - 2:12, 2:13 - 2:17 - 2:22
20
+
Rebasing can help a lot with identifying bugs, but use it with caution. Whenever we do a rebase, we're rewriting the history of our branch. The old commits get replaced with new commits, and they'll have completely different hash sums.
24
21
25
22
## 2:31 - 2:42
26
23
So as a general rule, you shouldn't rebase changes that have been pushed to remote repos. The Git server will automatically reject pushes that attempt to rewrite the history of the branch.
0 commit comments