我們公司正在研究現代化我們的版本控制，通常我們想使用git。我之前使用過分佈式版本控制，但只使用個人項目和開源項目（有某種用戶管理的項目）（Google代碼上的Mercurial和LaunchPad上的Bazaar）。如果我們在自己的倉庫中使用GIT，我不確定如何驗證每個提交的作者。我不是在談論推送認證，而是提交。GIT作者認證
所以說.. 1.我克隆回購和檢查出一個分支。 2.我將我的user.name更改爲我的工作人員並進行更改並最終提交。 3.我改變我的用戶名和推（例如我的SSH帳戶）。 4.我可以把所有的改變歸咎於我的同事。
這會成爲問題嗎？我們如何解決這個問題？
我確定有東西在那裏，但我想我不是在尋找正確的信息，所以如果你們可以給我一些基本的概述，這將是非常有益的。
感謝
您不能調節提交的創建，因爲這種情況發生在每個用戶的工作站上，在資源庫中自己的本地副本。
您可以在中央存儲庫中執行一些檢查（使用掛鉤），並要求傳入提交承載連接用戶的名稱。 但是，這是一個壞主意。
考慮一個用戶可能需要重用其他人的工作，但不想合併它的情況。他可能會挑選別人的承諾，或者將自己的分支重新分配給自己。在這種情況下，正確作者權信息匹配原始提交，並限制傳入的提交具有與推送它們的用戶相匹配的作者名稱會破壞此工作流程。
只有當它成爲問題時，我纔會擔心這一點。這歸結爲信任：如果你不信任開發者，爲什麼他們爲你工作？
其實這不是我自己的公司，在這裏大概有一百人，所以公司基礎設施和某些管理人員擔心問責制。 – NawaMan 2013-04-10 17:08:35
@NawaMan如果你想要Git的靈活性和敏捷性，那麼你就不能強加這個限制。如果貴公司想要集中管理所有內容並施加限制，則不要使用分散式VCS。或者，需要Git推送的代碼評論。 – cdhowie 2013-04-10 17:09:52
您可以隨時要求用用戶的私鑰簽名提交。但我會說這是全面的。您可以使用服務器端掛鉤來確保用戶僅限於提交給定名稱/電子郵件，但正如cdhowie指出的那樣，這使得在某些工作流程中很難提交其他人的工作。 – 2013-04-10 17:34:32
這是一個實際的問題嗎？我一直在一家相當大的公司工作，我們使用git進行版本控制，並使用gerrit進行代碼評審。從來沒有欺騙提交作者/提交者的問題出現。有時候人們做錯選擇時會誤以爲自己是作者，但這通常是在代碼審查期間被捕獲的。 – Michael 2013-04-10 17:02:24
感謝您的回答。現在我們還在評估中，這不是問題。這是劇本中的企業政策和偏執狂。另外，我感到他們不會喜歡我們只能依賴代碼審查人員（因爲在許多人都在使用的複雜分支的情況下會發生錯誤）。 – NawaMan 2013-04-10 17:12:35