|
hey, here is my dumb post in yospos about this but to paraphrase, i have 3 branches of a web project that are wildly different. my client has wanted to hold back tonnes and tonnes of work.now they want just a few features pushed to the master/live branch. i've been doing this pretty well for a while, but this time there's at least 25 commits to cherry-pick and 70 insertions. and so much has changed in the architecture of the app that i'll probably have to go find a dozen more changes that those commits depend on. i'll have to go and carefully choose every insertion and if i get just one thing wrong then the whole thing won't work and i'll have to start over, or do a bunch of hot fixes. it also doesn't help that we have no active users on the site so all the overhead and precaution seems useless and we should really just push all our features live since it's locked behind a beta key system anyway. my question is, am i a big whiny baby and this is just normal developer job stuff, or is this like impossible?
|
#
?
May 24, 2015 18:38
|
|
|
|
| # ? May 23, 2024 21:01 |
|
|
Thermopyle posted:I'm completely unfamiliar with SVN, but an application I use distributes itself via SVN (lol). svn revert file1 file2
|
|
#
?
May 24, 2015 18:49
|
|
|
PleasureKevin posted:hey, here is my dumb post in yospos about this This is common when there's a big problem in project management. You're not going to be able to unfuck the situation as it currently stands, but you can unfuck it in the future in a few different ways: 1) Keep every individual feature isolated in its own branch until it's ready to be released. Basically, every time you start on a new feature, branch it. When the feature is done, tested, and ready to be released, only then should it be merged back to trunk. Keep in mind that the merges will be nightmarishly painful unless you frequently merge any changes that are happening in your trunk back to your dev branches and resolve conflicts/retest functionality. 2) Branch for each feature, but the second the feature is done and potentially ready for QA/release, merge it to trunk. Keep features isolated behind feature flags (in a config file, database, whatever) so that you can toggle the feature on and off as necessary. When the feature is on in production and everything is fine and you know you'll never want to toggle it off again, remove the feature toggle in code and clean it up so your code doesn't turn into a rat's nest of feature toggle checks over time. This can lead to improved overall application health because you're constantly testing the codebase as a whole, instead of hoping that when you merge features X, Y, and Z into trunk, they actually don't break each other. A feature that you finish today and then sit on for 6 months is a lot more likely to be horribly broken or difficult to merge. #2 is the more "continuous delivery"-y way of doing things, although it takes a high level of discipline and a lot of automation to pull it off in the real world. New Yorp New Yorp fucked around with this message at 19:33 on May 24, 2015 |
|
#
?
May 24, 2015 19:29
|
|
|
thanks. this is actually what i was doing at first. but being the only developer, i found making and merging all the branches too much wasted overhead. each feature is of course in it's own commit (or sometimes a commit plus another commit to fix something later). is doing that and using git cherry-pick any different from merging branches? i've always tried to do what you're saying otherwise, pressured my client to push features out as soon as possible, but they won't, for whatever reason. but anyway, my main question isn't really answered. is it possible to do what my client wants? as in merge some features that are 100 commits ahead of master? should i push back more on this or just bite the bullet?
|
|
#
?
May 24, 2015 20:00
|
|
|
PleasureKevin posted:thanks. this is actually what i was doing at first. but being the only developer, i found making and merging all the branches too much wasted overhead. each feature is of course in it's own commit (or sometimes a commit plus another commit to fix something later). is doing that and using git cherry-pick any different from merging branches? merge everything then use feature flags to turn off the parts your client doesn't want live yet
|
|
#
?
May 25, 2015 00:24
|
|
|
the talent deficit posted:merge everything then use feature flags to turn off the parts your client doesn't want live yet thanks, did not know what those were until now. so then obviously they aren't in my app currently. i'll look into building those in from now on. however, still wondering about my original question.
|
|
#
?
May 25, 2015 19:26
|
|
|
PleasureKevin posted:however, still wondering about my original question. Your original question was answered: What you're encountering is common in badly run projects, it's a surmountable problem, but given your current state you're stuck just doing a lot of lovely merges.
|
|
#
?
May 25, 2015 19:48
|
|
|
PleasureKevin posted:thanks, did not know what those were until now. so then obviously they aren't in my app currently. i'll look into building those in from now on. this was my answer to your original question. presumably your branch applies relatively cleanly to the current production branch? merge the whole thing then go in and selectively turn off the parts your client doesn't want in yet. obviously if your new features replace parts of the app the client wants to keep live for now you'll have to figure out how to resurrect those parts but the rest of the features your client doesn't want you should be able to turn off fairly easily. you'll have to add a bunch of conditionals all over the place but it's probably easier and safer than trying to selectively extract a subset of features from a large number of commits
|
|
#
?
May 26, 2015 07:59
|
|
|
Current job has me doing TFS. Git spoiled me. Push something, poo poo breaks. Whatever, I say, roll it back! Still broken. Surely it was broken before, and I just rolled back to another broken state? If this happens, how do I undo the merges but not my changes so I can shelf my work and fix the build? edit: apparently the tfs server is dying! Can you use the TFS project tracking and metric stuff and use the git integration with VS, or do you have to stick to tfs for source control when using the work item tracking thing? I'm so done with TFS. Space Whale fucked around with this message at 15:30 on May 26, 2015 |
|
#
?
May 26, 2015 14:31
|
|
|
Space Whale posted:Current job has me doing TFS. Git spoiled me. You can make a team project that uses Git for scm and use all the normal work tracking and build stuff seamlessly. Build 2015 will let you build from external Git as well.
|
|
#
?
May 26, 2015 17:21
|
|
|
Space Whale posted:Current job has me doing TFS. Git spoiled me. I use Git-Tfs bridge to give me a local git repo that I can push into our TFSVC. Beats having to use shelvesets and other stuff to swap between work.
|
|
#
?
May 26, 2015 18:18
|
|
|
Ithaqua posted:You can make a team project that uses Git for scm and use all the normal work tracking and build stuff seamlessly. Build 2015 will let you build from external Git as well. I'm pushing hard for this right now, especially after we had to end up rebooting TFS itself and having a several hour hellmerge death march over this. Thanks!
|
|
#
?
May 26, 2015 20:06
|
|
|
What is the proper/normal method of adding a new branch to a git repository controlled by gerrit? Some of us wanted to work on a topic branch together, and did not even necessarily care for code review until our work has settled. Edit: It looks like we have some internal shenanigans for doing this, but I still wonder how grown-ups do this in case we're doing goofy stuff like usual. Rocko Bonaparte fucked around with this message at 21:58 on Jun 5, 2015 |
|
#
?
Jun 5, 2015 20:23
|
|
|
I should avoid committing my compiled .css, right? That seems to be the common wisdom. However, that leaves me confused as to how to actually deploy my CSS then. I'm using Beanstalk for Git deployment, which makes things very automated. If I keep my css out of my repo, will I need to manually transfer the .css files every time I deploy? Seems to defeat the purpose of Beanstalk's automation. Is there a better solution?
|
|
#
?
Jun 9, 2015 17:25
|
|
|
caiman posted:I should avoid committing my compiled .css, right? That seems to be the common wisdom. caiman posted:However, that leaves me confused as to how to actually deploy my CSS then.
|
|
#
?
Jun 9, 2015 17:48
|
|
|
That's about what I've been suspecting I should do. But the part that I can't quite get my head around is this:ExcessBLarg! posted:...checkout master, merge develop, run the compiler, add and commit the new compiled code... When I merge develop (in which .css files are included in .gitignore) into master (.css files NOT included in .gitignore), won't master's version of .gitignore get changed to look like develop's (with .css being ignored)?
|
|
#
?
Jun 9, 2015 18:30
|
|
|
caiman posted:When I merge develop (in which .css files are included in .gitignore) into master (.css files NOT included in .gitignore), won't master's version of .gitignore get changed to look like develop's (with .css being ignored)? So, assuming that .gitignore is already correct on the two branches (master has no .css files listed, develop does), then what you want to do the first time you merge is to run: code:
|
|
#
?
Jun 9, 2015 18:56
|
|
|
Perfect! Thanks.
|
|
#
?
Jun 9, 2015 19:16
|
|
|
Another git merge related question. I was hoping someone could explain why merging one branch into another essentially adds TWO commits into the current branch - the merge commit, as well as a copy of the latest commit of the branch being merged. I know there's a completely reasonable explanation, I just can't seem to find one. Is this just a part of the "recursive" strategy?
|
|
#
?
Jun 10, 2015 15:16
|
|
|
It's not just two commits. When you merge branches, you're adding all commits from the other branch, since the last common ancestor of the two branches, into the revision history. The purpose of the merge commit itself is to "glue" the two histories together by specifying two parent commits and encoding the resolved state of merge conflicts. Git is a bit misleading because "git log" shows a linear history by default, but it's actually a graph structure which you can see with "git log --graph". For the default (linear) presentation, "git log" orders commits on all merged branches by their commit time. So if you make one commit on a branch and immediately merge that branch, then yes, you'll see two commits at the top of the revision history.
|
|
#
?
Jun 10, 2015 15:27
|
|
|
caiman posted:Another git merge related question. I was hoping someone could explain why merging one branch into another essentially adds TWO commits into the current branch - the merge commit, as well as a copy of the latest commit of the branch being merged. I know there's a completely reasonable explanation, I just can't seem to find one. Is this just a part of the "recursive" strategy? It's not a copy. The merge commit has two parent commits, one from the branch being merged into and one from the branch being merged from; the same commit is thus referenced from both branches. It doesn't copy-paste changes from one branch to the other a la 'svn merge' (there's a separate command for that, cherry-pick), but actually ties together the two lines of history. Fire up 'gitk --all' (or 'git log --oneline --graph --decorate --all' for a terminal version) and you can see this pretty clearly.
|
|
#
?
Jun 10, 2015 15:30
|
|
|
Thanks guys, that's the reasonable explanation I was looking for. Regarding the output of 'git log --graph --decorate --all', is there a good resource that might help me learn to decipher what I'm seeing? It's very pretty, but I can' t make heads or tails out of it.
|
|
#
?
Jun 10, 2015 15:43
|
|
|
caiman posted:Thanks guys, that's the reasonable explanation I was looking for. The far left line is the branch you are on, all of the forking "branches" are just that: branches (demarcated by merge commits). The reason you can have multiple lines is multiple branches created at different points off the base tree. Oh, and each * is an actual commit, the dashed lines are just visual so you can follow.
|
|
#
?
Jun 10, 2015 16:23
|
|
|
caiman posted:Thanks guys, that's the reasonable explanation I was looking for. What Necrotic said; in addition, if you use the gitk command instead, you can then click on individual commits and it'll show you more information about them, which can be handy for exploring.
|
|
#
?
Jun 10, 2015 17:25
|
|
|
caiman posted:If I keep my css out of my repo, will I need to manually transfer the .css files every time I deploy? Seems to defeat the purpose of Beanstalk's automation. Is there a better solution? The best way is to get grunt out on the server then have a "build production" config that compiles stuff for production. Compiled artifacts never hit any repo.
|
|
#
?
Jun 10, 2015 18:51
|
|
|
caiman posted:Thanks guys, that's the reasonable explanation I was looking for. http://think-like-a-git.net/ Instant enlightment. Then create an alias for this: git log --decorate --oneline --color --all --graph
|
|
#
?
Jun 10, 2015 19:03
|
|
|
o.m. 94 posted:http://think-like-a-git.net/ Good read, thanks.
|
|
#
?
Jun 10, 2015 20:22
|
|
|
I had an interview earlier today at a place that uses https://sourcegear.com/vault/ It's a small team but they write software that basically runs factories and I was momentarily taken aback when the dev I talked to described it as "a better version of VSS" because that's such a low bar to clear that it doesn't seem worth mentioning. I mean, he could have just said "it's like VSS but it works" and I'd be less worried but, yeah, I'm a little worried. Should I be more than a little worried?
|
|
#
?
Jun 11, 2015 06:02
|
|
|
I had some run ins with it back in the day -- it is definitely archaic but the description of "vss that works" is pretty accurate and it is certainly better than nothing and was a valid technical decision at the time most likely. That said, I'd be a bit worried why they haven't re-visited the decision, it is a red flag there is lots of other archaic poo poo there. Like VB6 or something.
|
|
#
?
Jun 11, 2015 06:18
|
|
|
They did mention that they're currently on a push to clear out archaic poo poo from their production environment, but their ethos struck me a very pragmatic so, if Vault works, I'm guessing they'll just want to keep using it. Hmm
|
|
#
?
Jun 11, 2015 07:00
|
|
|
Ask about their other processes and technologies and see if you want to work in an environment that might've been apropos 10 or 20 years ago.
|
|
#
?
Jun 12, 2015 00:21
|
|
|
comedyblissoption posted:Ask about their other processes and technologies and see if you want to work in an environment that might've been apropos 10 or 20 years ago. If they're doing embedded work for factory equipment I don't think they're webscale
|
|
#
?
Jun 12, 2015 14:31
|
|
|
I did ask all my normal interview questions and that was the only red-flaggy thing that came up. They switched to it from VSS years ago and just don't care to change it because I guess it works for them. If you guys told me that it was basically ClearCase but for MS shops I'd be actually worried but it sounds like it's not a total horror, so I'm still hoping for an offer.
|
|
#
?
Jun 12, 2015 15:00
|
|
|
I can't decide if I should use master as a stable/release branch with a long running develop branch running in parallel, or use master as the development branch with a long running stable branch running in parallel. Only actual difference I suppose is whether you want a development or stable branch to be your "default". edit: using git. space kobold fucked around with this message at 17:26 on Jun 16, 2015 |
|
#
?
Jun 16, 2015 17:23
|
|
|
space kobold posted:I can't decide if I should use master as a stable/release branch with a long running develop branch running in parallel, or use master as the development branch with a long running stable branch running in parallel. A lot of folks seem to blindly advocate the latter (master as release, development on separate branch), but I think the answer varies depending on the purpose of the repository. Who are the primary users of the repository? If the primary users are developers, then it makes sense to do development on the master branch, and maintain a separate stable branch. If the primary users are end users, then it might be more appropriate to develop on a separate branch and push stable changes to master. Our repositories (which are used primarily by developers) are set up as follows:
Once changes in demo have been approved by management, we create a release tag (in the form r20150615), and they are applied to staging and production. edit: khant tipe or spel. edit 2: brevity MrPablo fucked around with this message at 18:49 on Jun 16, 2015 |
|
#
?
Jun 16, 2015 18:41
|
|
|
We use master as our "deployed on production" branch, but as you mentioned, it doesn't really matter. The branch names are just for humans; Git don't care. It always seemed to make more sense to me to have feature branches spawning off development than master. As a follow-up question for others: This setup basically means we are deploying off of development, since we only do the development->master merge once the code is in prod and the CI server has already built the release version from dev. Anything obvious I'm missing here that would make this better?
|
|
#
?
Jun 16, 2015 22:12
|
|
|
We use git-flow at work and I like it:
|
|
#
?
Jun 16, 2015 22:41
|
|
|
I'm a Git novice at best. I use SourceTree to get by right now. I have an old wiki with pages that use a proprietary versioning system. I would like to export, version-by-version, to a Git-based repository. It's easy enough to hack something together to get the job done, but I also want to preserve the original timestamps. My question is, how can I "forge" my commit timestamps to match the change history from my old wiki? I Google'd something similar, but do not understand Git well enough to make sense of the results, particularly the interplay between various timestamps.
|
|
#
?
Jun 18, 2015 15:39
|
|
|
Kobayashi posted:I'm a Git novice at best. I use SourceTree to get by right now. I have an old wiki with pages that use a proprietary versioning system. I would like to export, version-by-version, to a Git-based repository. It's easy enough to hack something together to get the job done, but I also want to preserve the original timestamps. My question is, how can I "forge" my commit timestamps to match the change history from my old wiki? Assuming you're running git from a command-line you can pass --date=$timestamp to the git commit command when you commit each revision.
|
|
#
?
Jun 18, 2015 19:34
|
|
only
|
|
| # ? May 23, 2024 21:01 |
|
|
Kobayashi posted:I Google'd something similar, but do not understand Git well enough to make sense of the results, particularly the interplay between various timestamps. This is where my knowledge gets fluffy, but basically the timestamp of the commit doesn't have any bearing on things from a file perspective. If you had A <- B <- C And commits B and C had much earlier timestamps (if that's possible) then it would be no different than if those commits had "logical" timestamps one after the other (A earliest, C most recent). The parent <- child relationship of the commits is what's important here in terms of sequential ordering, not the timestamp.
|
|
#
?
Jun 19, 2015 08:59
|
|