Something I often run into is something modifying file permissions on my desktop end, where permissions are irrelevant on the deployment end. Here is how to tell git to ignore permissions changes in the local repo:
git config core.fileMode false
Backup Scenario (Server to Desktop):
The simplest scenario is if you are developing on a server, for instance, and merely want to grab a backup copy on your laptop. Assuming you have already setup and are using a git repository on your server, on your laptop navigate to the directory where you wish to place your backup copy. Then:
git clone ssh://email@example.com/path/to/git/repository/name/
This will create a "name" directory on your laptop, containing all the code and the git repository. If, in future, you wish to copy over changes from server to laptop, cd into directory "name" and initialize "git pull":
git pull ssh://server/path/to/git/repository/name/ HEAD
In the future, to bring the laptop up to date, all that is required is to cd to the "name" directory, and do:
(ie. git remembers the server and the path on the server.)
Development / Production Scenario (Desktop to Server):
Now suppose you are doing development work on your laptop, and the public, production copy of the code is located on a server. First, ssh into the server and prepare a "bare" repository:
git --bare init
Then edit the config file to enable reposharing by adding the line "sharedrepository = 1" under the [core] section. Now back to the laptop.
git remote add origin ssh://yourname@server/path/to/git/repository/name/
git push origin master
The final step should push your latest and greatest software from laptop to server.
Git is a program used for distributed Source Code Management (SCM) whose popularity is increasing rapidly. Git seems to be becoming the de facto standard among Debian people, for instance. The first link is to kernel.org, the home of the Linux kernel, because Git was originally created by Linus Torvalds for the Linux kernel development.
Install git command line tools (Debian and derivatives):
apt-get install git-core
(Note that there is a legacy "git" package which has nothing to do with "git" the SCM software....)
You only need to know a few simple command lines to get an astonishing amount of function out of git, and therefore git can be usefully applied to even simple scenarios like bug fixing someone else's software and submitting patches upstream. This last is the example I will work through and demonstrate here, while trying to be more verbose then  & .
First, download and unpack your source code. Then cd into the base directory of the source code, and initialize git by running the following:
This will create a .git subdirectory which will contain git's repository (starting point plus history of changes you make to the code). Now if you do
you will see a long list of "Untracked files", ie. the repository is currently empty. Lets add everything you just unpacked to the repository:
Note the "." after "git add". Its the "." that specifies "everything" under the current directory. "git commit" will prompt you for a commit message, just type "Initial commit" and exit the editor. If you check the status again with "git status" you should see zero untracked changes. Now type
and you will see the record of your initial commit. Now build your unmodified source code (Debian?) just to make sure there is nothing wrong with it.
After the build successfully completes, "git status" will show a long list of changes even though you made no change to the source. Time to introduce .gitignore. Create a (hidden) file called ".gitignore" in your source directory root, and place the following on the first line: "*.o". If you run "git status" again you will discover that all *.o (object files) have vanished from the listing. The object of using .gitignore is to get rid / not track all the build noise, and *.o files definitely qualify. I am going to submit patches upstream, so I am pretty sure the contents of the debian directory are not something I want to track, and have also added a "debian*" line to .gitignore.
Now "git add ." and "git commit" again to get a clean git slate before beginning to make source changes.
Make your first source changes ("git status" should list the changed files). Build, install, and test the software. Let's say this was a partial change that solves part of the problem, but not the whole problem. This probably qualifies for another commit. "git add" the changed files, then "git commit". You can make several change / test / commit iterations, so that "git log" provides a detailed account of what you did. If they do not conflict with other commits, any individual commit can also be backed out.
Should you ever mess up and want to restore your last commit:
should do the trick, and wipe out all changes since the last commit.
When it comes time to submit your patch upstream, git can also generate the patch for you:
will generate a diff between your very last commit, and the one that preceded it.