|
BizarroAzrael posted:The master script, which calls all the other scripts to perform the update, is to be versioned as Update.bat.template, so users will need to cut off the ".template" and unversion it for it to work. Doing this for the other scripts seems impractical though, I don't want users having to muck around with them themselves. I thought about having them versioned as .templates as well, and having the master script rename them. Would it work to have the script rename them all by removing the .template? Then the update would restore the original .bat.template files which would be used next time the update runs. We did pretty much the same thing at the last place I was at, except putting it in a directory rather than renaming files from .template. It made things a bit easier since you had a working file if you were working with the source controlled version (especially useful because we had a series of files which referenced each other), and you could run the update script from any directory. Later on down the road our update got quite a bit more complex, so the .bat file ended up being a bit of a loader script that only updated the main updater tool and then executed it (by that point it was actually a winforms app). That was probably the least painful, as you didn't have the "double-update" whenever you updated the updater.
|
#
¿
Sep 11, 2009 14:28
|
|
|
|
| # ¿ May 7, 2024 17:54 |
|
|
Git flow is absolutely amazing and I can't imagine developing without it. It basically wraps up every best practice you should be following with git into an easy-to-understand syntax. Even if you're just working on something yourself and don't really need deployment branches and all that jazz, just working with "feature start" and "feature finish" feels a lot more natural and less repetitive than working directly with git.
|
|
#
¿
Jun 22, 2011 04:21
|
|
|
Mithaldu posted:The finish bit seems pretty meh. It seems much more useful to rebase the feature branch onto master, dealing with conflicts step by step and then merging it into master with --no-ff so there's still an explicit record of it being a feature branch. Maybe I'm not following, but you should be rebasing your main branch into your feature branches every so often and before the finish anyway, so by the time you actually merge your feature into development with finish, you shouldn't really have many conflicts to deal with anyway. I can see the point about --no-ff, but it's not personally a concern for me. If you're talking about running a rebase when you're on master with your feature branch, that would blow up like crazy if you have more than one developer.
|
|
#
¿
Jun 22, 2011 21:16
|
|
|
I was confused if you were saying "git rebase master" from the feature branch (which yeah) or "git rebase feature" from the master branch (which gently caress no). Rebasing master into your feature branch with git flow is 100% something you should be doing and git flow doesn't impact or prevent that at all. In regards to --no-ff, yeah, I honestly don't give a poo poo if the feature ceases to exist when I'm done with it, but that's just me.
|
|
#
¿
Jun 23, 2011 11:51
|
|
|
Another awesome option for bug tracking / continuous integration is Jira + Bamboo. It isn't free, but for less than 10 people it's a $10 one-time fee for each (you might want to bump it up to $30 and get a Greenhopper license as well since it's amazing and makes Jira a billion times better.) Jira is almost certainly overkill for a 2 man team, but it's still dead simple to use, and it will scale to pretty much any workflow you could possibly want. Bamboo is optimized towards building Java projects out of the box, but I didn't find it too difficult to get Rails projects building on it. As an added plus, Atlassian (the company who makes all this stuff) owns Bitbucket, so the integration between Jira / Bamboo and Bitbucket is pretty awesome.
|
|
#
¿
Nov 23, 2011 15:38
|
|
|
Rebasing generally isn't going to do a lot to avoid when conflicts happen though. Depending on when commits occurred, you may get lucky, but it certainly doesn't mean you'll never need to deal with them. nexus, one thing to keep in mind when working on branches that persist for longer than a day or so is that it's possible, and even recommended, to pull in changes from master periodically when you're working on your branch. If you do this, you'll reduce the odds of hitting conflicts when you have a huge amount of changes in your branch that need to be merged with a huge amount of changes in the master branch. I would personally start off each morning by running (from your branch): code:Now, there's still a possibility that you're going to have merge errors (you almost certainly will at some point, at the end of the day no SCM is going to get around 2 people editing the same line of code). To see what's going on when you get a merge error, run git status. The list at the very bottom is the list of files you need to resolve. Once you've opened those, and resolved the conflict, just git add them and commit when all of your files are merged successfully.
|
|
#
¿
Feb 2, 2012 13:40
|
|
|
I think it's totally reasonable to review a branches changes before you merge - we do that with another developer literally every time we pull anything into our mainline branch. git diff master..branch_name will give you all the commits. If you want something prettier than text output, I'd imagine all of the graphical tools have some sort of diff available. Better yet, if you're on GitHub, you can use pull requests to get a great diff view before merging, and even add comments for things to fix before you pull it into your mainline.
|
|
#
¿
Mar 5, 2012 03:32
|
|
|
By the way, I just downloaded SourceTree, and I wanted to say it's a pretty awesome repository browser. I still like to do most of my actual commits on the command line, but to get a visual of what's going on, or a nice pretty diff, it's pretty awesome.
|
|
#
¿
Mar 6, 2012 04:59
|
|
|
Mithaldu posted:Bullshit, that's not your dev being stupid. That's your devops being stupid and deploying from master instead of a dedicated release branch. Depending on your setup, there's nothing wrong with pushing from master. GitHub does it, for instance. We do it as well, but our "master" is less of a typical mainline, and more of a deployment branch. The only branch that ever gets merged into master is development or a hotfix branch we branched from master. Nothing gets to master unless all tests pass on development, and our staging server always has the current state of the development environment. The second something gets on master, it gets pushed to production. It works fine for us, and branching off release branches would add a lot of complexity for literally zero benefit. enki42 fucked around with this message at 13:17 on Mar 8, 2012 |
|
#
¿
Mar 8, 2012 13:10
|
|
|
Also, this doesn't exactly answer your question, ufarn, but one thing that we use to ensure that we aren't pushing unwanted changes to master, and just as a good way to review your code, is require that all changes to master are sent up as a pull request to GitHub. If you guys are using that, the diff view on a pull request really is excellent, and it lets you interactively add comments on certain line numbers and other nice things like that.
|
|
#
¿
Mar 15, 2012 16:11
|
|
|
Mr. Crow posted:This was my original thought on the process but it seemed to... simple. I dunno. Like I had to be missing something. Good to know it's effective! The main difference with "github-flow" vs. "git flow" is that github does deployments more or less immediately after something is checked into the main branch. If you can do this (and REALLY do this - i.e. your time from checking into master to deploy is less than a couple of hours and fully automated), then git flow adds a lot of ceremony you don't need. If you do have something like manual QA tests, scheduled releases, or anything else that prevents continous deployment, you will get burned by using the github style of doing things. At the end of the day, there's not really an objectively "good" branching model - just ones that are better and worse fits for your workflow.
|
|
#
¿
Mar 6, 2013 11:57
|
|
|
Volmarias posted:That sounds neat. Does it have explorer integration? If it's anything like the mac version, no, it's pretty self contained, and much more useful as a commit browser than a tree browser, if that makes any sense (I don't even think there's a way to view the file structure at a particular commit). It's a great tool even if you do use the command line pretty heavily though - I personally never use it to commit, but it's great for quick code reviews when I don't want to bother with a pull request, or being able to browse around the commit history and checkout a particular rev or something.
|
|
#
¿
Mar 20, 2013 02:23
|
|
|
Strong Sauce posted:So I have developed a feature, "A" off the "dev" branch. Let's say I make a PR for A and while it's being reviewed dev gets other commits/merges into it. You don't really need to do anything with a 'C' branch. It helps to think of this kind of stuff if you remember that you don't really branch off a branch, but off a commit. Your 'B' branch isn't really branched off 'A', it's branched off a specific commit on the 'A' branch at the point that you branched it. So once the pull request is accepted and 'A' is on dev, the ancestor commit is on dev, and 'B' is already branched off of dev in a sense.
|
|
#
¿
Apr 18, 2013 12:06
|
|
|
|
| # ¿ May 7, 2024 17:54 |
|
|
I'm a git user who probably wouldn't switch if given the option (although I've been meaning to checkout mercurial), but the Git CLI is unforgivably horrible for UX even if you otherwise have no problem with the command line.
enki42 fucked around with this message at 14:24 on Feb 28, 2014 |
|
#
¿
Feb 28, 2014 14:19
|
|