Tech.Git History
Show minor edits - Show changes to output
Changed lines 162-170 from:
(:sourceend:)
to:
(:sourceend:)
'''Remove the last commit from Git history'''
(:source lang=bash :)
git reset --hard HEAD~1
(:sourceend:)
If the commit has already been pushed to the remote, and you want to propagate the change (WARNING: this is bad if someone already has the commit that will be deleted into his history):
(:source lang=bash :)
git push -f
(:sourceend:)
'''Remove the last commit from Git history'''
(:source lang=bash :)
git reset --hard HEAD~1
(:sourceend:)
If the commit has already been pushed to the remote, and you want to propagate the change (WARNING: this is bad if someone already has the commit that will be deleted into his history):
(:source lang=bash :)
git push -f
(:sourceend:)
Changed lines 146-159 from:
It will create a new commit. The reverted commit is still present in the history.
to:
It will create a new commit. The reverted commit is still present in the history.
!! How to rewrite history
The git rebase command allows you to easily change a series of commits, modifying the history of your repository. You can reorder, edit, or squash commits together.
'''Warning''': Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository.
'''Rebase all the commits between another branch and the current branch state'''
(:source lang=bash :)
git rebase --interactive other_branch_name
(:sourceend:)
'''Rebasing commits against a point in time'''
To rebase the last few commits in your current branch, you can enter the following command in your shell:
(:source lang=bash :)
git rebase --interactive HEAD~7
(:sourceend:)
!! How to rewrite history
The git rebase command allows you to easily change a series of commits, modifying the history of your repository. You can reorder, edit, or squash commits together.
'''Warning''': Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository.
'''Rebase all the commits between another branch and the current branch state'''
(:source lang=bash :)
git rebase --interactive other_branch_name
(:sourceend:)
'''Rebasing commits against a point in time'''
To rebase the last few commits in your current branch, you can enter the following command in your shell:
(:source lang=bash :)
git rebase --interactive HEAD~7
(:sourceend:)
Changed line 120 from:
To remove a remote branch
to:
To remove a remote branch or tag
Changed line 124 from:
To remove a remote tag
to:
To remove a local tag
Deleted line 126:
Changed line 122 from:
git push origin :branch_to_delete
to:
git push origin --delete branch_or_tag_to_delete
Added lines 32-38:
(:sourceend:)
!! Work on a remote branch
(:source lang=bash :)
git fetch origin
git checkout -b mybranch origin/mybranch
!! Work on a remote branch
(:source lang=bash :)
git fetch origin
git checkout -b mybranch origin/mybranch
Deleted line 97:
Added line 101:
Note: It is better to don't use an already existing tag name to name your branch.
Changed line 5 from:
Some other [[http://mislav.uniqpath.com/2010/07/git-tips/ git tips]]
to:
Some other [[http://mislav.uniqpath.com/2010/07/git-tips/|git tips]]
Added lines 4-5:
Some other [[http://mislav.uniqpath.com/2010/07/git-tips/ git tips]]
Added lines 120-131:
!!How to synchronize a branch with the remore repository?
If the branch has no upstream:
(:source lang=bash :)
git pull origin v1.4-maintenance
(:sourceend:)
The best option is to provide the -u option when pushing to the remote to specify the upstream automatically.
To easily track a remote branch from someone else
(:source lang=bash :)
git checkout -t origin/feature
(:sourceend:)
It creates and checks out "feature" branch that tracks "origin/feature".
If the branch has no upstream:
(:source lang=bash :)
git pull origin v1.4-maintenance
(:sourceend:)
The best option is to provide the -u option when pushing to the remote to specify the upstream automatically.
To easily track a remote branch from someone else
(:source lang=bash :)
git checkout -t origin/feature
(:sourceend:)
It creates and checks out "feature" branch that tracks "origin/feature".
Changed line 95 from:
!! How to push a new branch to the remote
to:
!! How to push a new branch to the remote?
Changed lines 100-101 from:
!! How to delete a remote branch/tag
To remove a remote branch
to:
!! How to create a tag?
It will create an annotated tag (recommended)
(:source lang=bash :)
git tag -a v1.4 -m 'my version 1.4'
(:sourceend:)
To list tags:
(:source lang=bash :)
git tag
git tag -l v1.4/*
(:sourceend:)
!! How to delete a remote branch/tag?
It will create an annotated tag (recommended)
(:source lang=bash :)
git tag -a v1.4 -m 'my version 1.4'
(:sourceend:)
To list tags:
(:source lang=bash :)
git tag
git tag -l v1.4/*
(:sourceend:)
!! How to delete a remote branch/tag?
Changed lines 100-101 from:
!! How to delete a remote branch
to:
!! How to delete a remote branch/tag
To remove a remote branch
To remove a remote branch
Added lines 104-108:
(:sourceend:)
To remove a remote tag
(:source lang=bash :)
git tag -d tagtodelete
git push origin :refs/tags/tagtodelete
To remove a remote tag
(:source lang=bash :)
git tag -d tagtodelete
git push origin :refs/tags/tagtodelete
Changed line 95 from:
!! Push a new branch to the remote
to:
!! How to push a new branch to the remote
Changed line 100 from:
!! Delete a remote branch
to:
!! How to delete a remote branch
Added lines 95-105:
!! Push a new branch to the remote
It is better to don't use an already existing tag name to name your branch.
(:source lang=bash :)
git push origin newbranch
(:sourceend:)
!! Delete a remote branch
(:source lang=bash :)
git push origin :branch_to_delete
(:sourceend:)
Changed lines 94-101 from:
You can also check this [[http://mislav.uniqpath.com/2013/02/merge-vs-rebase/|useful post]]
to:
You can also check this [[http://mislav.uniqpath.com/2013/02/merge-vs-rebase/|useful post]]
!! How to revert a commit?
It is as simple as
(:source lang=bash :)
git revert 5f1b62549477
(:sourceend:)
It will create a new commit. The reverted commit is still present in the history.
!! How to revert a commit?
It is as simple as
(:source lang=bash :)
git revert 5f1b62549477
(:sourceend:)
It will create a new commit. The reverted commit is still present in the history.
Added lines 30-46:
(:sourceend:)
!! Remove untracked files
(:source lang=bash :)
git clean -f
(:sourceend:)
If you want to also remove directories, run
(:source lang=bash :)
git clean -f -d
(:sourceend:)
If you just want to remove ignored files, run
(:source lang=bash :)
git clean -f -X
(:sourceend:)
If you want to remove ignored as well as non-ignored files, run
(:source lang=bash :)
git clean -f -x
!! Remove untracked files
(:source lang=bash :)
git clean -f
(:sourceend:)
If you want to also remove directories, run
(:source lang=bash :)
git clean -f -d
(:sourceend:)
If you just want to remove ignored files, run
(:source lang=bash :)
git clean -f -X
(:sourceend:)
If you want to remove ignored as well as non-ignored files, run
(:source lang=bash :)
git clean -f -x
Deleted line 13:
Deleted line 22:
Deleted line 26:
Changed line 64 from:
# %item value=3% Then, Compare any branch from your local repository to any remote you've added.
to:
# %item value=3% Then, compare any branch from your local repository to any remote you've added.
Added lines 4-33:
!! Git info
There is no git info (like svn info) command available with git :(
Instead you can use following commands.
!!! List remote URL
(:source lang=bash :)
git remote -v
(:sourceend:)
!!! List branches
Remote branches:
(:source lang=bash :)
git branch -r
(:sourceend:)
Local branches:
(:source lang=bash :)
git branch
(:sourceend:)
!!! Git configuration
(:source lang=bash :)
cat .git/config
(:sourceend:)
!!! Most recent commit
(:source lang=bash :)
git —no-pager log —max-count=1
(:sourceend:)
Added lines 25-39:
(:sourceend:)
!! How to diff between a fork with its origin repository?
# First, in your forked repository, add the origin as a remote
(:source lang=bash :)
git remote add <aname-refering-to-the-origin-repo> <origin-git-url>
(:sourceend:)
# %item value=2% Fetch origin changes into your forked repository. It won't change your working copy.
(:source lang=bash :)
git fetch <aname-refering-to-the-origin-repo>
(:sourceend:)
# %item value=3% Then, Compare any branch from your local repository to any remote you've added.
(:source lang=bash :)
git diff master <aname-refering-to-the-origin-repo>/master
!! How to diff between a fork with its origin repository?
# First, in your forked repository, add the origin as a remote
(:source lang=bash :)
git remote add <aname-refering-to-the-origin-repo> <origin-git-url>
(:sourceend:)
# %item value=2% Fetch origin changes into your forked repository. It won't change your working copy.
(:source lang=bash :)
git fetch <aname-refering-to-the-origin-repo>
(:sourceend:)
# %item value=3% Then, Compare any branch from your local repository to any remote you've added.
(:source lang=bash :)
git diff master <aname-refering-to-the-origin-repo>/master
Changed lines 28-29 from:
If you are many people working on the same software, your central git repository will end with a lot of branches and merge. Indeed, developers start to work on a revision and, when they are ready to push their changes, there will probably be new revisions from other developers. The default behavior of git when pushing your changes is to define a branch, add your commits to this branch and then merge the branch back to the master. To avoid that, especially if you know there is no conflict, you can use %black%git rebase%.
See[[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] ([[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|french]]).
See
to:
If you are many people working on the same software, your central git repository will end with a lot of branches and merge. Indeed, developers start to work on a revision and, when they are ready to push their changes, there will probably be new revisions from other developers. The default behavior of git when pulling changes from the central repository is to define a branch, add your commits to this branch and then merge the branch back to the master. To avoid that, especially if you know there is no conflict, you can use %black%git rebase%% as explained [[http://git-scm.com/book/en/Git-Branching-Rebasing|here]] or [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|here (french)]].
Hopefully, there is a shorcut for that. You can use pull with %black%git pull --rebase%%. Git can be configured to make it the default behavior:
(:source lang=bash :)
git config --global --bool pull.rebase true
(:sourceend:)
You can also check this [[http://mislav.uniqpath.com/2013/02/merge-vs-rebase/|useful post]]
Hopefully, there is a shorcut for that. You can use pull with %black%git pull --rebase%%. Git can be configured to make it the default behavior:
(:source lang=bash :)
git config --global --bool pull.rebase true
(:sourceend:)
You can also check this [[http://mislav.uniqpath.com/2013/02/merge-vs-rebase/|useful post]]
Changed line 27 from:
!! How to avoid many branches in your repository
to:
!! How to avoid many branches in your repository?
Changed line 29 from:
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] ( [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|french]]).
to:
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] ([[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|french]]).
Changed line 29 from:
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] (or [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|(french)]]).
to:
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] ( [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|french]]).
Changed lines 25-29 from:
(:sourceend:)
to:
(:sourceend:)
!! How to avoid many branches in your repository
If you are many people working on the same software, your central git repository will end with a lot of branches and merge. Indeed, developers start to work on a revision and, when they are ready to push their changes, there will probably be new revisions from other developers. The default behavior of git when pushing your changes is to define a branch, add your commits to this branch and then merge the branch back to the master. To avoid that, especially if you know there is no conflict, you can use %black%git rebase%%.
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] (or [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|(french)]]).
!! How to avoid many branches in your repository
If you are many people working on the same software, your central git repository will end with a lot of branches and merge. Indeed, developers start to work on a revision and, when they are ready to push their changes, there will probably be new revisions from other developers. The default behavior of git when pushing your changes is to define a branch, add your commits to this branch and then merge the branch back to the master. To avoid that, especially if you know there is no conflict, you can use %black%git rebase%%.
See [[http://git-scm.com/book/en/Git-Branching-Rebasing|Git rebasing]] (or [[http://alx.github.io/gitbook/4_recombinaison_(rebase).html|(french)]]).
Added lines 2-3:
The Git community book [[http://alx.github.io/gitbook/index.html|(french)]] [[http://git-scm.com/book|(english)]]
Changed lines 1-2 from:
!Git How-tos
to:
!%center% Git How-tos
Changed line 23 from:
(:sourceend:)
to:
(:sourceend:)
Changed line 10 from:
# Then, fetch origin changes into your forked repository
to:
# %item value=2% Then, fetch origin changes into your forked repository
Changed line 14 from:
# List branches to see new available branches from the origin repository
to:
# %item value=3% List branches to see new available branches from the origin repository
Changed line 18 from:
# Now, we can merge
to:
# %item value=4% Now, we can merge
Added lines 1-21:
!! How to synchronize a fork with its origin repository?
MyA is a fork of the repository A.
You use MyA for your devs and made updates. In the same time, the origin repository A still follows its way (new push, etc.).
How to do if you want to (re)synchronize your forked repository with its origin?
# First, in your forked repository, add the origin as a remote
(:source lang=bash :)
git remote add <aname-refering-to-the-origin-repo> <origin-git-url>
(:sourceend:)
# Then, fetch origin changes into your forked repository
(:source lang=bash :)
git fetch <aname-refering-to-the-origin-repo>
(:sourceend:)
# List branches to see new available branches from the origin repository
(:source lang=bash :)
git branch -a
(:sourceend:)
# Now, we can merge
(:source lang=bash :)
git merge remotes/<aname-refering-to-the-origin-repo>/<branch-name>
(:sourceend:)
MyA is a fork of the repository A.
You use MyA for your devs and made updates. In the same time, the origin repository A still follows its way (new push, etc.).
How to do if you want to (re)synchronize your forked repository with its origin?
# First, in your forked repository, add the origin as a remote
(:source lang=bash :)
git remote add <aname-refering-to-the-origin-repo> <origin-git-url>
(:sourceend:)
# Then, fetch origin changes into your forked repository
(:source lang=bash :)
git fetch <aname-refering-to-the-origin-repo>
(:sourceend:)
# List branches to see new available branches from the origin repository
(:source lang=bash :)
git branch -a
(:sourceend:)
# Now, we can merge
(:source lang=bash :)
git merge remotes/<aname-refering-to-the-origin-repo>/<branch-name>
(:sourceend:)