Version tree/graph/network

  • Clean, concise and clear
  • Clear submission information
  • Easy to maintain and read

Here’s a counterexample:

Here’s a positive example:

Git file status

Check with git status

  • Untracked the new file does not add versioning
  • unmodify
  • modified
  • Staged with Git Add

Git diff –staged or Git diff –cached To see the difference between staged files and the last commit

Branches and tag

Use branches wisely, the benefits of branches:

  • Developing different functions at the same time does not conflict and can be tested independently
  • Focus on conflict resolution
  • Distinguish between features or a future release

Tag is used to tag a submission point. Tag is used after the release of the version so that it can be rolled back later. No revert is required.

A tag is a record of a version.

Develop new functional steps

  1. Pull a functional branch from the development branch
  2. Functional branch development and testing
  3. Function Branch Rebase development Branch (why)
  4. The functional branch is merged into the development branch

Note:

  • Do one thing at a time, write clear comments
  • Used each time a remote branch is pulledgit pull --rebase
  • Where the branch comes out, where it ends up
  • Rebase before merging

Fix the bug steps

Fixed bug of test line

Similar to the development steps

Online bug fixes

  1. Pull a fix branch from master
  2. Rebase the master after the test
  3. Merge back to master

Git Tips

Rebase and merge

Git rebase

Both Git merge and Git Rebase can integrate the contents of the two branches and the end result is no different, but changing the base makes the commit history cleaner.

For example, if dev commits once and master commits once after that, the state of the two branches is as follows:

Git merge results:

Git rebase results:

Order of submission points

  • git mergeThe order of commit points is the same as the time of commit, that is, master commits after Dev.
  • git rebaseAfter, the order becomes byrebaseThe branch (master) where all the commits are done firstrebaseBranch (dev) commits are beingrebaseCommit points on the same branch are still in chronological order.

Branch changes

  • After the dev is rebase master, the two branching branches become overlapping. It looks like the dev branch is pulled from the latest master.

When to use rebase/merge

Suppose: branch feature-a is pulled from dev. Git merge feature-a; git merge feature-a; Conversely, when feature-a wants to update the contents of the dev, git rebase dev is used.

When using the main look at the two branches of the “primary vice” relationship.

Pay attention to

In general, the rebase dev and the remote origin/dev will be separated, and the command line interface will prompt:

Your branch and 'origin/dev' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
Copy the code

In this case, you need to use git push -f to force push to overwrite the remote branch. If you use git pull in the prompt, the result becomes a merge and a merge commit point is generated.

carefulgit push -f!

— — — — — — — — — —

git merge –no-ff

–no-ff means not to merge quickly

Difference from Git merge

Git merge results:

The merge branch and the current branch are merged as a line on the graph, and the merge commit points are merged into the current branch one by one.

Git merge –no-ff

The branch to be merged is not on the same line as the current branch. The commit point to be merged is still on the original branch, and a new commit point is generated on the current branch.

— — — — — — — — — —

Git rebase -i

It is used to organize submissions and submit information. This does not seem to work very well.

Git rebase -i dev The following page is displayed.

3 Pick a615960 4 pick e4817b3 5 pick 8550690 6 7# Rebase 3190ea4.. 8550690 onto 3190ea4 (5 command(s))
8 #
9 # Commands:
10 # p, pick = use commit
11 # r, reword = use commit, but edit the commit message
12 # e, edit = use commit, but stop for amending
13 # s, squash = use commit, but meld into previous commit
14 # f, fixup = like "squash", but discard this commit's log message
15 # x, exec = run command (the rest of the line) using shell
16 # d, drop = remove commit
17 #
18 # These lines can be re-ordered; they are executed from top to bottom.
19 #
20 # If you remove a line here THAT COMMIT WILL BE LOST.
21 #
22 # However, if you remove everything, the rebase will be aborted.
23 #
24 # Note that empty commits are commented out
Copy the code

Modify the pick in front of the commit comment to merge the commit, where r is to retain the commit, modify the commit information, and f is to retain the commit but discard the commit information.

1 R FFC75A4 Modified 2 F 6C2217F BBB 3 R A615960 Modified A 1 4 F E4817B3 Modified A 2 5 F 8550690 modified A 3Copy the code

Then enter the interface to edit the two submission information with r, modify the submission information and save it.

Now if you look at the log, the five commits have now become two commits.

commit 94784f0c163bc4b2970f73066c91fac16b64be32 Author: *** Date: Mon, Jan 8 17:01:57 2018 + 0800 to modify a commit 52907 b261821afb0c38754ba95545ff8826910db Author: * * * the Date: Mon Jan 8 16:28:05 2018 +0800 Modify bCopy the code

— — — — — — — — — —

git pull –rebase

Git pull

In general, there is no difference between adding and not rebase.

However, as you can see from the git rebase feature above, a branch can be separated from its remote branch, and when you use git pull, your local branch will merge with the remote branch.

The correct way to do this is to use git pull –rebase to pull the latest branch.

Therefore, it is recommended to use the –rebase parameter whenever you pull a remote branch.

— — — — — — — — — —

Reset and revert

  • git resetChange the location of HEAD
  • git revertRestores a commit and generates a new commit to record the restore

Git reset Common command

  • Git reset HEAD {filename}: cancel the staged file and restore to the modified and unstaged state.

  • Git reset HEAD~{n}: falls back to the first n commits. It can also be used to merge the commits. The following result is the same as git commit –amend.

git reset HEAD~1
git commit
Copy the code

  • Git reset {version}: rollback to the specified version with a version number.

  • Git reset:

    1. Using parameter--hard, the staging area, workspace, and HEAD point to the same directory tree.
    2. Using parameter--soft, only change the HEAD pointing, the staging area and workspace remain the same.
    3. Using parameter--mixedOr with no arguments (the default is--mixed), changes the reference and resets the staging area, but does not change the workspace.

— — — — — — — — — —

git reflog

Git log is the command to view the commit record, and Git reflog is the function to view the local operation record, you can see the local commit, merge, rebase operation record, with the version number.

b3bf634 HEAD@{0}: rebase -i (finish): returning to refs/heads/feature-rebase-i b3bf634 HEAD@{1}: rebase -i (fixup): Dd19de3 HEAD@{2}: rebase -i (fixup):# This is a combination of 2 commits.A7f47b2 HEAD@{5}: rebase -i (start): checkout dev a472934 HEAD@{6}: Rebase: aborting a7f47b2 HEAD@{7}: rebase -i (start): commit dev a472934 HEAD@{8}: commit A7f47b2 HEAD@{11}: checkout: moving from dev to feature-rebase-iCopy the code

— — — — — — — — — —

git stash

Cache the workspace contents into a stack and then pull them out using the Git Stash pop. Useful when the workspace content is not committed, but you want to switch to another branch.

Pay attention to

It is not recommended to use git Stash on different branches at the same time. If multiple branches are involved, it is better to commit first. Do not push it to a remote location.

Author: Lilac Garden front end team — LWENN