I am starting a new software project where the entire effort is just me (the stereotypical individual in the basement startup). I want to use GitHub, but keep it to just what makes sense.
So I think in this case, I need to:
init - Create the project with the files in that folder
Make changes
branch - for those changes
checkout - ??? Do I need to checkout my branch? Or does running brnach make this the version I'm on?
Make more changes
commit - commit the changes to the branch on my computer
merge - merge those changes in to main on my computer
push - push all those changes up to GitHub
Is the above correct? I'm very experienced with GitHub, but only via VisualStudio and where others have set it all up. And... it's been 3+ years since I've even been doing that.
Related
For a project with multiple developers where one developer controls what goes to production: This developer pushes from his own branch <his_branch>, and everyone has to incorporate their changes into his branch. His branch contains his changes and the changes other developers' changes. How do I make sure I pull down his most recent branch and work from it on my local. I have tried so many different commands and approaches, with the most recent being:
Git clone the repository (done when I started the project)
Fetch his branch
Create a working branch <my_branch> from <his_branch>
git checkout -b my_branch origin/his_branch
(I get errors)
Create my branch on remote
Fetch all including my new branch (but my new branch contains code from Master)
Access my branch locally, work on it, commit changes, create a pull request for him to review
(I don't have his latest code) and there are many conflicts to resolve
I am new to GitHub and can't find a fairly straightforward answer to this question. Typically people who answer this question, make sure they provide the most complicated solution to follow to try to impress with their GitHub acumen.
Can someone provide a straightforward answer without snark, condescension, or derision?
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
Setting up new projects and branch designs in TFS 2015. This detail may be significant - I'm using it for PowerBuilder projects, not .NET - VS2015 is used to set up branches and perform merges, the files themselves will be checked in and out in PowerBuilder. Far as I can see that shouldn't make a difference, but mentioning it in case I've missed something
Using the following sample layout:
Prod branches to/from Mod, down to Dev. New CO projects branch from Prod (so they always start with a fresh set of the latest live code), then merged (via baseless merge) to the DEV branch, and re-parented once the connection is set up. That way the users wouldn't have to remember to do a baseless merge; Dev will become the default merge target
Merges would them go back up from Dev to Mod, then back to Prod
The issue is that as a test, I tried the baseless merge after the branch, expecting no files to be merged, as nothing has changed yet in any branch. But the merge from the CO branch to Dev merged ALL files. Not an issue now since there's no changes in place, but would be quite a problem once several projects have been merged to DEV.
After that merge, I made a small change in the project and tried a merge; only the one changed file merged.
My best guess is that since the new CO branch was created after the Dev Branch, it was seen as everything in it is newer than the Dev branch, so it rolled over everything. Not sure how it would treat changes in Dev not seen in the Prod branch yet, haven't tested that scenario. It SHOULD at the very least tell me there's changes that I need to merge, but I fear it might just roll over them with the "new" files in the CO branch.
The question is, how can/do I tell the system that this new branch is "not newer" than the Dev branch? Does indeed the fact that these are PowerBuilder files somehow limit the ability of TFS of recognizing versioning in some way?
Or even more simply, is the branch layout I'm trying not the best method?
EDIT - here's the structure I'm currently using for my .NET projects - I was trying to use the layout above instead for the new code.
It uses the "Main" branch suggested below in the comments, but since I'm pulling "CO Branches" from Dev, I get code currently being tested, and not pristine Prod code. I'm assuming trying to branch and re-parent from Prod in this layout would result in the same scenario.
So is this the better way to go after all?
You may have a Main branch, which is the junction branch between development and release branches, representing a stable snapshot of the product.
You can branch from Main to Dev, Mod and Prod, when the work on Dev branch finished, merge from Dev to Main, when you want to release the product, merge from Main to Prod. So when you want to branch from the latest live code, you can branch from Main. In this way, you can merge from CO to Main, then Main to Dev or Main to Prod. All changesets will be reserved.
Me and my friend are two days into using Git now but we still lack the know-how to use it properly and utilize its full power though it is a tremendous step in the right direction, compared to using Facebook messages to sending and syncing files. We have searched over the net and most of the guides for Egit either assume you work alone or that someone else clones and branches off to their own repo. However we are collaborating on the same project (a 2D RPG) and don't know how to properly use Egit to work together. Some of the problems we face:
1. We had the exact same copy of the project, he changed some of the methods we used, I changed some of the classes and resources we use. He committed and pushed to repo first. Now I cannot push or commit or even pull because of conflicts in the files (repo vs local) which Egit complains must be resolved.
2. How do you properly synchronize code that you are collaborating on? Lets say either one of us is first out to push to repo, what must the other (the puller) do to make sure his own code is not completely overwritten, only accept parts that have changed, parts that we think should be changed.
3. Do we always have to make a (new) local branch, pull to this, see changes, and merge the changes we want with the master/main? How do you properly do this.
Any input is most welcome, we are already much more efficient with our broken knowledge, more will only do good :)
Ok here are my answers:
We had the exact same copy ... because of conflicts in the files (repo vs local) which Egit complains must be resolved.
First you should make sure you use separate branches so that you can always commit.
Then you have to resolve any conflicts when you merge.
How do you properly synchronize code ...
Use separate branches to make sure code is ok before you pull it into master branch.
Do we always have to make a (new) local branch ...
Yes, git is built on the assumption that this is the best way to work. "Everything is local"
This is the way I or we usually use branches:
Main dev branch (Master)
Project branch, used to merge in features added by this project. When all features have been added and seems to work this is pushed/merged into the master branch.
Developer branches, every developer has his/her own branch to develop a specific feature before pushing/merging that into the project branch.
What could sometimes be good to have is also specific release branches. I.e. when a project has merged all added features into the master branch and everything seems ok, a release branch is created for regression testing. This branch will eventually contain the released software when all testing has been done.
The benefit of doing a separate release branch is that the main branch can continue to be developed, but if a fast bugfix has to be done on an earlier release it can be done on that release branch and then later merged into the master branch.
//jk
I have an SVN branch and a trunk. The trunk changes regularly and the branch doesn't.
Every now and then (let's say once per week) I want to update the local working copy of the branch with the latest changes of the trunk.
Ideally I would want to do this the same way as I do it with the latest version of the branch: with Eclipse : Team->Synchronize, so I can review all changes before updating.
Is this also possible with a different repository (for example : trunk) ?
If not, how do people review the changes before updating then??
I looked at Team->Merge, but this seems to update the changes directly to my working copy, without the possibility to review the changes first (the Preview-function is confusing, I think, and doesn't provide the nice side-by-side view of changes/conflicts that Synchronize has).
The right way to do this is with Merge. Subclipse includes a merge client that makes this easy to do. You are right that it does not give you a true preview, but the way it works is better from a Subversion perspective. The Merge Results view UI is basically the same as the Synchronize view. It lets you easily examine every change that the merge made in your working copy and the Eclipse compare editor that it opens makes it very easy to take out any parts of the change that you do not want in your code before you commit.
The problem with trying to do this from the Synchronize view is that you are then doing the merge yourself using code editors and Subversion has no awareness of what is merged. If you let Subversion first do the merge, then it can update all of its metadata properly and it is perfectly fine for you to then fixup the code to be the way you want it before you commit the results of the merge.
I'd checkout both branch and trunk as a separate eclipse projects into workspace. Then use some merging tool, for example meld to merge changes between them. After merge you can refresh branch in Eclipse and synchronize it with svn repository - now you can review all changes. (it's how I do it, since I do not believe svn eclipse plugin ;))
I agree that it is not really intuitive by design, but Mark is right, you "synchronize" your changes when committing them back to the trunk:
first make sure your local branch is completely synchronized with your repository branch (no changes)
Team -> Merge... your local copy of the branch with the repository trunk
you now have a local version of that merge
you can locally edit this version, make sure tests are working and there are no compiler errors
finally you synchronize your local merged branch version with the repository branch and commit all changes that have been made
besides, the same way you'll merge your branch back into the repository trunk
make sure all changes of your branch are committed to the repository branch
switch to the trunk Team -> Switch...
merge your trunk with your branch Team -> Merge... (Tab 'Reintegrate')
you now have a local version of the merge, you may edit the changes and review them, make sure that you have a working version now
synchronize your local trunk (merged version) with the repository trunk
commit all changes that you want to appear in the trunk
i recommend to commit all changes that you've made locally to your merge, since you've tested them locally. if you commit just a few changes, make sure the repository version is still working then with missing changes