Ios-git Branch (Distributed version control system)

Objective

• Almost all version control systems support branching in some way. Using branching means that you can separate your work from the development line to avoid affecting the development line. In many version control systems, this is a slightly inefficient process-often requiring a full copy of the source code directory to be created. For large projects, this process can take a lot of time.

• Some people refer to Git's branching model as its "must-kill" feature, which makes Git stand out from many version control systems. Why is the branching model of Git so outstanding? The way Git handles branching is incredibly lightweight, creating new branches is almost instantaneous, and switching between different branches is as easy as it can be. Unlike many other version control systems, Git encourages frequent use of branching and merging in the workflow, even if it is done many times a day. By understanding and mastering this feature, you realize that Git is so powerful and unique that it really changes the way you develop.

1, Branch Introduction

• Git does not save file changes or differences, but rather a series of snapshots of files at different times. Git saves a Commit object when the commit operation is committed.

• Knowing how Git holds the data, it's natural to think that the commit object will contain a pointer to the staging content snapshot. But more than that, the commit object also contains the author's name and mailbox, the information entered at the time of submission, and a pointer to its parent object. The Commit object produced by the first commit does not have a parent object, and the commit object produced by the normal commit operation has a parent object, and the commit object resulting from multiple branch merges has more than one parent object.

• To illustrate this more graphically, we assume that there is now a working directory containing three files that will be staged and submitted. The staging operation calculates the checksum (SHA-1 hash algorithm) for each file, and then saves the current version of the file snapshot to the Git repository (Git uses BLOB objects to hold them), and eventually officer and joins the staging area for submission.

  $ git add README test.rb LICENSE$ git commit -m "The initial commit of my project"

• When the git commit commit operation is used, Git calculates the checksum for each subdirectory and then saves the checksum as a tree object in the Git repository. Git then creates a commit object that contains pointers to the tree object (the project root), in addition to the information mentioned above. As a result, Git can reproduce this saved snapshot when needed.

• Now there are five objects in the Git repository: three BLOB objects (holding a snapshot of the file), a tree object (which records the directory structure and the Blob Object index), and a Commit object (containing pointers to the preceding tree object and all commit information).

• Make some changes and commit again, the resulting commit object will contain a pointer to the last committed object (the parent object).

• The branch of Git, in essence, is simply a mutable pointer to the Commit object. The default branch name for Git is master. After multiple commits, you already have a master branch that points to the last commit object. It will automatically move forward in each commit operation.

  • The master branch of Git is not a special branch. It is no different from the other branches at all. Almost every warehouse has a master branch because the git init command creates it by default, and most people are too lazy to change it.

2. Branch creation

• Git is simple to create a new branch, it just creates a new pointer for you to move. For example, to create a testing branch, you need to use the GIT branch command.

  # git branch [分支名]$ git branch testing

  • This creates a pointer on the currently committed object.

• Git has a special pointer called HEAD. Please note that it is completely different from the HEAD concept in many other version control systems such as Subversion or CVS. In Git, it is a pointer to the local branch that is currently in place (think of the HEAD as the alias of the current branch). In this case, you are still on the master branch. Because the git branch command simply creates a new branch, it does not automatically switch to the new branch.

• You can simply use git log commands to view the objects currently referred to by each branch. The parameters that provide this function are --decorate .

  $ git log --oneline --decoratef30ab (HEAD, master, testing) add feature #32 - ability to add new34ac2 fixed bug #1328 - stack overflow under certain conditions98ca9 initial commit of my project

  • As you can see, both the current "master" and "testing" branches point to the Commit object starting with F30ab and beginning with the checksum.

3. Branch switching

• To switch to a branch that already exists, you need to use the git checkout command. We now switch to the newly created testing branch.

  # git checkout [分支名]$ git checkout testing

  • So HEAD points to the testing branch.

• So how does this approach benefit us? It may now be submitted again.

  $ vim test.rb$ git commit -a -m 'made a change'

  • , your testing branch moves forward, but the master branch does not, and it still points to git checkout the object that the runtime refers to. This is interesting, now let's switch back to the master branch to see.

    $ git checkout master

  • This order has done two things. One is to point HEAD back to the master branch, and the second is to restore the working directory to the snapshot content pointed to by the Master branch. In other words, if you make changes now, the project will start with an older version. Essentially, this is to ignore the changes made by the testing branch so that it can be developed in another direction.

  • We may as well make some changes and submit them a little bit more.

    $ vim test.rb$ git commit -a -m 'made other changes'

  • Now, the submission history of this project has been forked. Because you just created a new branch and switched over to some work, and then switched back to the master branch for some other work. The two changes are for different branches: You can constantly switch and work between different branches and merge them when the time is ripe. And all of this work, the commands you need are only branch, checkout, and commit.

  • You can simply use the git log commands to view the history of the fork. Run git log --oneline --decorate --graph --all , it will output your commit history, the points of each branch, and the branching bifurcation of the project.

    $ git log --oneline --decorate --graph --all* c2b9e (HEAD, master) made other changes| * 87ab2 (testing) made a change|/    * f30ab add feature #32 - ability to add new formats to the* 34ac2 fixed bug #1328 - stack overflow under certain conditions* 98ca9 initial commit of my project

