IntelliJ IDEA提供了許多高級(jí)版本控制技巧，可以幫助開(kāi)發(fā)者更有效地管理代碼庫(kù)和版本控制工作。以下是一些高級(jí)技巧，可以提高你在IntelliJ IDEA中的版本控制體驗(yàn)：
多重版本控制系統(tǒng)支持： IntelliJ IDEA支持同時(shí)使用多個(gè)版本控制系統(tǒng)，如Git、SVN、Mercurial等。這意味著你可以在同一個(gè)項(xiàng)目中使用不同的版本控制系統(tǒng)，根據(jù)需要管理不同的代碼庫(kù)。
局部歷史記錄： IntelliJ IDEA允許你查看文件的局部歷史記錄，這意味著你可以查看文件的更改歷史，而不必依賴(lài)于整個(gè)項(xiàng)目的提交歷史。這對(duì)于深入了解特定文件的演變非常有用。
交互式重基： 在進(jìn)行合并操作時(shí)，IntelliJ IDEA提供了交互式重基（rebase）工具，可以幫助你重新定位和整理提交歷史，以保持項(xiàng)目的整潔性。
版本控制工具窗口： 版本控制工具窗口提供了豐富的功能，如提交、更新、查看歷史、分支操作等。你可以通過(guò)自定義工具窗口來(lái)定制版本控制工作區(qū)的布局，以適應(yīng)你的工作流程。
Git支持的高級(jí)操作： 如果你使用Git，IntelliJ IDEA提供了一些高級(jí)Git操作，如交互式重排（interactive rebase）、stash管理、子模塊支持等。這些功能可以在版本控制工具窗口或終端中使用。
版本控制標(biāo)簽： 你可以為重要的提交創(chuàng)建標(biāo)簽，以便更容易地跟蹤和恢復(fù)特定的版本。標(biāo)簽通常用于標(biāo)記發(fā)布版本。
代碼歷史分析： IntelliJ IDEA提供了代碼歷史分析工具，可以幫助你了解代碼庫(kù)的演變和貢獻(xiàn)者的工作。這對(duì)于項(xiàng)目維護(hù)和代碼審查很有幫助。
自動(dòng)化代碼審查和提交檢查： 可以配置IntelliJ IDEA來(lái)執(zhí)行自動(dòng)化代碼審查和提交檢查，以確保代碼符合項(xiàng)目規(guī)范和最佳實(shí)踐。
多分支管理： 如果你在一個(gè)大型項(xiàng)目中使用多個(gè)分支，IntelliJ IDEA提供了功能強(qiáng)大的分支管理工具，幫助你輕松地切換、合并和處理分支。
快速導(dǎo)航： 使用快捷鍵和搜索功能來(lái)快速導(dǎo)航到不同的提交、分支、標(biāo)簽等。IntelliJ IDEA的搜索功能非常強(qiáng)大，可以幫助你快速定位到特定的版本控制操作。
自定義Git鉤子： 如果你使用Git，可以自定義Git鉤子來(lái)在提交、合并等操作前后執(zhí)行特定的腳本或命令。
集成問(wèn)題跟蹤系統(tǒng)： 如果你的項(xiàng)目使用問(wèn)題跟蹤系統(tǒng)（如JIRA、GitHub Issues等），IntelliJ IDEA可以與這些系統(tǒng)集成，使你能夠從IDE中直接訪問(wèn)和管理問(wèn)題。
版本控制的代碼重構(gòu)： 在重構(gòu)代碼時(shí)，確保版本控制工具是活動(dòng)的，以便在重構(gòu)操作后保留版本歷史并正確提交更改。
這些高級(jí)版本控制技巧可以幫助你更好地管理和協(xié)作項(xiàng)目，確保代碼庫(kù)的質(zhì)量和可維護(hù)性。根據(jù)你的項(xiàng)目需求和工作流程，選擇適合你的技巧，并深入研究IntelliJ IDEA的版本控制功能，以提高開(kāi)發(fā)效率。
詳細(xì)說(shuō)明
Git Version Control
這篇文章是針對(duì)git版本控制和工作流的總結(jié)，如果有些朋友之前還沒(méi)使用過(guò)git，對(duì)git的基本概念和命令不是很熟悉，可以從以下基本教程入手：
專(zhuān)為設(shè)計(jì)師而寫(xiě)的GitHub快速入門(mén)教程
git – 簡(jiǎn)明指南
學(xué)習(xí)Git的在線互動(dòng)教程
基本概念
Git是什么？
Git是分布式版本控制系統(tǒng)，與SVN類(lèi)似的集中化版本控制系統(tǒng)相比，集中化版本控制系統(tǒng)雖然能夠令多個(gè)團(tuán)隊(duì)成員一起協(xié)作開(kāi)發(fā)，但有時(shí)如果中央服務(wù)器宕機(jī)的話，誰(shuí)也無(wú)法在宕機(jī)期間提交更新和協(xié)同開(kāi)發(fā)。甚至有時(shí)，中央服務(wù)器磁盤(pán)故障，恰巧又沒(méi)有做備份或備份沒(méi)及時(shí)，那就可能有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。
但Git是分布式的版本控制系統(tǒng)，客戶(hù)端不只是提取最新版本的快照，而且將整個(gè)代碼倉(cāng)庫(kù)鏡像復(fù)制下來(lái)。如果任何協(xié)同工作用的服務(wù)器發(fā)生故障了，也可以用任何一個(gè)代碼倉(cāng)庫(kù)來(lái)恢復(fù)。而且在協(xié)作服務(wù)器宕機(jī)期間，你也可以提交代碼到本地倉(cāng)庫(kù)，當(dāng)協(xié)作服務(wù)器正常工作后，你再將本地倉(cāng)庫(kù)同步到遠(yuǎn)程倉(cāng)庫(kù)。
為什么要使用Git
能夠?qū)ξ募姹究刂坪投嗳藚f(xié)作開(kāi)發(fā)
擁有強(qiáng)大的分支特性，所以能夠靈活地以不同的工作流協(xié)同開(kāi)發(fā)
分布式版本控制系統(tǒng)，即使協(xié)作服務(wù)器宕機(jī)，也能繼續(xù)提交代碼或文件到本地倉(cāng)庫(kù)，當(dāng)協(xié)作服務(wù)器恢復(fù)正常工作時(shí)，再將本地倉(cāng)庫(kù)同步到遠(yuǎn)程倉(cāng)庫(kù)。
當(dāng)團(tuán)隊(duì)中某個(gè)成員完成某個(gè)功能時(shí)，通過(guò)pull request操作來(lái)通知其他團(tuán)隊(duì)成員，其他團(tuán)隊(duì)成員能夠review code后再合并代碼。
Git有哪些特性
文件三種狀態(tài)(modified, staged, committed)
直接記錄快照，而非差異比較
多數(shù)操作僅添加操作
近乎所有操作都是本地執(zhí)行
時(shí)刻保持?jǐn)?shù)據(jù)完整性
有關(guān)以上特性的詳細(xì)解釋?zhuān)?qǐng)查看Pro git的git基礎(chǔ)章節(jié)
Git基本工作流程
在git版本控制的目錄下修改某個(gè)文件
使用git add命令對(duì)修改后的文件快照，保存到暫存區(qū)域
使用git commit命令提交更新，將保存在暫存區(qū)域的文件快照永久轉(zhuǎn)儲(chǔ)到 Git 目錄中
Git基本技巧
自動(dòng)補(bǔ)全
Git 命令別名
關(guān)于具體如何使用自動(dòng)補(bǔ)全和命名別名技巧，請(qǐng)查看Pro git的技巧和竅門(mén)
Git版本控制
創(chuàng)建倉(cāng)庫(kù)
git init
git clone
git config
保存修改
git add
git commit
查看倉(cāng)庫(kù)
git status
git log –oneline
撤銷(xiāo)修改
查看之前的commit
git checkout <commit> <file>
git checkout <commit>
git checkout <branch>
撤銷(xiāo)公共修改
git revert <commit>
撤銷(xiāo)本地修改
git reset
git clean
重寫(xiě)Git歷史記錄
git commit –amend
git rebase
git reflog
Git協(xié)作開(kāi)發(fā)
分支
git branch
git checkout
git merge
倉(cāng)庫(kù)同步
git remote
git fetch
git pull
git push
Git工作流
由于git擁有強(qiáng)大的分支特性，它的工作流比較靈活而缺乏約束，于是參考Atlassian Git Tutorial的Comparing Workflows章節(jié)提供四種Git工作流：
Centralized Workflow
Feature Branch Workflow
Gitflow Workflow
Forking Workflow
以上工作流只是參考指南，而不是具體規(guī)則。你可以根據(jù)自己實(shí)際情況來(lái)選擇適合自己的工作流或微調(diào)來(lái)滿足自己的需要。
Centralized Workflow
過(guò)渡到分布式版本控制系統(tǒng)看起來(lái)像一個(gè)艱巨的任務(wù)，但如果你充分利用好git的話，你不必改變你既有的工作流，你的團(tuán)隊(duì)可以采用與之前使用SVN一樣的方式來(lái)開(kāi)發(fā)項(xiàng)目。
如何工作
Centralized Workflow
從遠(yuǎn)程倉(cāng)庫(kù)(central repository)克隆工程到本地倉(cāng)庫(kù)(local repository) — git clone
在本地倉(cāng)庫(kù)編輯文件和提交更新 — git add和git commit
fetch遠(yuǎn)程倉(cāng)庫(kù)已更新的commit到本地倉(cāng)庫(kù)和rebase到已更新的commit的上面 —git fetch和git rebase 或 git pull --rebase
push本地主分支(master branch)到遠(yuǎn)程倉(cāng)庫(kù) — git push
管理沖突
File Conflicts
何時(shí)發(fā)生沖突：在開(kāi)發(fā)者發(fā)布它們功能之前，他們需要fetch遠(yuǎn)程倉(cāng)庫(kù)已更新的commit到本地倉(cāng)庫(kù)和rebase到已更新的commit的上面。有時(shí)，本地提交與遠(yuǎn)程提交會(huì)發(fā)生沖突，git會(huì)暫停rebase過(guò)程來(lái)讓你手動(dòng)解決沖突。
如何解決沖突：你可以使用git status和git add來(lái)手動(dòng)解決合并時(shí)沖突。
Feature Branch Workflow
Feature Branch Workflow的主要思想就是在開(kāi)發(fā)每個(gè)功能時(shí)都應(yīng)該創(chuàng)建一個(gè)獨(dú)立的分支而不只是使用主分支。由于每個(gè)分支是獨(dú)立且互不影響，這就意味著主分支不會(huì)包含broken code，對(duì)持續(xù)集成環(huán)境是很有幫助的。
如何工作
Feature Branch Workflow
仍然使用遠(yuǎn)程倉(cāng)庫(kù)(central repository)和主分支(master branch)仍記錄官方工程的歷史
開(kāi)發(fā)者每次開(kāi)發(fā)新功能時(shí)都創(chuàng)建一個(gè)新分支 — git checkout -b
Feature branches應(yīng)該推送到遠(yuǎn)程倉(cāng)庫(kù)(central repository) — git push
發(fā)送pull request來(lái)請(qǐng)求管理員能否合并到主分支(master branch)
發(fā)布新功能到遠(yuǎn)程倉(cāng)庫(kù)(central repository)
Pull Request
Pull request是一種當(dāng)開(kāi)發(fā)者完成一個(gè)新功能后向其他團(tuán)隊(duì)成員發(fā)送通知的機(jī)制。它的使用過(guò)程如下：
開(kāi)發(fā)者可以通過(guò)Github或Bitbucket發(fā)送pull request
Pull request on Github
其他的團(tuán)隊(duì)成員審查、討論和修改代碼
項(xiàng)目維護(hù)者合并新增功能分支到主分支(master branch)，然后關(guān)閉pull request
Gitflow Workflow
Feature Branch Workflow是一種非常靈活的開(kāi)發(fā)方式。對(duì)于一些規(guī)模比較大的團(tuán)隊(duì)，最好就是給特定的分支賦予不同的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨(dú)立的分支來(lái)準(zhǔn)備發(fā)布(preparing)，維護(hù)(maintaining), 和記錄版本(recording releases)。下面我會(huì)逐個(gè)介紹這個(gè)幾個(gè)分支：Historical Branches、Feature Branches、Release Branches和Maintenance Branches。
Historical Branches
Historical Branches
master分支保存官方發(fā)布?xì)v史
develop分支衍生出各個(gè)feature分支
Feature Branches
Feature Branches
feature分支使用develop分支作為它們的父類(lèi)分支
當(dāng)其中一個(gè)feature分支完成后，它會(huì)合并會(huì)develop分支
feature分支應(yīng)該從不與master分支直接交互
Release Branches
Release Branches
release分支主要用來(lái)清理釋放、測(cè)試和更新文檔
一旦develop分支獲得足夠的功能來(lái)發(fā)布時(shí)，你可以從develop衍生出一個(gè)release分支
一旦準(zhǔn)備好上架，release合并到master分支并且標(biāo)記一個(gè)版本號(hào)
另外，還需要合并回develop分支
Maintenance Branches
Maintenance Branches.png
maintenance分支用來(lái)快速給已發(fā)布產(chǎn)品修復(fù)bug或微調(diào)功能
它從master分支直接衍生出來(lái)
一旦完成修復(fù)bug，它應(yīng)該合并回master分支和develop分支
master應(yīng)該被標(biāo)記一個(gè)新的版本號(hào)
標(biāo)記Tags
使用兩個(gè)命令來(lái)給master分支標(biāo)記版本號(hào)：
git tag -a 0.1 -m "Initial public release" master
git push origin master --tags
Forking Workflow
Forking Workflow與以上討論的工作流很不同，一個(gè)很重要的區(qū)別就是它不只是多個(gè)開(kāi)發(fā)共享一個(gè)遠(yuǎn)程倉(cāng)庫(kù)(central repository)，而是每個(gè)開(kāi)發(fā)者都擁有一個(gè)獨(dú)立的服務(wù)端倉(cāng)庫(kù)。也就是說(shuō)每個(gè)contributor都有兩個(gè)倉(cāng)庫(kù)：本地私有的倉(cāng)庫(kù)和遠(yuǎn)程共享的倉(cāng)庫(kù)。
Forking Workflow
Forking Workflow這種工作流主要好處就是每個(gè)開(kāi)發(fā)者都擁有自己的遠(yuǎn)程倉(cāng)庫(kù)，可以將提交的commits推送到自己的遠(yuǎn)程倉(cāng)庫(kù)，但只有工程維護(hù)者才有權(quán)限push提交的commits到官方的倉(cāng)庫(kù)，其他開(kāi)發(fā)者在沒(méi)有授權(quán)的情況下不能push。Github很多開(kāi)源項(xiàng)目都是采用Forking Workflow工作流。
如何工作
在服務(wù)器上有一個(gè)官方公共的倉(cāng)庫(kù)
開(kāi)發(fā)者fork官方倉(cāng)庫(kù)來(lái)創(chuàng)建它的拷貝，然后存放在服務(wù)器上
Fork official repository.png
當(dāng)開(kāi)發(fā)者準(zhǔn)備好發(fā)布本地的commit時(shí)，他們push commit到他們自己的公共倉(cāng)庫(kù)
在自己的公共倉(cāng)庫(kù)發(fā)送一個(gè)pull request到官方倉(cāng)庫(kù)
維護(hù)者pull貢獻(xiàn)者的commit到他自己的本地倉(cāng)庫(kù)
審查代碼確保它不會(huì)破壞工程，合并它到本地倉(cāng)庫(kù)的master分支
push master分支到服務(wù)器上的官方倉(cāng)庫(kù)
其他開(kāi)發(fā)者應(yīng)該同步官方倉(cāng)庫(kù)。
擴(kuò)展閱讀
Pro Git 簡(jiǎn)體中文版
atlassian Git Tutorials
