------------
$ git branch
------------

which used to be nothing more than a simple script around `ls .git/refs/heads`.
There will be an asterisk in front of the branch you are currently on.

Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command

------------
$ git branch <branchname> [startingpoint]
------------

which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
on that branch -- switch to that branch with a regular 'git switch'
with the branchname as the argument.


Merging two branches
--------------------

One of the ideas of having a branch is that you do some (possibly
experimental) work in it, and eventually merge it back to the main
branch. So assuming you created the above `mybranch` that started out
being the same as the original `master` branch, let's make sure we're in
that branch, and do some work there.

------------------------------------------------
$ git switch mybranch
$ echo "Work, work, work" >>hello
$ git commit -m "Some work." -i hello
------------------------------------------------

Here, we just added another line to `hello`, and we used a shorthand for
doing both `git update-index hello` and `git commit` by just giving the
filename directly to `git commit`, with an `-i` flag (it tells
Git to 'include' that file in addition to what you have done to
the index file so far when making the commit).  The `-m` flag is to give the
commit log message from the command line.

Now, to make it a bit more interesting, let's assume that somebody else
does some work in the original branch, and simulate that by going back
to the master branch, and editing the same file differently there:

------------
$ git switch master
------------

Here, take a moment to look at the contents of `hello`, and notice how they
don't contain the work we just did in `mybranch` -- because that work
hasn't happened in the `master` branch at all. Then do

------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
$ git commit -m "Some fun." -i hello example
------------

since the master branch is obviously in a much better mood.

Now, you've got two branches, and you decide that you want to merge the
work done. Before we do that, let's introduce a cool graphical tool that
helps you view what's going on:

----------------
$ gitk --all
----------------

will show you graphically both of your branches (that's what the `--all`
means: normally it will just show you your current `HEAD`) and their
histories. You can also see exactly how they came to be from a common
source.

Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want
to merge the work we did on the `mybranch` branch into the `master`
branch (which is currently our `HEAD` too). To do that, there's a nice
script called 'git merge', which wants to know which branches you want
to resolve and what the merge is all about:

------------
$ git merge -m "Merge work in mybranch" mybranch
------------

where the first argument is going to be used as the commit message if
the merge can be resolved automatically.

Now, in this case we've intentionally created a situation where the
merge will need to be fixed up by hand, though, so Git will do as much
of it as it can automatically (which in this case is just merge the `example`
file, which had no differences in the `mybranch` branch), and say:

----------------
	Auto-merging hello
	CONFLICT (content): Merge conflict in hello
	Automatic merge failed; fix conflicts and then commit the result.
----------------

It tells you that it did an "Automatic merge", which
failed due to conflicts in `hello`.

Not to worry. It left the (trivial) conflict in `hello` in the same form you
should already be well used to if you've ever used CVS, so let's just
open `hello` in our editor (whatever that may be), and fix it up somehow.
I'd suggest just making it so