• Since the branch of Git is essentially a file containing the checksum of the object (the SHA-1 value string of length 40), its creation and destruction are exceptionally efficient. Creating a new branch is equivalent to writing 41 bytes (40 characters and a newline character) to a file, so how easy can it be? This is in stark contrast to most version control systems in the past, where all project files are copied once and saved to a specific directory when the branch is created. This tedious process usually takes several seconds, sometimes even several minutes. The length of time required depends entirely on the size of the project. In Git, projects of any size can create new branches in an instant. At the same time, because each commit records the parent object, it is equally simple and efficient to find the right merge basis (the common ancestor). These high-performance features allow Git to encourage developers to create and use branches frequently.

4. Branch merging

• Let's say you've fixed #53 problem, and you're going to merge your work into the Master branch. To do this, you need to merge the Iss53 branch to the master branch. You only need to check out the branch you want to merge into, and then run the git merge command.

  $ git checkout masterSwitched to branch 'master'

  # git merge [要合并到当前分支的分支名]$ git merge iss53

  Merge made by the 'recursive' strategy.index.html |    1 +1 file changed, 1 insertion(+)

  • In this case, your development history begins to diverge from an earlier point (diverged) because the master branch is committed not as a direct ancestor of the commit of the Iss53 branch, and Git has to do some extra work. When this happens, Git uses snapshots (C4 and C5) at the end of the two branches and the working ancestors of the two branches (C2) to make a simple tripartite merge.

  • Git makes a new snapshot of the results of the three-party merge and automatically creates a new commit to point to it. This is called a merge commit, and what's special about it is that he has more than one parent to submit.

  • It should be noted that Git decides which commits to choose as the best common ancestor, which is the basis of the merger, unlike the older CVS system or Subversion (prior to version 1.5), in which the user needs to choose the best consolidation basis for themselves. This advantage of Git makes it much easier to combine operations than other systems.

• Sometimes merging doesn't work so well. If you make different changes to the same part of the same file in two different branches, Git will not be able to merge them cleanly. If your changes to #53 issues and changes to hotfix involve the same file, merge conflicts will occur when merging them.

  $ git merge iss53Auto-merging index.htmlCONFLICT (content): Merge conflict in index.htmlAutomatic merge failed; fix conflicts and then commit the result.

  • At this point Git merges, but does not automatically create a new merge submission. Git pauses and waits for you to resolve the conflicts that are generated by the merge. You can use commands at any time after a merge conflict git status to view files that are in an unincorporated (unmerged) state because of a merge conflict.

    $ git statusOn branch masterYou have unmerged paths.  (fix conflicts and run "git commit")Unmerged paths:  (use "git add <file>..." to mark resolution)    both modified:      index.htmlno changes added to commit (use "git add" and/or "git commit -a")

  • Any files that have to be resolved because of a merge conflict are identified in the non-consolidated state. Git adds standard conflict resolution tags to conflicting files, so you can open the files that contain the conflicts and then manually resolve the conflicts. Conflicting files will contain special sections that look like this.

    <<<<<<< HEAD:index.html<div id="footer">contact : [email protected]</div>=======<div id="footer"> please contact us at [email protected]</div>>>>>>>> iss53:index.html

  • This represents the version indicated by HEAD (that is, where your master branch is located, because you have checked out this branch when you run the merge command) in the upper half of the section (the upper part of the =======), and the ISS53 branch indicates the version in the lower half of ======= Part. To resolve the conflict, you have to choose to use one of two parts that are split by =======, or you can merge the content yourself. For example, you can resolve the conflict by replacing the content with the following.

    <div id="footer">please contact us at [email protected]</div>      

  • The above conflict resolution only retains the modifications of one of the branches, and <<<<<<<, =======, and >>>>>>> are completely deleted. After you have resolved all the conflicts in the file, use the git add command for each file to mark it as a conflict resolved. Once these conflicting files are staged, Git will mark them as conflicts resolved.

  • If you are satisfied with the result and you are sure that the previously conflicting files have been staged, you can enter git commit them to complete the merge submission. By default, the commit information looks like this.

    Merge branch 'iss53'Conflicts:index.html## It looks like you may be committing a merge.# If this is not correct, please remove the file#   .git/MERGE_HEAD# and try again.# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.# On branch master# All conflicts fixed but you are still merging.## Changes to be committed:#   modified:   index.html#

