Tag Info

Hot answers tagged

136

I would argue that "in the age of GitHub, Stack Exchange, Coursera, Udacity, blogs, etc." the relevance of a concise and a well written resume is more important than ever. As an employer, I am not going to start with your github projects and blog posts. I might end up checking them if: your resume is relevant to my job requirements; and your resume ...


123

Look at a resume as a distilled brochure that advertises highlights from your skills and experience. A combination of your github and SO profiles and a bunch of other online resources may be complete and accurate, but it isn't sorted or otherwise prepared for easy reading in any way. People who hire want you to tell them what you think distinguishes you from ...


86

I think this question is just a special case of "Why should I learn any CLI for which a GUI alternative exist?". I suspect the latter question is about as old as GUIs, and I assume there were many attempts to answer it over the years. I could try to bumble my way through my own answer to this question, but Neal Stephenson articulated what I agree with as ...


81

If all your needs are covered, awesome, no need to dig deeper into git, your time would be better spent in learning something you actually need. git is just a tool, when you'll need to do something you can't with a GUI app, you'll know it. Just keep in mind that github != git.


75

Are your images original work or can they be recovered (guaranteed?) from else where? Are they needed to ship a software unit built from source? If they are original, they need backing up. Put them in you rev control, if the never change, the space penalty is the same as a backup, and they are where you need them. Can they be edited to change the ...


66

As you mentioned in your question, people fork repositories when they want to make a change the code, because you don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository). In the forked repository they have write access and can push changes. They may even contribute back to the original ...


63

Is it meant to show that this is a collaborative project - you're welcome to add improvements? Yes: you don't have the right to push a commit directly at their repo. But you do have the possibility to fork their repo, which makes it your repo, and push commit from there, preparing pull requests.


53

Why not let this eager person send you a pull request? You'll have the opportunity to review and critique that person's code. This seems like the simplest solution.


45

I have to disagree with the ROT-13 solution. Obfuscating your banned words simply because the sight of them might offend someone is a waste of time. Your dictionary of bad words/bad-word-rules should come from a separate file anyways (which could be loaded at runtime, or embedded as a resource). Obfuscating this file simply makes it more difficult for ...


43

You could define different groups of labels like issue types, issue priorities, issue statuses, version tags, and maybe more. In order to be able to see instantly to which group a label belongs to you could use a naming convention like <label-group>:<label-name>. Using such a naming convention should make managing Github issues much easier and ...


42

If your pull request got accepted and you haven't made any other changes that you might use personally, you should delete it. Deleting doesn't harm anything. You can always refork if you need to It cuts down on useless repos in search results when people are searching for something If you use your GitHub as a sort of resume for potential jobs/contracts, it ...


40

You are technically correct -- no real need to push if you aren't sharing the code with anyone. Then again, your laptop has a hard drive made by the lowest bidder. Your house could burn down before the hard drive fails. You might want to look at your code remotely. Or even share it with someone. Now, with Github, they require everything be public or you ...


40

Membership in an OSS project is not the same as a funded, corporate team where people are interviewed and chosen. The source is already out there (it isn't open source otherwise). Tell them to send in some patches. If they are good patches (and you must review them first), commit them. Once the prospect builds up trust and a a history of making valuable ...


38

Most of the CLI-only features only come into play when you accidentally get your repository into a weird state and want to fix it. On the other hand, the most common way to get your repo into a weird state is to use advanced features you don't understand. If you stick to what the GUI provides, that will cover your needs 99% of the time. The other reason ...


36

I've used GitHub profiles, twitter streams, and blogs all as indicators of quality in programming interviews/candidate screening. They all generate different signals in their own way. 9 out of 10 applicants have never submitted a single patch to a single open source project. Even updating broken documentation puts you into an upper echelon of developer. It ...


36

I'd be insanely leery about putting my company's intellectual property on someone else's servers, no matter who it is. Is GitHub Enterprise out of the question for your company? AFAIK, it deals with all of these types of potential security risks out of the box.


35

Markdown is a simple syntax for providing semantic info and representing common formatting in plain text. Daring Fireball has a awesome syntax guide for standard markdown. GitHub then uses a variant of this that they call GitHub Flavored Markdown. To set up your readme just create a plain text file and name it README (or README.md / README.markdown) and ...


33

In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub. When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...


30

Of course it is OK: it is hard to imagine that over 4,098,118 projects currently hosted on GitHub would all be 100% great and useful! You are not forcing anyone to use your code or even to look at it. If you host the project primarily for yourself, the quality of your code is of concern to you, and nobody else. You listed all the right reasons to host your ...


30

The "Fork me on Github" badge is meant to show that it the project you are granted the right to contribute to the project or use it as a starting point for your own project. It kinda shows that "it's a collaborative project and that you're welcome to add improvements." It allows you to play around with the code or make a spin-off of the same project ...


29

1) To pull in somebody else's changes, first add a remote that points to their repository. For example: git remote add soniakeys https://github.com/soniakeys/goptimize.git Then, you can fetch those changes into your repository (this doesn't change your code, yet): git fetch soniakeys Finally, to merge those changes, make sure you're on your master ...


29

If there was a benefit, it would merely be painful. But nothing sucks worse than painful and pointless. Just have the single personal account. Two reasons: Github has incredibly good access control in their organizations. If an employee leaves, you can instantly remove their access. If they had a company account, you'd have to reclaim the account somehow ...


28

After a quick test, it is possible to attach an issue to your own fork of a repo. Here is what I did : Fork a repo (duh!) Go to the Settings page of your fork. Check the box next to Issues You can now file issues on your own fork and they will not be placed in the main repo. Pretty straightforward, isn't it?


28

So that you have a clear and concise git history that clearly and easily documents the changes done and the reasons why. For example a typical 'unsquashed' git log for me might look like the following: 7hgf8978g9... Added new slideshow feature, JIRA # 848394839 85493g2458... Fixed slideshow display issue in ie gh354354gh... wip, done for the week ...


27

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future? Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major ...


27

I'd go with option 4: explain to the contributor why his pull request doesn't fit the project's goals (and in the process give the contributor a chance to explain why he thinks it does) and ask him to resubmit a new version containing only the changes which fit the project. This has two benefits: You don't have to do the work ;-) The contributor will get ...


26

If you want to message them via GitHub, why not use Mention Notifications? Open an issue on your own repository and mention the forker in that issue. The issue should be relevant to the stuff you want to pull, so you can discuss the pull request they need to send. Something like "@JohnSmith has already implemented this feature - can you please make a pull ...


25

Most HR screening these days done by recruiters and corporate HR departments is automated resume reading. A human never sees your resume/application. A computer program that searches out keywords in a plain text, HTML or Word document determines if your resume matches the specified job criteria. If it's a match, a HR person, who knows nothing about GitHub ...


25

The major difference between Gerrit's and GitHub's workflows are how changes are modeled. In Gerrit, every commit is a change that stands on its own. Although Gerrit will show you the relationships between commits, reviews are performed on a per-commit basis. Teams that are good at breaking large changes down into small, self-contained commits are likely to ...


25

You've worked really hard on this. Congrats on all the attention, but sorry it's not engaging. The first thing I notice is there are no issues. To get people to engage you have to be visible in their GitHub news feed. When you start an issue it'll show up for people following the project (not the ones who starred it). So you're community size is actually ...



Only top voted, non community-wiki answers of a minimum length are eligible