Git and GitHub workflow

　　Workflow with a variety of uses, but these are how to get started making more difficult to use in practice. This guide companies through an overview of the most popular team in several Git workflow so that we can start to use. Remember that in the process of reading, several workflows in this article as a guide rather than a program of the Ordinance. After the show a variety of possible uses workflow, or you can pick out a satisfying blend your own workflow needs from different workflow.

★ centralized workflow

　　If your development team members are already familiar with Subversion, centralized workflow so that you do not need to adapt to a new process can experience the benefits brought by Git. This workflow can also serve as a friendly transition migration to Git more style workflow.

 

★ feature branch workflow

　　Feature branch workflow with centralized workflow-based, the difference is assigned a specific function for each new branch to develop. This before the new functionality into a formal project, a Pull Requestsway to discuss changes.

 

★ GitFlow workflow

GitFlow workflow by providing functional development, preparation and publishing branches maintain separate distribution, so publishing iterative process smoother. Strict branching model also provides some very necessary structures for large projects.

 

2.GitHub

　　Is a platform for third-party managed code, git is just a tool, do not code hosting, github is a remote warehouse, implement managed code through git tool, pull, push, etc. operations. Cloud code, city code, etc.

URL: www.github.com

1. Create a warehouse

2. cloned by git

Cloned into local

 

3. Place the code submitted to a remote repository

 

 

If you select the "Submit", then it is submitted to the local repository, and not pushed to the remote repository.

 

If a point before the "Submit", then it is submitted to the local repository, and not pushed to the remote repository, so it is necessary in this way pushed to the remote repository.

3. collaborative development with a branch on GitHub

1. Centralized Workflow Case

★ case of a

Case: The two developers, tentatively called Li and Guo are cloned code from github to local, after

　　　　  Li login function code has been modified and pushed to submit a remote repository,

　　　　  小郭这时候并不知道小李做了代码的更改,假如这时候开发了一个注册功能完成之后推送提交到远程仓库,结果提交失败了

原因分析:因为小郭克隆的代码里面的登录功能还是旧版,并不是小李推送提交修改后的新版功能,所以出现了提交不成功的情况

解决方案:小郭先把新版的代码拉取过来覆盖掉旧版的,再进行注册功能的推送(因为已经提交到了本地仓库)

★案例二

案例情况:小李再次拉取代码,又更新了自己的登录功能代码把V1.2版本提交并推送到了远程仓库,之后

　　　　 小郭闲的没事干,去看了看小李的登录功能代码,做了一些改进,也更新了登录功能,之后发现提交推送失败了,所以拉取最新代码,结果失败了

原因分析:因为git并不会去把你修改的代码直接覆盖掉(不然你写的代码做的修改不就白干了?),所以就产生了冲突

解决方案:　　方案一:小郭把自己的代码复制一份放在别的地方,再把小李的拉下来看看有什么区别,更改以后再推送

　　　　 　　方案二:使用git解决 : 将冲突的内容调整好后写在下方，然后点击保存，然后标记为已解决，再提交并推送到远程仓库。

拉取失败以后,查看变更,