Sorry for this novice question.
What a want to do: I forked a website (superman.github.io) to write upon it and making it my website (batman.github.io).
Someone can help me with, How can I do this?
As a novice I have only changed the name, what's the next step?
Make changes..test.. then commit and push it(only when you are sure that you have done one significant change or corrected something or added feature). If accepted your changes will be accepted.
This is the general cycle. You can try to learn why we use github?
The sole purpose is to version control. So after you forked it you work on your local copy (by cloning of course) and commit multiple times but when you think you have added a feature or corrected something on the code then you will push it to the original repository. Then make a pull request to remote original repository. If accepted then you be happy.. you have contributed something significant.
Related
I have always worked alone rather than in a Dev team, so this has never been an issue
I am about to take on someone else to code with so some kind of versioning control is required
I have been looking at GitHub and integrating it with Netbeans
I can make changes and commit them no problem.
I was expecting to be able to ‘check out’ a file or files which would prevent the other user(s) from editing those files while I was editing until I commit the file and check it in
Is this the normal procedure and I am missing something, or is my understanding of GitHub incorrect?
it does help with some general understanding, but is there anything to stop one of us editing a file the other one is currently editing?
No: with a decentralized version control system, there is no (optimist or pessimist) locking mechanism possible or desirable.
The reconciliation is done when you are pushing your local work to the common remote repository: if other commits have already been pushed, you will have to pull first, merge their work to your branch (or rebase your branch on top of their work), test locally and, if everything is still working, try and push again.
Minimizing conflict and avoiding multiple team members are working on the same set of file remains an organization and communication issue.
I've got my first repo that people are interested in contributing to, but I'm totally lost on how to set up the repo so that it respects the Git Flow methodology I've been using while coding by myself.
What do I need to set up? Should I set the default branch to develop instead of master? Do I just need to instruct contributors that they need to use Git Flow and please create their feature under feature/, and submit PRs that way?
Okay the following are my personal thoughts and others might have different ideas :)
I always set the default branch to develop.
I manually do the PR's from github.
I select command line instructions in the PR and download the patch.
I create a feature branch myself, apply the downloaded patch, check the work and fix things if needed (code styling for example), and finish the feature.
Like I said, others might have different ideas about it, but this works for me.
I forked a repository (blog theme) on github, I want to make some changes to it and use it as my site, but I don't want to push those changes to the genuine repo, since the creator probably will not be interested, is that OK?, I mean will this brake any rules?, of course in my readme file I will give credits to the owner etc.
Should I just fork it or is better to clone it locally and then push it on Github as my own project, with credits to the legal owner.
Thank you
Unless they added you as a Collaborator on their repo, you wouldn't be able to push changes to the original (although you could submit Pull Requests).
It's probably more of an "informal rule" that you should fork, but you wouldn't be breaking any rules if you just made a new repo - unless you were violating the license or copyright of the original work.
A benefit of forking would be that you can more easily incorporate future changes to the original author's theme back into your fork (ex. if they fix something that you didn't notice was broken, future new standards compatibility, etc.)
Other benefits of forking include: let the original author know that their work really was useful to someone and let others see that it has been forked, thus validating the usefulness of the work if they're considering using the original work, etc.
So, while the original author might not be interested in your work specifically, there are benefits to you and the community to forking.
I've assumed maintainership for a given project on github. I've done so by cloning the repository of the original authors and pushing my own changes and developments. This was done in accord with the original authors, so they do not expect to work on this in the future. Nevertheless, my repository is marked as a fork of theirs, which makes it appear less official. Is there some way to denote a given repository as official? To swap the relation between my repository and that of the original developers?
I guess I could delete my repository, then ask the original devs to transfer theirs to mine, then let the original devs fork from that, then push my own changes from my local repo. But somehow this feels wrong. It would rely on my local copy. Migration of e.g. the pages branch might be causing extra trouble. I hope there is a cleaner solution.
There doesn't seem to be a clean way to do this.
It seems your best option is to ask GitHub support to convert your repository to "normal mode" as opposed to "forked from" mode.
Another solution is to delete and recreate the repository. However, this can be dangerous, as the wiki and issues data will also be deleted in this process.
If you have further questions about this then let me know in comments and I can amend my answer.
I just started using github.com and my friend and I are working on a project. How can I pull parts of the project but check out certain files I'm working on so he doesn't work on them. He can still download the files but he won't be able to open or edit them until I upload them back and give permission?
I suppose you mean lock a file when you edit it. Git won't let you do this and it's not something you need to worry about. Instead, you can both work on the same file and then merge your changes later.
If you really want to work that way (i.e: lock files, or at least control when your friend will modify your repo), you can ask your friend to fork your repo.
That way, he/she:
will have his/her own copy of said repo
will work on any file
will rebase first with branches fetched from your repo (added as a remote on his/her fork, as described in GitHub: working with remotes)
will make pull request, allowing to decide what to include and when.
Historically version control systems provide a checkin/checkout feature. When you do a checkout, you reserve the artifact. If another person also has the same file checked out, then you get an error when trying to checkin the artifact. Not sure creating another fork is really the equivale