I started my Django project locally and have been using git just fine.
I got ahead of myself and copied the code to the server which instantly became out of sync with my local version. I hadn't done a branch or anything.
The two part question is what's the best structure for me to work locally, push/pull to test server and then update live server when test is solid, and how do I get it setup from where I'm at?
I've been developing with no branches in these early stages, but I'd like to instead follow standard practices for branching and merging.
I'm using NetBeans 6.8 locally for coding and I've also got GitX. So any integration tips would be helpful also but I'm comfortable doing whatever command lines are necessary.
Thanks!
James
First you should be able to have some form of communication between the git repositories you've got on your local machine, the test server and the live server. Git is very flexible in this regard so a few of the options are:
Have the test and live server pull
from your local repository.
From development push to the test and live servers on appropriate times.
From development push to production and have the test server pull from production.
Have a fourth location where you'll store your git repo and push from development to that repository and have test and live pull from there.
Either way, once you reach a stage where you'll want to try something on the test server, create a tag. On the test server checkout that tag (git checkout <tagname>) and do your testing. (And once you are satisfied that it works the way you want, you can also use that tag on production. But I guess that's pretty obvious. :) )
The intermediate step, between creating the tag and checking it out, completely depends on your setup. Using the fourth option I just mentioned you'll need to push your tag first and fetch it on the testing machine. So the whole process would look similar to this.
<development>$ git tag v1.0
<development>$ git push
<development>$ git push --tags
<testing>$ git fetch --tags
<testing>$ git checkout v1.0
<live>$ git fetch --tags
<live>$ git checkout v1.0
Optionally you can (ab)use git decribe to check which tag you've got checked out at currently.
Regarding the branching and merging: what I like to do is create a branch for every feature I'm working on. Once I complete that feature I merge it back to master. So If I need to release before a feature is done, I can just leave that feature (and every releated) commit out of the release.
But this is just one way of doing it. You can setup the workflow to suit your situation. Especially regarding the use of branches. A more complex setup is described by Vincent Driessen in his article A successful Git branching model.
Disclaimer: I'm using git almost exclusively with one authoritative repo on a server (the fourth option). I haven't personally tried the other setups I suggested...
Update to respond to the comment by iJames:
To make dev push to and test pull from a new/different repository by default from now on, see the accepted answer of this question:
$ git branch --set-upstream master origin/master
With regards to the terminology:
Push is relatively simple: it pushes your local commits to a different repository. See for instance the Git User's Manual.
Fetching does the opposite, it "will update all of the remote-tracking branches to the latest version found in the repository". (Quote from the Git User's Manual.)
The pull command not only fetches the changes in, but also merges them into the current branch. (See the example in the official Git tutorial.)
Related
I'm using the code from a github repo for my project, and have been trying to understand some of the dev history about a problem I'm having. However, I'm unable to list the commits from one particular developer. Usually, you will see a link option to list all the commits, on the page of any one commit of any given author. But for this one dev only, that link isn't there. Github docs say this could be due to that author no longer having a github account, but that isn't the case here. Also, I can manually append a commits?author=username to the URL, but that doesn't work either. The only way I can see the commits is to load the network graph, scroll the timeline, and mouse-over each commit dot one at a time. It is a difficult way to scan through dozens of commits.
This is best done locally. Clone the repo and then use log or shortlog:
git log --author=author#email.com
or
git shortlog --author=author#email.com
gitk also supports the --author option to filter commits by author.
I currently use the lovely Github Pages to host a website. I would now like to try out some stuff, adding content, new scripts, ... So I have a dev branch in which I do this, and run a local webserver to test it. Once I'm happy with it I can push it to the gh-pages branch for 'release'.
However, I was now wondering. Is it possible to have the dev branch also be reachable anywhere just like the gh-pages branch? This would be very helpful in letting other people try out the new stuff I'm working on without having to risk releasing buggy code to everyone. So basically two gh-pages sites in one repo, one for release one for development.
Is this (or something similar) possible with Github?
So going carefully through the github pages documentation seeking for any solution using the offered functionalty it seems what you are looking for might have been nice but is not available, maybe the closest thing is to have two repositories for example username.github.io/production and another one that is forking it like username.github.io/development and working on it while pushing changes back to the production one using pull requests or any technique you would prefer
And if you like you can check out my post and see some techniques of altering your websites, as well jekyll has a _drafts directory which allows staging of a post and seeing it before being posted.
I think any branch can be reached via rawgit.com.
For example, if your user/organization is XYZ, you can reach the dev branch for your user/organization jekyll site at:
http://rawgit.com/XYZ/XYZ.github.io/dev/_site/index.html
Just don't include _site in .gitignore. You still have to build the site locally with jekyll build, so it's still not a perfect solution.
E.g., on the GDB Buildbot instance http://gdb-build.sergiodj.net, I want to check the builds for git commit 68b975af7ef47a9d28f21f4c93431f35777a5109 , Git tag binutils-2_25, which happened in Dec 2014 to compare with my local results.
Is that possible?
Things which complicate that feature:
there may be multiple builds per commit, e.g. different platforms. OK, give me a list of all of them.
some commits don't have builds.
That buildbot seems configured to run only every few commits to save CPU.
In that case, I would like to see the nearest built parent on my search result.
There has also been some discussion for this on Google Groups for Chromium, but I couldn't find a good solution: https://groups.google.com/a/chromium.org/forum/#!topic/infra-dev/T_7S9HXLWlo
I have also opened a feature request at: http://trac.buildbot.net/ticket/3320
For GDB in particular, I know about the gdb-testers mailing list https://sourceware.org/ml/gdb-testers/ , which seems to get daily automated emails from Buildbot. I'm not very satisfied with it because there is not one email per build (there is more than one daily build), but searching that list is a possible workaround.
Besides the automated email results, GDB maintainers have also set up one Git repository per test environment that contains one commit for every build under a cgit web interface at http://gdb-build.sergiodj.net/cgit
For example, for Debian x86_64, you can clone it with:
git clone http://gdb-build.sergiodj.net/git/Debian-x86_64-m64/.git
Each commit contains the gdb.sum and gdb.log, which are the main outputs of DejaGnu's tests.
Note however that those repositories are pretty big, 350M currently, and take a long time to clone.
The Buildbot configuration for the Git and email outputs seems to be on the personal Git server of the responsible developer: http://git.sergiodj.net/?p=gdb-buildbot.git;a=summary as mentioned on the ml announcement: https://sourceware.org/ml/gdb/2015-01/msg00043.html
I am working with a client that demands multi-stage server setup: development server, stage server and production/live server.
Stage should be as stable as it can be to test all those new features we develop at the development server and take this to the live server in the end.
We use git and github for version controlling. I use Ubuntu server edition as the OS.
The problem is, I have never working in such multi-stage server plan. What software/projects would you recommend to do a proper way of handling such setup, especially deployment and moving a new feature developed to the stage and then to the live server ?
We use two different methods of moving code from environment to environment. The first is to use branches and triggers with our source control system (mercurial in our case, though you can do the same thing with git). The other, is to use fabric, a python library for executing shell code across a number of servers.
Using source control, you can have several main branches, like production development staging. Say you want to move a new feature into staging. I'll explain in terms of mercurial, but you can port the commands over to git and it should be fine.
hg update staging
hg merge my-new-feature
hg commit -m 'my-new-feature > staging'
hg push
You then have your remote source control server push to all of your web servers using a trigger. A trigger on each web server will then do an update and reload the web server.
To move from staging to production, it's just as easy.
hg update production
hg merge staging
hg commit -m 'staging > production'
hg push
It's not the nicest method of deployment, and it makes rolling back quite hard. But it's quick and easy to set up, and still a lot better than manually deploying each change to each server.
I won't go through fabric, as it can get quite involved. You should read their documentation so you understand what it is capable of. There are plenty of tutorials around for fabric and django. I highly recommend the fabric route as it gives you lots more control, and only involves writing some python.
There is a nice branching model for git (as it is also used by github itself for example). You can easily apply this branching model using git-flow, which is a git extension that enables you to apply some high level repository operations that fit into this model. There's also a nice blogpost about this.
I do not know what exactly you want to automize in your deployment workflow, but if you apply the model mentioned above, most of the correct version handling is done by git.
To add some further automatic processing to this, fabric is a simple but great tool, and you will find many tutorials about its usage (also in combination with git).
For handling python dependencies using virtualenv and pip is for sure a very good way to go.
If you need something more complex,eg. to handle more than one django instance on one machine and for handling system wide dependencies etc checkout puppet or chef.
Try Gondor.io or Ep.io, they both make it pretty easy (gondor especially excels in this area) to have two+ instances with very similar code, from your VCS -- and to move data back and forth. (if you need an invite, ask either in IRC, but if I recall, they're both open now)
After my first question, id like to have a confirmation about the best git workflow in my case.
I have a single django project, hosted at github, and differents clones with each his own branch : customerA, customerB, demo... (think websites)
Branches share the same core but have differents data and settings (these are in gitignore)
When i work on CustomerA branch, how should i replicate some bug corrections to the other deployments ?
When i create a new general feature, i create a special branch, then merge it into my master. Then, to deploy on the 'clients', i merge the master branch into the customer branch. Is it the right way ? or should i rebase ?
# from customerA branch
git fetch origin master
git merge origin master
Also, i have created a remote branch for each customer so i can backup the customers branches to github.
It looks a very classic problem but i guess i dont use git the right way
Thanks.
Ju.
I would have a single project repo at a well-known place containing a master branch with the common code, and branches for specific deployments (e.g. customer/A customer/B demo).
Then I would have checkouts from each of these branches for each customer, for the demo server, and so on. You can let these pull automatically from their respective branch with a commit hook on the single project repo.
Every developer would have their local copy of the project repo, do local work, and then push stuff back to the single project repo.
The challenge will be to maintain the branches diverging from master and doing the regular merges so the diversion do not grow over time.
I have seen this solution describe somewhere in much more detail somewhere on the web, but I could not find it quickly again. Some blog post on using git for a staging and production web server, IIRC.
If the three sites share some 'core' code (such as a Django app) you should factor that core out into its own repo and use git submodules to include it in the other projects, rather than duplicating it.
I would have a repo called project-master or something like that and a repo for each client. Then, when you have code you need to be available to those client repos, you pull from the project-master to that repo.
Don't separate the projects in branches, separate them into different repositories.
Make the "common" code generic enough so that costumerA's copy of the common code is exactly the same as costumerB's copy of the common code.
Then, you don't have to pull or merge anything. When you update the common code, both costumerA and costumerB will get the update automagically (because they use the same common code).
By "common" code: I'm referring to the package/series-of-apps that power the websites you're developing.
I'm assuming costumerA and costumerB repositories would only include things like site-specific settings and templates.
The key here is making the "common" code generic: don't let costumerA use a "slightly modified version" of the "common" code.
Also, I'd suggest using a deployment mechanism that doesn't rely on git. git is a great source code management tool; but it's not designed (AFAIK) to be a deployment tool.