git提交代码

Genkins git远程分支代码拉取（四）

为君一笑 — Tue, 07 Apr 2020 02:12:03 +0000

Genkins git远程分支代码拉取（四）为君一笑 2020-04-07 10:12:03

1.远程拉取gitlab 工程分支，并在本地建立分支

具体过程

新建一个空文件

初始化 git init

自己要与origin master建立连接（下划线远程仓库链接）
git remote add origin http://192.168.9.10:8888/root/game-of-life.git

把远程分支拉到本地（game-of-live-first_branch为远程仓库的分支名）
git fetch origin game-of-live-first_branch

在本地创建分支game-of-live-first_branch并切换到该分支
git checkout -b game-of-live-first_branch origin/game-of-live-first_branch

把game-of-live-first_branch远程分支上的内容都拉取到本地
git pull origin game-of-live-first_branch

2.修改分支的内容并上传给远程分支

3.如果想在linux中拉取远程分支代码

[root@localhost rollBack]# git init
Initialized empty Git repository in /test/rollBack/.git/
[root@localhost rollBack]# git remote add origin git@192.168.9.10:root/game-of-life.git
[root@localhost rollBack]# git fetch origin game-of-live-first_branch
remote: Enumerating objects: 1770, done.
remote: Counting objects: 100% (1770/1770), done.
remote: Compressing objects: 100% (582/582), done.
remote: Total 1770 (delta 1112), reused 1770 (delta 1112)
Receiving objects: 100% (1770/1770), 15.00 MiB | 28.20 MiB/s, done.
Resolving deltas: 100% (1112/1112), done.
From 192.168.9.10:root/game-of-life

branch game-of-live-first_branch -> FETCH_HEAD
[root@localhost rollBack]# git pull origin game-of-live-first_branch
From 192.168.9.10:root/game-of-life

branch game-of-live-first_branch -> FETCH_HEAD

4.git使用

4.1.源码安装git
[root@localhost ~]# yum -y install curl-devel expat-devel gettext-devel openssl-devel zlib-devel
[root@localhost ~]# yum -y install perl-ExtUtils-MakeMaker package
[root@localhost ~]# tar xvf git-2.9.5 -C /usr/src/
[root@localhost ~]# cd /usr/src/git-2.9.5
[root@localhost git-2.9.5]# make configure
GIT_VERSION = 2.9.5
GEN configure
[root@localhost git-2.9.5]# ./configure --prefix=/usr/local/
[root@localhost git-2.9.5]# make && make install

4.2.配置git

[root@localhost git-2.9.5]# git config --global user.name "yunjisuan" #配置git使用用户
[root@localhost git-2.9.5]# git config --global user.email "102110504@qq.com" #配置git使用邮箱
[root@localhost git-2.9.5]# git config --global color.ui true #语法高亮
[root@localhost git-2.9.5]# git config --list 查看全局配置br/>user.name=yunjisuan
user.email=102110504@qq.com
color.ui=true

查看生成的配置文件并添加新模块 #在root下

[root@localhost ~] # cat .gitconfig
[user]
name = clsn
email = admin@znix.top
[color]
ui = true

[root@localhost ~]# cat .gitconfig
[user]
name = git
email = 102110504@qq.com
[color]
ui = true
[recevice] #添加此模块
denyCurrentBranch = ignore

获得配置命令的手册 #三种方法

git help <verb>
git <verb> --help
man git-<verb>

4.3.配置ssh，增加rsa认证

修改配置文件，增加下面内容
[root@localhost ~]# vi /etc/ssh/sshd_config
RSAAuthentication yes
PubkeyAuthentication yes

重启
[root@localhost ~]# systemctl restart sshd

4.4.获取git仓库（初始化仓库）

[root@localhost ~]# mkdir /git_data #创建目录
[root@localhost ~]# cd /git_data/
[root@localhost git_data]# git init #初始化目录
Initialized empty Git repository in /git_data/.git/
[root@localhost git_data]# git status #查看工作区状态
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)

添加并提交文件
[root@localhost git]# touch README
[root@localhost git]# echo "please read first" >> README
[root@localhost git]# git add *
[root@localhost git]# git commit -m "first commit"

5.git仓库的管理

5.1向git内增加文件：

创建文件
[root@localhost git_data]# touch README
[root@localhost git_data]# ls
README
[root@localhost git_data]# git status
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)
[root@localhost git_data]# git add ./ #添加文件跟踪
[root@localhost git_data]# git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README
[root@localhost git_data]# tree .git
.git
├── branches
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ └── update.sample
├── index
├── info
│ └── exclude
├── objects
│ ├── e6
│ │ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391 #查看隐藏目录下增加了一条文件
│ ├── info
│ └── pack
└── refs
├── heads
└── tags
10 directories, 15 files
[root@localhost git_data]# git commit -m 'first commit' #由工作区提交到本地仓库
[master (root-commit) 621be41] first commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README
[root@localhost git_data]# git status #查看git的状态
On branch master
nothing to commit, working tree clean
[root@localhost git_data]# tree .git/ #提交后的git目录状态
.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ └── update.sample
├── index
├── info
│ └── exclude
├── logs
│ ├── HEAD
│ └── refs
│ └── heads
│ └── master
├── objects
│ ├── 54
│ │ └── 3b9bebdc6bd5c4b22136034a95dd097a57d3dd
│ ├── 62
│ │ └── 1be41481cd4dd65b58d1400173228125cdeb5b
│ ├── e6
│ │ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│ ├── info
│ └── pack
└── refs
├── heads
│ └── master
└── tags
15 directories, 21 files
总结说：
git add 添加到暂存区域
git commit 提交git仓库 -m 后面接上注释信息，内容关于本次提交的说明，方便自己或他人查看

5.2删除git内文件

1）没有添加到暂存区的数据直接rm删除即可。
2）已经添加到暂存区数据：
git rm --cached database
#→将文件从git暂存区域的追踪列表移除(并不会删除当前工作目录内的数据文件)
git rm -f database
#→将文件数据从git暂存区和工作目录一起删除

5.3改（重命名数据）

1）没有添加到暂存区的数据直接mv/rename改名即可。
2）已经添加到暂存区数据：
git mv README NOTICE #这个改的时候工作目录里的文件名字也改了

5.4查（查看历史记录）
• git log #→查看提交历史记录
• git log -2 #→查看最近几条记录
• git log -p -1 #→-p显示每次提交的内容差异,例如仅查看最近一次差异
• git log --stat -2 #→--stat简要显示最近两次，数据增改行数，这样能够看到提交中修改过的内容，对文件添加或移动的行数，并在最后列出所有增减行的概要信息
• git log --pretty=oneline #→--pretty根据不同的格式展示提交的历史信息
• git log --pretty=fuller -2 #→以更详细的模式输出提交的历史记录
• git log --pretty=fomat:"%h %cn" #→查看当前所有提交记录的简短SHA-1哈希字串与提交着的姓名。
使用format参数来指定具体的输出格式
格式说明
%s 提交说明
%cd 提交日期
%an 作者的名字
%cn 提交者的姓名
%ce 提交者的电子邮件
%H 提交对象的完整SHA-1哈希字串
%h 提交对象的简短SHA-1哈希字串
%T 树对象的完整SHA-1哈希字串
%t 树对象的简短SHA-1哈希字串
%P 父对象的完整SHA-1哈希字串
%p 父对象的简短SHA-1哈希字串
%ad 作者的修订时间

5.5还原历史数据

Git服务程序中有一个叫做HEAD的版本指针，当用户申请还原数据时，其实就是将HEAD指针指向到某个特定的提交版本，但是因为Git是分布式版本控制系统，为了避免历史记录冲突，故使用了SHA-1计算出十六进制的哈希字串来区分每个提交版本，另外默认的HEAD版本指针会指向到最近的一次提交版本记录，而上一个提交版本会叫HEAD^，上上一个版本则会叫做HEAD^^，当然一般会用HEAD~5来表示往上数第五个提交版本。
git reset --hard hash ：
• git reset --hard HEAD^ #→还原历史提交版本上一次
• git reset --hard 3de15d4 #→找到历史还原点的SHA-1值后，就可以还原(值不写全,系统会自动匹配)

5.6还原未来数据

什么是未来数据？就是你还原到历史数据了，但是你后悔了，想撤销更改，但是git log已经找不到这个版本了。
git reflog #→查看未来历史更新点
[root@localhost git_data]# git reflog
b6a6e89 HEAD@{0}: reset: moving to HEAD^
519bf0d HEAD@{1}: commit: third commit
b6a6e89 HEAD@{2}: commit: second commit
621be41 HEAD@{3}: commit (initial): first commit
[root@localhost git_data]# git reset --hard 519b #在删除third commit情况下返回third commit
HEAD is now at 519bf0d third commit

5.7标签使用

前面回滚使用的是一串字符串，又长又难记。
git tag v1.0 #→当前提交内容打一个标签(方便快速回滚)，每次提交都可以打个tag。
git tag #→查看当前所有的标签
git show v1.0 #→查看当前1.0版本的详细信息
git tag v1.2 -m "version 1.2 release is test" #→创建带有说明的标签,-a指定标签名字，-m指定说明文字
git tag -d v1.0 #→我们为同一个提交版本设置了两次标签,删除之前的v1.0
[root@localhost git_data]# git reset --hard HEAD^ #还原历史数据
HEAD is now at b6a6e89 second commit
[root@localhost git_data]# git reset --hard v1.0 #利用标签回滚
HEAD is now at 519bf0d third commit

5.8对比数据

git diff可以对比当前文件与仓库已保存文件的区别，知道了对README作了什么修改后，再把它提交到仓库就放⼼多了。
git diff README
[root@localhost git_data]# echo 222 >> README
[root@localhost git_data]# git diff README
diff --git a/README b/README
index 2bbe845..56c43c1 100644
--- a/README
+++ b/README
@@ -1,2 +1,3 @@
111
111
+222

6..分支结构

6.1 增加分支
git branch 分支名称

6.2分支切换
[root@localhost git_data]# git branch #查看分支
linux

master
[root@localhost git_data]# git checkout linux #切换到分支 'linux'
M README
Switched to branch 'linux'
[root@localhost git_data]# git branch

linux
master

6.3在linux分支进行修改

例：就是切换到分支后进行普通操作

echo "clsn in linux" >> README

6.4合并代码

合并Linux上的代码到master上

git merge linux

6.5合并失败解决

模拟冲突，在文件的同一行做不同修改

在master 分支进行修改
[root@gitlab git_data]# cat README
2017年11月30日
[root@gitlab git_data]# echo "clsn in master">> README
[root@gitlab git_data]# git commit -a -m "clsn 2017年11月30日 09点20分 "
[master 7ab71d4] clsn 2017年11月30日 09点20分
1 file changed, 1 insertion(+)

切换到linux分支
[root@gitlab git_data]# git checkout linux
[root@gitlab git_data]# cat README
2017年11月30日
[root@gitlab git_data]# echo "clsn in linux" >> README
[root@gitlab git_data]# git commit -a -m "2017年11月30日 03"
[linux 20f1a13] 2017年11月30日 03
1 file changed, 1 insertion(+)

回到master分区，进行合并，出现冲突
[root@gitlab git_data]# git checkout master
切换到分支 'master'
[root@gitlab git_data]# git merge linux

冲突（内容）：合并冲突于 README
自动合并失败，修正冲突然后提交修正的结果。

解决冲突
[root@gitlab git_data]# vim README
2017年11月30日
clsn in master
clsn in linux
#手工解决冲突
[root@gitlab git_data]# git commit -a -m "2017年11月30日 03"
[master b6a097f] 2017年11月30日 03

6.6删除分支

因为之前已经合并了linux分支，所以现在看到它在列表中。

在这个列表中分支名字前没有 * 号的分支通常可以使用 git branch -d 删除掉；你已经将它们的工作整合到了另一个分支，所以并不会失去任何东西。
git branch --no-merged #查看所有包含未合并工作的分支

git branch -d 分支name

7.服务器命令总结

服务器上的管理命令
   mkdir：                                  //XX (创建一个空目录 XX指目录名)
　　pwd： // 显示当前目录的路径。
　　git init //把当前的目录变成可以管理的git仓库，生成隐藏.git文件。
　　git add XX //把xx文件添加到暂存区去。
　　git commit –m “XX” //提交文件 –m 后面的是注释。
　　git status //查看仓库状态
　　git diff XX // 查看XX文件修改了那些内容
　　git log //查看历史记录
　　git reset --hard HEAD^ //或者 git reset --hard HEAD~ 回退到上一个版本(如果想回退到100个版本，使用git reset –hard HEAD~100 )
　　cat XX //查看XX文件内容
　　git reflog //查看历史记录的版本号id
　　git checkout -- XX //把XX文件在工作区的修改全部撤销。
　　git rm XX //删除XX文件
　　git checkout –b dev //创建dev分支并切换到dev分支上
　　git branch //查看当前所有的分支
　　git checkout master // 切换回master分支
　　git merge dev //在当前的分支上合并dev分支
　　git branch –d dev //删除dev分支
　　git branch name //创建分支
　　git stash //把当前的工作隐藏起来等以后恢复现场后继续工作
　　git stash list //查看所有被隐藏的文件列表
　　git stash apply //恢复被隐藏的文件，但是内容不删除
　　git stash drop //删除文件
　　git stash pop //恢复文件的同时也删除文件
　　git remote //查看远程库的信息
　　git remote –v //查看远程库的详细信息
　　
git remote add origin https://github.com/-- //关联一个远程库 --为路径
　　git push –u origin master //(第一次要用-u 以后不需要)把当前master分支推送到远程库
　　git push origin master //Git会把master分支推送到远程库对应的远程分支上
　　git clone https://github.com/--- // 从远程库中克隆 --为路径
   远程仓库相关命令
   检出仓库：       $ git clone 
   查看远程仓库：$ git remote -v
   添加远程仓库：$ git remote add 
   删除远程仓库：$ git remote rm 
   修改远程仓库：$ git remote set-url --push 
   拉取远程仓库：$ git pull 
   推送远程仓库：$ git push 
  *如果想把本地的某个分支test提交到远程仓库，并作为远程仓库的master分支，或者作为另外一个名叫test的分支，如下：
   $git push origin test:master         // 提交本地test分支作为远程的master分支
   $git push origin test:test              // 提交本地test分支作为远程的test分支

来源：51CTO

作者：运维小白菜

链接：https://blog.51cto.com/13893093/2175764

标签

origin

git

git提交代码

git切换分支

pycharm git 创建分支以及打标签（TAG）

浪尽此生 — Tue, 07 Apr 2020 01:50:29 +0000

pycharm git 创建分支以及打标签（TAG）浪尽此生 2020-04-07 09:50:29

前提
分支管理
标签管理
参考

前提

基于本地已创建git 项目

分支管理

1 VCS--->Git----> Branches

2 创建新分支或者选择本地已有分支

3 编辑器右下角可以快速创建分支以及切换分支

标签管理

1 VCS--->Git----> Tag

2 在Version Contral中右键选中一个提交历史可以创建分支或者标签

3 同步到git版本服务器

VCS--->Git----> Push

选中 push tags ALL

4 在服务器端可以查看到标签以及分支

参考

仓库的分支(Branch)规范，影响到每个团队的工作流的一致性；标签(Tag)便于开发团队、测
试团队和其他团队识别每个项目的版本，特别是在协同处理线上问题的时候，大家可以非常清楚
地知道线上运行版本和代码库的对应关系。因此我们在制作的时候，主要考虑几个因素：

一是要有一定的规则，方便持续集成CI（自动化构建、测试、分布等）
二是要有一定的自由度，以适应不同团队的内部协作灵活性
要清晰规整，不要参差不齐难以识别

基于我们当前团队的协作能力和提交代码的质量水平，并考虑方便持续集成CI（自动化构建、
测试、发布），我们约定下列常驻Branch：

develop 分支：顾名思义即持续开发的分支，我们希望每个开发组都在这个分支上保
持线性的持续小步迭代，正常的CodeReview WorkFlow和开发级的自动CI也在这里进行。
当开发完一个迭代(Sprint)，开发小组有信心转测时，就将代码合并到 release 分支，
并要求打一个alpha级的Tag(如5.2.0-alpha)
release 分支：顾名思义即用于发布过程的分支，包括开发转测(实际上我们认为这里的测试集成测试)、测试和BugFix以及发布上线的过程，当发布成功时要打一个发布beta Tag(如
5.2.1-beta)，并将代码合并到 master 分支
master 分支：即有质量保证的、可安全运行的分支，禁止直接代码提交，避免被污染，仅用
于代码合并和归集，在这个分支上的代码应该永远是可用的、稳定的。当需要拉一个特别的开发分时，
应该基于 master。
当需要fix线上的一个问题是，应该基于上线时的那个beta Tag做hotfix。当出现线上Bug需要hotfix时，我们需要在上次上线的Tag处拉一个临时的 hotfix 分支进行
修正，或者在未被其他开发迭代污染的release分支上直接hotfix上线并合并到master和
develop，然后打一个新的Tag(如5.2.2-beta）

这个分支体系是我们期望长期持续迭代的分支规划，其它临时分支的删除、创建、命名，都由团队自己
决定，保持一定的灵活性。但每个团队都应该努力避免对上述常规情况造成破坏的情况发生，如果有特
殊情况（如有两个并行的开发分支同步进行），需要由各组Leader和QA团队协商提供临时方案，这会
影响到团队协同中的转测、CI基准分支等。

关于打 Tag 的规则：

鼓励开发和QA团队共同对勤于打Tag，这便于真正的版本管理，避免有rollback需要或者需要查看和
对比历史版本的时候的混乱和低效局面。但同时也要求一定的规范性，让人一看便知。

Tag格式为： MajorVersion.MinorVersion.FixVersion-TypeLabel，其中TypeLabel
为 alpha、 beta、 devel。具体参见下图举例，其中devel是留给开发过程中
使用的。

分工上，开发团队负责打 tag-alpha，测试团队负责打 tag-beta。

但是，自己决定并不意味着胡乱命名，大家仍然要以语义明（白）（准）确的原则
来管理自己的分支和标签名，因为所有这些都是为了提高协作效率。

这是一个参考示意图：

事实上，上图和常用的 Git 分支实践是比较相似的，只是为了方便自动化工作，我们将 release 分支常驻并配合 tag 管理了，其他工作的 workflow 基本相似，如下图：

这里写图片描述

必读经典：A successful Git branching model

参考文章：GIT分支管理是一门艺术
参考：https://blog.csdn.net/iprettydeveloper/article/details/53944125

来源：https://www.cnblogs.com/lduml/p/12651449.html

标签

git

git切换分支

git提交代码

git的学习笔记

本秂侑毒 — Mon, 06 Apr 2020 21:53:16 +0000

git的学习笔记本秂侑毒 2020-04-07 05:53:16

1. 安装git
centos上

yum install -y epel-release
yum install -y git

2. 创建版本库

mkdir  /home/gitroot
cd /home/gitroot
git init   ##用这个命令初始化，让这个目录变成git可以管理的仓库

3. 提交文件到仓库
创建一个文件 1.txt

echo -e "123\naaa\n456\nbbb" > 1.txt

git add 1.txt  //把1.txt添加到仓库中
git commit -m "add new file 1.txt"   //add完了必须要commit才算真正把文件提交到git仓库里

初始使用该命令会提示：
*** Please tell me who you are.

Run

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

这是要让我们设置用户邮箱和用户名。根据它提示设置一下即可：
git config --global user.email "aming@aminglinux.com"

git config --global user.name "aming"

echo -e "111111\n2222222222" >> 1.txt  //先更改一下1.txt
git status //查看当前仓库中的状态，比如是否有改动的文件
git diff 1.txt  //可以对比1.txt本次修改了什么内容，相比较仓库里面的版本

4. 版本回退
多更改几次1.txt，并进行 git add,  git commit操作
git log  //可以查看所有提交git仓库的记录操作
git log --pretty=oneline  //一行显示，更清楚

通过git log我们可以查看到过去提交的所有版本，所以根据这个log，我们可以指定回退某个版本
比如，结果如下
git log --pretty=oneline
142dde7c32cf8c2e4b59b6fafae468dedbb72ff9 change 1.txt
0ff5ab178ea2207e71fbe935c57a8ef1c30f63d7 change 1.txt
5aacaf4341484186802faed7d2db87840b2adc66 new file 2.txt
73235a8549b7e9cfa171d632e1a8f0d91cd0a0d5 new file

git reset --hard 0ff5ab1  //可以回退到第二行的这个版本，这里后面跟的字符串可以简写。
当回退到该版本后，再  git log 则最上面的版本不再显示了，那如果想再倒回退到第一行那个版本怎么办？
git reflog  //可以显示所有的版本

5. 撤销修改
修改1.txt，发现改的不对，想恢复到上一次提交时的状态。或者1.txt不小心给删除掉了。可以使用
git checkout -- 1.txt  //恢复到上一次提交时的状态

如果1.txt修改完了，保存后，git add 1.txt了，但没有commit，再想回退到上一次提交时的状态。可以使用
git  reset HEAD 1.txt
然后再
git checkout -- 1.txt

那如果不仅add也commit了，那就用第4版本回退的方法。

6. 删除
touch  2.txt
echo "22222222222222" > 2.txt
git add 2.txt
git commit -m "add new file 2.txt"

上面的操作，我们在git仓库里提交了一个新的文件2.txt，下面删除它
rm -f 2.txt
git status //可以看到，提示2.txt文件被删除了
如果要想恢复，直接用  git  checkout -- 2.txt
现在是，我们想在git仓库里删除
git rm 2.txt
git commit -m "delete 2.txt"
这样就彻底删除了2.txt

7. 做一个远程仓库（github）
首先到 https://github.com 注册一个账号，创建自己的git，点repositories  --> new
名字自定义，比如叫studygit  选择public  点 create repository

添加key：
右上角点自己头像，选择settings，左侧选择SSH and GPG keys
右上角点New SSH key，把linux机器上的 /root/.ssh/id_rsa.pub内容粘贴到这里

把本地参考推送到远程仓库
git remote add origin git@github.com:aminglinux/studygit.git
git push -u origin master
下一次再推送，就可以直接 git push

下面我们克隆一个远程仓库过来
cd /home
git clone  git@github.com:aminglinux/lanmp.git
它提示，会在当前目录下初始化一个仓库，并创建一个.git的目录
Initialized empty Git repository in /home/lanmp/.git/

完成后，ls可以看到一个lanmp的目录
cd  lanmp
vi lanmp.sh 编辑一下文件，然后提交
git add lanmp.sh
git commit -m "sdlfasdf"
然后再推送到远程服务端
git push

8. 分支管理
查看分支
git branch

创建分支
git branch aming
git checkout  aming

在aming分支下，编辑2.txt，并提交到新分支
echo "askdfjlksadjflk" >  2.txt
git add 2.txt
git commit -m "laksjdflksjdklfj"

切换回master分支
git checkout master

合并分支
git merge aming //把aming分支合并到了master

如果master分支和aming分支都对2.txt进行了编辑，当合并时会提示冲突，需要先解决冲突才可以继续合并。
解决冲突的方法是在master分支下，编辑2.txt，改为aming分支里面2.txt的内容。然后提交2.txt，再合并aming分支。
但是这样有一个问题，万一master分支更改的内容是我们想要的呢？我们可以编辑2.txt内容，改为我们想要的，然后提交。切换到aming分支，然后合并master分支到aming分支即可。（倒着合并）合并分支有一个原则，那就是要把最新的分支合并到旧的分支。也就是说merge后面跟的分支名字一定是最新的分支。

删除分支
git  branch -d aming
如果分支没有合并，删除之前会提示，那我们就不想合并，强制删除
git branch -D aming

对于分支的应用，建议大家以这样的原则来：
master分支是非常重要的，线上发布代码用这个分支，平时我们开发代码不要在这个分支上。
创建一个dev分支，专门用作开发，只有当发布到线上之前，才会把dev分支合并到master
开发人员应该在dev的基础上再分支成个人分支，个人分支（在自己pc上）里面开发代码，然后合并到dev分支

在dev分支合并bob分支的命令是：
git checkout dev //先切换到dev分支，然后
git merge bob

9. git stash 保留现场
当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。解决这个问题的办法就是git stash命令。

比如我们在aming分支，编辑了一个新的文件3.txt
这时候我们需要到其他分支去修复一个bug，所以需要先git add 3.txt
然后 git  stash  保存一下现场
再切换到另外分支去修复bug，修复完bug后，再回到aming分支
git stash list 可以看到我们保存过的现场
用 git stash apply 恢复现场
也可以指定stash：
git stash apply stash@{1}

10. 远程分支
查看远程库信息，使用git remote -v  本地新建的分支如果不推送到远程，对其他人就是不可见的
查看远程分支  git ls-remote origin
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

11. 标签管理
标签类似于快照功能，我们可以给版本库打一个标签，记录某个时刻库的状态。我们可以随时恢复到该状态。
git checkout master 先切到master分支上
git tag v1.0  给master打一个标签v1.0

git tag 可以查看所有的标签

tag是针对commit来打标签的，所以可以针对历史的commit来打tag
git log --pretty=oneline --abbrev-commit
git tag v0.9 46d3c1a
git tag -a v0.8 -m "tag just v1.1 and so on"  5aacaf4  //可以对标签进行描述

git tag -d v0.8  //删除标签

git push origin v1.0 //推送指定标签到远程
git push --tag origin //推送所有标签

如果本地删除了一个标签，远程也想要删除需要这样操作：

git tag v1.0 -d
git push origin :refs/tags/v1.0

12. 巧用别名
git commit 这个命令是不是有点长？用别名可以提高我们的工作xiaol
git config --global alias.ci commit
git config --global alias.co  checkout
git config --global alias.br  branch

查看git别名使用命令
git config --list |grep alias

查询log小技巧：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

取消别名
git config --global --unset alias.br

13. 搭建git服务器
github毕竟是公开的，而私有仓库又得花钱买。所以我们可以想办法搭建一个私有的，只自己公司使用的。
yum install git //安装git
useradd -s /usr/bin/git-shell git //添加git用户，并且设置shell为/usr/bin/git-shell,目的是为了不让git用户远程登陆
cd /home/git
mkdir .ssh
touch .ssh/authorized_keys

chown -R git.git .ssh
chmod 600 .ssh/authorized_keys

定好存储git仓库的目录，比如 /data/gitroot
mkdir /data/gitroot
cd /data/gitroot
git init --bare sample.git // 会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以.git结尾
chown -R git.git sample.git

在客户端上（自己pc）克隆远程仓库
以上操作是在git服务器上做的，平时git服务器是不需要开发人员登录修改代码的，它仅仅是充当着一个服务器的角色，就像github一样，平时操作都是在我们自己的pc上做的。
首先要把客户端上的公钥放到git服务器上/home/git/.ssh/authorized_keys文件里
git clone git@ip:/data/gitroot/sample.git

此时就可以在当前目录下生成一个sample的目录，这个就是我们克隆的远程仓库了。进入到这里面，可以开发一些代码，然后push到远程。

来源：oschina

链接：https://my.oschina.net/u/613887/blog/742224

标签

Git Tag 标签

醉酒当歌 — Mon, 06 Apr 2020 19:43:17 +0000

Git Tag 标签醉酒当歌 2020-04-07 03:43:17

git tag 按字母排序显示标签

git tag v1.01 打上v1.01这个标签

git show v1.01 显示这个标签的详情

可以同时打多个tag指向同一个时间点上的版本

git push origin --tags 推送本地所有新增标签到远端

ps：下面看下git命令之git tag 给当前分支打标签

列出标签

$ git tag # 在控制台打印出当前仓库的所有标签

$ git tag -l ‘v0.1.*' # 搜索符合模式的标签

打标签

git标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象。建议使用附注标签。

# 创建轻量标签

$ git tag v0.1.2-light

# 创建附注标签

$ git tag -a v0.1.2 -m “0.1.2版本”

创建轻量标签不需要传递参数，直接指定标签名称即可。

创建附注标签时，参数a即annotated的缩写，指定标签类型，后附标签名。参数m指定标签说明，说明信息会保存在标签对象中。

切换到标签

与切换分支命令相同，用git checkout [tagname]

查看标签信息

用git show命令可以查看标签的版本信息：

$ git show v0.1.2

删除标签

误打或需要修改标签时，需要先将标签删除，再打新标签。

$ git tag -d v0.1.2 # 删除标签

参数d即delete的缩写，意为删除其后指定的标签。

给指定的commit打标签

打标签不必要在head之上，也可在之前的版本上打，这需要你知道某个提交对象的校验和（通过git log获取）。

# 补打标签

$ git tag -a v0.1.1 9fbc3d0

标签发布

通常的git push不会将标签对象提交到git服务器，我们需要进行显式的操作：

$ git push origin v0.1.2 # 将v0.1.2标签提交到git服务器

$ git push origin –tags # 将本地所有标签一次性提交到git服务器

注意：如果想看之前某个标签状态下的文件，可以这样操作

1.git tag 查看当前分支下的标签

2.git checkout v0.21 此时会指向打v0.21标签时的代码状态，（但现在处于一个空的分支上）

3. cat test.txt 查看某个文件

本文转载于：https://www.cnraksmart.com/210.html

来源：https://www.cnblogs.com/subaomg/p/9875605.html

标签

git 远程分支和tag标签的操作

纵饮孤独 — Mon, 06 Apr 2020 18:29:16 +0000

git 远程分支和tag标签的操作纵饮孤独 2020-04-07 02:29:16

git远程分支操作：
1、创建远程分支
git push --set-upstream origin develop:develop2
在服务器创建远程分支devlop2，让本地的develop分支和develop2分支相互关联
2、把本地代码推送到远程分支上
git push origin develop:develop2
把本地的develop分支上的代码推送到远程develop2分支上
3、删除远程的分支
git push origin --delete develop2
删除远程的develop2分支
4、查看本地分支与远程分支之间的关系
git remote show origin
5、把远程服务器的代码拉取到本地
git pull origin develop2:develop
把远程develop2分组的代码拉起到本地develop分支
git pull和git push可以总结为下面的形式
git push origin srcBranch:DestBranch
git pull origin srcBranch:DestBranch
都是从srcBranch到DestBranch
6、git tag的操作
7、在当前分支的某个提交节点上创建一个Tag标签
git tag -a v1.0 -m 'v1.0 release'
创建一个v1.0的tag，注释是v1.0 release
8、查看标签的具体信息，显示标签对应哪个commitid
show tag v1.0
9、查看当前分支存在哪些tag
git tag
10、把标签推送到服务器
git push origin v1.0
git push origin refs/tags/v1.0:refs/tags/v1.0
将v1.0的tag推送到服务器
11、把本地全部存在的tag推送到服务器
git push origin --tags
12、其他人如何获取服务器上的标签
git pull
git fetch origin tag v1.0
执行git pull就会把服务器存在的tag标签拉取到本地
13、删除远程的tag
git push origin --delete tag v5.0
14、删除本地的tag
git tag -d v5.0

来源：https://www.cnblogs.com/kebibuluan/p/10293300.html

标签

origin

git

git提交代码

git 实践(一) pull的使用

限于喜欢 — Mon, 06 Apr 2020 18:23:09 +0000

git 实践(一) pull的使用限于喜欢 2020-04-07 02:23:09

前言

工作中，我们会用到git pull来从远程仓库"同步"代码，通常有三种方式；

git pull origin <remote_branch>：<local_branch>
git pull origin <remote_branch>
git pull

这三种用法充分诠释了什么是简即繁，繁即简；看上去简单的，往往背后蕴藏玄机；

测试环境:
本地分支：master和dev
远程分支：master和dev

$ git branch -a
* dev
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/dev
  remotes/origin/master

1.git pull origin <remote_branch>：<local_branch>

这种用法写起来最为繁琐，但最好理解：

场景：当本地的当前分支不是local_branch；
作用：将远程分支拉取到指定本地分支；

例如：当前分支是dev，但是你想把远程master”同步”到本地master，但又不想使checkout切换到master分支；
这时你就可以使用git pull origin master：master

zhangchangzhi@ZBXXXX /e/02.Workspace-test/gitTest (dev)
$ git pull origin master:master
From https://github.com/jinxintang/gitTest
   a09fdc4..941758f  master     -> master
Already up-to-date.

从上述代码可以看到，我当前分支为dev,但执行"同步”操作的却是在master分支；

2.git pull origin <remote_branch>

有了上面的例子，这种使用方法的场景和作用就好理解了：

场景：在当前分支上进行同步操作；
作用：将指定远程分支同步到当前本地分支；

废话不说，上代码：

zhangchangzhi@ZBXXX /e/02.Workspace-test/gitTest (dev)
$ git pull origin master
From https://github.com/jinxintang/gitTest
 * branch            master     -> FETCH_HEAD
Already up-to-date.

把远程master分支同步到HEAD分支（HEAD分支指向当前位置）；

3.git pull

这种写法最简单，也最常用，但是隐含的知识也是最多的；

场景：本地分支已经和想要拉取的分支建立了“关联”关系；
作用：拉取所有远程分支的新版本"坐标"，并同步当前分支的本地代码(具体根据关联分支而定)

什么是"关联"分支?

首先我们先使用git branch -vv 查看一下目前分支的“关联”情况；

$ git branch -vv
* dev    1a1b215 [origin/dev] Merge branch 'master' of https://github.com/jinxintang/gitTest into dev
  master a09fdc4 [origin/master] create pull

可以看到我们的本地的dev关联的是远程(origin)的dev，本地的master关联的是远程(origin)的master;
那么这种关联是如何建立、是否可以修改呢；
配置本地分支与远程分支的三种方法：
1.检出时建立关联关系：git checkout -b dev origin/dev
当我们检查时，git会自动为我们检出的分支和远程分支建立关联关系；
2.提交时配置关联关系：git push -u origin <remote_branch>或git push --set-upstream origin <remote_branch>

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_zcz)
$ git branch -vv
* dev_zcz 3b7001a [origin/dev] cm
  master  a09fdc4 [origin/master] create pull

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_zcz)
$ git push -u origin dev_zcz
Everything up-to-date
Branch dev_zcz set up to track remote branch dev_zcz from origin.

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_zcz)
$ git branch -vv
* dev_zcz 3b7001a [origin/dev_zcz] cm
  master  a09fdc4 [origin/master] create pull

通过上面的例子可以看到push前dev_zcz关联的是origin/dev,执行push -u 后管理分支改为origin/dev_zcz
注：默认配置下，提交时本地分支需和远程分支同名；

3.更改git/config文件：git branch --set-upstream-to=<remote_branch>

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_zcz)
$ git branch --set-upstream-to=origin/zcz
Branch dev_zcz set up to track local branch origin/zcz.

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_zcz)
$ git branch -vv
* dev_zcz    3b7001a [origin/zcz] cm
  master     a09fdc4 [origin/master] create pull
  origin/zcz 3b7001a [dev_zcz] cm

无论使用上述那种方法，本地分支和远程分支的“关联”最终都会写到config文件；

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest/.git (GIT_DIR!)
$ cat config
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true
[remote "origin"]
        url = https://github.com/jinxintang/gitTest.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "dev_zcz"]
        remote = .
        merge = refs/heads/origin/zcz
[branch "origin/zcz"]
        remote = .
        merge = refs/heads/dev_zcz

注：本项目的配置信息存放目录：项目所在目录/.git/config
看完这三种配置关联分支的方法，想必大家已经对“关联分支”有了一定了解；

关联分支：在git中表现为upstream,无论是使用push -u 或是 git branch --set-upstream-to方法，均会将这种对应关系写入.git/config配置文件，如果一个本地分支没有关联分支，则无法执行 git push 或 git pull指令；

