Github/Version Control Best Practices

L.Jenkins · 17-01-2014 10:14pm #1

Not here to discuss the how to aspect of Github and/or version control. I'm here mainly to get a feel for the best practices surrounding the topic. In my previous job we relied heavily on Github and my tool of choice was SmartGit. With each passing day, we retrieved the latest version of our project in the morning and synced our work last thing at night, as you might do.

I usually kept 3 copies of the projects I worked on. 1 I retrieved in the morning, the latest copy of working build (for roll back in case I fúcked up somewhere and needed a quick fix to start over with) and what I worked on (to be synced upon completion at the end of the day or as required during the day).

What is the best practices used in industry at the moment regards maintaining working copies, while updating a project?

Giblet · 17-01-2014 10:23pm

I think the above is actually going perpendicular to what git allows you to do. Surely the ease of branching, stashing, reverting, checking out specific commits / tags means you don't really care about your working copy, just your index. You should commit to the smallest granularity, rebase to fix history (you can also use filters to fix history if required), and use topic branches to make sure you aren't encroaching on other people too often. Look at gitflow for a branching model. Tools such as github, gitosis and gitlab allow you to protect branches in central repos so you can force the use of forks and branches and use code reviews before accepting a merge as well.

Aswerty · 18-01-2014 7:48pm

While rebasing is popular it's a bit controversial isn't it? Reshaping history and all that. Though I must say as a mercurial user I've always been a bit jealous of it. I'm sure there is a hg extension out there for it though but I haven't yet gone in search of it and from what I hear there is "reasons" for not having it in there.

Also @Itzy why do you keep previously committed versions? Surely you can just clone them back out if you've made an absolute hames of it. Though all actions Giblet mentions can usually be invoked for most problems without the need for cloning out an earlier version. Keeping separate working copies is only needed, as far as I know, when you are working on multiple branches concurrently.

L.Jenkins · 18-01-2014 11:10pm

To Aswerty, I only keep the previous working (What I've committed and know to be good) version plus what I'm working on.

Colonel Panic · 18-01-2014 11:53pm

Aswerty wrote: »

While rebasing is popular it's a bit controversial isn't it? Reshaping history and all that. Though I must say as a mercurial user I've always been a bit jealous of it. I'm sure there is a hg extension out there for it though but I haven't yet gone in search of it and from what I hear there is "reasons" for not having it in there..

There is a debase extension but I can't risk trying it right now.

I've switched to Git for external projects and love being able to rebate when sending external pull requests while sparing the world of intermediate commits.

I'd not think rebase has value outside external contributors personally.

Aswerty · 19-01-2014 12:14am

@Itzy Why do you do that? I don't see any need for it under normal circumstances. Of course there is no harm in doing it, I just think it's unnecessary.

@Colonel Yeah I had a quick google for the extension after I posted. It seems pretty much the same as the inbuilt Git feature.

L.Jenkins · 19-01-2014 12:19am

Out of habit really. I like to keep a local copy just in case of the worst case scenario, what ever that may be.

Github/Version Control Best Practices

Comments