程序員git考試題目

❶ 程序員必備知識有哪些

根據軟考程序員職稱的考試內容，我們可以得出，程序員需要具備以下的知識。但這些只是基礎，還要不斷擴展。
計算機硬體基礎知識。
1. 計算機科學基礎。
1.1數制及其轉換。
二進制、十進制和十六進制等常用數制及其相互轉換。
1.2數據的表示。
數的表示（原碼、反碼、補碼表示，整數和實數的機內表示方法，精度和溢出）。
校驗方法和校驗碼（奇偶校驗碼、海明校驗碼）。
1.3算術運算和邏輯運算。
計算機中二進制數的運算方法。
邏輯代數的基本運算和邏輯表達式的化簡。
1.5常用數據結構。
數組（表態數組、動態數組）、線性表、鏈表（單向鏈表、雙向鏈表、循環鏈表）、隊列、棧、樹（二叉樹、查找樹）、圖的定義、存儲和操作
1.6 常用演算法。
演算法與數據結構的關系，演算法效率，演算法設計，演算法描述（流程圖、偽代碼、決策表）
2. 計算機系統基礎知識。
2.1計算機基礎知識。
2.1.1計算機系統的組成，硬體系統、軟體系統及層次結構。
2.1.3 中央處理器CPU。
運算器和控制器的組成，常用的寄存器、指令系統、定址方式、指令執行控
處理機性能。
2.1.4 主存和輔存。
存儲器系統。
存儲介質（半導體、硬碟、光碟、快閃記憶體、軟盤、磁帶等）。
主存儲器的組成、性能及基本原理。
Cache的概念、虛擬存儲的概念。
輔存設備的類型、特性、性能和容量計算。
2.1.5 I/O介面、I/O設備和通信設備。
I/O介面（匯流排、DMA、通道、SCSI、並行口、RS232C、USB、IEEE1394）。
I/O設備的類型和特性（鍵盤、滑鼠、顯示器、列印機、掃描儀、攝像頭，以及各種輔存設備）。
I/O設備控制方式（中斷控制、DMA）。
通信設備的類型和特性（Modem、集線器、交換機、中繼器、路由器、網橋、網關）及其連接方法和連接介質（串列連接、並行連接，傳輸介質的類型和特性）。
2.2 軟體基礎知識。
2.2.1 操作系統基礎知識。
操作系統的類型和功能。
操作系統的內核（中斷控制）和進程概念。
處理機管理、存儲管理、設備管理、文件管理、作業管理、漢字處理。
2.2.2 程序設計語言和語言處理程序基礎知識。
匯編、編譯、解釋系統的基礎知識。
過程（函數）調用。
2.3 網路基礎知識。
網路的功能、分類、組成和拓撲結構。
網路體系結構與協議（OSI/RM，TCP/IP）。
2.4 資料庫基礎知識。
數據模型，ER圖。
數據操作（關系運算）。
資料庫語言（SQL）。
2.5 多媒體基礎知識。
多媒體基礎概念，常用多媒體設備性能特徵，常用多媒體文件格式類型。
3．軟體開發和運行維護基礎知識。
3.2 軟體需求分析、需求定義及軟體基礎知識。
結構化分析概念（數據流圖（DFD）、實體關系圖（ER））。
面向對象設計、結構化設計基礎知識。
模擬設計、代碼設計、人機界面設計要點。
3.3 程序設計基礎知識。
結構設計程序設計，程序流程圖，NS圖，PAD圖。
程序設計風格。
面向對象設計基礎知識、可視化程序設計基礎知識。
3.4 程序測試基礎知識。
黑盒測試、白盒測試、灰盒測試基礎知識。
4． 安全性基礎知識。
安全性基本概念。
加密與解密基礎知識。
5． 標准化基礎知識
標准化基本概念
6． 信息化基本知識。
有關的法律、法規要點。
7． 計算機專業英語。
考試科目2：程序設計。
1. 內部設計
1.1 理解外部設計。
1.3 物理數據設計。
確定數據組織方式、存儲介質，設計記錄格式和處理方式。
2． 程序設計。
2.1 模擬劃分（原則、方法、標准）。
3． 程序實現。
3.1 編程。
編程方法和標准。
程序設計語言的使用。
4.程序設計語言（C語言為必選，其他語言可以任選一種）。
4.1 C程序設計語言（ANSI C標准）。
程序結構，語法，數據類型說明，可執行語句，函數調用，標准庫函數，指針。
4.2C＋＋程序設計語言（ANSI C＋＋標准）。
C＋＋和面向對象程序設計，語法和程序結構，類、成員、構造函數、析構函數、模板、繼承、多態。
4.3java程序設計（Java 2）。
語言機制（程序結構和語法，類、成員、構造函數、析構函數、繼承、介面）。
4.4Visual Basic程序設計（Visual Basic 6.0）。
用戶界面設計。

