…read and compare the help for the log command across the various tools: 4 pages for bzr log, one page for svn log, 26 pages for git log, and one page for hg log. In fact there’s a great quote in the bazaar docs about it: The log command in git is, much like the rest of the tool, somewhat overly powerful. You can do this by using fetch and then merge instead of the pull command in fact the pull command is a wrapper which runs fetch followed by merge so these approaches are equivalent. You may also prefer to pull down the changes and then look at them before applying them to your branch. If the changes apply cleanly, git will automatically then commit these changes for you – you will see these in your history with a message like “Merge branch ‘master’ of git:///joindin/joind.in”. You’ll see information about which files have changed and how much was added/removed in them. If the changes all apply cleanly, git will automatically commit them for you (more on committing changes later), which surprises a lot of people when they see it for the first time! The syntax is simple, especially if you have the other repo set up as a remote: When you want to bring in changes from another repository, you can simply use pull to bring them in and apply them to your repo. Keeping Up To Date with Fetch+Merge or Pull This shows the upstream remote we just created, and the origin which is made by default when you clone a repo to point to the repo that was cloned. $ git remote add upstream git:///joindin/joind.in.git To add and then check these aliases, use the git remote command: A great example is the instructions given in the github forking guide which recommends setting up an “upstream” alias to make it easy to pull in changes from there. Git has a way of adding shortcuts to repository URLs that you are likely to use a lot. Nothing to commit (working directory clean) # Your branch is ahead of 'origin/master' by 1 commit. With git, you can have local changes, and you can also commit to the local repo and not push the changes to the location you cloned from yet, and the status command gives this information all in one go. Just like with Subversion, the status command shows us what state our repository is in. If you are checking out your own project and you want to be able to push your changes back to it, then you need to use one of the private URLs and set up an ssh key to use with it. Some are public, some are private so you need permission to push for those. On github, there are different URL formats. Initialized empty Git repository in /home/lorna/svndir/joindin/thinkvit/joind.in/.git/ Here’s an example, showing a clone of my private joind.in repo on github. When you are ready to clone the repo, create the directory to store it in and change into it. In git, you always clone the whole repo, not a subdirectory, and the metadata is all stored at the top level, in a directory called. You end up with a local repository on your filesystem, which behaves as both the repo and as your working copy. In git, you don’t checkout code, you clone a repository. GUI tools and IDE plugins are available for git so it is worth taking a look at what is available for the development environment you use. I’ve used entirely the command line tools, since those are the same on every platform. Today I thought I’d share my “cheat sheet” for git – the commands that I use on a day-to-day basis.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |