GitHub操作记录

*学习Git的一本推荐书 https://git-scm.com/book/zh/v2

*安装 Git for Windows

GitHub desktop  操作教程 https://www.jianshu.com/p/06a960d991aa  https://www.jianshu.com/p/a6fc842f501d

对文件右键点击Git Bash Here之后会打开命令行窗口，在窗口中就可以运行 Linux 命令。

shell基本概念 翻译程序可厉害了，只要你输入具体的命令，它就会把它翻译给机器听，这样你就可以和机器沟通了。例如，我们输入ifconfig可以查看 IP 地址，翻译程序就会将这条命令翻译给硬件，告诉它我们要查看 IP 地址。其实这里的翻译程序就是 Shell，而具体的命令就是Linux命令。 简单地说，Shell 就是一套位于硬件和用户之间的程序，我们一般称之为解释器。  Shell 语言是一门弱语言类型，所以变量可以无须定义便可直接使用。 在 Linux 中有三个经常用到的输入输出流，他们分别是： 标准输入（stdin） 标准输出（stdout） 标准错误（stderr） 标准输入指的是从键盘这些标准输入设备读取到的数据。一般情况下标准输入重定向的很少用到。 标准输出则是通过屏幕输出的这些数据。我们可以通过标准输出重定向来让数据保存到文件里。echo "hello" 1> out.txt   读取数组元素值的一般格式是：${array_name[index]} 在 Shell 语言中的运算都是通过其他命令来实现的，其中最常用的就是 expr 命令。 判断变量 a 的范围，我们在 [] 符号中，只能使用 -gt 、-a、-lt等操作符。但如果用[[]]实现，我们就可以用上&&和||操作符; Shell 语言还支持下面这些关系运算符： -eq：检测两个数是否相等，相等返回 true。 -ne：检测两个数是否不相等，相等返回 true。 -gt：检测左边的数是否大于右边的，如果是返回 true。 -lt：检测左边的数是否小于右边的，如果是返回 true。 -ge：检测左边的数是否大于等于右边的，如果是返回 true。 -le：检测左边的数是否小于等于右边的，如果是返回 true。 逻辑运算符有三个，分别是：非运算、或运算、与运算。 !：非运算符。 -o：或运算符。 -a：与运算符。  Shell 语言并没有布尔型。

*（Repository）仓库是git的基本概念，本质就是一个文件目录，这个目录中的所有文件都被git管理，目录下不管做什么操作都会被记录，包括：增加、删除、修改文件等，都会被记录下来，以便后来跟踪与修改相关记录，甚至可以还原到项目中的某个点。

 

*分支(branch)在一般的项目开发中会定义分支模型，在常用的模型中，分支有两类，五种

• 永久性分支
   
  • master branch：主分支
  • develop branch：开发分支
• 临时性分支
   
  • feature branch：功能分支
  • release branch：预发布分支
  • hotfix branch：bug修复分支

master和develop分支禁止直接从本地仓库commit并push到源仓库，必须由开发者的分支合并过去。合并前需要提交pull request的请求，通过相关代码编写人的code review并同意合并后才能将自己的分支合并到develop分支。master分支只能从develop分支合并。

为了提高效率，防止过多的冲突，在寻求分支合并前，应尝试将develop分支合并到自己分支，提前查看合并的冲突，在解决冲突后再提交pull request。
 

冲突解决:

修改是存在本地的，和中央仓库是完全隔离的。 要发布修改到正式项目中，开发者要把本地master分支的修改『推（push）』到中央仓库中。这相当于svn commit操作，但push操作会把所有还不在中央仓库的本地提交都推上去。 中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。如果开发者本地的提交历史和中央仓库有分歧，Git会拒绝push提交否则会覆盖已经在中央库的正式提交。 在开发者提交自己功能修改到中央库前，需要先fetch在中央库的新增提交，rebase自己提交到中央库提交历史之上。这样做的意思是在说，『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史，就像以前的SVN的工作流中一样。 如果本地修改和上游提交有冲突，Git会暂停rebase过程，给你手动解决冲突的机会。Git解决合并冲突，用和生成提交一样的git status和git add命令，很一致方便。还有一点，如果解决冲突时遇到麻烦，Git可以很简单中止整个rebase操作，重来一次（或者让别人来帮助解决）。

相关代码:

