316
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 with Monica
8,3653 gold badges35 silver badges43 bronze badges
210
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 ...
165
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
...
151
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.
144
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 ...
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 ...
116
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 ...
110
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 ...
108
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.
101
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 ...
93
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 ...
85
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 ...
79
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 ...
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.
70
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 ...
68
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 ...
63
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 ...
57
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 ...
55
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 ...
55
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. ...
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.
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 ...
49
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.
...
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 ...
45
Deleting forked repositories will erase history from your Pull Requests.
Deleting a forked repository will delete any information associated with your repository. This can retroactively affect any references to your repository, including pull requests that have already been merged. (See Pull request displays "unknown repo" after deletion of fork)
Your ...
45
The whole "don't store binaries in source control" is set forth for a specific reason: If you have source code that compiles, don't store the actual compilation, but just the source code. Images and visual assets do not have a "source," so they should be tracked in version control.
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/...
42
You should look at git-flow. It's an excellent (and popular) branching model.
Git Flow Summary
Branching
The main trunks that stay around forever are develop and master. master holds your latest release and develop holds your latest "stable" development copy.
Contributors create feature branches (prefixed with feature/ by convention) off of develop :
$...
41
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
