|
nexus6 posted:It sound simple in theory until I have made about sixteen commits, pull and everything breaks so I have to create a new clean branch and cherry-pick every single commit. Merge early, merge often.
|
#
¿
Apr 5, 2012 15:43
|
|
|
|
| # ¿ May 10, 2024 01:24 |
|
|
Flobbster posted:I guess my main workflow issue is this: We've been using CVS through Eclipse (since we mainly do Java development), and Eclipse's built-in CVS support is really nice. It doesn't matter how much work my teammate does since my last checkout, if he's checked in a bunch of changes and I have a bunch of pending changes as well, it's super easy for me to synchronize with the repo, view all the changes, commit my non-conflicting ones, check out his non-conflicting ones, and then interactively merge where conflicts exist and then commit those back. I read this until I get to "I merge my UNCOMMITTED changes with ..." which makes me cry. Flobbster posted:We've tried using our old workflow with git/eGit (remote on Github), and while eGit is nice it definitely doesn't feel as mature as the CVS support. It's been a clusterfuck a couple times when we both had changes to the same resources, which made me think that git's distributed model might encourage a different/better workflow for this. Workflow for a DCVS system is: -I do something. -Some other guy does something. -Other guy commits, pulls (but there's nothing to pull), and pushes. -I commit. -I pull the other guy's changes. -I merge. If my merge fails because of whatever, I can just throw everything away and retry the merge. Nothing is ever lost because I have already committed. This step can be retried as much as you like. If there's a lot of commits you have to merge with, you could also merge in steps. But I've never needed to. -I commit the merge, pull again (because the merge has taken some time), and push. If a merge is trivial, the DCVS tool should do almost everything automatically. If the merge isn't trivial, you need some brains and a good merge tool. What merge tool you use doesn't really depend on the source control system you use. The biggest advantage to a DCVS, to me, is that you commit first, and only then merge. A merge can be retried as much as you like, because everybody's changes have already been committed and are safe. There is no such thing as 'pending changes'.
|
|
#
¿
Apr 5, 2012 17:10
|
|
|
Physical posted:I didn't think there was a debate. I use git extensions (it gives context menus AND integrates into Visual Studio), and older git gui (MYSgit I think) and also the Team plugin for eclipse. You're right, there was no debate because it was pretty clear that Git on Windows was a pretty crappy experience. (And I personally think Hg is better anyway, so whatever.)
|
|
#
¿
May 21, 2012 21:40
|
|
|
Is VS2012 really out yet? Or is it only people with expensive MSDN subscriptions or whatever.
|
|
#
¿
Aug 21, 2012 17:04
|
|
|
So other guy merges your changes while he hasn't commited his own changes yet? That is so horrible. What if he fucks up the merge? Then he just lost his own changes. First commit, then merge. (And commit the merge, obv.)
|
|
#
¿
Jan 21, 2013 22:43
|
|
|
"Oh no, my history reflects what's actually happened, woe is me!"
|
|
#
¿
May 20, 2013 22:07
|
|
|
Question about branching and configuration: I have 2 named branches in HG: default and maintenance. Normal mainline development is happening in default, bugfixes on the currently released version happen in the maintenance branch. Because there can (and will) be database difference in both environments, I'll need different database and different configurations. So I'll need a different configuration in each branch. Problem is that when I merge between them, the differences have a tendency to be merged away. (Which is logical since that's what a merge is.) So either the maintenance or the default config will be overwritten. I have tried to just use a different solution configuration in Visual Studio, with config transformations. This works for running the application (I just need to switch the active configuration in VS, that's easy), but my integration tests that I run with NCrunch insist on only using the default or an explicitly set configuration. So for the tests I'll still need to have some configuration file somewhere that's different in each branch. Anyway, TL/DR: what would be a good strategy to maintain a different configuration in 2 branches that survives merging in both directions?
|
|
#
¿
Jun 7, 2013 10:08
|
|
|
Yeah, I didn't see any way out of putting the config in some file somewhere and versioning it. I have separate configs for app and test anyway, that's not the problem. (Tests are in different projects.) The problem is having separate configs for different branches. I added an explicit setting for the maintenance branch now, only for the test projects. That is a fairly easy setting to maintain so I think it'll work.
|
|
#
¿
Jun 8, 2013 16:49
|
|
|
My workflow (with hg) is this: (Sidenote: we have 4 environments: Dev (local development), Test (in-company testing), QA (client testing), en Production.) Stuff gets done on the default branch. At some point, I want to release something to the test environment. I make sure my local copy is on the changeset where I want to release, and I run my deployment tool. It calls msbuild a bunch of times to create installation files and everything. I also use a numbering scheme for sql scripts and my deployment tool runs the necessary scripts as well. It's pretty neat. Anyway, afterwards it tags the changeset as 'Test'. When I've tested everything in the Test environment, I run the deployment tool again. It retrieves the changeset tagged as 'Test' to a folder (not my development folder because I don't want to have to clean it when I want to move from Test to QA), and it runs the whole deployment cycle again, building and running scripts and moving everything to QA. Afterwards the 'Test' changeset gets tagged as 'QA'. When the clients have tested everything in QA (or when they haven't and I want to deploy anyway), I run the deployment tool again, and this time it deploys everything to Production. Afterwards, the 'QA' changeset gets tagged as 'Release'. (Of course, when a bug is found in Test or QA, I don't have to keep moving along on the release track, I can start again from Dev once I've fixed the bug.) So, I use the tags as a way to track what version is deployed where, and, crucially, for my deployment tool to know what it has to release. Deployment is as simple as pushing a button. Then, bugfixes: Obviously, it's possible that bugs are discovered in the production version of the program. But development has most likely been going on, and most of the time the bleeding edge version is not ready for release. So it's not possible to fix the bug on the bleeding edge version and release that. We have to go back to the released version, fix the bug there, and release that. And that's exactly what happens: I go back to the release version (conveniently tagged with the 'Release' tag), and fix the bug. I commit the fix, but this time not on the 'default' branch, but on a named branch called 'maintenance'. (For hg there's no functional difference between named and unnamed branches, it's just nice to be able to see if a commit was on the default branch or in maintenance.) And then I just run the deployment tool again. The changeset with the fix gets deployed to Test and tagged as Test, deployed to QA and tagged as QA, and deployed to production and tagged as Release. Afterwards, I switch back to the default branch, and merge the bugfix into it. Done! TL/DR: source control system is used to track releases, but not as a deployment tool. The deployment tool uses source control to gather what it needs and afterwards tags the changeset it used. I think it's a great system and so should you.
|
|
#
¿
Jun 11, 2013 20:03
|
|
|
My deployment tool is just a program I wrote myself. It can execute programs (used for msbuild and command-line HG commands), and copy files from one location to the other. The main advantage is one-click deployment of just about anything. (Once you set it up right.) Because having to do that manually is tedious and error-prone.
|
|
#
¿
Jun 12, 2013 11:15
|
|
|
I guess the first thing I'd do is use Git, and then look into the Git equivalent of Hg's MQ.
|
|
#
¿
Jun 25, 2013 10:27
|
|
|
Guys, guys, the answer is obviously hg. Much better than git on Windows machines.
|
|
#
¿
Nov 7, 2013 20:18
|
|
|
Then again, with a distributed system there's nothing to go down. If all else fails you can still bundle changesets and put them on a USB drive.
|
|
#
¿
Nov 8, 2013 17:36
|
|
|
I set up the HG server at work. Extra work after it was set up: none whatsoever. Disk space used: extremely low. And that's with 400+ repositories on it. The only thing that worries me is that I forgot how to set it up and that the HG installation is getting out of date.
|
|
#
¿
Nov 9, 2013 09:40
|
|
|
aerique posted:Well, that's the whole point the previous poster was making. Also what if the server croaks with a deadline looming? Is it backed up off-site and is that your job / responsibility? True. Backups are made, but not my job. Also since it's distributed, backups are on people's PC's anyway.
|
|
#
¿
Nov 9, 2013 10:45
|
|
|
We do commits in feature branches, and when a feature is done someone else reviews the work + merges it into default.
|
|
#
¿
Feb 16, 2016 17:38
|
|
|
Hi, I have a question about Git. What does the 'x behind' mean in this screenshot? Is it a problem I should get rid of? If it helps, I'm coming from having a lot of experience with Mercurial, and basically none with Git.
|
|
#
¿
May 3, 2016 09:58
|
|
|
When I try to pull, I have to choose the remote branch to pull. I choose master, and it pulls the new commits if there are any, but then the 'x' just increases. (It's 8 currently.)
|
|
#
¿
May 3, 2016 10:14
|
|
|
Ok that did something interesting. Now I have this:
|
|
#
¿
May 3, 2016 10:30
|
|
|
I guess that's all normal then? What does the little light blue ball mean right before the 'master' and 'origin/master'? And for that matter, what do those mean exactly? I think 'master' is supposed to be the master branch, right? If I remember correctly, Git branches are pointers to something, and the master branch pointer is pointing to that last commit? What's the origin/master thing then?
|
|
#
¿
May 3, 2016 11:04
|
|
|
nielsm posted:"master" is the name of the default branch in git. "origin/master" refers to the "master" branch on the remote named "origin", which is the default name for the remote you get when you clone a repository. Ok cool. And what's the little empty blue ball icon thing?
|
|
#
¿
May 3, 2016 17:17
|
|
|
SourceTree. There's a screenshot a few posts up.
|
|
#
¿
May 3, 2016 18:54
|
|
|
Is there some way in Git to just checkout the latest commit, skipping over all the intermediate ones? I had some coworkers commit things with paths beyond the maximum Windows path length, and now I can't get to the latest version, which doesn't have those files anymore.
|
|
#
¿
May 11, 2016 13:45
|
|
|
|
| # ¿ May 10, 2024 01:24 |
|
|
apseudonym posted:Git does not destroy commits, you have to work really hard to lose data. This is a big reason git rocks. Oh, cool. apseudonym posted:Eventually git gc will go through and get rid of commits that aren't referenced anymore. So with 'work really hard' you actually mean 'just do nothing for a few days'.
|
|
#
¿
Jul 29, 2016 00:13
|
|