在git中管理審美代碼更改

我發現我對源代碼做了很多小的更改，通常情況下幾乎沒有任何功能影響。例如：在git中管理審美代碼更改

提煉或更正評論。
在一個類中移動函數定義以獲得更自然的閱讀順序。
間距和排列一些聲明的可讀性。
摺疊使用多行到一個的東西。
刪除舊的註釋代碼。
糾正一些不一致的空白。

我想我有一個強大的關注我的代碼中的細節。但問題是我不知道如何處理這些變化，並且它們使得在git中的分支之間切換變得困難。我發現自己不知道是否要進行微小的改動，把它們藏起來，或者把它們放在一個單獨的小調整分支中，並在稍後進行合併。這些選項似乎都不理想。

主要問題是這些變化是不可預測的。如果我要這樣做，那麼會有很多提交「Minor code aesthetic change」的提交，因爲第二個我做出這樣的提交，我注意到另一個類似的問題。當我做一個小小的改變，一個重大的改變，然後另一個小的改變時，我應該怎麼做？我想將三個小改動合併爲一個提交。當更改幾乎不需要我的注意時，看到在git status中修改的文件也很煩人。我知道git commit --amend，但我也知道這是不好的做法，因爲它使我的回購與遙控器不一致。

來源

2009-09-24 Ollie Saunders

這是所有源控制系統共有的問題。我還沒有遇到系統內置的答案。 – ChrisF 2009-09-24 11:34:14

如果您保留的地方分支永遠不會推送/提交補丁（例如整型分支），那麼諸如'commit --amend'和'rebase -interactive'（可以重新排序，編輯和壓縮提交）突然有可能良好的做法 - 他們可以使您的發展歷史更清潔！ – Cascabel 2009-09-24 12:30:48

使用MQ Extension for mercurial在mercurial中獲得git rebase功能 – 2009-09-27 06:26:48

一方面我不認爲適度頻繁的微小變化會對任何事物或任何人造成很大的傷害。我總是在我們的團隊中立即做出輕微的美容修改，我們已經同意我們只在我們的提交信息中使用化妝品這個詞，就是這樣。

我不會推薦的是將化妝品與其他變化一起！另一方面，如果這對你來說是一個問題，你想改變一些東西，我會建議你做一個美容會議，你可以從你提到的列表中解決所有類型的問題。僅在特定時間點專注於化妝品也可能更有效。否則美化變化可能會成爲拖延式活動。

來源

2009-09-24 11:51:39 markus

我不認爲你應該包括他們與其他「真正」的變化。這樣做會使合併分支時難以查看更改。

也許你在自己的分支上保留這些細微變化的想法有其優點。

當我使用Perforce公司（與它的多個變更表），我可以把這些編輯在一個單獨的變更表，直到我有「足夠」，在保證一個校驗，校驗中會包含多個文件和每個文件可以有多個佈局但沒有「真實」的變化。

來源

2009-09-24 11:37:07 ChrisF

git中的模擬是保留一個整型分支，並且可能交互地重新綁定它以在合併之前將它們很好地壓合在一起，或者保留化妝品存儲，定期應用它，添加更多的變化，並再次存儲它。不幸的是，由於外觀變化經常會影響很多線條，因此您會開始較快地遇到合併衝突。 – Cascabel 2009-09-24 12:29:05

我想你應該用更好的提交信息分別提交這些更改。而不是「小代碼美學改變」。你應該寫一些東西，比如'在X視圖的X部分中改變頭部的間距'。

這不會以任何方式傷害你。

來源

2009-09-24 12:11:23 allesklar

在git中，請記住，除非您推送（或以其他方式發佈）提交，否則您可以根據需要自由編輯它們。在你的例子中，假設你還沒有推動你的主要變化，我認爲你合併這兩個小變化是完全合理的。如果您擔心污染主代碼庫，那麼您可以像往常一樣執行您的工作，然後在推送前編輯提交，以便將最小的更改合併爲最近的提交，檢查它是否足夠大如果它看起來太小，就不推動那個提交（還）。

來源

2009-09-24 12:20:07

你可以使用「git rebase -i 」來重新排序和壓縮美學變化到單個提交中：http：// www。kernel.org/pub/software/scm/git/docs/git-rebase.html#_interactive_mode – 2009-09-24 12:53:38

我建議讓他們分開並堅持，以便至少其他開發人員能夠合併他們而不用擔心太多。 :-)我傾向於做你所描述的。

另一個可行的建議是爲代碼定義標準化的格式，並使用IDE或其他進程（build/checkin）在保存或簽入時自動格式化代碼。因此，如果您是反叛者，那麼您仍然可以在本地使用自己的格式:-)但是當簽入時，所有代碼看起來都是相同的。

我認爲git能夠定義預檢入鉤子，但也有螞蟻目標，maven插件和IDE功能/插件，可以以自動方式進行自動格式化。

來源

2009-09-24 16:04:34 cjstehno

你很幸運能夠使用git！正如其他人指出的那樣，您可以在將其推送到回購之前將更改結合起來。這是git的一個更酷的區別。我可以走你，儘管它，如果你在一個分支工作：

> git checkout dev # branch for work 
>> ... do some stuff 
> git commit -am 'cosmetic only 1' 
>> ... do some more stuff 
> git commit -am 'cosmetic stuff I missed last time' 
>> ... do some real stuff 
> git commit -am 'real work' 
> git checkout master && git pull && git checkout dev 
    # optional, if you repo is out of date 
> git rebase --interactive master

在這一點上，你可以重新安排你的提交，並結合他們together--正是你想要的。於是最後：

> git checkout master && git merge dev && git push && git checkout dev

所以祕密是：

Git的輕鬆的一個分支工作能力
檢查往往
Git的在系統中已經編輯提交能力的Git的便利

說實話，我一般不擔心提交日誌那麼多。我只是深入挖掘歷史，足以讓這種維護工作值得努力。

順便說一句如果你不在分支上工作，我確信有一種方法可以做到這一點，但我不知道它。以下是關於在分支上工作的參考：http://osteele.com/archives/2008/05/my-git-workflow

來源

2009-09-26 02:14:23 ndp

在git中管理審美代碼更改

回答

相關問題