总结
算法知识点繁多,企业考察的题目千变万化,面对越来越近的“金九银十”,我给大家准备好了一套比较完善的学习方法,希望能帮助大家在有限的时间里尽可能系统快速的恶补算法,通过高效的学习来提高大家面试中算法模块的通过率。
这一套学习资料既有文字档也有视频,里面不仅仅有关键知识点的整理,还有案例的算法相关部分的讲解,可以帮助大家更好更全面的进行学习,二者搭配起来学习效果会更好。
部分资料展示:
有了这套学习资料,坚持刷题一周,你就会发现自己的算法知识体系有明显的完善,离大厂Offer的距离更加近。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
$ git checkout cat
Switched to branch 'cat'
$ mvim lib/cat.rb
$ git add lib/cat.rb
$ git commit -m "Add initializer"
\[cat a3bce42\] Add initializer
1 files changed, 3 insertions(+), 1 deletions(-)
切到 GUI 來看的話你會發現現在 cat 這支 branch 比 master branch 要在多上兩個 commit 的內容。
如果這時候我們在 master 上繼續開發會發生什麼事呢? 我們現在切換到 master branch 並增加一個檔案及內容,照慣例 add 後 commit。
$ git co master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
$ git add spec/animal\_spec.rb
$ git commit -m "Another spec"
\[master 7d72927\] Another spec
1 files changed, 2 insertions(+), 0 deletions(-)
我在 master branch 的 animal_spec.rb 增加了一些內容,把它 commit 之後我們切換到 GUI 來看。
我們發現現在 master branch 與 cat branch 已經產生分歧了,因為兩支 branch 都有了各自往後開發的 commit ,而且由於 master branch 最後一次的 commit 時間較新因此排列在最前面。
Git rebase 整理現在的 branch
假設我們現在在 cat branch 的開發動作已經完畢,通常我們現在要做的事情會是將 cat branch 合併回 master branch,在開發流程上, master branch 就像是一個主要的 branch ,每個開發人員都是從 master branch checkout 出去一支新的 branch 做開發,在開發完畢後就再將開發完的 branch 合併回 master branch,因此 master branch 都會保有最新的開發好的狀態,一般在 Git 教學中會教你現在使用 git merge
這個指令來將兩個 branch 合併,但這邊我要先教你的是 git rebase
這個指令。
與 git merge
不同的是, git rebase
不單單只是將兩個不同的 branch 合併起來,而是將某一支 branch 基於另一支 branch 的內容合併起來,這是什麼意思? 以我們的例子來說,我們在 cat branch 開發完了以後,這時候我們的 master branch 也有了其他開發者所合併回去的內容,換句話說現在的 master branch 與我們當初 checkout 出去的時候的狀態已經不同了,但我們會希望我們現在這支 cat branch 的內容就像是剛剛從 master branch checkout出來一樣乾淨,也就是說讓 cat branch 中保有 master branch 最新的狀態, git rebase
會基於 master branch 目前最後一次的 commit 內容再往後把你在 cat branch 上commit 的內容加上去,我們現在在 cat branch 輸入 git rebase master
來將 cat branch 基於 master branch 做 rebase。
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Add Cat.rb
Applying: Add initializer
過程中沒有發生衝突,這時候我們到 GUI 看看現在的結果。
原先 cat branch 上的兩個 commit (Add Cat.rb 和 Add initializer) 已經合併到 master branch 最新的 commit (Another spec),換句話說目前 cat branch 的內容就像是剛從 master branch 所 checkout 出來然後再加上自己的 commit,因此不同於 git merge
的線圖會把 cat branch 合併到 master branch , 而是把原本的 cat branch 接到 master branch 因此只有一條線,當一個專案有很多的 branch 再做開發的時候會避免很多 branch 的線接來接去難以辨認。
開發過程中,若你在開發的 branch 功能比較多, commit 的量也比較多時,建議使用rebase將你現在的 branch 整理過再合併回主幹,這樣會產生較漂亮的線圖
若你想要看看目前的 branch 與其他 branch 有哪些差異,你可以使用 git diff
的指令去觀察,例如我現在想要看 master 跟 cat 這兩個 branch 的差異,我只要下:
$ git diff cat master
diff --git a/lib/cat.rb b/lib/cat.rb
deleted file mode 100644
index 1227d26..0000000
--- a/lib/cat.rb
+++ /dev/null
@@ -1,5 +0,0 @@
-class Cat < Animal
- def initialize
- super
- end
-end
你就可以看到現在的 cat branch 跟 master branch 的差異在哪了。
如果我們開發完畢時,我們會把開發好的東西合併回 master 很自然的我們通常都會使用 git merge
這個指令來合併兩個branch
$ git merge cat
Merge made by recursive.
lib/cat.rb | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 lib/cat.rb
這時候我們看圖的話會是這樣:
可以看到我剛剛在 master branch 下了 git merge cat
這個指令來告訴 git 要 merge cat 到現在所在的 branch ,因此在圖上就看到了 cat branch 拉一條線回來合併到了 master 這個 branch 了,解釋這張圖的意思就是, cat branch 從 master branch 的 Another spec 這一次的 commit 分支出來後,自己產生了三次的 commit (Add Cat.rb、Add initializer、Rever “Add initializer”) 然後合併到 master。
Confict: 處理 Git 合併時的衝突:
很常發生的情況是再 merge 或是 rebase 的圖中產生了 convict (衝突),這時候 Git 會停下來請你去處理,例如我們在 cat 和 master 的 branch 都對 lib/cat.rb 這支檔案做編輯,然後我們將他們 merge:
$ git merge cat
Auto-merging lib/cat.rb
CONFLICT (content): Merge conflict in lib/cat.rb
Automatic merge failed; fix conflicts and then commit the result.
你會看到 Git 告訴你在你合併的過程中在 lib/cat.rb 這支檔案發生了衝突,Git 不知道該怎麼處理因此要你去處理它,這時候我們打開這支檔案會看到這樣的情況:
<<<<<<<<<< HEAD 到 ========== 的中間區域是目前你所在 branch 的 commit 內容,而從 =========== 到 >>>>>>>>>>> cat 則是你要合併的 cat branch 的內容,你必須做出決定看是要兩個都留下,或是選一個,或是改成你想要的內容,改好後記得要將 Git 自動產生的 <<< 、 =====、 <<< 的內容都刪除,修改完畢後存檔,將剛剛修改過的檔案再使用 git add
加入 stage ,將所有的衝突都修正完畢後就使用 git commit
提交一次 commit,由於這次的 commit 是在處理 merge 時的衝突,因此 Git 很聰明的已經幫我們加上了一些預設的訊息 “Merge branch ‘cat’”, commit 提交後就會看到合併成功的訊息了。
$ git add lib/cat.rb
$ git commit
\[master c37c9e3\] Merge branch 'cat'
發生 confict 時的處理步驟
-
將發生 confict 的檔案打開,處理內容( 別忘了刪除<<<、===、>>> )。
-
使用
git add
將處理好的檔案加入 stage。 -
反覆步驟 1~2 直到所有 confict 處理完畢。
-
git commit
提交合併訊息。 -
完成
講到這裡我們再來整理一下工作流程,讓大家再複習一下 git 的使用:
-
在專案中會有一條主 branch 是大家將開發好或是修好的東西合併回去的對象,所有要開發的新功能或是修 bug 都是從主 branch 拉出一條新的 branch 去工作。
-
當你完成一個階段性的任務時,將你剛剛 所新增的內容使用
git add
加入到 stage 的狀態,並且使用git commit
加上 commit 的訊息來提交一次的 commit。 -
反覆動作 2 直到你完成這支 branch 的主要目的(新功能/修 bug ),若這時你離主 branch 已經有一段時間,或是確定主 branch 上已經有新的 commit ,使用
git rebase
將自己的分支整理然後使用git merge
合併回主 branch,反之則是直接使用git merge
將自己 branch 的內容合併回去。
Git reset 取消上一次的操作
取消 merge
版本控制最大的好處之一就是讓你永遠可以後悔,因此我們常會希望把已暫存的檔案、已提交的 commit 或是已合併的 branch 取消修改,這時候我們可以使用 git reset
這個指令來幫助我們,像現在我若是想要取消剛剛的 merge 動作,我只要下:
$ git reset --hard ORIG\_HEAD
HEAD is now at c126ff9 Config initialze
這時候再回去看圖你會發現已經回到合併前的樣子了:
取消已暫存的檔案
有時候手殘不小心將還沒修改完的檔案使用 git add
加入了 stage ,這時候可以使用 git reset HEAD <file>
來將這支檔案取消 stage:
你可以看到我使用 git add
將檔案加入 stage 後,在我的 status 狀態顯示 lib/cat.rb 這支檔案現在已經準備好被 commit ,但這時我使用了 git reset HEAD
將這支檔案取消 stage,再使用 status 查看時它就變回一支還沒加入 stage 的檔案了。
取消修改過的檔案
学习路线+知识梳理
花了很长时间,就为了整理这张详细的知识路线脑图。当然由于时间有限、能力也都有限,毕竟嵌入式全体系实在太庞大了,包括我那做嵌入式的同学,也不可能什么都懂,有些东西可能没覆盖到,不足之处,还希望小伙伴们一起交流补充,一起完善进步。
这次就分享到这里吧,下篇见。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
这张详细的知识路线脑图。当然由于时间有限、能力也都有限,毕竟嵌入式全体系实在太庞大了,包括我那做嵌入式的同学,也不可能什么都懂,有些东西可能没覆盖到,不足之处,还希望小伙伴们一起交流补充,一起完善进步。
这次就分享到这里吧,下篇见。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!