Git Cheat Sheet
luisbg.blogalia.com
luisbg.blogalia.com
http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html
In nice printable format with a sort of "state diagram" for commits (workspace <-> index <-> local commit <-> remote commit)
`git pull --rebase` is a much better conceptual way to integrate changes from your upstream when working together collaboratively. The rationale is this: a newly released change should be, in the ideal case, simply an incremental diff against the head of the branch. It may have been developed by forking off at some point in the past, and incorporating changes over time, but those are implementation details of how the diff has been constructed. Once the diff is ready to go, ready to be committed, it's just an incremental change to the head.
By working in a branch and using `git pull --rebase` to incorporate upstream changes, you keep your code in a constant state of being "an incremental addition" to the primary branch. Indeed, it's very similar to what happens with Perforce when one runs `p4 sync ...`, by comparison - your local code is updated to account for the new remote contents. Finally when you submit, your change looks like a single incremental commit, or series of commits. The resulting history is simple and linear.
Sometimes people object to this because they claim that source history should be the "true history of what happened", whatever that means. I believe those arguments miss the point of source history. Source code history is always an abstraction over what really happened. Imagine an extreme example: an IDE that generates a single source commit for every keypress you type while editing a file. That's the true history of what really happened. But is it useful to commit that history to a repository? Of course not - that history is kept locally in your IDE as undo buffer. Similarly, it's often not useful to pollute the commit history with implementation details of how you developed the change (sometimes, but not often).
When you develop changes locally and push them upstream, you rightfully make a judgment call about what level of detail about the development process should be exposed in the history, and what level of detail should be hidden. For example, you might hide detail by combining many keypresses into one commit, as is conventional, or by squashing multiple related commits into a single commit. You might hide the detail about how your change was developed over time by using rebase to make it appear as if it's an incremental change to the head, even if it was developed over time and involved several integrations from the upstream. Sometimes these history-abstracting changes are not appropriate, such as if you truly need to develop a branch in parallel with the main branch, that many people are collaborating on. In that case, a branch may be appropriate. Most of the time, it's ideal to develop changes directly on the master branch, as an incremental change to it, using `git pull --rebase` to keep local changes up to date, which will result in a simple, linear history.
I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.
Learning and adopting Git was definitely worth it for me and organizations I've worked with. It provides advantages that are difficult to describe in words and best experienced first hand [1]. Once you understand it, it's like a swiss army knife, or a power tool capable of manipulating source code commits any way one desires. The user experience might not be simple, but the semantics are simple in a way that makes operations easy to perform in Git that are challenging in other source control systems.
You can probably take better advantage of source control than checking in on a monthly basis. Personally, I recommend checking in about every 30 minutes to folks I work with. However, we're used to quick release cycles where code might reach production hours after we submit it, not years. I personally favor frequent commits also because it acts as an additional layer of protection against data loss, as well as facilitating frequent code reviews and visibility by coworkers, frequent integration testing, etc. These benefits support developing code as a team, and support a quick release process.
If you'd like to learn Git, then I'd recommend integrating it into your daily habits such that you're committing regularly, perhaps every 30 minutes to an hour. It will be difficult to learn the tool effectively if you use it only once per month.
[1] I'm happy to try if anyone wishes, but there are plenty of arguments out there. I would summarize by saying that Git simply works better than anything else I've used, including CVS, Subversion, Perforce, etc. Upon familiarizing myself with Git, it feels like those tools, through lack of capability, create a lot of problems and friction that Git avoids.
1 - Clone the repo (only need do this once)
2 - git checkout branchname
3 - Make some file changes
4 - git add filenames
5 - git commit
6 - git pull (make sure you are up to date BEFORE you push to remote repo)
7 - Build and TEST
8 - git push
That's 90% of what I do.
Merging branches is simple.
1 - git checkout destinationBranch
2 - git pull
3 - git merge sourceBranch
4 - build and test
5 - git push
Cheers!
The main point is to make your commits small and incremental, with a single commit adding a single feature (or fixing a bug, etc). If you are reading the commit log, there shouldn't be any surprises as to what a particular commit actually changes when applied. If you have a lot of uncommitted changes, remember that you don't have to add them all at once -- use 'git add file1 file2' and make descriptive messages for each change. Also remember that you can 'rebase --interactive' to fix up your commits locally if you want (don't rebase shared/pushed history, though).
git add .
Add all modified files to be commited
One I use from time to time is git add -p (-p stands for patch) , useful if you have a large set of changes, you keep forgetting to commit incrementally upfront, and you want to split your changes into one or more commits.
git checkout -b BRANCH_NAME will create a new branch locally.
Also, if you have time, look at pre-commit hook for your project :-) tired of running your favorite test harness plugin for your project manually or waiting for your Jenkins server to get the job?
Last, is git fetch vs git pull still a debate? I always use git fetch because that seems to be most preferable, fetch then rebase is the right path, most clean way to merge changes with some upstream / branch.
https://docs.google.com/presentation/d/1t8grwHN0SB7HGgD9Jv9g...
"git stash branch <branchname>"
like "git stash" it stashes away all the untracked modifications you have, but it puts them onto another branch. i often end up making partial progress on things that should be conceptually in different branches at once - this way, you can stash unrelated changes into different branches, and then merge each branch as you finish.