What dev workflow should I have, inc FTP and Github?

I’m not a pro developer.

So far, my Atom environment has involved using the ftp-remote-edit package to live-edit files on my webhost, and across two machines.

Two changes:

  • I had been syncing Atom settings using Dropbox. Now I am aiming to use sync-settings.
  • I am looking at switching from ftp-remote-edit to remote-ftp.

Now I also want to start posting some repositories to GitHub. I have fired up the GitHub package in Atom. But I’m confused about what my workflow/environment should be.

There are two hurdles I see…

  • remote-ftp requires a local Project, which actually seems unnecessary if the aim of which is to save files directly on the remote server. I guess I could store that Project in a Dropbox file, for use across the two machines.
  • The GitHub part… is it the case that the Staging process will only work for files stored and edited in a local project? ie. I can’t make a repository and commit to it from the files in the “Remote” tree pane shown by remote-ftp?

Maybe you’ll say the correct way to do things is to have a full local environment in which to develop and test, then stage to both FTP and GitHub when code is ready. But, at this stage, I’m unlikely to replicate my website (WordPress development) locally and want to continue editing it remotely.

I’m a bit confused as I’m not an Atom expert and and only now getting in to GitHub, so I want to learn.

Thanks.

atom-commander lets you interact directly with your FTP folder, with no local project required.

It is the case that a core package, like github, will never assume the presence of any community package, and so categorically can’t have any features that interact with the community package aside from public services made available to all packages. It’s also the case that there’s a fundamentally different action involved in making a git commit command on a remote server versus your local machine, so there’s zero chance of accidental compatibility.

If you want to run commands on a remote server, I recommend the process-palette package. It allows you to set up whatever string or environment you want, with variables to pull in information like the filename. It would be super-easy to set up a command to do ssh -t me@myserver.com 'git add .' (you need to set up key authentication first or it just won’t work). The package gives each command string an in-Atom command name, which can then be bound to a keybinding or a toolbar button.

If I understand correctly, remote-ftp and the GitHub extension won’t play nicely with each other, so no committing from the Remote view spun up by remote-ftp?

I was wondering if this is a reason the files in the Git window are not changing from green to orange when modified. The truth may be that I’m not yet fully understanding the Git/GitHub extension per se. It’s also the case that, when modifying a file from the left-hand, Project tree, I can’t get them to change to orange in the Git window either…

Which may prompt me to wonder about the whole relationship between the local folder (“Project”) and the Remote view via remote-ftp. My Project folder contains some of the files edited and stored on the server, but not all of them. Not sure of the relationship. Maybe remote-ftp is using the dedicated, user-specified local folder as its own cacheing folder in which to save before uploading, whereas ftp-remote-edit, which I had used until this week, I think uses the equivalent local cacheing but in a hidden folder, rather than a user-specified one.

Still, My GitHub pane just shows…

“This repository does not have any remotes hosted at GitHub.com

… so it’s not clear to me how to create or link to a GitHub repository. How do I do that?

atom-commander lets you interact directly with your FTP folder, with no local project required.

Thanks. The other two seem more appealing given they employ a tree structure on the left.

If you say that they “won’t play nicely”, it makes it sound like you can’t have both packages installed at once because they have a negative interaction. They have absolutely no interaction or knowledge of each other’s existence, so how they play together is a non-question because, even though we can imagine it, from the code’s perspective it’s a physical impossibility. That’s all. What you want can be done, but someone would have to write a package to do it. It wouldn’t be a difficult package to write (you’re just automating a very predictable command line string with a little user input, using the tried and tested ssh and git programs), but it might not be worth it when there’s a package in process-palette that can automate any instruction you give it. Do you want thirty packages that all basically do one thing, or one package that can do anything?

I was wondering if this is a reason the files in the Git window are not changing from green to orange when modified. The truth may be that I’m not yet fully understanding the Git/GitHub extension per se. It’s also the case that, when modifying a file from the left-hand, Project tree, I can’t get them to change to orange in the Git window either…

