I know that this question has been asked in many different forms, but I have yet to see the configuration that I want, so I'm throwing this out there.
What I want:
1. 2 clones of the master, so each has its own entire version of the project, so that one subdomain goes to his current work, and the other to mine so that we can both see the changes that we commit and push to the remote server in our respective remote clones.
We both have own local versions of our remote folders/clones.
Essentially we both have our own branches, that neither of us are ever committing to the master branch. My personal branch can be considered the master in this case, because I want him to be able to make his changes, me be able to see and test them on his subdomain, and them merge them into my own.
I also want him to be able to pull my latest commits to the remote server into his own remote clone, and then subsequently onto his local machine so he always has my latest code.
What are the best practices for this? As of now this is what we have been doing and it has been a huge hassle and makes me hate git.
I make changes locally, commit them, and then push to my remote folder of the same branch.
He merges his local folder/branch with the remote commits that I made.
Any commits hes made locally he then commits to his remote branch/subdomain. (This should mean that his remote branch also includes my changes that he merged since his remote folder should be an exact replica of his local machine)
Upon inspection and testing I say a feature is complete, and I then merge into my local branch/folder
I push to my remote branch/folder and everything is available to see on my domain.
Is this not the correct way of doing things? Any suggestions or advice greatly appreciated!
The essentials are that we each have our own branches, and can make additional branches for features and merge them into our own. And also that we each have exact replica copies of our local machines on the server in different folders that are pointed to by the webserver via subdomains so both can be viewed at the same time in different states.
I apologize in advance for the length of this, I just wanted to be as clear as possible.
What you've written is not extensible - add a third developer, and then what do you do?
Instead, have the following branches:
master (always clean, use only for deployment to production server)
staging (always clean)
acceptance (messy)
You create new branches from staging:
git checkout staging
git pull
git checkout -b feature/JF_my_new_feature_20141018
(use a unique set of initials so you know who wrote the branch, and datestamp the branch as well.)
When you're satisfied with your branch (and your tests run fine), you merge into acceptance and run tests there. When your coworkers (or your QA team, or whoever), have verified that the branch is good, you merge it into staging.
Everybody always creates new branches from staging, and nobody merges into staging without a thumbs-up from someone else.
Related
in the software company I work we use jenkins to deploy to different servers, the way we do that is ever single branch from git repository deploy to the specific server based on the name of the branch and in the specifications on the jenkinsfile. But we are in the process of unification of this branchs in just one: Master, but how we can configure jenkins to catch the same code and deploy to the servers we are interested in, without changing the code? I think we should separate code from deploy, but the pipeline still have to exist in some way.
2 solutions come to mind:
I believe you may be using SCM polling to get the builds started. With git diff you can check what was changed and based on that start the specific deployment.
If you are running the builds manually you can parameterize the build and specify this way which one you want to deploy.
From experience you might want to set the pipeline so when you commit to the repository only testing and building is done and deploy is not done (or only on a test env) and the proper prod deploy is done only manually (and can be parameterized).
We are using Jenkins,GerritTrigger setup for CI and it will start build for each commit though all commits came from single push. Since all changes are dependent on each other its enough to make a single build with all changes, but I don't see that option in GerritTrigger plugin.
I believe many companies use Jenkins and Gerrit combination and I am curious to know how they are handling these cases.
Example:
If a developer pushes below 4 commits at once to gerrit it will create 4 changes accordingly in gerrit say 1,2,3,4 and it starts 4 builds in jenkins for all commit
git log --oneline
e3dfdwd CommitD
5fgfdgh CommitC
df34dsf CommitB
a23sdr3 CommitA
Here 4 commits as a whole will pass all tests in jenkins but individually they will fail. Now jenkins builds will fail for A, B, C and will succeed for D as it will checkout A,B,C as they are its dependencies.
In this case though Commit-D is successful it can't be merged as its dependencies are not passed in Jenkins.
It seems reasonable from development to expect jenkins verification for each push instead of each commit. But GerritTrigger can run for each commit only.
Question:
Is there a way to inform jenkins to start build only for commit-D as it will have all dependencies C,B,A ??
Or can we start a build for each git push from development instead of commits?
Sorry if I had any info
I found a way to start build only for commit-D.
I have introduced a gerrittrigger job which runs immediately after every commit, this job will not do any clone/build/verification.
It will just do some set of verifications like, check if given change has needed-by change, dependency exists and dependencies on same branch etc
This job will trigger another main job which does real clone, checkout change, build, verification etc only for changes which pass all validations.
So this will start job always for top commit and approve/reject all dependent changes based on job result.
Though it has few limitations, we found this method is suitable for our workflow
Most companies don't use git and gerrit :) Most companies don't even use git, unfortunately. And most of the ones that do, don't use gerrit. I've consulted for dozens of companies: two use git, and neither of them have even heard of gerrit.
I don't think it's possible to get gerrit to think of pushes as if they were commits. Since each commit in a push can be separately reviewed and rejected, each commit has to be considered and built separately. If you don't want it to work that way, gerrit might not be for you.
Instead, you should squash your related commits locally before pushing them to gerrit. This will achieve the desired results.
I have a Rails app deployed on Heroku and I have a git repo that I'm currently working on with uncommitted code changes. In the meantime, I need to make changes to the source on Heroku independently of the local repo. Can I do the following:
Clone the Heroku git repo on the same development machine with a different app name though with the same account
Make changes to the new local repo
Commit those changes to the new local repo
Push those changes to the Heroku repo
Resume working on my original local repo
Will this approach work?
Yep, that workflow would work, or stash them - and don't forget if you do make a clone of the heroku repo you'll have made changes to a different clone of the repo and you'll need to make those changes in your original local repo.
In future I'd suggest that you assume that your 'master' branch is what's live on Heroku and branch of that to work in - you can even push this branch into a new app for testing purposes. This way bug fixes can be performed on your local master branch (or another branch and merged into master) and pushed to heroku and then when you've finished your new work you merge the branch back into master and deploy that to your live environment. I wrote a blog article on the subject a while back, here
I haven't used heroku but if I wanted to make changes to a deployed application while I had unsaved changes in my sandbox, I would do one of the following.
stash my local changes, cut a branch from the point where I want to make a fix, make it, deploy it, switch back to my original branch and pop from the stash.
Commit my unsaved changes (into the current branch - say work), cut a branch from the point where I want to make a fix, make my fix, deploy it, switch back to work, reset my HEAD to before my "temporary" commit and resume work.
Unless you're using git in an unconventional fashion, there's no need to make another clone.
If you clone the heroku repository to a separate directory, made changes and push it from there, then there is a possibility of conflicts later down the road.
If its only the issue with the uncommitted changes then certainly you can stash them using "git stash" and later retrieve it using "git stash pop".
My work-cycle: I always keep a master branch with the #1 rule "always push to Heroku after committing something to master". If I code on something that I do not want to deploy immediately, I have to branch.
I know this works not for all use cases, but having always a branch that is identical to the app that is productive on Heroku makes me sleep better ;)
I'm still figuring GitHub and Heroku out, so please bear with me. :)
I've a web app on, say, xyz.com. What I am doing now is to make some code/UI changes on some files, commit those files, push them to the master branch, and then refreshing the url to see these changes.
I think this is obviously the wrong approach, but I don't know of how else to test changes done to my code without having to push them on to the master branch. How could I do so?
I don't quite understand the situation in the full version of your question (see my comment and, as icc asks, why can't you test locally?), but to answer the question in the title, you can see the differences between your master and the version on GitHub by running:
git fetch github
git diff github/master master
(That's assuming that the remote that refers to your GitHub repository is called github - it might well be origin in your case. You can see all your remotes with git remote -v.)
To explain that a little further, when you run git fetch github, git will update all your so-called "remote-tracking branches" - in most cases those are the ones that look like origin/whatever, github/experiment, etc. Those are like a cache of the state of those branches, and they're only updated when you run git fetch or successfully git push to that branch on the remote repository. So, once you've done this to make sure that github/master is a recent snapshot of that branch on GitHub, you can happily compare it with your local master branch using git diff.
First: You don't push to the master branch, you push to a remote repo. You should probably read up on your git.
Second: This is not a good workflow, first you should commit your changes and then test them locally. When you are done testing you are ready to push your commits to a remote repo.
This is primarily a question about effective Git usage. I should first say I'm not an expert in Rails (at least in a production sense) and definitely a Git newbie, however, I have had some experience using SVN.
My problem is that I am trying to create a rails application but do not know the best way to keep development local on my computer but be able to deploy to my shared hosting account on Dreamhost.
I figured that Git would allow me to do this, but I am not completely sure how. I was thinking of creating a Git repo on the server and having my local stuff pushed onto it after each commit. I have read a few tutorials on Git, but am still confused on what to do. The alternative to this would be to just use FTP and copy over the files but that doesn't seem right.
Does anybody have a few first steps and/or commands that I can use? Is this deployment method fishy or is there a better way to do this?
I run a Rails website for a brass band in Wisconsin in a very similar setup to what you're describing, though it currently operates out of hostingrails.com. I host my code on github, though there's no reason you couldn't host it privately. My flow has evolved over the last year and a half, so take from this only what you need in the short term.
At the center of my flow, I have set up a semi-elaborate Capistrano script to handle the deployment, including a separate staging environment that makes a whole copy of the production database for testing. This took a while (hours, not days) to build, but it has been so worth it.
My workflow keeps at least 2 branches:
current_release: Live production code. Emergency bugfixes are made here.
master: Finished features ready for release. These features wait here to be tested live. Emergency bugfixes are merged in from current_release.
<feature_name>: Features under development. I try not to have more than 3 of these outstanding at any given time. Emergency bugfixes are merged in, and master is frequently merged in to keep the feature current.
Having this setup allows me to work on several things concurrently. Week-to-week (as this is nowhere near a full-time occupation), I do the following:
I edit in feature branches. I switch back and forth, get bored, get excited, whatever. Sometimes I merge two features that grow together.
[edit]
$ git commit
$ git push github [feature]
Finished features ready for iminent deployment are merged one-at-a-time to the master branch.
$ git checkout master
$ git merge [feature]
[fix immediate problems or inconsistencies]
$ git commit
$ git push github master
$ git branch -d [feature]
I stage the website to a private URL (happens to be stage.madisonbrass.com). The staging environment always pulls from the master branch.
$ cap staging deploy # master is now live at stage.madisonbrass.com
Bam, while I'm testing, I find an emergency bug on the public website. Fortunately, I have current_release working separately, and thus can separately fix and deploy it.
$ git checkout current_release
[fix bug]
$ git commit
$ git push github current_release
$ cap production deploy
I return to the master branch, and start by merging the emergency fix.
$ git checkout master
$ git merge current_release
I continue testing master. Hopefully no new issues appear, but if they do I fix them in master, I merge these changes into current_release and do another production deployment.
$ git checkout current_release
$ git merge master
$ git push github current_release
$ cap production deploy
I tear down my staging environment, lest it somehow get indexed by a search engine.
$ git staging teardown
What I do is have a shared, bare Git repository (created with git init --shared --bare) which is the "master" repository and is where I push my work. A bare repository does not have a working directory. For my web directory, I clone the master repository so it has a working directory and all the files are there. From there, I git pull any new work that I've committed.
I always do development work on a separate machine with a clone of the repository and a test development environment. When I've finished a feature, I push it up to the master and then log in to the production server and pull it to the working directory there.
This is just me for not-terribly-important projects. One could extend this with many more steps and checks and balances for Important Work.
I'd recommend using GitHub and keep your Dreamhost resources as free as you can to run your Rails app (in fact, depending on your project, I'll need as much as it can have to coup with it, being a shared hosting).
My usual workflow involves having a development environment and a GitHub account. We use Capistrano (which is fairly simple to learn and understand) to manage the push to GitHub, and then the respective deployment to the hosting, in your case Dreamhost, through SSH/SCP.
That way, you won't have to worry about what it's actually on your production repository, neither having to do maintenance tasks on it. Works pretty fast too and can easily be adapted for when you decide to change hostings o servers.