The Bug that can’t be changed, the pretense that can’t be written. The public account Yang Zhengyou now focuses on mobile basic development, covering audio and video, APM, information security and other knowledge fields; Only do the whole network the most Geek public number, welcome your attention!

Large Internet companies pay attention to details and internal implementation, and the code quality requirements are extremely demanding. New employees are required to <review code + mentor >. Every time they write a line of code, they must explain the principle inside. Why to write, if use what design pattern will become more expansibility, business documents and technical documents are mandatory, various process like line office, a detail problems and influence are the release of complex requirements can be divided into multiple id, then each person is responsible for their own small demand module, small group would pay more attention to the overall I have to sort out the business process before doing it. Just on National Day, I took some time to summarize Git and then gradually analyze how the real git management of enterprises is. I hope it will be helpful to you in the workplace.

How to clone a new project to a local location

1. git clone project

The git init command creates an empty Git repository or reinitializes an existing repository.

git init 
git clone
Copy the code

1.1 Clone the project remotely

1.2 Interface after Clone is Successful

1.3 Local File Changes

1.4 Open the display page of my new project

1.5 Switch to the Log/History panel

1.5 Switching to the Local Master Branch

2. Modify/commit the new project

2.1 Create a workManager. md file in the local repository directory

2.2 In the “Log/History” panel of sourceTree, view

2.3 Prompt you for new uncommitted changes. Switch to the ‘File Status’ panel

2.4 The modified files will be added with temporary storage stage, unstage and submit options

  • The workspace

  • Version of the area
    • There is one in the workspace. Git’s directory, usually a hidden directory. This folder, already mentioned, indicates that the directory in which it resides is a Git managed repository. In this folder, Git repository information is stored. This is the Git repository
  • The staging area

  • Git repository contains many files, the most important of which is a staging area called index (or stage) and the HEAD pointer. Other branch information is stored in the RefS folder.

  • Where we store changes, all changes have to be cached here. When we execute the commit command, we are actually committing the contents of the staging area to the branch corresponding to the HEAD.

  • Initially, the staging area should be empty, and when we commit to the staging area, as above, the staging area will have content before we execute the COMMIT command.

  • After the commit, the staging area is cleared for the next staging and commit.

  • Pointer to the HEAD

    • Git is just a pointer move, so what is Git’s pointer? If it moves, the HEAD pointer points to the branch we are currently in
      • Every commit in Git will string it into a line. This line is a timeline, and a timeline is a branch.

      • When we started, we only had one master branch, and we only had one timeline, so our HEAD pointed to the master, and then the master pointed to our commit line.
      • The HEAD doesn’t point to the commit, it points to the branch, the master points to the commit, so the HEAD points to the current branch. HEAD and master are both Pointers
      • When a new commit is made, the timeline node is added and the master moves forward, followed by the HEAD
      • When a new branch dev is created, a pointer to dev is actually created. However, dev is split from master, so dev and master are initially on the same node

      • Its pointing information is not visible, but you can see which branch the current HEAD points to by looking at the branch information under the project name in the sourceTree project list. HEAD points to Dev.

      • After the new branch is created, HEAD points to the new branch, and the commit operation is dev

      • A commit on Dev simply moves dev forward, leaving master where it was

      • What about our merge operation?

        • The merge operation simply points the master to the commit where Dev is currently located, and this is a pointer movement.

        • Git merges are also very fast, the contents of the workspace do not change (actually only very little, because switching back to master will make some changes to the file), and then the pointer moves

        • Deleting branches is also very simple. Just pointer removal, no file system changes. When the branch is deleted, the merged master branch has no effect, only the pointer is removed.

2.5 After the submission is successful, the “File Status” panel is clean again. Switch to Log/History

  • Only changes that are added to the staging area are committed because Git manages changes. For example, if you make the first change, then add it to the staging area, then make the second change, but the second change is not added to the staging area, then if you commit, you will only commit the first change
    • Because Git only puts what you put in the staging area the first time, your second change is not in the staging area. To commit the second change as well, resend and commit.

  • We submitted successfully, just to the local warehouse successfully, do not believe you can go to the remote warehouse to see if there is the latest submission information. Local warehouse, we can only play in the local, although it can do version management, but others can not see, we also need to push to the remote warehouse, so that others can see

3. Create my Dev branch

