Git's management process in a small team (go)

Target Audience : Learn the basic concepts of git and be able to use Git for basic local and remote operations.

The basics of Git can be found in the answers-how do I use GitHub? , Liu Yong has given some good learning materials.

This article describes the basic use flow of Git management in small teams.
Code management for a small team can take the form of a central remote repository for a project that is the main place for the team members to communicate code. There are also some member remote repositories that can be used to restrict code communication among some members of the team. The members are divided into the following types of roles: Responsible person, general team member, pre-release responsibility and version repair responsible person . The following sections specifically describe the Git usage process for various roles.

Basic Information :
Branches that require more than one person to work together can establish a remote branch, and a single-person-completed branch will only have local branches.

First, the person in charge

Responsibility of the responsible person: Manage remote warehouses.
The owner's work can be done directly at the remote warehouse.

1. Create a project

• Create a public project
• Add readme.md
• Add a Certificate
• Add Ignore File
• Create Dev Branch

2. Other

• Update readme.md file

Second, the team members

Work Flow :

• Cloning a project
• Check out and create the dev branch to keep track of the remote Origin/dev branch.
• Create your own branch member* based on the Dev branch.

• Add a file on your own branch
• Modify a file on your own branch
• Merge to Dev Branch
• Push Dev branch to Origin/dev branch

Update. gitignore file

• Create a new branch from Dev Ignore (if you create a remote branch with frequent predictions, you will now have templates, and occasionally a direct change on the dev branch without ignoring them)
• Update ignores files
• Merge to \ Push to Origin/dev branch as soon as possible (avoid conflicting two team members while changing the file.) ）

1. Create a local warehouse

$ cd [项目路径] $ git clone https://coding.net/tangyikejun/GitTest2.git  $ git checkout -u -b dev origin/dev$ git checkout -b [MEMBER_NAME];

2. Updating the Local warehouse

$ git add .$ git commit -m”your comments”       // …                                               // 多次提交后完成了一项新的功能，自己的分支下能正常运行$ git checkout dev$ git merge --no-ff [MEMBER_NAME] // [MEMBER_NAME] 是自己的分支名称$ git push

3. Update the. gitignore file

$ git checkout dev        //…                                               // 更新忽略文件$ git add .$ git commit -m“更新.gitignore文件”$ git push

4. Common query Commands

$ git branch                                            // 查看自己所在分支 以及自己所拥有的分支$ git log --pretty=“%h - %cn(%ci): %s” --graph // 查看自己的提交记录$ git reflog // 查看自己的操作历史$ git status // 查看本地仓库当前的文件状态$ git blame [FILE_PATH] // 查看文件的每一部分最后由谁改动

5. Handling of contingencies

unexpected : a conflict occurred while pushing code to the remote dev branch.
solution : First pull down the Origin/dev branch of the remote repository, resolve the conflict file and then push. Always try to avoid changing the same file by different team members.

$ git push        // …                                               // 遇到错误$ git pull       // …                                               // 解决冲突$ git add .$ git commit -m”solve conflict:由于XX原因出错，修改XX文件解决问题”$ git push

accident : Accidentally push your work to the Master branch.
solution : Roll back the master first, and then use git push -f to delete the wrong commit.

Third, the pre-release responsible person & version repair responsible person 1. Pre-release responsible person

When a new version needs to be published, the pre-release responsible person:

• Create a release-version number branch based on the latest dev branch
• Carry out repair work
• Merge to Dev Branch
• Merge to Master Branch
• Hit label
• Remove release-Version Number branch

$ git checkout dev$ git pull$ git checkout -b release-1.2        //…                                               // 进行修缮工作$ git checkout dev$ git merge --no-ff release-1.2 $ git checkout master$ git merge --no-ff release-1.2 // 在评论中写入相比上个版本新增的功能，修复的bug等详细内容$ git tag v1.2$ git branch -d release-1.2

Use git show [TAG_NAME] to view the submission information for the label.

2. Version Repair Responsible person

When a bug is found in a newly released version, the version repair responsible person:

• Create a hotfix-version number branch based on the latest master branch
• Perform debug work
• Merge to Master Branch
• Hit label
• Merge to Dev Branch
• Remove hotfix-Version Number branch

$ git checkout master$ git pull$ git checkout -b hotfix-1.2.1 //… // 进行修缮工作$ git checkout master$ git merge --no-ff hotfix-1.2.1 $ git tag v1.2.1 $ git checkout dev$ git merge --no-ff hotfix-1.2.1 // 在评论中写入修复的bug等详细内容$ git branch -d hotfix-1.2.1

3. Handling of contingencies

unexpected : A team member completes his task and merges into the Dev branch, and when pushed, discovers that the repair work of the release branch changes its original file, resulting in a conflict.
solution : Pull the Origin/dev branch down to resolve the conflict and resubmit it again. (Note that the file on the master branch after resolving the conflict is still in conflict with the work of the team member.) Unless the team resolves the conflict without changing the repair code at Relese, instead of just changing his code to fix the problem. Therefore, once a conflict arises, it is advisable for both parties to agree on a reasonable exchange of views. Reduce conflict. )

IV. member Remote Warehouse

When a team member wants other members to assist with his programming tasks, the member can create a remote repository for their own local warehouse as a member of the remote repository, facilitating the assistance of other members. Establishing a member remote repository avoids the clutter of code exchange in the central remote repository.
Member remote warehouses are operational as a simplified version of the Central remote Repository. differ only in subtle places.

1. Help person

• Create a member remote warehouse
• Add Member Remote Warehouse

• Push your own branch to the master branch of the member remote repository

• Pull the Master branch of the member remote repository to its own branch

git remote add [ALIAS_NAME] [GIT_ADRESS] $ git push [ALIAS_NAME] [BRANCH_NAME]:[BRANCH_NAME_REMOTE] $ git pull

Example:

$ git remote add binRepo https://coding.net/chenbin/GitTest2.git $ git push binbin  binRepo:master                               //由于是第一次推送，该操作已经使得分支binbin 跟踪了远程分支 binRepo/mastr

When a branch a tracks remote Branch B, that is, B becomes the default pull source for a, and therefore, a local branch can only track one remote branch at a time.

command to have a local branch trace the remote branch

$ git branch -u [REPO_NAME]/[REMOTE_BRANCH_NAME] [BRANCH_NAME]  // git branch -u binRepo/master binbin

2. Facilitators

• Clone member Remote Repository
• Create your own branch based on the master branch member*
• Modify the code on your own branch
• Push to member remote warehouse after merging to master branch

$ git clone https://coding.net/chenbin/GitTest2.git $ git checkout -b member1;        //…                                                       //修改代码$ git add .$ git commit -m"我帮你把XX功能完成了"$ git checkout --no-ff merge member1;$ git push


Http://www.cnblogs.com/tangyikejun/p/4217561.html

Git's management process in a small team (go)