You don’t actually have a remote repo for that folder. Everything is “green” in the Git tab because there are no remote files, so everything is a new file. Nothing is colored in tree-view and you don’t have the “git repo” icon next to the Context directory name because there’s no remote. You need to open the command line and run git add remote origin followed by the address of your repo on GitHub or Bitbucket or whatever you use. Then run git push -u origin to affirmatively tell git to push everything to the origin and everything should work swell. I’ve done this a bunch of times. Then again, for that to work you have to actually have all of your files on your computer, and you just want to touch them with FTP.

One more note: Make sure that the repo you have remotely is either exactly the same project or completely blank. If you try to hook the wrong repos together, git will complain a lot even if the code files are identical. This is because it doesn’t look at the code, but at the commit hashes stored in the .git/ folder.

Which may prompt me to wonder about the whole relationship between the local folder (“Project”) and the Remote view via remote-ftp.

The local folder is Context/. And it doesn’t have any relationship, except that things you download from your FTP server are going to end up there. The tab you keep calling “Project” is the tree view. It’s entitled such because it is the tab where you go to look at all the folders that are a part of the active project (in Atom’s world, that’s everything you have open in a particular window).

… so it’s not clear to me how to create or link to a GitHub repository. How do I do that?

I recommend checking out GitHub’s documentation.

Thanks. The other two seem more appealing given they employ a tree structure on the left.

atom-commander can’t do a tree, but all you have to do to get a dock item to the left side is click on the tab and drag it up to the tab bar on the left dock.

Okay, maybe now I’m getting somewhere. It seems GitHub initialisation through the command line, through a repo already created at github.com, is necessary first? And that’s on top of establishing git/GitHub proficiency before GitHub-in-Atom proficiency?

So it seems the instructions are something like… ?

  • Create a repo on github.com
  • Set it up as a remote repository for the Atom project…
    • In Terminal, change to Atom Project folder.
    • Run git add remote origin git@github.com:myusername/my-title.git ?? (or URL?)
  • Push?
    • Run git push -u origin (but when? I this a one-time before editing code, or the step after making edits?)

Then again, for that to work you have to actually have all of your files on your computer, and you just want to touch them with FTP.

Exactly. I think this is an additional factor in the workflow I am trying to achieve.

As I said, I have this situation where I would like to continue making direct edits to files on my server (even if I recognise that doesn’t sound wisest).

But I also have this interest in posting some of that code to GitHub, and so I’m clearly striving to understand GitHub and GitHub+Atom.

I appreciate your replies.

Broad answer: no, it’s not necessary, and there are many ways to get to the harmonious conclusion. Specific answer: yes, based on what you’ve done so far, the fastest way to get your Context/ folder working with Atom’s git features is to fix the repo using the command line. Atom will recognize any correctly-formed repository and it will respect any remotes configured for those repositories. If you’re starting from an initialized repo with no remotes, Atom doesn’t have a feature to set them and you can either use a program like Git for Desktop or GitKraken (I suggest checking out the latter), or you can run the commands.

So it seems the instructions are something like… ?

If this is your first step, all you have to do is use the GitHub:Clone command (alt-g and then =) or git clone from the command line, or clone in another app. However, you already have a repo on your computer, so that has to either be purged or fixed.

  • Run git add remote origin git@github.com:myusername/my-title.git ?? (or URL?)

You can. That string works. I use git clone http://github.com/myusername/my-title because it’s shorter and easier to remember.

  • Run git push -u origin (but when? I this a one-time before editing code, or the step after making edits?)

If you get the repo set up correctly, you won’t have to do anything on the command line again. The -u origin switch tells the repo where to push to, and once that’s been done it will remember. Atom can’t send that switch, as far as I know, so you have to do it.

But I also have this interest in posting some of that code to GitHub, and so I’m clearly striving to understand GitHub and GitHub+Atom.

But Atom only reads files on your computer, so you have to have the files on your computer if you want to interact with them through the github package. You can, of course, use ssh from within a package inside Atom, such as termination or process-palette, and through the connection you can run whatever git commands you want, provided git is installed on your server (if you’re using a stock Ubuntu server—and unless you have a reason to not be you should—it 100% is).