Awesome First PR Opportunities A list of awesome beginners-friendly projects. Inspired by blog post and project. If you are an open source project maintainer, add the label first-timers-only (or similar) to your project and list it here so people can find it. If you are looking to contribute then explore this list, look at, and follow on Twitter to be notified when a new first-timers-only issue is created. If you are not a programmer, but would like to contribute, check out the list.NET.

(label: Jump-In) Should testing for.net - the way Asserting Should be!. (label: first-timers-only) The.NET MVVM framework for cross-platform solutions, including Xamarin.iOS, Xamarin.Android, Windows and Mac. C.

(label: good first issue) Vim-fork focused on extensibility and agility. C. (label: good first issue) Build cross platform desktop apps with JavaScript, HTML, and CSS. (label: junior job) 2D and 3D cross-platform game engine. Also has C# and Python code. (label: stat:contributions welcome) Computation using data flow graphs for scalable machine learning Clojure.

(label: low-hanging-fruit) A music programming language for musicians. 🎶 ClojureScript. (label: good first issue) The Next Generation code editor! One of the top funded projects on KickStarter. Dart. (label: beginner) A website for developers writing Dart web apps, including AngularDart apps. (label: beginner) A website covering the Dart language and common libraries, for developers of Dart libraries, web apps, server-side code, and mobile (Flutter) apps.

I can't even test the functionality because it won't let me pass the first screen because I don't have config user.email set in my gitconfig. I have a pre-commit hook that is installed on all new repo's I create/clone that warns me, and then I set an email address PER REPO. This way I can work on both $WORK and open source projects on the same machine while having different email addresses per repository.

The assumption that a user needs to have user.email set globally breaks my entire work-flow. I switched from SourceTree to GitKraken, I don't know all the internal issues of what transpired at Atlasian on the SourceTree team, but to me it's just not the same product that the old Mac app was when they where independent. I really like GitKraken and the team is taking feedback applying it constructively and putting out an impressive product. The part I really like is it's the same app on OSX, Linux and Windows using Electron to build it was a smart move on their part.

My favorite feature has to be dropping a branch on another branch to create a pull request. I don't fanboy stuff much these days but I am a pretty big fan of their's right now. I already got that question today.

So, I'll just repost my answer: here are some differences from the top of the head:. Fork has tabbed interface. For each commit you can see not only changes, but also the whole repository as it was at the moment of commit. Diff viewer shows exact difference between two pieces of code.

For example, here are both SourceTree and Fork showing the same commit:, In ST (on the top) you need to figure out what has changed, in Fork (the bottom one) you see the difference clearly. Repository browser shows you many details about your repositories in the similar way as Finder does.

Commit list marks commits which do not belong to your commit tree with gray color. All of the OS X interfaces to Git are, to be honest, quite terrible. Sourcetree is awful. GitHub Desktop is even worse.

I've tried a couple of others, the names of which elude me at the moment. I think most of it is less of a complaint against the software itself, and more of a problem with trying to present the complexities of Git in a simplistic UI.

The simple fact is: Git as a whole is really, really freaking complex. Making the basic operations idiot proof is difficult enough, and then you have to try to offer a frontend for things like rebasing. Seriously though, fuck the products that pre-select all unstaged files to be added to the index on every commit. If I wanted the file staged, I would add it. Stop harassing me to add my development files - and no, I shouldn't have to gitignore them to prevent being constantly forced to deselect them. By all means, show checkboxes for me to add the files, but do not pre-check them. I haven't seen a single interface that gets it right.

JetBrains' integration in their IDEs is the closest to 'mostly usable' I've seen, where branch creation, pulls, merges, conflict resolution, and pushes are fairly straightforward. It's still far from perfect - I do the lower-level Git Pull rather than using the Update Project window because I have no idea what operations that window performs; and some rare operations still require dropping to command-line. I'd rate their implementation a 7/10 compared to the 3/10 other tools like Sourcetree provide. A huge reason JetBrains has an insurmountable lead is its diff and merge editor. It is the best on the market, and the only usable side-by-side merge tool I can work with.

Their 3-way diff is a dream to use. The last time I had to assist a co-worker merge a conflict using WinMerge on Windows, I gave up after 30 minutes. I flat out could not understand what the differences were, let alone figure out how to resolve the conflicts. Went back to my desk, checked out the branch in JetBrains' PhpStorm, performed the same merge, and had the conflicts resolved in a couple of minutes.

It's no surprise to me that people using WinMerge erase work done by other people far too often. Anti-disclaimer: not affiliated in any way with JetBrains.

Their IDEs are mostly amazing, though it's frustrating that they focus 95%+ of their efforts on new features without going back and fixing what is wrong with their existing features. Their diff/merge editor, at least, is unmatched by any other product I have seen to date (other than the fact that CMD+F / CTRL+F to find in the diff editor is broken. Again, JetBrains has some serious bugs that never get fixed). Having `git status` in a window-based UI is very nice. In magit, the window is divided into two sections horizontally: unstaged changes and staged changes. Each section contains multiple changed files that can be folded or expanded, and individual lines or hunks can be staged/unstaged as needed in order to prepare a commit. While it is an emacs extension, non-emacs users can start it with a one-line command and treat it as a standalone application, e.g.

I know at least one non-emacs user who uses it that way. There are some videos on youtube showing the magit UI.

Show Hn: Fork A Fast And Friendly Git Client For Mac Os

It would of course look more modern were it not an emacs extension but, emacs lisp programmers being as they are, I believe it is the most fully featured and powerful graphical git UI in existence.