I have to maintain a base version of code and different "variations" of that code with client specific modifications for different clients sites.
It would be much easier to force all clients on the same variant, or have a super variant that encompasses all clients' needs. However that is not the nature of my world and I can't change it.
Given this environment, what is the best way to use github?
I can create a separate repository for each version. I can create one repository with separate branches. In either case I see how I can use github as a storage medium and version control for each variant, but I don't see how I can use github to help manage the code divergence.
thanks
Based on your question I would recommend a single repo, with a master branch. You can use other branches for the "variations".
The tricky part is when a commit is made to master that won't cleanly merge into another branch. You can do a merge commit with git merge, but I prefer to do a git rebase onto the new HEAD of master. This way people using master could easily pull in changes from that branch.
Related
Related
I work for a small company that currently has only two developers. I'm not an expert with GitHub and I know that our current workflows aren't necessarily standard. I'm not looking to re-design our whole workflow, just a reasonable solution to this specific challenge:
We have two main branches: Development and Master. We use the Master branch for client installs, so it is always behind Development, until we merge the two before a major release.
Due to the nature of our software and target market, it is important for us to be able to periodically apply custom code for specific clients to the Master branch between releases so that it is ready for their use when we install. We also need to apply these changes to the Development branch so that they are included in the next release. This custom code is included in all future client installs/updates, but only accessible to the specific client based on configuration settings.
My current solution is to create the "Custom Feature" branch based on the Master branch. When the custom work is done, we will create a pull request for both the Master branch and the Development branch. Since the Master branch always has the same code as development, just in an earlier state - this seems to me like it should work. But like I said, I'm not an expert with GitHub and I'm sure this could be dangerous for any number of reasons.
I know it's risky to apply these types of periodic changes to a live release branch. However due to the nature of our software, most of our clients expect at least a small level of customization when we install for them.
Edit
I'm aware this is very similar to this question:
Avoid merging master into development branch
But I'm proposing branching from the release branch rather than the development branch, so I think it's a different case (I'll admit some of the concepts from that question go over my head though). I apologize if this is deemed to be a duplicate.
I recommend getting familiar with GitFlow as it might be a solution to your problem. https://datasift.github.io/gitflow/IntroducingGitFlow.html
Basically, you are right, the correct way to do this is to branch off from master, create the change in the branch and then merge to master and develop. Follow the "hotfix" section in the attached link.
Sorry if this isnt the correct forum to post a source control related question, but i wasn't sure where else to ask.
So im setting up a git repository for my team - developers & artists. Gitlab is our host and sourcetree is our client.
How is it possible to set it up in such a way that our artists arnt required to pull all the developer commits, and the developer's arnt required to pull all the artist commits. Because this is currently what happens when we are all working on the master branch.
Would the best way to achieve this be different branches(master, dev, art), set up multiple repositories or is there a better way?
Thanks ~Scott
If the code which the developers and artists are contributing is ultimately being used in the same software product, then you probably want to be using a single Git repo. As for avoiding integrating changes from the other party, you really can't completely avoid it.
A simple suggestion is along the lines of what you already mentioned, namely having a separate dev and art branch. During each sprint cycle, developers and artists would contribute to their separate branches. At the end of the sprint, someone familiar with Git and the entire codebase, such as a dev ops person or maybe a developer, could merge both branches back to master. Then, he could spawn new feature branches for the developers and artists, for the next sprint. This approach could largely shield each party from having to worry about the work the other is doing.
We use Mercurial as source control, mainly using named branches for major features that we close and merge into the development branch once finished.
Recently I had two divergent solutions to a particular problem. I couldn't decide which to chose as both had their pros and cons, so I implemented them both but had to chose one to be merged into the main branch.
The second implementation is not intended to be merged into the main branch ever. But I still want to keep it just in case it might be useful some day.
One obvious solution is to just open a named branch for each. Close both and just merge 1 into the main.
But this leaves some sort of "clutter" into the source tree.
Are there any other alternatives or best practices?
We at RhodeCode use completely bookmark based solution, and pull request functionality.
We use rebase as merge strategy, this leaves the commit graph nice and clean. If we need to track changes you can always get back to original pull request and see what was the development process including CI tests/code comments.
Bookmarks are in our view much better option since it's a lightweight pointer, this allows you to do easy rebases/commit squash and simply then push new bookmark pointer and update the pull request with this info. This combined with Mercurial's phases support give a really nice way of working with new code submissions. (Public in main repo, drafts in forks where the commits are coming from)
We so far did few thousands of pull requests internally developing RhodeCode itself, and we all agreed with the team it's the most flexible and also simplest process.
I'm not sure what's the best Mercurial workflow for what I'm trying to accomplish, so I'm looking for any tips and ideas.
Main development happens on a master repo, and I have many customer specific repos that are nearly identical to the master, with few tweaks here and there specific to the needs of that customer.
My current workflow is to have a named branch in the master repo (name: webapp), then clone that repo for each customer. Each customer repo has a named branch (name: customer#), and then I periodically pull from master repo, merging the two branches (webapp and customer#) and tidying up conflicts.
Is this the best workflow for what I'm trying to do, or is there a better way to track an upstream repo with small tweaks added for every clone?
This is the textbook case where feature branching (which is what you're effectively doing) is a bad choice. Rather, consider branching by abstraction, which is not branching in DVCS sense, but rather branching in code.
Not "better"|"worse", but slightly different way may be using MQ (and single mainline without branches) and mq-patches for customer-specific changes instead of branches in different repos.
In extremal case it can be single repository with core in permanent changesets and set if MQ-queues (queue per customer) and pull|merge|resolve will be replaced with pull|apply path|resolve|save edited patch
As far as I can see, there is no simpler or easier ways than your current approach.
The real difficulty is not a problem of branching/workflow strategy, but a problem of your overall code structure: I mean you have potential conflicts between the main and the custom branches (or versions). This problem won't go away automatically by choosing a "better" branching/workflow strategy. Because it's essentially a problem of code, you have to tackle it at the code level, either by resolving the conflicts manually during the process of merging the main to the custom branch, or by insulating the various customizations from the main code so that any change in the latter won't affect the former. Either way obviously has its pros and cons. If mergings and conflicts happen very frequently, you would like to consider to adopt the second way; otherwise, your current approach is just fine IMO.
Currently we are using SVN.
I would like to start using GitHub, but one absolute requirement is that we will need to have precommit (premerge) validation of the code like we currently have. Does GitHub support precommithooks (premergehooks)?
We're a team of 5 developers. We made an agreement that all code (JavaScript) should pass JSLint-like validation. Voluntary validation has proven not to work because it's easily forgotten. How can we be sure that code that becomes available to the others is guaranteed to validate against JSLint (or similar)?
The concept I was looking for was the prereceive hook
I don't believe github supports pre-commit hooks. However, the git core does. You could set up the pre-commit hooks locally, or apply them as a test before merging branches into your main github.
I think you're missing something fundamental about git. It's not a centralized model (well ok, it can be, but if you're going to use it this way then github is probably the wrong approach). If you're using github, the right way to do this is:
Host your main repo
Have your developers each create their own fork
Let them happily hack away, committing and pushing to their heart's content
When they think a feature is ready, they send a pull request to you (the maintainer) which you yourself verify on the side to ensure stability. Then you merge / rebase their changes into the main repo.
Naturally there are many ways to skin a cat. But when you're talking about "real git" (the kind employed by the open source community), the centralized "check-it-in-and-it-damned-well-better-work" model is kind of difficult, especially when it comes to larger projects.
I think this article describes a very good workflow that could be a basis for automation:
http://scottchacon.com/2011/08/31/github-flow.html
The main idea is that you use pull requests as mentioned above, but you can also have a service that can use the github api to fetch or pull the branch making the request, merge, test, validate then push to the target branch.
No, GitHub doesn't support pre-commit hooks. How would that even work? Committing happens on your computer, do you really want to allow GitHub to run arbitrary code on your machine?