3.0 The nature of Branch creation

  • How easy it is to create a new branch, just create a new pointer,HEAD changes the bottom point, there is no copy of the file, so it can create the new branch in 1s

  • If there is a BUG in the master branch, create a temporary temp branch from the master branch, fix the BUG in temp, and merge it with the master branch. The master branch continues publishing
  • Fixes are incorporated into the Dev branch, which also ensures that code on the Dev branch is stable. Finally, delete the temp branch

3.1 How do I Create a Branch?

  • The new branch is in the same state as the branch being branched (master here)

  • After a new branch is created, SourceTree (Git) defaults the HEAD to the newly created branch, and the new branch is in the same state as the original branch
    • To switch branches, just double-click on the branch to switch. This is much faster than switching branches using Git commands. The Dev branch is then pushed to the server.

    • After the push is successful, origin will add a Dev branch in the sourceTree remote option, indicating that the server already has a Dev branch

3.2 How Do I Switch Branches?

  • If we switch to another branch without committing, this change will be carried to the other branch as well. Double-click the Master branch directly
  • My changes to the Dev branch haven’t been committed yet. The change will be carried over to the other branches when the branch is switched, regardless of whether the staging area is joined or not, as long as it is not committed
  • We want to make sure the changes are committed or stored before switching branches

4. Merge branches

4.1 How Do I Merge Branches?

The merge branch is the target branch. For example, if we want to merge the changes on the Dev branch to the master branch, we need to merge the changes on the Master branch

Once the merge is complete, we can check that the files under the master branch are the same as the changes under the Dev branch. The Master branch is then pushed to the serverHere my Dev branch is never pushed to the server. This is merely to say that, we can not in local modification is submitted to the server, this is what we usually use branches to fix bugs and developing new function in practice, our Dev branch should submit the service side, because everyone in the Dev branch work, and you from Dev branch out to other local branch, Should not be submitted to the server

4.2 Requirements for Branch Management

2 master/develop

  • Do not delete, overwrite, or rename resident branches (branches*masterBranch,*develop)

4.2.2 master

  • Disallow branching#masterTo allow other branches # to merge into the branch#master
  • Merge to branch#masterIs published code (tip: test before release)
  • Disallow branching#masterMerges directly into other branches.
  • Allow the branches#masterCreate a new branch

Holdings in release

  • Release the version from the branch#masterCreate a new branch#release/x.x.x(new branch#release/[version number], e.g.The release / 1.0.0)
  • Allows completed functionality to be released (tested) to be merged into the branch#release
  • When the release version is done, merge into the branch#masterBranch,#develop

4.2.4 new

  • releaseBefore packaging, ask all development in the group to make sure that the code to be released is ready (merge, cut, change, etc.)
  • releaseAfter packaging, notify relevant people to test and describe the content of the release (new features, cuts, BUG fixes, optimizations, etc.)

5. Release a new version

  • 5.1 After the master merge is complete, the new version can be published. We use the tag tag to indicate the version.
  • 5.2 A Tag is similar to a branch except that it is a copy of a pointer created from a commit and therefore cannot be moved, but multiple tags can be added and removed

  • 5.3 Labels can also be pushed to the remote end

  • 5.4 Click OK to view the version information on the server

  • 5.5 Branch * Master tag is used

    • performrelaseAfter a successful merge of a release, enter it in the current releaseTAG(TAGNaming conventions: [Version number])

  • 5.6 The process of developing A function A and B and releasing the version on Git:

      1. frommasterPull A functional branch A and A functional branch B
      1. In branchesA and BDevelopment function, after development respectively in the branchA and BUnit testing
      1. Function branchA and BAfter the unit tests are done separately, they are merged intodevelopTo do integration testing
      1. There are new releases to be made frommasterDraw one from the stable branchreleaseThe branch acts as a packaged release branch

      1. There may be four requirements:

      2. Only one feature, A or B, is included in the Release, in which case branch A or B is merged into Release for the final packaged Release test, and released after the test is completed.

      3. This version should include both function A and function B, and merge both branches into the release branch for final packaged release tests and release after completion of the tests.

      4. After the release is complete, merge the Release branch into Master and Develop, respectively

      5. Delete the release branch at this point and the released functionality A or B or AB

  • 5.7

Version Name consists of three digits separated by two dots, representing the major Version number, minor Version number, and compiled Version number, for example, 1.1.0, as shown in the following figure:

  • Major Version number: +1 when the App has a relatively large feature update, such as adding some major new features.

  • Minor version number: +1 for routine App version update, note that BugFix does not need to update minor version number.

  • Compilation version: +1 for each build package, ensuring the uniqueness of each build package, facilitating fault locating and troubleshooting.

