Shulou(Shulou.com)06/03 Report--

Git actual combat management project example analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Example

1.git common command # 1. Initialization is usually in the root directory, execute: [git init], and complete the git initialization of the project # 2. Add when in the project, after adding a new file, execute: [git add.], finish adding the new file git # 3. Submit when in the project, after updating the content, execute: [git commit-m'log content'], complete the git submission, you need to note that the submission is submitted to the local temporary storage area, and the content changes have not been synchronized to the remote, which is different from the svn submission # 4. Check status if you want to view the git status of the project, execute: [git status] # 5. View branches, view local branches, execute: [git branch] View remote branches, execute: [git branch-r] # 6. Open a new branch, for example, from the master branch, open the branch v1.0, execute: [git checkout-b v1.0 origin/master] # 7. Clone and pull the clone code from the remote warehouse, execute: [git clone https://xxx/xxx.git] pull the latest code from the remote warehouse, and execute: [git pull] # 8. If the push is a local project, you need to establish a connection with the remote warehouse for the first push. Execute: [git remote add origin https://xxx/xxx.git] if it is a local project, after the connection with the remote warehouse is established, the first push executes: [git pull]-> give priority to pulling the [git push-u-f origin/master]->-f parameter from the remote warehouse, indicating forced push. If it is not the first push to overwrite the remote warehouse, execute: [git push] 1.2. Create a remote warehouse

Having reviewed the common commands of git, we made a relatively complete case demonstration with the help of Ma Yun. First of all, let's build a remote warehouse: algorithm, which is used to share data structures and algorithms. I will put the source code of a series of articles on data structures and algorithms into this warehouse.

1.3. Prepare the project and perform git initialization

Let's go to the project: data-struct-pro root directory and create two files, namely

README.md, used to describe project details

.gitignore, used to describe git ignoring file information

1.3.1.README.md data structure and algorithm knowledge converge 1.3.2.gitignore# ignore class file * .class # ignore package file * .war * .ear # ignore kdiff3 comparison file * .orig # ignore maven file target/# ignore eclipse file .settings / .project.classpath # ignore idea file .idea / / idea/*.ipr*.iml*.iws# ignore temporary file * .log*.cache*.diff*. Patch*.tmp# ignores system files. DS_StoreThumbs.db1.3.3. Perform git initialization

Before git initialization

After git initialization

1.4. Add and submit local projects

After initialization, the project has been managed through git. We need to add and submit the project content to the git local temporary storage area.

To view the current git status information, execute: [git status]

To add project content, execute: [git add.]

Submit project content, execute: [git commit-m'algorithm project init']

1.5. Push the local project to the remote warehouse

After the local project git is initialized, we need to further push the project to the remote repository. Specific steps

To establish a remote warehouse connection, execute: [git remote add origin https://gitee.com/yanghouhua/algorithm.git]

Pull remote warehouse initialization information and execute: [git pull]

Push the local project to the remote warehouse, execute: [git push-u-f origin master]

Figure 1

Figure 2 (user verification is required when pushing, and you can enter the user name and password on the remote warehouse)

Figure 3 (after the push is successful, our project code is already available on the remote warehouse)

1.6.git best practices

At this point, we have pushed the local project to the remote warehouse for management. At this time, the partners of the project team can pull the code of the project to the local from the remote warehouse and happily carry on the daily development.

Of course, at this time, we need to pay attention to some best practices, which I will share with you below.

Branch development, backbone release

Git Project Branch Management

1.6.1.git Project Branch Management

Here, I would like to share with you the branch management practice implemented by our project team. You need to note that the practice style of each project team must be different and need to be adjusted with reference to the needs of the project team. So we can just pay attention to the meaning of each branch.

Master branch: the trunk branch. In our project team, the master branch is used for online backup, that is, after each online release, it is merged directly from the release branch.

Release branch: release branch. In our project team, this branch is used for online release.

Test branch: the testing branch, which is used for testing in our project team

Develop branch: development branch, in our project team, this branch is used for new requirements, new function development. For each new requirement and new function, we will start from the release branch and open a develop branch, such as develop-xxx-20210523

Hotfix branch: bug repair branch, which is used for online bug repair in our project team. For online bug, we will start from the release branch and open a hotfix branch, such as hotfix-xxx-20210523

See here, some friends may ask, so how do your branches flow to ensure code synchronization? Here's what we do.

Whether it is a new requirement or an online bug repair, we will start a new branch with the release branch as the starting point.

When the requirements development is complete, or the bug repair is complete, we will first merge the code into the test branch for testing

After the test is passed, we will merge the requirements branch and bug repair branch code into the release branch for pre-production release.

After the pre-production environment test is passed, it is directly pushed and released to the production environment.

The whole project is released online, and the release branch code is merged into the master branch to realize the synchronization of the branch code.

1.6.2. Branch development, backbone release

With regard to the whole branch code flow, I will not demonstrate specifically, after all, each team will have its own specification. Finally, let's share how to open a new branch and how to switch between branches.

Create a new branch, execute: [git checkout-b v1.0 origin/master]

Push v1.0 branch to remote warehouse, execute: [git push origin HEAD-u]

Switch branches, execute: [git checkout master]

Figure 1

Figure 2

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.