This is the 15th day of my participation in the August More Text Challenge

preface

I remember that when I started to do project development, I always finished a project by myself, and I didn’t know what team development was. There was no such concept. With my work, I came to know that all projects in the company were team development, and how could so many people develop a project at this time? Later, I knew there was a project version management tool SVN was popular in the early stage, and then I started to use Git so that the team could easily manage the project based on Git version

Quick learning

Initialize the local repository

Git –version check whether the git version is installed successfully

  1. Initialize the project Git repository

Find the project root path and initialize the local repository with git init

  1. Add project code to the repository

Add dots to represent all files with git add. After adding the local repository successfully, the Java file turns green

  1. Submit the file to the local repository for approvalgit commit -m "First commit"The following m indicates the submitted comment information

Associated remote warehouse

Here we use GitHub as the project remote repository example to the remote repository page and copy the repository address

HTTS is more convenient for direct connection. SSH requires the correct configuration of key and TOKE, but it is more secure than HTTP. I use HTTPS for convenience, and GENERALLY USE SSH in company projects

  1. Associate the remote warehouse address with the local warehouse
Git remote add origin {git remote add originnew remote

Copy the code
  1. Push to the remote repository

Git push -u origin master is used to synchronize the local project code push to the remote repository. Master represents the remote master branch.

Ignore files

There is some code in the project that does not need to be submitted for each update, such as class byte files (targer files), files generated by development tools, JAR files, properties files, etc., At this point we can write.gitignore to add unwanted submitted file directories to the.gitignore file

  1. Ignore the rules

Manage Git commit behavior of files in the current folder by defining.gitignore files under the project and defining corresponding ignore rules in this file

In the.gitingore file, specify an ignore rule on each line, following the appropriate syntax. Such as:

*.log
*.temp
/vendor
Copy the code
  1. Grammar rules

The gitignore annotation uses the ‘#’, * to indicate matching zero or more arbitrary characters, so the pattern above is to ignore all XML files,log files, and APK files.

The. Gitignore configuration file is used to configure files that do not need to be added to version management. Configuring this file facilitates version management

*. A means to ignore all files ending in. A! /TODO means to ignore only TODO files in the root directory of the project, excluding subdir/TODO build/ means to ignore all files in the build/ directory and filter the entire build folder. TXT indicates that doc/notes. TXT is ignored but not doc/server/arch. TXT bin/: indicates that the bin folder in the current path is ignored. All contents in the bin folder are ignored. C: indicates that cat.c is ignored. Build /cat.c debug/*.obj: Obj and tools/debug/ IO. Obj **/foo: Ignores /foo,a/foo,a/b/foo, etc. A /**/b: A /b,a/x/ b,a/x/y/b, etc. /bin/run.sh indicates that the run.sh file *. Log in the bin directory is not ignored. *. Zip: filter all. Zip files. / MTK /do.c: filter specific files. Of course, there is a local library, but push does not upload. Note that Gitignore can also specify which files to add to version management, as follows: *.zip ! The only difference with/MTK /one.txt is that there is an exclamation mark at the beginning of the rule. Git adds files that meet these rules to version management. Why should there be two rules? Imagine a scenario where we only need to manage the one.txt file in the/MTK/directory, and no other files in the directory need to be managed. The.gitignore rule should be written as: : / MTK /*! / MTK /one.txt Assuming we only have filter rules and no rules, then we need to write all files in/MTK/except one.txt! Note that/MTK /* cannot be written as/MTK /, otherwise the parent directory is excluded by the previous rule, one.txt file although added! Filter rules, also not in effect! -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- and some rules are as follows: fd1 / * note: ignore all directories under the fd1 content; Note that either the /fd1/ directory in the root directory or a subdirectory /child/fd1/ is ignored; /fd1/* Note: Ignore all contents of the /fd1/ directory under the root directory. / *! .gitignore ! /fw/ /fw/* ! /fw/bin/ ! /fw/sf/ Description: Ignore all contents except the. Gitignore file and the /fw/bin/ and /fw/sf/ directories in the root directory. Use the bin/ parent directory first! Rules so that they are not excluded.Copy the code

Note that the gitignore file is configured but does not take effect

There are two possibilities:

  1. There is a problem with the.gitignore file configuration. For example, I encountered this problem once: I used the plugin “Add to gitignore” in Idea on Windows to Add a folder that needs to be ignored. It writes:.idea\ to my.gitignore file, which should actually be: /.idea/

  2. Before you add a new ignore rule, you have already committed the file corresponding to the rule. In this case, you need to delete the local cache (change it to untrack state) using the command:

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

Copy the code

Git git

Remote warehouse related commands

  1. Check out the warehouse: git clone git://github.com/jquery/jquery.git

  2. Git remote -v

  3. Git remote add [name] [url]

  4. Git remote rm [name]

  5. Git remote set-url –push [name] [newUrl]

  6. Git pull [remoteName] localBranchName

  7. Git push [remoteName] localBranchName

If you want to commit a local branch, test, to the remote repository as the master branch of the remote repository, or as another branch named test, as follows:

Git push origin test: $git push origin test: $git push origin test: $git push origin test: $git push origin testCopy the code

Branch Operations related commands

  1. Check out the local branch: Git Branch

  2. Check the remote branch: git branch -r

  3. Create a local branch: git branch [name] —- Notice After a new branch is created, it does not automatically switch to the current branch

  4. Git checkout [name]

  5. Git checkout -b [name]

  6. Git branch -d [name] —- -d deletes branches that have been merged. If you want to forcibly delete a branch, you can use the -d option

  7. Git merge [name] —- Merge a branch named [name] with the current branch

  8. Git origin [name]

  9. $git push origin :[name] $git push origin :[name]

Version (tag) Commands related to the operation

  1. Check the version: git tag

  2. Git tag [name]

  3. Git tag -d [name]

  4. To check the remote version, run git tag -r

  5. Git origin [name]

  6. Git push origin :refs/tags/[name]

  7. Merge remote repository tags locally: git pull origin –tags

  8. Upload local tags to remote repositories: Git push Origin –tags

  9. Git tag -a [name] -m ‘yourMessage’

Git branch

Here the basic use of Git refer to Mr. Liao Xuefeng’s basic use of Git tutorial

The main branch

In real development, a repository (usually a single project) has two main branches: the Master and Develop branches. The life cycle of these two branches is the entire project life cycle. That is, it is not deleted from the creation, and it is constantly added to the project as it develops. The Master branch is automatically generated when the Git repository is created, and the Develop branch is created from the Master branch, as shown below.

  1. Master: This branch is the most stable. This branch represents the project in a releasable state.

For example, merging code into the Master branch means that the master branch has completed a release version of the project, and the project manager can assume that the project is ready for a new release. So the Master branch is not a random place to check in code, and only merges into the Master branch if the planned release features are completed on the Develop branch and the tests are clean.

  1. Develop: as a branch of development, parallel to the master branch.

For example, if Wang erdog wants to develop a feature, he will create a feature branch fb-Register from the Develop branch. After the fb-register branch is registered, the code will be merged into the Develop branch. The Fb-Register has done its job and can be deleted. The project manager saw wang ergou’s efficiency was very high, so: “Two dogs you also did the login function.” Create a new branch called Fb-login from Develop, have a cup of coffee, and an hour later, when the login function is ready, merge that branch’s code back into Develop and delete it

Support the branch

These branches exist for programmers to collaborate and respond to the various needs of the project. These branches are created to solve a specific problem, and when that problem is solved, the code is merged back into the main branch, develop or Master, and removed

  1. Feature branches: This branch is most closely related to our programmers’ daily development, and is called a functional branch

Must be created from the Develop branch and merged back into the Develop branch

  1. Hotfix Branches: This branch was used to fix particularly urgent bugs on the line

  2. Release Branches: This branch is used to distribute new versions.

reference

  1. Git git
  2. Gitignore Configuration rule
  3. Gitignore doesn’t take effect