[Android Q&A, Help & Troubleshooting] The Arrow:
So now we learnt pull, push, status. We proceed with The most important command

cherry-pick

{Most of the people might have heard of it, and wonder what it is?}

Cherry picking in Git is designed to apply some commit from one branch into another branch, one repo into another

Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).

When it is not obvious how to apply a change, the following happens:

The current branch and HEAD pointer stay at the last commit successfully made.

The CHERRY_PICK_HEAD ref is set to point at the commit that introduced the change that is difficult to apply.

Paths in which the change applied cleanly are updated both in the index file and in your working tree.

For conflicting paths, the index file records up to three versions, as described in the "TRUE MERGE" section of git-merge[1]. The working tree files will include a description of the conflict bracketed by the usual conflict markers <<<<<<< and >>>>>>>.

No other modifications are made.

So I would wish to cherry-pick a particular commit on the same repo we have been working upon.

This is the commit I want to pick in my repo.

For cherry-picking, first we need to learn

git fetch

What does git fetch do?

git fetch - Download objects and refs from another repository

Command :

git fetch <URL> <Branch>

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.

git fetch can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file.

When no remote is specified, by default the origin remote will be used, unless thereâ€™s an upstream branch configured for the current branch.

So we fetch it from the AICP github with branch name n7.1

and then we cherry-pick it by using

git cherry-pick <commit ID>

and now it's cherry-picked. We have that commit in our repo.

Note : This was an easy pick but most picks aren't this easy. We will learn about fixing conflicts later on

Now we push it to gitlabs repo.

and we'll check if our gitlabs repo has it now !?

Now we learn how to create a new branch and push to that branch.

We create a new branch by

git branch <new branch name>

This creates a new branch with the new branch name specified in the command.

Now we checkout the branch to switch to that particular branch.

Command :

git checkout <branch name>

git checkout <branch>

To prepare for working on <branch>, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the <branch>.

If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to

git checkout -b <branch> --track <remote>/<branch>

You could omit <branch>, in which case the command degenerates to "check out the current branch", which is a glorified no-op with a rather expensive side-effects to show only the tracking information, if exists, for the current branch.

Now that we have successfully cherry-picked,

we will learn to show the commits logs in terminal itself (Not GUI).

git log

can help us with that.

We can also add a flag besides it for example 'git log -3' to see the last 3 commits.

Shows the commit logs.

The command takes options applicable to the git rev-list command to control what is shown and how, and options applicable to the git diff-* commands to control how the changes each commit introduces are shown.

Now we learn how to revert a cherry-pick ?

Well it's pretty easy.

So I grab the commit ID from the commit I wish to revert.

Here's the command

git revert <commit ID>

After reverting make sure to push it to the repo to see the revert there as well :)

Supposing we make a change to a repo and we don't wish to commit it. Instead we wish to reset the repo to the previous state,

Here is a ways we can do it.

git stash

It discards all the local changes and gets it back to the last commit.

Also suppose if we want to revert 20 odd commits and we have force push access (And you are lazy like me :P), we don't revert it one by one. Instead we can just hard reset the repo to the last commit

Command :

git reset --hard <commit ID>

This is the easiest way to do it.

Now the last one. Force pushing

Sometimes github doesnt let us push after resetting hard because the previous commits dont exist in our repo.

We can just force push to force it accept the commits

Command :

git push -f <URL name> <branch name>

It is basically a noob method to just add changes easily after a failed or unsuccessful push.