Getting Started with git, using principles and how to manage projects on Gitlab, GitHub, or stash (i)

First of all, I have been so busy these days that I have been doing projects from morning to night so that I haven't updated my blog for months. In fact, there are a lot of things worth sharing, but because of the time problem stranded, and now also forget what has, it is a pity ...

This article is written mainly out of a personal view of the more common phenomenon, is that many developers are using GIT to manage the project, but most people are only "fool" in the use, and often do not know what they are doing, what happened to their own projects.

As far as the project team of our company is concerned, the first two days the team leader has been talking to me, let me have time to follow up the codereview, organize everyone to make up this aspect. Today finally free to do a bit, only to find that the original people in the use of Git is basically a small white level, let alone in Gitlab and other servers to manage the project.

So I intend to use this article to help you understand git, so that everyone as far as possible to understand what their operations are doing, encountered problems in the end because of what, should be how to respond and so on. (By the way, individuals are less inclined to use tortoisegit-like interface software, which is more convenient and straightforward with Git bash)

Okay, that's the end of the crap, let's get down to the chase.

git add/git commit/git pull/git push/git Status These commands should be the most used, I will not say the specific. Here are some explanations for the branch branch and remote server remotes, so that we can understand the structure of GIT in project management, and then understand what we are doing and how to solve the problem.

If we use Git bash to enter a directory (for example: d:/test/) and execute the GIT init command in this directory, we will create a repository (repository) in this directory, which is our Git managed repository, if you do anything in this directory , can be managed through git.  For example, if you create a new file TestFile.txt, you can add this file to Git's staging area via the git add TestFile.txt command, and then git commit-m "Add a file TestFile.txt" command will be able to completely incorporate this file into Git management.

So what is branch (branch)? In fact, we can understand the "parallel world" in a sci-fi film. When a repository is established, git defaults to creating a master branch for us, which is the default for operations on a branch called Master. Of course, we can create a branch called Testbranch with the git branch testbranch command, which is created based on your current branch, that is, if you are currently in the Master branch, if you have established a Testbranch branch , then the contents of the Testbranch branch will be the same as what you commit in the Master branch, and there will also be a TestFile.txt file that I have just entered in Testbranch. We can switch back and forth through the git checkout master and git checkout testbranch commands on two branches, and on which branch your file directory will become the content of the branch. (Git checkout-b testbranch2 command is equivalent to git branch testbranch2 + git checkout testbranch2 two commands, which I will not repeat after these fancy commands, When the reader becomes familiar with git, it will naturally come into contact with more commands like this.

The concept of branching above must be understood, as this is the basis for understanding git pull and git push. As you can see, there's no git pull and git push involved in the previous tutorial, because we've been working on a warehouse repository and we're managing our own projects. When it comes to multi-person management, that is, when we want to manage someone else's project or the company's project, it involves someone else's repository. Here, it is hoped that readers will treat the company's repository (Gitlab, or stash, etc.) as the repository on their computer, without too much special.

So now it involves the coordination of two repository. In order to avoid directly explaining too complex content, below I have a relatively simple scenario to explain, complex readers familiar with the next. The scenario is as follows: There is a warehouse repository on the remote (company) server, which contains a master branch, a Testa branch, and a TESTB branch. When we develop the project, we clone the project directly to Local on our own computer, then we also have a same repository on our computer, including a master branch, a Testa branch, a TESTB branch. Now everyone should be clear: you can now understand that there are already 6 branches, remote has three, you have three local. To make it easier to distinguish, I'll add a (L) to the back of the local branch. So when we use the git checkout Master command, we actually switch to the master (L) branch locally, and remember, we're not going to be able to switch to the branch on the remote. Oh, that's not your repository~. Many people just don't differentiate, Cause you don't know what you're doing, just get confused about having a simple git pull and git push concept.

The following is the turn of git pull and git push. If we switch to the Testa (l) branch after git checkout testa, if we make some changes, git add and git commit, it means that the changes are committed to the Testa (l) Branch, and the remote Testa branch is the same as the original, if you want to let the remote Testa branch also become your change after the appearance, it will use the git push command. Of course there is no accident here, because it is probably in git version after 1.9.2, git default push mode changed to Simple mode, personal comparison suggested this way (that is, where pull from, I push back where). You can view your current push mode by command git config push.default, and you can set your global push mode to simple by using the git config--gloable push.default simple command. Other ways readers can search for themselves here and don't repeat them. So to summarize, in general, if you checkout to the Testa (l) branch to execute the git pull command, the contents of the Testa branch in the remote repository are updated to your local testa (l) branch, and the Push command is the same.

Well, it's too late, let's talk about it today. After the article reminds oneself, explains the remote aspect content as well as the merge related content, these contents are in the project very important movement and the concept, hoped that everybody must understand. Finally, there may be some codereview related content and some of the more fragmented but critical issues that often occur during GIT usage. I believe that if you follow the order of the previous articles, and finally see those problems themselves can analyze the causes and solutions.

Getting Started with git, using principles and how to manage projects on Gitlab, GitHub, or stash (i)