The difference between git pull, git fetch and git clone (and git rebase)
Update: So, over a year later and I’ve had some feedback from a colleague (thanks Ben!). Nothing here is drastically wrong, but some clarifications should help!
When I started out with git …
… who am I kidding, I’m still a git n00b. Today, I tweeted about git. I wanted to know what the differene between pull, fetch and clone is. After discovering that, really, 140 characters isn’t enough to answer the questions, I had a play around.
Git Pull
From what I understand, git pull will pull down from a remote whatever you ask (so, whatever trunk you’re asking for) and instantly merge it into the branch you’re in when you make the request. Pull is a high-level request that runs ‘fetch’ then a ‘merge’ by default, or a rebase with ‘–rebase’. You could do without it, it’s just a convenience.
%> git checkout localBranch %> git pull origin master %> git branch master * localBranch
The above will merge the remote “master” branch into the local “localBranch”.
Git fetch
Fetch is similar to pull, except it won’t do any merging.
%> git checkout localBranch %> git fetch origin remoteBranch %> git branch master * localBranch remoteBranch
So, the fetch will have pulled down the remoteBranch and put it into a local branch called “remoteBranch”. creates a local copy of a remote branch which you shouldn’t manipulate directly; instead create a proper local branch and work on that. ‘git checkout’ has a confusing feature though. If you ‘checkout’ a local copy of a remote branch, it creates a local copy and sets up a merge to it by default.
Git clone
Git clone will clone a repo int a newly created directory. It’s useful for when you’re setting up your local doodah
%> cd newfolder %> git clone git@github.com:whatever/something.git %> git branch * master remoteBranch
Git clone additionally creates a remote called ‘origin’ for the repo cloned from, sets up a local branch based on the remote’s active branch (generally master), and creates remote-tracking branches for all the branches in the repo
Git rebase
Finally, git rebase is pretty cool. Anything you’ve changed by committing to your current branch but are no in the upstream are saved to a temporary area, so your branch is the same as it was before you started your changes, IE, clean. It then grabs the latest version of the branch from the remote If you do ‘git pull –rebase’, git will pull down the remote changes, rewind your local branch, then replays all your changes over the top of your current branch one by one, until you’re all up to date. Awesome huh?
Finally..
If you get stuck, run ‘git branch -a’ and it will show you exactly what’s going on with your branches. You can see which are remotes and which are local. This is a good headsup before you start to break things! It’s worth remembering that git branches are basically just a pointer, so to be able to work with those commits you need a local branch which points to somewhere from which those commits are reachable.
Thanks to Ben for the extra stuff, clarifications and calling me an idiot when I get git wrong, because I am, as it’s really pretty simple, except for the simple.
Like this:
macupgrades.co.uk: a whole jar of awesomesauce
Not my harddrive - Image by Robert Scoble @ Flickr
I recently purchased a new hard drive for my aging Mac from www.macupgrades.co.uk. Storing everything on my NAS so I have more space on my mac is a pain-in-the-ass, so I decided to get a larger capacity drive so I can store everything locally as well. I placed an order on the Tuesday and paid for the courier delivery as I needed the drive before the weekend.
On the Wednesday I recieved an email stating that the drive had been shipped and would be with me on Friday – awesome. I was very excited, I nearly bought a macchiato to celebrate.
Anyway, the next day, I received an email stating there had been a problem and that the drive hadn’t shipped so wouldn’t be with me until the following Monday. I was pretty pissed off about that, so I emailed www.macupgrades.co.uk and said, I thought the item was in stock and would be delivered by Friday, if I’d known there would be a problem, I’d have ordered another item.
I also asked if I could be refunded the difference between the Courier and Royal Mail delivery as paying for the courier delivery wouldn’t have got me the item on time. I was amazed to recieve this response:
I’m sorry there has been a delay with your item. This was due a collection
issue with our courier company.
We can as a gesture of goodwill offer you the Seagate Momentus 7200 RPM
500GB drive for you at the same price – delivery for Friday.
Or we can progress with the Scorpio for delivery Monday with the difference
on the courier refunded.
Please let us know.
Best Regards
Gavin
Awesomesauce! A better harddrive (I only ordered a 5400) and delivery the next day! Well, I asked if they could send me a drive, any drive, by Friday and lo, when I arrived at work this morning, it was waiting for me. A pre-9am delivery no less.
So, thank you macupgrades.co.uk, your customer service is second to none and I will be a customer for life now.
Scrummaster? We don’t need no steenking Scrummaster!
A Sad Face by Emmaline
I discovered something strange today. I recently left one development team to go work for another (that’s for a seperate blog post all together) and I was chatting to some old team members today who had just had their Scrum Sprint Review/Retrospective and they mentioned one of the things that had come out of the Retrospective was that they aren’t going to have a Scrum Master for this sprint, or, it seems, any sprint.
“Huzzah!” I hear you cheer! “They must be self-managing!”
No, no they are not. It’s far, far worse than that. They’ve decided they don’t need a scrum master as, in their experience, the scrum master is useless. With no power to help the team make decisions and one team member describing the Scrum Master as “a puppet of the business”, then it’s quite clear that scrum, at this company, is broken.
It’s a sad day for me as ever since I heard about scrum about two and a half years ago from a colleague (@garethholt), I realised it’s potential. I’ve tried hard, arguing the point with colleagues, management and everyone who’ll listen. We’ve tried different length sprints, staggered sprints, digital backlogs, analogue backlogs, all sorts. Inspected and adapted and now it’s all for nowt. At every turn, the business said “No, I’m not confident enough to try scrum properly.” or, more accurately, “I don’t want to surface the organisational dysfunction.”. The team realises that the business cannot let go of the reigns.
It’s all about trust.
They all seem like the wind has been taken from their sails and it’s sad and dissapointing. Especially as they have an ‘Agile Manager’ and a ‘Product Owner’ who is also a director. Even the people employed to support scrum don’t seem to have confidence in it. Now THAT is a problem.
I might go home and cry.
Is my time more valuable than your time?
A Warlock
As anyone who has ever done sprint planning will tell you; estimating the time a task will take to complete can sometimes be a risky, confusing and sometimes arrogant or embarassing business.
Unless you have absolute equilibrium in your team, ie everyone is at the same level and can perform at the same pace, you’ll often come across situations where a developer will say:
“That will take 3 ideal hours!” and sit, smug in the knowledge that they can do that task in 8 hours (or more, generally. Don’t forget Boyle’s law).
“Um, ” says a small voice, “I think it would take 6 hours.” The new team member, green as the grass on the other side, but sharp as a tack pipes up. “I don’t know how to attach the hoo-hah to the wot-not, I’d need to research that.”
“It’s easy!” says smug developer, “You simply wangle the wand at the warlock and insert the key of truth.”
“OK, ” retorts the green guy, “Didn’t I read in the out-of-date wiki entry that there is three factor authentication on the key of truth? I’d need to read up on that before I started the task.”
“Pah”, says smug developer, “Then I should do it.”
and thus fails scrum. Allocating tasks during planning is, sometimes, a neccessary evil, especially if you’re up against an arbitrary deadline as we often are. However, if you do find yourself having the luxury of being able to swarm on stories, or pick any task from the board, then you should and you should usually pick one you have no idea how to do. This’ll give you a chance to do some on-the-job learning from your peers and mentors. Consider this though:
“It’ll take me six hours, but I’ll have it done by the end of the day tomorrow, ” says green developer, “I don’t have any other responsibilities at the moment”.
“Ah, yes, ” says old man smug, “I am the scrum master (yes, yes, quiet down – sometimes you DO need to do both) and I need to the new business team with some issues and also I have to record some training screen casts, so I won’t be able to have it done for another three days, even if I started it now!”
So, as you can see, it’s all swings and round abouts. The rules (or guidelines) I’ve heard many times state to go for the higher figure. With a dash of common sense obviously, if it’s more than double the amount of the lowest figure, then you’ve got other problems. Always err on the side of caution I say, but that’s up to you.
Why is this important? You need to be consistent with the blocks of time/effort/whatever you estimate with. Ideal hours seems the best way to go about it, but don’t, whatever you do, start referring to six ideal hours as a “day” it’ll just confuse the issue. Six ideal hours is just that. It might take one day, or it might take six. However long it takes in real time, make sure your estimates in ideal times are as accurate as they can be. It’ll help in the long run as you’ll get better at estimating, better it getting it right sprint after sprint and it’ll help you eliminate the waste. Time holes that suck away your resourced hours will be highlighted because by the end of the sprint, you’ll not have “spent” the ideal hours, yet you’ve pissed away a two week iteration. But at least it will show you where your problems lie.
Does the daily standup provide value?
Our team sits in a horse-shoe shape where I work. Some people on the inside and some on the outside. There are no partitions, no borders and people only really put their headphones on when they REALLY want to get in the zone. Communication is key to having an effective scrum team and in this shape, totally co-located (even the DB team are in the horse-shoe and they’re not even part of the scrum team!) means communications is but a chair twhirl or a lean over the desk away.
So, with this much communication going on, is the daily stand up still worth it? Does it provide enough value for the team over and above that value currently being sucked from rich communication throughout the day anyway? It seems to be that the only people who might benefit from the standup, then, are the chickens, who really don’t listen to what we’re saying as they don’t understand it and are just there to wait until the end when they get a chance to say their piece.
Usually, not particularly interesting or worthy.
None-the-less, the stand up does provide a moment of the day at which you can see everyone’s trousers and shoes and feel like a “team”, a group of people all striving for the same goal and not a disparate set of developers hunkered behind a screen waiting for the end of the day.So, then, is the standup merely an ideal? Something that is important only for what it IS and not what it does or provides in the way of value? Perhaps, but I don’t mind either way, either options provides some benefit and some is better than none. Also, I like to look at shoes.
IS EVERYONE AWAKE?
Try this in your standup tomorrow;
Wait until it’s your turn to offer yesterday/today/blockers, the make something up. See if anyone notices. If they do, then you appear to be doing scrum properly as your team are interested in what you have to say. If no-one bats an eyelid, then you’ve got a problem. The standup is an information radiator, some way of telling your team and anyone else who is interested, exactly what it is you’re doing. If what you’re doing is dull, then spice it up a bit. If it’s the same thing as you were doing yesterday and probably the same thing as you’re doing tomorrow, then try and be a bit more detailed – what EXACTLY did you do.
If people are genuinely not interested, then perhaps you’ve structured your team wrong. Really, you should all be working round the same kind of area, so if people aren’t interested because it’s not something they do, or will do, then it sounds like you may not be swarming and your developers are siloed. If that’s the case, then shake things up, because you’re not doing scrum!
4 comments