313
You are completely abusing branches! You should have the customisation powered by flexibility in your application, not flexibility in your version control (which, as you have discovered, is not intended/designed for this sort of use).
For example, make textfield labels come from a text file, not be hardcoded into your application (this is how ...
answered Nov 9 '15 at 16:03
Lightness Races in Orbit
7,8613 gold badges34 silver badges43 bronze badges
204
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 ...
184
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 ...
150
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
...
143
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 ...
141
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
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.
130
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 ...
115
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 ...
111
3 reasons why:
According to the terms of the GPL, people accessing GitHub via the web is not considered releasing (or propagating in GPLv3 terms), and so GitHub is not required to share their source code. If GitHub was to sell a version of their service (which they might do, I haven't bothered to look) where they send you their software and you run an ...
107
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.
99
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 ...
92
Having 500 clients is a nice problem, if you had spent the time up front to avoid this problem with branches, you may never have been able to remain trading for long enough to get any clients.
Firstly, I hope you charge your clients enough to cover ALL the costs of maintaining their custom versions. I am assuming that clients expect to get new versions ...
83
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 ...
75
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.
73
You can delete your fork as soon as you submit a Pull Request, regardless if it's merged or not. GitHub stores all PRs in the upstream repository, meaning proposed changes are tracked even if the fork is deleted.
That simplifies the decision.
You may still want to keep the fork if:
You'll be contributing more right away (e.g. extend existing PR or open ...
68
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 ...
65
Why the hell not? :)
Storing binaries is considered bad practice, yes, but I never worried too much about images.
Worst case, if you have tons, store them somewhere else or use externals or an extension for binary support. And if the images won't be changed that often, then where's the problem? You won't get a big fat delta. And if they get removed over ...
65
I am a user of SVN and now I am learning GIT.
Welcome to the gang!
SVN Re-education
In SVN I usually [...]
Hold on for a moment. While CVS and SVN and other traditional (i.e. centralized) version control system fulfill (mostly) the same purpose as modern (i.e. distributed) version control systems like mercurial and Git, you'll be much better off ...
60
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 to ...
59
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 ...
57
The MIT license doesn't specify attribution beyond maintaining the copyright notice.
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
Somewhere within the source for the project you are considering forking, there should be a LICENSE file or equivalent. If there isn't, then ...
56
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 ...
54
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.
53
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 branch ...
52
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 ...
51
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 ...
49
This is a dilemma: you cannot close the issue as "fixed", because you don't actually know if it was fixed, or at least even if some issue was fixed, you don't actually know whether this was the issue the reporter was talking about. On the other hand, you don't want to leave an issue that might have been fixed open, especially if you won't ever be able to ...
47
It comes from the CI mindset where there is integration several times a day.
There are pros and cons of both.
On our team we have abandoned the develop branch as well since we felt it provided no additional benefit but a few drawbacks. We have configured our CI software(Teamcity) to compensate for the drawbacks:
Enable deployment of a specific commit. ...
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 you/...
43
This question is pretty old but this is a common question that comes up when dealing with Git and there has some progress on modern solutions to storing large files in a Git repo since the last answer.
For storing large files in Git there are the following projects:
git-annex - This has been around for awhile but frankly it's complexity gets in the way.
...
Only top voted, non community-wiki answers of a minimum length are eligible
