|
It looks like you're creating 2.5.1 as a branch and not a tag, though. Are you tagging it later on? I think if you have a branch and a tag with the same name it has issues with ambiguity when you try to checkout that ref.code:For your second question, you can merge in the tag if you have a multiple engineers working on the branch: code:code:1. Master is the "stable" branch. In your case this would be 2.5.0 at the start. 2. Develop is the "unstable" branch. New work for 2.6.0 should be merged here when completed. 3. When you need to make bug fixes for 2.5.x you create a branch based off of master (or the tag, but master should always be the latest stable tag), do your testing with this branch, etc... When you're done with the fixes and they are verified you can merge that branch back into master and tag as 2.5.1. 4. To get changes into develop you have two options: (1) rebase develop onto master. As people should not be working directly on this branch it should not disrupt peoples flows. If someone working on a feature requires the bugfix they can now rebase on develop. (2) simply merge it into develop. The downside of this now develop will have a merge commit at a later point than master. I personally like the first option under 4, but I think people have pretty varying opinions on this.
|
#
?
Mar 27, 2014 20:31
|
|
|
|
| # ? Jun 5, 2024 16:42 |
|
|
I was just gonna leave 2.5.1 as a branch and not tag it. I guess what I should have done was create a branch for 2.6.0 after releasing 2.5.0. At this point I've already merged stuff that is for 2.6.0 back into master, thinking that I was going to be able to tag 2.6.0 very soon and release it. Thanks for all the info, I think it makes sense now.
|
|
#
?
Mar 27, 2014 21:54
|
|
|
The downside of leaving 2.5.1 as a branch is that it clutters up your list of branches forever. Sticking to tags for completed things and branches for things in progress improves the UI if nothing else. My personal preference workflow-wise is to actively develop on master, create branches off tagged releases for hotfixes and just cherry-pick commits between branches as needed. If you were planning on releasing some point releases for 2.5 while working on 2.6, then just have a 2.5 branch that has applicable stuff cherry-picked over. Plorkyeran fucked around with this message at 23:49 on Mar 27, 2014 |
|
#
?
Mar 27, 2014 23:45
|
|
|
fletcher posted:So two questions: (1) Is this an acceptable way of doing it? (2) How should I incorporate the changes made for 2.5.1 into 2.6.0? 1. Sure 2. `git cherry-pick`
|
|
#
?
Mar 28, 2014 06:55
|
|
|
edit: Answered my own question.
Woodsy Owl fucked around with this message at 10:12 on Mar 28, 2014 |
|
#
?
Mar 28, 2014 10:02
|
|
|
Plorkyeran posted:The downside of leaving 2.5.1 as a branch is that it clutters up your list of branches forever. Sticking to tags for completed things and branches for things in progress improves the UI if nothing else. I went back today and changed it to be like you described, makes a lot more sense now. It was a little scary rewriting history and cleaning everything up, but the end result looks great now. 2.5.1 is now a tag right after 2.5.0 and all of the 2.6.0-dev stuff is on a new branch, which will be merged back to master and tagged as 2.6.0 at release time. So thanks again to you and others for the advice! Fortunately I'm the only developer using this repo still 
|
|
#
?
Apr 1, 2014 00:23
|
|
|
Is there a way to move files between branches without doing the checkout first? Or maybe it would be better to explain what I'm trying to do and see if there is a better solution:
|
|
#
?
Apr 1, 2014 13:16
|
|
|
You can't really do much to not-checked-out branches other than change the commit they point at. I recommend just having a second copy of the repo cloned which you use for updating the gh-pages branch with the built files. gh-pages is not at all something git is designed to do.
|
|
#
?
Apr 1, 2014 15:48
|
|
|
^^^^ This. And perhaps a script to go check out repo, build these files and rsync it together and commit it for ya.
|
|
#
?
Apr 1, 2014 16:33
|
|
|
Anyone aware of a good pre-packaged talk (speaker's notes and slide deck) for introducing a team to Git? I'm going to be doing that soon and figured why reinvent the wheel.
|
|
#
?
Apr 1, 2014 17:05
|
|
|
That's a shame, but it's understandable. "Website deployment" is probably a bit of an awkward (ab)use of version control. I'll probably go with the simplest option of just cp build dir to /tmp/, checkout gh-pages and cp back  .
|
|
#
?
Apr 1, 2014 17:08
|
|
|
Ender.uNF posted:Anyone aware of a good pre-packaged talk (speaker's notes and slide deck) for introducing a team to Git? I'm sure at least one of these must not be terrible: http://www.slideshare.net/search/slideshow?searchfrom=header&q=git (Slideshare is so frustrating -- it's really only good when they include a link to the presentation being given somewhere.)
|
|
#
?
Apr 1, 2014 17:57
|
|
|
prefect posted:I'm sure at least one of these must not be terrible: http://www.slideshare.net/search/slideshow?searchfrom=header&q=git Maybe you can find something from here: https://www.google.com/search?q=git+presentation
|
|
#
?
Apr 1, 2014 18:48
|
|
|
Sneaking Mission posted:Maybe you can find something from here: https://www.google.com/search?q=git+presentation I can't tell if that's snark directed at me or prefect, but I have been searching Google. So far I've found a lot of great info on git, just not something designed for someone who already knows git to present to a team that doesn't.
|
|
#
?
Apr 1, 2014 18:53
|
|
|
Xik posted:Is there a way to move files between branches without doing the checkout first? Or maybe it would be better to explain what I'm trying to do and see if there is a better solution: You can totally do this. I work on a project that always builds things from commits, so there's a command to build that makes a commit for you on another branch without touching your workspace. In true git tradition, I could knock that up as a shell script for you in an hour or so.
|
|
#
?
Apr 1, 2014 20:10
|
|
only
|
Here's a hackjob. Run the script as BRANCH_NAME FILE1 FILE2 FILE3... The branch name has to be the full name for the first commit e.g. refs/heads/lookaside, but just lookaside should work after that. code:
|
|
#
?
Apr 1, 2014 22:12
|
|
|
Ender.uNF posted:I can't tell if that's snark directed at me or prefect, but I have been searching Google. So far I've found a lot of great info on git, just not something designed for someone who already knows git to present to a team that doesn't. And to answer my own question: https://github.com/schacon/git-presentations Some excellent Keynote presentations to work with. Thanks, schacon!
|
|
#
?
Apr 2, 2014 03:58
|
|
|
Edison was a dick posted:Here's a hackjob. Run the script as BRANCH_NAME FILE1 FILE2 FILE3... You're totally awesome Edison. I'll probably have to spend some time learning what the git commands in the script do but since the entire point of my current project is to become more familiar with a bunch of tools, this suits me just fine. Thanks a bunch!
|
|
#
?
Apr 2, 2014 07:54
|
|
|
Can someone give me a use case for why I shouldn't always use git fetch -p It's a pain in the rear end when cleaning up old branches that I have to do "git remote prune origin" on various servers, or basically when fetching anywhere. But presumably it's turned off for a reason - I could understand if git gave you some indication that branches had been removed on origin, a bit like "you are x commits behind", but it doesn't. You can still resurrect a deleted branch and commit to it locally unless you prune?
|
|
#
?
Apr 2, 2014 11:20
|
|
|
I use "git fetch -p" almost always as well but I can imagine it not being the default because one wouldn't want local branches to be deleted without explicitly telling Git to do so. Maybe you're working on that branch and plan to merge it into another one locally even if you're aware it has been deleted remotely. Then again, I can imagine Git warning you if you've got changes in your local branch and also if you've got a local branch that happens to be accidentally named the same as a remote branch. A good candidate for an alias I think.
|
|
#
?
Apr 2, 2014 12:26
|
|
|
Sure, that makes total sense; does prune delete the local branch as well? My above post was under the assumption that the local branch remains after prune, but if it deletes the local ref as well then totally it shouldn't be default.
|
|
#
?
Apr 2, 2014 13:14
|
|
|
Ender.uNF posted:I can't tell if that's snark directed at me or prefect, but I have been searching Google. So far I've found a lot of great info on git, just not something designed for someone who already knows git to present to a team that doesn't. I deserved some snark; I was mostly posting to whine about slideshare, not because I had any genuinely helpful, specific advice. 
|
|
#
?
Apr 2, 2014 13:16
|
|
|
oiseaux morts 1994 posted:Sure, that makes total sense; does prune delete the local branch as well? My above post was under the assumption that the local branch remains after prune, but if it deletes the local ref as well then totally it shouldn't be default. Hmm, the doc says it only removes remote-tracking branches so my examples might not have been appropriate at all. Sorry for potentially spouting nonsense earlier. I'll leave further comments on this matter to people more knowledgeable than me.
|
|
#
?
Apr 2, 2014 13:35
|
|
|
So now the apache subversion project isn't using subversion anymore: https://issues.apache.org/jira/browse/INFRA-7524
|
|
#
?
Apr 2, 2014 14:02
|
|
|
That's the one problem with April Fools' Day on the web, stuff sticks around for days or weeks (or months or years).
|
|
#
?
Apr 2, 2014 15:34
|
|
|
poo poo, the 4 people covering the story didn't pick that up.
|
|
#
?
Apr 2, 2014 17:08
|
|
|
It's in the title...
|
|
#
?
Apr 2, 2014 17:20
|
|
|
It wasn't when they started. They actually said it was real a few times, after people suspected it was an AF joke.
|
|
#
?
Apr 2, 2014 18:10
|
|
|
I'm new to git. If there's a project on a private server that only I am working on, I just want to be able to track changes and revert if need be, is there any reason I can't use git init without --bare? I don't want to have to push to a clone and then SSH to the server and merge back into the master every time I make a change. I know nobody else will be working on it, but when I try to push to the master (bare repository) it gives a warning and blocks it, saying that there could be data loss etc. Surely if I'm the only contributor this won't be an issue and I can safely disable this warning for this project? Or is the normal thing, even in this circumstance, to 'git init' into the working files, then clone that to a repository that handles development, then push to the second repository, SSH to the server and pull from there into the master?
|
|
|
#
?
Apr 5, 2014 10:21
|
|
|
Sulla-Marius 88 posted:I'm new to git. If there's a project on a private server that only I am working on, I just want to be able to track changes and revert if need be, is there any reason I can't use git init without --bare? I don't want to have to push to a clone and then SSH to the server and merge back into the master every time I make a change. I know nobody else will be working on it, but when I try to push to the master (bare repository) it gives a warning and blocks it, saying that there could be data loss etc. Surely if I'm the only contributor this won't be an issue and I can safely disable this warning for this project? Git is not a deployment mechanism, which is the main problem. You can ignore the warnings if you KNOW you'll never change anything by hand on your remote, but there's a reason for that warning.
|
|
#
?
Apr 5, 2014 13:35
|
|
|
Ah. I guess that makes sense. So what's the standard procedure here, then? 'git init' the original/production folder, 'git clone' it into a branch that I push changes to, then on the server manually merge the two? Or.. what?
|
|
|
#
?
Apr 5, 2014 13:40
|
|
|
on the server you could use a hook which checks out the newly pushed stuff into your production location for example, this in .git/hooks/post-receive: #!/bin/sh GIT_WORK_TREE=/var/wherever git checkout -f #and perhaps this line (cd /var/wherever && init-the-deployment.sh)
|
|
#
?
Apr 5, 2014 13:59
|
|
|
Sulla-Marius 88 posted:Ah. I guess that makes sense. So what's the standard procedure here, then? 'git init' the original/production folder, 'git clone' it into a branch that I push changes to, then on the server manually merge the two? Or.. what?
|
|
#
?
Apr 5, 2014 14:57
|
|
|
I've set up the git server on my own server so I don't use github at all. I've found it really tough to find tutorials or introductory guides to git that teach you how to use git when setting up your own server and with existing source code. Gul Banana so I create a copy of the master that I commit/push changes to, and that hook waits for incoming pushes and automatically pushes it out to the original repository?
|
|
|
#
?
Apr 5, 2014 15:22
|
|
|
Sulla-Marius 88 posted:I've set up the git server on my own server so I don't use github at all. I've found it really tough to find tutorials or introductory guides to git that teach you how to use git when setting up your own server and with existing source code. I think a large part of this is that if you aren't doing something complicated, there is basically no setup needed - git init --bare on the server, git init on the client with the existing source, add the server as a remote, push/fetch as needed. If you are doing something complicated, like wanting to automatically deploy your code to production when pushed to the server, you're now getting away from plain git and into deployment systems built around git. Sulla-Marius 88 posted:Gul Banana so I create a copy of the master that I commit/push changes to, and that hook waits for incoming pushes and automatically pushes it out to the original repository? What? No. You have a non-bare repo locally you use for actual development. You have a bare repo on the server. When you push to the bare repo, the post-receive hook runs and deploys the changes you just pushed to the directory where your software is actually deployed, e.g. /var/www/. The deployment directory is not actually a git repo. The #git help text for !deploy may also be relevant here: quote:<gitinfo> Git is not a deployment tool, but you can build one around it (in simple environments) or use it as an object store(for complex ones). Here are some options/ideas to get you started: http://gitolite.com/deploy.html ToxicFrog fucked around with this message at 15:30 on Apr 5, 2014 |
|
#
?
Apr 5, 2014 15:27
|
|
|
I'm trying to start from scratch and I'm getting some bizarre behaviour here. I'm trying to use SourceTree on windows to manage it. I'm hoping to have git on the server, that can handle versioning and auto-deploy to the working files. So I have: Server: /home/username/http/hosts/* is the directory that holds all my files. /home/username/http/dev_git/.git holds the non-bare repository. I did 'git init' in /dev_git/ to create it -- folder has nothing else in it. In SourceTree I modify the remote repository to point to the new one: ssh://username@server.ip.address.here:port/home/username/http/hosts/dev_git/.git And try to push 3 php files that I've modified, should be about 10 kb total. It spends a couple minutes uploading at goddamn 2-5mb/s before warning with something weird and erroring out, so I decide to delete the local content and try again from scratch in case it's screwing up because of the changed context or it's trying to upload every single file in my local copy of the site code, rather than just the 3 files in the commit. So I delete the local, start a whole new project in sourcetree and try to connect. And it starts downloading at 1.5mb/s for like 30+ seconds. I'm on internet with a pretty shallow data transfer limit so I had to cancel it after about 30 seconds because honestly where the hell is it getting this from? The whole size of the git folder on the server is 22mb. I just cancelled, deleted the local copy, and tried again -- about a minute at 2.5mb/s download and still no end in sight. I'm super confused and I don't know why it's doing this. Essentially what I want is: The production directory on the server. An exact copy of that code on my local machine (I already have this). A way so that changes made on the local machine can be pushed to the production directory while keeping a record of changes. I still don't understand why the initial setup didn't work, why it really didn't want me to push directly to the master branch of the original repository. I also don't know why it's trying to download so much when all the data involved is only like 22mb. e: Removed a bit of whinging. Sulla Faex fucked around with this message at 20:41 on Apr 5, 2014 |
|
|
#
?
Apr 5, 2014 20:12
|
|
|
If I 'git init' into the production directory, that will create the master. Should I then: git branch develop; git checkout develop? And connect Sourcetree to that branch, take the hit and download all the source files again, and add a post-receive hook to auto-merge the develop branch back into master?
|
|
|
#
?
Apr 5, 2014 20:38
|
|
|
I'm not sure what you're doing but I think you're making things more complicated then they need to be. It's also possible there is some confusion about the distributed nature of git that is tripping you up.code:
I now have a git repository with a file and history. I can clone it and make an exact duplicate of it. This can be done locally to somewhere else on the file system or remotely over ssh. code:
So say I made some changes in the test_repo_clone folder. I added ('staged') them and then committed them. It's now a head or out of "sync" from the other. I can navigate back into the test_repo and pull in the changes I just made to the other: code:To understand why and what the difference is, check out this article. With one of them being "bare" you can add it as a remote and "push" changes to it. If you can understand the above, you can then go on to learn about branches and then worry about hooks. I'm not trying to be condescending, but it's probably best you understand the basic concepts before worrying about more advanced stuff.
|
|
#
?
Apr 5, 2014 21:18
|
|
|
You can test the server -> client relationship locally like so:code:code:code:code:code:
|
|
#
?
Apr 5, 2014 21:50
|
|
|
|
| # ? Jun 5, 2024 16:42 |
|
|
Anyone here using this Visual Studio Online "cloud" repository thing? How smooth does it work? It seems to be free for up to 5 users with my MSDN account, seeing how I'm just one, this may fit.
|
|
#
?
Apr 6, 2014 13:30
|
|
