GIT is a tool for us programmers to eat, this article is mainly about the commit and branch and for most programmers are afraid of conflict some personal opinions, if there is something wrong or your company GIT submission process welcome comments below.

Before we can discuss the specification, we need to establish the most basic requirements

1. Keep a good code format within the team, which is easy to read and maintain, and the most important thing is to reduce unnecessary code conflicts (it is suggested to uniformly use the code formatting of the development tool (IDEA)).

2. Any code submitted must be verified to work

3. The submitted code must remove useless package path references and useless dependencies, and try not to use expired methods or classes

1. Commit Message specification

Specification format:

<type>: <subject>

Copy the code

**type  **

  • Feature: New feature
  • Fix: Fixes bugs and styles
  • Refactor: refactoring (i.e. code changes that are not new features or bug fixes)
  • Test: Adds a test chore: changes to the build process or helper

subject

A short description of the purpose of the submission, describing what was done or changed, if there is a team management tool (JIRA) or product requirement, must be part of the description with an internally named requirement code to facilitate logging, merging and cherry pick.

For example:

  1. Feature: Complete development # code xxx.xxx requirement
  2. Fix: fix # code XXXX query problem

2. Submission specification and GIT development process

Git branch * * * *

  1. Master (production environment) a UAT function is deployed and merged to the master when it is ready for production. Only UAT branch merging /cherry-pick is allowed.
  2. Uat (test environment) merges a feature branch into UAT when deploying it to test, and only feature branch merges are allowed.
  3. Feature/XXXX (feature branch) merges/commits to feature when developing a feature or fixing a bug
  4. Dev /xx (local development version)

Before development, you need to cut one on the Master branch for requirements, bugs, refactoring……. Name feature branches, such as feature/ item numbers (BUG codes)

2.1 There is no local project, clone the code and switch to the development branch

Clone and create a local dev development branch on the feature branch to be developed. The local branch can be named by dev/ itself.

git clone-b dev/xx feature/ Project IDCopy the code

2.2 If there is a local project, switch the development branch

To avoid inconsistency between the local and remote branches, switch to the feature/ item number branch and update it.

Git checkout feature/ project id git pullCopy the code

Then cut out your own development branch on feature/ project number

git checkout dev/xx
Copy the code

2.3 Submission Code

Note: suffixes or files that do not need to be committed must be added to.gitignore files in the same directory as.git

Add the modified file to the staging area

git add .   
Copy the code

Commit the modified file to the local version library

git commit -m 'fix: modified XXXXX'
Copy the code

You can also combine two steps and operate in one step

git commit -am 'fix: modified XXXXX'
Copy the code

I personally recommend that you use IDEA or other Git graphical interface to select files that need to be added, or operate.

Git git git git git git

  • The first is the Git pull code action button
  • The second is the Git commit action button
  • The third is the Git log action button
  • The fourth is the Git Revert action button

Start by clicking the Git Submit button

Click the submit button to see the status of Git, which files are modified, which files need to submit Git, and which files do not need to submit Git. You can use revert to a previous change if you want to do something temporary or unexpected.

If the file doesn’t need to be modified, or if you accidentally do things like whitespace, use Revert

If the file was created when the project started, such as an Excel or log exported by the project, use delete to delete it

You can also use the TortoiseGit, Source Tree, and TortoiseGit as well as the TortoiseGit and Source Tree as well. And git’s own two gitks and git-GUI (you can type commands in your git directory).

2.4 Push to remote Branch

Before pushing the local branch dev to the remote dev, switch to the feature/ project id branch,merge remote branch code first.

Git checkout feature/ project id git pullCopy the code

Switch to your development branch dev/ XXX

git checkout dev/xxx
Copy the code

Rebase feature/ project number to own dev/ XXX, main function is to check whether there is a conflict.

Git rebase feature/ project idCopy the code

Push dev/ XXX directly to remote dev/ XXX without conflict

git  push  origin dev/xxx
Copy the code

If there is a conflict, you can use the git status command at any time after a merge conflict to view the files that are unmerged due to the inclusion of the merge conflict

git status
Copy the code

All files that are in conflict with the merge and need to be resolved are identified as unmerged. Git adds a standard resolution flag to files that have conflicts, so you can open those files and resolve them manually.

<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
 please contact us at [email protected]
</div>
>>>>>>> dev/xx:index.html
Copy the code

The above file contents indicate that there is a conflict between the version that head points to (i.e. the branch of Rebase) and the version that dev/xx points to below

======= is the split line. The top half is the code for the version of the branch that head points to, and the bottom half is the code for the version that dev/xx points to

