Python-day97--git Collaborative Development

1. Collaborative development process

-Create three development branches based on Dev

-Everyone is developing in their own branch

- after the first person has been developed, pull down the review branch from the Cloud repository - merge the personal branch with the review branch (make sure the review branch is the latest code)-upload the review branch to the cloud repository

- Second Person development complete - pull the review branch down from the Cloud repository -merge the personal branch with the review branch (make sure the review branch is the latest code) (there may be a conflict)- Upload Review Branch to cloud version library

- Third person development complete - pull the review branch down from the Cloud repository -merge the personal branch with the review branch (make sure the review branch is the latest code) (there may be a conflict)- Upload Review Branch to cloud version library

-Development team leader or boss review code, if the code is not a problem and then merge the code into the dev branch

-Test in Dev branch, if test is no problem add to Master branch online

Note: Generally in the company will be agreed to develop the completion of one or two small functions or a fixed length of time will be review merge code to see if there is a conflict

Interview questions:
Company code review how to do?　　Who's going to do it? We all have our own branch River Review Branch, small function development after the merger to review, small leader or eldest review.
Ask: Then do you team leader do not develop?   A: Team leader only develop the core technology, the workload is small; or we fix it for about two or three hours together review
Interview questions: Everyone has their own branch

2.. gitignore file

The first thing to emphasize is that the file's full filename is ". Gitignore", and note that there is a "." In the front. Files that do not have an extension are not well created under Windows, so here's how to create a win7:

Create a file with the file name: ". Gitignore.", notice that there is a point before and after. The system is automatically renamed to ". Gitignore" after saving.

In general, a ". Gitignore" file is required for each GIT project, and the purpose of this file is to tell git which files do not need to be added to version management.

In real-world projects, many files do not need to be versioned, such as Python. pyc files and some configuration files that contain passwords, and so on.

The contents of this file are rules that git will use to determine whether to add files to version control.

Let's look at the usual rules:

• /mtk/Filtering the entire folder

• *.zip filtering all. zip files

• /MTK/DO.C filtering a specific file

Quite simply, the filtered files will not appear in your GitHub library, of course, the local library, but the push will not be uploaded.

It is important to note that Gitignore can also specify which files to add to version management:

• !*.zip

• !/mtk/one.txt

The only difference is that there is an exclamation point at the beginning of the rule, and git adds a file that satisfies that rule to version management.

Why should there be two kinds of rules? Imagine a scenario: we only need to manage the one.txt files in the/mtk/directory, and no other files in this directory need to be managed. Then we need to use:

• /mtk/

• !/mtk/one.txt

Assuming we only have filter rules without adding rules, we need to write out all the files except One.txt in the/mtk/directory!

The last thing to emphasize is that if you accidentally push the project before creating the. gitignore file, even if you write a new filter rule in the. gitignore file, the rules won't work, and git will still be versioning all the files.

Simply put, the problem is that git is already managing these files, so you can no longer filter them by filtering rules.

So make sure you get into the habit of creating. gitignore files at the start of a project, otherwise, once push is made, it can be cumbersome to handle.

# 此为注释 – 将被 Git 忽略 *.a       # 忽略所有 .a 结尾的文件 !lib.a    # 但 lib.a 除外 /TODO # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO build/    # 忽略 build/ 目录下的所有文件 doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt--------------------------------------------------------------Split Line--------------------------------------------------------                         Create the. gitignore file-------------------------------------------------------------------git--Wq --to exit the edited. gitignore file. gitignore file What to write about--and so on, to see your specific needs

3. Fork the code of others on GitHub

Find an item, click Fork, then copy his project to my repository and fix it in my repository

To let him know after the modification is complete, we click on the button above to go to the following page

Select the object to return the notification to-that is, where the fork came from

Then click

And then it shows that the submission was successful,

The person who is being forked will be asked by a fork, and if he agrees to this request, his project will show what I have changed, then I will be the contributor to his project.

4, git authentication: SSH secret to authentication and HTTPS authentication, now in the company these two not too obvious distinction

HTTPS authentication requires a username and password, but now the optimizer remembers the password.

The following describes the SSH secret to the way certification: must be done at the terminal

1) created a pair of secret to

2) to view the secret

3) show public want, copy → put on github settings configuration

4) Add a public order to your personal github

5) Fill in the title→ to fill in the Copy, then click Add

This configuration will no longer need to login password or anything, but note: only with SSH link, such as

Python-day97--git Collaborative Development