Git Learning Notes

A good scenario Git best Practices manual (multilingual) : github.com/k88hudson/g…

Git version control and storage model

What is Git and why do you use it

Imagine a scenario: You wrote a version 1.0 file, and now you need to modify it to improve the content. You are afraid of losing the original file, so you make a copy of the 1.0 file and modify it on this copy.

Two files are not enough to cause too much trouble, but in actual study and work, I often encounter multiple files in a project, and each file has a lot of modifications. In teamwork, everyone needs to update the progress synchronously to ensure that there is no error in the updated and communicated parts. This makes versioning very difficult and incurs a significant mental and human cost.

Git was created to solve this problem. Git is a version control system that helps workers keep track of every update committed without having to manually create copies, merge updates, and manage version history. In teamwork, also don’t need a manager active distribution of historical records and the new version to other members, project members can record directly from any one of the intact version machine (such as a dedicated central server), remote copy, pull a the same record, create your own work branch, to update the push back. After each member completes their own tasks and pushes them, the manager checks these branches through Git, merges them, and completes the version update of the overall project.

Distributed systems, localized storage

Git is designed to be a distributed management system, with a complete version library on every machine participating in the project. The submission and modification of version history is also done locally. For the user of this machine, version and branch can be switched quickly, without obtaining version information through the network.

Networking is needed when you need to interact with the version history of other machines, such as cloning, remote push, and consolidation.

As for the so-called “central server”, just for convenience, setting up a server with a clean and complete version history for release, management and standardization does not mean that Git is not a distributed system.

Snapshots of storage items over time

Git creates a snapshot of all files and saves the index/pointer each time an update commits/saves the project status. Of course, you don’t need to recreate and store unmodified files, just keep the link pointing to the previous file. Therefore, when changing or viewing different versions of files, Git can replace them without recalculating the differences by changing the index/pointer. This is the reason why Git version switch is relatively fast.

Three states

The folders/files Git will use for version control are divided into workspace, staging area, and repository.

• Workspace, which represents files that we are currently writing, modifying, and have not yet committed to the staging area
• Holding area, passgit add Save the current state of the workspace as preparatory information that may be submitted to the repository in the future, and you can add overwrites multiple times
• The repository, or Git repository, is available throughgit commitSave the staging area information as the final, official version record and add it to the repository. The contents of the repository cannot be modified at will (version rollback is an index/pointer rollback and does not actually delete the content).

start

Install Git

Git-scm.com/book/en/v2/…

Configure user information after the installation

Set the username and email address. This setting is necessary. Every Git commit requires a source record for it to work properly.

$ git config --global user.name "John Doe"
$ git config --global user.email "[email protected]"
Copy the code

–global represents the global configuration. By default, local commits run under this configuration. If you want to change the configuration under a particular project, run under this configuration without –global.

Check configuration information You can run the following command and view the official document for other configuration parameters.

$ git config --list
Copy the code

See the help

$ git help config
$ git add -h
Copy the code

The above commands can be used to view the help information of a specific command on the console. The help command can be used to view the complete manual. -h is more concise and is a quick reference for viewing optional parameters of the command. The example statement shows viewing parameters of Git add. In the follow-up study, parameters of many commands can be checked by using the above commands.

In addition, it is also convenient to search for instructions through Git official website, technical forum, search engine and other methods.

Git basis

Obtaining Git repository

To create a Git repository locally, either initialize it locally or clone it from someone else:

Initialize a repository in an existing project directory

Go to your project directory and type the following command to have Git take over files in the current directory and its subdirectories.

$ git init
Copy the code

This step creates a.git hidden folder in your directory for git work. Do not tamper with the contents of this directory.

Clone a repository from another server

$ git clone https://github.com/libgit2/libgit2 mylibgit
Copy the code

With git Clone, you can clone the libgit2 repository on Github to a directory named mylibgit. Now you have the complete version information of the repository on Github, as well as the.git folder of the original repository. You can build on that directly.

Git also supports Git ://, or SSH transfer protocol. For details, see Github and GitLab. To identify users and ensure security, these websites generally require hash authentication keys on local machines for communication security verification. This topic will be added later.

Basic operation

The following diagram shows the state change cycle of the file:

• Untracked is not tracked, usually when a new file is created or the file is removed from the staging area or repository record
• The file has not been Unmodified
• Workspace file has not been committed to staging or repository after modification
• Passage Ten has been Staged and has not yet been committed to the version library

Viewing file Status

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Copy the code

Git status allows you to see which files are newly created/untracked (tracked via Git add), which files are being modified and haven’t been temporarily stored, which files haven’t been committed in the staging area, and so on. It is highly recommended to check before each commit.

The sample information indicates that the workspace is clean, which means no files have been created or modified. Notice the word master, master refers to the branch we’re currently in, which is the default master branch, and the concept of a branch can be looked at later.

File trace/add to staging area

$ git add *.c
$ git add LICENSE 
Copy the code

If a file is not tracked, then in Git’s Git status message it is not modified. Writes to the new file are always untracked.

Add workspace files that have not been traced or modified to the staging area with Git add. A convenient way to add all files is:

$ git add --all
Copy the code

Commit to the repository

$ git commit -m 'initial project version'
Copy the code

-m and the following string are used to mark the description of the submission. Git will automatically generate a hash check value for each commit as a unique identifier for the commit, which can be used for subsequent identification, switching, etc., and can be viewed via Git log.

If you want to commit directly from your workspace in one step, you can use the -a option to do both staging and commit, but this is generally not recommended.

Ignore the file gitignore

Some files, such as temporary files, development toolkits, log files, etc., are not required to be managed by Git. In this case, you can create a.gitignore file in the root directory of your project and list the patterns (re) of the files to be ignored. For example:

*.[oa]
*~
Copy the code

* Matches all strings. The first line ignores all files ending in.o or.a, and the second line ignores files ending in ~. Here are some more examples

#Ignore all.a files
*.a

#But keep track of all lib.a, even if you ignored the.a file earlier! lib.a
#Only TODO files in the current directory are ignored, not subdir/TODO
/TODO

#Ignore any folder named build in any directory
build/

#Ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

#Ignore.pdf files under the doc/ directory and all its subdirectories
doc/**/*.pdf
Copy the code

To view changes

$ git diff
Copy the code

The above command compares the difference between the current workspace and the current staging snapshot, that is, the difference between the current file and the file when Git add

$ git diff --staged
Copy the code

Passage Passage Parameters are added to compare the differences between the current staging area and the latest version library, that is, the differences between git Add and Git commit files. (You can also use the cached parameter, synonymous)

Remove the file

$ git rm filename
Copy the code

The above command will delete the file from the workspace and staging area, and git status will show that the file is deleted if it has not been modified or committed to the staging area. After the next commit, Git will no longer put the file under version management.

If the file to be deleted has been modified or placed in the staging area, add -f to git rm to forcibly delete the file.

If you want to remove a file from Git management but still want to keep it in your current working directory, add the –cached parameter and ignore the file with.gitignore

Move/rename the file

Git does not directly track file movement. Simply renaming a file is treated as a new file. To rename a file in Git, you can do this:

$ git mv README.md README
Copy the code

It is equivalent to the following three commands

$ mv README.md README
$ git rm README.md
$ git add README
Copy the code

With git mv, git can infer that this is a rename, and git status will display:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
Copy the code

Viewing Historical Records

Git log

$ git log
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <[email protected]>
Date:   Sat Mar 15 16:40:33 2008 -0700

    removed unnecessary test

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <[email protected]>
Date:   Sat Mar 15 10:31:28 2008 -0700

    first commit
Copy the code

Git commit -m XXX git commit -m XXX

If you want the submission information to appear on a single line, use –pretty=oneline

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
Copy the code

More commonly, the –pretty and –graph arguments are used to make it easier to view historical checksums, branch merges, and so on

$ git log --pretty=format:"%h %s" --graph
* 2d3acf9 ignore errors from SIGCHLD on trap
*  5e3ee11 Merge branch 'master' of git://github.com/dustin/grit
|\
| * 420eac9 Added a method for getting the current branch.
* | 30e367c timeout code and tests
* | 5a09431 add timeout protection to grit
* | e1193f8 support for heads with slashes in them
|/
* d6016bc require time for xmlschema
*  11d191e Merge branch 'defunkt' into local
Copy the code

–pretty=format: is a syntax that specifies the output format, %h for the hash of the output abbreviation, %s for the output commit description.

You can check the official document for specific parameters: git-scm.com/book/en/v2/…

Cancel the operation

Modify the submitted

