branch_1 and branch_2.git diff branch_1..branch_2
git diff branch_1...branch_2
error: unable to push to unqualified destination: the_remote_branch The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@repository_name'-p, --prune After fetching, remove any remote-tracking branches which no longer exist on the remote.The name "git" was given by Linus Torvalds when he wrote the very
first version. He described the tool as "the stupid content tracker"
and the name as (depending on your way):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of shit": when it breaks
| Version | Original release date[citation needed] | Latest version | Release date[citation needed] |
|---|---|---|---|
| 0.99 | 2005-07-11 | 0.99.9n | 2005-12-15 |
| 1.0 | 2005-12-21 | 1.0.13 | 2006-01-27 |
| 1.1 | 2006-01-08 | 1.1.6 | 2006-01-30 |
| 1.2 | 2006-02-12 | 1.2.6 | 2006-04-08 |
| 1.3 | 2006-04-18 | 1.3.3 | 2006-05-16 |
| 1.4 | 2006-06-10 | 1.4.4.5 | 2008-07-16 |
| 1.5 | 2007-02-14 | 1.5.6.6 | 2008-12-17 |
| 1.6 | 2008-08-17 | 1.6.6.3 | 2010-12-15 |
| 1.7 | 2010-02-13 | 1.7.12.4 | 2012-10-17 |
| 1.8 | 2012-10-21 | 1.8.5.6 | 2014-12-17 |
| 1.9 | 2014-02-14 | 1.9.5 | 2014-12-17 |
| 2.0 | 2014-05-28 | 2.0.5 | 2014-12-17 |
| 2.1 | 2014-08-16 | 2.1.4 | 2014-12-17 |
| 2.2 | 2014-11-26 | 2.2.3 | 2015-09-04 |
| 2.3 | 2015-02-05 | 2.3.10 | 2015-09-29 |
| 2.4 | 2015-04-30 | 2.4.12 | 2017-05-05 |
| 2.5 | 2015-07-27 | 2.5.6 | 2017-05-05 |
| 2.6 | 2015-09-28 | 2.6.7 | 2017-05-05 |
| 2.7 | 2015-10-04 | 2.7.5 | 2017-05-05 |
| 2.8 | 2016-03-28 | 2.8.5 | 2017-05-05 |
| 2.9 | 2016-06-13 | 2.9.4 | 2017-05-05 |
| 2.10 | 2016-09-02 | 2.10.3 | 2017-05-05 |
| 2.11 | 2016-11-29 | 2.11.2 | 2017-05-05 |
| 2.12 | 2017-02-24 | 2.12.3 | 2017-05-05 |
| 2.13 | 2017-05-10 | 2.13.4 | 2017-08-01 |
| 2.14 | 2017-08-04 | 2.14.3 | 2017-10-24 |
| 2.15 | 2017-10-30 | 2.15.1 | 2017-11-28 |
|
Legend:
Old version
Older version, still supported
Latest version
Latest preview version
|
|||
git gc --prune.[38]When there are more than one common ancestors that can be used for three-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the three-way merge. This has been reported to result in fewer merge conflicts without causing mis-merges by tests done on prior merge commits taken from Linux 2.6 kernel development history. Also, this can detect and handle merges involving renames.
— Linus Torvalds[46]
In many ways you can just see git as a filesystem – it's content-addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a filesystem person (hey, kernels is what I do), and I actually have absolutely zero interest in creating a traditional SCM system.From this initial design approach, Git has developed the full set of features expected of a traditional SCM,[29] with features mostly being created as needed, then refined and extended over time.
$ git config --global user.name "Your Name Comes Here" $ git config --global user.email you@yourdomain.example.com
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
$ eval $(ssh-agent -s)
$ ssh-add ~/.ssh/id_rsa
---
Add public key vào github
$ clip < ~/.ssh/id_rsa.pub
---
Confirm kết nối
$ ssh -T git@github.com
---
Tạo project trên github
---
Vào thư mục cần đưa lên github
$ git init $ git add . $ git commit -m "first commit" $ git remote add origin git@github.com:path/to/project.git $ git push -u origin master
origin, since this
name is familiar to all Git users.
origin prematurely. In the figure above, there are subteams of Alice and Bob,
Alice and David, and Clair and David.bob, pointing to Bob’s repository, and vice versa.
masterdevelopmaster branch at origin should be familiar to every Git user. Parallel
to the master branch, another branch exists called develop.origin/master to be the main branch where the source code of
HEAD always reflects a production-ready state.origin/develop to be the main branch where the source code of
HEAD always reflects a state with the latest delivered development changes
for the next release. Some would call this the “integration branch”. This is
where any automatic nightly builds are built from.develop branch reaches a stable point and is
ready to be released, all of the changes should be merged back into master
somehow and then tagged with a release number. How this is done in detail will
be discussed further on.master, this is a new
production release by definition. We tend to be very strict at this, so that
theoretically, we could use a Git hook script to automatically build and
roll-out our software to our production servers everytime there was a commit on
master.master and develop, our development model uses
a variety of supporting branches to aid parallel development between team
members, ease tracking of features, prepare for production releases and to
assist in quickly fixing live production problems. Unlike the main branches,
these branches always have a limited life time, since they will be removed
eventually.
develop develop master, develop, release-*, or hotfix-*develop (to definitely add the new feature to the
upcoming release) or discarded (in case of a disappointing experiment).origin.develop branch.$ git checkout -b myfeature develop Switched to a new branch "myfeature"
develop branch to definitely add
them to the upcoming release:$ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop
--no-ff flag causes the merge to always create a new commit object, even
if the merge could be performed with a fast-forward. This avoids losing
information about the historical existence of a feature branch and groups
together all commits that together added the feature. Compare:
--no-ff flag was used.developdevelop and masterrelease-*develop
branch is cleared to receive features for the next big release.develop is when
develop (almost) reflects the desired state of the new release. At least all
features that are targeted for the release-to-be-built must be merged in to
develop at this point in time. All features targeted at future releases may
not—they must wait until after the release branch is branched off.develop
branch reflected changes for the “next release”, but it is unclear whether that
“next release” will eventually become 0.3 or 1.0, until the release branch is
started. That decision is made on the start of the release branch and is
carried out by the project’s rules on version number bumping.develop branch. For example, say
version 1.1.5 is the current production release and we have a big release
coming up. The state of develop is ready for the “next release” and we have
decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we
branch off and give the release branch a name reflecting the new version
number:$ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)
bump-version.sh is a fictional shell script that changes some files in
the working copy to reflect the new version. (This can of course be a manual
change—the point being that some files change.) Then, the bumped version
number is committed.develop branch). Adding large new features here is
strictly prohibited. They must be merged into develop, and therefore, wait
for the next big release.master (since every commit on master is a new release by definition,
remember). Next, that commit on master must be tagged for easy future
reference to this historical version. Finally, the changes made on the release
branch need to be merged back into develop, so that future releases also
contain these bug fixes.$ git checkout master Switched to branch 'master' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2
Edit: You might as well want to use theTo keep the changes made in the release branch, we need to merge those back into-sor-u <key>flags to sign your tag cryptographically.
develop, though. In Git:$ git checkout develop Switched to branch 'develop' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes)
$ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe).
masterdevelop and masterhotfix-*develop branch) can
continue, while another person is preparing a quick production fix.master branch. For example, say version
1.2 is the current production release running live and causing troubles due to
a severe bug. But changes on develop are yet unstable. We may then branch off
a hotfix branch and start fixing the problem:$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1. $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)
$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)
master, but also needs
to be merged back into develop, in order to safeguard that the bugfix is
included in the next release as well. This is completely similar to how release
branches are finished.master and tag the release.$ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1
-s or -u <key> flags to sign
your tag cryptographically.develop, too:$ git checkout develop Switched to branch 'develop' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes)
develop. Back-merging the bugfix into the release branch will eventually
result in the bugfix being merged into develop too, when the release branch
is finished. (If work in develop immediately requires this bugfix and cannot
wait for the release branch to be finished, you may safely merge the bugfix
into develop now already as well.)$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).
cd existing_repo
git remote add origin git@gitlab.com:hungnv-runsystem-net/design-pattern.git
git push -u origin --all
git push -u origin --tags
$ git checkout -b myfeature develop
Switched to a new branch "myfeature"
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
–no-ff flag có nghĩa là việc merge sẽ luôn
luôn tạo ra 1 đối thượng commit, kể cả nếu việc merge có thể được thực
thi với fast-forward. Nó chống lại việc mất thông tin về quá trình phát
triển của feature và nhóm lại với nhau, hình sau sẽ giúp ta dễ hình dung
hơn:–no-ff thì những log về commit
trong branch cũ vẫn được lưu giữ lại việc này giúp cho chùng ta lần lại
được log của tất cả những commit trong quá khứ, xem được những thay đổi
trong mỗi lần commit đấy. Sử dụng flag này tránh được rắc rối khi chúng
ta kiểm tra lại sự thay đổi của project trong quá trình phát triển, khi
mà lúc merge xong thì mọi commit trong branch cũ được kết hợp lại làm
một.$ git checkout -b release-1.2 develop
→ tạo mới và chuyển sang "release-1.2"
$ ./bump-version.sh 1.2
→ bump (nâng version) new version (config thông tin của product thành version mới)
$ git commit -a -m "Bumped version number to 1.2"
→commit state mới
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
$ git tag -a 1.2
Relese done, và được tag cho lần release này.
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
Bước này có thể bị confict, ta phải fix chúng rồi commit lên develop.
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
$ git checkout -b hotfix-1.2.1 master
Tạo mới và chuyển sang branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)
Đừng bao giờ quên bump the version number sau khi branching off!
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
Finishing a hotfix branch
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).