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.
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 have a project with a single branch, default. I have been iterating on this single named branch for some time now and I have been using tags to mark version number milestones.
The project's source code changed quite a bit between tags 1.0.7 and 1.1.0 (current). However, there are some users on 1.0.7 that need a bug fix. So I checked out the source, updated to tag 1.0.7, implemented a fix and committed. That was tagged 1.0.8, and will probably be the last commit on the 1.0.x line.
I now have two heads on the default branch. I expected that. But when I tried to push to our BitBucket account, I received a warning from hg: "push creates new remote head". Reading up on this message, I get a lot of answers explaining why the message is there and for most people the answer is just to merge. However, I don't think I want that in this case. The two branches aren't compatible.
It looks like I can just use the -f option to force push the new head to the remote repository, however this seems to be discouraged both by hg help and various posts on the web without much explanation as to why. So what is the downside to doing this? It seems as though I can still update to whatever tags/revisions I want to continue working on. If I push that head to the BitBucket account, will I be shooting myself in the foot in some way?
Having multiple heads is perfectly fine.
If there are several heads and there's little indication as to their purpose, it may be difficult for others to see where they should continue and what is the head which contains the newest developments, e.g. which gains new features.
However by using the tags on the branch with clear versioning like you do, that problem doesn't exist either.
There's one small catch though: Mercurial will, upon clone, update to the newest commit in the default branch - e.g. the head which received the last commit. If that's the 1.0.x head of yours, that might be unfortunate. However you can fix this, by attaching the special '#' bookmark to the mainline or development head. Mercurial will always update to the head which bears that bookmark, if it is present - irrespective which head has the newest commit.
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.
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
Shelved means the changes are set aside for you to work on later.
Checked in means that the changes are made available to the rest of the team, will be in the build and will eventually ship.
Very different. Think of shelving as a tool for context switching when you're not done with a task. Checking in means you're done (at least a part of it).
Shelve your changes when you want to save the changes that you have made, but need to go back to the previous version to make other changes (perhaps, bug fixes) that you want to deploy without the updates you are currently working on. Since you're usually checking in pretty regularly, I find this to be a rare occurence -- like I just deployed to the QA box and an error was immediately found. I'll shelve that day's changes bringing me back to the QA deployed version, make the update, then unshelve my changes -- merging the two as necessary. Any longer than that and you'll probably be looking to check out a previous version and branch instead. I'd be happy to hear of other experiences where shelving has proved more useful, though.
Other users can download your shelvesets by searching for them, so it is a good way to pass code around for reviews. however you will get an error if you try to unshelve code files that you already have checked out, so you need a clean environment ready.
I often shelve my changes at the end of the day if I'm working on something big that I can't check in. That way, if my PC dies overnight, I've got a backup on the server.
Darcy gets it spot on. You can also think of shelving as a private branch that is not publicly visible for the most part. Shelvesets can also be deleted completely, not like deleting checked in code. If you delete a shelfset it is gone forever.
Everyone above has said so much true and I learned allot from it.
Just to add my experience, correct me if I am wrong. In a project, we have a configuration file mypc.json specific to each PC of the developer. We usually override it when running server locally. Other team members have the same file name with different configurations in it. No one wants their file to be pushed with the same name to the development branch. So I use shelve to save these type of changes. Whenever I need these configurations I can easily apply changes from shelve and my environment configurations are back in my project.
My boss announced yesterday a new commit policies for checkins into the repository. This policies are valid for commits into head/trunk and branches.
A commit message must have the following items:
Reason (Bug ID,Project ID, or non functional change)
Name of the reviewer
After the commit we also have to create a change blog entry in our CMS.
I'm not a big fan of this commit policies, because I don't normally need a reviewer when I am doing new or experimental stuff in a non-productive-branch.
Do you have any commit policies do you have to follow?
I think it is a good idea to change the productive-branch only due to a Bug Report, but commits into the development branches should be less restrictive.
Commit early and commit often.
We actually use /trunk as development and tags to branch different releases. Only structural intrusive changes go in /branches.
We actively use tags for production and acceptation releases, so we can go back in time easily. Anything committed in the trunk should only have a message describing what the commit changed or added briefly.
I'm not a big fan of using the message space to link with Bug ID's it still requires a lookup for the ID in which case you could also look it up in the bug tracking software and close it there, which to me is about the same effort.
Not to say i dont like any svn integration:
- We use more goodness of automated nant scripts to make releases which branches them in /tags
- svn props actually store our version numbers :p.
- hook scripts for email notification and message logging (great for copy pasting release notes).
We have a number of policies, which are enforced via an in-house plug-in to Visual Studio. We check that code compiles and that unit tests have be run successfully. At the moment we also check code coverage and issue warnings for code which doesn't have enough tests. We also do various consistency checks and verify that an appropriate task is present in our change management system in order to provide traceability for all changes.
The advantage of tool support is great, as it is not really up to people to respect the policies, but obviously there's a drawback as well as these checks take time to run. However, with many developers it is hard to enforce standards without proper tool support.
A reviewer seems pointless for the reasons you mentioned, because not everything needs to be reviewed by others.
In the past the only commit policy we had (where I used to work) was to include a comment indicating what you changed and why, but that's more common sense than anything else.
A common commit policy is to associate a bug ID to the commit to trunk as a justification. Sometimes, version control and bug tracking systems are configured to enforce this policy.
Our commit policy sounds a bit like yours, only we don't enforce it on task branches (where a task branch is like a developer's sandbox for experimenting).
Our commit comments must include either a change control ID (new feature, enhancement) or an issue ID (bug fix). You must also include a brief explanation as to why you made this change; version control tracks the who, what, when and where.
My commit message include a short describtion what i have implemented or changed in the classes.
The bug number and additional describtions i put in the commentation above the new code. IDs inside the commit messages we put when we merge changes into a tagged branche.
Every night a automatic build checks the different features and products too get sure that the code base is stabil.
But in the end i think you can not have too many describtions for new or changed classes but too many policies you have to do before a commit. The name of the reviewer is something which i would not put into the commit message.
Think about that you sometimes have to undestand your code which you have implemented 2 years ago. And then you are happy about commit messages which are not like "Update after debugging".
We have branches for every released major version of the software that is still actively supported. Checking into any of these branches requires a bug ID - this is enforced by scmbug, which will not only check that the comment is prefixed by the bug ID, but will also look up this bug in the bug database, ensure it is assigned to the committer, and potentially check other criteria (e.g. that the "fix in branch" field is the branch being committed to).
One of the products has more potential to fail in embarrasing ways, and checkins to this require not just a bug ID but a code review as well. However, the criteria for the code reviewing is handled in our bug database - we have custom fields for this and the bug cannot be accepted and closed until it has been reviewed. To me this works from a conceptual level - it's probably better to check code that is believed to work into the repository un-reviewed, then reopen the bug and change it if necessary rather than hold off on committing until you're sure it is ready for release.
Other than that, there's no explicit policy for the trunk (though of course the general tenets of checking in often without breaking the build, including good descriptive commit messages, checking in units of work atomically still apply).