1). 首先将远程代码拉取到本地     git clone xxx     git checkout -b develop origin/develop git branch -a 查看所有分支，就能看到远程分支。 2).新建feature分支     git checkout -b feature  GitHub团队项目合作流程:   以及:参考 https://blog.csdn.net/koffuxu/article/details/39010803 git checkout -b dev origin/dev 的意思是，创建一个dev分支（-b），并把远程dev分支（origin/dev）的内容放在该分支内。接着切换到该分支（checkout） git checkout master 用于切换分支 和团队分支合并: 首先查看有没有设置upstream，使用 git remote -v 命令来查看 首先执行 git fetch upstream 获取团队项目最新版本。 ，当前分支是dev分支，执行 git merge upstream/dev 命令后，会将源分支（upstream/dev）合并到当前分支（dev）。 如果你是在本地的master分支上开发，那么在使用该命令前，先切换到master分支。 merge的时候，有可能碰到冲突。需要解决冲突才能继续下面的操作。冲突的解决可以参考→ 冲突的解决 解决冲突后，就可以使用 git push 命令将本地的修改同步到自己的GitHub仓库上了。 3).多人在feature上开发，如果中途需要将develop的变更合入feature，所有人需要将本地的代码变更提交到远程     git fetch origin      git rebase origin/feature     git push origin feature 然后由feature负责人rebase develop分支，删除原来feature分支，重新新建feature分支；     git fetch origin     git rebase origin/feature     git rebase develop     git push origin :feature     git push origin feature 这样可以保证feature保持线性变更； 4).feature开发完成后，所有人需要将本地的代码变更提交到远程     git fetch origin      git rebase origin/feature     git push origin feature 然后由feature负责人rebase develop分支，然后将feature分支合入develop，删除feature；     git fetch origin     git rebase origin/feature     git rebase develop     git checkout develop     git merge feature     git push origin :feature 这样可以保证develop保持线性变更，各feature的变更完整可追溯；  5).合入feature后拉出对应的release/feature分支，后续bug修复在release/feature上     git checkout develop     git checkout -b release/feature release/feature分支的同步合并与feature分支相同  6).release/feature分支bug修复完成后，拉取对应的tag推送远程进行发布     git tag -a v1.0 -m 'feature发布'     git push origin v1.0 之后将release/feature合入develop分支，然后删除     git rebase develop     git checkout develop     git merge release/feature     git push origin :release/feature 7).发布完成后将release合入master分支，保证master为最新稳定版本（实际操作为发起merge request）     中央仓库的建立:git init --bare /path/to/repo.git 各个开发者创建整个项目的本地拷贝。通过git clone命令完成： git clone ssh://user@host/path/to/repo.git git status # 查看本地仓库的修改状态 git add # 暂存文件 git commit # 提交文件 git push origin master origin是在小明克隆仓库时Git创建的远程中央仓库别名。 小红push修改会怎么样？她使用完全一样的push命令： git push origin master 但她的本地历史已经和中央仓库有分岐了，Git拒绝操作并给出下面很长的出错消息： error: failed to push some refs to '/path/to/repo.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 这避免了小红覆写正式的提交。她要先pull小明的更新到她的本地仓库合并上她的本地修改后，再重试。 小红用git pull合并上游的修改到自己的仓库中。这条命令类似svn update——拉取所有上游提交命令到小红的本地仓库，并尝试和她的本地修改合并： git pull --rebase origin master --rebase选项告诉Git把小红的提交移到同步了中央仓库修改后的master分支的顶部，如下图所示： 如果你忘加了这个选项，pull操作仍然可以完成，但每次pull操作要同步中央仓库中别人修改时，提交历史会以一个多余的『合并提交』结尾。对于集中式工作流，最好是使用rebase而不是生成一个合并提交。 rebase操作过程是把本地提交一次一个地迁移到更新了的中央仓库master分支之上。这意味着可能要解决在迁移某个提交时出现的合并冲突，而不是解决包含了所有提交的大型合并时所出现的冲突。这样的方式让你尽可能保持每个提交的聚焦和项目历史的整洁。反过来，简化了哪里引入Bug的分析，如果有必要，回滚修改也可以做到对项目影响最小。

 

上传eclipse项目 https://blog.csdn.net/jam_fanatic/article/details/82810949

Eclipse 从git导入maven多模块项目 https://blog.csdn.net/xiongyouqiang/article/details/78903975

 

 

trydemot QQ