Git Step by step– (7) Git remote repository (cont.)

The previous article described some of the uses of Git remote repositories, but there are some things that need to be added, so there's this sequel.

. gitignore

In the previous article, we introduced the Git patch feature, and when we generated the patch, "Git status" would show that the patch file was "untracked files". Of course, there is no need for us to track this patch file.

Similarly, projects may often generate files that are not tracked by Git systems, files generated during build-up, or temporary backup files generated by the programmer. We can use "git add" to avoid adding these files to staging area, but it will be troublesome to do this every time.

Therefore, in order to meet the above requirements, the GIT system has a feature that ignores certain files. We can add a file called ". Gitignore" to the working directory to tell the GIT system which files to ignore.

You can see that when we use the ". Gitignore" file, the filtering rules in the file take effect.

Attention:

1. The file name ". Gitignore" is not supported in a Windows environment, so you can name the file ". Gitignore."
2. The ". Gitignore" file only takes effect for subdirectories of the current directory and all current directories, i.e. if we move the ". Gitignore" file to the "advance" folder, then the filter rule will take effect on "advance" and its subdirectories.
3. It is recommended that the ". Gitignore" file be submitted to the repository so that other developers can share the filtering rules

Filter syntax

Here's a look at common filtering syntax:

• "/" At the beginning of the slash indicates the directory
• Asterisk "*" wildcard with multiple characters
• Question mark "?" Pass a single character
• Square brackets "[]" contains a list of matches for a single character
• Exclamation mark "!" Indicates that the matching file or directory is not ignored

Here are some simple examples:

• foo/*: Ignore all content under directory foo
• *. [OA]: Ignore All. O and. A Files
• !CALC.O: Cannot ignore CALC.O file

Exclude file

There is a ". Git/info/exclude" file in the Git repository, and when we point to using a specific filter rule for a particular warehouse, we can write the filter statement in the exclude file.

Look at the Remote Warehouse command

The previous article simply introduces the use of push and pull commands, which will be described further here.

First, let's look at "Git branch" and "Git Remote" commands, which can provide us with a lot of useful information.

1. Git branch

2. Git remote

git push

The remote repository that the push command uses to push updates for the local branch, the format of the command is as follows:

GIT push < remote host name > < local branch name >:< Remote Branch name >

1. Updating with "Git push", creating a remote branch

2. To remove a remote branch from "Git Push"

3. "Git push origin" that omits branching information

   When push is done this way, a warning is given indicating that "Push.default" is not set.

   There are two kinds of settings for push in Git:

• Simple mode: Just push the update of the current branch to the corresponding remote branch, which is used by default after Git 2.0
• Matching mode: Pushes all local branches with corresponding remote branches

Based on Git's hints, we can set the push mode via "git config--global push.default".

Git pull

The pull command is the function of retrieving updates from a remote branch and merging them into the specified local branch, with the Pull command formatted as follows:

Git pull < remote host name > < remote branch name >:< local branch name >

1. Git pull Origin release-1.0:release1.0

   Retrieve the update of the Origin host release-1.0 branch and merge with the local release-1.0 branch.

   In general, pull commands are performed between the associated local and remote branches, and of course, you can use the unrelated local and remote branches for pull operations, but this is not recommended.

   If you really need updates on other remote branches, it is recommended that you use "Cherry-pick" to take this update to the associated remote branch and then pull on the associated branch.

2. Omit local branch Name: Git pull Origin release-1.0

   Represents the retrieval of updates from the Origin/next remote branch and then merges into the current branch

3. If the current branch has an upstream (association) branch, you can use GIT pull origin directly

   Indicates that the local current branch is automatically merged with the associated Origin host branch

The "Git Pull" operation is actually equivalent to performing a "git fetch" to get the remote update, and then the "Git merge" is merged with the local branch.

Of course, the pull command also supports merging using the REBASE mode:

Git pull--rebase < remote host name > < remote branch name >:< local branch name >

In this case, "git pull" is equivalent to "git fetch" plus "Git rebase".

It is recommended to use "Git fetch" plus "git rebase" instead of "git pull" to get remote updates, which is explained later.

git fetch

The fetch command is simple enough to retrieve the remote update locally.

1. Git fetch origin

   This command indicates that updates on all branches of the remote origin host are retrieved locally

2. Git fetch Origin Master

   This command only retrieves updates on the master branch on the remote Origin host

Summarize

Through these introductions, I believe you will be more familiar with the remote warehouse operation commands, making the work in the GIT environment more smoothly.

Git Step by step– (7) Git remote repository (cont.)