Git学习笔记(SourceTree克隆、提交、推送、拉取等)

本文详细介绍如何使用SourceTree进行Git操作,包括克隆、提交、推送、拉取、版本回退、检出及标签使用,适合初学者快速掌握SourceTree与Git的基本流程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转:https://www.cnblogs.com/gamedaybyday/p/6373312.html

学习一下sourcetree使用git

目录

一 克隆Clone

二 提交Commit和推送Push

三 拉取pull和获取fetch

四 版本回退reset

五 检出checkout

六 标签Tag

 

 

一 从远程库克隆Clone

Clone就是将远程库的代码拷贝到本地。

 

填写远程和本地项目路径,点击“克隆“。这样就会将服务器上项目代码克隆到本地了。

git -c diff.mnemonicprefix=false -c core.quotepath=false clone --recursive https://git.coding.net/gamedaybyday/HelloGit.git D:\Git\HelloGit
Cloning into 'D:\Git\HelloGit'...

 

二 提交Commit和推送Push

commit将工作空间修改提交到本地库。

push将本地库修改提交到远程库。

新建一个test.txt来测试,任意改点什么。在文件状态处可查看,红色为删除,蓝色为增加部分。

 

 将修改后文件由未暂存文件,勾选到已暂存文件。

选择提交

 

 添加修改日志。

这里如果勾选“立即推送变更”则会同时执行commit和push。

 

 

 

git -c diff.mnemonicprefix=false -c core.quotepath=false commit -q -F C:\Users\gzy\AppData\Local\Temp\ofkmvj0p.tft

 

 这时,修改的代码提交到了本地仓库。sourcetree会提示有修改代码尚未推送到远程库。

 

 选择推送。将本地仓库推送push到远程库。

 

1

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags origin master:master

 

三 拉取pull和获取fetch

pull 从远程拉取最新版本 到本地  自动合并 merge

fetch   从远程获取最新版本 到本地   不会自动合并 merge

 

虚线表示拉取到本地仓库

实现表示拉取到本地仓库,并合并到工作空间

git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin
From https://git.coding.net/gamedaybyday/HelloGit
   9664a7c..42c8f2e  master     -> origin/master
git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin

git -c diff.mnemonicprefix=false -c core.quotepath=false pull origin master
From https://git.coding.net/gamedaybyday/HelloGit
 * branch            master     -> FETCH_HEAD

 

假如有冲突,使用解决冲突。

 

 

 四 版本回退reset

reset 将当前版本回退到选定的版本

 

 

 

git -c diff.mnemonicprefix=false -c core.quotepath=false reset -q --mixed 657cf95e9925724ea54f81c2dc03f09ab025d571

 

 五 检出checkout

checkout 创建分支,切换分支。

checkout时,如果只有当前分支,则会新建一个分支。

如果是两个分支间checkout,则会切换分支。

 

 

 

将项目从最新checkout到modify11:46,这时HEAD指向到modify11:46这个版本。

 

git -c diff.mnemonicprefix=false -c core.quotepath=false checkout 657cf95e9925724ea54f81c2dc03f09ab025d571
Note: checking out '657cf95e9925724ea54f81c2dc03f09ab025d571'.

 

当修改这个checkout的分支时。可以看到从modify11:46checkout后,修改的提交会忽略到modify11:47以后的提交。

相当于checkout命令 创建了新分支,并切换到了这个分支。

 

 

但是这个分支是不存在的。要新建一个分支。

 

 

 六 标签Tag

tag 就是给这个版本打个标记,方便用于识别查看等操作。

 

 

 

 

git -c diff.mnemonicprefix=false -c core.quotepath=false tag -a -m "" tag3

 

