Use Git version control on Launchpad
#11
Posted 27 March 2016 - 05:07 AM
I would appreciate it if you could comment on the document (requires a Microsoft account) or in this thread. In particular, I will be looking to answer any questions raised by editing the document, so that it provides the best information for the switch.
#12
Posted 27 March 2016 - 06:44 AM
I am not familiar with Git, although I know it is widely praised. I am curious about its ability to pull and push changes. Is there magic here in fixing up coding conflicts that usually come with a merge, or is it just a line by line text merge of the code as we might have seen in SVN?
#13
Posted 27 March 2016 - 12:46 PM
first of all thank you very much for your document. It's exactly what I - that never used git - needed. I hope I will able to replicate the full flow.
Personally I was comfortable with Tortoise, but I understand there can be advantages here.
#14
Posted 27 March 2016 - 04:00 PM
wacampbell, on 27 March 2016 - 06:44 AM, said:
The pushing and fetching do not involve any merging themselves, as they're simply replicating one set of commits/history in to another repository. If you and I both make commits on branch A, when I get your commits locally I will have a divergent history. Git provides multiple options for resolving that:
- If my changes have not yet been shared, I have the option to "rebase" - which is effectively replaying my work on top of yours, so it becomes linear.
- In all cases, I have the option to "merge" - which is much the same as in Subversion, taking both histories and trying to reconcile their unique differences.
In both cases, conflicts can (and do occasionally) arise. Resolution is identical to Subversion, and if you use TortoiseGit you'll have exactly the same UI for it too. :)
I believe that Git can avoid merging and do better at it when it does happen for two reasons:
- Its history of commits and their parents is very precise and correct, where as Subversion has been lacking quite badly in this area - so Git has better information about the ancestry available.
- Its default merge algorithm can cope with multiple common ancestors, using the "recursive" merge strategy (the default), for when you've already done some merging and are re-merging branches and that kind of thing.
Git can also use other merge strategies and even has a few diff algorithms that can be selected in cases where the default "myers" is not working well. That flexibility is something I've not yet exploited, but is probably good to have in the toolkit.
#17
Posted 23 April 2016 - 09:59 AM
James Ross, on 26 November 2015 - 01:36 PM, said:
I've been collaborating with a colleague recently (using Microsoft Team Explorer) and being able to try things out and share is so much more productive. I never learned how to do that in the SVN that OR uses.
Hopefully, with Git we can work together much more easily.
#18
Posted 11 June 2016 - 06:39 AM
#19
Posted 11 June 2016 - 06:46 AM
James Ross, on 27 March 2016 - 05:07 AM, said:
I worked through your Git workflow example so here is some feedback. As a newcomer to Git, I found a few sticking points in following the example.
Step 1: New repository
It wasn't clear that I should create a branch "develop" at this stage as I would need it in Step 4.
Step 2: Create a branch for doing some work
I puzzled over "feature/example" wondering if "/" was a command parameter. I've since confirmed that branches can contain "/" characters and form a hierarchy.
Step 3: Make changes
After making a change, my commit failed as no files had been added.
I fixed this by including the -a attribute but is that best practice?
git commit -a -m “This is an example commit”
Step 4: Combine with work from others
After switching back to the branch "develop", "git pull" failed with
"There is no tracking information for the current branch."
I tried a few things but without success.
How do I fix this?
Thanks
#20
Posted 12 June 2016 - 06:35 PM
cjakeman, on 11 June 2016 - 06:46 AM, said:
After making a change, my commit failed as no files had been added.
I fixed this by including the -a attribute but is that best practice?
git commit -a -m “This is an example commit”
I think this is not the best practice.
Best practice would be :
1) Add the files you want to include in the repository : git add <file name list>
This allows you to control what you want to include. For example, you don't want to include build files (not the best example : build files can be ignored using a .gitignore file).
2) Then commit : git commit -m <commit message>