没有"关联"分支的情况下，使用push会先让你设置一个upstream branch.

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_no_upstream)
$ git branch -vv
* dev_no_upstream 3b7001a cm
  dev_zcz         3b7001a [origin/zcz] cm
  master          a09fdc4 [origin/master] create pull
  origin/zcz      3b7001a [dev_zcz] cm

zhangchangzhi@ZB-PF0SB6DQ MINGW64 /e/02.Workspace-test/gitTest (dev_no_upstream)
$ git push
fatal: The current branch dev_no_upstream has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin dev_no_upstream

那么建立了一个关联分支，是否就一定能使用git push呢？请阅读<git 实践(二)push的使用>

来源：https://www.cnblogs.com/jianxian/p/12650939.html

标签

Git 分支 - 远程分支

痞子三分冷 — Mon, 06 Apr 2020 17:04:03 +0000

Git 分支 - 远程分支痞子三分冷 2020-04-07 01:04:03

Git 分支 - 远程分支
远程分支
远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。

我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。比如我们想看看上次同 origin 仓库通讯时 master 分支的样子，就应该查看 origin/master 分支。如果你和同伴一起修复某个问题，但他们先推送了一个 iss53 分支到远程仓库，虽然你可能也有一个本地的 iss53 分支，但指向服务器上最新更新的却应该是 origin/iss53 分支。

可能有点乱，我们不妨举例说明。假设你们团队有个地址为 git.ourcompany.com 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 origin，并下载其中所有的数据，建立一个指向它的 master 分支的指针，在本地命名为 origin/master，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 master 分支，始于 origin 上 master 分支相同的位置，你可以就此开始工作（见图 3-22）：

图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 origin 上的 master 分支。
如果你在本地 master 分支做了些改动，与此同时，其他人向 git.ourcompany.com 推送了他们的更新，那么服务器上的 master 分支就会向前推进，而与此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 origin/master 指针仍然保持原位不会移动（见图 3-23）。

图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。
可以运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器（本例为 git.ourcompany.com），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 origin/master 的指针移到它最新的位置上（见图 3-24）。

图 3-24. git fetch 命令会更新 remote 索引。
为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 git.team1.ourcompany.com。可以用第二章中提到的 git remote add 命令把它加为当前项目的远程分支之一。我们把它命名为 teamone，以便代替完整的 Git URL 以方便使用（见图 3-25）。

图 3-25. 把另一个服务器加为远程仓库
现在你可以用 git fetch teamone 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 origin 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为 teamone/master 的远程分支，指向 teamone 服务器上 master 分支所在的提交对象 31b8e（见图 3-26）。

图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。
推送本地分支
要想和其他人分享某个本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操作而被自动同步到你引入的远程服务器上，你需要明确地执行推送分支的操作。换句话说，对于无意分享的分支，你尽管保留为私人分支好了，而只推送那些协同工作要用到的特性分支。

如果你有个叫 serverfix 的分支需要和他人一起开发，可以运行 git push (远程仓库名) (分支名)：

$ git push origin serverfix
Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 1.74 KiB, done.
Total 15 (delta 5), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git

[new branch] serverfix -> serverfix
这里其实走了一点捷径。Git 自动把 serverfix 分支名扩展为 refs/heads/serverfix:refs/heads/serverfix，意为“取出我在本地的 serverfix 分支，推送到远程仓库的 serverfix 分支中去”。我们将在第九章进一步介绍 refs/heads/ 部分的细节，不过一般使用的时候都可以省略它。也可以运行 git push origin serverfix:serverfix 来实现相同的效果，它的意思是“上传我本地的 serverfix 分支到远程仓库中去，仍旧称它为 serverfix 分支”。通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作 awesomebranch，可以用 git push origin serverfix:awesomebranch 来推送数据。

接下来，当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 origin/serverfix，并指向服务器上 serverfix 所指向的版本：

$ git fetch origin
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From git@github.com:schacon/simplegit

[new branch] serverfix -> origin/serverfix
值得注意的是，在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的 serverfix 分支，有的只是一个你无法移动的 origin/serverfix 指针。

如果要把该远程分支的内容合并到当前分支，可以运行 git merge origin/serverfix。如果想要一份自己的 serverfix 来开发，可以在远程分支的基础上分化出一个新的分支来：

$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
这会切换到新建的 serverfix 本地分支，其内容同远程分支 origin/serverfix 一致，这样你就可以在里面继续开发了。

跟踪远程分支
从远程分支 checkout 出来的本地分支，称为跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入 git push，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 git pull 会获取所有远程索引，并把它们的数据都合并到本地分支中来。

在克隆仓库时，Git 通常会自动创建一个名为 master 的分支来跟踪 origin/master。这正是 git push 和 git pull 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如 origin 上除了 master 之外的其它分支。刚才我们已经看到了这样的一个例子：git checkout -b [分支名] [远程名]/[分支名]。如果你有 1.6.2 以上版本的 Git，还可以用 --track 选项简化：

$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'
现在你的本地分支 sf 会自动将推送和抓取数据的位置定位到 origin/serverfix 了。

删除远程分支
如果不再需要某个远程分支了，比如搞定了某个特性并把它合并进了远程的 master 分支（或任何其他存放稳定代码的分支），可以用这个非常无厘头的语法来删除它：git push [远程名] :[分支名]。如果想在服务器上删除 serverfix 分支，运行下面的命令：

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git

[deleted] serverfix
咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的 git push [远程名] [本地分支]:[远程分支] 语法，如果省略 [本地分支]，那就等于是在说“在这里提取空白然后把它变成[远程分支]”。

来源：https://www.cnblogs.com/ITniu/p/7426795.html

标签

这篇关于git的使用方法你一定要看

白昼怎懂夜的黑 — Mon, 06 Apr 2020 09:09:06 +0000

这篇关于git的使用方法你一定要看白昼怎懂夜的黑 2020-04-06 17:09:06

以下的介绍只是基于我个人对于git的理解，并且可能生编硬造了一些不完全符合git说法的词语。目的只是为了让git通俗化，使初学者也能大概了解如何快速上手git。

同时，下面所有讨论，我们都假设只使用一个分支，也就是主分支master的情况，虽然这种作法并不符合git规范，但是现实情况中绝大部分用户是直接在master分支上进行工作的，所以在这里我们不去引入更加复杂的各种分支的情况，也不涉及标签tag的操作，只讲在最简单的主分支上如何回退。

3个步骤

正常情况下，我们的工作流就是3个步骤

git add .
git commit -m "comment"
git push

4个区

git之所以令人费解，主要是它相比于svn等等传统的版本管理工具，多引入了一个暂存区(Stage)的概念，就因为多了这一个概念，而使很多人疑惑。其实，在初学者来说，每个区具体怎么工作的，我们完全不需要关心，而只要知道有这么4个区就够了：

工作区(Working Area)
暂存区(Stage)
本地仓库(Local Repository)
远程仓库(Remote Repository)

5种状态

以上4个区，进入每一个区成功之后会产生一个状态，再加上最初始的一个状态，一共是5种状态。以下我们把这5种状态分别命名为：

未修改(Origin)
已修改(Modified)
已暂存(Staged)
已提交(Committed)
已推送(Pushed)

检查修改

了解了基本概念之后，我们来谈一谈犯错误之后如何撤销的问题。首先，我们要了解如何检查这3个步骤当中每一个步骤修改了什么，然后才好判断有没有修改成功。检查修改的二级命令都相同，都是diff，只是参数有所不同。

已修改，未暂存

git diff

首先，我们来看一下，如果我们只是简单地在浏览器里保存了一下文件，但是还没有做git add .之前，我们如何检查有哪些修改。我们先随便拿一个文件来做一下实验。

我们在文件开头的第2行胡乱加了4个数字1234，存盘，这时文件进入了已修改状态，但是还没有进入暂存区，我们运行git diff，结果如下

$ git diff
diff --git a/app/Http/Controllers/Admin/VideoController.php b/app/Http/Controllers/Admin/VideoController.php
index 5a3a49d..757c775 100644
--- a/app/Http/Controllers/Admin/VideoController.php
+++ b/app/Http/Controllers/Admin/VideoController.php
@@ -3,7 +3,7 @@
 * Created by PhpStorm.
 * User: cyw
 * Date: 2019/6/7
- * Time: 12:11
+ * Time: 12:111234
 */
 namespace App\Http\Controllers\Admin;

git diff的结果告诉我们哪些文件已经做了哪些修改。

已暂存，未提交

git diff --cached

现在我们把修改放入暂存区看一下。先执行git add .，然后执行git diff，你会发现没有任何结果。

这说明git diff这个命令只检查我们的工作区和暂存区之间的差异，如果我们想看到暂存区和本地仓库之间的差异，就需要加一个参数git diff --cached：

diff --git a/index.md b/index.md
index 73ff1ba..1066758 100644
--- a/index.md
+++ b/index.md
<a href='http://www.jobbole.com/members/li754132448'>@@</a> -1,5 +1,5 <a href='http://www.jobbole.com/members/li754132448'>@@</a>
 ---
-layout: main
+1234layout: main
 color: black
 ---

这时候我们看到的差异是暂存区和本地仓库之间的差异。

已提交，未推送

git diff master origin/master

现在，我们把修改从暂存区提交到本地仓库，再看一下差异。先执行git commit，然后再执行git diff --cached，没有差异，执行git diff master origin/master，可以看到差异：

在这里，master就是你的本地仓库，而origin/master就是你的远程仓库，master是主分支的意思，因为我们都在主分支上工作，所以这里两边都是master，而origin就代表远程。

撤销修改

了解清楚如何检查各种修改之后，我们开始尝试各种撤销操作。

已修改，未暂存

如果我们只是在编辑器里修改了文件，但还没有执行git add .，这时候我们的文件还在工作区，并没有进入暂存区，我们可以用：

git checkout .

或者

git reset --hard

来进行撤销操作。

可以看到，在执行完git checkout .之后，修改已被撤销，git diff没有任何内容了。

一对反义词 git add .的反义词是git checkout .。
做完修改之后，如果你想向前走一步，让修改进入暂存区，就执行git add .，
如果你想向后退一步，撤销刚才的修改，就执行git checkout .

已暂存，未提交

你已经执行了git add .，但还没有执行git commit -m "comment"。这时候你意识到了错误，想要撤销，你可以执行：

git reset
git checkout .

或者

git reset --hard

git reset只是把修改退回到了git add .之前的状态，也就是说文件本身还处于已修改未暂存状态，你如果想退回未修改状态，还需要执行git checkout .。

或许你已经注意到了，以上两个步骤都可以用同一个命令git reset --hard来完成。是的，就是这个强大的命令，可以一步到位地把你的修改完全恢复到未修改的状态。

已提交，未推送

你的手太快，你既执行了git add .，又执行了git commit，这时候你的代码已经进入了你的本地仓库，然而你后悔了，怎么办？不要着急，还有办法。

git reset --hard origin/master

还是这个git reset --hard命令，只不过这次多了一个参数origin/master，正如我们上面讲过的，origin/master代表远程仓库，既然你已经污染了你的本地仓库，那么就从远程仓库把代码取回来吧。

已推送

很不幸，你的手实在是太快了，你既git add了，又git commit了，并且还git push了，这时你的代码已经进入远程仓库。如果你想恢复的话，还好，由于你的本地仓库和远程仓库是等价的，你只需要先恢复本地仓库，再强制push到远程仓库就好了：

git reset --hard HEAD^
git push -f

以上4种状态的撤销我们都用到了同一个命令git reset --hard，前2种状态的用法甚至完全一样，所以只要掌握了git reset --hard这个命令的用法，从此你再也不用担心提交错误了。

文源网络，仅供学习之用，如有侵权，联系删除。

我将优质的技术文章和经验总结都汇集在了我的公众号【Java圈子】里。

为方便大家学习，我整理了一套学习资料，涵盖Java虚拟机、spring框架、Java线程、数据结构、设计模式等等，免费提供给热爱Java的同学！更有学习交流群，多交流问题才能更快进步~

来源：oschina

链接：https://my.oschina.net/u/4477286/blog/3214481

标签

为Xcode配置Git和Github

牧云@^-^@ — Sun, 05 Apr 2020 23:05:49 +0000

为Xcode配置Git和Github 牧云@^-^@ 2020-04-06 07:05:49

Xcode、Git和Github是三个伟大的编程工具。本文记录一下如何在Xcode中使用Git作为源代码控制工具，以及如何将本地的Git仓库和远程Github上的仓库集成起来。

1. 如何为新建的Xcode项目使用Git

Xcode4开始，就已经将Git作为内置的源代码控制（Source Control）工具了,所以为新建的项目使用git来管理是很方便的。

在新建项目向导中，可以直接选择Git作为源代码控制工具，完成项目新建向导后，就在本地项目目下新建了一个仓库。

2. 如何为已经存在的项目使用Git

如果已经存在了一个Project，想要为它使用Git，可以利用Git的命令行来操作。

假设该项目的根目录是： ~/Documents/Projects/ProjectA

(1) 在终端中先进入该目录：

cd ~/Documents/Projects/ProjectA

(2) 在该目录初始化Git仓库：

git init

(3) 注意，这时一定不要着急将目录下的所有文件都添加进来，先手工设置一些针对Mac OS X上的无用文件的排除(exclude)，在项目根目录(ProjectA)下新建.gitignore文件，在该文件中添加如下排除规则:

# 排除build目录
build/*
 
# Exclude temp nibs and swap files
# 排除nib临时文件和交换文件
*~.nib
*.swp
 
# 排除OS X的文件夹显示属性目录
.DS_Store
 
# 排除xcode3 xcode4的用户自定义设置文件
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser
xcuserdata

上面的规则只是大多数开发者都不需要进行版本控制的文件，还可以根据实际需要添加其它排除规则. 关于.gitignore更多的信息可以google之。

(4) 向git仓库中添加源文件

继续在终端命令行中，进入ProjectA下，

git add .
git commit -m "Initial commit"

然后重启Xcode，就可以在Orgnizer视图中的“Repositories”选项卡界面下看到ProjectA的仓库了，并且已经完成了源代码的初次提交。此后，就可以进行源代码在本地仓库的版本控制了。

3. 如何将Xcode的本地Git仓库与Github的远程仓库集成？

Github的理念源自于Git，但是与Git相比已经有了一些异化的功能特性(比如Pull Request)，所以二者并非完全一致的。但是从版本控制方面来说，差别不大。所以利用Xcode内置的Git管理功能即可与Github连接，而无需额外安装Github客户端。

Github的仓库地址有两种方式：

一种是SSH连接方式，形式为：git@github.com:Hao-Wu/ProjecA.git

一种是HTTP形式，形式为：https://github.com/Hao-Wu/ProjectA.git

这两种仓库地址使用的认证方式也不一样。对于SSH连接，使用非对称公钥认证方法；对于HTTP连接，使用帐号密码认证方式。

3.1 使用SSH方式

# 检查本机是否已经存在ssh公钥
$ cd ~/.ssh

如果以前已经生成过ssh密钥对，那么就存在这个.ssh目录，目录下有id_rsa.pub公钥文件。如果还记得这个密钥对生成的细节(比如passphrase)，就可以直接拿来用；否则就再多花费半分钟时间，生成新的密钥对(记得先备份旧的密钥文件，说不定其它什么项目或程序在使用):

#创建新的SSH密钥对
$ ssh-keygen -t rsa -C "your_email@example.com"

Enter passphrase (empty for no passphrase): [输入密码]
Enter same passphrase again: [再次输入密码]

到这里，SSH密钥对就生成了，接下来将id_rsa.pub文件用文本编辑器打开，将其中的全部字符串拷贝，并粘贴到web版的github.com中SSH公钥设置内。这样Xcode就可以利用SSH认证与github连接。先测试一下：

$ ssh -T git@github.com

本机就会向github发出一个连接请求，随后Mac OS会弹出一些安全认证和请求获取授权的提示框，要选择允许。如果github的服务器返回：

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

这就说明本地的git已经能够成功与github服务器通信了。(不用担心上面的访问被拒绝的提示)。在确定能够与github服务器连接后，即可为ProjectA的本地git仓库添加远程地址：

依次点击， Orgnizer –> Repositories –> ProjectA –> Remotes –> Add Remote

输入ProjectA在github上的地址(如果没有就先在github.com的仓库管理页面新建一个名为ProjectA的仓库)：git@github.com:Hao-Wu/ProjecA.git

Username与Password不用输入，关闭Orgnizer视图。在File –> Source Control中即可将本地仓库的代码Push到github上了。

3.2 使用HTTP方式

使用http认证方式省去了生成SSH证书的步骤，但是在每次提交时都需要输入github的帐号和密码。

类似地，依次点击 Orgnizer –> Repositories –> ProjectA –> Remotes –> Add Remote

输入ProjectA在github的http形式的地址：https://github.com/Hao-Wu/ProjectA.git

在UserName和Pasword中分别输入github网站登录的用户名和密码 (用户名不是邮箱形式)。关闭Orgnizer视图，File –> Source Control –> Push, 即可向github中push本地仓库的代码。这个过程可能需要重新输入一遍github的用户名和密码。

来源：https://www.cnblogs.com/W-Kr/p/5382486.html

标签

分布式版本控制系统（git分支管理）

强颜欢笑 — Sun, 05 Apr 2020 16:47:12 +0000

分布式版本控制系统（git分支管理）强颜欢笑 2020-04-06 00:47:12

1，分支管理

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，立刻提交，由于代码还没有写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的风险。
现在有了分支，就不能怕了，你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，在一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

Git的分支与其他版本控制系统不同，无论创建，切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

2，创建与合并分支

在版本回退里，我们已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支（master分支），HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

① 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD执行maser，就能确定当前分支，以及当前分支的提交点，每次提交，master分支都会向前一步：

② 当我们创建新的分支，例如dev时，Git创建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

可以看到，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化。

③ 不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

④ 假如我们在dev上的工作完成了，就可以把dev合并到master上。Git合并很简单，就是把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快，就改改指针，工作区内容不变。

⑤ 合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，我们就剩下了一条master分支：

下面开始进行实践：
首先，我们创建dev分支，然后切换到dev分支：

[jonson@localhost mygit]$ git checkout  -b dev
Switched to a new branch 'dev'
#git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev

然后，用git branch命令查看当前分支：

[jonson@localhost mygit]$ git branch
* dev     
  master
#git branch命令会列出所有分支，当前分支前面会标一个*符号

然后，我们就可以在dev分支上正常提交，比如对test.txt文件做修改：

[jonson@localhost mygit]$ echo "create a new brach" >> text.txt 
[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo
create a new brach
然后提交：
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "branch test"
[dev e2d7f2d] branch test
 1 file changed, 1 insertion(+)

现在，dev分支的工作完成，我们就可以切换回master分支：

[jonson@localhost mygit]$ git checkout master
Switched to branch 'master'
[jonson@localhost mygit]$ git branch
  dev
* master
[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo

切换回master分支后，在查看刚刚修改的文件，刚才添加的内容不见了。原因是那个提交是在dev分支上，而master分支此刻的提交点并没有变：

合并分支：
现在，我们把dev分支的工作成果合并到master分支上：

[jonson@localhost mygit]$ git merge dev
Updating 7646ab6..e2d7f2d
Fast-forward
 text.txt | 1 +
 1 file changed, 1 insertion(+)
[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo
create a new brach

git merge命令用于合并指定分支到当前分支。合并后，再查看文件的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意：上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master执行dev的当前提交，所以合并速度非常快，当然，也不是每次合并都是Fast-forward，后面会讲其他方式的合并。

#合并完成后，如果需要删除dev分支，可以执行以下命令：

[jonson@localhost mygit]$ git branch -d dev
Deleted branch dev (was e2d7f2d).
[jonson@localhost mygit]$ git branch
* master
#删除后，查看branch，就只剩下master分支了。

小结
Git鼓励大量使用分支：

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>

3，解决冲突

人生不如意之事十有八九，合并分支往往也不是一帆风顺的。
1）准备新的分支（feature1）

[jonson@localhost mygit]$ git checkout -b feature1
Switched to a new branch 'feature1'

修改test.txt文件并提交：

[jonson@localhost mygit]$ echo "create two branch" >> text.txt 
[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo
create a new brach
create two branch
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "two branch"
[feature1 78292e2] two branch
 1 file changed, 1 insertion(+)

切换到master分支：

[jonson@localhost mygit]$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
#git提示我们当前master分支比远程的master分支超前1个提交。

接下来，在master分支上也进行修改并提交：

[jonson@localhost mygit]$ echo "create a three branch" >> text.txt 
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "three branch"
[master e27d699] three branch
 1 file changed, 1 insertion(+)

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

[jonson@localhost mygit]$ git merge feature1
Auto-merging text.txt
CONFLICT (content): Merge conflict in text.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了，Git告诉我们，test.txt文件存在冲突，必须手动解决冲突后再提交。git status可以告诉我们冲突的文件：

[jonson@localhost mygit]$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看test.txt的内容：

[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo
create a new brach
<<<<<<< HEAD
create a three branch
=======
create two branch
>>>>>>> feature1

git用‘<<<<<<<’，’=======’， ‘>>>>>>>’标记出不同分支的内容，我们修改如下后保存：

[jonson@localhost mygit]$ cat text.txt 
# this is jonson first repo
create a new brach
<<<<<<< HEAD
create two branch
=======
create two branch
>>>>>>> feature1

再提交：

[jonson@localhost mygit]$ git commit -m "new branch"
[master 966dd22] new branch

现在，master分支和feature1分支变成了下图所示：

工作完成后，删除feature1分支:

[jonson@localhost mygit]$ git branch -d feature1
Deleted branch feature1 (was 78292e2).

小结：
当Git无法自动合并分支时，就必须解决冲突。解决冲突后，再提交，最后合并完成。

4，分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。下面来进行实践：
1）首先，仍然创建并切换dev分支：

 [jonson@localhost mygit]$ git checkout -b dev
Switched to a new branch 'dev'
[jonson@localhost mygit]$ git branch
* dev
  master

修改test.txt文件，并提交一个新的commit：

[jonson@localhost mygit]$ echo "create four branch" >> text.txt 
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "add merge"
[dev e730d1b] add merge
 1 file changed, 1 insertion(+)

现在我们切换回master：

[jonson@localhost mygit]$ git checkout master
Switched to branch 'master'

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

[jonson@localhost mygit]$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 text.txt | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。合并后，我们用git log 看看分支历史：

可以看到，不使用Fast forward模式，merge后就像这样：

小结：
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

5，Bug分支

软件开发中，必定会有bug。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代码101的bug的任务时，很自然的，你想创建一个临时分支来修复它，但是，当前正在dev上进行的工作还没有提交：

[jonson@localhost mygit]$ echo "create five branch" >> text.txt 
[jonson@localhost mygit]$ git status
# On branch dev
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   text.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   new-repo/
no changes added to commit (use "git add" and/or "git commit -a")

此时，问题出现了，工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作:

[jonson@localhost mygit]$ git stash
Saved working directory and index state WIP on dev: e730d1b add merge
HEAD is now at e730d1b add merge

现在，可以查看工作区，可以看到就是干净的了，因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支（issue-101）：

[jonson@localhost mygit]$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
[jonson@localhost mygit]$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，就假如需要把“create four branch”改成“create five branch”，然后提交：

[jonson@localhost mygit]$ sed -i 's/four/five/' text.txt 
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "fix bug 101"
[issue-101 6484832] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后再删除这个临时分支：

[jonson@localhost mygit]$ git checkout master
[jonson@localhost mygit]$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 text.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[jonson@localhost mygit]$ git branch -d issue-101
Deleted branch issue-101 (was 6484832).

这下问题解决了，原计划两个小时的bug修复只花了5分钟！现在，又可以接着回到dev分支干活了：

[jonson@localhost mygit]$ git checkout dev
Switched to branch 'dev'
[jonson@localhost mygit]$ git status
# On branch dev
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   new-repo/
nothing added to commit but untracked files present (use "git add" to track)

工作区此时是干净的，因为刚才的工作现场我们用git stash储藏起来了，可以用git stash list 命令看看：

[jonson@localhost mygit]$ git stash list
stash@{0}: WIP on dev: e730d1b add merge

所以现在我们需要恢复一下，有两种方式：
一种是用git stash apply 恢复，但是回复后，stash内容并删除，你还需要用git stash drop来删除。
另一种是用git starh pop，恢复的同时把stash内容也删了（所以一般采用这种方法）：

再用git stash list 查看，就看不到stash内容了，并且也恢复到之前的工作状态：

#当你多次stash时，如果你要恢复指定的stash，用以下命令：
git stash apply stash@{0}

小结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除。
当手头工作没有完成时，先把工作现场git stash储藏起来，然后去修复bug，再git stash pop，删除stash内容，并恢复到工作现场。

6，多人协作

当你从远程库克隆时，实际上Git自动把本地master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

#要查看远程库的详细信息，用`git remote -v`：
[jonson@localhost mygit]$ git remote -v
origin  git@github.com:sqm-sys/jonson-repo.git (fetch)
origin  git@github.com:sqm-sys/jonson-repo.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

[jonson@localhost mygit]$ git push origin master
推送其他分支：
[jonson@localhost mygit]$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此需要时刻与远程同步；
dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非领导要看看你每周到底修复了几个bug；

抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。

现在，模拟一个你的同事，可以在另一台电脑（注意要把SSH key添加得到GitHub）下克隆：

[zhangsan@localhost ~]$ git  clone git@github.com:sqm-sys/jonson-repo.git
Cloning into 'jonson-repo'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 26 (delta 5), reused 25 (delta 4), pack-reused 0
Receiving objects: 100% (26/26), done.
Resolving deltas: 100% (5/5), done.

需要的注意的是，你的同事从远程库clone时，默认情况下，只能看到本地的master分支，而看不到其他分支：

[zhangsan@localhost ~]$ cd jonson-repo/
[zhangsan@localhost jonson-repo]$ git branch
* master

现在，你的同事要在dev分支上开发，就必须创建远程origin的dev分支到本地（可以执行以下命令）：

[zhangsan@localhost jonson-repo]$ git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'

此时，他就可以在dev上分支上进行修改了，然后，时不时的把dev分支push到远程：

[zhangsan@localhost jonson-repo]$ echo "create six branch" >> text.txt 
[zhangsan@localhost jonson-repo]$ git add text.txt 
[zhangsan@localhost jonson-repo]$ git commit -m  "add six branch"
[dev f50cefa] add six branch
 1 file changed, 1 insertion(+)
[zhangsan@localhost jonson-repo]$ git push origin dev
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 287 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To git@github.com:sqm-sys/jonson-repo.git
   c7d965a..f50cefa  dev -> dev

你的同事已经向origin/dev分支推送了他的提交，而此时你也对同样的文件作了修改，并试图推送：

[jonson@localhost mygit]$ git branch
* dev
  master
[jonson@localhost mygit]$ echo "ha ha ha " >> text.txt 
[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "this is haha"
[dev 94c4cde] this is haha
 1 file changed, 1 insertion(+)
[jonson@localhost mygit]$ git push origin dev   #进行推送
To git@github.com:sqm-sys/jonson-repo.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:sqm-sys/jonson-repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败，原因是你的同事的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们：先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

可以看到git pull失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

[jonson@localhost mygit]$ git branch --set-upstream-to=origin/dev
Branch dev set up to track remote branch dev from origin.

创建链接后，在执行pull：

[jonson@localhost mygit]$ git pull
Auto-merging text.txt
CONFLICT (content): Merge conflict in text.txt
Automatic merge failed; fix conflicts and then commit the result.

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法之前的解决冲突完全一样（将冲突的内容进行修改）。解决后，提交，再push：

[jonson@localhost mygit]$ git add text.txt 
[jonson@localhost mygit]$ git commit -m "merge & six branch"
[dev 4ba822d] merge & six branch
[jonson@localhost mygit]$ git push origin dev
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 616 bytes | 0 bytes/s, done.
Total 6 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To git@github.com:sqm-sys/jonson-repo.git
   f50cefa..4ba822d  dev -> dev

push成功，因此，多人协作的工作模式通常是这样：

1）首先，可以试图用'git push origin <branch-name>' 推送自己的修改；
2）如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3）如果合并冲突，则解决冲突，并在本地提交；
4) 没有冲突或者解决掉冲突后，再用'git push origin <branch-name>' 推送就能成功；
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令'git branch --set-upstream-to=origin/<branch-name> '。
这就是多人协作的工作模式。。。

来源：51CTO

作者：wx5b9c94b17c62a

链接：https://blog.51cto.com/13972012/2485046

标签