Yes really nice article. Far shorter and better than the one I’ve done for my friends :-).
But perhaps you could think on how to work on parallel branches that should never be merged again.
This is clearly a lack in DCVS today. There is no natural way on how to deal with that. Just an example:
Say I develop a website for customers. They all have a common part. But imagine one customer (A) need a really specific feature. And imagine one of my previous customer (B) want the same feature.
There is no easy way to just send the “patch” of this feature to the customer B. Even if I made a specific branch for this feature. Because I should have started the branch after the branch for A and B have diverged.
[bad ascii art]
time ---->
feature --------
A ------------------
C -------------------------------
B ------------------------
[end of bad ascii art]
if I merge “feature” in A I get many stuff of B which shouldn’t be push to A. Of course, If I had thinked twice before starting the feature branch from B but I started it from C, it wouldn’t be a problem.
I loved you article about branching. I’m curious to know if you can imagine a way to handle such a case.
[…] Aha! Moments When Learning Git March 10th 2010 12:12pm Git is a fast, flexible but challenging distributed version control system. Before jumping in: Understand regular version control Understand distributed version control Along with a book, tutorial and cheatsheet, here are the insights that helped git click. There’s a staging area! Git has a staging area. Git has a staging area!!! Yowza, did […] From: betterexplained.com […]
“GIT has a staging area” - This was exactly my Aha moment too. Had been digging GIT for a yr, totally confused. Then the Aha staging area moment. GITs a Beauty.
Yogsototh: Yes, there is a way to get what you want: it’s called cherry-picking.
Git is actually very good at dealing with the problem you describe. You can use “git rebase” to reorder or move changes around to make a feature branch (even ex post facto), and then merge that feature branch into all of the customer branches that want it.
Do not use ‘git branch’ in scripts. Use ‘git symbolic-ref HEAD’ or ‘git rev-parse --symbolic-full-name HEAD’ together with advanced variable substitution.
You list “git branch -a” under “remote data”, but it’s a local command using only local data. The data shows the results of the last fetch of remote data, but it’s a strictly local operation.
For me the most important git “aha” was understanding the difference between, say, “master”, “origin/master”, and the “master” that lived at “origin”. And then understanding the commands that examine and move changes between each of these.
Understanding those and understanding the staging area comprise almost all of the challenge for a new user coming from the Subversion world, in my experience.
[…] Aha! Moments When Learning Git | BetterExplained Git is a fast, flexible but challenging distributed version control system. (tags: git version control cheatsheet) […]
@Pete: Thanks – that’s a great point. Right now, intuitively, I see local master as my changes, origin/master as the last changes I’ve synced, and “master that lived at origin” as the very latest changes on the site. I wonder if I’m correct ;).
@Matthieu: Yeah, I contemplated putting in the -b shortcut but decided it was too much. Git has shortcuts for everything it seems! Sometimes it’s nice to know the atomic operations vs. the magic switches :).
I can only add to the guys above: Thank you for the ‘essence’ and ‘brevity’ You might like the book ‘Clean Code’ by Robert Martin, if you didn’t get the tip to that one already
You might like the book ‘Clean Code’ by Robert Martin, if you didn’t get the tip to that one already