Honest question: Is Github supposed to be about Git and code?
Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code.
I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy.
The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git.
In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.
They help, but as a user of Github for Windows, I have too often been told that a "synch" (basically a combination of push and pull) failed and I need to resolve the issue using my command prompt. As an anecdotal measure, I would estimate this happens about 5 to 10% of the time while working alongside my colleagues who are not using Github for Windows, or any similar GUI tool, and using our own private Gitlab origin.
Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool.
I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.
Try Atlassian's SourceTree.[1] I have only used the Mac app. It's the GUI I settled on after trying three or four others, including Github (again, for Mac). They built the Windows client after everyone who uses Windows at work clamored for it. I'm still on XP though and it requires 7+.
Atlassian also has a good, friendly set of tutorials for using Git.[2] The order in which they introduce the concepts and the commands encourages a clear understanding of the whole system.
SourceTree has been great and Atlassian's support is also excellent. However, I still can't work out how to turn off Git's overly-optimistic automerge, which leaves << HEAD strewn through files at random.
I briefly tried SourceTree when the Windows build was first made available for download. However, it too did not support Git submodules--although from my understanding the Mac version does. I'll keep an eye on it though, since that seemed like something that would be added in time.
I am a firefighter and hobby/part-time developer. We have more manuals and SOP's than you can shake a stick at. They should be in source control so we can see how strategy and tactics evolve over time, who made the changes, diff's and/or allow "pull requests" from the field to change something for the better, as just one example.
Now, try to explain to your Chief or supervisor about how awesome Git is.. that is easy and I've done it. Then comes the part where you explain how to use it; The problem is the interface on both the CLI and GUI require a TON of "other" domain knowledge to use effectively. Abstract all that away at the same price point of Github and you will win a HUGE market.
We don't have IT budget to pay anyone to do this... nor buy the extremely expensive solutions that already exist. So we rely on email and ad hoc training to make sure everyone can stay abreast. Now, how many businesses not related to software development could benefit from Git or a similar DVCS?
That's a pretty interesting use case. I'm always interested in occupations with non-technical emphasis that are moving towards Git, GitHub, and source control in general.
I'd be really interested in hearing more about the problems you face, personally and within the firestation. If you'd like you can email me at my username [at] gmail.
Will do. Think about medical records or 911 call data in a git repo. This is evolutionary stuff that no one in the fire service is thinking about. Hell, our IT guru's can't seem to get clean data from one database to another. Its a sad state in .gov IT at the local level.
Hello Brother! Yes, we've used those... sadly they don't work "at scale." My department has 600 members and a lot of them have good ideas. They have to go through the chain-of-command to get those ideas heard. This method not only suffers from the telephone problem Ie. the idea is lost in translation. It also suffers from a Chief or Capitan not liking the idea(s) and never doing anything with it. Manuals and SOPs in a democratic environment where anyone could clone, make changes and submit pull-requests would be a manna from heaven.
In that case a Github wiki might be a good start. You get the version control, but there's enough abstracted away that it should be easy to get up and running with. Now, you just need everyone in your department to get a Github account...
Yeh, but the convenience of it here is that you may freely browse that repo (and change URL in the address bar), and still have the access to the repo URL.
You can clone with HTTPS, SSH, Subversion, and other methods.
Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option.
The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories.").
There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...
Agreed. I use Bitbucket every day, and while it's far short of 30 seconds, I do find it takes a second or two of extra scanning to notice where the repo URL is. And it's essentially on the top right, not aggressively out of the way.
Now, Github's pushing it even further out of view than Bitbucket's location.
Yeah but by the time you've used the site a couple times, you'll be able to find the repo url from then on. It really doesn't make any sense being at the top of the page taking up so much prime space.
They added a green button which i assume is "fork on github". It seems they want to encourage people to use github rather to clone to local filesystem.
They've always had a quite prominent "fork on github" button.
Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system.
The default workflow is designed to play nice with their issue tracker/etc.
Nope, that one is for pull requests. But they did disable SSH cloning for read-only and the cloning URL is not showing at all (only after you click on HTTPS), pointing towards preferring of forking.
Then I thought how awesome GitHub was and it really understood users. It always had the big repo url on front and top where one can never miss it.
In this new design, GitHub has pushed it on to bottom right and reduced the input size. Bad Decision IMHO.