當前位置:首頁 » 數據倉庫 » 資料庫版本和git版本並存
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

資料庫版本和git版本並存

發布時間: 2022-09-13 09:42:00

❶ GIT的版本庫

創建一個版本庫:git init
( kwydwuf注: 新版 git 中應該用 git init ,不要再用 init-db 命令,具體可以通過命令 git help init 查看)
可以了。現在我們來為本文的寫作創建一個版本庫: $mkdirgittutorcn$cdgittutorcn$gitinitgit 將會作出以下的回應 /[yourpath]/.git或(/Users/1a/gittutorcn/.git/)這樣,一個空的版本庫就創建好了,並在當前目錄中創建一個叫 .git 的子目錄。你可以用 ls -a 查看一下,並請注意其中的三項內容:
* 一個叫 HEAD 的文件,我們現在來查看一下它的內容: $cat.git/HEAD現在 HEAD 的內容應該是這樣: ref:refs/heads/master我們可以看到,HEAD 文件中的內容其實只是包含了一個索引信息,並且,這個索引將總是指向你的項目中的當前開發分支。
* 一個叫 objects 的子目錄,它包含了你的項目中的所有對象,我們不必直接地了解到這些對象內容,我們應該關心是存放在這些對象中的項目的數據。
Note
關於 git 對象的分類,以及 git 對象資料庫的說明,請參看 [Discussion]
* 一個叫 refs 的子目錄,它用來保存指向對象的索引。
具體地說,子目錄 refs 包含著兩個子目錄叫 heads 和 tags,就像他們的名字所表達的意味一樣:他們存放了不同的開發分支的頭的索引, 或者是你用來標定版本的標簽的索引。
請注意:master 是默認的分支,這也是為什麼 .git/HEAD 創建的時候就指向 master 的原因,盡管目前它其實並不存在。 git 將假設你會在 master 上開始並展開你以後的工作,除非你自己創建你自己的分支。
另外,這只是一個約定俗成的習慣而已,實際上你可以將你的工作分支叫任何名字,而不必在版本庫中一定要有一個叫 master 的分支,盡管很多 git 工具都認為 master 分支是存在的。
現在已經創建好了一個 git 版本庫,但是它是空的,還不能做任何事情,下一步就是怎麼向版本庫植入數據了。

❷ 如何一起使用 Git 和 SVN

操作步驟:
你需要:

1.安裝 git 和 git-svn
2.創建工作目錄:mkdir strigi
3.初始化git工作目錄:

4.找到項目的某個提交 (你可以通過 cia版本控制 去獲得). 警告: 命令git-log 會從這個版本開始顯示項目的版本歷史。
5.執行命令git-svn fetch -rREVISION,REVISION 就是剛才獲得的那個版本號。
6.更新工作目錄:git-svn rebase,現在你就可以在這個項目中使用git作為版本控制了。
要保持工作目錄更新,可以執行:

git-svn rebase

你可以用下面的命令將更改提交到svn伺服器:

git-svn dcommit

通過這種方式,所有的git提交都會「轉換」成相應的svn命令。
解決git-svn rebase的問題

在加入新東西之前,你也許會在同步主開發樹的時候體驗到一些問題。實際上,你在執行git-svn
rebase之前還必須提交所有的本地修改(使用git-commit命令)。

有時候這並不合理,因為你的更改也許還沒有準備好提交(還沒有完成、測試或者驗證這寫代碼)。不過別擔心,git對此也有一個官方的解決方案,只需下面的步驟:

先把你的改動保存起來,使用命令:git-stash

更新工作副本,使用命令:git-svn rebase,這跟平時一樣

恢復保存起來的改動,使用命令:git-stash apply

清除「保存」,使用命令:git-stash
clear。第1步之後,所有未提交的改動在工作副本上都看不到了,因而你可以執行rebase命令,不會有任何問題。

❸ git版本沖突怎麼解決

如果系統中有一些配置文件在伺服器上做了配置修改,然後後續開發又新添加一些配置項的時候,
在發布這個配置文件的時候,會發生代碼沖突:
error: Your local changes to the following files would be overwritten by merge:
protected/config/main.php
Please, commit your changes or stash them before you can merge.
如果希望保留生產伺服器上所做的改動,僅僅並入新配置項, 處理方法如下:
git stash
git pull
git stash pop
然後可以使用git diff -w +文件名 來確認代碼自動合並的情況.
反過來,如果希望用代碼庫中的文件完全覆蓋本地工作版本. 方法如下:
git reset --hard
git pull
其中git reset是針對版本,如果想針對文件回退本地修改,使用
git checkout HEAD file/to/restore

