git log and git show and in particular two of my favourite existing tricks:In this case, I’m working with the second option, so I’m pushing to the upstream repo. I’m also pushing to a live repository as well, so I thought I’d outline the commands I’m using. The setup here is the main github repo, and I have my own fork of that, which is cloned onto my laptop. I can push to both that main repo, which I’ll call “upstream” (because the github documentation does and it makes sense!) and another repo that I’ll call “live”. All in all it looks something like this:
So here’s my problem.
We dont know deployment. We work from same copy on one test server through ftp and then upload live on FTP.We have some small projects and some big collaborative projects.
We host all these projects on our local shared computer which we call test server.
All guys take code from it and return it there. We show our work to clients on that machine and then upload that work to live ftp.Do you think this is a good scenario or do we make this machine a dev server and introduce a staging server for some projects as well?
I wrote him a reply with some suggestions (and my consulting rate) attached, and we had a little email exchange about some improvements that could fit in with the existing setup, both of the hardware and of the team skills. Then I started to think … he probably isn’t the only person who is wondering if there’s a better way. So here’s my advice, now with pictures! Continue reading
On Monday 19th March I’ll be speaking at PHP Leeds. The topic is all things git and github; as an open source project lead I see lots of very capable programmers taking their first steps with github. In this session we’ll talk about how you can use these tools to contribute to open source (or your own projects, of course), covering both “what to click in the web interface” and “what to type at the command line” for git and github respectively. Come along if you want to know more about git, open source, or github!I have the main repo cloned onto my local machine. Before I do anything, I fetch and merge from the origin and then push back to it, so I know my repo is in sync with the github one. Then I fetch the branch I want to merge – usually one that we’ve got a pull request for. To see what’s in the branch:
git log [branch] --not master
This is nice because it doesn’t show what’s in the master branch of this repo but missing from the incoming branch, it just shows me what’s new on this branch.
I can diff and merge at this point, but more than once I’ve merged and then wondered what changes I have in my repo that aren’t in the github one (this is where it is helpful to have fetched from the remote one first). I have the github repo mapped as “origin” as per the excellent documentation so I can just do:
git diff origin/master..HEAD
This shows me the differences that are in my current repo as compared to origin/master, which is the tip of the main repo shown at the version it was when I last fetched it. I particularly use this when I’ve merged someone’s changes in for testing and am wondering quite what was supposed to happen – sometimes just reading the diff beforehand isn’t enough, it’s only when I get the code merged I realise something unexpected is happening!
In fact, all I had to do was update my upstream remote on my local repo – I set this up following the excellent github forking instructions when I first forked the repo. All I did then was to check my remotes:
git remote
This showed my remotes with the “upstream” pointing to the old repo. So I copied the URL of the organization repo, removed the old version and added a new upstream:
git remote rm upstream
git remote add upstream git://github.com/joindin/joind.in.git
Everything now behaves as before while handling the new central repo for the project – hopefully this helps others with projects moving from user accounts to organizations (or organisations, as I keep typing, British spellings as always!)
This is the easy bit:
$ git branch
* api
master
$
The entry with the star next to it is the current branch, so here you can see that I have branches “master” and “api” and I’m currently working on the “api” branch. If you only have one branch it will usually be called “master”.
My experience is with Subversion until now, and branching is really different in git (because it actually has branches rather than just copies, this is definitely a feature, but it is a different approach from how I had used them before). So you can switch your working copy around to look at different branches, which threw me a bit to begin with. To change branches, just checkout the one you want:
$ git checkout master
Switched to branch 'master'
$
If you actually wanted a new branch simply name it and ask checkout to create it if it doesn’t exist, by using the -b switch:
$ git checkout -b demo
Switched to a new branch 'demo'
$
So now my branch command shows me this:
$ git branch
api
* demo
master
$
This is very much an optional step. Many of my branches are private branches – meaning that I branch on the development server, finish the feature at hand, and then merge the changes into my master branch without pushing the branch to anywhere else. To share changes with others though, I sometimes like to push my changes up to github – which is my “origin” remote on my repo. So to push the demo branch we just made, I would simply do:
$git push origin demo
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:lornajane/joind.in.git
* [new branch] demo -> demo
$
If you use “git push” on its own, it will push all branches which exist on both the local repo and the origin – but will not push any private branches unless you specify that it should.
The http://help.github.com site, Github’s own documentation, is actually brilliant and has really helped me to get up to speed with working with my own code and contributions from others.
* The only problem I’ve had with code on github recently is that I merged totally the wrong changeset into the main project root. Which really isn’t the fault of the source control system :)
Hope to see you there!