Git/Visual Studio Code setup

Make sure that you are signed in to VPN (GlobalProtect) or using AdobeCorp in the office.

Sign in to GitHub - Adobe Enterprise Docs using your LDAP.

If this is the first time you have signed in to Enterprise github.com, an Enterprise GitHub account is created for you.

Note that this Adobe Enterprise account is different from a personal GitHub.com account you may have created. You can sign in to only one account at a time in a browser, unless you use Incognito or Private tabs.

If you don’t have access to a repo, ask Bob (bbringhu) or another Org Owner to give you Write or Admin access to any repo you’ll be working on.

By default, new members have Read access. You’ll want Write or Admin access for any repo in which you’ll need to publish content.

Decide which Git client and Markdown editor you want to use.

Most of us use GitHub Desktop for the client and Visual Studio Code for the editor.

Both are free. Some people prefer using SourceTree or command line tools for the client. That’s fine.

Sign in to GitHub Desktop (if you’re using it as a client).

Make sure you’re signed in to VPN or AdobeCorp. In GitHub Desktop, go into Preferences > Accounts and specify your GitHub Enterprise Server user name and password. Use your Adobe LDAP info.

You must be signed in to Adobe Corp or VPN to use the GitHub Enterprise Server.

(Recommended) Install Git on your computer.

Installing Git improves the communication between Visual Studio Code and Git/GitHub Desktop.

On a Mac, the Homebrew option works well. Contact Bob if you need help installing.

Customize Visual Studio Code (if you’re using it as an editor).

• Install the Adobe Markdown Authoring plugin.
• See VSC add-ons for a list of other extensions we find helpful.

Consider installing the AdobeDocs Chrome extension.

Become familiar with Adobe Markdown syntax.

Continue to learn Git.

If you want a demo or if you have questions, feel free to reach out to Bob. If you have questions about editorial issues or guidelines, contact Blake or Alva. We’re available through Slack and email.

If you have not already done so, add your GHEC Enterprise account to GitHub Desktop > Settings > Account.

Go to the repository’s git Enterprise page in your browser and click the Clone or download button on the right side, and then click Open in Desktop.

You can also clone directly from within GitHub Desktop via File > Clone Repository. If you use this method, make sure that you clone the Enterprise version, not the public mirror.

Click Allow to open GitHub Desktop.

Specify the location of the cloned files (the default is a “GitHub” folder in your Documents folder).

Click Clone.

In GitHub Desktop, click Fetch Origin to pull the files down from the server to your hard drive.

Open the Markdown files in your editor of choice, and save the Markdown files. Any changes you make to the cloned files are listed in GitHub Desktop.

Make sure that you have admin rights to your repo. Contact the SSE team if necessary.

Open your repo on github.com/adobe-enterprise-docs and click the Settings tab.

Click Branches in the left rail.

Click Add Rule if there is not an existing rule for the main branch. (Click Edit if there’s already a rule for main.)

If you’re creating a rule, specify the branch name such as master or staging in the Branch name pattern field.

Specify the branch protection rules.

• (Optional) Select Require pull request reviews before merging if you want someone to acknowledge approval before a PR is merged. (Writers usually choose not to select this option.)

• (Recommended) Select Require status checks to pass before merging and specify Validation. This requires the pull request to pass validation before it can be merged to main.

• (Optional) Select Require branches to be up to date before merging if you want to make sure that the main branch is up to date. Selecting this option can help reduce Git conflicts, but updating the main branch re-triggers validation. With larger repos, re-running validation can be time-consuming, especially during a release cycle when multiple writers are updating the main.

• (Optional) Select Include Administrators if you want everyone, including admins, to wait for validation to succeed. (Writers usually choose not to select this option.)

• (Optional) Select Restrict who can push to matching branches (recommended) and specify the members of your team, if anyone, who can push directory to master. When this option is selected, only the specified team members can commit directly to master. Everyone else needs to submit a pull request from a branch.

  note
  NOTE
  When you restrict who can push directly to master, writers can get stuck in GitHub Desktop when they accidently attempt to commit the changes to the main branch instead of a different branch. When this happens, have an admin go change settings to allow the changes to go through, and then change the settings back. (There’s probably a better way to handle this in GitHub Desktop, but I haven’t figured it out…)