❹ 如何一起使用 Git 和 SVN

項目環境說明
項目使用svn進行代碼版本管理。
使用場景
修改了某些文件後,在修改成另外的實現方法前先備份當前已經實現的方案(git commit臨時文件)
在不能連接svn伺服器的機器上修改svn版本管理的代碼,且需要進行版本管理
前期准備
安裝git(MSsyGit,TortoiseGit)
安裝svn(TortoiseSVN)
測試步驟
本地新建目錄welkinvcproject.svngit,svn checkout file:///E:/Code/svnRepository/welkinvcproject/trunk
在svn Settings的Global ignore pattern增加*.git,例如我的設置是*.git *.obj *.manifest *.manifest.res *.ilk *.idb *.dep *.user *.exe *.pdb
在welkinvcproject.svngit目錄滑鼠右鍵點擊Git Init Here
在welkinvcproject.svngit目錄下建立.gitignore文件,把不需要git管理的文件加入此表,例如.svn. 或者編輯.git/info/exclude文件,我設置的是
*.svn
*.obj
*.manifest
*.manifest.res
*.ilk
*.idb
*.dep
*.user
*.exe
*.pdb
在welkinvcproject.svngit目錄滑鼠右鍵點擊Git Commit -> "master"...,提交所有svn版本控制的文件
在本地隨便修改幾個文件,但由於還不能確定是最後的代碼,所以不能提交到svn,採取臨時提交到git的辦法來管理。在welkinvcproject.svngit目錄滑鼠右鍵點擊Git Commit -> "master"...,提交變更的文件
重復循環執行上一步
最後再提交到svn,再提交到git,這是svn的代碼和git的代碼是一致的。(稍後如果發現之前提交到git的某個版本的代碼更合適,可以使用git revert到相應的版本,再提交到svn和git)

❺ 關於git和github版本管理的疑問,先謝謝大家了,80分~~

樓主 我一個問題一個問題的回答哈
1、git是分布式管理,也就是說伺服器上的和本地的可以隨時同步更新,當你提交不成功時,你所更改的文件會放在緩存區,別人來提交的時候會一起把所有更改的文件提交,建議代碼入庫不要多個人來操作 一個人就好了 這樣子不容易出錯。
2、git分支間的合並---是把兩個分之間不同的修改合並到一起,如果遇到沖突(比如修改到了同一個文件),就會提示你,讓你忽略或者是手動處理。(建議手動處理)
3、不用,你就在本地客戶端克隆一個代碼庫,然後進行本地修改,到時候代碼入庫的時候注意一個先後順序就行了。
4、為什麼要在伺服器上改呢?直接在本地進行開發,然後在進行伺服器的代碼同步不就好了嗎

❻ 關於git怎樣合並不同版本

舉個例子:
git rev-list --after="Fri Jan 6 11:47:13 2017 +0800" --before="Fri Jan 11 11:47:13 2017 +0800" --reverse master | git cherry-pick --stdin
先用git rev-list把一段時間內的變更列出來,然後用管道傳給git cherry-pick。注意到是為了cherry-pick,所以rev-list的輸出順序反一下,變成最老的先輸出。

❼ git版本控制的原理,看書上的說的不是很能理解

不保存他們的差異數據意思是每次他保存的是變化後的整個的文件,
就是如果有修改了那麼 他就保存全部 (當然是提交後)
上面的 圖中虛線的意思是這個文件沒有變化所以這個版本中的這個文件用的是上一個版本中的文件的快照就是
有的版本記錄的修改就是 比如版本2里記錄了(a文件發生了變化,在38行插入了兩行數據是.......)
而git保存的所 在版本而終記錄一下 a文件修改後的完整的文件

這樣造成的結果就是如果文件修改過多,版本庫會過大,那麼可以git gc 整理一下,他會把版本庫壓縮一下,就小了
希望可以幫到你

❽ git上傳項目代碼,資料庫會同步嗎

不會直接同步,需要自己操作。

  1. 直接在github網頁上完成創建代碼文件並編寫,比較容易。

  2. 是本地編寫完代碼,放到本地倉庫,然後再同步到github遠程倉庫,想著以後做稍大的項目可能會本地測試修改,然後再上傳。

  • 第一次配置流程可能有點麻煩,還有一些注意事項,因此在這里總結一下。

