Do I need the GitHub tools installed on my machine to use RD's SC? Would it be a good idea to have them anyway so I can do some things outside of RD if necessary?
I didn't get nearly as much reading done over the weekend as I'd planned. :(
fair enough, it's already daunting if you don't know what you're doing! ;)
So, if we're using Git, I need to create the repository somewhere local to me, not where everyone else on the team can access it. They only get to it through Git, right?
Gah! but, if someone else wants to get the code, they should only get it by cloning from the repository, right?
There's no need, and it's actually BAD, to put the code on a shared location on the network where everyone can get their fingers in it bypassing Git. right?
@FreeMan When we need a local repo, we publish to the network location and clone to local machines. Think of the online provider just like you would any other network drive. Github is more like Dropbox for the published repository with some web tooling built on top of it.
And the remote is the part that lives on the Git server (be it GitHub, another host, or privately hosted). My local is my clone of the remote. Then I work off that, forking as necessary for different changes (bug fixes and dev work). I then PR into my own local, make sure I didn't break anything, then merge to the remote on the server?
crap, really shoulda done some reading over the weekend!!!
The workflow really depends on how you want to do it. You can use a fork workflow, but that's usually more appropriate for larger projects with lots of contributors. For projects that you work on as the only dev, just branch.
[rubberduck-vba/Rubberduck] is the "main repo". [retailcoder/Rubberduck] is my "fork". both have a [next] branch. so when I make local changes to [retailcoder/Rubberduck/next] and I want to bring in these changes to the "main repo", I make a PR from [retailcoder/Rubberduck/next] into [rubberduck-vba/Rubberduck/next]
but before I can make a PR the remote needs to first see my local changes, so I push my local commits to my fork
a branch is really just a copy of the project, ...kind of like a folder (in SVN it's actually a physical folder)
my fork is my copy of the remote repository. I work on branches (one for this bug, one for that feature, etc) that are only in my local. I commit changes to the local branch I'm working on, push those to my local "next", then PR to the "main repo" Next. Eventually those get pushed from "main/Next" to "main/Master".
if you're working in local branch "feature" and want those commits into your local branch "master" all you need is to merge. then your local master will be desynchronized from your remote master; when you push the local commits they'll be on the remote, but still in your fork. then at one point you're happy about your changes and you want them into the "main" repository, so you make a pull request to grab "master" off your fork and merge with "master" off the "main" fork/repository.
So what I need is a test project with nothing but some text files so I can get the hang of this without royally screwing up anything, then figure out my workflow, then move on to the real thing.
I'd like to have a vaugish idea what I'm doing before I try to put the code I've been working on for the last 2.5 years into it then hose myself... :/
@Comintern if my fork is located on my local hard drive, and it takes me a couple of days to figure out a bug, then I need a backup of my local hard drive until I'm ready to push to the remote master, right? My local master is at the mercy of the hard disk that it's physically stored on until it's either backed up or merged with a remote somewhere else, correct?
I think the issue is that the code we have is the master copy, and when it goes into GitHub, it will be in an account under my name. That will be our Remote. Anything that's being worked on will be by me or the one other guy who occasionally gets in there and rummages around a bit.
I think my confusion is between my fork on GH and the master on GH, but under my account.
since this is corporate code, I'm thinking that we may actually install a local Git server. I mean why not? I can barely manage to figure out the basic concepts, I'm sure I can handle administering the server, right?
@Mat'sMug ah, carp. Since there's only 2 of us, I'm sure we'd go for the Organization option. I'm sure we could shake loose that little bit of coinage, but I have to get a full handle on it first. Get buy in from the other guy (who carries all the weight in recommendations), and I'm good to go.
Hey man, you know GitHub? How about we put all our stuff on private repositories? There's a small monthly fee, but I'm sure we could convince management to grant it - github is just so awesome isn't it?
or just make everything public and have management recommend making them private
@Comintern So... Can I use the network location as my "Master Repo" location, then have each of us fork to our own local (network) location, then clone to a local (another network directory or local HD) location for the actual day-to-day work?
light bulb starts to glimmer, but isn't fully bright yet
of course you can :) your respective forks should be on the network though, and backed up. e.g. under your user profile's documents folder, i.e. not local.
@FreeMan What we do here is use a network share "\\Dev\Source\" to store all the "master" repositories. Everyone clones them to local, and then synchs back to \\Dev\Source\.
If you wanted more control over what gets put into your "master" than that, you would probably want to use forks.
and, since the Master repository is not on GitHub itself, there's no need to worry about it being visible to others, and there's no need to pay to make it private
working as I am with GitHub for Windows (for now at least) and "TestGit1" located on the server. I've made a couple of changes and committed them them both. I did a Sync, then created a PR. I clicked the "View it on GitHub" link, then merged it.
simple when you're just typing some text. Merges will be more difficult if two of us are modifying the same sets of files...
that's where many, smaller modules with many, smaller functions becomes more valuable - more likely to be working in different areas of code, thus less likely to have merge conflicts by changing the same code twice in different ways.
@Mat'sMug - If the Worksheet_SelectionChange is in a private worksheet code sheet (and that's the only place it is going to trigger) and not a public module code sheet then it is implicitly private. — Jeeped4 mins ago
#nope
@Mat'sMug - Hmmm, well I know you cannot call it from another codesheet. It must be public to that codesheet but private beyond that. — Jeeped1 min ago
@Jeeped If I have that handler in Sheet1 and make it say Debug.Print "Hello", and then go to, say, Sheet2, and expose a Public Sub Test() that does Sheet1.Worksheet_Change Range("A1"), I get "Hello" printed to the immediate pane. Seems Public means "public" after all ;-) — Mat's Mug1 min ago