5. Branch Management

• 1) Delete Branch

  # git branch -d [分支名]$ git branch -d iss53

• 2) View the list of branches

  • 1> If you run it without any parameters, you get a list of all the branches that are currently running.

    $ git branch

      iss53* master  testing       

  • Note the * Character of Master Zhiqian: it represents the branch that is now checked out (that is, the branch that the current HEAD pointer points to). This means that if committed at this time, the master branch will move forward with the new work.

  • 2> If you need to see the last commit for each branch, you can run the git branch-v command.

      $ git branch-v  

      iss53 93b412c fix javascript issue* master 7a98805 Merge Branch ' iss53 ' testing 782fd34 add Scott to the author list in the Readmes  

  • 3> --merged with --no-merged These two useful options you can filter the branches in this list that have been merged or have not been merged into the current branch.

    • If you want to see which branches have been merged into the current branch, you can run them git branch --merged .

      $ git branch --merged

        iss53* master

    • Because the ISS53 branch has been merged before, you now see it in the list. Branches that do not have an * number before the name of the branch in this list can usually be git branch -d deleted; You have integrated their work into another branch, so you don't lose anything.

    • View all branches that contain non-consolidated work and can be run git branch --no-merged .

      $ git branch --no-merged

        testing

      • Other branches are shown here. Because it contains work that has not yet been merged, attempting to delete it by using a git branch -d command fails.

        $ git branch -d testingerror: The branch 'testing' is not fully merged.If you are sure you want to delete it, run 'git branch -D testing'.

    • If you really want to delete a branch and lose that work, you can force it to be removed using the-D option.

6. Branch Development Workflow

• 1) long-term branch

  • Because Git uses a simple tripartite merge, it's not difficult to merge a branch into another branch over a longer period of time. In other words, you can have multiple open branches at the same time throughout the project development cycle, and you can periodically merge certain feature branches into other branches.

  • Many developers who use Git like to work in this way, such as keeping completely stable code on the master branch--possibly just code that has been published or is about to be released. They also have parallel branches called develop or next, which are used for subsequent development or test stability-these branches do not have to be absolutely stable, but once they are stable, they can be merged into the master branch. This allows you to merge into the trunk branch and wait for the next release after making sure that these completed feature branches (short-term branches, such as the previous ISS53 branch) pass through all tests and do not introduce more bugs.

  • In fact, we were just talking about pointers that move right along with your commits. The pointer to the stable branch is always behind a large section in the commit history, while the pointers to the frontier branches tend to be more forward-leaning.

  • Usually think of them as pipelining (work silos) might be better understood, and those test-tested submissions would be selected for a more stable pipeline.

  • You can maintain different levels of stability in this way. Some large projects also have a proposed (recommended) or pu:proposed updates (Recommended update) branch, which may not be able to enter the next or master branch because it contains some immature content. The goal is to have different levels of stability for your branches, and when they have some degree of stability, merge them into branches with higher levels of stability. Again, it is not necessary to use multiple long-term branches, but it is often helpful to do so, especially if you are working in a very large or complex project.

• 2) attribute branches

  • Attribute branches apply to projects of any size. An attribute branch is a short-term branch that is used to implement a single feature or its associated work. You may have never done this on another version control system (VCS), because it is often laborious to create and merge branches in those version control systems. However, it is common to create, use, merge, and delete branches multiple times in a day in Git.

  • You have seen this usage in the iss53 and hotfix attribute branches that you created in the previous section. You have submitted some updates in the feature branches (ISS53 and hotfix branches) that were added to the previous section, and after they were merged into the trunk branch, you deleted them. This technology enables you to quickly and completely context-switch (context-switch) because your work is dispersed across pipelines, and each branch in a different pipeline is only relevant to its target characteristics, so It's easier to see what changes you've made when doing work like code reviews. You can keep the changes you make in a feature branch for a few minutes, days, or even months, and then merge them when they mature, without caring about the order in which they were built or the progress of their work.

  • Consider an example where you work to C1 on the master branch, create a new iss91 branch to solve a problem, work to C4 on the Iss91 branch, but you have a new idea about the problem, and then you create a iss91v2 The branch tries to solve the problem in a different way, then you go back to the master branch for a while, and you have a less sure idea, and you create a Dumbidea branch in the C10 and experiment on it. Your submission history looks like the following.

  • Now, let's say two things: we finally decided to use the second solution, the one in Iss91v2, and we showed the Dumbidea branch to our colleagues and found it to be a genius. So next, we're going to discard the original ISS91 branch (which would actually discard C5 and C6) and merge the other two branches directly into the trunk. The final commit history will turn into figure 3-21.

  • It is important to keep in mind that these branches are all local branches. When you use branching and merging, everything is done in your own Git repository, and it doesn't involve interacting with the server at all.

