Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just curious as to what the general consensus is for committing code of GitHub.
Should you commit only build-able code? Or is there a time when unbuildable code commits have their place?
Or am I totally miss-understanding GitHub completely? If so, please inform me how it should be?
If the master needs to stay buildable, I recommend that you make a branch, and merge the branch only when the code is working as intended.
GitHub is a place for sharing your code to everyone, it's your wish if you want to make it public for everyone to use or contribute or keep it private.
There are so many advantages in uploading code to GitHub :
1> Others can look at your code for reference and can also contribute to it
2> It keeps all your coding records with history so you can show them to your company when you apply for a job
yes, you can also upload unbuildable code and open an issue and wait for anyone else to fix it.
and it's a good practice to keep 2 branches one for buildable code (master branch)
and another test branch for testing stuff
In general for git, the master branch is reserved for only buildable features. Other branches can be reserved for in-progress features to be later merged into the master branch once completed and tested. GitHub, for the most part, follows these rules too.
To me, it really depends on the kind of project you are working on:
If the commit is for a private project, (and therefore probably has little following) you can do what you want
If the commit is for a highly visited project, maybe think twice before submitting unbuildable code without making a note in the commit message that it is unbuildable
As always, if you own the repo, you can follow any rules you like, but if it is owned by another individual, be sure to follow the rules that they set out for the repo.
It just depends. Some argue that all commits should compile or be "build-able", but IMO that defeats the purpose of frequent commits.
Typically, when I'm developing a project my rule of thumb is commit after 20 minutes or so of developing, and push every hour or when I finish the branch/feature I was working on. So if you are working on a project individually, then committing with issues in your code may not raise any problems. Committing frequently is the whole purpose of version control applications like Git, and you have the ability to go back to any previous versions whenever you like. If you are working on a project with a team there may be some guidelines as to when you commit/push, so make sure to check with your team if that is the case. Check out What are the differences between "git commit" and "git push"? if you are trying to better understand Github.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
I am a newbie to both StackOverflow and Opensource contributions, excuse me if I didn't put it correctly.
Here's the question :
I heard some contributors saying that you need to clone the open-source project's code to your machine to be able to contribute to that project, And at the same time they say that you fork it.
I don't understand why we need to clone the code when we can fork it. Or both ways are fine?.
Please help me with this.
On GitHub, a fork of a repository is a copy of it that the owner (in this case, you) controls. That lets you make changes to it by pushing additional branches containing code, and then, if you want, to make a pull request from your fork into the main project, requesting that the owner of the main project include the code from that branch. Both the fork and the original project are Git repositories that are stored on GitHub.
Technically, you don't need to clone the code from GitHub if you've forked it since you can just edit the code in the GitHub web interface. However, practically, people prefer to write code on their own machines with their own editors and development environments. Usually you want to test the code you're writing as well, so you need it to be local to do that. So typically, you clone the repository to your system, create a branch, and make changes there. Then you can push the branch to your fork on GitHub, and then, if you want, create a pull request to the main repository.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am struggling with figuring out a good method for handling my work flow using Mercurial. I have read many related questions here on SO and other places but couldn't find a reasonable solution.
Suppose I have two branches:
the default branch I do normal development in. Deploying releases from and marking them with release tags
a branch for a specific customer that is maintained separately. It runs on a separate version number, branched from an older version of the application.
These two branches are mostly identical now but there are already some differences. Over time, they will drift apart more.
It means that I have 4 types of source files:
Type-A: Files that remain identical in both branches (changes, if introduced, should be present in both). These are most of the files.
Type-B: Files that are only in the default branch and do not need to be merged into the customer branch
Type-C: Files that are only in the customer branch and do not need to be merged into the default branch
Type-D: Files that are present in both branches, have shared code but also contain code that should remain separate and specific to each branch
Development done on the default branch and there are regular releases which are mostly incremental. But I also have these two scenarios:
Some changes done to the default branch, need to also be merged to the customer branch (e.g. a bug or feature that need to be fixed/added to both).
A "hotfix" done to the customer branch and cannot be immediately merged to the default branch but needs to be merged eventually at some point.
Problem is that I can't figure out a reasonably simple, clean and safe way to support these two scenarios. Mercurial doesn't have the concept of partial merges or ignoring files on merge. It merges changesets but it insists on including the files that were introduced in previous revisions.
Merging default into customer branch or customer into default in these scenarios forces me to add files of Type-B and Type-C. Making a change to file of Type-A that doesn't need be added to the other branch (making it Type-D) introduces a challenge.
Now obviously I can work around some of these problems by using compiler defines (thus keeping source files the same in both branches), editing code manually and manually removing files after merges but this doesn't feel like the most efficient and clean way to handle this.
Surely this is a common enough work flow that wiser people than me already figured out. Can anyone suggest any method or best practices that can streamline the work in these scenarios? Or is there something fundamentally flawed with my setup?
Also, does Git handles these flows more gracefully?
Thanks.
I would do any development that a the customer requires on the customer branch and merge it into default. This will work for hotfixes and it is simpler than cherry-picking your development changesets from your default branch. It's easier to merge forwards rather than backwards. It also gets rid of Type-B file problem because there are no Type-B files in the customer branch.
Type C files I would merge into default and then delete on the default branch. Any further modifications to these files should generate a warning that file modified on branch was deleted on the other branch.
Separate changesets can be exchanged between branches using hg graft -r SRCREV commands
More complex and probably hard (but also more flexible and manageable) way may be using MQ and more than one queue (Queue per Type?), but even with one queue of MQ-patches with good naming convention you will not lost
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In large Libre Source software projects, versioned with Mercurial or similar DVCS tools, which of the following is considered to be more conventional:
Keeping the latest "stable" version of the software in the default branch. Tagging each release in default so you know which revision got packaged up as a download. Merging patches into default as soon as they are tested. Keeping new features, etc. in named branches to be merged into default on the next release.
Keeping each release in a named branch, or similar. Using default to keep bleeding-edge code that's only intended to be run by developers or the very foolhardy.
Or... is there some better pattern of workflow that it widely accepted?
Mercurial has a fairly strong opinion on what you should use your default branch for. It's documented in the Standard Branching wiki page. The summary is:
You should not use a name other than default for your main development branch.
The reason is that default is the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.
Even with tons of documentation that says "branch before adding a new feature" (see next point), people will forget this when they send you patches. They then have the trouble of cleaning up things by moving changesets around.
So always put the bleeding-edge code in the default branch and use other branches for your stable releases.
Don't treat branch names as disposable
Branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced. Thus you will want to give some thought to your branch names so that you don't pollute the branch namespace.
Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial and the tools surrounding it are designed to work well with hundreds of branches. Mercurial itself still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow alredy stabilized.
We have caches in place internally in Mercurial, so the problems are mostly UI problems: hosting sites and log viewers might run hg branches to load all 10,000 branches into a single drop-down menu. That is really slow and useless for the poor user that want to select a single branch from the gigantic menu.
If the branches are closed, then they wont show up in hg branches, and so the problem should be minimized. However, the tools might want to show closed branches too — it all depends on the tool.
I'm sorry this is a little vague. The main point is that Mercurial is built to scale in the number of changesets, not the number of named branches. We have addressed the biggest performance problems with named branches with the cache I mentioned before, so today I'm not too concerned about having many branches, especially if the number of open branches is kept small (less than, say, 100).
I have fallen into the habit if using default in Mercurial and master in Git for the actual work, the bleeding edge, and using tags and branches for the releases. hgsubversion and Git-Svn seem to take this tack.
There are not, in common, such thing as "most conventional" - each and every workflow is a matter of local convention and development policy in team.
I saw both mentioned policy often, and intermediate variations - also.
In case of strong testing|release policy and intensively used branches ("branch per task") "default" branch often exist only as merges-only branch (merges from feature-branches before QA-testing) and means "Code, which work with finished features, without throwing errors, but with unstested functionality".
Minor versions form named branches, each release in such branch is tag. Bugfix branches are merged after completing into "default" and active versions branches
But this workflow is just one more example, not better|worse than others, suitable for mid-size teams with responsibility separation established, doesn't work well in "chaotic anarchy" development
There's not a huge amount in it. If we're talking about just DEV & STABLE branches, which is default is mainly just a naming convention. I'd tend to have DEV as default, just because most work goes happens on the dev branch and if this is the default branch, it's less hassel.
Personally I prefer a named branch per release. Bugfixes can then go on those branches and be forward ported with relative ease to all releases after using hg merge. If you try to do the same with DEV and STABLE, you can only ever have one maintained release (the last one), or your stable branch starts growing branches and you end up with a (possibly less organised) version of the branch per release structure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm in a situation where some minor patches I've submitted to an open-source project were ignored or explicitly not accepted.
I consider them useful, but more important is that I need the functionality they implement.
I don't want to push my ideas and suggestions anymore to the main contributors, because I don't want to turn this into an ego issue. I've decided that my best bet would be just to use what I wrote for my own purposes. I don't want to fork the whole source code tree because I like how things are generally working, I'm just not happy with details.
But I do realize that the project will evolve and I would like to use the new features that will eventually appear. I understand that I'll have to merge all new things into my own source tree. Are there any best practices for this scenario?
The standard approach is to maintain a vendor branch in your repository. The idea is that you import a pristine copy of the original sources (called a vendor drop) into your local repository, and store it on a branch. This is the version of the code prior to applying your mods. You tag that with the version, then copy it to the main trunk and apply your patches.
When subsequent new versions of the vendor code are released, you check out the vendor branch (without your mods), and overlay the new version on top. Finally you merge the new branch with your mods, checking that they are still applicable/relevant, and you're ready to go again.
There can be complications e.g. with files being renamed, deleted etc. The script svn_load_dirs.pl, that comes with Subversion, can help with this by allowing you to identify files which have changed name and automating some of the bureaucracy.
This approach is discussed in detail (and much more clearly) in the Subversion book, under the section Vendor Branches.
If you are using Git, or could get used to use it, perhaps you should take a look at Stacked Git or Guilt.
They are layers on top of Git to keep track of patches.
Generally you would create a branch of the project in the repository. In your specific case, I would create a branch of just the directory that contains your code if that is possible. A lot of repositories like subversion will allow you to then check out your branch along side the main trunk. That should allow you to maintain your patches and ensure that they work with future changes that are made to the trunk.