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.
Related
I am studying how to use GitHub to collaborate with other people.
I have already set up Collaborators for one of my project and they have been able to download it.
But I don't know how to go for the next step. In other words, after they make their contribution; how are they supposed to upoad the result of their work, so that I can get it?
Yes indeed, by following the guides I have been able to make an update to a test project.
But everything is not quite clear yet.
I follow the process of creating-a-branch -> editing-something -> creating-a-pull-request -> merging-the-branch.
Then I delete the branch since it is no more needed. Apparently it works, but I can still see the deleted branch after, so it doesn't seem to be really deleted.
Starting July 2019, using GitHub Desktop, as part of its epic "branch pruning" and its 2.1.0 release, will prune those remote tracking branches for you.
Branches that have been merged and deleted on GitHub.com will now be pruned after two weeks.
See desktop/desktop issue 750:
We decided in taking a very conservative posture that we would only delete branches that aren't actively in use (hence the 14 days requirement) and don't have anything on them that's ahead of the default branch on GitHub. This combination, in addition to the branch being deleted on GitHub.com, seems relatively uncontroversial, but we're definitely going to listen to feedback we receive in the weeks and months after this ships to make sure it aligns with people's expectations and isn't overly aggressive.
Because we've taken an extremely conservative approach here, we don't intend to provide the ability to toggle it as a setting.
If you use a particularly branch frequently, this will never prune that branch, and it's restricted only to branches where there is no additional work that hasn't been merged into the default branch on GitHub.
In other words, we set this up intentionally such that users should never lose any work, which is our primary concern when deleting things. Hope that makes sense, and appreciate the feedback.
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.
Is it possible to create new branch directly from Issue which is posted on Github? We have project hosted on Github with many issues, it would be easy for us just to click one button in Issue web interface and create new branch for it to start developing.
This is not possible directly from the issue interface. I can try to provide you some workarounds and maybe start a debate why one would want this feature:
Creating branches directly on the web interface
After you've noticed that you need to start working on an issue you can just go to the repository main page (keyboard shortcut gc) and create a branch with the name you want:
Chrome extensions
If this is a must for you, you can create a chrome extension that augments the UI and creates a branch directly from the Issues WebUI using the GitHub API. There's a lot of open source extensions that augment the default WebUI.
Is it the most efficient way to start a new feature?
I think this changes from developer to developer, but having worked with GitHub for 7 years using Issues I've never felt the need for this feature because unless it's a one line change that doesn't require local testing or compilation, I still want to get down to my command line and IDE. If I have to do that, I still have to at least git fetch to get the branch I just created directly through the issue interface. If that's the case I've always preferred to just look at the issue and run git checkout -b branch-name, optionally with git push if my team needs to see the branch.
Then the issue name wouldn't normally translate to a branch name, at least I wouldn't want that. So that option to create a branch from an issue would probably need to spin out a prompt to allow me to name the branch what I wanted.
This is just my personal opinion and nothing else, hope it helps :)
GitHub finally added this feature request to their roadmap.
Summary
The branch is the first thing a developer creates when the start
working on a new issue. Creating that association makes it really easy
for someone to then follow the work happening and keep everything
connected as they take their idea to code.
Intended Outcome
We want to help developers get started on work faster and signal to
their team where to find the code changes related to an issue. It
should also be really easy to then follow development to the pull
request without the user needing to do additional work to link
everything together.
How will it work?
From the issue page, a user can quickly create a branch with an
auto-generated or custom name that becomes associated with the issue.
They can then fetch the branch and switch to it in their development
environment and further development changes (such as commits and pull
requests) are automatically associated with the issue.
https://github.com/isaacs/github/issues/1125
Nope. You can subscribe this issue.
You could accomplish this by creating a small script.
I'd start by leveraging the Issues Event webhook. This will fire a JSON payload every time an issue is opened. When the webhook fires, your script can then create a new branch using the Create a Reference API endpoint. Note: URL must be formatted as heads/branch, not just branch.
There is an app that automatically creates branches for issues. You can install it here for free: https://github.com/marketplace/actions/create-issue-branch
If you want to create the branches manually instead of automatically:
It does not enable you (directly) to click on create branch from the issue. Instead you would have to write a comment in the issue consisting of: /cib. If you do that, it automatically creates the branch from the issue.
Please note I have no affiliation with the app.
Recently I saw that Github finally added this feature to its Issues Panel.
All you have to do is navigate to an Issue on Github and scroll down to the following section:
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.
I am after some advice / guidance on how to deal with a source control issue. Historically we have everything under SVN in the one dev branch and a release branch. We have one section that contains a lot of the content files as well as images and CSS files. We do make changes to the files in these folders sometimes, normally the CSS files. Our client also has access to these files as they do part of their CSS and general content management them selves.
We have now taken this folder out of the main dev branch and moved it into its own "resource" branch. This has taken it from over 3GB to under 1GB in the dev branch.
We are in the process of setting up TeamCity and getting as much as possible automated. Our issue is how best to deal with the clients making changes and pulling them back down into our dev enviornment, also how to push our changes up without conflicting with their changes. Obviously this can be done manually but we want to get away from this time consuming model and automate as much as possible.
We are happy to except that we can make the assumption that the clients changes take precedent over ours. I have got as far (in thinking about it, not implementation), to say that we have another branch "dev-resources" and we do a nightly pull from the clients resources branch and merge them together. Not 100% sure what the best way to automate this is, for example conflicts, making it choose theirs and then flagging this up so we know there was an issue, or getting it to fail at the point of a conflict.
The next issue is how to push our changes up to the clients resources branch.
I cannot see any process that would be fully automated due to conflict issues but if we can automate 90% and can make it visible when there is an issue that would be great.
Thanks