A cherry-pick applies the changes from a given commit (from another branch) onto the current branch. A rebase resets the branch to the state of another branch (upstream) and then re-applies your local changes by cherry-picking each of your local commits onto the upstream commit history.
Usage
git_rebase_list(upstream = NULL, repo = ".")
git_rebase_commit(upstream = NULL, repo = ".")
git_cherry_pick(commit, repo = ".")
git_ahead_behind(upstream = NULL, ref = "HEAD", repo = ".")
Arguments
- upstream
branch to which you want to rewind and re-apply your local commits. The default uses the remote upstream branch with the current state on the git server, simulating git_pull.
- repo
The path to the git repository. If the directory is not a repository, parent directories are considered (see git_find). To disable this search, provide the filepath protected with
I()
. When using this parameter, always explicitly call by name (i.e.repo =
) because future versions of gert may have additional parameters.- commit
id of the commit to cherry pick
- ref
string with a branch/tag/commit
Details
git_rebase_list
shows your local commits that are missing from the upstream
history, and if they conflict with upstream changes. It does so by performing
a rebase dry-run, without committing anything. If there are no conflicts, you
can use git_rebase_commit
to rewind and rebase your branch onto upstream
.
Gert only support a clean rebase; it never leaves the repository in unfinished
"rebasing" state. If conflicts arise, git_rebase_commit
will raise an error
without making changes.
See also
Other git:
git_archive
,
git_branch()
,
git_commit()
,
git_config()
,
git_diff()
,
git_fetch()
,
git_ignore
,
git_merge()
,
git_remote
,
git_repo
,
git_reset()
,
git_signature()
,
git_stash
,
git_tag