❷ 如何用5個問題考察一個java程序員的水平

可以的，但想更快地進步，在Java熟練的情況下，可以考慮掌握下面知識。
若開發基於 Web 的應用，下面這些內容應該熟練掌握：
Web 相關技術，比如 HTML、CSS、Javascript、jQuery
JSP/Servlets
Web 框架，比如 SSH 三大框架、myBatis
XML 和 JSON
Web 伺服器，比如 Tomcat
Web 應用伺服器，WebLogic、WebSphere
一些基本庫，比如 Java mail、log4j 等
Java 程序員都應該掌握的資料庫技術：
SQL 查詢語句：Inner Outer Joins、Group by、Having
存儲過程
觸發器
游標
資料庫驅動（JDBC）
一些工具和思想方法：
開發工具：比如 Eclipse、MyEclipse、IntelliJ IDEA
版本管理工具，比如 SVN、Git
測試：單元測試、jUnit
需求分析
版本管理

❸ 程序員需要具備哪些知識

1、程序員需要學會主動學習，要懂得懂得不斷精進自己的專業技能。
2、程序員需要具有個人品牌意識，要學會自我營銷，在業界打造自己的個人品牌。
3、程序員重視單元測試，專業的程序員需要知道單元測試的重要性，會把測試代碼和產品代碼看的一樣重要。
4、程序員要善於管理時間。尊重對方的時間。只召集那些必要的同事參加會議，並且會在會議前整理好會議的主題和議程。
5、程序員要善於管理精力。專業的程序員能夠讓自己精力充沛地投入到工作中。
6、程序員要善於管理壓力。專業的程序員會盡量避免壓力，他們謹慎承諾，不答應做不到的事情；懂得保持代碼的整潔，方便問題定位和重構代碼。
7、要懂得去掌握一些編程之外的技術。專業的程序員除了們具備計算機原理、TCP/IP協議這些計算機學科的基礎知識，他們也會對常用的Shell命令牢記於心，他們還善於使用各種工具的快捷鍵來提升他們的工作效率。

❹ 45 個 Git 經典操作場景，專治不會合代碼-

git 對於大家應該都不太陌生，熟練使用git已經成為程序員的一項基本技能，盡管在工作中有諸如 Sourcetree 這樣牛X的客戶端工具，使得合並代碼變的很方便。但找工作面試和一些需彰顯個人實力的場景，仍然需要我們掌握足夠多的git命令。

下邊我們整理了45個日常用git合代碼的經典操作場景，基本覆蓋了工作中的需求。

如果你用 git commit -a 提交了一次變化(changes)，而你又不確定到底這次提交了哪些內容。你就可以用下面的命令顯示當前 HEAD 上的最近一次的提交(commit):

或者

如果你的提交信息( commit message )寫錯了且這次提交(commit)還沒有推(push), 你可以通過下面的方法來修改提交信息( commit message ):

這會打開你的默認編輯器, 在這里你可以編輯信息. 另一方面, 你也可以用一條命令一次完成:

如果你已經推(push)了這次提交(commit), 你可以修改這次提交(commit)然後強推( force push ), 但是不推薦這么做。

如果這只是單個提交(commit)，修改它：

如果你需要修改所有 歷史 , 參考 'git filter-branch'的指南頁.

通過下面的方法，從一個提交(commit)里移除一個文件:

這將非常有用，當你有一個開放的補丁( open patch )，你往上面提交了一個不必要的文件，你需要強推( force push )去更新這個遠程補丁。

如果你需要刪除推了的提交( pushed commits )，你可以使用下面的方法。可是，這會不可逆的改變你的 歷史 ，也會搞亂那些已經從該倉庫拉取(pulled)了的人的 歷史 。簡而言之，如果你不是很確定，千萬不要這么做。

如果你還沒有推到遠程, 把Git重置(reset)到你最後一次提交前的狀態就可以了(同時保存暫存的變化):

這只能在沒有推送之前有用. 如果你已經推了, 唯一安全能做的是 git revert SHAofBadCommit ， 那會創建一個新的提交(commit)用於撤消前一個提交的所有變化(changes)；或者, 如果你推的這個分支是rebase-safe的 (例如：其它開發者不會從這個分支拉), 只需要使用 git push -f 。

