Version tree/graph/network

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

Here’s a counter example:

Here’s a good example:

Git File Status

Check git status

  • Untracked New file is not versioned
  • unmodify
  • modified
  • Staged Git Add temporary storage

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:

  • The development of different functions at the same time does not conflict, can be tested independently
  • Conflict resolution can be centralized
  • Distinguish between features or future versions

The purpose of a tag is to label a commit point and tag a published version so that you can roll back a particular version later without having to revert.

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. Functional branch Rebase Development branch (why)
  4. The functional branch is merged into the development branch

Note:

  • Do one thing at a time and write a clear comment
  • Used each time you pull a remote branchgit pull --rebase
  • Where the branches come out, where they end up
  • Rebase before merging

Fix the bug steps

Test line bug fixes

Similar to development steps

Online bug fixes

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

Git Use Tips

Rebase and merge

Git rebase git rebase git rebase

Git merge and Git rebase both merge the contents of the two branches and the end result is no different, but rebasing makes the commit history cleaner.

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

Git merge results

Git rebase

Order of submission points

  • git mergeCommit points are in the same chronological order as commit points, i.e., commit points for master are after commit points for dev.
  • git rebaseAfter, the order becomes byrebaseAll commits are in front of the branchrebaseThe branch (dev) commits are beingrebaseCommit points on the same branch remain in chronological order after the branch.

Branch changes

  • After rebase the master, dev has changed from two bifurcated branches to overlapping branches. It looks like dev is pulled from the latest branch of the master.

When to use rebase/Merge

Hypothetical scenario: Pull branch feature-a from dev. Git merge feature-a; git merge feature-a; Instead, git rebase dev is used when feature-a wants to update dev.

When used, it mainly depends on the relationship between the two branches.

Pay attention to

In general, rebase dev and 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

Git push -f is used to override the remote branch. If you use git pull as prompted, the result will be merge and a merge commit point will be generated.

carefulgit push -f!

— — — — — — — — — —

git merge –no-ff

–no-ff stands for no fast merge

Git Merge differs from Git Merge

Git merge results

The branches of the merge and the current branch are graphically aligned, and the commit points of the merge are merged into the current branch one by one.

Git merge –no-ff

The branch being merged is not on the same line as the current branch. The commit point is still on the original branch and a new commit point is created on the current branch.

— — — — — — — — — —

Git rebase -i

It is used to organize submissions and submit information.

Git rebase -i dev The following interface is displayed.

1 Pick FFC75A4 Modified 2 Pick 6C2217f BBB 3 Pick A615960 Modified A 1 4 Pick e4817B3 Modified A 2 5 Pick 8550690 modified A 3 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

Change the pick in front of the commit comment to merge the commit, where r is to keep the commit and modify the commit information, and f is to keep 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 of editing two r typed submission information, and modify the submission information to save.

Now if I look at the log, the five commits I just did have 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 Change BCopy the code

— — — — — — — — — —

git pull –rebase

Differences with Git pull

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

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

Git pull –rebase is the correct way to pull the latest branch.

Therefore, it is recommended that you pull a remote branch at any time, preferably with the –rebase parameter.

— — — — — — — — — —

Reset and revert

  • git resetModify the position of HEAD
  • git revertRestores a commit and produces a new commit to record the restore

Git reset common command

  • Git reset HEAD {filename}: Cancel the temporary file and restore it to the modified state.

  • Git reset HEAD~{n}: resets to the previous n commits. It can also be used to merge commits and is written the same as git commit –amend.

git reset HEAD~1
git commit

Copy the code

  • Git reset {version}: resets to the specified version.

  • Git reset:

    1. Using parameter--hard, the staging area, workspace, and the directory tree to which HEAD points have the same contents.
    2. Using parameter--soft, only change the direction of HEAD, the staging area and workspace remain unchanged.
    3. Using parameter--mixedOr no arguments (default is--mixed), change the reference pointing and reset the staging area, but do not change the workspace.

— — — — — — — — — —

git reflog

Git reflog is used to view local commit records. You can view local commit, merge, and rebase records with version numbers.

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): checkout 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 pull them out using git Stash pop. Useful when you have not committed workspace content but want to cut to another branch.

Pay attention to

It is not recommended to use git Stash in different branches at the same time. If multiple branches are involved, it is better to commit first rather than push to a remote one. It can be used in the next commit –amend to the last commit.

Original text: juejin. Cn/post / 684490…