7. Remote BRANCH

• 1) Remote Branch

  • A remote reference is a reference (pointer) to a remote repository, including branches, tags, and so on. You can git ls-remote (remote) explicitly obtain a complete list of remote references, or by git remote show (remote) obtaining more information about remote branches. However, a more common practice is to take advantage of remote trace branches.

  • The remote Trace branch is a reference to the remote branch state. They are local references that you can't move, and they move automatically when you do any network traffic.

  • They are named in (remote)/(branch) Form. For example, if you want to see the state of the master branch the last time you communicate with the remote repository origin, you can view the Origin/master branch. You work with coworkers to solve a problem and they push a iss53 branch, you may have your own local ISS53 branch, but the branch on the server points to the commit of origin/iss53.

  • This may be a bit difficult to understand, let's take a look at an example. Suppose you have a git server in git.ourcompany.com on your network. If you clone from here, the Git clone command automatically names it as Origin, pulls all its data, creates a pointer to its master branch, and names it locally as origin/master. Git will also give you a local master branch that points to the same place as the master branch of origin, so you have the basis for the job.

  • Remote Repository The name "origin", like the branch name "master", does not have any special meaning in Git. At the same time "master" is the git init default starting branch name when you run it, because it is only widely used, "origin" is the git clone default remote repository name when you run it. If you run git clone -o booyah , then your default remote branch name will be booyah/master.

  • A Git clone will build your own local branch master and Remote Branch origin/master, and point them all to the Master branch on origin.

  • If you do some work at the local Master branch, but at the same time others push the commit to git.ourcompany.com and update its master branch, then your commit history will move in a different direction. Perhaps, as long as you are not connected to the origin server, your origin/master pointer will not move.

  • If you want to synchronize your work, run the git fetch origin command. This command finds which server "origin" is (in this case, git.ourcompany.com), fetches data that is not locally, and updates the local database, moving the Origin/master pointer to the new, updated location.

  • To demonstrate that there are multiple remote warehouses and remote branches, we assume that you have another internal Git server that is used only for the development work of your sprint team. This server is located in git.team1.ourcompany.com. You can run the git remote add command to add a new remote repository reference to the current project, which we'll explain in detail in Git basics. Name this remote repository as Teamone, as an abbreviation for the entire URL.

  • You can now run git fetch teamone to crawl data that is not available locally teamone the remote repository. Because the existing data on that server is a subset of the origin server, Git does not crawl the data but sets the remote trace branch teamone/master to the master branch of Teamone.

• 2) Push Branch

  • When you want to share a branch publicly, you need to push it to a remote repository with write permissions. The local branch does not automatically synchronize with the remote repository, and you must explicitly push the branch that you want to share. This way, you can put content that you don't want to share on your private branch, and push content that needs to collaborate with others to a public branch.

  • If you want to work with someone on a branch called Serverfix, you can push it like the first branch. Run git push [remote] [branch] .

    # git push [remote] [branch]$ git push origin serverfix

    Counting objects: 24, done.Delta compression using up to 8 threads.Compressing objects: 100% (15/15), done.Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.Total 24 (delta 2), reused 0 (delta 0)To https://github.com/schacon/simplegit * [new branch]      serverfix -> serverfix

  • Some of the work here has been simplified. Git automatically expands the Serverfix branch name to Refs/heads/serverfix:refs/heads/serverfix, which means "push the local Serverfix branch to update the Serverfix branch on the remote repository." ”

  • You can also run the following command, and it will do the same thing, as it says, "Push the local Serverfix branch as a serverfix branch of the remote repository" in this format to push the local branch to a remote branch with a different name.

    # git push [remote] [branch]:[remote-branch]$ git push origin serverfix:serverfix

  • If you do not want the branch on the remote repository to be called Serverfix, you can run git push origin serverfix:awesomebranch to push the local Serverfix branch to the Awesomebranch branch on the remote repository.

  • The next time other collaborators fetch data from the server, they will generate a remote branch origin/serverfix locally, pointing to a reference to the server's Serverfix branch.

    $ git fetch originremote: Counting objects: 7, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From https://github.com/schacon/simplegit * [new branch]      serverfix    -> origin/serverfix

  • It is important to note that when crawling to a new remote tracing branch, an editable copy (copy) is not automatically generated on-premises. In other words, in this case, there will not be a new Serverfix branch, only one cannot modify the Origin/serverfix pointer. You can run to git merge origin/serverfix merge the work into the current branch. If you want to work on your own Serverfix branch, you can build it on a remote tracing branch.

    # git checkout -b [branch] [remotename]/[branch]$ git checkout -b serverfix origin/serverfix

    Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

  • This will give you a local branch for your work, and the starting point is in Origin/serverfix.

