You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remote branch
4.1 To see tracking branches
4.2 Track remote branch
4.3 Checkout a special remote branch
4.4 Synchronize the local branch (master) with the remote branch
master branch contains production code. All development code is merged (via GitHub pull request) into master in sometime.
develop branch contains pre-production code. When the features are finished then they are merged into develop.
During the development cycle, a variety of supporting branches are used:
feature-* branches are used to develop new features for the upcoming releases. May branch off from develop and must merge into develop.
hotfix-* branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master and develop.
release-* branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master and develop.
1.1 Create and switch branch
git checkout
$ git checkout -b dev
Switched to a new branch 'dev'
the same:
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
$ git branch
* dev
master
git switch
Git v2.23.0 began to support the $ git switch command.
In Git version 2.23.0, a new command called $ git switch was introduced to eventually replace $ git checkout, which is somewhat overloaded as a command (it does a bunch of separate things).
-d --delete
Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or --set-upstream-to. -D
Shortcut for --delete --force.
Example:
Now that your work is merged in, you have no further need for the iss53 branch. You can close the issue in your issue-tracking system, and delete the branch:
$ git branch -d iss53
1.3 Delete remote branch
Suppose you’re done with a remote branch — say you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the --delete option to git push. If you want to delete your serverfix branch from the server, you run the following:
Basically all this does is remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it’s often easy to recover.
Combining the work from two different branches together. This will allow us to branch off, develop a new feature, and then combine it back in.
The first method to combine work that we will examine is $ git merge. (The second one is $ git rebase .)
Merging in Git creates a special commit that has two unique parents. A commit with two parents essentially means "I want to include all the work from this parent over here and this one over here, and the set of all their parents."
Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else.
The advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.
It’s important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it’s telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you’ll need to fetch from all your remotes right before running this. You could do that like this:
Adding a remote tracking branch means that git then knows what you want to do when you git fetch, git pull or git push in future.
It assumes that you want to keep the local branch and the remote branch it is tracking in sync.
If you are planning on basing your work on an upstream branch that already exists at the remote, run:
$ git push origin react-get-api
Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 2 threads
Compressing objects: 100% (34/34), done.
Writing objects: 100% (34/34), 282.29 KiB | 12.27 MiB/s, done.
Total 34 (delta 10), reused 0 (delta 0)
remote: Resolving deltas: 100% (10/10), completed with 5 local objects.
remote:
remote: Create a pull request for'react-get-api' on GitHub by visiting:
remote: https://github.com/Qingquan-Li/learnenglish/pull/new/react-get-api
remote:
To github.com:Qingquan-Li/learnenglish.git
* [new branch] react-get-api -> react-get-api
$
$ git branch -vv
dev 86ecaf1 [origin/dev] Use a new domain: learnenglish.qingquanli.com
master d23fb72 [origin/master] Merge pull request #1 from Qingquan-Li/dev* react-get-api be839f6 Write a simple get-api page
$
$ git branch -u origin/react-get-api
Branch 'react-get-api'set up to track remote branch 'react-get-api' from 'origin'.
$
$ git branch -vv
dev 86ecaf1 [origin/dev] Use a new domain: learnenglish.qingquanli.com
master d23fb72 [origin/master] Merge pull request #1 from Qingquan-Li/dev* react-get-api be839f6 [origin/react-get-api] Write a simple get-api page
If you are planning to push out a new local branch that will track its remote counterpart, you may want to use git push -u to set the upstream config as you push:
(dev) $ git push -u origin dev
This sets the upstream association for any future git push and git pull attempts automatically.
Example (Assuming that you haven't set-upstream before pushing):
jake@vm-ubuntu:~/react-table-demo$ git push
fatal: The current branch dev has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin dev
jake@vm-ubuntu:~/react-table-demo$ git push --set-upstream origin dev
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 2 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 729 bytes | 729.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To github.com:FatliTalk/react-table-demo.git
28bf37e..785a523 dev -> dev
Branch 'dev'set up to track remote branch 'dev' from 'origin'.
$ # After cloning a remote Git repository, there is only the `master` branch in the repository.
$ git branch
* master
$
$ # Using the `-a` flag to check other branches hiding in the repository.
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/dev
remotes/origin/master
remotes/origin/pythonanywhere
$
$ # If you want to work on that branch, you'll need to create a local tracking branch:
$ git checkout pythonanywhere
Branch 'pythonanywhere'set up to track remote branch 'pythonanywhere' from 'origin'.
Switched to a new branch 'pythonanywhere'
$
$ git branch
master
* pythonanywhere
4.4 Synchronize the local branch (master) with the remote branch
Table of Contents:
1.1 Create and switch branch
1.2 Delete local branch
1.3 Delete remote branch
2.1 non fast-forward merge
2.2 fast-forward merge
2.3
git merge --no-ff
vsgit-merge
4.1 To see tracking branches
4.2 Track remote branch
4.3 Checkout a special remote branch
4.4 Synchronize the local branch (master) with the remote branch
References:
1. Use different branch
Two main branches with infinite lifetime:
master
branch contains production code. All development code is merged (via GitHubpull request
) into master in sometime.develop
branch contains pre-production code. When the features are finished then they are merged into develop.During the development cycle, a variety of supporting branches are used:
feature-*
branches are used to develop new features for the upcoming releases. May branch off fromdevelop
and must merge intodevelop
.hotfix-*
branches are necessary to act immediately upon an undesired status ofmaster
. May branch off frommaster
and must merge intomaster
anddevelop
.release-*
branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off fromdevelop
and must merge intomaster
anddevelop
.1.1 Create and switch branch
git checkout
$ git checkout -b dev Switched to a new branch 'dev'
the same:
$ git branch dev $ git checkout dev Switched to branch 'dev'
$ git branch * dev master
git switch
Git v2.23.0 began to support the
$ git switch
command.In Git version 2.23.0, a new command called
$ git switch
was introduced to eventually replace$ git checkout
, which is somewhat overloaded as a command (it does a bunch of separate things).$ git switch -c dev Switched to a new branch 'dev'
the same:
$ git branch dev $ git switch dev Switched to branch 'dev'
1.2 Delete local branch
-d
--delete
Delete a branch. The branch must be fully merged in its upstream branch, or in HEAD if no upstream was set with --track or --set-upstream-to.
-D
Shortcut for --delete --force.
Example:
Now that your work is merged in, you have no further need for the iss53 branch. You can close the issue in your issue-tracking system, and delete the branch:
1.3 Delete remote branch
Suppose you’re done with a remote branch — say you and your collaborators are finished with a feature and have merged it into your remote’s
master
branch (or whatever branch your stable codeline is in). You can delete a remote branch using the--delete
option to git push. If you want to delete yourserverfix
branch from the server, you run the following:Basically all this does is remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it’s often easy to recover.
2. Git merge
Combining the work from two different branches together. This will allow us to branch off, develop a new feature, and then combine it back in.
The first method to combine work that we will examine is
$ git merge
. (The second one is$ git rebase
.)Merging in Git creates a special commit that has two unique parents. A commit with two parents essentially means "I want to include all the work from this parent over here and this one over here, and the set of all their parents."
2.1 non fast-forward merge
2.2 fast-forward merge
2.3
git merge --no-ff
vsgit-merge
3. Git rebase
Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else.
The advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.
Note: The Golden Rule of Rebasing reads: “Never rebase while you’re on a public branch.”
-> Replace with use Pull requests
4. Remote branch
4.1 To see tracking branches
If you want to see what tracking branches you have set up, you can use the
-vv
option togit branch
.It’s important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it’s telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you’ll need to fetch from all your remotes right before running this. You could do that like this:
$ git fetch --all; git branch -vv
4.2 Track remote branch
Adding a remote tracking branch means that git then knows what you want to do when you
git fetch
,git pull
orgit push
in future.It assumes that you want to keep the local branch and the remote branch it is tracking in sync.
If you are planning on basing your work on an upstream branch that already exists at the remote, run:
Example:
If you are planning to push out a new local branch that will track its remote counterpart, you may want to use
git push -u
to set the upstream config as you push:This sets the upstream association for any future
git push
andgit pull
attempts automatically.Example (Assuming that you haven't set-upstream before pushing):
4.3 Checkout a special remote branch
4.4 Synchronize the local branch (master) with the remote branch
The text was updated successfully, but these errors were encountered: