GitHowTo
This is a basic guide to learn about the use of GIT.
Github provides easy tutorials to install Git on your machine:
This will be a quick how to get used to git workflow commands.
First of all, register to GitHub
Then go to emesene/emesene and click on the “Fork” button.
Now you’ve got a YOURNAME/emesene repository.
You’ll see a link named “YOUR Clone Url”.
Copy that link, open a terminal and type:
git clone git@github.com:YOURNAME/emesene.gitGreat, now you have a directory called “emesene” with your project inside.
Now you’re ready to code. Suppose you want to implement the feature “foobar”.
Then type git checkout -b foobar, it will create a new branch called “foobar” and switch to it.
Now, just code and, when you think it is right:
1- Check the status of your changes: git status (This will show you the changes that you just made and will be sended)
2- Add the files that you want to commit: git add [file]
If you want, you can add al your recent changes using: git add .
3- Check again the status (if you want):git status (you will see the files that will be pushed)
4- Set the commit: git commit -m "YOUR MESSAGE"
In the commit message, follow this simple git convention: first line is long no more than 50 characters, with a short summary. If more explanation is needed you should leave a blank line, then enter your long description on 79-chars limiter lines.
Example:
This is a good commit.
It is good because it implements lot of long-wanted features, like foo and bar.
Furthermore, no lolcatz were killed when doing this.
5- Send the commit: git push
Now you have your recent files in your repo, now, just send a pull request and wait :D.
You should not push what is not needed. Doing git commit -a, instead, commits just everything. This, often, is bad.
You’d better use git add and, most of all, git add -p
-p stays for “patch”: it will ask, for each “block” of code which you could commit, if you really want to commit it.
It is very simple to use, and will make you more responsible about what you’re commiting.
If you want to make sure about what you’re commiting, use git diff --cached, it will display the ready-to-commit changes.
Also, I like to use git commit -v, which displays the diff as a comment, so that I can view it while writing the commit message.
Sometimes you committed something, but someone asks you to fix something, or you want to fix something yourself. Instead of making a new commit, you can also edit the previous commit(s).
git reset --soft HEAD^ (will reset the commit history to the previous commit. The —soft option makes sure the files don’t get reset too)
Then edit whatever you want to edit
git commit -a -v -c ORIG_HEAD (recommits with the same commit message. Because of the -v option, you can check if everything goes well)
If you do this after pushing, you’ll have to use git push -f next time you try to push.
You’ll want to stay in sync with the upstream master branch on emesene/emesene. The easiest way to do this is by adding it as an remote branch
git remote add upstream git://github.com/emesene/emesene.git (it’s just an alias)
Now, make sure you don’t have uncommitted changes! (git status is your friend)
git pull upstream master will merge the upstream repo into yours. If there are conflicts, solve it or git reset --hard
For a good guide on rebasing, I suggest you to read rebase chapter on ProGit
I suggest you to run gitk or gitk --all. The commit tree should be self-explainatory.
Also, if git log shows you any merge commits, this means that it isn’t properly synced with the upstream branch
rebase.
Just do (we’ll assume that “upstream” is your name for http://github.com/emesene/emesene repo)
git fetch upstream (fetch the latest changes from the upstream branch)
git rebase upstream/master (rebase upon the upstream branch)
Sometimes, if you have any merge commits in your branch, this won’t work. The best way to get rid of them is using git fetch upstream (this will fetch the latest changes of the upstream branch) and then do git reset --hard upstream/master. BE AWARE THAT THIS WILL THROW AWAY ALL YOUR CHANGES.
If you want to keep your changes, you can put them in a different branch first git branch branchname. Now you’ll have a branch with your committed changes backed up. It’s now safe to reset. If you want to pull the changes back to your master branch, you could use git cherry-pick branchname 1234567890abcdef1234567890abcdef12345678, where 1234567890abcdef1234567890abcdef12345678 is the commit you want in your master branch.
Sometimes your feature is not still complete, but you still want to make the world know about it.
git push origin foobar will upload the branch “foobar” to your GitHub repository.
You can view it at the URL https://github.com/YOURNAME/emesene/tree/foobar
So, you’ll have TWO branches on your GitHub repo: master and foobar.
When you go to https://github.com/YOURNAME/emesene it will display “master” by default, but you can browse to “foobar” easily.
When your work on that feature is finally done, you should merge the changes in the master branch:
git checkout master git merge foobar
If you behave like a good boy, it shouldn’t report conflicts and there shouldn’t be any merge commits. However, conflicts could happen. In this case you’d better cherry-pick the changes back into your master branch
git push origin master will upload the changes you just did to your GitHub master branch.
You could keep your foobar branch (if you like “feature-branch” development style, which I won’t discuss here), or you could delete it:
git push origin :foobar will remove foobar branch from GitHub
git branch -d foobar will remove the branch foobar from your local repo, too.