If some files are found to be wrong or forgotten to be committed to the staging area after a mistake, you can run the following command after modifying and adding the files to the staging area:

$ git commit --amend
Copy the code

With the –amend argument, you can recommit, so you can use this command to fix the last bad commit after making the right changes, for example:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
Copy the code

Cancel the temporary file

Suppose you have committed some files to the staging area with git add * or some other operation. Now you want to withdraw a file from the staging area, such as readme.md, using the following methods:

$ git reset HEAD README.md
Copy the code

Two identifiers are used: reset, which represents a reset, and HEAD, which is a pointer to the most recent current commit. This means that the current file state is changed to the last time it was committed, so that the staging area is restored and the workspace changes were not committed. For HEAD, see the HEAD pointer

Now look at it using Git status and you will see that readme. md has been categorised Changes Not Staged for Commit.

Undo workspace changes

If you want to undo a change to a workspace file with Git, you can override it with the most recently committed version, thus resetting the change.

$ git checkout -- README.md
Copy the code

Version back

If we make a bad COMMIT, or if some of the solutions are abandoned and we need to go back to a previous version to rebuild, we need to do a version rollback:

$ git reset --hard HEAD^
Copy the code

There is a –hard parameter, which directly resets all work to a commit corresponding to a pointer. HEAD^ represents the last commit of the most recent commit. A ^ represents one advance. For example, HEAD^^ represents two backbacks….. . You can also specify the hash checksum for different commits using git logs. For example, if the first six bits of the hash value of a submission are A721C9, run the following command to return to the submission.

$ git reset --hard a721c9
Copy the code

Note that it doesn’t have to be a 6-bit hash, Git will automatically look for a hash that starts the same as the one we entered. For example, if there are no duplicates, it is ok to enter the first four digits, but if there are duplicates, it is time to enter more digits.

Tag the submission

What is a label?

In general, a Tag represents the Tag, name, version number, etc. of a particular commit, such as V1.0 or V2.0-beta. Unlike Git commit-m, which is generally a summary description of the commit, such as what was changed or added. This distinction needs to be made.

Viewing Label History

Very simple, as follows:

$ git tagV0.1 v1.0 v1.1Copy the code

Create a label

Git comes in two types of tags, Lightweight and annotated.

The former is a submitted reference, and the latter has more information than the former, such as the name of the labeler, email address, date and time, etc. The website recommends creating a footnote tag because it provides more traceable information.

• The following is an example of creating a footnote label:

$Git tag-a v1.4-m"my version 1.4"
Copy the code

The above instructions create the v1.4 tag with -a and add the tag description with -m.

Git show v1.4 shows the commit information for this tag and the commit information for the corresponding commit.

• The following is an example of creating a lightweight label

$Git tag v1.4
Copy the code

Git show v1.4 contains only commit information and no tag information.

• An example of tagging a history commit is as follows

$Git tag -a v1.29fceb02
Copy the code

Add the hash of the submitted hash.

Push the label

By default, labels are not sent to the remote warehouse server, so you need to push labels manually. The instructions for pushing labels are as follows:

$Git push origin v1.4
Copy the code

The above directive pushes the V1.4 tag to the remote Origin repository (the Origin concept is described in the remote server later).

To push multiple labels, use the following command:

$ git push origin --tags
Copy the code

The command pushes all labels that are not on the remote server

Remove the label

Delete a local label:

$Git tag - d v1.4
Copy the code

Deleting a Remote Label

$Git push Origin --delete 1.4
Copy the code

Git branch

The perceptual cognition

The branch function of Git is the key to master.

Git creates snapshots for different versions of files and uses indexes/Pointers to point to different snapshots to quickly switch versions.

So the concept of branch is actually very simple. Suppose we have an original version of a file called V0, with the default pointer master pointing to that version. When we commit an update to V1, V0 -> V1 becomes an ordered reference, with master acting as a pointer from V0 to V1. Now access master, and the V1 version of the file will be displayed.

Then another team member came along, so the two decided to develop and merge their own parts, and each cloned a project from a central server. Suppose you update the V1 version of the file to v2-1, represented by the pointer dev1, and he updates the file to v2-2, represented by the pointer dev2. So we have a bifurcation between V1 and V2, so V1’s master pointer has two paths, but both paths are incomplete, so how do we merge them into a real V2, and let the master point to V2?