The conflict solution retain only one branch of modification, and < < < < < < <, = = = = = = =, and > > > > > > > these lines need to be completely removed.

Perform operations after the modification is complete

git add .

Copy the code

Use the git add command to mark it as resolved. Once the conflicting files are temporarily saved, Git marks them as resolved

Then continue with the rebase operation:

git rebase --continue
Copy the code

Loop through rebase –continue until rebase succeeds

Then push

git  push  origin dev/xxx
Copy the code

Finally, log in to the Web management of GitLab or Coding and submit a merge request. Merge the remote branch dev/ XXX and the remote branch Feature/item number. Only after the merge, can you indicate that your submission is complete. After all the people in the feature branch have completed the development and passed the test, the feature will be merged into UAT for online test.

Now let’s look at conflict resolution using our artifact idea.

When operating merge, rebase, and cherry-pick, pop conflicts when there is a conflict

It is best not to choose directly between remote or modified code, but to select each line change by clicking on the file separately

After the solution is completed, apply and push can be done directly.

Conclusion:

With Git, only push and pull operations are remotely handled. Everything else is done locally, which means that only pull,push, or remote branch merges on the Git platform really know if there is a conflict. There is still no way to ensure that dev and feature do not conflict, because when you rebase, it does not mean that the code of your current local feature branch is exactly the same as that of the feature branch when you initiate the merge request. Therefore, the rebase feature only reduces the conflicts when merging features in advance.

Git operation process, people have different habits, in fact, there is nothing wrong with how to operate, if the company, the team has approved the specification, still according to the specification.

** Common submission methods **:

1. Directly develop in the feature branch, everyone pull (git fetch + git merge) the new feature code before commit, and then add. Commit push after conflict is resolved once.

Commit to the local branch, then pull –rebase (git fetch + git rebase) the current new feature code, and then add. Push after conflict resolution.

3. The strict operation I wrote above is that everyone has a local branch named themselves, conflicts are resolved by merging with the local branch to be merged, merge or rebase, and then merge by request from the Web platform.

4. We welcome more ways to be awesome…

The first is the simplest and most common way of doing things. This way, it is easy to lose the code you have modified in the process of resolving conflicts, resulting in irreparable results. (You can also use idea to rollback local history)

The second method is to commit and then pull the code rebase, which ensures that your code is committed to the local branch. No matter how much you change the code later, you will not lose the committed code.

The operation of the third one is a little complicated. Although it takes a detour, compared with the second one, the main difference is whether the feature branch allows direct submission. If allowed, the permission control of feature merging is placed in the link of merging into UAT.

GIT does nothing more than **** pull code, push code, merge code, and at every step there is a real conflict with the remote branch. But there are many different ways to resolve conflicts early or in what ways.

Whatever graphical tool you’re using, you need to understand the basic git commands and the commands behind each graphical tool operation.

Warning: do not delete your.git directory if you have code that does not push.

The consequences of not resolving the conflict and then pushing, hahaha, I laughed

* * eggs; **

Now that we have finished the knowledge submitted above, let’s expand our knowledge

1. How to reset?

Usage:

Git reset - mixed/hard/soft c27894c06a2cc23e4097a93013cf640cc4fd527d git reset - mixed HEAD ~ 1 Git reset -- soft HEAD~1: rollback git reset -- soft HEAD~1: rollback git reset -- soft HEAD~1 Git reset -- hard HEAD~1 before commit To roll back a version, clear the staging area, and restore the version of committed content to local, local files will be replaced with the version of the rollback, that is, restore to before developmentCopy the code

Reset is not recommended or allowed to be used.

Git itself stores all the history of your code, whether you commit it incorrectly or if the code you commit is buggy. Commit another commit based on the error, not undo the code you have committed to a remote branch.

If you accidentally commit a small movie to GIT, or if you want to “delete the code and run away”, or if your changes become thousands of bugs, you will need to force the push to the remote branch after the reset point, and the remote branch’s commit records will be permanently lost.

2. I want to merge the code before a commit of the UAT branch

 git  checkout -b uat20190711 c27894c06a2cc23e4097a93013cf640cc4fd527d 
Copy the code

You can push to a remote branch and merge with another branch or switch to another branch

3. Cherry -pick?

git  cherry-pick -x -n 017822ece3049d3f46c72cabf32dee9f44dd15cc
Copy the code

Commit a commit by making the changes directly to the current branch and then committing it, so committing a commit should be clear about the intent of the commit.

-x retains the original author. -n does not automatically submit

Graphical tool screenshots, their own exploration, all the same, find a commit record directly operation can be.

Blog Address:my.oschina.net/wangnian