主要流程如下:

①注冊github賬號,下載git客戶端

②創建本地倉庫(其實就是個文件夾)

③使用ssh密鑰連接本地倉庫和github遠程倉庫

④將本地項目上傳到github遠程項目

❾ Git是什麼

Git是什麼?
Git是目前世界上最先進的分布式版本控制系統(沒有之一)。
Git有什麼特點?簡單來說就是:高端大氣上檔次!
那什麼是版本控制系統?
如果你用Microsoft Word寫過長篇大論,那你一定有這樣的經歷:
想刪除一個段落,又怕將來想恢復找不回來怎麼辦?有辦法,先把當前文件「另存為……」一個新的Word文件,再接著改,改到一定程度,再「另存為……」一個新文件,這樣一直改下去,最後你的Word文檔變成了這樣:

過了一周,你想找回被刪除的文字,但是已經記不清刪除前保存在哪個文件里了,只好一個一個文件去找,真麻煩。
看著一堆亂七八糟的文件,想保留最新的一個,然後把其他的刪掉,又怕哪天會用上,還不敢刪,真郁悶。
更要命的是,有些部分需要你的財務同事幫助填寫,於是你把文件Copy到U盤里給她(也可能通過Email發送一份給她),然後,你繼續修改Word文件。一天後,同事再把Word文件傳給你,此時,你必須想想,發給她之後到你收到她的文件期間,你作了哪些改動,得把你的改動和她的部分合並,真困難。
於是你想,如果有一個軟體,不但能自動幫我記錄每次文件的改動,還可以讓同事協作編輯,這樣就不用自己管理一堆類似的文件了,也不需要把文件傳來傳去。如果想查看某次改動,只需要在軟體里瞄一眼就可以,豈不是很方便?
這個軟體用起來就應該像這個樣子,能記錄每次文件的改動:

版本
用戶
說明
日期

1 張三 刪除了軟體服務條款5 7/12 10:38
2 張三 增加了License人數限制 7/12 18:09
3 李四 財務部門調整了合同金額 7/13 9:51
4 張三 延長了免費升級周期 7/14 15:17
這樣,你就結束了手動管理多個「版本」的史前時代,進入到版本控制的20世紀。

❿ Git分支管理的框架版本同步設計

理解並合理使用git各種分支,便可實現高可用的商用開發模式。

Git 在整個開發周期會保持兩個「並行」的主要分支:

①origin/master:該分支的源碼HEAD始終指向可立即用於生產環境的狀態;

②origin/develop:該分支的源碼HEAD總是反映下一個版本的最新開發狀況。也可以叫它」整合分支「,從它開始每日的構建;

# 輔助分支 的使用

除了master和develop兩個主分支外,我們還需要其他輔助分支去完成並行開發、版本發布、快速修復生產環境Bug等操作,這些輔助分支的生命周期較短,通常在完成任務後立即被刪除。

①feature分支(功能分支):

從develop檢出:

shell> git checkout -b feature-xxx develop

完成功能後應該立即合並入develop分支,以確保功能被合並到即將發布的版本之中:

shell> git checkout develop shell> git merge --no-ff feature-xxx

*--no-ff將在分支合並時創建新的提交對象,即使本次合並可以使用 fast-forward 提交。這可以避免丟失功能分支的歷史信息,把所有功能疊加提交入分支;

②release分支(發布分支):

從develop分支檢出

shell> git checkout -b release-*.* develop// *.*為版本號

這個分支主要用於 追求一些細節修改、小Bug修復以及發布版本的數據修改等,該分支不能用於大功能的開發,在版本發布完成之後合並回develop分支並清除。

# 發布進 mastershell> git checkout master shell> git merge --no-ff release-*.* shell> git tag -a *.*
# 合並回 developshell> git checkout develop shell> git merge --no-ff release-*.*

③hotfix分支(熱修復分支):

該分支可能從master分支檢出,其本質是用於對生產版本進行快速修復。由於develop分支上的開發還不足夠穩定,無法並入生產版本,衍生出熱修復分支來解決問題

shell> git checkout -b hotfix-*.* master

在完成Bug修復之後,該分支需要合並回master和develop分支,以保證下一個版本中也修復了該Bug。操作與發布分支相似

# 合並入 mastershell> git checkout master shell> git merge --no-ff hotfix-*.* shell> git tag -a *.*.*
# 合並入 developshell> git checkout develop shell> git merge --no-ff hotfix-*.*

來源:Git中各種分支的使用