Now the duo are using the following solution: they create a new pointer called pre to master, V1, which means pre-release. And now they’re going to merge their parts into the Pre, so the pre now becomes V2. At this point, let’s review all pointer changes:

Pointer to the	Change the path
master	V0 -> V1
dev1	master -> V2-1
dev2	master -> V2-2
pre	Master -> V2 (merge dev1 and dev2 file contents)

As you can see, the whole file version change, called branch, is very graphic. After checking that there is no problem, we let the master pointer follow the path of the pre pointer, and now the master is pointing to V2! If you want to continue updating the version, pull the master file again and repeat the idea.

The above content involves the creation, switching, merging and other operations of branches.

Basic operation

Pointer to the HEAD

The HEAD pointer is a concept that can be intuitively understood as HEAD always points to the latest commit under the current branch.

In previous operations, we want to switch between the different branches, we have to see the different versions of a file, under different branch here to “see” the master, dev1, dev2, requires a [eyes], the [eyes] is the pointer to the HEAD, that is we write some data structure algorithms, such as tree and chain table, Frequently used active pointer.

For example, if HEAD points to Dev1, we see dev1’s latest file snapshot, and if HEAD points to master, we see the master’s file snapshot.

Create a branch

$ git branch dev1
Copy the code

The above directive creates a branch called dev1 with a pointer to the current file, HEAD.

See the branch

$ git branch
  dev1
* master
Copy the code

* indicates which branch is currently in.

Switch branch

$ git switch dev1
Copy the code

You can use the -c argument if you want to switch branches while creating them.

When you commit a new version under the Dev1 branch, both the dev1 and HEAD Pointers advance further, while the original Master branch does not.

Undivided branch merging

Now, assuming that the dev1 branch has been completed and committed, we need to change the second requirement from the master branch. Let’s switch back to the Master branch:

$ git switch master
Copy the code

The HEAD pointer returns to the master position, and the workspace contents revert to the master state. We create a Dev2 branch to make changes and commit, the same steps as Dev1.

Now let’s merge the dev2 additions to the master:

$ git switch master
$ git merge dev2Updating f42c576.. 3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)Copy the code

The merge command merges the contents of the target branch to the current branch. We notice that the output has the word fast-forward, which stands for Fast forward. This is due to the change relationship between dev2 and master. It is a straight line, and the update can be completed by moving the master pointer to Dev2.

Delete the branch

Now dev2 is useless, let’s delete it.

$ git branch -d dev2
Copy the code

Merging of diverging branches

Now we’re going to add dev1 work to the master as well. Obviously, there are some differences with dev2 merging: Dev1’s content comes from earlier history and does not have dev2’s changes, and moving the current master pointer directly to Dev1 will lose dev2’s content. Some additional conditions are encountered:

The contents of files changed by different branches have overlapping parts

For example, if two branches change the same part of the same file, it is very common. For example, dev1 puts a function at the top and Dev2 adds a function at the top. The idea is to have both functions.

$ git switch master
$ git merge dev1
Auto-merging Test1.txt
CONFLICT (content): Merge conflict in Test1.txt
Automatic merge failed; fix conflicts and then commit the result.
Copy the code

These prompts indicate that a merge conflict has occurred, and when the file is opened, the following condition occurs:

Git automatically makes special changes to the file. Both dev1 and dev2 changes occur. Between <<<<<< HEAD and ======, the current master makes changes to the historical file. The result of dev2 (we merged Dev2 into the master first). And between >>>>>> dev1 and ====== represents the dev1 changes that are now being merged.

Git add and Git commit: Git commit: git commit: Git commit: Git commit: Git commit

Changes to different branches have no conflicting parts

It’s also very common for multiple people to write code in separate file modules, with different people writing different files. The merge then proceeds normally, merging the snapshots of the two branches and their most recent common root into a new commit.

For example, changes in Dev2 create new files, not modify source files. At this point we repeat the previous process and merge the master pointing to dev2 with dev1:

$ git switch master
$ git merge dev1
Merge made by the 'recursive' strategy.
Test1.txt | 1 +
1 file changed, 1 insertion(+)
Copy the code

Even though the master and Dev1 are on different branch paths, there is no previous conflict at this point. Instead, their parts are directly superimposed to form a new COMMIT.

Rebase for branch management

Git merge Merges the contents of two branches and their nearest common root node into a new commit:

So what does Rebase mean?

Common Rebase examples

In the case above, we could logically not do a violent merge. Instead, we could compare the differences between C4 and C2, record the changes, and then add them to C3, forming a new commit for which the experiment redirects. After confirming that everything is correct, we ask the master to move forward. This is what Rebase does:

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
Copy the code

You can see that experiment is transferred from C4 to C4′, and the file content is equivalent to C5. In this case, you can use Git merge to make the master step forward.

$ git checkout master
$ git merge experiment
Copy the code

One might ask, what does this look like? In fact, in terms of results, the result of git merge is the same, but with the benefit of a cleaner commit history, you can see multiple forks in a straight line from git log –graph. Developers can rebase their dev developer branch locally to the master, and the dev is already in the merged state, while the master remains unchanged. In this way, project managers can merge code directly and quickly, reducing the pressure of integration, and also meet the needs of code cleanliness and obsessiveness, especially for Git repositories with multiple members and branches.

A more complex Rebase example

The example in the figure can be assumed as follows: at C2, the project is split into two parts, one is the master underlying backbone code, and the other is the specific application development starting from C3, which is divided into two parts, the Server server and the Client client.

If the client is already developed and wants to be added to the master, the server is not yet completed and cannot be merged with the client or C3 root node. By this time you can use the git rebase, C8 and the change of C9, added to the master in the first snapshot file, figure is changed to the following effect:

The specific code is as follows:

$ git rebase --onto master server client
Copy the code

The C8 and C9 changes are added to the master branch to form a new path. Then the client pointer points to the final result.

Move the master pointer as before:

$ git checkout master
$ git merge client
Copy the code

The new submission history is as follows:

Now that the server has been developed, we need to rebase its updated content on the Master branch. The previous steps were to switch to the branch to rebase, such as client, and then specify the target branch. Now we can use a more complete syntax and rebase the branch directly without switching branches:

$ git rebase master server
Copy the code

Commit changes from the server branch to the master snapshot. The submission history becomes the following image:

Then let the master branch proceed and delete the server and client branches:

$ git checkout master
$ git merge server
$ git branch -d client
$ git branch -d server
Copy the code

Submission history finally turned into a clean line, Amazing!

Do not use Rebase carelessly

The disadvantages of Rebase are also obvious. If you look a little closer, you’ll realize that Rebase destroys previous branch histories, such as the original paths of the client and server in the above example, so don’t use Rebase to break branches if someone might be developing on them!

If you follow this golden rule, nothing will go wrong. Otherwise, the people will hate you, and your friends and family will laugh at you and spit on you.

In fact, in the original example, it was unwise to destroy the client and server branches. Because client and Server are also relatively independent subject branches in real projects, which are often version-controlled in a central Git repository and developed on client and server respectively by the front and back end staff, and the project is iterative, these subject branches should be retained.

For more difficult and painful examples of how not to do this, check out the Rebase section on Git’s website.

Rebase VS Merge best practices

Before we get to the answer, we need to rethink what Merge and Rebase mean for commit history.

The Merge operation itself is a record of history. It can trace the changes of various branches. Even though the commit history may seem complicated and confusing, the value and significance of the trace history is eternal.

Rebase destroys the process of change, leaving only the versions that are judged to be “published” and discarding the “rough drafts” in between. The benefit is that as users, we can focus on where we need to do the most research, rather than wasting our time and energy elsewhere.

Git website gives a principle which I think is quite accurate:

As a general rule, only base cleanup history on local changes that haven’t been pushed or shared with others, and never base commits that have been pushed elsewhere, so you can get the benefit of both approaches.

Git commits that need to be pushed elsewhere mean that someone else will continue to develop and study them, which fits the reason for not messing with Rebase mentioned earlier.

Remote Git repository

Now that you’ve mastered most of Git’s common local operations, you can handle the general issues of version control and manage your own projects. Now comes the final step: how to collaborate with others, how to develop with remote repositories, concepts like Clone, Push, pull, and Remote, as well as well-known remote Git repository hosting services like GitHub and GitLab.

In addition, remote Git repositories can be set up themselves, but in most cases developers will use existing hosting services, so this section will not be described, and please refer to the official documentation if necessary.

Transfer protocol

The first step in network communication is to determine a communication protocol. Here we do not talk about the rational part of the git clone command as the entrance to illustrate the role of the protocol in the actual development.