• 3) Tracking Branch

  • Checking out a local branch from a remote trace branch automatically creates a "Trace branch" (sometimes called an "upstream branch"). The trace branch is a local branch that has a direct relationship to the remote branch. If you enter on a trace branch git pull , Git can automatically identify which server to crawl, merge to which branch.

  • When you clone a warehouse, it usually automatically creates a master branch that tracks origin/master. However, if you prefer, you can set up other trace branches on other remote repositories, or do not track the master branch. The simplest is the example that was seen before, run git checkout -b [branch] [remotename]/[branch] . This is a very common operation, so Git provides --track shortcuts.

    # git checkout --track [remotename]/[branch]$ git checkout --track origin/serverfix

    Branch serverfix set up to track remote branch serverfix from origin.Switched to a new branch 'serverfix'

  • If you want to set the local branch to a different name from the remote branch, you can easily add a command to a local branch of a different name.

    # git checkout -b sf [remotename]/[branch]$ git checkout -b sf origin/serverfix

    Branch sf set up to track remote branch serverfix from origin.Switched to a new branch 'sf'

  • The local branch SF is now automatically pulled from Origin/serverfix.

  • Set up an existing local branch to track a remote branch that you just pulled down, or you want to modify the upstream branch that you are tracking, you can set it explicitly at any time -u or by --set-upstream-to running the option git branch .

    $ git branch -u origin/serverfixBranch serverfix set up to track remote branch serverfix from origin.

  • You can use the options if you want to see all of the tracking branches that you set up git branch -vv . This lists all the local branches and contains more information, such as whether each branch is tracking which remote branch and local branch are leading, backward, or both.

    $ git branch -vv  iss53     7e424c3 [origin/iss53: ahead 2] forgot the brackets  master    1ae2a45 [origin/master] deploying index fix* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it  testing   5ea463a trying something new

  • Here you can see that the ISS53 branch is tracking origin/iss53 and "ahead" is 2, which means two commits have not been pushed to the server locally. You can also see that the master branch is tracking the Origin/master branch and is up to date. Next you can see that the Serverfix branch is tracking the Server-fix-good branch on the Teamone server and is 3 behind 1, meaning that one commit on the server has not been merged into the same time that the local three commits have not yet been pushed. Finally, you see that the testing branch does not track any remote branches.

  • One important point to note is that the values for these numbers come from the last data you crawled from each server. This command does not connect to the server, it will only tell you about the local cache server data. If you want to count the latest leading and trailing numbers, you need to crawl all the remote warehouses before running this command. Can do like this: $ git fetch --all ; git branch -vv .

• 4) Pull Branch

  • When a git fetch command fetches locally-not-available data from the server, it does not modify the contents of the working directory. It will only fetch the data and let you merge it yourself. However, there is a command called git pull in most cases it means a git fetch git merge command immediately thereafter. If you have a set of trace branches, as demonstrated in the previous chapters, whether it is explicitly set or clone checkout created for you through or commands, git pull finds the servers and branches that the current branch is tracking, fetches the data from the server, and then attempts to merge into that remote branch.

  • Because git pull the magic is often confusing, it fetch is usually better to use the merge command explicitly alone.

• 5) Delete Remote Branch

  • Let's say you've done all the work through the remote branch, which means you and your collaborators have completed a feature and merged it into the remote repository's master branch (or any other stable code branch). You can run --delete git push a command with options to delete a remote branch. If you want to remove the Serverfix branch from the server, run the following command.

    # git push [remotename] --delete [branch]$ git push origin --delete serverfix

    To https://github.com/schacon/simplegit - [deleted]         serverfix

  • Basically, this command simply removes the pointer from the server. Git servers typically keep data for a period of time until garbage collection runs, so if you accidentally delete it, it's usually easy to recover.

Ios-git Branch (Distributed version control system)