<think>我们正在讨论的是在提交代码之前是否需要先更新。根据Git的最佳实践,在提交更新是一个好习惯,但并不是强制性的。然而,在多人协作的项目中,为了避免冲突和保持代码同步,通常建议在提交前先最新的代码。 引用[2]中提到: 1. 在本地修改与远程代码无冲突的情况下,优先使用:pull->commit->push 2. 在本地修改与远程代码有冲突的情况下,优先使用:commit->pull->push 所以,是否必须先更新决于具体情况: 1. **无冲突情况**:先(pull)最新代码,然后提交(commit)你的修改,最后推送(push)到远程仓库。这样可以保证你的本地代码是最新的,避免推送时因为落后远程仓库而产生冲突。 2. **有冲突情况**:如果你在本地修改的文件与远程仓库的最新修改有冲突,那么先(pull)会提示冲突。此时,你可以先提交(commit)你的修改(注意:提交后你的修改在本地仓库,但尚未与远程同步),然后(pull)最新代码,这时Git会尝试合并,如果有冲突需要手动解决冲突,解决后再提交(commit)一次,最后推送(push)。 但是,引用[2]也提到,如果你先执行了pull而存在冲突,Git会给出错误提示,这时你可以按照第二种方式处理(即先提交,再解决冲突,再推送)。 因此,在Sourcetree提交代码前,并不一定强制必须先更新,但为了减少冲突和保持代码同步,强烈建议先更新。具体操作流程如下: ### 推荐操作流程(无冲突时): 1. 点击Sourcetree顶部的“”按钮,从远程仓库获最新代码并合并到当前分支。 2. 解决可能出现的冲突(如果有冲突,需要手动解决并提交)。 3. 暂存(Stage)你要提交的文件。 4. 填写提交信息,点击“提交”按钮。 5. 点击“推送”按钮,将提交推送到远程仓库。 ### 如果存在冲突(或者你担心有冲突): 1. 先暂存并提交你的修改(这样你的修改在本地仓库,不会丢失)。 2. 点击“”按钮,远程更新,此时如果有冲突,Sourcetree会提示冲突。 3. 解决冲突(在冲突文件中手动合并,然后标记为已解决)。 4. 再次提交(因为解决冲突后需要提交合并结果)。 5. 推送。 注意:在Sourcetree中,(Pull)操作相当于执行了`git fetch`和`git merge`两个操作,所以会尝试自动合并。如果自动合并失败,就会产生冲突。 ### 为什么推荐先? 因为如果你在本地提交之前没有最新的远程代码,那么当你推送时,可能会因为远程有新的提交而导致推送失败(提示你需要先)。这样你就需要先,然后解决冲突,再推送。而如果你在提交前就并解决了冲突,那么推送就会更顺利。 但是,如果你是在一个独立的分支上工作(例如你自己的特性分支),并且你确定这个分支只有你在修改,那么你可以先提交(或者直接推送,因为不会有冲突)。不过,为了养成良好的习惯,还是建议先。 总结:在Sourcetree提交代码前,并不强制必须先更新,但为了保持代码同步和避免后续冲突,强烈建议先更新。特别是在多人协作的分支(如开发分支dev)上工作时,更应该先提交。 引用[1]中提到的代码提交流程也是先主分支最新代码,然后合并到自己的开发分支,再推送。这进一步印证了先的重要性[^1]。 所以,答案是:不是必须,但强烈建议。 相关问题: 1. 在Sourcetree中如何解决合并冲突? 2. 如何配置Sourcetree提交前自动更新? 3. 为什么有时候更新后会出现冲突?</think>在 Sourcetree提交代码前**不强制要求必须先更新**,但根据不同的协作场景和修改内容,有不同的最佳实践策略: ### 🔍 核心原则:避免覆盖他人代码 是否需要先决于: 1. **是否与他人修改相同文件** 2. **当前分支的协作状态** 3. **代码冲突的风险程度** ### 📝 具体操作建议 #### ✅ 场景 1:修改独立文件(无冲突风险) ```mermaid graph LR A[修改独立文件] --> B[直接提交] B --> C[推送] ``` - **无需先**:如果修改的是他人不会触碰的文件(如新建工具类) - **操作流程**: 1. 暂存目标文件 → 提交推送 2. 推送时若提示落后远程,再执行 #### ⚠️ 场景 2:修改公共文件(可能冲突) ```mermaid graph TB A[修改公共文件] --> B[先最新代码] B --> C{有冲突?} C -->|是| D[解决冲突] C -->|否| E[提交修改] D --> E E --> F[推送] ``` - **必须**:当修改核心文件(如公共组件、配置文件) - **操作流程**: 1. 点击顶部 **""** 按钮 2. 如果有冲突: - 在冲突文件点右键 → **"解决冲突"** - 手动合并代码 → 标记为**已解决** 3. 提交修改 → 推送 ### ⚡ 最佳实践(推荐) 1. **每日首次工作前**:先最新代码 2. **提交前检查**: - 查看 **"日志/历史"** 标签页 - 确认远程分支是否有新提交(小云朵图标提示) 3. **分支策略**: ```mermaid gitGraph commit branch dev-xxx checkout dev-xxx commit checkout main commit checkout dev-xxx merge main ``` - 在自己的开发分支(如 `dev-xxx`)提交 - 定期将主分支合并到开发分支[^1] ### 💡 为什么有时不强制? - 当修改内容完全独立时,先提交可减少不必要的合并记录 - Sourcetree 推送时自动检测远程状态,落后时会提示: ```diff ! [rejected] dev-xxx -> dev-xxx (non-fast-forward) + 需要先执行 git pull ``` ### ❌ 高风险操作(禁止) - 在多人协作的分支(如 `dev/main`)直接提交而不 - 忽略推送时的 non-fast-forward 警告强制推送 > 📌 总结:**修改私有文件可直提交,修改公共文件必先**。养成提交前查看远程变更的习惯,可大幅减少冲突概率[^2]。 --- ### 🔄 相关问题 1. 如何在 Sourcetree 中解决合并冲突? 2. 什么情况下应该使用 `git rebase` 代替 `git pull`? 3. 如何配置 Sourcetree推送前自动检测远程更新? 4. 分支管理策略中 feature branch 和 develop branch 有何区别?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值