同樣的警告：不到萬不得已的時候不要這么做.

或者做一個 互動式rebase 刪除那些你想要刪除的提交(commit)里所對應的行。

注意, rebasing(見下面)和修正(amending)會用一個 新的提交(commit)代替舊的 , 所以如果之前你已經往遠程倉庫上推過一次修正前的提交(commit)，那你現在就必須強推( force push ) ( -f )。注意 – 總是 確保你指明一個分支!

一般來說, 要避免強推 . 最好是創建和推(push)一個新的提交(commit)，而不是強推一個修正後的提交。後者會使那些與該分支或該分支的子分支工作的開發者，在源 歷史 中產生沖突。

如果你意外的做了 git reset --hard , 你通常能找回你的提交(commit), 因為Git對每件事都會有日誌，且都會保存幾天。

你將會看到一個你過去提交(commit)的列表, 和一個重置的提交。選擇你想要回到的提交(commit)的SHA，再重置一次:

這樣就完成了。

一般來說, 如果你想暫存一個文件的一部分, 你可這樣做:

-p 簡寫。這會打開交互模式， 你將能夠用 s 選項來分隔提交(commit)；然而, 如果這個文件是新的, 會沒有這個選擇， 添加一個新文件時, 這樣做:

然後, 你需要用 e 選項來手動選擇需要添加的行，執行 git diff --cached 將會顯示哪些行暫存了哪些行只是保存在本地了。

git add 會把整個文件加入到一個提交. git add -p 允許互動式的選擇你想要提交的部分.

多數情況下，你應該將所有的內容變為未暫存，然後再選擇你想要的內容進行commit。但假定你就是想要這么做，這里你可以創建一個臨時的commit來保存你已暫存的內容，然後暫存你的未暫存的內容並進行stash。然後reset最後一個commit將原本暫存的內容變為未暫存，最後stash pop回來。

注意1: 這里使用 pop 僅僅是因為想盡可能保持冪等。注意2: 假如你不加上 --index 你會把暫存的文件標記為為存儲。

如果你只是想重置源(origin)和你本地(local)之間的一些提交(commit)，你可以：

重置某個特殊的文件, 你可以用文件名做為參數:

如果你想丟棄工作拷貝中的一部分內容，而不是全部。

簽出(checkout)不需要的內容，保留需要的。

另外一個方法是使用 stash ， Stash所有要保留下的內容, 重置工作拷貝, 重新應用保留的部分。

或者, stash 你不需要的部分, 然後stash drop。

這是另外一種使用 git reflog 情況，找到在這次錯誤拉(pull) 之前HEAD的指向。

重置分支到你所需的提交(desired commit):

完成。

先確認你沒有推(push)你的內容到遠程。

git status 會顯示你領先(ahead)源(origin)多少個提交:

一種方法是:

在main下創建一個新分支，不切換到新分支,仍在main下:

把main分支重置到前一個提交:

HEAD^ 是 HEAD^1 的簡寫，你可以通過指定要設置的 HEAD 來進一步重置。

或者, 如果你不想使用 HEAD^ , 找到你想重置到的提交(commit)的hash( git log 能夠完成)， 然後重置到這個hash。使用 git push 同步內容到遠程。

例如, main分支想重置到的提交的hash為 a13b85e :

簽出(checkout)剛才新建的分支繼續工作:

假設你正在做一個原型方案(原文為working spike (see note)), 有成百的內容，每個都工作得很好。現在, 你提交到了一個分支，保存工作內容:

當你想要把它放到一個分支里 (可能是 feature , 或者 develop ), 你關心是保持整個文件的完整，你想要一個大的提交分隔成比較小。

假設你有:

我去可以通過把內容拿到你的分支里，來解決這個問題:

這會把這個文件內容從分支 solution 拿到分支 develop 里來:

然後, 正常提交。

假設你有一個 main 分支， 執行 git log , 你看到你做過兩次提交:

