版本控制

Python入门——安装与PIP Python下载 安装 版本控制 各个版本安装到不同目录下： 版本设置： 运行 运行pip37版本： 运行python38版本： PIP换源 临时使用pip源方法： 永久换源方法： Linux方法： Windows方法： pip使用 pip介绍 依赖包查询 pip说明： pip安装某一个库： pip卸载某个库 pip升级某个包 pip列出当前已经安装可升级的包 pip批量升级过期包 使用pip-review批量升级 使用py脚本升级批量升级 参考文档 Python下载 官网：https://www.python.org/ windows下载地址：https://www.python.org/downloads/windows/ 64位操作系统，选择：Download Windows x86-64 executable installer 安装 安装时选择默认目录/自定义目录，切记添加系统环境变量。 版本控制 安装多个版本时，需要进行版本控制。 各个版本安装到不同目录下： 版本设置： 1.更改python.exe名称 2.更改pip.exe名称 同样设置其他版本。 运行 运行pip37版本： 运行python38版本： PIP换源 由于默认pip源为国外镜像，速率较慢，需要更换PIP源为国内镜像： 临时使用pip源方法： 可以在使用pip的时候加参数

一、基础配置 1、安装 ]# yum install -y git 2、配置用户信息 配置用户联系方式：名字、email ]# git config --global user.name "Mr.Zhang" ]# git config --global user.email "zk@qq.com" 配置写日志使用的文本编辑器 ]# git config --global core.editor vim 查看配置信息 ]# git config --list user.name=Mr.Zhang user.email=zk@qq.com core.editor=vim ]# cat ~/.gitconfig [user] name = Mr.Zhang email = zk@qq.com [core] editor = vim 二、应用 1、git的三个工作区域 工作区：编写程序的目录 暂存区：保存工作区文件到版本库之间的缓冲地带 版本库：保存每次提交的代码。在工作区中有一个.git的目录，它就是版本库 2、创建git工作区 (1) 全新创建 ]# git init gittest # 将会出现gittest目录 初始化空的 Git 版本库于 /root/gittest/.git/ (2) 已存在目录 ]# mkdir devops ]# cd devops/ devops]#

编程江湖中一直盛传着一个段子，那就是要问程序员最讨厌哪 4 件事？那必须是： 写注释、写文档、别人不写注释、别人不写文档。 当你让程序员写一个项目，或者和同事共同完成一个项目的时候，如果你不做好注释的话，那么你可能会受到整个团队程序员的集体关爱。因为每个程序员的基础不一样，而且入门的编程语言也不一样，但是大多数语言都遵循相同的思想。所以，他们也会出现相同的问题。 编程不规范，同事两行泪！为了警醒各位可爱的程序员们，特意给大家整理了一下。以下是编程七宗罪，你可以想办法避免他们发生。虽然我不是基督教徒，但是我也喜欢定义七宗罪。 作者 | Nitin Sharma，全栈开发者 01. 协作时不使用版本控制 上帝保佑，我们有版本控制工具。如我所说，如果我们没有像 Git 这种版本管理工具，代码的世界将变得异常艰难。版本控制让我们在协作的时候，修改或移动变得非常简单。 想像一下，我们坐在电脑前，手动检查并合并文件，为不同的版本保存不同的文件夹。这样做是非常低效的，并且很不可靠。幸运的是，我们有 Git 和其它版本控制工具，来帮我们完成这个事情。 我参与过没有版本控制的项目，那简直就是一场恶梦。 02. 不使用合适的变量命名 我不知道为什么，身边总有一些人，使用很短 / 随机的名称来给变量命名。当你的项目只有 10-20 行代码，或者只是代码片段时，你可以使用这种方式进行命名，但是在大项目中

目的 我打算把所有服务器的配置文件用git管理起来，这样可以记录配置变更状况。 但是有一个问题是，如何多人协作？服务器配置信息非常敏感，如果这个版本库泄漏，整个公司的服务器架构就彻底泄漏了。 这个版本库只能在开发者本地电脑里面解密，远程托管版本库的服务器不应该知道文件里面的内容。 那么解决办法就是：本地git版本库是解密的，在上传过程中内容全部加密，密钥保存在本地，同时密钥可以分享给其他开发者。 考虑了几个解决方案： git-crypt ：可以加密部分文件，原理是加上了加密的fiter和diff， 但是官方说只适合加密部分文件，而不适合全版本库加密。部分文件加密很容易造成信息泄漏，一定要全版本库加密才适合。 串联 sshfs 和远程服务器加密文件系统 encfs ：首先用 sshfs 加载远端文件系统，然后用 encfs 创建加密文件系统。 我估计无法解决多人同时 push 情况下的竞争条件，并且encfs有安全漏洞，使用 上push/pull 之前需要加载两层文件系统，不是很方便。 git-remote-gcryp t用 gpg 进行远端加密。 比较符合我预期的模式，但是用 gpg 不是特别方便协作。但是别的方法走不通，只有这个方法可用。 使用方法 安装git-remote-gcrypt和gnupg sudo apt-get install git-remote-gcrypt

