|
I'm switching our team from svn to git. I've been using git-svn for a long time and thought I had a pretty good handle on it, but now that I've got everyone using git I see I need to change my workflow a little bit. How do you handle feature branches and collaboration? Especially if you want to merge more than once. Say I make a new branch from master called features/AddAWidget. I hack on that branch for a while until I want to incorporate it in the build, so I merge features/AddAWidget into master and push it. Then later I want to refine that feature a bit, so I checkout that same branch. Here's where I get confused... I used to 'git rebase master' to keep my feature branch up to date. But now that I'm sometimes pushing and sharing that branch, it seems that's a bad idea. So what do I do? Do I merge feature into master, then merge master back into feature? I'm getting a little confused here.
|
#
?
Oct 25, 2011 15:58
|
|
|
|
| # ? May 10, 2024 21:05 |
|
|
Dromio posted:I'm getting a little confused here.
|
|
#
?
Oct 25, 2011 16:06
|
|
|
Mithaldu posted:Once you've merged it into master it's best to leave it at that and just make a new branch if you want to change that feature again. What if I'm doing something like described here? If I merge the feature branch into the "develop" branch using "--no-ff" will I be able to continue working on the feature branch and merge it into develop again later? Even if I don't keep the feature branch up-to-date from changes others have put into develop elsewhere?
|
|
#
?
Oct 25, 2011 17:14
|
|
|
I am in somewhat of a hurry, so i cannot mull over the details right now, but please let me suggest you to watch the first half of this video to maybe improve your mental model of git commits.  http://blip.tv/open-source-developers-conference/git-for-ages-4-and-up-4460524
|
|
#
?
Oct 25, 2011 17:49
|
|
|
Dromio posted:If I merge the feature branch into the "develop" branch using "--no-ff" will I be able to continue working on the feature branch Dromio posted:and merge it into develop again later? Dromio posted:Even if I don't keep the feature branch up-to-date from changes others have put into develop elsewhere? As long as you're fine with not having the latest and greatest from develop in your feature branch that's all easily doable. But honestly, i'd suggest to gently caress merging and rebase your poo poo. You do feature branches usually because you're the only one working on them, so it's fine to get creative on them. Rebasing also gives you the MASSIVE advantage of being able to rebase up one-by-one and resolve conflicts piece by tiny piece, instead of in one massive merge.
|
|
#
?
Oct 25, 2011 20:14
|
|
|
Mithaldu posted:But honestly, i'd suggest to gently caress merging and rebase your poo poo. That's what I had been doing when I was working in the remote repository alone. But now it complains if I push a branch to origin after rebasing. And that makes sense-- I can't rewrite history if someone else might have checked it out elsewhere. I want to do collaborative work on features moving forward, so it's going to be a bit of trouble.
|
|
#
?
Oct 25, 2011 20:29
|
|
|
Dromio posted:That's what I had been doing when I was working in the remote repository alone. But now it complains if I push a branch to origin after rebasing. And that makes sense-- I can't rewrite history if someone else might have checked it out elsewhere. I want to do collaborative work on features moving forward, so it's going to be a bit of trouble. If multiple people collaborate on the same feature, make your contributions in sub-branches of your own. Remember, rebasing is only ever an issue if two people work on the same branch and even then there's quite a few circumstances where it's fine, thanks to cherry-picking being a thing.
|
|
#
?
Oct 25, 2011 20:36
|
|
|
Mithaldu posted:As long as you're fine with not having the latest and greatest from develop in your feature branch that's all easily doable. But honestly, i'd suggest to gently caress merging and rebase your poo poo. You do feature branches usually because you're the only one working on them, so it's fine to get creative on them. Rebasing also gives you the MASSIVE advantage of being able to rebase up one-by-one and resolve conflicts piece by tiny piece, instead of in one massive merge. Merging is possible step by step too, you know. Admittedly, it won't look pretty :-)
|
|
#
?
Oct 25, 2011 22:07
|
|
|
Anyone know of a good Linux SVN client? Comparable to Tortoise for Windows.
|
|
#
?
Oct 25, 2011 22:11
|
|
|
uXs posted:Merging is possible step by step too, you know. Admittedly, it won't look pretty :-)
|
|
#
?
Oct 25, 2011 22:19
|
|
|
ianN posted:Anyone know of a good Linux SVN client? Comparable to Tortoise for Windows. You mean a GUI? Most Linux distro's come with an SVN client installed. You should go ahead and learn the command line as it opens a lot of powerful tools. As to a GUI, Nautilus already has support for SVN and there is RapidSVN. Edit: Has anyone here used RTC and could point me to a good tutorial of how best to use it and hopefully deals with ideas such as topic branches? We've been using it for a project, and to describe the current usage as painful is being kind. HFX fucked around with this message at 22:29 on Oct 25, 2011 |
|
#
?
Oct 25, 2011 22:27
|
|
|
Plorkyeran posted:I suppose you could rebase step by step on a temp branch and use the result of that as the merge conflict resolution. That is a pretty interesting idea, i like that!
|
|
#
?
Oct 25, 2011 22:29
|
|
|
I've been using git for the past several months in a very basic way. I am a one man web development company, and use git through Aptana just to keep track of my own revisions. After releasing an application I decided I should start looking into creating branches to keep even better track of updates I make to the live application. In Apatana, I created a new branch that I called "1.01". I've made many commits through it and the development site always reflects 1.01 (http://mysite.local). Once it all looked good, I merged it into the master branch. My first question is if I'm on the right track with how I am handling branches. My next one will be something like 1.02. Is this correct? Also, since the actual working directory always has the latest changes, is it possible to have the master branch sitting in it's own folder so I can always have that copy to reference with a URL like http://mysite-master.local? Or how would that be handled?
|
|
#
?
Oct 26, 2011 19:28
|
|
|
VerySolidSnake posted:Also, since the actual working directory always has the latest changes, is it possible to have the master branch sitting in it's own folder so I can always have that copy to reference with a URL like http://mysite-master.local? Or how would that be handled? Clone your repo, checkout the master branch and serve it.
|
|
#
?
Oct 26, 2011 19:39
|
|
|
VerySolidSnake posted:I've been using git for the past several months in a very basic way. I am a one man web development company, and use git through Aptana just to keep track of my own revisions. After releasing an application I decided I should start looking into creating branches to keep even better track of updates I make to the live application. There isn't really a single "correct" way to do this stuff. Source control is a tool; use it in whatever way works best for you. If you're doing completely linear development and not maintaining old versions, then you can just use tags to mark "milestone commits" (aka releases): pre:o---o---o---o---o---o---o
^ ^ ^
v1.0 v1.1 HEAD
pre: v1.0.1
v
b1---b2
/
o---o---o---b1---o---b2---o
^ ^ ^
v1.0 v1.1 HEAD
*Note: This is one of several reasons why you should make your commits small and atomic. Don't just treat commits like a snapshot of your working tree. What you describe sounds to me something like this: pre:o---o---o <-- branch v1.0
^\
v1.0 \
\-o---o <-- branch v1.1
^\
v1.1 \
\-o---o <-- branch v1.2
^
HEAD
ColdPie fucked around with this message at 00:55 on Oct 27, 2011 |
|
#
?
Oct 27, 2011 00:53
|
|
|
I think that last diagram isn't entirely honest, since for git tag markers and branch markers are exactly the same except for the single defining differences that branch markers move on when you commit while they're active.
|
|
#
?
Oct 27, 2011 08:15
|
|
|
ColdPie, I appreciate the response! Tags seem to make the most sense since development is linear. I also found some git commands that would allow me to clone a previous git tag into a different directory, so if I wanted I could have easy access to testing old versions. I believe I will also stick with using 2 branches for now as well. One as the master, the other as development. Once I merge the two, I will create a tag, then begin working on the development branch again.
|
|
#
?
Oct 27, 2011 12:51
|
|
|
VerySolidSnake posted:ColdPie, I appreciate the response! Read this. It's about Mercurial, but explains why a default and a stable branch could be easier to work with than a development and a master branch. Edit: this = http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/ uXs fucked around with this message at 13:48 on Oct 27, 2011 |
|
#
?
Oct 27, 2011 13:45
|
|
|
Actually, i can explain 4 words why having a dev and a master branch is counter-productive: You cannot bisect (sanely)! Bisecting is the act of finding commits that introduced bugs by way of checking out the first, last, and middle commit of a repo, testing them; then repeating that for the "good" segment. If your commits are all intertwined with two branches merging back and forth this feature becomes pretty much entirely useless.
|
|
#
?
Oct 27, 2011 14:23
|
|
|
Mithaldu posted:Actually, i can explain 4 words why having a dev and a master branch is counter-productive: You cannot bisect (sanely)! It seems to work fine for me.
|
|
#
?
Oct 27, 2011 18:05
|
|
|
I am very new to git. So please bear with me if this is a simple question. We have two developers, myself and someone in a remote location. The flow right now is, when he wants me to push something to our test server, he tells me, I do it, and when it's passed our testing I push it to the live server. We just got git and am learning it, and I was wondering how best to duplicate this division of responsibilities? Right now I'm thinking, we have master (live server), from which is branched test, from which is branched our development environments. We can both push our development environments to test, but I want to be the only one to be able to push to master. Can I, and how do I, set up this kind of restriction?
|
|
#
?
Oct 27, 2011 22:43
|
|
|
You want Gitolite. It's easy to set up and very powerful. When you're using a server run by Gitolite, everyone uses the same user (git) and access control works through SSH keys. You can restrict his access so that he can't push to the master branch, but all other branch names are fine.
|
|
#
?
Oct 27, 2011 23:49
|
|
|
 holy moly look at those hashes https://github.com/vog/beautify_git_hash/commits/master$ git log --format=oneline 0016ae203f6eea832955423d0230c13f79253d39 Fixed typo 0015aa2023bfdd5c07cd209055078c3d0d021e8b Improved introduction text 0014ac07575d500b76ee4304cfb72e0439c4ba7b Provide .gitignore 0013a87ea205f676c55f86348e9c3fcf6d9cda5d Provide a Git post-commit script 0012a12532c1fc3a37b4b3976282062df2604ad6 Suppress an otherwise misleading Git er 0011aeb1e6c54a735acaf1f86e4085a81bb45de7 Improved coding style 0010a17abe46935a634dd7948163ddfdb3a63d24 Automatically propose a new prefix when 0009a2599c168f24cdfe4eac1ee6f171525cbf9c Improved usage message 0008a192c3713ea7ca5cbb7788c089099d865119 Make script executable 0007a5ed133a9803ac77b4661fbef36b0219c12a Introduced new function show_proposal_f 0006a71f3baf593db0e0638445b6271a5dd6e9ef Improved naming of variables 0005a8c811d2c3ed904f9a46e135c6d755430df1 Added an introduction text to the modul 0004ada882d1733ca217d42fc43cdede06577776 Make the script also work on Python < 2 0003a5f11b18591383b61700fc18ccaaef3e0f7b Show a more appropriate output when the 0002a87e25527ea0de04244f879544a02153289e Improved coding style 0001a2f14eaf525be00b381b9b3dcd406a6ff7e1 Added the initial version
|
|
#
?
Oct 29, 2011 04:26
|
|
|
That's cute, but won't be of much use when multiple people work on a repo.
|
|
#
?
Oct 29, 2011 09:21
|
|
|
Mithaldu posted:That's cute, but won't be of much use when multiple people work on a repo. Unless you put a hook on the main Git repo 
|
|
#
?
Oct 29, 2011 13:02
|
|
|
Mithaldu posted:That's cute, but won't be of much use when multiple people work on a repo. by the way, the idea originally came from the BitCoin project 
|
|
#
?
Oct 30, 2011 01:16
|
|
|
I've started a VBA specific thread but this query I have might as well go here too: Version Control in Excel VBA is a bit of a pain. Fine for one person of course, but multiple users starts to get messy. I/we currently use SourceTools.xla which is functional enough and integrates well with SVN/Tortoise, although there is a shortcoming with the .frx files due to VBA/Excel modifying files when they're exported for reasons best known to itself. This leads to an issue with the versioning of the .frx files as they're committed before they're changed (I think) so they always end up out of date for the next user. SourceTools is a small VBA tool that effectively breaks the workbook into its component parts and stores them in a subfolder in addition to the main workbook whilst interacting with TortoiseSVN. Problem is, any changes to the sheets themselves are only stored in the workbook and aren't exported. One of the problems is that if you have, say, one person working on the worksheets alone and another person on the VBA alone, it can get slightly messy when it comes to committing things. Ideally the VBA chap will commit modules using SourceTools, the sheets chap will "update" using SourceTools taking the new things on board before saving his workbook then performing a manual commit using Tortoise outside of Excel. It's awkward, but it *should* work. It doesn't really get round the .frx problem however. Anyone ever tried to VC a VBA Excel workbook that's co-developed by more than one person? Sonic H fucked around with this message at 13:12 on Nov 2, 2011 |
|
#
?
Nov 2, 2011 13:05
|
|
|
Sonic H posted:Anyone ever tried to VC a VBA Excel workbook that's co-developed by more than one person? I feel like this belongs in the Horror Thread.
|
|
#
?
Nov 2, 2011 14:31
|
|
|
Steampunk Hitler posted:I feel like this belongs in the Horror Thread. You're probably right as thus far it works, but it's not pretty. Managing an Excel workbook is something nobody should have to do.
|
|
#
?
Nov 2, 2011 14:40
|
|
|
I'm think I'm "doing it wrong" with git and trying to force it to follow my desired workflow. I have a branch called "Production" that contains the code that's currently on Production. I have a branch called "Development" that contains all the code that's been in development and the developers feel like might be ready for release, but is untested. I have multiple feature branches like "feature/addTotalCountToReport" where a developer implemented a specific feature. When a developer starts a task, they make a branch off "Development" and start their work. When they're done with the task, they push their feature branch to origin and merge it back into Development so it gets automatically built on our shared dev server for testing. Then our QA guy comes to me and says "I want to deploy feature/addTotalCountToReport, but not feature/bigGiantChange because it still needs work". Originally I thought it was as easy as merging feature/addTotalCountToReport into my Production branch and building. But because that was branched from Devlopment originally, when I merge it'll bring in code from previous development branches that might not be wanted. So how do I fix this? Should feature branches be built off Production, not Development? I think this might confuse the developers because they won't see the bugfix they did yesterday. Or do I cherry-pick all the commits from the feature branch into Production? That seems kind of nasty, but seems to work.
|
|
#
?
Nov 2, 2011 15:45
|
|
|
I had used SVN version control back in college for a database design class. We had stored all of our files on there and our group had loved it because we didn't have to pass around USB drives and version control allowed us to always have backups for when we did something we didn't want to do. I now use git version control with a free ProjectLocker account for all of my code for my job. I'm trying to get my coworker to use it as well but he doesn't want to give it a chance. I love it however and have had to revert files to previous versions 4x in the last week or so. Big time saver for me.
|
|
#
?
Nov 2, 2011 15:53
|
|
|
Dromio posted:I have a branch called "Production" that contains the code that's currently on Production. Can we get a screenshot of what tortoisegit thinks this looks like? I have the feeling that that split right there is your issue. Normally you'd use tags, and if appropiate, localized small bugfix branches, to mark production stuff.
|
|
#
?
Nov 2, 2011 17:07
|
|
|
Mithaldu posted:Can we get a screenshot of what tortoisegit thinks this looks like? I have the feeling that that split right there is your issue. Normally you'd use tags, and if appropiate, localized small bugfix branches, to mark production stuff. I'm having a terrible time uploading to imgur, but suffice it to say that the history log looks like a complete mess. I'm not sure how to use tags to do what I want here. I want three devs to be able to work on 9 different features, and be able to pick and choose to only include code from feature 4 of 9 into production, then later be able to come back and add feature 3. But maybe it's just not really feasible. My current thinking is that we can do it if we start branching features from Production and forget about the "Dev" branch altogether. So the workflow might be code:
|
|
#
?
Nov 2, 2011 17:49
|
|
|
So we finally have git set up but I'm really confused how to handle multiple people merging. I have a branch, test, that I merged a feature in to earlier today. The other developer has now merged his new feature into it, and in the process - since his new feature was branched off before I merged mine in - it deleted the files that mine added. 1) How do we get around this? 2) How can I force git to not remove files without asking? Edit: Corollary: When should we pull, and I guess when we pull (I'm guessing before a merge?) we should merge the pulled copy into the branched feature? Golbez fucked around with this message at 22:57 on Nov 3, 2011 |
|
#
?
Nov 3, 2011 22:25
|
|
|
Golbez posted:So we finally have git set up but I'm really confused how to handle multiple people merging. Did he actually merge with your things? If he did, he did his merge incorrectly. But I don't know enough about Git to know where exactly.
|
|
#
?
Nov 4, 2011 15:19
|
|
|
uXs posted:Did he actually merge with your things? We're still not sure what went wrong. Since we're converting an existing, non-version controlled codebase to use branches and all that, hiccups are slipping through. He never completed the merge, and now using a tool it seems like he's getting around it, but I'm still not sure.
|
|
#
?
Nov 4, 2011 15:28
|
|
|
Golbez posted:We're still not sure what went wrong. Since we're converting an existing, non-version controlled codebase to use branches and all that, hiccups are slipping through. He never completed the merge, and now using a tool it seems like he's getting around it, but I'm still not sure. A merge is a pretty simple concept. You have 2 revisions, and need to merge those into 1 revision. So you tell your system that, and it prepares for you a revision that it thinks is a combination of those two. If it can't, it should indicate to you where the problem areas are, and give you the opportunity to merge those areas manually. When that's all done, you can check your work (this is where you should test both your changes as the changes the other guy made), and then commit it.
|
|
#
?
Nov 4, 2011 17:14
|
|
|
Fortunately, we finally got the problems worked out, it seems to have been a one-time hiccup caused by us pushing an existing codebase into git and then branching it out.
|
|
#
?
Nov 4, 2011 17:33
|
|
|
I want to create a git repository. This project ties together three external projects stored in other git repositories that are maintained by someone else. My project will combine two of these projects (which are already very similar) while the third is separate- the directory structure will look like this:code:I was hoping that I could store all three projects as independent branches in my repository, and then do some kind of "merge into directory" thing, where I merge a local branch into a subdirectory of another. Is this possible? What's the best way for me to handle this?
|
|
#
?
Nov 7, 2011 16:42
|
|
|
|
| # ? May 10, 2024 21:05 |
|
|
Using VisualSVN server, is there a way of changing the default project structure from trunk/tags/branches to <anything else>? So instead of having to go through generating a repo, then populating it with a predefined folder structure each time, I can have VSVN do it for me?
|
|
#
?
Nov 7, 2011 17:29
|
|