讓我們用提交hash(commit hash)標記bug ( e3851e8 for #21, 5ea5173 for #14).

首先, 我們把 main 分支重置到正確的提交( a13b85e ):

現在, 我們對 bug #21 創建一個新的分支:

接著, 我們用 _cherry-pick_ 把對 bug #21 的提交放入當前分支。這意味著我們將應用(apply)這個提交(commit)，僅僅這一個提交(commit)，直接在HEAD上面。

這時候, 這里可能會產生沖突， 參見互動式 rebasing 章 沖突節 解決沖突.

再者， 我們為bug #14 創建一個新的分支, 也基於 main 分支

最後, 為 bug #14 執行 cherry-pick :

一旦你在github 上面合並(merge)了一個 pull request , 你就可以刪除你fork里被合並的分支。如果你不準備繼續在這個分支里工作, 刪除這個分支的本地拷貝會更干凈，使你不會陷入工作分支和一堆陳舊分支的混亂之中。

如果你定期推送到遠程, 多數情況下應該是安全的，但有些時候還是可能刪除了還沒有推到遠程的分支。讓我們先創建一個分支和一個新的文件:

添加文件並做一次提交

現在我們切回到主(main)分支，『不小心的』刪除 my-branch 分支

在這時候你應該想起了 reflog , 一個升級版的日誌，它存儲了倉庫(repo)裡面所有動作的 歷史 。

正如你所見，我們有一個來自刪除分支的提交hash(commit hash)，接下來看看是否能恢復刪除了的分支。

看! 我們把刪除的文件找回來了。Git的 reflog 在rebasing出錯的時候也是同樣有用的。

刪除一個遠程分支:

你也可以:

刪除一個本地分支:

首先, 從遠程拉取(fetch) 所有分支:

假設你想要從遠程的 daves 分支簽出到本地的 daves

( --track 是 git checkout -b [branch] [remotename]/[branch] 的簡寫)

這樣就得到了一個 daves 分支的本地拷貝, 任何推過(pushed)的更新，遠程都能看到.

你可以合並(merge)或rebase了一個錯誤的分支, 或者完成不了一個進行中的rebase/merge。Git 在進行危險操作的時候會把原始的HEAD保存在一個叫ORIG_HEAD的變數里, 所以要把分支恢復到rebase/merge前的狀態是很容易的。

不幸的是，如果你想把這些變化(changes)反應到遠程分支上，你就必須得強推( force push )。是因你快進( Fast forward )了提交，改變了Git 歷史 , 遠程分支不會接受變化(changes)，除非強推(force push)。

這就是許多人使用 merge 工作流, 而不是 rebasing 工作流的主要原因之一， 開發者的強推(force push)會使大的團隊陷入麻煩。使用時需要注意，一種安全使用 rebase 的方法是，不要把你的變化(changes)反映到遠程分支上, 而是按下面的做:

假設你的工作分支將會做對於 main 的pull-request。一般情況下你不關心提交(commit)的時間戳，只想組合 所有 提交(commit) 到一個單獨的裡面, 然後重置(reset)重提交(recommit)。確保主(main)分支是最新的和你的變化都已經提交了, 然後:

如果你想要更多的控制, 想要保留時間戳, 你需要做互動式rebase (interactive rebase):

如果沒有相對的其它分支， 你將不得不相對自己的 HEAD 進行 rebase。例如：你想組合最近的兩次提交(commit), 你將相對於 HEAD~2 進行rebase， 組合最近3次提交(commit), 相對於 HEAD~3 , 等等。

在你執行了互動式 rebase的命令(interactive rebase command)後, 你將在你的編輯器里看到類似下面的內容:

所有以 # 開頭的行都是注釋, 不會影響 rebase.

然後，你可以用任何上面命令列表的命令替換 pick , 你也可以通過刪除對應的行來刪除一個提交(commit)。

例如, 如果你想 單獨保留最舊(first)的提交(commit),組合所有剩下的到第二個裡面 , 你就應該編輯第二個提交(commit)後面的每個提交(commit) 前的單詞為 f :

如果你想組合這些提交(commit) 並重命名這個提交(commit) , 你應該在第二個提交(commit)旁邊添加一個 r ，或者更簡單的用 s 替代 f :

你可以在接下來彈出的文本提示框里重命名提交(commit)。

如果成功了, 你應該看到類似下面的內容:

--no-commit 執行合並(merge)但不自動提交, 給用戶在做提交前檢查和修改的機會。 no-ff 會為特性分支(feature branch)的存在過留下證據, 保持項目 歷史 一致。

有時候，在將數據推向上游之前，你有幾個正在進行的工作提交(commit)。這時候不希望把已經推(push)過的組合進來，因為其他人可能已經有提交(commit)引用它們了。

這會產生一次互動式的rebase(interactive rebase), 只會列出沒有推(push)的提交(commit)， 在這個列表時進行reorder/fix/squash 都是安全的。

檢查一個分支上的所有提交(commit)是否都已經合並(merge)到了其它分支, 你應該在這些分支的head(或任何 commits)之間做一次diff:

這會告訴你在一個分支里有而另一個分支沒有的所有提交(commit), 和分支之間不共享的提交(commit)的列表。另一個做法可以是:

如果你看到的是這樣:

這意味著你rebase的分支和當前分支在同一個提交(commit)上, 或者 領先(ahead) 當前分支。你可以嘗試:

如果你不能成功的完成rebase, 你可能必須要解決沖突。

首先執行 git status 找出哪些文件有沖突:

在這個例子裡面, README.md 有沖突。打開這個文件找到類似下面的內容:

你需要解決新提交的代碼(示例里, 從中間 == 線到 new-commit 的地方)與 HEAD 之間不一樣的地方.

有時候這些合並非常復雜，你應該使用可視化的差異編輯器(visual diff editor):

在你解決完所有沖突和測試過後, git add 變化了的(changed)文件, 然後用 git rebase --continue 繼續rebase。

如果在解決完所有的沖突過後，得到了與提交前一樣的結果, 可以執行 git rebase --skip 。

任何時候你想結束整個rebase 過程，回來rebase前的分支狀態, 你可以做:

暫存你工作目錄下的所有改動

你可以使用 -u 來排除一些文件

假設你只想暫存某一個文件

假設你想暫存多個文件

這樣你可以在 list 時看到它

或

首先你可以查看你的 stash 記錄

然後你可以 apply 某個 stash

此處， 'n'是 stash 在棧中的位置，最上層的 stash 會是0

除此之外，也可以使用時間標記(假如你能記得的話)。

你需要手動create一個 stash commit ， 然後使用 git stash store 。

如果已經克隆了:

如果你想恢復一個已刪除標簽(tag), 可以按照下面的步驟: 首先, 需要找到無法訪問的標簽(unreachable tag):

記下這個標簽(tag)的hash，然後用Git的 update-ref

這時你的標簽(tag)應該已經恢復了。

如果某人在 GitHub 上給你發了一個 pull request , 但是然後他刪除了他自己的原始 fork, 你將沒法克隆他們的提交(commit)或使用 git am 。在這種情況下, 最好手動的查看他們的提交(commit)，並把它們拷貝到一個本地新分支，然後做提交。

做完提交後, 再修改作者，參見變更作者。然後, 應用變化, 再發起一個新的 pull request 。

在 OS X 和 Linux 下, 你的 Git的配置文件儲存在 ~/.gitconfig 。我在 [alias] 部分添加了一些快捷別名(和一些我容易拼寫錯誤的)，如下:

你可能有一個倉庫需要授權，這時你可以緩存用戶名和密碼，而不用每次推/拉(push/pull)的時候都輸入，Credential helper能幫你。

你把事情搞砸了：你 重置(reset) 了一些東西, 或者你合並了錯誤的分支, 亦或你強推了後找不到你自己的提交(commit)了。有些時候, 你一直都做得很好, 但你想回到以前的某個狀態。

這就是 git reflog 的目的， reflog 記錄對分支頂端(the tip of a branch)的任何改變, 即使那個頂端沒有被任何分支或標簽引用。基本上, 每次HEAD的改變, 一條新的記錄就會增加到 reflog 。遺憾的是，這只對本地分支起作用，且它只跟蹤動作 (例如，不會跟蹤一個沒有被記錄的文件的任何改變)。

上面的reflog展示了從main分支簽出(checkout)到2.2 分支，然後再簽回。那裡，還有一個硬重置(hard reset)到一個較舊的提交。最新的動作出現在最上面以 HEAD@{0} 標識.

如果事實證明你不小心回移(move back)了提交(commit), reflog 會包含你不小心回移前main上指向的提交(0254ea7)。

然後使用 git reset 就可以把main改回到之前的commit，這提供了一個在 歷史 被意外更改情況下的安全網。

❺ 程序員需要掌握的技能

程序員需要掌握的技能如下：

1、Git

Git是一個版本控制軟體，最早是Linux之父為了更好的管理Linux內核代碼而編寫的。版本控制是可以記錄每一次修改的文件以及內容的改動，不需要遠程或者架設伺服器就能做到本地版本管理。比如你要查看某次改動只要查看每次修改的備注就可以了。

4、VS code

每一個程序員都應該有一個最熟悉的文本編輯器，大家如果要邁入編程這一行就應該知道文本編輯器的幫助作用。Notdpad++反華我們今天就不提它了，但是鼓勵各位開發者多學習一些高級文本編輯器。