Open up your platform with Open Source and GitHub
Download as PPT, PDF1 like1,342 views
The document provides information about open sourcing projects and using GitHub. It discusses the benefits of open sourcing including increased adoption, feedback, and community. It then outlines the steps to open source a project including picking something to open source, deciding where to host it (e.g. GitHub), setting up a GitHub repository, using Git concepts like branches, structuring the project, and cleaning up and pushing the code. The document concludes with recommendations like using private and public repositories, taking advantage of GitHub tools, and considering package managers.
![Some git concepts
local and remote[origin]
− All changes start local and need to be 'committed' and 'pushed' in
order to be persisted remotely(and available to others)
− This includes branches.
Branches
− Branches “diverge from the main line of development”
− They start locally and if you want to share them need to be pushed
− Create a branch
git checkout -b branch_name
− Share the branch with the remote
git push -u origin branch_name](https://image.slidesharecdn.com/devatinterconnect2015dev6295-150610155411-lva1-app6892/85/Open-up-your-platform-with-Open-Source-and-GitHub-12-320.jpg)
![Make some process decisions [hint: git flow]
Branches [the gist]
master – default branch,
production ready.
develop – latest develop
code, should be stable.
feature/release/defect –
used to do work.
Author: Vincent Driessen
Original blog post: http://nvie.com/posts/a-succesful-git-branching-model
License: Creative Commons BY-SA](https://image.slidesharecdn.com/devatinterconnect2015dev6295-150610155411-lva1-app6892/85/Open-up-your-platform-with-Open-Source-and-GitHub-13-320.jpg)
![Private & Public
A GitHub repository can be public or private (if paid) but not
both
In some instances, you may wish to develop code that will
support an internal feature of your platform that is not public
yet. This is a great scenario for a mixed environment.
Create a Private git repository
on GitHub or on an internal
server.
Add it to your existing repo.
Create a branch and push it to
the private remote.
$ git remote add private git@github.com:
[user]/private.repo.git
$ git checkout -b private-branch
$ git push -u private private-branch](https://image.slidesharecdn.com/devatinterconnect2015dev6295-150610155411-lva1-app6892/85/Open-up-your-platform-with-Open-Source-and-GitHub-17-320.jpg)
Open up your platform with Open Source and GitHub
- 1. © 2014 IBM CorporationFebruary 22 – 24, 2015 Open Up Your Platform with Open Source & Github!
- 2. A Quick Introduction Agenda − Why Open Source? − Getting Started − Git & Github − General Recommendations About Me Scott Graham, IBM WebSphere Team working on Real-Time Communications swgraham@us.ibm.com
- 3. The Big Question: Why Open Source?
- 4. Why Not? • Intellectual property concerns • Licensing Issues • Internal Bureaucracy LAWYERS, GUNS AND MONEY But these can be overcome, and in many cases its worth the effort.
- 5. Benefits Take advantage of demand. − Almost every Fortune 500 company today has an Open Source strategy and mandate. Developer Adoption and Support − Increase Adoption of your platform and tools − Get rapid feedback on features − Solicit contributions Community − Create a community around your platform and tools − Become part of the Open Source community in general
- 7. An anecdotal story Everything inside IBM We moved our client libraries and samples to GitHub to be developer friendly. There are things you can do with Open Source only but by pulling in Liberty you get way more functionality.
- 8. First – Pick Something Samples using your platform APIs Developer tools Products that enhance, but are dependent on your platform Systems Management tools and scripts Protocol implementations that other people may be interested in adopting
- 9. Second – Decide where to put it GitHub Google Code SourceForge etc. And while there are also many others for the remainder of the presentation we will presume you chose GitHub.
- 10. Third – Assuming you picked GitHub... 1. Download and install 'git' from git-scm.com 2. Setup 'git' : https://help.github.com/articles/set- up-git/ 3. Setup Authentication with GitHub 4. Create a Repository 5. Optional: If you use Eclipse, install EGit http://eclipse.org/egit/
- 11. Git & Github
- 12. Some git concepts local and remote[origin] − All changes start local and need to be 'committed' and 'pushed' in order to be persisted remotely(and available to others) − This includes branches. Branches − Branches “diverge from the main line of development” − They start locally and if you want to share them need to be pushed − Create a branch git checkout -b branch_name − Share the branch with the remote git push -u origin branch_name
- 13. Make some process decisions [hint: git flow] Branches [the gist] master – default branch, production ready. develop – latest develop code, should be stable. feature/release/defect – used to do work. Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA
- 14. Structure your project Projects on GitHub have a common structure README.md CONTRIBUTING.md LICENSE /src /tests /dist The README.md is automatically served by GitHub when your repository is accessed. Add install, setup information Here. These define how to contribute and the license you are publishing the code under. Generally stores a distributable version (built) of your app. Projects in GitHub generally include all of the product's tests and the tests can be run by anyone who clones the project.
- 15. Clean it up and push it When moving an existing project out to the public, ensure you meet your company's licensing requirements. Remove any internal information (ip addresses, user names, server names) etc. Add build files and anything else that doesn't belong in source control to your '.gitignore' # 1. From your project dir, init # as a git repo $ git init # 2. Edit .gitignore to ignore files # 3. Add files to be tracked (will # not add files in .gitignore) $ git add . # 4. Perform initial commit $ git commit -m 'Initial commit' # 5. Add the remote repository $ git remote add origin rem_repo_url # push it to to remote $ git push origin master
- 17. Private & Public A GitHub repository can be public or private (if paid) but not both In some instances, you may wish to develop code that will support an internal feature of your platform that is not public yet. This is a great scenario for a mixed environment. Create a Private git repository on GitHub or on an internal server. Add it to your existing repo. Create a branch and push it to the private remote. $ git remote add private git@github.com: [user]/private.repo.git $ git checkout -b private-branch $ git push -u private private-branch
- 18. Use the GitHub tools Issues – to track defects/feature requests/etc. Pull Requests - Handle contributions from others without giving write access to your repository. Wiki – Document information about your project, the API, etc. github.io: https://pages.github.com/ – Serve a simple website to advertise and demo your project
- 19. Use public package managers If you want people to install and use your code support the public package managers. Bower – Client Side JavaScript – http://bower.io npm – Server Side JavaScript http://npmjs.com Maven – Java Projects http://maven.apache.org/
- 20. Specific JavaScript considerations Dependencies: To CDN or not to CDN ? − Licensing considerations, performance, version matching − Using Bower? Provide a CDN for your repo via 'https://rawgit.com/'
- 21. Thank You!
Editor's Notes
- #6: Many companies will not purchase software they do not have access to source code. So there is a real business reason for doing this.