6. Cache and fix bugs

  • 6.1 Bug Repair Generally occurs in Bug repair of the released version. That is, Bug fix the master branch.
  • 6.2 It is common for us to work on the Dev branch and then switch to the Master branch for Bug fixes.
  • 6.3 As mentioned earlier, when switching branches, make sure the branch is committed. If the current Dev branch can commit, this is definitely the best option, but if it can’t commit at the moment, caching is needed
    • So the question is, right? How do you store it?

  • 6.4 After storage, the work will become very clean, and you can rest assured to cut to other branches

  • 6.5 How to recover after on-site storage

  • 6.6 Classification of storage functions

    • 6.6.1 The file is not temporarily saved

    • At this point, text.txt is not tracked by Git, so it is not cached by default
    • So it stays in the file system. If we switch to the MAste R branch
    • This change (adding a new file is also a change) is carried to the master

    • 6.6.2 The file has been temporarily saved
      • role
        • To prevent the file from being mistakenly committed in master and appearing in a version that should not be there
      • Deleting files also needs to be added to the staging area to store the site

    • 6.6.3 Reserve the temporary storage area
      • If the change option to keep staging is checked at the cache site, content that has been added to the staging area is retained

    • And when you switch branches, the contents of the staging area are carried to other branches. So that other branches can see the changes made

  • 6.7 Master branch Bug fixes

  • 6.8 Branch HotFix Rules

    • repairBUGWhen from the branch#masterCreate a new branch#hotfix/x.x.x(new branch#base/[version number.BUG number], e.g.The base / 1.0.2)
    • repairBUGThat’s it. Merge into the branch#masterBranch,#develop

7. Collaborate with multiple people

7.1 Git code submission specification

  • Submit code carefullyreviewAll the code I wrote
  • Before submitting the test, fully test yourself according to the test cases
  • Multithreaded data read and write must pay attention to thread safety, the lock of the lock, try to use thread safe container
  • Same branch code update mandatory use,Rebase,To keep the branches clean. Recommend to use,AndroidStudio,Built-in version control tool to avoid errors.
  • Merging between branches should be done using,The Merge,To maintain a complete merge record.
  • Avoid low-level null pointer errors
    • Java code object usage nulls
    • Java calls a function defined by Kotlin. The parameter must be null
  • To follow,Alibaba Code Guide,Don’t make any spelling mistakes in your code,IDEIf you encounter wrong words, you will be warned. If there is a warning, you should correct it in time to avoid code reading difficulties
  • BugfixVersion rules can only be modifiedbugThe related content is not allowed to increase requirements or modify the content, repairbugTo find outbugThe real reason to avoid in order to repairbugAnd introduce new problems

8 Conflict Resolution

It is not recommended to use the native diff tool to resolve conflicts. We can use the tools that come with AndroidStudio or use ByondCompare to handle conflicts

9 The version is rolled back

10. Line feed compatibility

11 Undoing the Modification

  • When will it be neededSourceTree (Git)Undo modify

12 Other Operations

13 Git Branch Cleanup Principles

  1. Delete useless branches periodically.
  2. releaseAll branches remain, but only if there is a common naming convention.
  3. alreadymergeBranches that pass can be deleted after a month.
  4. notmergeBranches can be deleted after three months with the consent of the branch creator.
  • Addendum to branch creators:
    • A. If it is A public branch like Release /bugfix, it may not have A personal attribute name.
    • B. If branches are created for personal functions, they must have a requirement ID name, for example, 031004
    • C. If the branch creator cannot be confirmed, it shall communicate with the group to confirm whether the branch can be deleted and then make a decision (if no one claims the branch, the clearing personnel shall decide whether to delete it by themselves).

14 fromSVNMigration toGit

  • fromSVNMigration toGitNot only does source code migration need to be done, but we also want toOn the SVNthecommitInformation can also migrate. Here we useSubgitTool.
    • You have made a lot of changes to the source file since your last commit, and you want to go back to the original state in one step, which is the state since your last commit

15 Git Management history

15.1 Local Version Control System

15.2 Centralized Management and Control System

15.3 Distributed Control System

16 Differences between Git and other SVNS

  • 16.1 One centralized control, one distributed; Nearly all operations are performed locally;
  • 16.2 Directly record snapshots instead of difference comparison;
  • 16.3 Git branch is very convenient to use;
  • Git usually only adds data; Once you commit a snapshot to Git, it’s hard to lose data, especially if you regularly push your database to other repositories;

17 Flowchart of Git commands

18 Git file status

Your likes, comments, favorites, forwarding, is a great encouragement to me!