How can I simply use Git's participating team to develop it in the enterprise? Git usage Tutorials

Git is a tool and a science, and it depends on you how you want to learn and how you use it.

What I'm talking about here is the basic requirements that we can get started using git and actually realize the benefits of git.

First, download the installation

Very simple, can see Baidu tutorial git download installation graphics tutorial

second, the initialization operation (see the blog git-ssh Configuration and use of the diagram)

1, the first use of git, you need to set up a git username and mailbox:

$ git config--global user.name "username"
$ git config--global user.email "your email"

2. To see if SSH key has been generated (SSH Secure Shell protocol, see Blog Security Shell Protocol):

$ CD ~/.ssh

$ LS To see if there are id_rsa (private keys) and id_rsa.pub (public key) two files

3. If SSH key has not been generated, use the following command to create or overwrite :

$ ssh-keygen-t rsa-c "your email"

Set Password (enter two password to confirm) or do not set password (three times enter)

4, Login to GitHub or Gitlab official website, after setting up SSH key, Git bash can be used normally

third, the project development use steps

1. Create a remote repository on GitHub or Gitlab

2. Clone project, open Bash, CD to local where you want to create a local warehouse (generally recommended that your development should be in this directory, such as Eclipse workspace in this directory, your local warehouse operations will be synchronized to the development, in the Eclipse Project point right-click Refresh will be updated , super Convenient), and then:

$ git clone "warehouse SSH url" (The success of LS to see the warehouse files, CD in the directory will display (master) main branch)

3, creating branches, generally not recommended directly on the main branch development, so create sub-branches as a development branch

$ git Branch Branch name (Create Branch)

$ git Checkout branch name (toggle branch)

4, after the modification, the submission changes to the buffer :

$ git Add directory/File/. (. For all files in directory)

5. If this stage of modification is complete, you can submit the modification to this branch (can commit after multiple add):

$ git commit-m "commit instructions"

Let's talk about Git's operating area (see the Blog Click to open the link)

The workspace is our local file system.

The repository includes the buffer and the branch area, and the modification of the add is submitted to the buffer, and the commit changes are submitted to the branch area.

6. If a day's task is completed or a task is completed, the contents of the local branch can be submitted to the remote repository for review and consolidation by the manager :

$ Git push Origin branch name

7, because the purpose of using GIT is multi-person collaborative development, so the work done by others may be the basis for you to complete the work, at this time your local need to push to the remote warehouse (you use a remote warehouse) code , you can through:

$ Git Pull Origin branch name (pulls the main repository to local this branch)

The above process is actually two steps,

Git fetch origin (pull remote repository to local) and Git merge Origin branch name (merge local and branch)

* This is actually not very normative, the standard practice is: The Master Master branch of the remote repository for all versions, sub-branches only for local development and upload changes, so all pull should be pulled to master, instead of directly to the pulling sub-branch, and then through the merge The master implementation merges with the master sub-branch:

$ git checkout master (switch from current branch to main branch)

$ git pull (pulls the current version of the remote repository to the main branch)

$ git checkout sub-branch name (switch from main branch to sub-branch)

$ git Merge master (merge with Main branch)

Note: There is also a git rebase directive that is also a merge branch, and the branch that is only merged is extinct, is a complete merge, and merge is the content merge. Rebase can be used with pull, which is said during the 9th clash.

8, before the pull, because we have local changes, they have not been saved, pull will be lost, we can commit, the version is merged and then pulled, but you may not want to do so, and your code is not necessarily the time to upload, merge, it will need to temporarily save our changes :

$ git stash (staged modification)

$ git stash pop (pull, popup modified)

9, in this process, there is a great possibility of encountering conflicts

The most common conflict is content conflict : You modify the implementation of a function, and the remote repository version is not the same as yours, and when the major version and your changes are merged, the code changes to who it is, so it conflicts. Typically occurs during Git pull and git merge.

The workaround for this conflict is to modify the conflicting files directly, and the conflicting files will be identified at the command line with the following flags in the conflicting file:

<<<<<<< HEAD
This is between you and the change.
=======
This is someone else's change.
>>>>>>> 6853E5FF961E684D3A6C02D4D06183B5FF330DCC

Then delete other people's changes or delete their own changes, delete the identifier, when all the conflicts are processed, execute git add and git commit.

In the process of git rebase, there may be a conflict : In this case, Git will stop rebase and will let you resolve the conflict, after resolving the conflict, with the git add command to update the index of these content, then you do not have to commit, Just execute:

$ git rebase--continue so git will continue to apply the rest of the patch, and here's the patch that's the case:

means to cancel each commit in your local current branch and temporarily save them as patches (patches), which are placed in the ". Git/rebase" directory, and then update the local current branch to the newest "origin" branch. Finally, apply the saved patches to the local current branch

$ git rebase--abort at any time, you can use the--abort parameter to terminate the action of Rebase, and the current branch will return to the state before the start of the rebase.

If you want to learn more about Git, recommend Liaoche's git tutorial