How do you create a new project/repository?
A git repository is simply a directory containing a special .git
directory.
This is different from "centralised" version-control systems (like subversion), where a "repository" is hosted on a remote server, which you checkout
into a "working copy" directory. With git, your working copy is the repository.
Simply run git init
in the directory which contains the files you wish to track.
For example,
cd ~/code/project001/
git init
This creates a .git
(hidden) folder in the current directory.
To make a new project, run git init
with an additional argument (the name of the directory to be created):
git init project002
(This is equivalent to: mkdir project002 && cd project002 && git init)
To check if the current current path is within a git repository, simply run git status
- if it's not a repository, it will report "fatal: Not a git repository"
You could also list the .git
directory, and check it contains files/directories similar to the following:
$ ls .git
HEAD config hooks/ objects/
branches/ description info/ refs/
If for whatever reason you wish to "de-git" a repository (you wish to stop using git to track that project). Simply remove the .git
directory at the base level of the repository.
cd ~/code/project001/
rm -rf .git/
Caution: This will destroy all revision history, all your tags, everything git has done. It will not touch the "current" files (the files you can currently see), but previous changes, deleted files and so on will be unrecoverable!
Best Answer
Here's the cheat sheet on the commands:
hg update
changes your working copy parent revision and also changes the file content to match this new parent revision. This means that new commits will carry on from the revision you update to.hg revert
changes the file content only and leaves the working copy parent revision alone. You typically usehg revert
when you decide that you don't want to keep the uncommited changes you've made to a file in your working copy.hg branch
starts a new named branch. Think of a named branch as a label you assign to the changesets. So if you dohg branch red
, then the following changesets will be marked as belonging on the "red" branch. This can be a nice way to organize changesets, especially when different people work on different branches and you later want to see where a changeset originated from. But you don't want to use it in your situation.If you use
hg update --rev 38
, then changesets 39–45 will be left as a dead end — a dangling head as we call it. You'll get a warning when you push since you will be creating "multiple heads" in the repository you push to. The warning is there since it's kind of impolite to leave such heads around since they suggest that someone needs to do a merge. But in your case you can just go ahead andhg push --force
since you really do want to leave it hanging.If you have not yet pushed revision 39-45 somewhere else, then you can keep them private. It's very simple: with
hg clone --rev 38 foo foo-38
you will get a new local clone that only contains up to revision 38. You can continue working infoo-38
and push the new (good) changesets you create. You'll still have the old (bad) revisions in yourfoo
clone. (You are free to rename the clones however you want, e.g.,foo
tofoo-bad
andfoo-38
tofoo
.)Finally, you can also use
hg revert --all --rev 38
and then commit. This will create a revision 46 which looks identical to revision 38. You'll then continue working from revision 46. This wont create a fork in the history in the same explicit way ashg update
did, but on the other hand you wont get complains about having multiple heads. I would usehg revert
if I were collaborating with others who have already made their own work based on revision 45. Otherwise,hg update
is more explicit.