$ git clone [email protected]:xxxx/xxxx.git
$ git clone https://github.com/xxxx/xxxx.git
Copy the code

The above two statements are common examples of cloning remote projects stored on GitHub. The first is the URL under SSH protocol, and the second is the URL under HTTPS protocol. The actual content is the same, but the protocol is different. Other remote Git services such as GitLab are similar, and the URL may be represented differently, but the essence is the same.

Generating an SSH Public Key

To ensure security, many Git servers use SSH keys for authentication to distinguish, authenticate, trace specific development machines, and control permissions. In GitHub’s case, you need to do two things:

• Generate the local SSH key pair by entering system commands on the console
• Find the local key file and add the public key from the key pair to GitHub’s trust list

To complete the work above, can download and upload project normally, specific operation can refer to lot SSH key guidelines: help.github.com/articles/ge…

Basic operations for remote interaction

Associated with the remote repository

There are two cases of [association] here. One is that there is no existing project in the local area and a copy of the project needs to be downloaded to the local area through Git Clone. In this case, the local repository and the remote repository will be automatically associated. On the other hand, there is an existing project locally and a remote associated repository needs to be added or changed. Now let’s say we have a local repository named Learngit. Now let’s create a GitHub repository with the same name and execute the following commands locally:

$ git remote add origin [email protected]:yourname/learngit.git
Copy the code

The above instructions can be analyzed as follows: Yourname is your GitHub account name. Yourname is your GitHub account name. Yourname is your GitHub account name. This is easy to look up. Once you’ve created the Github repository, its URL is available for viewing, both SSH and HTTPS urls.

If you want to change the url of the remote repository, just do the following:

$ git remote set-url origin [email protected]:yourname/learngit.git
Copy the code

Set-url is used here to make the change.

To view remote warehouse information, use the following command:

$ git remote -v
origin  [email protected]:yourname/learngit.git (fetch)
origin  [email protected]:yourname/learngit.git (push)
Copy the code

The -v argument performs a view of the remote repository, followed by fetch and push indicating that the remote repository can perform fetch or push behavior.

To disassociate a remote repository, use the rm command:

$ git remote rm origin
Copy the code

View/trace other remote branches

Git Clone can be downloaded from a local repository. When using Git branch, you will find that there is only one local master branch. If you need to develop other branches based on remote branches, you need to use the -a parameter to query:

% git branch -a
Copy the code

The -a parameter lists the local and all remote remote/origin/XXX branches. In this case, we need to create a new branch locally and associate it with a remote branch:

$ git checkout -b myDev origin/myDev
Copy the code

With the myDev branch created and synchronized with the remote repository of the same name, you can now develop and push to the corresponding remote branch. Similarly, the local master branch corresponds to the Origin /master branch by default.

To see the remote branch corresponding to a local branch, use the following command:

$ git branch -vv
Copy the code

Push to remote repository

$ git push -u origin master
Copy the code

The above command pushes the local master branch to the remote origin repository, which uses the push command and the -u parameter, the former is the meaning of remote push, the latter means to associate the local master and remote master, in the future push, Just use git push to simplify. Of course, in general, it is recommended to include the local branch name and the remote repository name to remind yourself not to commit the wrong branch.

If you are developing based on other remote branches, as described earlier, just follow these steps:

$ git checkout -b dev origin/dev
Copy the code

Associate the local branch with the remote branch, so that you can develop based on the dev branch, and push:

$ git push origin dev
Copy the code

Pull remote branch updates to local

The actual development is collaborative, and when you are developing locally, the remote repository may already have some updates, so you need to merge the latest content in first, organize it, and then submit it for upload.

$ git pull
Copy the code

The above command attempts to merge the branches of the Origin remote repository locally. Sometimes the local and remote branches may fail because they are not exactly the same, so you need to display the relationship between the specified local branch and the remote branch to be pulled. For example, if the origin/dev branch is not associated with the remote origin/dev branch, it cannot be identified and pulled, and needs to be set manually:

$ git branch --set-upstream-to=origin/dev dev
Copy the code

Git pull.

As mentioned earlier, the second step of Git pull is merge, which requires the same operation as the previous branch management. Git push after the merge, update, and commit to the local repository:

$ git commit -m "fix env conflict"
$ git push origin dev
Copy the code