Git and Github

[notdavidlynch]

Do you use Git and Github for personal projects? Do you use it at your job? For both? Do you use both for personal stuff or just Git with local repositories?

When do you make initial commits? As early as possible? When you've managed to get something functional? When you're closer to a finished project and just want to share it?

How do you decide when to push? Finished, functional, or fuck it just push it all?

How often do you commit? Do you follow any rules? For instance, I'm being taught to make one commit per logical change, and this has really altered my approach to coding. Whereas before I could be doing one thing and easily get sidetracked by something else or just go around haphazardly refactoring or whatever, now I avoid it simply because I don't want to have to try and explain what I did in a commit message. It forces me to be more focused and intentional. I want to be able to explain the commit in one sentence.

How about etiquette? Any conventions you follow? When you fork do you make all of your changes in a new branch so that your forked master can be easily updated?

I just want to know what people are doing. When I first started with Git/Github I just used it to have finished projects on display and really didn't know what the hell I was doing (probably still don't). I also understand that you can basically host sites from Github, so that's interesting.

[Utisz]

At the moment, I fucking hate Git. Up until a couple of months ago, I just used SVN and for all the shit I'm doing (LaTeX files or sometimes source code collaborating with three or four people), but folks then started creating Git repos and the added complexity of Git is at the moment a ball-buster. I'm sure it has many benefits compared to SVN for large complex software projects but not for the shit I do and I wish the folks I work with would shut the fuck up about it and just use SVN.

I'm mainly pissed off though in that the last LaTeX file I was collaborating on, every Git pull created a whole-file conflict seemingly based on some newline bullshit, which never happened with SVN. It made my job a lot fucking harder for no good reason.

Anyways, I say all this from the perspective of someone who knows fuck all about Git. I'm sure once you learn about it and know the ins and outs it's pretty swell and stuff but I find myself not really caring enough. Having had a brief look at some tutorials, it seems to be able to use Git, you have to understand in some detail how it works and how it is implemented, which I sort of tried and sort of got and then sort of gave up on. I just stick to commit/push/pull and hope nothing else comes up.

[notdavidlynch]

Yeah, I just recently finished a course dedicated to it and I was impressed with how confusing some of it was, or seemed to be, and I knew that I would need to go back and revisit basically the entire second half of the course. At least the course realized this and periodically tried to get me to write out my understanding of what was going on.

[Utisz]

I should add though, whatever my own (possibly ignorant) misgivings about Git, it is a really useful thing to learn for anyone interested in software development ... I think for sure it's a very useful course to do. And I wouldn't sweat all of the details ... like anything else, once you have the basics, I guess you can continue on a need-to-learn basis and just google the more advanced stuff if/when the need arises.

[LordLatch]

I have no formal training that would push me past a cursory understanding of version control nor have I participated in a collaborative effort that would require it.

[ACow]

Git has been recommended by "the consultancy" as version control software for our future state at work. So theoretically in the long term we (by which I'm assuming me) are going to have to figure out how that's going to work. I actually agree that we could use some sort of version control, but like a lot of choices, i think they just chose the popular one that "everyone's talking about".

I actually like git as a concept, just so we're clear, so don't let the rest of my post over-ride that.

Several issues i've been immediately presented with in practice.

To use git, you've got to understand some concepts and lingo first. That's a barrier to the average joe. But you could say that with any version control software.

Second, you can't just "start using git" unless you're effectively solo. If you've got teams/multiple people, then you've got to establish a "git workflow/framework", and that's potentially some complicated/contentious shit right there if you don't have the authority/foreknowledge to just say "so mote it be!".

Thirdly, not all programming fits naively into a git workflow. The consultants recommended git for version control. Groovy. When you're making "another app" or "an academic paper", I actually understand how that could work. You've got everyone in little object oriented or effectively project specific worlds. This guy works on that feature. This team is adding in that option to that menu. They're each typing away and they're going to independently branch/merge/commit for each of their features and advances. I have a feeling the consultant that recommended it has only ever worked by themselves (partly because of how they work, partly because they're too insufferable for anyone to voluntarily want to work with them).

I'm in analytics. OO is not a natural fit for math/stats, so no one works like that. In addition, we're not writing software for application delivery per se, we're implementing computational processes onto real world complex systems. Which means that we don't have decoupled designed systems to target: we have complex cluster-fucks which look to me like a minefield of contradictory merge/change conflicts. "Oh well you should have designed that better". Thank you academics, perhaps you can write a letter to human history and inform them they've been doing it all wrong, i'm sure our race will comply and be more orderly in the future.

We don't necessarily have one static code base that incrementally evolves like in software product development, although each individual implementation might have facets of that. We should have several competing, often paradigm specific models with re-settable parameters that should all be competing and testing and changing to explain certain phenomenon. That's not incremental features/development on a code base. That's changing from one code base to another code base. We aren't making product 1.0, 1.1, 1.2, 1.3, 1.4 with incremental product releases. We might metaphorically have windows 1.0, 1.1b, 1.1a, 2.0, linux, os/2, and plan 9 simultaneously, and we're moving between each depending on time and circumstances with changes happening underneath us and potentially outside of our control. Its not immediately clear how version control would live in such an environment.

I'm sure part of this is my ignorance. But you know what, if I'm ignorant, what do you think is going to happen once you start trying to introduce it to the workers?

[Ptah]

No.

[JohnClay]

I use git for a lot of projects at work. One has a team of 3 or 4. I like how you can create a branch then merge it back later. We use bitbucket which lets you have a couple of free private git repositories. For the projects I work alone on I just create zips regularly and upload using ftp. With the git projects we have a localhost and push changes when things are working ok then the senior programmer deploys it to the stage or production server. When you're merging branches git can usually do it automatically but occasionally you've got to manually merge a change in a file (it shows 2 different versions in a section)