idea如果当前project用了版本控制器，其下面新建的所有的项目默认都是加入到版本控制里面，所以项目名称和文件都是红色的，如图： 看起来非常不爽, 那么如何解决呢? File–》Settings–》version control 弹出的文件夹选择不需要加入版本控制的文件，然后点击OK，如图： 当选择了当前Project的名字后, 整个项目的红色就消失了, 是不是很开心? 参考资料: https://blog.csdn.net/jyh1314/article/details/61201746/ 来源： https://www.cnblogs.com/zjulanjian/p/10757217.html

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 关于版本控制 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。有以下三种版本控制系统： 1. 本地版本控制系统 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。图示如下， 2. 集中化的版本控制系统 集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）能够让在不同的开发系统上的开发人员协同工作。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法 3. 分布式版本控制系统 分布式版本控制系统(Distributed Version Control System，简称 DVCS ),像 Git，Mercurial，Bazaar 以及 Darcs 等

用过SVN或CVS版本控制工具的朋友，在享受着它们给我们带来的方便的同时，也许也在为这么一件事情苦恼： 如果某个目录在SVN或CVS版本控制工具的控制之下时。该目录下以及该子孙目录下都会有一个.svn目录或CVS目录。当我们想让该目录脱离版本控制工具控制时，想删除这些.svn目录或CVS目录。一个一个手动删除吗？目录树大了呢？有成百上千个分支目录也要手动删除吗？ NO。有更简便的方法，即可实现一键删除。操作步骤如下： 步骤一、编写注册表脚本 新建一个文本文件，把下面的代码COPY进去，保存为delSVNorCVS.reg. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteCVSOrSVN] @="Delete CVS/SVN Folders" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteCVSOrSVN\command] @="cmd.exe /c \"TITLE Removing CVS/SVN Folders in %1 && COLOR 9A && FOR /r \"%1\" %%f IN (.svn,CVS) DO RD /s /q \"%%f\" \"" 步骤二

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> @author ninghao.net git commit --help git config --list git config --unset --global user.name git config --global color.ui true cat ~/.gitconfig git log --oneline git log --oneline -n 10 --graph --decorate --all git log --oneline --grep='index.html' ＃ 搜索带关键词的log git log --oneline --after='2015-09-12' git log --oneline --before='1 week' git diff git diff --staged (老版本是 git diff --cached) git diff master..awesome 对比master和awesome两个分支的不同 git mv before.txt after.txt 等价于git rm before.txt; git add after.txt git mv old_path/test.txt new_path/test.txt git rm file

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Intro 版本控制系统是什么 版本控制系统(Version Control System,VCS)可以帮助我们记录和跟踪项目中各文件内容的修改变化。它可以帮我们保存项目的各个版本，以及修改原因，我们可以借用此工具回到项目曾经的某个状态。除此之外，版本控制系统也是帮助人员进行协作开发的利器。 Git是什么 Git是一个分布式版本控制系统(Distributed Version Control System,DVCS)。与传统的集中式版本控制系统(如CVS、Subversion和ClearCase)相比，Git具有以下优势： 分布式体系结构：可以完全断网工作，不受网络连接的限制 分支与合并操作很容易：创建分支简单、经济、快速，Git只会保存与主干的差异，这与其他版本控制系统不一样。Git把分支上所有修改合并回父分支，即使多次，也只是一眨眼的功夫 跟Subversion进行交互：Git可以从SubVersion的版本库中导入所有的历史，并把你在Git中的改动发送回Subversion的版本库 版本库 版本库(Repository)是版本控制系统用来存储所有历史数据的地方。大多数版本控制系统在版本库中存储各个文件的当前状态、历史修改时间、谁做的修改、以及修改的原因、还有修改的内容。 常见的版本控制系统可以分为两种类型

前言 关于这个主题，之前我录了段视频教程，在本地看清晰度还可以，但传到优酷上就很不清晰了，即使是后来重制后还是一样不清晰，所以现在想整理成文字版。当然，大家还可以将我百度云上的视频下载下来观看，连同优酷的相关地址都附在文末了。 正文 说到Git呢，相信从事软件开发的都不陌生，是用于 版本控制的，在全球范围内被广泛使用，相比于另一版本控制技术——SVN，似乎更受追捧一些，全球最大的代码托管平台GitHub使用的就是Git技术。 Git与SVN的最主要的区别就是，Git的代码仓库是分布式的，一般流程就是在本地拉一个服务器上仓库的拷贝，修改代码后先提交到本地仓库，然后再合并到远程仓库；而SVN的代码仓库是集中式的，一般就服务器上的一个，提交代码就是直接提交到服务器上的仓库去，这样如果网络不畅就无法提交了，那段时间就无法版本控制了。 还有一点比较明显的区别，不过我不知道我说的对不对，大家听且听之，自行判断。Git由于有本地仓库，工作目录一般就在本地仓库那里，从文件角度上看不出两个分支的文件分别在哪里，似乎工作目录下同时只存在一个分支。而SVN则能够清晰地看到哪些是主干的文件，哪些是分支的文件。 长久以来，Git都是以命令行方式使用的，而SVN在Windows上则有TortoiseSVN这样的强大的图形界面工具，这就形成了鲜明对比。对于刚入门的人