I have a GitHub repo that has multiple contributors making changes at the same time. I'm having conflicts with merging pull requests because by the time someone wants to submit changes they've made to be reviewed, someone else who had been working on a portion of the code in the same file will end up having an outdated repository on their local device. Whenever they plan to make their pull request with the changes, the repository had already been changed.
What is the proper way to submit changes through the command line before making a pull request to ensure you have the updated repository and the changes on your local device arent removed by re-pulling?
How should I properly be instructing my team to make changes to my repository while avoiding conflicts of files being updated?
What steps should I be taking when reviewing pull requests to make sure I am merging properly?
This is a very common scenario with version control tools like GitHub. There is NO solution to avoid merges completely, being in the same repository but there are a few ways that can help you reduce merges:
If possible, restructure your repo and make it modular for different teams.
See if you can use the concept of a common library and rearrange contents in various smaller repositories.
THE BEST way is to ask all contributors to make small and very frequent changes. This will increase no. of pull requests but it will make review quick for reviewers. And you also need to ensure there is no pipeline being formed for pull request review.
Thanks!
Related
I'm not sure if it's an appropriate question here, and I haven't found another related question.
I'm new to programming, and I save my work every day, updating my repository with GItHub Desktop.
Is OK to do that? Is this good practice?
Is there a better way to keep saving my work on a daily basis?
it’s perfectly fine to push your project to origin and that is one of the reasons for git as it keeps your work safe. Further, having frequent commits during stages allows you revert back to those commits when you make a mistake or something goes wrong.
Although when it comes to best practice you should create different branches in your GitHub project and merge those branches into the main branch once it is in a complete state so your main branch is always a functioning product. Here’s some further reading on this:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
You may also want to explore more of the GitHub docs.
Git can become quiet complex especially when working with other people so it’s useful to get in the habit with following branching structures and writing useful commit messages. Also you’ll often find different organisations have specific rules to this and you’ll have to understand git enough to work with in the way your team does.
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.
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?
I've done a lot of reading, and have been trialing GIT, GIT Tortoise, Tortoise SVN and PlasticSCM, to find the right source control for our small team (5-10 users).
Some background on our team: 6 copy writers/editors (2 remote), 2 developers, 2 graphic designers. We are not always working on projects together, sometimes up to 5 of us might be working on a given project. I'm unconcerned about the developers with DVCS, my concern is mainly around the other roles who are (in the nicest way) limited in their technical capability. Some of our copy writers update multiple source files (HTML, PDFs and adding concept graphics) to live, unversioned build directories (backed up as build.23.06.11.new.new.final.zip!). The copy and GD team will not have time, or to be brutally honest, the inclination to merge/resolve conflicts, or probably even remember to switch branches.
A few SO questions have shed light on what what seems to be a fairly consistent approach - main trunk (no junk in the trunk!) with teams having their own branches, and having release branches etc.
Every time I've re-read the links...
https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team
Getting started with Version Control
http://svn-ref.assembla.com/subversion-how-tos.html
...and google in general, I still end up asking myself the same questions:
Is it a Bad Idea to create role-specific branches for "trouble points" (copy team), where they can push to the repo, then our developers will merge their work into the actual project branch?
Should I still try to enforce a task-per-branch for everyone else?
Should I do task-per-branch for everyone but let the copy team create very broad tasks?
Is there usually a team/group/person who is considered an "admin" role for a repo who does crucial merges?
(is there an alternative suggested workflow where copy writers don't touch source?)
Unfortunately, the copy teams play a vital role in updating files which in turn affect layouts and all sorts of things, on a continual basis during dev. Its not like I can keep them in a bubble until the end of a project and chuck their work in.
... the good news is that hopefully, after a number of years, I'm ready to force everyone to move to version control! We've also settled on PlasticSCM for its intuitive GUI and Windows integration.
The best answer to this question would try to answer the 4 points above - tackle point 5 if you like - explain weak points if possible, and provide advice, gotchyas, etc.
cheers!
So basically you want to know how to get team-member of different skill-levels to use SCM and play nice with each other.
Buy-in from your team is priority #1. If you can't make them learn it, then you're left with providing a path of least resistance. So you really need to be flexible. There might be a wrong-way and a right-way to use the tool, but if the users won't accept the right-way, then the wrong-way is better than them not using it at all. How you achieve this balance is going to be different for every team.
Is it a Bad Idea to create role-specific branches for "trouble points" (copy team), where they can push to the repo, then our developers will merge their work into the actual project branch?
No, maybe its not optimal, but if this makes it easy for the Copy Team, then thats what you're left with. You could probably go even further and setup each user with their own branch. Then they never have to worry about merging other peoples changes.
Should I still try to enforce a task-per-branch for everyone else?
Each dev should have a unique "local" branch, that is not tracking an upstream branch. For example, use something generic like mydev. This makes it easy for them to switch between their local code and the current upstream branch.
You don't necessarily need to force everyone to create a local branch for every task, cause in the end, you're going to want them just to rebase their working branch onto the upstream one, and commit so it just becomes a fast-forward (i.e. linear commit).
Now for tasks that multiple devs are working on, or it is a feature that involves groups of smaller commits, then yes it does make sense to force them to create a new specific task branch. When they merge they can make sure to force a merge-commit, then it is clear that a set of commits are grouped together and all were part of a specific task. The merge commit will display like merged branch feature-X.
Should I do task-per-branch for everyone but let the copy team create very broad tasks?
It's really up to how much buy-in you can get from the Copy Team. I think if they really get confused with the DVCS tools, then you have to scale back until you can find something that does not cause too much of an impact.
One solution, is to have one of your devs help integrate the Copy Teams changes into another branch that everyone else will look at. That will help offload the learning-curve of the tool onto someone outside of the Copy Team.
Is there usually a team/group/person who is considered an "admin" role for a repo who does crucial merges?
Yes, this makes sense. However the great thing about SCM, is that everyone will be able to go back and do a code review on a merge. So if a merge breaks the code, you can either append the corrections after the merge, or remove the merge, and do it over.
(is there an alternative suggested workflow where copy writers don't touch source?)
Well, one possible technique is the Integration Manager model. The developers commit changes to their own share repos, but its up to the integration manger, to merge in the changes to the blessed repository.
I'm sure there are other methods that might work for your users, but this question is slightly ambiguous.
I am working on establishing a workflow at my company if we were to migrate to DVCS (most likely Mercurial). One of the things I would like to do is to have a repository for QA. The idea being that each developer works on a branch and when they are done the branch is pushed to QA. From there the test team can do their testing and report back any bugs. Once the branch is fully tested and acceptable it will be pushed to a staging repository where the merge back to the mainline will happen before pushing to the central repository.
This can work quite easily if everyone just communicates the status of their work in some way, but I know this doesn't always happen as you would want it to. What I am worried about is branches in the QA repo waiting around but nobody knows if it is waiting to be tested, currently being tested, waiting for fixes, waiting to be pushed to the staging area etc. So what I am looking for are ideas of how a status can be added to a branch? What would also be good would be to do it in a way that we could use hooks to also notify people of changes in the status.
Any ideas would be appreciated.
Unfortunately I think you need a different system to keep track of this part of your workflow.
A repository consists of things that aren't supposed to change all willy nilly, yet the current Q&A status will by necessity change orthogonal to the contents of the repository.
Let me rephrase that. You have 10 changesets in the Q&A repository, ready to be tested. Exactly what each tester focuses on, the status of each test, etc. will change, even though those 10 changesets stay the same.
I would definitely try to use a bugtracking system where you can integrate the repository history in some way, even if it is just by linking an issue in the system to its changeset.
I notice your comment about not getting support for buying Kiln, but there are other systems you should be able to integrate that would give you something similar.
I would very much resist trying to press Mercurial into service of something it wasn't built to support, trying to use tags for this would fail miserably, and bookmarks would give you problems, as you've already noted.
So again, try to find a separate system for keeping track of Q&A status.
One simple method might be to keep a metadata file in your repo's root folder, named .teststatus or somesuch, that looks like:
# branch-name, last passed revision
default, 0123456789ab
stable, 0123456789ac
bobs-dev-branch, 0123456789ad
marys-dev-branch, none
Using tags or bookmarks would feel like a sort of abuse, here. You couldn't use the same tag across branches (e.g. passed would have to be stable-passed), and tags are generally not moving. Bookmarks, on the other hand, are intended to move, but you still have the branch-namespacing issues.
Joel Spolsky, one of the founders of this site, produces a program called FogBugz that is integrated with Mercurial and makes it easy to keep track of everyone's status.
I'm not completely sure how your workflow works, but here are a few ideas:
Tags.
Use named branches and close the branch when tested.Typing hg branches will show you which branches are still pending.
You could probably use an incoming hook for the automatic notification of new changesets being added to the QA repo.
Why would a developer push something to a QA repository if it wasn't ready to be QA'd? I think the act of pushing changesets to a QA designated repository should be the signal that the feature is ready to be tested.
Feature branches by cloning is my favorite approach.